Les incidents LON2 de LINX en 2023 ont fait de l’état réel du réseau un test de responsabilité

Résumé

Selon LINX, la défaillance d’une fibre noire à LON2 le 20 juin 2023 a réduit la résilience sans provoquer immédiatement d’impact pour les membres. Le 21 juin, des pertes détectées par Flowmon, des oscillations de liens intercommutateurs, des pertes de trafic et des problèmes de joignabilité sont ensuite apparus sur le LAN de peering. [1]
LINX a indiqué qu’un routeur nouvellement installé avait auparavant servi en laboratoire. Son ancienne configuration OSPF et son ancien identifiant de routeur avaient été supprimés, puis un nouvel identifiant déployé par NETCONF. Le processus OSPF actif avait néanmoins conservé l’ancienne identité, faute d’avoir été réinitialisé. [1]
L’opérateur a également observé des adresses MAC présentes dans la table logicielle d’un équipement de bordure mais absentes de sa table matérielle. Pour certains problèmes résiduels de joignabilité, la réinitialisation de la session BGP L2VPN EVPN entre les VTEP concernés a permis de repeupler la table matérielle. [1]
Les épisodes des 29 juin et 5 novembre, ainsi que la maintenance de fibre, la modification logicielle ensuite annulée et l’enquête fournisseur encore ouverte, ne doivent pas être artificiellement réunis sous une cause racine unique. [1]
Le sujet n’est pas de déclarer EVPN, VXLAN, OSPF, l’automatisation ou le matériel désagrégé dangereux. Il est de déterminer quelles preuves doivent interdire ou autoriser l’entrée en production d’un équipement : identité active unique, état de processus nettoyé, cohérence entre plan de contrôle et plan de données, test réaliste du chemin dégradé et vérification depuis la bordure membre.
Le rapport annuel 2023 de LINX attribue à LON2 une disponibilité de 99,997 %, légèrement inférieure à l’objectif interne de 99,998 %. Ce chiffre confirme l’importance opérationnelle des interruptions, mais ne permet pas de déduire un nombre précis de membres, de préfixes, de paquets ou de pertes financières affectés. [2]
La responsabilité est distribuée sans être indéterminée. LINX contrôlait notamment l’admission du routeur, l’automatisation, la surveillance, l’isolement des liens, les manipulations de sessions et la communication sur le service. Les fournisseurs intervenaient sur des composantes physiques ou logicielles. Chaque membre demeurait responsable de ses propres sessions et choix de continuité.
La frontière de responsabilité est donc l’état en cours d’exécution. Une configuration voulue, une transaction d’automatisation réussie ou un pourcentage annuel constituent des enregistrements utiles. Ils ne remplacent pas la preuve que les identités actives sont uniques, que les VTEP se joignent, que les entrées EVPN atteignent le matériel et que les paquets franchissent réellement la fabric.

Une perte de fibre sans impact immédiat, mais pas sans conséquence

Le premier événement de la séquence publiée par LINX est facile à sous-estimer. Le 20 juin 2023, une connexion en fibre noire de LON2 est tombée. LINX a précisé que cette première défaillance n’avait pas eu d’impact immédiat sur ses membres, mais qu’elle avait réduit la résilience du réseau. [1] Cette distinction est essentielle. Un service peut continuer à transporter du trafic alors que sa marge de sécurité vient de se contracter.

Dans un réseau redondant, la continuité apparente après la perte d’un chemin ne signifie pas que la situation opérationnelle est inchangée. Le trafic peut avoir basculé vers un nombre inférieur de chemins, traverser des équipements différents ou dépendre davantage d’une agrégation, d’un lien intercommutateur ou d’un domaine de convergence particulier. La topologie nominale représentée dans les documents d’architecture n’est plus celle qui porte effectivement la charge.

Le 21 juin, LINX a signalé des pertes observées par Flowmon et des oscillations de liens intercommutateurs. Des pertes de trafic et des problèmes de joignabilité ont alors touché le LAN de peering LON2. Les équipes ont désactivé certains liens afin de restaurer partiellement le service, puis désactivé une agrégation entre des équipements de cœur pour parvenir à un rétablissement plus complet. Le 22 juin, des problèmes plus ciblés de joignabilité IP subsistaient encore. [1]

Cette succession oblige à distinguer plusieurs états : service nominal, service dégradé mais encore disponible, perturbation large, restauration partielle, puis résolution de cas résiduels. Les fusionner sous une seule heure de « retour à la normale » détruirait une information importante. Un réseau peut sembler rétabli pour la majorité du trafic tout en restant défaillant pour certaines destinations ou certains chemins.

La première défaillance de fibre appartient donc pleinement à l’analyse de responsabilité, même sans impact membre immédiat. Elle a modifié l’environnement dans lequel les anomalies suivantes se sont manifestées et dans lequel les opérations de restauration ont été conduites. Elle ne prouve pas à elle seule la cause des pertes ultérieures. Elle établit en revanche que le système fonctionnait déjà avec une résilience réduite.

Une gouvernance sérieuse doit rendre cet état visible. Lorsqu’un chemin critique est indisponible, les règles d’admission en production, de maintenance et de changement devraient se durcir. Une activation non indispensable peut être différée. Un canari plus représentatif peut devenir obligatoire. Les seuils de retour arrière peuvent être abaissés. Le dossier public ne dit pas quelles décisions précises LINX a prises sur chacun de ces points. Ils constituent des exigences dérivées de l’incident, et non des accusations sur un processus interne non publié.

Le passage du laboratoire à la production est une transition d’état

