Mardi dernier, le 12 août 2014, plusieurs de nos clients nous ont signalé à partir de 10h env. que les services que nous hébergeons n’étaient plus disponibles. Pourtant, le contrôle de nos serveurs et services ne signalait aucune panne et notre service de surveillance externe ne nous a transmis aucun signal d’alarme. D’autre part, nous avons appris via les commentaires de nos clients sur les réseaux sociaux que ce problème d’indisponibilité ne concernait que certains fournisseurs d’accès.

Ce constat nous a ainsi fait soupçonner un problème de routage externe. Nous avons immédiatement clarifié la situation et nous avons contacté notre partenaire de transit IP. En général, il est difficile d’identifier la cause de ce type de problèmes en raison de l’implication de plusieurs réseaux et donc de plusieurs parties. Après divers examens supplémentaires, il s’est avéré que la cause du problème ne venait pas de ce côté.

C’est pourquoi nous nous sommes ensuite concentrés sur les routeurs qui relient notre infrastructure au monde extérieur. Ceux-ci dressent des tables de routage qui permettent de déterminer quel réseau de connexion permet de joindre un destinataire spécifique le plus rapidement possible. Dès l’apparition des problèmes, nous avions si certaines entrées des tables de routage n’étaient pas défectueuses, voire manquantes, ce qui n’était pas le cas. Après un examen approfondi, nous n’avons constaté aucune anomalie qui aurait pu expliquer un problème de comportement des routeurs.

Après que certains Internautes aient signalé des problèmes chez d’autres grands fournisseurs dans le monde entier, qui étaient apparemment déclenchés par une augmentation soudaine et excessive des entrées dans la table de routage Internet, nous nous sommes également penchés sur ce phénomène. Pourtant, nos sessions BGP ne pouvaient pas être touchées par cette augmentation, car nos routeurs disposent d’une mémoire RAM largement suffisante. Cependant, étant donné que les routeurs ont défini une limite arbitraire de 512 000 entrées pour le routage matériel, indépendamment des BGP, nous avons décidé d’approfondir nos recherches, même si cette limite n’était plus dépassée. Pourtant, après des tests aléatoires réalisés sur des adresses IP touchées, il s’est avéré que c’était bel et bien le cas pour les tables hardware (TCAM). Face à ce constat et étant donné que nous ne redémarrons qu’exceptionnellement ce genre de composants critiques pendant la journée, nous nous sommes d’abord abstenus de redémarrer les routeurs.

Après d’autres clarifications, il s’est avéré que le dépassement des tables hardware était la cause du problème, et ce malgré les tests aléatoires concluants. Nous avons donc procédé au redémarrage et tout est rentré dans l’ordre. Nous supposons que le dépassement de la limite a entraîné la perte de routes critiques que nous n’avions pas immédiatement détectés lors des tests aléatoires. Et ces routes n’ont pas non plus été remplacés après le redémarrage des sessions BGP, une fois le nombre d’entrées redescendu en-dessous de la limite.

Mesures prises
Ces événements nous ont amenés à prendre diverses mesures techniques:

  • La limite pour le routage matériel a été augmentée et fixée à 800 000 entrées. Cela réduit de façon significative la probabilité que ce problème se reproduise.
  • Le contrôle des routeurs sera encore renforcé afin de pouvoir détecter plus rapidement ces anomalies à l’avenir.
  • Nous essayons en outre de comprendre pourquoi ce dysfonctionnement n’a pu être éliminé que par un redémarrage alors que le nombre d’entrée était repassé sous la limite.

Nous tenons à présenter toutes nos excuses pour les désagréments occasionnés. Nous prenons cet événement très au sérieux et nous ferons tout notre possible pour garantir la qualité de nos prestations à l’avenir, une qualité à laquelle nos clients sont habitués et qu’ils sont en droit d’exiger.

Explications sur les perturbations du réseau le 12 août 2014

Markus Gebert

Markus Gebert est co-propriétaire de Hostpoint et responsable de l'ingénierie et du développement.

0