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

FS#14176 — GSW Paris

Attached to Project— Reseau Internet et Baies
Incident
Paris   → GSW
CLOSED
100%
Le POP de Globalswitch est down. Nous investiguons.
Date:  Wednesday, 29 July 2015, 17:12PM
Reason for closing:  Done
Comment by OVH - Wednesday, 29 July 2015, 16:03PM

Une erreur humaine est à l'origine du probleme. La
configuration OSPF a coupé le routeur de GSW.

Le trafic a été repris par TH2 sur Paris.


Comment by OVH - Wednesday, 29 July 2015, 16:07PM

On a des comportements bizarres sur le th2-1-a9 mais
pas seulement. Les routes qui sont habituellement
annoncés par GSW sont toujours là.

On cherche.

Apparament l'un des routeurs "reflector" (rf-3-a1) n'a
pas annoncé à tous les autres routeurs que le routeur
GSW est down. Du coup, les routeurs vers GSW sont toujours
installés.

On coupe la session BGP vers le rf-3-a1 et th2-1-a9 pour
verifier.

Ca fixe. Okey c'est par là.

On coupe toutes les sessions BGP

rf-3-a1#clear ip bgp *


Comment by OVH - Wednesday, 29 July 2015, 16:13PM

Le rf-1-a1 est down avec GSW.

On a fait le reset de rf-3-a1 qui a apparament un bug.
Durant quelques minutes on a donc été uniquement sur
seulement un RR rf-2-a1.


Comment by OVH - Wednesday, 29 July 2015, 16:38PM

Le reset de rf-3-a1 a fixé le probleme d'annonces qui
aurait dû disparaitre lorsque le routeur gsw-1-a9 a
été isolé.

Le trafic est revenu à la normal. On a été principalement
impacté vers les connexions gerées par gsw-1-a9:
- 50% de Free
- 50% d'Orange
- 30% Telefonica (Backup)
- 50% Google Eurupe

Transit:
- 20G Cogent
- 40G Tata
- 20G Level3
- 10G Telia

Le reste de la backbone continuait à fonctionner normalement.


Comment by OVH - Wednesday, 29 July 2015, 16:39PM

On fait le rollback sur la configuration gsw-1-a9.
On a coupé les sessions BGP avec les PNI et Transit.
On a remis la configuration OSPF.
C'est UP.
On remet les sessions BGP avec les peers.


Comment by OVH - Wednesday, 29 July 2015, 16:42PM

Tout est UP.


Comment by OVH - Wednesday, 29 July 2015, 17:12PM

Bonjour,
Nous venons d’avoir un incident sur le routage sur l’un
de 2 routeurs de Paris: gsw-1-a9. L’erreur humaine est
à l’origine de la panne: l’un des ingénieurs de l’équipe
network (c’est mon équipe ..) a effacé par erreur la configuration
OSPF sur le routeur. Malgré la double confirmation de
l’application de la configuration, il a confirmé yes yes ..
des automatismes .. Et donc le routeur gsw-1-a9 est
parti dans les choux.

Mais cela tout doit continuer à fonctionner. Sauf que nous
avons eu un bug BGP sur le 3eme routeurs reflector,
rf-3-a1 qui n’a pas communiqué au reste de la backbone
que gsw-1-a9 est down. rf-2-a1 l’a fait et rf-1-a1 a été
down durant la panne. Du coup la backbone continuait
à se comporter comme si le routeur gsw-1-a9 était UP.
On le voyait à travers les loops dans les traceroutes.

Nous avons redémarré toutes les sessions BGP sur
rf-3-a1 mais sachant que rf-1-a1 a été en panne avec
gsw-1-a9, et donc que seulement rf-2-a1 assurait la
synchronisation BGP entre tous les routeurs en Europe,
nous avons eu des yoyos dans le réseau en Europe:
ça pouvait pinger ou pas durant 60-120 secondes par
routeur.

En suite, tout est revenu puis nous avons remis la configuration
sur le routeur gsw-1-a9. La backbone est UP.

Nous sommes sincèrement désolés pour cette panne.
L’erreur humaine peut arriver et la backbone est preuve
pour faire face à ce genre de problèmes. On regarde
pour trouver le bug sur nos RR (ASR1002). Puis on va
déterrer la hache pour s’occuper des doigts de mes
gars ..

En savoir plus:
http://travaux.ovh.net/?do=details&id=14176

Amicalement
Octave