La révélation la plus instructive de LINX concerne un routeur récemment installé à LON2. L’équipement avait auparavant été utilisé dans un laboratoire et partageait initialement son identifiant de routeur avec un autre équipement déjà en production. LINX a expliqué que l’ancienne configuration OSPF et l’ancien router ID avaient été supprimés, puis qu’un nouvel identifiant avait été déployé par NETCONF. Malgré cela, le processus OSPF actif continuait d’utiliser l’ancienne identité parce qu’il n’avait pas été réinitialisé. [1]

Ce cas montre la différence entre trois réalités que les procédures de changement confondent parfois. La première est l’intention : l’identifiant que l’inventaire ou le dépôt de configuration attribue à l’équipement. La deuxième est l’opération de déploiement : la commande ou la transaction confirmant que la nouvelle valeur a été acceptée. La troisième est l’état exécuté : l’identité que le processus de routage utilise effectivement et que ses voisins observent.

Les deux premières réalités peuvent être correctes alors que la troisième ne l’est pas. Un fichier peut contenir la bonne valeur. NETCONF peut avoir livré la modification prévue. Le système de gestion peut déclarer la transaction réussie. Si le processus en mémoire continue cependant d’utiliser une valeur antérieure, le réseau fonctionne sur une identité différente de celle attestée par les outils de gestion.

OSPF s’appuie sur un identifiant de routeur destiné à reconnaître de manière unique l’origine des informations de topologie dans le domaine de routage. La RFC 2328 définit ce router ID comme une valeur de 32 bits identifiant le routeur dans le système autonome. [11] Une identité dupliquée compromet la capacité du réseau à relier correctement les annonces d’état de liens aux processus qui les émettent.

La documentation opérationnelle de Juniper classe également les router IDs dupliqués parmi les anomalies critiques, mais cette documentation explique un principe de protocole ; elle ne permet pas d’identifier le fournisseur de l’équipement impliqué chez LINX ni de lui attribuer l’incident. [18]

Un routeur provenant d’un laboratoire doit par conséquent être considéré comme porteur d’un état non fiable jusqu’à preuve du contraire. La suppression de la configuration visible n’est qu’une étape. Selon la plateforme, des processus persistants, des fichiers de démarrage, des adjacences, des caches de transfert, des associations VTEP, des identifiants de gestion, des certificats ou des versions logicielles peuvent survivre à une reconfiguration partielle.

La bonne unité de contrôle n’est pas le fichier nettoyé, mais la transition complète. L’équipement doit quitter un état de laboratoire connu, être réinitialisé selon une procédure reproductible, démarrer avec l’image et la configuration de production attendues, présenter les identités actives correctes et être reconnu ainsi par le reste du réseau. Si l’un de ces postconditions échoue, l’admission doit être refusée.

Une identité n’est pas une simple métadonnée

Le router ID peut ressembler à une valeur administrative parmi d’autres. En réalité, il est une ressource opérationnelle. Son unicité participe à la cohérence du protocole et à la possibilité de distinguer les équipements dans le graphe de routage.

Cette observation s’étend à d’autres identités : adresses de loopback des VTEP, numéros de systèmes autonomes, adresses du LAN de peering, identifiants d’interfaces, adresses MAC, VNI et route targets. Toutes ne produisent pas les mêmes symptômes en cas de conflit, mais elles partagent une exigence : le réseau doit pouvoir démontrer qui alloue la valeur, où elle est enregistrée, comment elle est appliquée et par quel mécanisme un doublon est détecté.

Un registre ou une source de vérité reste indispensable. Il permet de conserver l’intention, l’historique et la responsabilité de l’attribution. Mais ce registre fonctionne comme un livre de comptes, pas comme un souverain capable d’imposer à lui seul l’état du protocole. Une base peut contenir un identifiant unique tandis qu’un processus actif continue d’émettre sous une ancienne identité. La primauté revient alors au code en cours d’exécution et aux observations du réseau.

L’objectif n’est donc pas d’opposer les inventaires aux opérations. Il est de les réconcilier. À chaque identité déclarée doit correspondre une preuve issue de l’équipement et de ses voisins. Un changement d’identifiant doit conserver la valeur avant modification, la valeur attendue, l’événement de réinitialisation requis et la valeur observée après convergence. Un contrôle négatif doit démontrer qu’aucun autre processus du domaine n’utilise simultanément la même identité.

Cette discipline protège également l’automatisation. Une plateforme de déploiement devient plus fiable lorsqu’elle ne se contente pas de signaler l’acceptation de commandes, mais vérifie les postconditions sur le réseau vivant. Elle peut interroger le routeur candidat, ses voisins et la source de vérité, puis bloquer l’exposition au trafic si les vues divergent.

L’incident ne justifie pas une conclusion générale selon laquelle NETCONF ou l’automatisation seraient insuffisants par nature. Il révèle une définition trop faible du succès si celui-ci s’arrête à la livraison de la configuration. Une automatisation mature doit inclure l’effet attendu sur les processus, les adjacences et le transfert.

LON2 comme fabric EVPN sur VXLAN

Le contexte architectural est indispensable pour comprendre pourquoi l’incident dépasse la simple erreur d’identité. LINX a présenté LON2 comme une architecture désagrégée utilisant EVPN sur VXLAN et un modèle leaf-spine automatisé au sein d’un point d’échange réparti sur plusieurs sites. [3][4][5][6]

