Résumé

  • Dans une note du 26 juin 2025, MIX explique qu'un opérateur bien dimensionné devrait absorber la perte d'un IX grâce, notamment, à une capacité de transit surdimensionnée et à une stratégie de peering diversifiée [1].
  • MIX souligne aussi que des instabilités répétées créent un risque par la convergence des routes et la reconvergence du trafic, même si le LAN de peering n'est pas en soi un point unique de défaillance [1].
  • La documentation actuelle du route server de MIX décrit l'ASN 61968, des listes issues des IRR, des contrôles de chemin, le rejet des routes RPKI INVALID et des communautés permettant aux participants de choisir la diffusion [2].
  • Ces contrôles ne remplacent ni les chemins physiques diversifiés, ni la capacité de transit de secours, ni la preuve qu'une application reste accessible pendant le basculement.
  • Le registre donne l'identité et l'intention. Le verdict opérationnel vient des retraits de routes, du chemin effectivement choisi, du trafic déplacé et de la qualité de service observée.

La portée exacte de la position de MIX

MIX ne dit pas qu'un point d'échange ne peut jamais connaître d'interruption. Sa note affirme qu'un participant préparé ne devrait pas dépendre d'un seul LAN pour toute sa connectivité. Elle cite deux moyens concrets : conserver une capacité de transit suffisante et diversifier les lieux ou relations de peering [1]. La responsabilité de la continuité dépasse donc l'infrastructure commune de l'IX.

Un point d'échange fournit un environnement commun où des réseaux autonomes échangent routes et trafic. Chaque participant conserve ses propres choix de transit, de peering privé, de préférence BGP et de capacité. L'existence d'un second chemin ne garantit pourtant pas que ce chemin sera sélectionné à temps, qu'il acceptera tous les préfixes nécessaires ou qu'il supportera la charge déplacée.

Le second élément de la note est le plus important pour l'audit. MIX relie les interruptions fréquentes aux effets de convergence des routes et de reconvergence du trafic sur l'écosystème de routage [1]. Une topologie redondante peut donc rester fragile si les changements simultanés de sessions provoquent du churn, des décisions instables ou une congestion sur les sorties de secours.

Distinguer disponibilité du fabric et politique du route server

Le route server simplifie le peering multilatéral. Selon MIX, le service utilise l'ASN 61968. Les préfixes autorisés sont construits à partir de bases IRR; le premier ASN du chemin doit correspondre au participant; plusieurs classes d'ASN ou de routes invalides sont refusées; les routes dont la validation RPKI est INVALID sont rejetées [2]. Des communautés permettent aussi à un participant de limiter ou d'ajuster la diffusion de ses annonces.

Le trafic ne traverse pas le route server comme un routeur de transit. Il circule directement entre voisins sur le LAN, et l'ASN du route server n'apparaît pas dans l'AS_PATH [2]. Le RFC 7947 décrit ce modèle d'interconnexion multilatérale [4]. Cette séparation est essentielle : un filtre de route peut fonctionner correctement alors que le transport commun est indisponible; inversement, le LAN peut être disponible alors qu'une politique incorrecte bloque un chemin nécessaire.

Il faut donc auditer trois surfaces : le fabric de commutation partagé, le plan de contrôle multilatéral du route server, et les sessions bilatérales ou de transit de chaque participant. Une preuve sur l'une de ces surfaces ne suffit pas à conclure sur les deux autres.

Ce que MIX devrait pouvoir démontrer

L'opérateur de l'échange doit pouvoir reconstruire l'état des commutateurs, des liens internes, des ports membres et des processus de route server pendant une période de changement. Les éléments utiles incluent les erreurs d'interface, les événements de topologie, le comportement ARP ou Neighbor Discovery, les volumes de broadcast, la protection du plan de contrôle et l'étendue des sessions touchées.

Pour le route server, le dossier devrait relier les versions de politique, la fraîcheur des données IRR et RPKI, les routes acceptées ou rejetées, les mises à jour BGP et les communautés traitées. Les observations externes doivent compléter ces journaux, car un système de gestion peut rester vert alors qu'un participant voit une perte partielle ou une asymétrie.

