rssLink RSS for all categories
 
icon_red
icon_green
icon_green
icon_red
icon_red
icon_green
icon_green
icon_red
icon_red
icon_red
icon_green
icon_green
icon_green
icon_orange
icon_green
icon_red
icon_blue
icon_orange
icon_red
icon_green
icon_green
icon_red
icon_green
icon_red
icon_orange
icon_green
icon_green
icon_green
icon_green
icon_green
icon_green
icon_green
icon_green
 

FS#16851 — Infrastructure téléphonie

Attached to Project— VoIP
Incident
Backend / Core
CLOSED
100%
Suite au crash soft d'un de nos routeurs (cf FS#16850), certains services ont été perturbés durant quelques minutes.

Le support OVH téléphonique (1007) a subi une coupure des appels.
Le service sms a subi un retard dans l'acheminement des messages.
Les todos manager ont aussi subi un retard de traitement.

La situation est revenue à la normale.

Nous surveillons l'activité.
Date:  Wednesday, 09 March 2016, 12:06PM
Reason for closing:  Done
Comment by OVH - Tuesday, 01 March 2016, 19:56PM

Le routeur a recrashé. On change la carte.


Comment by OVH - Tuesday, 01 March 2016, 20:58PM

La carte a été remplacée.
Le routeur est UP.

Les services repartent.

Le retard sur les sms, ainsi que le traitement
des opérations sur le manager est résorbé


Comment by OVH - Wednesday, 02 March 2016, 05:09AM

