OVHcloud Network Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
RBX
Incident Report for Network & Infrastructure
Resolved
Bonjour,
Ce matin, nous avons eu un incident sur le réseau optique qui interconnecte notre site de Roubaix (RBX) avec 6 des 33 points de présence (POP) de notre réseau : Paris (TH2 et GSW), Francfort (FRA), Amsterdam (AMS), London (LDN), Bruxelles (BRU).

Le site RBX est connecté à travers 6 fibres optiques à ces 6 POP : 2x RBX<>BRU, 2x RBX<>LDN, 2x RBX<>Paris (1x RBX<>TH2 et 1x RBX<>GSW). Ces 6 fibres optiques sont connectées aux systèmes de nœuds optiques qui permettent d’avoir 80 longueurs d’onde de 100Gbps sur chaque fibre optique.

Pour chaque 100G connectés aux routeurs, nous utilisons 2 chemins optiques qui sont géographiquement distincts. En cas de coupure de fibre optique, le fameux « coup de pelleteuse », le système se reconfigure en 50ms et tous les liens restent UP. Pour connecter RBX aux POP, nous avons 4.4Tbps de capacité, 44x100G : 12x 100G vers Paris, 8x100G vers London, 2x100G vers Bruxelles, 8x100G vers Amsterdam, 10x100G vers Frankfurt, 2x100G vers DC GRA et 2x100G vers DC SBG.

A 8h01, d’un coup, l’ensemble des liens 100G, les 44x 100G, ont été perdus. Étant donné le système de redondance que nous avons mis en place, l’origine du problème ne pouvait pas être la coupure physique de 6 fibres optiques simultanément. Nous n’avons pas pu faire les diagnostiques sur les châssis à distance car les interfaces de management étaient figées. Nous avons été obligés d’intervenir directement dans les salles de routage, pour faire les manipulations sur les châssis : déconnecter les câbles entre les châssis puis faire redémarrer le système et enfin seulement faire les diagnostiques avec l’équipementier. Les tentatives de redémarrage du système ont pris beaucoup de temps, car chaque châssis a besoin de 10 à 12 minutes pour démarrer. C’est la principale raison de la durée de l’incident.

Le diagnostique : Toutes les cartes transpondeurs que nous utilisons, ncs2k-400g-lk9, ncs2k-200g-cklc, sont passées en état « standby ». L’une des origines possible d’un tel état est la perte de configuration. Nous avons donc récupéré le backup et remis en place la configuration, ce qui a permis au système de reconfigurer toutes les cartes transpondeurs. Les 100G dans les routeurs sont revenus naturellement et la connexion de RBX vers les 6 POP a été rétablie à 10h34.

Il s’agit clairement d’un bug software sur les équipements optiques. La base de données avec la configuration est enregistrée 3 fois et copiée sur 2 cartes de supervision. Malgré toutes ces sécurités, la base a disparu. Nous allons travailler avec l’équipementier pour trouver l’origine du problème et les aider à fixer le bug. Nous ne remettons pas en cause la confiance avec l’équipementier, même si ce type de bug est particulièrement critique. L’uptime est une question de design qui prend en compte tous les cas de figure, y compris quand plus rien ne marche. Le mode parano chez Ovh doit être poussé encore plus loin dans l’ensemble de nos designs.

Les bugs ça peut exister, les incidents qui impactent nos clients non. Il y a forcement une erreur chez Ovh puisque malgré tous les investissements dans le réseau, dans les fibres, dans les technologies, nous venons d’avoir 2 heures de downtime sur l’ensemble de nos infrastructures à Roubaix.

L’une des solutions est de créer 2 systèmes de nœuds optiques au lieu d’un seul. 2 systèmes, cela veut dire 2 bases de données et donc en cas de perte de la configuration, un seul système est en panne. Si 50% des liens passent par l’un des systèmes, aujourd’hui, nous aurions perdu 50% de la capacité mais pas 100% de liens. C’est l’un des projets que nous avons commencé il y a 1 mois, les châssis ont été commandés et nous allons les recevoir dans les prochains jours. Nous pourrons commencer les travaux de configuration et migration sous 2 semaines. Vu l’incident d’aujourd’hui, ce projet devient prioritaire, pour l’ensemble de nos infrastructures, tous les DCs, tous les POPs.

