OVHcloud Network Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
TH2
Incident
Report for Network & Infrastructure
Resolved
Nous avons actuellement un problème sur le POP de TH2 impactant une partie de la backbone.
Nous investiguons.
Update(s):
Date: 2017-07-27 20:26:38 UTC
Ayant eu des interrogations à ce sujet et pour préciser, il n'y a aucun SPOF dans l’architecture.
Sur Paris, nous avons tous les peering et tous les transit sur 2 POP espacés de 20 km et je parle que de Paris. Les DC sont connectés sur 3 à 6 POP en même temps.
Sur Paris 2 couples de routeurs qui fonctionnent indépendamment. Pour preuve, on lit bien dans le task travaux qu'on a isolé complètement les routeurs de TH2 durant 4H. durant 4H on n'a pas utilisé les infra de TH2.
Avez-vous été coupés du monde durant 4H où TH2 a été en travaux avec les ingés TAC de Cisco ? NON, aucun impact de couper un routeur. Donc pas de SPOF.
Chaque router sur notre backbone pousse entre 300Gbps à 700Gbps. Si on coupe électriquement un router, le réseau a besoin d'un peu de temps pour se recalculer. Combien en cas de panne électrique d'un POP ? Il faut compter quelques secondes pour que OSPF se coupe et le réseau se recalcule mais c'est surtout les 120 sec de BGP qui prennent du temps.
Ce que nous avons eu c'est un bug et ce sont les cas les plus chiant car la panne n'est pas aussi nette qu’une panne elec. On ne sait jamais à l'avance comment le réseau se comportera car cela dépend de la nature du bug. Dans ce cas, ce n’était particulièrement pas net :(
Et pourtant pour isoler immédiatement les routeurs on utilise un protocole encore + rapide que OSPF et BGP. C'est BFD qui vérifie que les liens sont UP tous les 100ms, 10x par seconde. S'il détecte un défaut, tout bascule en moins de100ms et vous ne voyez rien. Vous n’imaginez pas le nombre d'incident de liens on gère par jour sans aucun effet sur la prod.
Pour aller encore plus vite, les liens entre nos DC et les POP on les gère nous même à travers 2 routes optiques. Chaque 100G est envoyé sur 2 chemins de 300-800km et de l'autre côté le système surveille si le signale optique arrive encore. En cas de défaut, boom, ça bascule en
50ms.
Alors pourquoi avons-nous eu l'impact sur la prod avec le souci de TH2 ? Comme indiqué plus haut, il y avait un bug software dans .. le BFD lui-même. Le routeur de TH2 a planté le process BFD. Normalement le routeur aurait dû s'isoler de lui-même.
Mais il ne l'a pas fait. TH2 voyait les paquets BFD des routeurs RBX GRA SBG mais il n'envoyait plus les paquets BFD aux autres routeurs. Du coup RBX GRA et SBG ont bien isolé TH2 mais TH2 ne l'a pas fait. On a dû intervenir manuellement sur les infra, analyser la situation et prendre les bonnes décisions immédiatement.
Dans ce cas précis c'est toujours trop long, l'homme a la fâcheuse tendance à réfléchir pour savoir quel bras il faut couper. On a coupé TH2, bgp ospf, isoler le routeur, puis tout est revenu car tout est doublé en surcapacité sur GSW où nous avons exactement le même routeur à plusieurs millions et qui a fait son job.
Sur la backbone, on va mettre à jour les routeurs, durant le mois d'Aout, comme cela était prévu de longue date. La dernière version fixe les soucis de \"check parity\" et nous allons en savoir plus sur le bug qui nous a touché, s’il est déjà fixé ou sera fixé.
Dans quelques mois, nous allons enlever le reste de petits routeurs 6K de la backbone, comme cela sera fait cette nuit à Palo Alto, a été fait à San José la semaine passée et Los Angeles il y a 2 semaines.
Une fois que nous aurons uniquement des Cisco ASR9K sur la backbone, nous allons basculer OSPF vers ISIS, puis activer MPLS ce qui va améliorer encore plus la convergence en cas de pannes.
Nous espérons que la robustesse de notre architecture qui ne comporte aucun SPOF.
Tout est au pire doublé. Tout. Partout.
Il n'y a rien qui est en \"single\".
Date: 2017-07-26 14:18:38 UTC
Les quelques perturbations IPv6 sur xDSL sont fixées.
Date: 2017-07-26 13:59:12 UTC
Suite au reboot de th2-a9, nous avons quelques perturbations IPv6 sur le xDSL .
Nous analysons
Date: 2017-07-26 12:38:50 UTC
Tout est stable, nous surveillons attentivement th2-1-a9 pendant quelques heures.
Date: 2017-07-26 12:07:25 UTC
Nous dé-isolons également l'OSPF tout en surveillant les logs de l'équipement.
Date: 2017-07-26 12:01:22 UTC
Nous rallumons les peering BGP sur th2-1-a9.
Date: 2017-07-26 11:54:52 UTC
Lors du diagnostique réalisé avec notre fournisseur, il en est ressorti que nous avons rencontré un bug sur la FIB manager (celle-ci s'est bloquée), ce qui a entrainé une erreur de parité sur le routeur et a ensuite engendré l'incident.
Le routeur a rebooté, nous surveillons actuellement le routeur (celui ci est encore isolé pour le moment).
Date: 2017-07-26 11:42:22 UTC
Nous allons procéder au reload de toutes les location de th2-1-a9
Date: 2017-07-26 11:23:21 UTC
Notre fournisseur identifie un dysfonctionnement du fib-manager sur l'équipement concerné. Il complete son analyse avant de procéder à un réinitialisation de cet élément
Date: 2017-07-26 11:15:14 UTC
Notre fournisseur procède actuellement au diagnostique de l'équipement.
Date: 2017-07-26 10:57:30 UTC
Nous sommes actuellement en contact avec notre fournisseur pour comprendre la situation du a9.
Date: 2017-07-26 10:36:04 UTC
La grande majorité du service est revenue.
De l'impact peut encore être ressenti sur le service telecom.
Date: 2017-07-26 10:25:39 UTC
Nous isolons tous les peers BGP sur th2-1-a9
Date: 2017-07-26 10:25:11 UTC
Nous détectons un problème BFD
[12:17:21] th2-1-a9.fr.eu => EDM request for 'oper/ip_bfd_v1/node/801/__ipv4_shsession_active_summary/' from 'bfd' (jid 1168, node 0/RSP1/CPU0). No response from 'bfd_agent' (jid 125, node 0/0/CPU0) within the timeout period (100 seconds) (%SYSDB-SYSDB-6-TIMEOUT_EDM )
Date: 2017-07-26 10:02:24 UTC
Nous réalisons un switchover sur une des RSP de th2-1-a9.
Date: 2017-07-26 10:00:45 UTC
Tous les services passant par TH2 peuvent être impacté.
Nous isolons actuellement TH2 en OSPF pour rétablir le service le plus rapidement possible.
Nous investiguons.
Update(s):
Date: 2017-07-27 20:26:38 UTC
Ayant eu des interrogations à ce sujet et pour préciser, il n'y a aucun SPOF dans l’architecture.
Sur Paris, nous avons tous les peering et tous les transit sur 2 POP espacés de 20 km et je parle que de Paris. Les DC sont connectés sur 3 à 6 POP en même temps.
Sur Paris 2 couples de routeurs qui fonctionnent indépendamment. Pour preuve, on lit bien dans le task travaux qu'on a isolé complètement les routeurs de TH2 durant 4H. durant 4H on n'a pas utilisé les infra de TH2.
Avez-vous été coupés du monde durant 4H où TH2 a été en travaux avec les ingés TAC de Cisco ? NON, aucun impact de couper un routeur. Donc pas de SPOF.
Chaque router sur notre backbone pousse entre 300Gbps à 700Gbps. Si on coupe électriquement un router, le réseau a besoin d'un peu de temps pour se recalculer. Combien en cas de panne électrique d'un POP ? Il faut compter quelques secondes pour que OSPF se coupe et le réseau se recalcule mais c'est surtout les 120 sec de BGP qui prennent du temps.
Ce que nous avons eu c'est un bug et ce sont les cas les plus chiant car la panne n'est pas aussi nette qu’une panne elec. On ne sait jamais à l'avance comment le réseau se comportera car cela dépend de la nature du bug. Dans ce cas, ce n’était particulièrement pas net :(
Et pourtant pour isoler immédiatement les routeurs on utilise un protocole encore + rapide que OSPF et BGP. C'est BFD qui vérifie que les liens sont UP tous les 100ms, 10x par seconde. S'il détecte un défaut, tout bascule en moins de100ms et vous ne voyez rien. Vous n’imaginez pas le nombre d'incident de liens on gère par jour sans aucun effet sur la prod.
Pour aller encore plus vite, les liens entre nos DC et les POP on les gère nous même à travers 2 routes optiques. Chaque 100G est envoyé sur 2 chemins de 300-800km et de l'autre côté le système surveille si le signale optique arrive encore. En cas de défaut, boom, ça bascule en
50ms.
Alors pourquoi avons-nous eu l'impact sur la prod avec le souci de TH2 ? Comme indiqué plus haut, il y avait un bug software dans .. le BFD lui-même. Le routeur de TH2 a planté le process BFD. Normalement le routeur aurait dû s'isoler de lui-même.
Mais il ne l'a pas fait. TH2 voyait les paquets BFD des routeurs RBX GRA SBG mais il n'envoyait plus les paquets BFD aux autres routeurs. Du coup RBX GRA et SBG ont bien isolé TH2 mais TH2 ne l'a pas fait. On a dû intervenir manuellement sur les infra, analyser la situation et prendre les bonnes décisions immédiatement.
Dans ce cas précis c'est toujours trop long, l'homme a la fâcheuse tendance à réfléchir pour savoir quel bras il faut couper. On a coupé TH2, bgp ospf, isoler le routeur, puis tout est revenu car tout est doublé en surcapacité sur GSW où nous avons exactement le même routeur à plusieurs millions et qui a fait son job.
Sur la backbone, on va mettre à jour les routeurs, durant le mois d'Aout, comme cela était prévu de longue date. La dernière version fixe les soucis de \"check parity\" et nous allons en savoir plus sur le bug qui nous a touché, s’il est déjà fixé ou sera fixé.
Dans quelques mois, nous allons enlever le reste de petits routeurs 6K de la backbone, comme cela sera fait cette nuit à Palo Alto, a été fait à San José la semaine passée et Los Angeles il y a 2 semaines.
Une fois que nous aurons uniquement des Cisco ASR9K sur la backbone, nous allons basculer OSPF vers ISIS, puis activer MPLS ce qui va améliorer encore plus la convergence en cas de pannes.
Nous espérons que la robustesse de notre architecture qui ne comporte aucun SPOF.
Tout est au pire doublé. Tout. Partout.
Il n'y a rien qui est en \"single\".
Date: 2017-07-26 14:18:38 UTC
Les quelques perturbations IPv6 sur xDSL sont fixées.
Date: 2017-07-26 13:59:12 UTC
Suite au reboot de th2-a9, nous avons quelques perturbations IPv6 sur le xDSL .
Nous analysons
Date: 2017-07-26 12:38:50 UTC
Tout est stable, nous surveillons attentivement th2-1-a9 pendant quelques heures.
Date: 2017-07-26 12:07:25 UTC
Nous dé-isolons également l'OSPF tout en surveillant les logs de l'équipement.
Date: 2017-07-26 12:01:22 UTC
Nous rallumons les peering BGP sur th2-1-a9.
Date: 2017-07-26 11:54:52 UTC
Lors du diagnostique réalisé avec notre fournisseur, il en est ressorti que nous avons rencontré un bug sur la FIB manager (celle-ci s'est bloquée), ce qui a entrainé une erreur de parité sur le routeur et a ensuite engendré l'incident.
Le routeur a rebooté, nous surveillons actuellement le routeur (celui ci est encore isolé pour le moment).
Date: 2017-07-26 11:42:22 UTC
Nous allons procéder au reload de toutes les location de th2-1-a9
Date: 2017-07-26 11:23:21 UTC
Notre fournisseur identifie un dysfonctionnement du fib-manager sur l'équipement concerné. Il complete son analyse avant de procéder à un réinitialisation de cet élément
Date: 2017-07-26 11:15:14 UTC
Notre fournisseur procède actuellement au diagnostique de l'équipement.
Date: 2017-07-26 10:57:30 UTC
Nous sommes actuellement en contact avec notre fournisseur pour comprendre la situation du a9.
Date: 2017-07-26 10:36:04 UTC
La grande majorité du service est revenue.
De l'impact peut encore être ressenti sur le service telecom.
Date: 2017-07-26 10:25:39 UTC
Nous isolons tous les peers BGP sur th2-1-a9
Date: 2017-07-26 10:25:11 UTC
Nous détectons un problème BFD
[12:17:21] th2-1-a9.fr.eu => EDM request for 'oper/ip_bfd_v1/node/801/__ipv4_shsession_active_summary/' from 'bfd' (jid 1168, node 0/RSP1/CPU0). No response from 'bfd_agent' (jid 125, node 0/0/CPU0) within the timeout period (100 seconds) (%SYSDB-SYSDB-6-TIMEOUT_EDM )
Date: 2017-07-26 10:02:24 UTC
Nous réalisons un switchover sur une des RSP de th2-1-a9.
Date: 2017-07-26 10:00:45 UTC
Tous les services passant par TH2 peuvent être impacté.
Nous isolons actuellement TH2 en OSPF pour rétablir le service le plus rapidement possible.