Résumé

  • Les 22 et 23 novembre 2023, des trames LACP à portée locale du lien ont franchi la limite d’une connexion client sur le tissu partagé d’AMS-IX, perturbant l’état de groupes d’agrégation de liens et de sessions BGP appartenant à d’autres entités.
  • Une analyse de responsabilité doit distinguer le déclenchement, l’amplification interconstructeurs, la stabilisation de la plateforme et le rétablissement réellement observé par les réseaux connectés; elle doit aussi exiger des preuves testables d’isolation, de conformité et de chemins de secours utilisables.

Un incident d’isolation, pas seulement une baisse de trafic

L’incident survenu à Amsterdam en novembre 2023 ne se résume pas à une courbe de trafic dégradée. Il pose une question plus fondamentale pour tout point d’échange Internet: une trame de contrôle qui n’a de sens qu’entre deux systèmes adjacents peut-elle sortir de cette relation et modifier l’état réseau d’autres entités sur une infrastructure Ethernet partagée ?

Selon le compte rendu d’AMS-IX, la réponse a été oui pendant les épisodes examinés. Un équipement client a émis des paquets LACP alors qu’il était raccordé à un port qui n’utilisait pas LACP. Ces paquets ont ensuite été propagés par un commutateur de périphérie fournisseur Juniper au-delà de la relation à laquelle ils auraient dû rester confinés. Des groupes d’agrégation de liens appartenant à d’autres clients ont réagi aux trames reçues. Leurs états LACP ont fluctué, avec des répercussions sur leurs sessions BGP.

Cette séquence fait de l’événement un problème d’isolation du tissu de peering. La trame initiale provenait d’un côté client, mais la portée de ses effets dépendait des contrôles placés entre ce port et le reste de la plateforme: règles d’admission, listes de contrôle d’accès, logique d’approvisionnement, comportement effectif des commutateurs et détection des trames anormales. Une trame indésirable n’aurait pas dû pouvoir acquérir une portée multi-entités simplement parce qu’elle avait été émise.

La distinction est essentielle pour attribuer les responsabilités sans spéculer sur une faute juridique. L’équipement client contrôlait la source de la trame. AMS-IX contrôlait le tissu partagé, la politique applicable aux ports, la génération des filtres, le choix et l’exploitation des équipements ainsi que les mécanismes de surveillance et de communication. Les constructeurs contrôlaient le comportement de leurs implémentations. Les réseaux connectés contrôlaient, chacun dans ses propres limites, leurs capacités de transit de secours, leurs autres sessions de peering et l’autorité opérationnelle permettant de déplacer du trafic.

Aucun de ces constats ne permet, à lui seul, de conclure à une négligence, à une illégalité, à une rupture de contrat, à une intention malveillante ou à une responsabilité juridique. Ils permettent en revanche de poser une question technique précise: quelles limites auraient dû être invariantes, et quelles preuves montrent qu’elles l’étaient effectivement ?

Deux fenêtres officielles distinctes

AMS-IX a déclaré une première période affectée allant de 19 h 08 à 23 h 04 CET le 22 novembre 2023. Le lendemain, une seconde période a été enregistrée de 09 h 38 à 10 h 25 CET. Ces deux intervalles doivent rester séparés dans toute chronologie sérieuse. Ils montrent que l’histoire ne s’est pas achevée avec la première remontée apparente du trafic.

Pendant la première période, les fluctuations actives de sessions LACP et BGP ont accompagné une forte baisse du trafic observé sur la plateforme d’échange. AMS-IX a indiqué un point bas de 2,1 Tb/s. L’opérateur a également rapporté une diminution du nombre de sessions BGP IPv4, de 885 à 550, et du nombre de sessions IPv6, de 800 à 450.

Ces chiffres décrivent l’état de la plateforme d’échange. Ils ne comptent ni des utilisateurs, ni des applications, ni des entreprises intégralement déconnectées. Ils ne quantifient pas les pertes économiques ou la perte de paquets totale. Ils ne démontrent pas non plus que toute l’Europe aurait subi une panne uniforme. Une session BGP en moins peut affecter un ensemble de préfixes, mais sa conséquence concrète dépend des autres chemins disponibles, de la capacité de ces chemins et des décisions de chaque réseau.