Dans le métier de fournisseur des infrastructures Cloud, seul ceux qui sont paranos durent. La qualité de service est une conséquence de 2 éléments. Tous les incidents anticipés « by design ». Et les incidents où nous avons appris de nos erreurs. Cet incident là nous amène à mettre la barre encore plus haut pour s’approcher du risque zéro.

Nous sommes sincèrement désolés pour les 2H33 minutes de downtime sur le site RBX. Dans les prochains jours, les clients impactés vont recevoir un email pour déclencher l’application des engagements SLA.

Amicalement
Octave

Update(s):

Date: 2017-11-11 01:42:01 UTC
Optical incident on Roubaix from 09/11/2017


Incident Summary:
8h00: All 100G links to DC Roubaix are down.
8h15: Unable to connect to the node
8h40: We restart the master frame electrically.
9:00 am: The node is still unreachable.
9:15 am: We unwire the management node.
9:30 am: We regain control of Roubaix.
9h40: We can see all the frames but no alarm on the frame and the circuit configuration has disappeared.
10h00: We inject the last database backup on the node
10h15: The circuits start to go up again
10h30: Most of the circuits are up, 8 are still down
11h00: Some transponders can’t be detected by the system, and an amplifier is out of order, the RMA of the amplifier is launched.
11h30: We reset all transponders not recognized, all circuits are up
14h15: Replacement of the amplifier is completed
14h30: All circuits are up, functional protections and the last alarms have been dealth with.


Explanation:
According to the logs gathered from all the frames of the Roubaix node (20), it appears that we had 3 separate events cascading on the Roubaix node:

1. Node Controller CPU overload (master frame)
Each optical node has a master frame that allows exchanging information between nodes and swapping with its slave frames. On this master frame, the database is saved on 2 controller cards as well as the LCD.

From 7:50 a. m., we noticed that Roubaix starts to have communication problems with the nodes directly connected to it and show a CPU overload on the master frame. As of today, we are unsure what caused this CPU overload. Despite the SBG down earlier, we are looking at all the potential causes. The manufacturer's teams are still investigating this cause. We scheduled a call on Saturday, November 11th, to find out more about the root cause.


2. Cascade switchover
Following the CPU overload of the node, the master frame made a switchover of the controller boards. After the first switchover of controllers and CPU overload, we came across a known Cisco software bug. This bug happens on large nodes and results in a controllers’ switchover occurring every 30 seconds. Normally this switchover stabilizes itself. This bug will be fully fixed by the 10.8 release to be available on November 31st.


3. Loss of the database
At 8:00 am, following the cascade switchover event, we came across another software bug which de-synchronize timing between the 2 controller cards of the master frame. This bug caused a command sent to the controller ordering cards to set database to 0. The master frame controllers sent this new information to the Slaves frames and lost all 100G links from Roubaix. This bug is fixed in release 10.7 and now available.



Action Plan:

Here is the action plan that will be implemented with the manufacturer's advice:

-Two weeks ago, we launched the replacement of Roubaix and Gravelines controllers with TNCS (instead of TNCE) bringing double the CPU power and double the RAM. We received the first 2 yesterday for Roubaix and we will do the swap as soon as possible, after validating the process with the manufacturer's. We're going to push the replacement of the Controllers on the Strasbourg and Frankfurt nodes as well.

-We are now pushing the software upgrade on all nodes to go to 10.8

-Today we are using version 10.5.2.6, we have to go through an intermediate version 10.5.2.7 to be able to go in 10.7 or 10.8 afterwards.

-We will split the large nodes (POP/DC) to have at least 2 nodes controllers per POP/DC



Summary:
Step 1: Replacement of TNCE on RBX/GRA (ETA: Monday 13th November evening for RBX, Tuesday 14th November evening for GRA)
Step 2: Upgrade Software in 10.8 (ETA possible: 4 weeks)
Step 3: Split of the large nodes (ETA: TBA. It is necessary to decide the right strategy and establish the precise protocol and then work on the roadmap)


Potential Split Strategy:

It is possible to completely split the network into 2 fully independent networks at the management level (with always the possibility of re-splitting the nodes inside each network). With a \"smart\" red and blue distribution of the optical lines between 2 networks, each DC can reach each POP over 2 distinct networks.

Date: 2017-11-10 19:56:16 UTC
Incident optique sur Roubaix du 09/11/2017

