Rapport d'incident sur France-IX

 Mise à jour - le 1er Septembre

 

Voici une mise à jour et les conclusions concernant le problème rencontré le 18 Août. Vous trouverez à la fin de cet article la chronologie détaillée de la panne ainsi que les investigations qui ont suivi.

 

1 – La panne, les investigations et la résolution:

 

Deux problèmes ont été identifiés entrainant la panne du 18 Août:
   - Des tempêtes de trafic unicast sur plusieurs ports, jusqu'à 300Mbps observées
   - Amplification de ces tempêtes par une boucle atteignant 2Gbps sur certains ports.

Après avoir résolu le problème de boucle, nous avons concentré nos efforts pour trouver l'origine de ces tempêtes unicast.
Ce "flooding" unicast est apparu à nouveau sur certains ports et la cause principale a été trouvée: Nous avons corrélé l'apparition de "flooding" unicast avec des bagots d'interface.

Pour éviter que ce problème  réapparaisse, des modifications ont été apportées sur les configurations des équipements, après des échanges avec les experts Juniper. Nous avons renforcé également le filtrage niveau 2, particulièrement avec les IXP partenaires.

La situation est maintenant stable et comme nous l'avons dit précédemment, vous pouvez réactiver vos sessions BGP (nous voyons encore quelques sessions BGP down).

Pendant les investigations, nous avons désactivé l'export des statistiques de flux. Nous allons planifier prochainement une maintenance pour réactiver l'export de flux.

 
2 – Compréhension du problème:

Bien que ce problème soit maintenant résolu, nous voulons comprendre dans le détail le comportement de la plateforme Juniper pendant l'incident. C'est pourquoi nous travaillons toujours en étroite collaboration avec Juniper. Deux ingénieurs du TAC travaillent sur ??le case, un dans nos locaux et un autre basé à Amsterdam. L’équipe d'ingénierie Juniper aux États-Unis est également impliquée. Nous mettrons à jour cet article s'il y a des informations pertinentes à vous communiquer.

 

3 - Plan d'action:

   - Les  Serveurs de routes  connectés au cœur VPLS: Afin d’éviter le moindre impact sur ??les serveurs de routes en cas de panne, nous prévoyons  de connecter ces serveurs directement à l'infrastructure VPLS. Actuellement, ils sont connectés à notre infrastructure de VMs.

   - Suppression du trafic anormal: Au cours de la résolution des problèmes, nous avons observé du trafic anormal envoyé par certains membres (proxy ARP, IPv6 Router advertisement, STP, CDP / FDP, OSPF / ISIS, etc). Nous prendrons contact avec eux afin de supprimer ce trafic anormal et avoir des configurations homogènes.

 

 

Premier rapport - le 23 Aout

 

Le lundi 18 vers 12h00, du trafic de type "broadcast" (le trafic était répliqué sur plusieurs ports) a été observé. Ce trafic a été amplifié par une boucle atteignant jusqu'à 2Gbps. Après avoir stoppé la boucle, le trafic a diminué de manière significative. Nous avons dû modifier le mode de filtrage de ce trafic non désiré, dans la mesure où les filtres préalablement configurés ne fonctionnaient pas comme ils le devraient.

Nous avons contacté le support Juniper a ce sujet, et nous avons ouvert plusieurs tickets pour comprendre pourquoi ce trafic n'a pas été bloqué correctement par le filtre appliqué globalement dans l'instance VPLS et sur les ports membres.

Ce trafic est réapparu à quelques reprises et une solution a été trouvée pour le stopper immédiatement. Un "clear" des entrées MAC dans la table VPLS permet de stopper ce trafic (cette opération n'a pas d'impact sur le trafic de membres). Après d'autres investigations avec le support Juniper, et la collecte des captures de trafic, nous avons détecté que le trafic indésirable était du trafic unicast (et non pas broadcast). Ce trafic est considéré comme "unknown unicast", bien que les adresses MAC soient connues au sein de la table VPLS.

Nous travaillons en étroite collaboration avec l'équipe d'ingénierie de Juniper pour comprendre si le problème est connu. Nous menons des conférences téléphoniques avec eux plusieurs fois par jour. En attendant, pour éviter que le problème se reproduise, nous avons appliqué la solution suivante: un script a été installé sur nos équipements Juniper pour stopper automatiquement le trafic indésirable dès que le phénomène se produit.

Nous nous excusons encore pour ces désagréments et nous tenons à remercier les membres France-IX qui nous ont envoyé des données pour nous aider à mieux identifier l’incident.

Nous travaillons toujours avec Juniper. Nous vous enverrons un rapport complet plus tard.

 

Lundi 18 Août vers 12:00: Tempête de trafic unicast sur plusieurs ports atteignant 300Mbit/s par membre.

Lundi 18 Août à 15h02: Une boucle est apparue sur le réseau, les 300Mbit/s ont été amplifiés, atteignant 2 Gbps sur certaines interfaces. Le LAN de France-IX a été également impacté, dégradant la connectivité des serveurs de route.

Lundi 18 Août vers 17h00: Nous avons stoppé la boucle, mais 300Mbit/s de trafic étaient toujours visibles sur certains ports. En modifiant certains filtres, nous avons réussi à stopper le flooding, vers 18h00.

Lundi 18 Août vers 19h00: 3 cases Juniper ont été ouverts pour comprendre le comportement des filtres et celui de la plate-forme pendant la panne. Plusieurs conférences par jour ont permis d'échanger les informations utiles avec les experts Juniper et progresser dans l'investigation.

Du mardi 19 au lundi 25: Nous avons observé à nouveau du trafic unicast répliqué sur certains ports (entre 10 Mbps et 100 Mbps ) sur les PoP Telehouse2 et Interxion2.

Jeudi 21 Août: Nous avons installé deux sondes afin de capturer et d'analyser ce trafic anormal.

Conclusions: Après avoir écarté diverses pistes, nous avons finalement corrélé le "flapping" de certaines interfaces avec les tempêtes de trafic unicast. Après avoir déplacé ces ports sur des nouvelles interfaces, le phénomène ne s'est plus reproduit. Suivant les conseils de Juniper nous avons appliqué des modifications sur les configurations pour éviter à nouveau ce genre de situation.
Nous continuons à travailler avec Juniper pour mieux comprendre le comportement de la plateforme.

PS: Nous n'avons détaillé ci-dessus que les étapes permettant de résoudre le problème. Nous avons exploré plusieurs pistes et réalisé quelques modifications sur la plateforme (suppression d'IPFIX, modification des règles de filtrage, modification des configurations pour certains VLAN). Ces éléments ne sont pas détaillés ici, car ils ne sont pas pertinents.