Le point bas de 2,1 Tb/s doit être interprété avec la même discipline. Une baisse de trafic sur AMS-IX peut résulter de sessions devenues indisponibles, mais aussi d’un déplacement volontaire du trafic vers d’autres interconnexions. Une partie du trafic absent de la plateforme peut donc continuer à circuler ailleurs. La courbe mesure le volume traversant l’échange; elle ne mesure pas directement l’expérience de bout en bout de chaque service.

La seconde fenêtre, le 23 novembre, impose une autre prudence. Une plateforme peut sembler stabilisée à un moment donné sans que toutes les causes contributives soient comprises, que tous les entités aient rétabli leurs sessions ou que tous les services aient retrouvé leurs chemins habituels. La réapparition d’une période affectée le lendemain rappelle que la récupération doit être établie par plusieurs niveaux de preuve, pas seulement par une amélioration momentanée d’un agrégat.

La chronologie technique: du port client au tissu partagé

Le point de départ attribué par AMS-IX est une émission de paquets LACP par un équipement client raccordé à une liaison qui n’était pas configurée comme liaison LACP. L’identité du client et le modèle de son équipement n’ont pas été rendus publics. Il serait donc incorrect de les inférer à partir des entités connus de l’échange ou d’indices indirects.

LACP sert à coordonner une agrégation de liens entre systèmes adjacents. Ses messages décrivent notamment la participation des ports à un groupe agrégé et permettent aux deux extrémités de négocier un état cohérent. Leur signification est locale à cette relation. Ils ne sont pas destinés à être relayés à travers un réseau Ethernet partagé comme s’il s’agissait de trafic ordinaire.

C’est précisément cette propriété qui rend la fuite importante. Une trame LACP ne doit pas seulement être « inhabituelle » sur un port non-LACP. Elle doit être contenue. Le contrôle attendu est une limite de portée: quelle que soit la manière dont un client configure son équipement, une trame de protocole lent à portée locale du lien ne doit pas être livrée à un autre entité.

Selon le récit d’AMS-IX, le commutateur de périphérie fournisseur Juniper a propagé les paquets. D’autres clients les ont alors reçus, et certains de leurs groupes d’agrégation ont réagi. L’état des LAG a fluctué. Lorsque des interfaces ou des agrégats servant de support à des sessions de peering changent d’état, les sessions BGP correspondantes peuvent tomber puis se rétablir. La documentation d’AMS-IX explique d’ailleurs que des changements de topologie et de lien peuvent provoquer des fluctuations BGP, et recommande des temporisations courtes dans le contexte approprié.

Cette documentation établit une attente opérationnelle: le lien entre l’état d’agrégation, la topologie et les sessions BGP est connu. Elle ne prouve toutefois pas quelle ligne de code, quelle syntaxe de filtre ou quelle version logicielle a permis la fuite en novembre 2023. Une documentation générale décrit le modèle voulu; elle ne remplace pas les journaux, les configurations et les essais relatifs à l’événement.

L’invariant manquant sur le port non-LACP

Le fait que le port concerné n’utilisait pas LACP ne rendait pas le filtrage moins nécessaire. Il rendait au contraire l’invariant plus simple à formuler: une trame LACP reçue sur ce port ne devait pas franchir sa frontière client.

Une politique robuste ne devrait pas dépendre d’une hypothèse selon laquelle un client raccordé sans agrégation dynamique n’émettra jamais de trame LACP. Un équipement peut être mal configuré, conserver un ancien réglage, subir une modification ou générer un trafic inattendu. La fonction du tissu partagé n’est pas de présumer que toutes les extrémités seront toujours conformes, mais de limiter la portée d’une anomalie lorsqu’elle apparaît.