VXLAN transporte des segments Ethernet au-dessus d’un réseau IP en encapsulant les trames entre des points de terminaison de tunnel, les VTEP. La RFC 7348 décrit ce mécanisme d’encapsulation. [13] EVPN utilise BGP pour distribuer des informations de joignabilité et d’association nécessaires à l’overlay. La RFC 7432 définit le cadre EVPN, tandis que la RFC 8365 décrit son utilisation pour des overlays de virtualisation, notamment avec VXLAN. [14][15]

Cette séparation apporte de la souplesse et de l’échelle. L’underlay fournit la joignabilité IP entre les VTEP. Le plan de contrôle EVPN distribue les informations permettant de localiser les adresses MAC ou IP dans l’overlay. Le matériel de transfert doit ensuite programmer les entrées qui feront effectivement circuler les paquets.

Chacune de ces couches produit ses propres preuves. Une loopback de VTEP peut répondre. Une session BGP peut être établie. Une route EVPN peut être visible dans le logiciel. Une adresse MAC peut apparaître dans une table de contrôle. Pourtant, aucune de ces observations ne garantit isolément que l’ASIC ou le composant de transfert utilisera l’entrée attendue lorsque le paquet arrivera.

LINX a rapporté précisément ce type de divergence pour certains problèmes subsistant le 22 juin : des adresses MAC figuraient dans la table logicielle d’un équipement de bordure, mais pas dans sa table matérielle. La réinitialisation de la session BGP L2VPN EVPN entre les VTEP concernés a permis de repeupler la table matérielle. [1]

Cette observation ne démontre pas une défaillance générale d’EVPN, de BGP ou de VXLAN. Elle établit une limite plus précise : dans cet épisode, la présence d’une information au niveau logiciel ne suffisait pas à prouver la capacité de transfert. Le dossier de rétablissement devait descendre jusqu’au plan de données.

Quand le plan de contrôle et le matériel racontent des histoires différentes

La distinction entre une table logicielle et une table matérielle est centrale pour les infrastructures à haut débit. Le logiciel apprend, calcule ou reçoit des informations. Il construit ensuite une représentation logique de la destination et demande au plan de transfert de programmer l’état nécessaire. Le matériel traite les paquets à la vitesse de ligne à partir de cette programmation.

Si les deux vues divergent, les interfaces de contrôle peuvent présenter une situation cohérente alors que les paquets ne suivent pas le chemin attendu. L’opérateur peut voir une adresse MAC apprise, une route EVPN présente et une session stable, tout en conservant une panne sélective de joignabilité.

Les défaillances sélectives sont particulièrement difficiles à détecter dans un point d’échange. Le trafic global peut rester élevé. La majorité des membres peut continuer à communiquer. Les systèmes de supervision peuvent joindre les adresses de gestion. Les route servers peuvent conserver leurs sessions BGP. Seules certaines adresses, certains couples de leafs ou certains chemins peuvent échouer.

La RFC 9062 est pertinente parce qu’elle décrit des exigences d’exploitation, d’administration et de maintenance pour EVPN, y compris la nécessité de disposer de mécanismes permettant de vérifier la connectivité et de rapprocher les vues du plan de contrôle et du plan de données. [17] Elle ne prouve pas le défaut précis survenu à LON2. Elle fournit un cadre pour définir le type de preuve qu’un opérateur doit rechercher.

Un contrôle d’admission ou de clôture doit donc comparer les tables. Pour un échantillon représentatif d’adresses MAC et IP, il faut vérifier la présence dans la vue logicielle, la présence dans la vue matérielle et le succès d’un transfert réel. L’échantillon doit couvrir les combinaisons de leafs, de VTEP, de domaines de pont et de chemins qui peuvent révéler une asymétrie.

Cette vérification ne doit pas être réservée aux incidents. Elle peut devenir une postcondition de changement. Si une entrée attendue n’atteint pas le matériel, l’équipement ne doit pas être déclaré prêt au seul motif que le plan de contrôle la connaît. Le test final porte sur la réalité du transfert.

La redondance est un état démontré, pas une étiquette d’architecture

Le mot « redondant » est souvent utilisé comme propriété stable d’un système. Or la redondance varie avec l’état des chemins, les maintenances, les pannes et la capacité réelle des solutions de secours.

Après la perte de fibre du 20 juin, LON2 continuait à fonctionner, mais avec une résilience réduite selon LINX. [1] Cela signifie que les opérations du lendemain se sont déroulées dans une topologie différente de la topologie nominale. Les liens intercommutateurs, les agrégations, les équipements de cœur et les chemins restants portaient une importance accrue.

Une procédure de changement devrait reconnaître explicitement cette condition. Le système de gestion des changements doit savoir qu’un chemin est indisponible. Une activation programmée peut alors être évaluée contre la topologie réelle, et non contre un diagramme supposant tous les liens disponibles.

La cartographie des dépendances devient également nécessaire. Une fibre, une agrégation, un processus OSPF, une session EVPN et une table matérielle appartiennent à des couches différentes, parfois suivies par des équipes ou des fournisseurs différents. Pourtant, elles participent toutes au même service de bout en bout.

Le canari doit emprunter le chemin réellement sollicité. Un test effectué dans un laboratoire simplifié ou sur une partie non affectée du réseau peut donner une confiance trompeuse. Si le risque porte sur un chemin intercommutateur de secours ou sur un VTEP particulier, le canari doit exercer ce chemin, observer la convergence et vérifier le transfert de paquets.

Des conditions d’arrêt doivent être définies avant le changement : identité dupliquée, voisin inattendu, oscillation de lien, hausse des pertes, divergence entre tables, échec de sonde membre ou absence de convergence dans la fenêtre attendue. Cette préparation évite de négocier le niveau de gravité pendant que la fabric se dégrade.

