Datacenter : Online.net a rencontré un problème particulier avec un routeur Cisco

Dans la journée de mardi, la branche Datacenter du groupe Iliad (qui abrite l’infrastructure de l’offre Online.net de serveurs dédiés ou mutualisés et d’hébergement) a connu une alerte singulière associée à un problème de routeur à partir de son datacenter Paris DC2 situé à Vitry sur Seine (Val-de-Marne).

Les alertes se sont multipliées mardi soir via Twitter pour signaler un problème et les exploitants d’Iliad Datacenter ont utilisé le même canal pour fournir des précisions sur l’évolution de la situation.

Dans le compte-rendu de la panne diffusée mardi vers 20H00 sur le forum Online.net, il est indiqué qu’en salle 103, « nous avons eu des difficultés techniques avec le routage (Cisco 4507 en SUP6E) qui assurent le routage local de la salle pour 120 baies ».

Les détails de l’incident rapportés par Arnaud de Berningham, CEO d’Online.net, sont retranscrits intégralement ici (on a essayé de fournir des précisions sur les points les plus techniques) : « Une première fois vers 15h05 pendant 10 minutes environs, puis une deuxième fois vers 17h01 pendant 45min à 2h en fonction de la baie et du service. Les autres baies (Salle 203, 301 à DC2, Dedirack et l’ensemble des serveurs à DC3 [un autre data center du groupe, ndlr] n’ont pas été concernées ni perturbées. »

Les étapes pour identifier le problème

1- Lors du premier incident, nous avons identifié une corruption suivie d’une désactivation de la CEF [mode de commutation, ndlr] du routeur, provoquant le passage en routage logiciel et une dégradation significative des performances. Après vérification, nous avons constaté qu’aucune limite hard n’était dépassé et avons rebooté le routeur en n’écartant pas un problème software. Les IPFO [IPFailover, une adresse IP basculable d’un serveur à un autre, ndlr] ont été réactivées rapidement et avons gardé le routeur sous surveillance

2- Lors du deuxième incident, nous avons subi exactement le même problème.
Ne sachant pas expliquer l’origine de la désactivation de la CEF notamment par un dépassement d’une limitation matérielle, nous avons procédé au débug méthodique, dans l’ordre : bascule sur carte SUP6E (carte insérée dans le routeur) de secours (même problème), retiré toutes l’IPV6 et les IPFO configurées (même problème), désactivation de l’IGP [Interior Gataway Protocol, protocole de routage] et les uplinks [liens vers les opérateurs ou vers d’autres réseaux plus importants internes ou externes] même problème, remplacé le matériel (même problème).
Après 45 minutes à écarter les différents scénarios, en collaboration avec Cisco, nous avons réactivé les baies 1 par 1 jusqu’à écarter une baie problématique. Vers 18h15, nous avons identifié la baie « problématique », puis la machine « problématique ». Entre-temps, nous avons réactivé l’ensemble des fonctionnalités, dans l’ordre : les IP principales, les adresses IPv6, les IP failover, puis la dernière baie E-14.

3- Après analyse et capture des paquets du serveur, nous avons clairement identifié un problème de type « Paquet de la mort » [paquet TCP spécifique provoquant la corruption de la CEF des routeurs intermédiaires, entraînant un plantage réseau], immédiatement transmis à Cisco, qui prend très au sérieux notre remontée. Un case est ouvert au plus haut niveau possible d’importance. En parallèle, nous reproduisons en environnement lab le problème.

« A ce stade, compte tenu de la nature et de la sensibilité du bug, sachez que l’ensemble de vos interlocuteurs Online et notre partenaire Cisco sont mobilisés. Entre temps, la situation est stabilisée, le problème n’a aucune raison de se reproduire », est-il précisé dans le message.

Paquets fautifs isolés et identifiés

« L’architecture de notre réseau n’est clairement pas en cause dans cet incident. Nous espérons obtenir des réponses rapidement et vous tiendrons informés, précise Arnaud de Bermingham dans son message de reporting. »

Dans un update diffusé sur le forum hier après-midi (19 mars), Arnaud de Berningham précise : « Nous avons isolé et identifié précisément les paquets fautifs. Nous avons reproduit avec succès en environnement lab et production le « bug ».

Contacté ultérieurement par ITespresso, le responsable Hébergement d’Iliad-Free précise que « l’incident réseau n’a concerné qu’une seule salle, représentant moins de 15% du parc de serveurs en service ».

Quiz : Connaissez-vous bien les VPN ?

Credit photo : Shutterstock.com