AMS-IX a indiqué que des mesures de filtrage LACP existaient. Le compte rendu précise néanmoins que la liste de contrôle d’accès LACP sortante pertinente sur les équipements Juniper n’était pas pleinement opérationnelle. Sur les commutateurs Extreme SLX, la liste sortante ne s’est pas comportée comme attendu. AMS-IX a laissé ouverte la question de savoir si ce comportement provenait d’un bogue logiciel ou d’une modification de syntaxe après une mise à niveau.

Cette incertitude ne doit pas être comblée par une accusation contre l’un ou l’autre constructeur. Les versions exactes, la syntaxe complète des règles, l’historique des modifications et les conclusions des fournisseurs ne sont pas publics. On peut cependant identifier le besoin de preuve: pour chaque famille d’équipements et chaque type de port, un test doit démontrer qu’une trame LACP reçue d’un entité ne peut pas être transmise à un autre.

L’invariant devrait s’appliquer aux ports agrégés statiquement, aux ports utilisant LACP et aux ports sans agrégation. Les actions légitimes peuvent varier selon le type de port, mais la frontière interclient ne devrait jamais varier. Sur un port LACP, certaines trames doivent atteindre le système adjacent qui termine la relation. Sur un port non-LACP, elles peuvent être rejetées ou placées en quarantaine. Dans aucun cas elles ne devraient circuler entre entités.

De la fluctuation LACP aux sessions BGP

Une fois les trames sorties de leur périmètre, le risque n’était plus limité à une irrégularité de couche 2. Les systèmes destinataires pouvaient interpréter ces messages comme des informations pertinentes pour leurs propres agrégats. La réaction d’un LAG modifie l’ensemble logique de liens disponibles. Selon la topologie, elle peut supprimer momentanément le support d’une session BGP ou provoquer des changements répétés d’état.

La chute rapportée des sessions IPv4 de 885 à 550 et des sessions IPv6 de 800 à 450 indique une perturbation importante sur le plan de contrôle de l’échange. Mais elle ne dit pas que toutes les sessions ont échoué pour une cause identique, ni que chaque réseau a subi le même effet. Certaines sessions ont pu tomber directement avec un agrégat; d’autres ont pu être désactivées volontairement par des opérateurs souhaitant protéger leur trafic; d’autres encore ont pu rester établies alors que le chemin de données était dégradé.

Cette dernière possibilité explique pourquoi la seule vue BGP ne suffit pas. Une session « établie » est une preuve utile, mais partielle. Elle montre que deux routeurs échangent encore des messages de contrôle. Elle ne garantit pas que toute la capacité attendue est disponible, que les paquets suivent le meilleur chemin ni que les applications atteignent leur destination avec une qualité acceptable.

Inversement, la disparition d’une session à AMS-IX ne prouve pas nécessairement une perte totale de connectivité. Un réseau disposant de transit, d’un autre point d’échange ou d’un peering distant peut annoncer ou apprendre les mêmes routes ailleurs. La responsabilité opérationnelle ne consiste donc pas uniquement à préserver un compteur de sessions; elle consiste à maintenir des chemins utilisables ou à basculer vers eux de façon contrôlée.

Pression sur les ressources et amplification RSVP

Le compte rendu d’AMS-IX décrit ensuite une amplification au-delà de la fuite initiale. Les fluctuations LACP et BGP ont créé de la pression sur les ressources. AMS-IX a signalé une situation de pénurie de ressources et de tampons pleins, associée à des erreurs de délai RSVP. Des équipements Juniper affectés ont envoyé des messages RSVP Path Error, lesquels ont provoqué des problèmes supplémentaires sur des commutateurs Extreme SLX.

Il faut préserver l’ordre causal présenté par l’opérateur. RSVP n’est pas décrit comme l’origine de l’incident. Le déclenchement attribué par AMS-IX est la fuite de trames LACP, suivie des fluctuations LAG et BGP. La signalisation RSVP et les Path Error interviennent comme éléments d’une cascade aggravée par la pression sur les ressources.