Enfin, la responsabilité du retour arrière doit être explicite. Qui peut désactiver le nouveau routeur ? Qui peut réinitialiser un processus ou une session ? Qui décide de reporter l’activation tant que la fibre n’est pas réparée ? La distribution des compétences ne doit pas produire une absence de décision.

Reconstituer la séquence des 20, 21 et 22 juin

Une chronologie précise permet de ne pas simplifier excessivement l’incident. Le 20 juin, la fibre noire est tombée et la résilience a été réduite sans impact membre immédiat signalé par LINX. Le 21 juin, Flowmon a relevé des pertes et des liens intercommutateurs ont oscillé. Des pertes de trafic et des problèmes de joignabilité ont ensuite été observés sur le LAN de peering. [1]

Les ingénieurs ont désactivé des liens au cours de la restauration. Une agrégation entre équipements de cœur a ensuite été désactivée comme solution de contournement permettant de rétablir plus complètement le service. Ces actions montrent que la restauration était aussi une modification de topologie : retirer un chemin ou une agrégation peut stabiliser le réseau tout en changeant les propriétés de résilience et de capacité.

Le 22 juin, la perturbation générale avait diminué, mais des problèmes précis de joignabilité IP demeuraient. C’est dans ce contexte que LINX a observé des adresses MAC présentes dans la table logicielle mais absentes de la table matérielle, puis réinitialisé la session BGP L2VPN EVPN entre les VTEP affectés. [1]

Cette dernière étape est importante pour la méthode d’analyse. Le service n’était pas simplement « en panne » puis « rétabli ». Il existait une phase intermédiaire où la plupart des indicateurs pouvaient sembler meilleurs alors que des destinations particulières restaient injoignables. Une mesure agrégée ou une seule sonde aurait pu manquer ces cas.

Le récit public mentionne également qu’une résolution complète a été obtenue après le redémarrage d’un routeur de cœur et la réactivation du lien désactivé. [1] Plusieurs actions ayant été menées au fil de la récupération, leur succès opérationnel ne suffit pas à attribuer à chacune une portée causale universelle. Une action peut rétablir le service en supprimant un état problématique sans démontrer à elle seule comment cet état a été créé.

Pour apprendre de l’incident, chaque action devrait être reliée à une hypothèse, à un résultat attendu et à une observation. La réinitialisation d’une session vise un type d’état. Le redémarrage d’un équipement en vise potentiellement plusieurs. La réactivation d’un lien restaure une propriété topologique. Le dossier doit préserver ces distinctions.

Les épisodes de juin et novembre ne forment pas automatiquement une cause unique

La mise à jour de LINX ne s’arrête pas à la séquence du 20 au 22 juin. Elle mentionne un autre épisode de joignabilité le 29 juin, puis une réapparition de pertes sporadiques de flux le 5 novembre, après une opération de maintenance menée par un fournisseur sur une fibre noire. Elle évoque également une modification logicielle destinée à traiter le comportement de la table MAC matérielle, modification qui a ensuite été annulée après l’incident de novembre, tandis que l’enquête du fournisseur se poursuivait. [1]

La récurrence de symptômes similaires renforce la nécessité d’une méthode durable. Elle ne donne cependant pas le droit de déclarer que tous les épisodes partagent une cause racine unique. Une perte de joignabilité peut résulter de multiples combinaisons de topologie physique, d’identité de protocole, d’état EVPN et de programmation matérielle.

Le router ID OSPF conservé en juin constitue une observation précise attribuée à LINX. La divergence entre table MAC logicielle et table matérielle en constitue une autre. La maintenance de fibre et le retour arrière logiciel de novembre appartiennent à une séquence ultérieure. Le dossier public ne démontre pas que l’identité dupliquée explique à elle seule tous les symptômes de juin et de novembre.

Une gestion rigoureuse de la récurrence doit conserver plusieurs hypothèses tant que les preuves ne les départagent pas. Une réinitialisation peut supprimer l’état observé sans révéler son origine. Un redémarrage peut corriger plusieurs problèmes simultanément. Un retour arrière peut être prudent sans prouver que la version annulée causait tous les incidents.

Pour chaque hypothèse, l’opérateur devrait consigner le mécanisme envisagé, les symptômes qu’il explique, ceux qu’il n’explique pas, la modification appliquée et le test qui permettrait de la confirmer. Cette structure évite que le résultat visible — le retour du trafic — soit présenté comme une démonstration complète de causalité.

Le langage public devrait rester aligné sur ce niveau de preuve. Il est possible de dire ce que LINX a observé, ce que ses équipes ont modifié et ce qu’un fournisseur continuait d’examiner. Il serait excessif de transformer une enquête non close en attribution certaine ou en constat juridique.

Ce que mesure — et ne mesure pas — une disponibilité de 99,997 %

Le rapport annuel 2023 de LINX indique que LON2 a atteint une disponibilité de 99,997 %, sous l’objectif interne de 99,998 %, et relie cet écart à plusieurs interruptions. [2] La proximité des deux chiffres ne doit pas masquer la question essentielle : quelle population, quelle période et quelle définition de service composent le pourcentage ?

Une disponibilité agrégée résume utilement l’état d’un service. Elle ne révèle pas automatiquement quels membres, ports, VLAN, sessions ou préfixes étaient affectés. Elle ne montre pas davantage si une panne était symétrique ni si un petit groupe a subi un problème plus long que celui reflété par la moyenne.