Résumé de l'incident :
• 8h00 : Toutes les liens 100G au DC de Roubaix sont down.
• 8h15 : Impossible de se connecter au nœud
• 8h40 : Nous redémarrons électriquement le châssis maitre.
• 9h00 : Toujours impossible de récupérer la main sur le nœud
• 9h15 : Nous décâblons tout le management du nœud
• 9h30 : Nous réussissons à récupérer la main sur Roubaix
• 9h40 : On voit tous les châssis mais aucune alarme sur le châssis et la configuration des circuits a disparu
• 10h00 : On injecte le dernier backup de la database sur le nœud
• 10h15 : Les circuits commencent à remonter
• 10h30 : La plupart des circuits sont up, il en reste 8 down
• 11h00 : Certains transpondeurs ne sont pas vu par le système, et un ampli est HS, on lance le RMA de l'ampli
• 11h30 : On reset tous les transpondeurs non reconnu, tous les circuits sont up
• 14h15 : On effectue le remplacement de l'ampli
• 14h30 : Tous les circuits sont up, les protections fonctionnelles et les dernières alarmes fixées.



Explication :
D’après les logs récoltés sur tous les châssis du nœud de Roubaix (20), il apparait que nous avons eu 3 phénomènes en cascade sur le noeud de Roubaix :

1. Surcharge du CPU du Node Controller (châssis maitre)
Chaque nœud optique a un châssis maitre qui permet d'échanger les informations entre les nœuds et permet d'échanger avec ses châssis slaves. Sur ce châssis maitre est sauvegardé la database sur 2 cartes controllers et le LCD.
A partir de 7h50, on remarque que Roubaix commence à avoir des problèmes de communication avec les nœuds directement connectés à lui et montrer une surcharge CPU du châssis maitre. Aujourd'hui, nous n'avons pas encore la cause de cette surcharge du CPU. Malgré le down de SBG plus tôt, nous examinons toutes les pistes. Les équipes du constructeur investiguent encore sur cette cause. Nous avons un call samedi 11 novembre pour en savoir plus.

2. Switchover en cascade
Suite à la surcharge du CPU du node, le châssis maitre a effectué un switchover des cartes controller. Après le premier switchover des controllers et la surcharge du CPU, nous sommes tombé sur un bug soft connu de Cisco. Ce bug arrive sur les gros nœuds et a pour conséquence de faire un switchover des controllers toutes les 30 secondes. En temps normal ce switch over se stabilise seul. Ce bug est fixé en release 10.8 qui sera disponible à partir du 31/11

3. Perte de la database
A 8h00, suite aux switchover en cascade, nous sommes tombé sur un autre bug soft qui est une désynchro du timing entre les 2 cartes controllers du chassis maitre. Ce bug a provoquer l'envoi d'une commande disant aux cartes controller de mettre la database à 0. Les cartes controllers du châssis maitre ont donc envoyées cette nouvelle information aux châssis slaves ce qui a fait perdre tous les liens 100G de Roubaix. Ce bug est fixé en release 10.7 qui est actuellement disponible.



Plan d'action :
Voici le plan d'action que l'on va mettre en place avec les conseils du constructeur:

• Il y a 2 semaines, nous avons lancé le remplacer les cartes controllers de Roubaix et Gravelines par des TNCS (au lieu de TNCE) qui ont le double de puissance CPU et le double de RAM. Nous avons reçu les 2 premières hier pour Roubaix et nous allons faire le swap rapidement, après avoir eu la procédure du constructeur.(Semaine du 13 Novembre). Nous allons pousser le remplacement des Controllers sur les noeuds de Strasbourg et Frankfort aussi.
• Nous faisons l'upgrade software de tous les nœuds pour aller en 10.8
• Aujourd'hui nous somme en version 10.5.2.6, nous devons passer par une version intermédiaire 10.5.2.7 pour pouvoir aller en 10.7 ou 10.8 ensuite
• Nous effectuons un split des gros nœuds (POP/DC) pour avoir au moins 2 nodes controllers par POP/DC

En résumé :
• Step 1 : Remplacement des TNCE sur RBX/GRA (ETA possible: lundi 13/11 soir pour RBX, mardi 14/11 soir pour GRA)
• Step 2 : Upgrade Software en 10.8 (ETA possible: 4 semaines)
• Step 3 : Split des gros noeuds (ETA: à étudier. Il faut décider la stratégie, établir le protocole précis puis faire la roadmap)