Cette distinction évite deux erreurs. La première consisterait à transformer un protocole de signalisation en cause initiale alors que les faits publiés ne le soutiennent pas. La seconde serait de généraliser la cascade à tous les réseaux MPLS. Le comportement observé dépendait d’une architecture, d’implémentations, de réglages et d’états de ressources particuliers. Les normes RSVP-TE, MPLS et VPLS expliquent le rôle des messages, la signalisation et certains mécanismes de récupération; elles ne prouvent pas que toute infrastructure conforme reproduirait le même enchaînement.

L’aspect interconstructeurs mérite néanmoins une attention particulière. Un système peut satisfaire ses essais locaux et échouer lorsque les sorties d’un équipement deviennent les entrées exceptionnelles d’un autre. Sous charge normale, un message Path Error peut être traité sans conséquence étendue. Dans une plateforme où les sessions fluctuent, où les files se remplissent et où les ressources se raréfient, sa fréquence ou son contexte peut produire un effet différent.

La responsabilité technique s’étend donc aux interactions. Les tests ne devraient pas seulement demander si chaque commutateur filtre correctement une trame dans un scénario nominal. Ils devraient exercer les combinaisons Juniper–Extreme réellement déployées, reproduire les variations rapides d’état, imposer une pression contrôlée sur les ressources et vérifier qu’aucun message de contrôle ne transforme une perturbation localisée en cascade.

Les tampons pleins sont un signal, pas une explication complète

Dire que des tampons étaient pleins décrit un état observable, mais pas toute la chaîne qui y a conduit. Pour comprendre la propagation, il faudrait connaître la nature des files concernées, les volumes de messages, les seuils, les mécanismes de limitation, les priorités et la chronologie détaillée de la consommation des ressources. Ces données ne sont pas publiques dans le paquet factuel disponible.

Il serait donc excessif d’affirmer qu’un paramètre précis aurait suffi à éviter l’incident. On peut en revanche demander que les preuves de réparation relient la cause, l’état intermédiaire et le contrôle correctif. Si la plateforme a subi une pression anormale lors de fluctuations LACP et BGP, les essais doivent montrer comment elle se comporte lorsque cette pression est reproduite. Si des files de contrôle peuvent se remplir, les alarmes doivent se déclencher avant que les fonctions de récupération ne deviennent elles-mêmes des amplificateurs.

Cette approche protège également contre une vision trop étroite du « correctif ». Ajouter un filtre sur le port qui a participé à l’événement peut supprimer la reproduction la plus directe. Cela ne démontre pas que tous les ports équivalents sont conformes, que la génération automatique des règles est cohérente, que les mises à niveau conservent leur sémantique ou que les interactions entre plateformes restent maîtrisées.

Trois niveaux de récupération à ne pas confondre

La chronologie met en évidence au moins trois niveaux de récupération.

Le premier est la stabilisation de la plateforme AMS-IX: arrêt des fluctuations, retour des sessions et restauration d’un fonctionnement suffisamment stable pour le trafic. C’est le niveau que décrivent principalement les métriques de l’échange.

Le deuxième est le déplacement du trafic par les réseaux connectés. Certains opérateurs ont retiré des sessions, modifié leurs préférences ou utilisé d’autres chemins. Ce déplacement peut réduire l’exposition de leurs clients avant que le tissu partagé soit complètement stabilisé.

Le troisième est le rétablissement de bout en bout. Il dépend des routes réellement sélectionnées, de la capacité disponible, des congestions éventuelles et du comportement des services. Il peut précéder ou suivre la stabilisation de la plateforme pour un réseau donné.

Total Uptime a fourni une observation contemporaine de déplacement du trafic et de restauration. Cette information montre qu’un opérateur connecté a utilisé ses propres leviers pour réagir. Elle ne constitue pas une mesure de l’impact total sur AMS-IX ni de l’ensemble des utilisateurs.

NFOrce a documenté l’arrêt de sessions et des mesures destinées à limiter la perte de paquets. Là encore, l’observation porte sur la réponse d’un réseau particulier. Elle indique qu’une désactivation volontaire peut être préférable au maintien d’une interconnexion instable, mais elle ne permet pas de quantifier la situation de tous les entités.