Dans une fabric EVPN, une défaillance sélective peut être fortement diluée par un indicateur général. Si la mesure repose sur l’état électrique des ports, elle peut manquer un chemin qui reste « up » tout en ne transférant pas certaines destinations. Si elle repose sur le trafic total, les membres non affectés peuvent masquer les pertes d’un sous-ensemble. Si elle dépend des alarmes, elle hérite des angles morts de la supervision.

La méthode de calcul devrait donc être liée au dossier d’incident. Celui-ci doit préciser le dénominateur, les fenêtres de maintenance exclues, les points d’observation, les seuils et le type de service testé. Des sondes membre-à-membre, des vérifications de joignabilité des route servers, des tests de sessions bilatérales et des contrôles de l’overlay peuvent compléter la mesure.

Cela ne signifie pas que toutes les données internes doivent être rendues publiques. La topologie détaillée et les informations concernant les membres peuvent être sensibles. Il est possible de conserver des preuves restreintes tout en publiant une conclusion bornée : classe de service affectée, période, méthode de mesure, degré de confiance et statut de remédiation.

Le chiffre annuel confirme que les incidents ont compté dans le bilan de disponibilité de l’opérateur. Il ne peut être transformé en estimation client par client, en volume de paquets perdus ou en coût économique sans données supplémentaires. Toute tentative de ce type dépasserait les preuves disponibles.

Le point d’échange contrôle la fabric, pas toutes les politiques de ses membres

Un point d’échange fournit une infrastructure partagée à des réseaux autonomes. Les membres peuvent établir des sessions bilatérales, utiliser des route servers ou combiner plusieurs options. Les informations publiées par LINX décrivent ses services de peering et ses mécanismes d’automatisation, mais ne révèlent pas la stratégie de continuité de chaque membre. [7][8][9]

Cette séparation limite l’attribution tout en clarifiant les responsabilités. LINX contrôlait la fabric LON2 et la procédure par laquelle le routeur entrait en production. Cela inclut l’admission de l’équipement, le déploiement de configuration, la surveillance, l’isolement de liens, les manipulations de sessions et les communications relatives au service.

Les fournisseurs de fibre contrôlaient les opérations physiques relevant de leur périmètre. Les fournisseurs d’équipements ou de logiciels contrôlaient une partie de l’analyse des défauts et des correctifs disponibles. Une enquête fournisseur en cours ne prouve toutefois ni faute juridique ni causalité générale.

Les membres contrôlaient leurs propres ports, sessions BGP, politiques de routage et choix de diversification. Certains pouvaient utiliser plusieurs LAN de peering, d’autres échanges ou du transit. Le dossier public ne permet pas d’affirmer que tous disposaient des mêmes chemins ou qu’une seconde connexion constituait nécessairement une solution indépendante.

La responsabilité doit être attribuée action par action. Qui connaissait l’état dégradé de la fibre ? Qui pouvait reporter l’activation ? Qui devait vérifier l’identité OSPF active ? Qui pouvait réinitialiser le processus ? Qui rapprochait les tables logicielles et matérielles ? Qui testait la joignabilité depuis la bordure ? Qui informait les membres des cas résiduels ?

Cette matrice est plus utile que la recherche d’un responsable unique. Les incidents réseau traversent fréquemment des frontières techniques et organisationnelles. Plusieurs parties peuvent détenir des contrôles différents sans que les preuves disponibles permettent d’accuser l’une d’elles de négligence.

La responsabilité distribuée devient problématique seulement lorsqu’aucun acteur ne possède le test de bout en bout. Chaque équipe peut alors clôturer son composant tandis que le service reste imparfait. L’objectif est de rendre les interfaces de responsabilité explicites.

Le dossier d’admission d’un routeur issu du laboratoire

Un dossier d’admission crédible commence avant la connexion au réseau de production. Il identifie l’équipement, son rôle, son image logicielle, sa configuration de référence et les identités qu’il devra utiliser. Il précise la procédure de nettoyage ou de reconstruction appliquée et les états persistants susceptibles de survivre.

La vérification d’identité vient ensuite. Le dossier doit contenir le router ID OSPF attendu, la valeur rapportée par le processus actif et celle observée par les voisins. Une recherche de doublon doit couvrir le domaine concerné. Si l’identifiant a changé, la preuve doit inclure la réinitialisation, le redémarrage ou l’effacement de processus requis par la plateforme.

L’underlay doit être validé indépendamment. Les loopbacks de VTEP doivent être joignables par les chemins prévus. Les interfaces, métriques et agrégations doivent correspondre à la topologie réelle. Si une fibre est déjà indisponible, le test doit montrer que le chemin restant transporte la charge attendue et ne révèle pas un point de défaillance caché.

L’overlay exige ses propres contrôles. Le routeur doit annoncer et apprendre les informations EVPN prévues. Les VNI, domaines de pont et route targets doivent correspondre à la source de vérité. Une route inattendue, un voisin de laboratoire ou une association résiduelle doit bloquer l’admission.

La réconciliation du transfert est décisive. Les entrées MAC et IP sélectionnées doivent apparaître dans les vues logicielle et matérielle lorsque la plateforme les expose. Des paquets doivent franchir les combinaisons de leafs et de VTEP concernées. Le cas LINX montre pourquoi une table logicielle seule ne constitue pas une preuve suffisante.

Les tests négatifs sont tout aussi importants : absence de router ID dupliqué, de voisin non autorisé, de VTEP de laboratoire, de VLAN inattendu, de route target non suivie ou d’entrée confinée au logiciel. Les procédures vérifient souvent ce qui doit exister, mais omettent de prouver l’absence des résidus dangereux.