Suite a deux nouveaux crashs plus tôt dans la soirée (cf FS#16850), nous allons remplacer le chassis du routeur.

Le châssis est arrivé à Paris. En attendant son installation, nous isolons le routeur.

Pas de soucis constatés depuis 23h


Comment by OVH - Wednesday, 02 March 2016, 08:15AM

Le service VoIP continue à fonctionner sans soucis.

Nous préparons le remplacement du châssis A. Normalement
ce soir nous allons le remplacer et nous allons remettre
en place la redondance courant de la nuit.


Comment by OVH - Wednesday, 02 March 2016, 08:56AM

Nous rencontrons actuellement des problèmes sur les infra c5c et c5d.

c5c remonte progressivement mais nous constatons des problèmes sur c5d.

Plus d'info dès que possible.


Comment by OVH - Wednesday, 02 March 2016, 09:05AM

Le défaut sur l'infra D est causé par un problème réseau, sans doute lié au problème du routeur de cette nuit.
Nos équipes sont dessus.
Nous tentons de rétablir la situation le plus rapidement possible.


Comment by OVH - Wednesday, 02 March 2016, 09:59AM

Le chassis c5d et proxy c ont un problème.
Nous avons sortir les lames de ce chassis et les avons remis une par une.
Le chassis ne remonte pas.
Nous l'avons redémarré électriquement.

Actuellement, environs 6000 clients doivent être impacté par ce problème qui impacte aussi sip3.ovh.fr


Comment by OVH - Wednesday, 02 March 2016, 10:12AM

nous avons attaché l'ip de sip3.ovh.fr sur le proxy B et migrons les clients de l'infra c5d vers c5a.

Nous avons récupéré la connexion à c5d et testons les connexions à la base de données.


Comment by OVH - Wednesday, 02 March 2016, 10:17AM

La moitié des clients sur sip3.ovh.fr sont remontées.


Comment by OVH - Wednesday, 02 March 2016, 10:19AM

actuellement, 90% des lignes sont remontées.


Comment by OVH - Wednesday, 02 March 2016, 11:58AM

Le routeur p19-v2-6k est revenu avec la configuration de nos ip publiques, impactant pendant 10min tout le trafic VOIP.

La situation est revenue à la normale. Nous surveillons l'activité.


Comment by OVH - Wednesday, 02 March 2016, 12:07PM

Nous effectuons un rafraîchissement de l'ensemble des écrans MGCP.


Comment by OVH - Wednesday, 02 March 2016, 12:21PM

Nous investiguons sur un problème sur les relais de voix de l'infrastructure A, provoquant des communications blanches de façon aléatoire.


Comment by OVH - Wednesday, 02 March 2016, 12:32PM

Nous avons rebooté un relais de voix, la situation est revenue à la normale sur l'infrastructure A.


Comment by OVH - Wednesday, 09 March 2016, 12:06PM

Dans la nuit du Mardi 2 au Mercredi 3 Mars 2016, à 19h20, nous avons
rencontré deux redémarrages intempestifs de l'un de nos deux routeurs, ce
routeur a perturbé les appels en cours sur l'infrastructure D et les
enregistrements sur sip3.ovh.fr. Normalement, le routeur de backup doit
assurer le relais sans coupure dans les communications. Cependant, le
chassis BCT7 Cirpack n'a pas réagit comme prévu. Un point est en cours
avec notre équipementier pour en étudier l'origine.

Après investigation avec Cisco, sur des cas passés qu'il avait pu rencontrer,
nous sommes arrivés à la conclusion que les redémarrages venaient du chassis du
routeur en lui-même. Un case à donc été immédiatement ouvert chez Cisco afin de
recevoir un nouveau chassis dans la nuit de mardi à mercredi.

Au cours de la nuit, les machines (autre que Cirpack) affectés sur ce routeur
ont été migrées, 120 câbles à rebrancher un par un vers le routeur de backup.
Aucun soucis n'a été constaté jusque Mercredi à 6h00. A 08h00, nous avons
eu les echos des premiers dysfonctionnements liés à une mauvaise remonté du
câble de management sur BCT7 sur l'infrastructure D de la veille, ce qui
a provoqué une panne pour les clients se connectant par ce proxy ainsi
que ceux dont les lignes étaient hébergées sur l'infrastructure D. 10% de nos
clients ont été impactés.

Sans cette interface de management, les masters et les slaves des lames
Cirpack ne peuvent plus communiquer ensemble. Normalement, il n'y a pas
d'impact une fois le chassis booté, le master restant master et le slave
passant en mode "config". mais ce process n'a pas bien fonctionné pour les
serveurs de base de données de l'infrastructure D, et les serveurs du proxy
sip3.ovh.fr. La situation pour ce problème est revenue à la normale à 10h40.

Loi des séries oblige, le routeur coupé pendant la nuit a été redémarré
suite à une mauvaise manipulation humaine à 11h00. Celui-ci étant branché
pour le flux entrant mais pas le flux sortant, celui-ci a aspiré le
trafic évitant le trafic de s'écouler du réseau. Celui-ci a été débranché de
suite pour revenir à la normal à 11h25.

Enfin, le reboot du routeur la veille a engendré deux phénomènes imprévus :
L'un de nos relais de voix de l'infrastructure A n'a pas pu invalider son cache
de session en cours après avoir perdu la communication avec son infrastructure.
De 11h30 à 12h30, le nombre de session à saturé ce qui en a suivi un phénomène de
communication blanche. Un redémarrage du relai a pu résoudre le soucis. Encore une
fois, ce comportement anormal a été remonté à notre équipementier.



L'année dernière nous avons quadruplé la taille de notre infrastructure
pour anticiper sereinement la croissance continue de notre parc et isoler
les pannes dans un périmètre restreint. Nous avons également mis en place
des solutions pour analyser le réseau de signalisation et notifier tout
les comportements anormaux par email ou dans le manager.

Après cette nuit et matinée mouvementé du mardi au mercredi 3 Mars,
nous avons pu voir que même si la configuration du réseau est conçue
pour gérer ce type de dénis de service, nous n'avions jamais
testé ce type de cas pour vérifier à 100% que tout est bien ok en cas
d'imprévu. Aussi, nous n'avons pas inclu la variable "test du comportement
du matériel Cirpack en cas d'imprévu réseau". De ce fait, nous devons
mettre en place une procédure de SPOF périodiquement sur notre
infrastructure (pourquoi pas, avec une configuration
réseau dupliquée à des lieux géographiques différents) pour voir
comment celui-ci se comporte et anticiper les
conséquences hardwares et softwares de l'infrastructure.

Aussi, nous nous sommes rendu compte que la réactivité aurait pu être
bien plus rapide avec des indicateurs
supplémentaires (monitoring des sessions de nos relais voix en live,
monitoring des proxy sip). Notre travail a déjà pu commencer dans ce sens.