EDPnet a publié une chronologie d’impact de service, une affirmation relative à une capacité alternative et des mises à jour de rétablissement. Cette documentation contribue à relier l’état de l’échange à une expérience en aval. Elle reste néanmoins le compte rendu d’un opérateur, circonscrit à son réseau et à sa visibilité.

Ces exemples ne prouvent pas que tout trafic pouvait contourner le dommage. Ils montrent que les chemins de secours ont une valeur lorsque quatre conditions sont réunies: ils existent, ils disposent d’une capacité suffisante, les routes peuvent effectivement les utiliser et une personne ou une automatisation possède l’autorité nécessaire pour déclencher le changement.

Ce que RIPE Atlas rend visible

L’analyse fondée sur RIPE Atlas apporte une perspective différente. Au lieu de partir uniquement des compteurs internes d’AMS-IX, elle observe des chemins depuis des sondes réparties sur Internet. Les résultats du paquet gelé indiquent que certains chemins ont contourné la zone affectée, tandis que d’autres ont échoué ou changé.

Cette visibilité est importante parce qu’elle montre la diversité des résultats. Internet peut contourner un dommage pour certaines paires source-destination sans le faire pour toutes. Les politiques BGP, les relations commerciales, la présence à d’autres points d’échange et la capacité disponible déterminent les options réelles.

RIPE Atlas ne voit toutefois pas chaque utilisateur, chaque application ou chaque flux. L’emplacement des sondes, le choix des cibles, le moment des mesures et les chemins visibles limitent l’inférence. Un changement de traceroute peut révéler un déplacement de chemin sans quantifier à lui seul la perte de paquets, la latence applicative ou les pertes commerciales.

L’intérêt de ces mesures réside donc moins dans une estimation universelle que dans la confrontation de plusieurs récits. Les compteurs d’AMS-IX indiquent une dégradation du tissu. Les notifications d’opérateurs décrivent des décisions locales. RIPE Atlas révèle des conséquences de chemin hétérogènes. Ensemble, ces sources permettent de distinguer l’état de la plateforme, les mécanismes de contournement et l’expérience en aval, sans prétendre disposer d’une vue exhaustive.

Les chemins alternatifs ont une économie

La présence théorique d’une autre route ne suffit pas. Un chemin de transit de secours peut être techniquement disponible mais trop petit pour absorber le trafic normalement échangé à AMS-IX. Un peering distant peut exister sans transporter les mêmes routes ou sans disposer d’une capacité immédiatement mobilisable. Une politique BGP peut aussi maintenir une préférence pour le chemin affecté tant qu’un opérateur ne modifie pas ses annonces ou ne ferme pas une session.

L’obligation opérationnelle raisonnable n’est donc pas « avoir une seconde connexion » sous une forme abstraite. Elle consiste à connaître la capacité mobilisable, les préfixes couverts, les délais de bascule, les dépendances communes et les personnes habilitées à agir. Un chemin de secours non testé est un enregistrement d’intention, pas une garantie de continuité.

Pour les réseaux connectés, cette préparation a un coût. Le transit redondant, le peering distant, les ports supplémentaires et la capacité inutilisée représentent des dépenses. Toutes les organisations ne peuvent pas acheter la même marge. Cette contrainte n’efface pas la valeur du contrôle; elle impose de définir explicitement le risque accepté et les services qui exigent une redondance supérieure.

Pour un échange, la question complémentaire est de réduire la probabilité qu’un entité oblige les autres à utiliser ces options. L’isolation du tissu partagé reste la première défense. Les chemins alternatifs sont une couche de résilience, non un substitut à la séparation des domaines de contrôle.

Registres d’intention et réalité en fonctionnement

Un point d’échange dispose de nombreuses données décrivant ce qui devrait exister: entités, numéros de système autonome, interfaces, types de port, agrégats, politiques autorisées et règles générées. Ces éléments sont indispensables. Ils permettent d’identifier une relation, de reconstruire une configuration attendue et de déterminer les contrôles qui auraient dû s’appliquer.