Enfin, la surveillance et le retour arrière doivent être prêts avant l’exposition au trafic. Les alertes de flux, l’état des liens, les sessions, la programmation matérielle et les sondes doivent être associés au nouvel équipement. Le propriétaire de chaque alerte et l’autorité capable d’annuler le changement doivent être connus.

Une automatisation n’est complète que lorsqu’elle vérifie ses effets

L’utilisation de NETCONF dans le récit de LINX illustre une distinction fondamentale. Un mécanisme automatisé peut appliquer exactement la configuration demandée sans que le processus actif adopte immédiatement la nouvelle valeur. [1]

Une automatisation mature doit donc être définie par ses postconditions. Elle ne se termine pas quand le serveur de configuration reçoit une réponse positive. Elle se termine lorsque l’état observé du réseau correspond au résultat attendu.

Pour une modification de router ID OSPF, les postconditions peuvent inclure la nouvelle identité locale, la disparition de l’ancienne, le rétablissement des adjacences, la cohérence des observations voisines et l’absence de doublon. Pour EVPN, elles peuvent inclure la stabilité des sessions, la joignabilité des VTEP, la présence des routes attendues et la programmation des entrées sélectionnées dans le matériel.

Le pipeline doit aussi connaître les opérations non déclaratives nécessaires. Certaines modifications requièrent de réinitialiser un processus, de redémarrer un démon ou de redémarrer l’équipement. Ces opérations ne sont pas des exceptions informelles à laisser à la mémoire d’un ingénieur. Elles doivent faire partie du contrat de déploiement de la plateforme concernée.

Une bonne automatisation interroge plusieurs perspectives. Elle compare le candidat, ses voisins, la source de vérité et, lorsque possible, le plan de transfert. Cette vérification croisée évite qu’une commande locale correcte soit prise pour une représentation complète du domaine.

Elle doit enfin savoir s’arrêter. Une divergence d’identité, une adjacence inattendue ou une entrée absente du matériel doit empêcher le passage à l’étape d’exposition au trafic. Le système ne doit pas seulement produire un avertissement dans un journal que personne ne consulte pendant la fenêtre de changement.

L’enseignement de LON2 n’est donc pas qu’il faut remplacer l’automatisation par des interventions manuelles. Il est qu’il faut automatiser la preuve de l’état réel, y compris les contrôles négatifs et les effets sur le transfert.

Le canari doit représenter l’architecture qui portera le trafic

Les essais en laboratoire réduisent les risques, mais ils peuvent aussi simplifier les conditions déterminantes. Une maquette ne reproduit pas toujours la densité de routes, la variété des équipements voisins, les chemins de fibre, les agrégations ou les contraintes de programmation matérielle de la production.

Le canari de production doit par conséquent être limité sans être artificiel. Il peut porter un sous-ensemble de chemins ou de trafic, mais il doit traverser les mécanismes dont on veut valider le comportement : underlay, VTEP, plan de contrôle EVPN, tables matérielles et chemin de secours.

Dans une situation de résilience fibre réduite, le canari doit emprunter la topologie dégradée qui portera réellement les paquets. Tester uniquement le chemin nominal absent ou un segment non concerné ne répond pas à la question opérationnelle.

Les critères de réussite doivent associer plusieurs niveaux. L’adjacence OSPF doit être correcte. La session EVPN doit être stable. Les routes et adresses attendues doivent être présentes. Les entrées correspondantes doivent être programmées en matériel. Des sondes doivent confirmer le transfert bidirectionnel depuis des points représentatifs.

Le canari doit également avoir une durée suffisante pour révéler des oscillations ou des pertes sporadiques. Une capture instantanée immédiatement après la convergence peut manquer un comportement intermittent. Les signaux Flowmon, les changements d’état des liens et les variations de programmation doivent être observés pendant une fenêtre définie.

Un test de basculement contrôlé complète l’exercice. Si le design promet une continuité après la perte d’un chemin, l’opérateur doit démontrer cette continuité avant que le routeur ne porte une charge étendue. La RFC 5880 décrit BFD comme un mécanisme de détection rapide des défaillances de chemin, mais la présence d’un mécanisme de détection ne remplace pas le test du service de bout en bout. [16]

Le résultat du canari doit être conservé avec le changement. Sans horodatage, chemins testés, valeurs observées et décision finale, le mot « validé » reste une affirmation impossible à auditer.

La preuve de restauration doit atteindre la bordure membre

Un lien stable ne prouve pas la disponibilité du service. Une session BGP établie ne prouve pas que tous les paquets utiles traversent la fabric. Une table matérielle correctement remplie ne prouve pas, à elle seule, que le chemin complet fonctionne dans les deux sens.

La clôture doit donc inclure des observations depuis la bordure membre ou depuis des points de vue représentatifs. Les sondes doivent franchir les chemins affectés et tester une joignabilité bidirectionnelle. Selon le contexte, plusieurs tailles de paquets ou protocoles peuvent être nécessaires. Un seul ping réussi constitue une preuve faible pour une infrastructure transportant des flux très divers.

Les résultats doivent être segmentés. Le 22 juin, LINX signalait encore des problèmes concernant des adresses IP précises. [1] Une vérification globale de la fabric pouvait réussir tout en laissant ces cas non résolus. La clôture devait donc rapprocher l’adresse concernée, l’état MAC, les informations EVPN et le transfert effectif.