Une clôture publique peut rester sobre. Elle peut indiquer la surface touchée, les limites temporelles, la classe de contrôle concernée, la portée pour les participants, la correction durable et le test négatif qui montre qu'une condition équivalente est désormais contenue. Elle n'a pas besoin de publier les configurations sensibles.

Ce que chaque participant devrait pouvoir démontrer

Le participant doit prouver qu'un changement sur l'IX n'est pas devenu une panne pour ses clients. Une simple capture montrant qu'une autre session BGP est établie ne suffit pas. Il faut un historique des routes et du trafic relié à des mesures de service.

Le dossier de routage doit montrer quelles routes apprises à l'IX ont disparu, quelles routes de transit, de PNI ou d'un autre échange sont devenues préférées, combien de temps la sélection a pris et quels préfixes sont restés sans alternative. Les données Adj-RIB-In, la décision locale et les routes annoncées permettent de distinguer l'absence d'un chemin de secours d'un chemin présent mais écarté par la politique.

Le dossier de capacité doit montrer la charge déplacée, la marge restante, les pertes de paquets et la latence. Le modèle doit couvrir un changement corrélé : de nombreux réseaux peuvent quitter le même échange au même moment. Une liaison de transit confortable en temps normal peut être insuffisante lorsque plusieurs flux convergent ensemble.

Enfin, des sondes DNS et applicatives externes doivent confirmer le résultat visible par l'utilisateur. La convergence BGP n'est qu'un mécanisme. Une route peut être présente alors qu'un pare-feu, un chemin retour ou une règle d'ingénierie du trafic empêche encore la transaction.

Sécurité des routes et continuité

Le rejet des routes RPKI INVALID documenté par MIX est un contrôle d'admission important [2]. Les listes IRR et les vérifications du chemin apportent d'autres contraintes. Le RFC 7454 rassemble des pratiques de sécurité BGP, et le RFC 9234 apporte les BGP Roles et l'attribut Only-to-Customer [5][6].

Ces mécanismes ne constituent pas une garantie universelle de disponibilité. Une route peut avoir une origine valide et être mal dimensionnée, mal propagée ou indisponible à cause du transport. À l'inverse, des données de registre obsolètes peuvent empêcher une route de secours légitime. Le bon contrôle n'est pas d'accepter largement pendant une urgence, mais de maintenir les autorisations et de tester les chemins de repli avant l'urgence.

Le registre comme grand livre

PeeringDB associe actuellement AS16004 à MIX S.r.L. - Milan Internet eXchange [3]. Cette continuité d'identité facilite le contact, le provisionnement et la vérification d'une relation. Elle ne dit pas quel paquet a circulé ni quelle route a été choisie.

C'est la surface Heng.lu de l'analyse : le registre est un grand livre et un mécanisme de continuité, pas un souverain qui garantit le réseau. La preuve exige de rapprocher l'identité, la politique prévue et l'état réellement exécuté. Si le registre, la configuration et les routes observées divergent, cette divergence doit être traitée comme un incident opérationnel.

Le paquet de preuves utile

Un dossier de reconvergence devrait contenir cinq blocs. Le premier décrit l'état prévu : topologie, rôles des sessions, politiques, routes autorisées et objectifs de capacité. Le deuxième fixe la chronologie du déclencheur et des actions. Le troisième conserve les chemins avant, pendant et après le changement. Le quatrième mesure le trafic et le service. Le cinquième documente la correction, le retour arrière et un exercice répété.

La conclusion doit rester limitée aux données disponibles. La note de MIX pose une attente raisonnable : un participant préparé ne transforme pas un seul LAN en dépendance absolue [1]. Pour rendre cette attente auditable, MIX et les participants doivent joindre leurs preuves par des horodatages, des identifiants de session et des mesures comparables. La redondance n'est pas un nombre de liens; c'est une transition vérifiée entre deux états du réseau.

Sources

  1. https://www.mix-it.net/en/the-peering-lan-is-not-inherently-a-critical-point-of-failure/
  2. https://www.mix-it.net/en/route-server/
  3. https://www.peeringdb.com/api/net?asn=16004
  4. https://www.rfc-editor.org/rfc/rfc7947.html
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://www.rfc-editor.org/rfc/rfc9234.html