Perturbation du réseau

Incident Report for NetSyst

Postmortem

Le vendredi 12/06, à partir d’environ 10h10, notre infrastructure réseau a connu une instabilité ayant entraîné des perturbations de connectivité. Cet incident est intervenu après une maintenance opérateur réalisée la veille, le jeudi 11/06, sur le lien entre nos sites de Nexeren et UltraEdge Vénissieux. À l’issue de cette maintenance, le trafic a été remis en service sur ce lien le vendredi matin vers 10h00.

Peu après, vers 10h10, nous avons procédé à une opération réseau habituelle consistant à ajouter un nouveau VXLAN/VNI sur notre infrastructure. Cette opération, normalement maîtrisée, a provoqué une reconvergence de la stack EVPN. Durant cette reconvergence, plusieurs sessions BGP EVPN ont commencé à présenter des erreurs de type holdtimer expired, indiquant que certains équipements ne recevaient plus les messages attendus dans les délais normaux.

Dans la même fenêtre d’intervention, une erreur humaine de configuration a également été commise lors de la saisie d’une commande. Cette erreur a temporairement coupé l’ensemble de la partie backbone Internet. Elle a été immédiatement identifiée et corrigée, et nous avons également annulé l’ajout du VLAN/VNI réalisé précédemment. Cependant, malgré ce retour arrière, l’instabilité n’a pas été résolue, ce qui indiquait qu’un autre facteur était en cause.

Les premiers symptômes observés pouvaient laisser penser qu’un switch était dans un état instable. Dans le cadre du rétablissement du service, nous avons donc procédé au redémarrage de cet équipement. Après cette action, la situation a semblé se stabiliser temporairement. Toutefois, lorsque le lien opérateur Nexeren–UltraEdge Vénissieux est redevenu actif et a de nouveau été utilisé par l’infrastructure, les coupures sont réapparues. C’est ce qui explique que l’incident ait été perçu en deux phases : une première coupure liée à la phase initiale de reconvergence et de diagnostic, puis une seconde lorsque le trafic est repassé par le lien concerné.

Les investigations menées ensuite ont permis d’identifier la cause principale de l’incident : la MTU du lien opérateur Nexeren–UltraEdge Vénissieux avait été modifiée à la suite de la maintenance. Ce lien était historiquement configuré et exploité avec une MTU de 9216, mais après l’intervention opérateur, la MTU effective était passée à 9166. L’opérateur nous a confirmé avoir changé le modèle de carte utilisé sur cette wave, ce qui a entraîné cette modification de MTU sans notification préalable.

Ce point a rendu le diagnostic particulièrement difficile. Le lien apparaissait bien comme opérationnel, et le routage considérait toujours ce chemin comme utilisable. Autrement dit, les équipements voyaient le lien comme actif et continuaient à y faire passer du trafic. En revanche, la MTU réelle du lien ne permettait plus de transporter correctement certains paquets attendus par notre infrastructure. Une partie du trafic pouvait donc être perdue silencieusement, sans que cela se traduise par une coupure franche du lien.

La reconvergence EVPN déclenchée lors de l’ajout du VXLAN/VNI a rendu ce problème visible, car elle a généré des échanges réseau sensibles à cette différence de MTU. Les sessions BGP EVPN ont alors subi des pertes suffisantes pour expirer en holdtimer expired. Le fait que le lien reste actif et que le routage continue de l’utiliser a fortement complexifié l’analyse, car les indicateurs habituels ne montraient pas une panne évidente du lien.

L’erreur humaine de configuration survenue pendant l’intervention a aggravé l’impact en provoquant une coupure temporaire du backbone Internet, mais elle n’était pas la cause de la persistance de l’incident après rollback. La cause principale était bien la modification non annoncée de la MTU sur le lien opérateur Nexeren–UltraEdge Vénissieux.

Dans le cadre des investigations et afin d’éviter tout nouveau battement réseau ou la réapparition d’un problème caché, l’un des routeurs de Nexeren a été volontairement maintenu hors service. Cet équipement restera arrêté jusqu’à la fenêtre de maintenance prévue ce soir, afin de permettre sa remise en service dans un cadre contrôlé et avec un impact minimal pour les clients.

Afin d’éviter qu’un incident similaire ne se reproduise, nous renforçons nos procédures de validation après maintenance opérateur, notamment avec des contrôles explicites de MTU sur les liens critiques avant leur remise en production complète. Nous allons également demander à nos opérateurs que tout changement matériel ou toute modification des caractéristiques techniques d’un lien, en particulier la MTU, soit communiqué en amont. Enfin, nos procédures de configuration réseau seront renforcées afin de réduire le risque d’erreur humaine lors des opérations sur des trunks ou des VLANs.

En conclusion, l’incident a été causé par une modification non annoncée de la MTU sur un lien opérateur critique entre Nexeren et UltraEdge Vénissieux. Le lien apparaissait opérationnel, mais ne transportait plus la taille de paquets attendue par notre infrastructure. La reconvergence EVPN a révélé ce problème, l’erreur de configuration a temporairement amplifié l’impact, et le redémarrage d’un switch lors de la première phase explique pourquoi l’incident a été observé en deux coupures distinctes. Par mesure de prudence, un routeur Nexeren reste actuellement hors service jusqu’à la fenêtre de maintenance de ce soir, où il sera remis en production de manière contrôlée.

Posted Jun 12, 2026 - 13:52 CEST

Resolved

Nous avons identifié qu’un routeur présente des timeouts depuis ce matin. Cet équipement vient d’être isolé afin de limiter son impact sur le service et de poursuivre les investigations dans de meilleures conditions.

L’incident est intervenu dans une période où des configurations globales étaient également en cours. À ce stade, nous ne pouvons pas confirmer qu’il existe un lien direct entre ces opérations et les timeouts observés sur le routeur. Il peut s’agir d’une coïncidence, mais ce point fait partie des éléments actuellement analysés par nos équipes.
Posted Jun 12, 2026 - 11:05 CEST

Monitoring

Nous avons identifié qu’une erreur humaine de configuration est à l’origine de l’incident actuellement rencontré.

Cette mauvaise configuration a entraîné une perturbation du service pour une partie de nos utilisateurs. Nos équipes sont intervenues afin d’identifier précisément la cause, corriger le paramétrage concerné et s’assurer que la situation est désormais stabilisée.

Nous tenons à présenter nos excuses pour la gêne occasionnée. Nous savons l’importance de la disponibilité de nos services et regrettons sincèrement cet incident.

Une analyse interne sera menée afin de renforcer nos procédures de validation et de réduire le risque qu’une situation similaire se reproduise.

Merci pour votre compréhension.
Posted Jun 12, 2026 - 10:42 CEST

Identified

Nous rencontrons actuellement une interruption de nos services réseau. Nos équipes techniques sont pleinement mobilisées et, suite aux investigations, nous appliquons actuellement un correctif pour rétablir la situation au plus vite.

Le retour à la normale se fera de manière progressive pour l'ensemble de nos services. Nous suivons de près l'évolution de la situation afin de garantir la stabilité de nos infrastructures.
Posted Jun 12, 2026 - 10:34 CEST
This incident affected: Network (AS209097, Collectes Opérateurs).