Les signalements des membres constituent également des observations pertinentes, sans être automatiquement décisifs. Un membre peut détecter une panne invisible à la supervision centrale. À l’inverse, un problème applicatif ou interne peut ressembler à une défaillance du point d’échange. Des horodatages et des données de chemin comparables permettent de distinguer ces situations.

La communication doit préserver la différence entre restauration large et résolution totale. Si la désactivation de liens rétablit la majorité du service mais que des cas résiduels subsistent, un seul horaire de rétablissement masque la réalité. Le compte rendu doit préciser ce qui a été restauré, comment cela a été vérifié et ce qui reste en investigation.

Cette prudence n’est pas un exercice de style. Elle empêche qu’une solution de contournement soit ultérieurement considérée comme une correction de cause racine, et elle protège les équipes contre une fausse certitude lors d’une récurrence.

Un modèle de preuves versionné pour les récidives

Les événements de juin et novembre montrent l’intérêt d’un modèle de preuves versionné. Chaque correction doit être associée à une hypothèse de défaillance, à un résultat observable attendu et à un test capable de confirmer ou d’infirmer ce résultat.

Pour l’identité OSPF, l’hypothèse porte sur un processus actif ayant conservé une ancienne valeur. La correction attendue est une identité unique dans tout le domaine après la réinitialisation appropriée. Les preuves comprennent les vues locale et voisines ainsi qu’une recherche de doublons.

Pour la divergence MAC, l’hypothèse concerne la synchronisation ou la programmation entre le plan de contrôle et le plan de transfert. Le résultat attendu est la présence cohérente des entrées sélectionnées et le passage des paquets. Les preuves associent tables logicielles, tables matérielles, état EVPN et sondes.

Pour la fibre, l’hypothèse porte sur la réduction de diversité et sur la topologie portée par les liens restants. Le résultat attendu est soit la restauration de la diversité physique, soit la validation explicite du mode dégradé. Les preuves comprennent l’état optique, la carte des chemins, la capacité et les essais de basculement.

Pour une modification logicielle, l’hypothèse doit être rattachée à un défaut ou à un symptôme défini. Une installation réussie ne démontre pas sa correction. De même, un retour arrière après un incident est une donnée importante sans prouver que la version annulée expliquait tous les symptômes.

Ces ensembles de preuves doivent partager une chronologie fiable. Sans synchronisation temporelle, une équipe peut associer un événement de contrôle à une perte de trafic survenue avant ou après. Il faut distinguer l’heure réelle de l’événement, l’heure de son observation et l’heure de l’action corrective.

La comparaison entre incidents devient alors plus rigoureuse. Si un nouvel épisode reproduit la même divergence matérielle dans une topologie comparable, la confiance dans un mécanisme commun augmente. Si seul le symptôme visible est similaire, l’incertitude doit rester plus forte.

Des métriques qui mesurent le réseau plutôt que le rituel

Le taux de réussite des déploiements et le temps moyen de rétablissement sont utiles, mais incomplets. Une automatisation peut déclarer un succès tout en laissant un processus avec une ancienne identité. Un service peut sembler rétabli rapidement en moyenne alors que certaines destinations restent injoignables.

Un programme d’admission laboratoire-production devrait mesurer les échecs de postcondition. Combien de fois l’identité voulue diffère-t-elle de l’identité active ? Combien d’équipements nécessitent une réinitialisation imprévue ? Combien d’admissions révèlent-elles une adjacence, une route ou une entrée de transfert résiduelle ? À quelle fréquence les tables logicielle et matérielle divergent-elles pendant un canari ?

L’exposition en état dégradé mérite également une mesure. Pendant combien de temps le réseau fonctionne-t-il sans la diversité de chemins prévue ? Combien de changements sont-ils réalisés pendant cette période ? Les risques ont-ils été explicitement acceptés ? Chaque changement disposait-il d’un canari représentatif et d’une preuve de retour arrière ?

La vérification côté membre constitue une autre métrique. Quelle proportion du service affecté a été testée depuis des points d’observation pertinents ? Quel délai sépare le rétablissement général de la résolution des cas résiduels ? Les sondes en échec et les retests réussis sont-ils conservés ?

La complétude du dossier peut aussi être mesurée : chronologie synchronisée, topologie, identité des protocoles, données de transfert, sondes, propriétaires des actions et limites des déclarations publiques. L’objectif n’est pas de remplir des formulaires. Une preuve manquante indique une conclusion que l’opérateur ne pouvait pas démontrer.

Ces métriques ne doivent pas devenir un théâtre de conformité. Une équipe peut optimiser le nombre de contrôles cochés sans améliorer le réseau. Des échantillons aléatoires, des revues indépendantes et la comparaison avec les incidents réels permettent de maintenir leur utilité. Le test final reste la détection des divergences avant que les membres n’en subissent les effets.

La responsabilité sans invention de faute

L’analyse technique doit séparer clairement contrôle opérationnel, causalité et faute juridique. LINX avait la maîtrise de la fabric et de l’admission du routeur. Cela suffit pour examiner les contrôles qu’un opérateur de point d’échange doit posséder. Cela ne suffit pas pour conclure à une négligence.

Les fournisseurs détenaient des responsabilités sur certains composants ou investigations. Le fait qu’un fournisseur poursuive une enquête ou qu’une modification logicielle soit annulée ne prouve ni la cause universelle des événements ni un manquement contractuel.

Les membres avaient leurs propres responsabilités de connectivité. Leurs choix de sessions bilatérales, de route servers, d’autres points d’échange ou de transit pouvaient modifier leur exposition. Les sources publiques ne permettent pas de reconstruire ces choix membre par membre.