Mais ces enregistrements ne filtrent aucune trame par eux-mêmes. Le comportement réel dépend du code actif, de la configuration effectivement chargée, de la sémantique interprétée par la version installée, des ACL présentes dans le matériel, de l’état des LAG, des sessions BGP et des chemins alternatifs utilisables.

L’incident révèle l’écart possible entre ces deux plans. Un port enregistré comme non-LACP peut être correctement décrit dans le système d’approvisionnement tout en laissant passer une trame LACP si la règle attendue n’est pas créée, appliquée ou interprétée comme prévu. Une ACL peut être visible dans une configuration sans produire le comportement matériel attendu. Une politique peut donc être administrativement correcte et techniquement inefficace.

La responsabilité doit relier l’enregistrement à une observation. Pour chaque port, il faut pouvoir répondre: quelle politique est attendue ? Quelle règle a été générée ? Quelle règle est réellement installée ? Comment le matériel traite-t-il une trame de test ? Une alarme apparaît-elle si la trame est reçue ? Le résultat demeure-t-il identique après une mise à niveau ou un retour arrière ?

Les mesures correctives annoncées

AMS-IX a annoncé plusieurs actions après l’incident: appliquer des ACL aux liaisons non-LACP, améliorer la création des ACL dans la pile d’approvisionnement, examiner les filtres LACP sortants sur Juniper et Extreme, étudier des alertes pour les BPDU de protocoles lents et revoir les règles de communication de sa liste technique.

Ces actions répondent aux surfaces de contrôle révélées par l’événement. Étendre les filtres aux ports non-LACP traite la frontière initiale. Modifier l’approvisionnement vise à rendre la politique moins dépendante d’une intervention ponctuelle. Réexaminer les ACL sur plusieurs constructeurs reconnaît que la même intention peut produire des résultats différents. Les alertes peuvent raccourcir le temps entre une émission anormale et son diagnostic. La révision des communications peut aider les entités à déplacer leur trafic plus tôt.

Il faut néanmoins les décrire comme des engagements annoncés par AMS-IX. Le paquet public ne contient pas une vérification indépendante démontrant que chaque action est restée efficace dans toutes les configurations actuelles. Il ne fournit pas non plus les résultats complets d’essais de non-régression, les conclusions détaillées des constructeurs ou les preuves de retour arrière.

Une réparation durable ne se juge pas à l’existence d’une liste d’actions. Elle se juge à des résultats reproductibles: la trame est arrêtée sur chaque type de port; la règle est générée et installée sur chaque plateforme; une divergence déclenche une alarme; les essais interconstructeurs réussissent sous pression; une mise à niveau ne modifie pas silencieusement la sémantique; et un retour à une version ou une configuration sûre a été exercé.

Communication et autorité de bascule

Pendant une perturbation d’interconnexion, la communication est un contrôle technique indirect. Les réseaux connectés ne peuvent décider de fermer une session ou de déplacer du trafic que s’ils disposent d’informations suffisamment précises: portée estimée, symptômes, heure de début, stabilité observée et risques liés au maintien des sessions.

Une communication trop générale peut conduire certains opérateurs à attendre alors qu’une bascule serait préférable. Une alerte trop alarmiste peut provoquer des retraits inutiles. La qualité attendue n’est pas la certitude immédiate, souvent impossible, mais une séparation claire entre faits observés, hypothèses, actions recommandées et inconnues.

L’autorité compte autant que l’information. Un réseau peut posséder un chemin alternatif mais être incapable de l’utiliser rapidement si seul un petit nombre de personnes peut modifier les politiques ou si aucune automatisation contrôlée n’est prévue. La continuité dépend alors d’une chaîne de décision, pas seulement de la topologie.

Un exercice de résilience devrait donc tester la technique et l’organisation: réception d’une alerte, validation de la dégradation, fermeture ou dépriorisation d’une session, observation du chemin de remplacement, contrôle de la capacité, puis retour au fonctionnement normal. Le résultat attendu est une preuve horodatée, pas une affirmation générale selon laquelle le réseau « dispose de redondance ».