Stratégie possible pour le split :
Il est possible de splitter complètement le réseau en 2 réseaux indépendants et étanches au niveau du management (avec toujours la possible de re-splitter les nodes à l'intérieur même de chaque réseau). Avec une répartition \"smart\" des lignes optiques entre 2 réseaux \"red\" et \"blue\", chaque DC peut joindre chaque POP en direct par chacun des 2 réseaux distincts.

Date: 2017-11-09 21:08:19 UTC
Dear customer,
This morning, we experienced an incident on the optical network which connects our Roubaix (RBX) site with 6 of the 33 points of presence (POPs) on our network. Paris (TH2 and GSW), Frankfurt (FRA), Amsterdam (AMS), London (LDN), Brussles (BRU).
The Roubaix site is connected via 6 fibre optic cables to these 6 POPs: 2x RBX<>BRU, 2x RBX<>LDN, 2x RBX<>Paris (1x RBX<>TH2 et 1x RBX<>GSW). These 6 fibre optic cables are connected to a system of optical nodes which means each fibre optic cable can carry 80 x 100 Gbps.
For each 100 G connected to the routers, we use two optical paths which are in distinct geographic locations. If any fibre optic link is cut, the system reconfigures in 50ms and all the links stay UP.
To connect RBX to our POPs, we have 4.4Tbps capacity, 44x100G: 12x 100G to Paris, 8x100G to London, 2x100G to Brussels, 8x100G to Amsterdam, 10x100G to Frankfurt, 2x100G to the GRA DC and 2x100G to SBG DC.

At 8:01, all the 100G links, 44x 100G, were lost in one go. Given that we have a redundancy system in place, the root of the problem could not be the physical shutdown of 6 optical fibres simultaneously. We could not do a remote diagnostic of the chassis because the management interfaces were not working. We had to intervene directly in the routing rooms themselves, to sort out the chassis: disconnect the cables between the chassis and restart the system and finally do the diagnostics with the equipment manufacturer. Attempts to reboot the system took a long time because each chassis needs 10 to 12 minutes to boot. This is the main reason that it the incident lasted such a long time.

Diagnostic: all the interface cards that we use, ncs2k-400g-lk9, ncs2k-200g-cklc, went into \"standby\" mode. This could have been due to a loss of configuration. We therefore recovered the backup and reset the configuration, which allowed the system to reconfigure all the interface cards. The 100Gs in the routers came back naturally and the RBX connection to the 6 POPs was restored at 10:34.

There is clearly a software bug on the optical equipment. The database with the configuration is saved 3 times and copied to 2 monitoring cards. Despite all these security measures, the database disappeared. We will work with the OEM to find the source of the problem and help fix the bug. We do not doubt the equipment manufacturer, even if this type of bug is particularly critical. Uptime is a matter of design that must consider every eventuality, including when nothing else works. OVH must make sure to be even more paranoid than it already is in every system that it designs.

Bugs can exist, but incidents impacting our customers are not acceptable. This is an OVH issue, because despite all investments in the network, in the fibre, in the technologies, we still experienced 2 hours of downtime on all our infrastructure in Roubaix.

One solution could be to create 2 optical node systems instead of one. 2 systems mean 2 databases and so if we lose configuration, only one system is down. If 50% of the links went through one of the systems, today we would have lost 50% of the capacity but not 100% of links. This is one of the projects we started 1 month ago, the chassis have been ordered and they will arrive in the coming days. We can start the configuration and migration work in 2 weeks. Given today's incident, this project has become a priority for all of our infrastructures, all DCs, all POPs.

In the cloud infrastructure business, only those who are vigilant to the point of paranoia will last. The quality of service is down to two elements. All incidents which can be anticipated \"by design\". And the incidents where we learn from our mistakes. This incident has forced us to raise the bard even higher to get closer to “zero risk”.

We are sincerely sorry for the 2 hours and 33 minutes of downtime on the RBX site. In the coming days, all customers affected by this incident will receive an email explaining how to activate their SLA.

Sincerely
Octave
Posted Nov 09, 2017 - 06:50 UTC
This incident affected: Infrastructure || RBX (RBX1).