Une analyse défendable pose donc des questions de propriété sans transformer les réponses inconnues en accusations. Qui possédait le contrôle d’admission ? Qui devait attester l’identité active ? Qui contrôlait l’état des fibres ? Qui avait autorité pour revenir en arrière ? Qui conservait les preuves de transfert ? Qui informait les membres des limitations restantes ?

Cette approche est cohérente avec une responsabilité fondée sur la réalité du réseau. Elle considère les registres, les configurations et les rapports comme des éléments nécessaires, mais exige qu’ils soient liés à l’état actif. Elle ne fait pas du document le substitut du paquet.

La qualité du compte rendu public de LINX tient précisément à la publication de détails techniques exploitables : résilience réduite, ancienne identité OSPF conservée, divergence entre tables, solutions de contournement, récurrence et enquête en cours. [1] Ces éléments permettent de définir de meilleurs contrôles sans spéculer sur les personnes, les contrats ou les données privées.

L’analyse gagne en force lorsqu’elle respecte ces frontières. Les affirmations directement issues de LINX restent attribuées à LINX. Les RFC expliquent les protocoles. La documentation fournisseur illustre des pratiques générales. Aucune de ces catégories ne doit être utilisée pour produire artificiellement une conclusion que les sources ne contiennent pas.

Ce que les sources publiques ne permettent pas d’affirmer

Les documents disponibles ne donnent pas la liste complète des membres, préfixes, sessions, sites ou volumes de trafic affectés. Ils ne fournissent pas une durée exhaustive pour chaque épisode de joignabilité. Ils n’exposent pas la configuration privée des équipements, l’intégralité des transactions d’automatisation, les bases de transfert ni le dossier fournisseur complet.

Ils ne prouvent pas que le router ID OSPF dupliqué explique à lui seul tous les symptômes de juin et novembre. Ils ne démontrent pas non plus qu’EVPN, VXLAN, OSPF, BGP, NETCONF, l’automatisation ou le matériel désagrégé sont intrinsèquement dangereux.

La disponibilité annuelle de 99,997 % ne constitue pas une mesure membre par membre. Elle ne doit pas être convertie en nombre supposé de clients affectés, en paquets perdus ou en pertes financières.

Les sources ne démontrent aucune négligence, dissimulation, violation contractuelle ou faute individuelle de LINX, d’un fournisseur ou d’un ingénieur. L’analyse de responsabilité peut identifier les contrôles nécessaires sans rendre de jugement juridique.

Elles ne décrivent pas davantage la topologie privée complète de LON2 ni le comportement précis de chaque membre entre LON1, LON2, les route servers, les sessions bilatérales et le transit. Les documents publics sur la double infrastructure londonienne et les services de peering fournissent un contexte, pas une preuve de la stratégie de chaque réseau connecté. [4][7][8][20]

Ces limites doivent accompagner les conclusions, et non être reléguées à une réserve formelle. La confiance est élevée pour la chronologie et les observations attribuées à LINX. Elle est plus faible pour l’allocation complète de la cause et de l’impact.

Une conclusion bornée n’est pas une conclusion faible. Elle distingue ce qui est observé, ce qui est expliqué par les standards, ce qui est déduit comme exigence de contrôle et ce qui demeure inconnu. C’est précisément cette séparation qui rend l’analyse utile aux opérateurs.

Le réseau en cours d’exécution constitue le registre final

La leçon durable de LON2 n’est pas que les laboratoires seraient dangereux ni que les fabrics modernes seraient trop complexes. Elle est que le passage de l’intention à la production doit être démontré.

Un dépôt de configuration peut attribuer un nouveau router ID. NETCONF peut livrer cette valeur. Un inventaire peut associer correctement l’équipement à son rôle. Le plan de contrôle EVPN peut afficher une adresse MAC. Un tableau annuel peut rester très proche de 100 %. Tous ces enregistrements peuvent être exacts alors que le chemin de paquets reste incorrect.

Le registre final est le réseau actif : identité de protocole unique observée dans le domaine, adjacences courantes, joignabilité des VTEP, état EVPN cohérent, entrées programmées dans le matériel, chemins physiques stables et tests de bout en bout réussis.

Cette norme renforce la valeur de l’automatisation. Une plateforme devient digne de confiance lorsqu’elle vérifie ses effets et bloque sur les divergences. La réponse à un processus conservant une ancienne identité n’est pas davantage de gestes manuels. C’est un contrat de déploiement indiquant quand une réinitialisation est requise et prouvant ensuite le résultat actif.

Pour un point d’échange, cette exigence est particulièrement importante. La fabric relie des réseaux indépendants dont l’opérateur ne contrôle pas toutes les politiques. Il peut néanmoins prouver l’état de la plateforme commune : diversité des chemins, unicité des identités, cohérence entre contrôle et transfert, joignabilité représentative et traitement explicite des inconnues.

Le récit de LINX fournit une matière rare pour construire cette discipline. Il décrit la fibre dégradée, l’identité OSPF conservée, la divergence entre logiciel et matériel, les manipulations de liens et de sessions, la récurrence et l’enquête poursuivie. [1] La réponse responsable n’est pas d’en tirer une histoire simpliste avec un coupable unique. Elle consiste à transformer chaque observation en condition d’admission et en preuve de clôture.

Une architecture redondante non exercée reste une promesse. Une identité correcte uniquement dans la configuration reste une promesse. Une adresse MAC présente uniquement dans le logiciel reste une promesse. La responsabilité commence lorsque l’opérateur peut montrer que chacune de ces promesses s’est matérialisée dans le transfert réel des paquets.