Le voisin BGP n’était pas le prochain saut : l’autorité discrète des serveurs de routes d’IXP

Résumé

• Le serveur de routes d’un point d’échange est un courtier de joignabilité, pas un routeur de transit. RFC 7947 lui demande donc de conserver le NEXT_HOP du participant et recommande de ne pas insérer son propre AS dans l’AS_PATH.
• Le client reçoit légitimement une route dont le voisin de session n’est ni le premier AS du chemin ni le prochain saut. L’exception au contrôle du premier AS doit rester limitée aux seuls serveurs vérifiés ; elle ne remplace ni les filtres d’importation ni la détection de boucle.
• Une preuve complète relie l’annonce d’origine, les validations du courtier, la vue calculée pour le destinataire, l’Adj-RIB-Out, l’Adj-RIB-In du client, la résolution de voisinage, la FIB et les paquets. L’état « Established » ne prouve qu’une session.

Le mauvais voyant était vert

Imaginons un IXP de laboratoire utilisant des adresses et numéros réservés à la documentation. Le réseau A annonce un préfixe témoin à deux serveurs de routes. Le réseau B reçoit cette route par une session eBGP établie avec le premier serveur. Dans l’UPDATE, l’AS_PATH commence par l’ASN de A et le NEXT_HOP contient l’adresse de A sur le LAN de peering. L’ASN du serveur n’est pas ajouté.

Un modèle de configuration générique impose que le premier AS du chemin soit celui du voisin eBGP. B rejette donc la route. L’opérateur désactive ce contrôle uniquement pour l’adresse certifiée du serveur de routes. La route est acceptée, sélectionnée, puis la FIB pointe vers A. Les paquets traversent le commutateur de l’IXP entre B et A ; ils ne passent pas par le serveur qui a transmis l’UPDATE.

Le second serveur de routes reste joignable et sa session est également établie. Pourtant, il ne transmet pas le témoin à B. Une règle d’export propre à B, ou un calcul de meilleure route réalisé avant cette règle, a masqué l’autre chemin disponible. La redondance des machines est intacte ; la redondance du service ne l’est pas.

Ce scénario est synthétique. Il révèle quatre identités que les diagnostics paresseux confondent : le pair TCP/BGP, l’AS placé à gauche de l’AS_PATH, l’adresse NEXT_HOP et le système réellement traversé par les paquets.

Un courtier qui agit sans transporter

Dans un point d’échange, le maillage complet de sessions bilatérales devient coûteux à mesure que le nombre de participants augmente. Le serveur de routes permet à chacun d’échanger des informations de joignabilité avec de nombreux réseaux au moyen d’un petit nombre de sessions.

Cette simplification ne rend pas le serveur neutre. Il reçoit des routes, les valide, choisit parfois entre plusieurs candidats, applique des règles propres à chaque client et redistribue un résultat. Il exerce bien une fonction de contrôle.

Mais il ne transporte pas le trafic correspondant. RFC 7947 distingue ainsi le serveur de routes d’un routeur et d’un collecteur. Le collecteur reçoit des flux BGP pour l’observation ; le serveur d’IXP intervient dans la distribution opérationnelle. Le routeur de transit, lui, se trouve sur le chemin des paquets. Employer un même mot pour ces trois fonctions conduit à demander les mauvaises preuves.

L’AS_PATH n’est pas la liste de toutes les machines ayant manipulé une annonce. Il décrit le chemin d’AS associé à la joignabilité et sert à la sélection, aux politiques et à la prévention des boucles. Ajouter l’AS du courtier pour refléter sa présence dans la session donnerait une apparence familière, mais une histoire de transfert fausse.

La transparence modifie les règles ordinaires d’eBGP

Le comportement de base de RFC 4271 prévoit qu’un locuteur externe ajoute son AS lors d’une annonce. RFC 7947 recommande au serveur de routes de ne pas le faire par défaut et de ne pas altérer l’AS_PATH sans configuration explicite. La raison n’est pas esthétique : un AS supplémentaire peut changer une préférence ou déclencher une politique chez le destinataire.

Pour NEXT_HOP, l’exigence est plus nette encore. Le serveur doit conserver l’adresse fournie. Si A annonce le préfixe, le trafic de B doit joindre le routeur de A sur le tissu commun. Réécrire cette adresse vers le serveur de routes attirerait les paquets vers une machine qui n’a pas vocation à les transférer.

Cette transparence est une discipline active. Le serveur peut toujours filtrer l’annonce, traiter une communauté selon le contrat de l’IXP, sélectionner un chemin et construire une vue différente pour chaque client. Son influence n’est simplement pas inscrite comme un saut de transfert.

Il faut donc deux registres. Les attributs BGP portent les éléments utiles à la décision et au transfert. Les journaux et RIB du serveur documentent l’intervention du courtier. Une route propre ne prouve pas l’absence d’intermédiation ; un journal de session ne prouve pas le chemin des paquets.

L’exception au premier AS doit avoir une frontière

Le contrôle de cohérence du premier AS vérifie habituellement que le chemin reçu commence par l’ASN du voisin externe. Il détecte des erreurs utiles dans une relation bilatérale ou de transit. Un serveur transparent fait volontairement échouer cette égalité.

RFC 7947 exige donc qu’un client puisse désactiver ce contrôle et recommande un réglage par pair. La portée fait toute la différence. L’exception s’applique aux adresses de serveurs de routes obtenues auprès de l’IXP, non à un modèle partagé par tous les voisins.

Une désactivation globale transformerait une adaptation précise en perte générale de validation. À l’inverse, conserver le réglage ordinaire sur le serveur produit une session apparemment saine qui rejette systématiquement les routes utiles.

Accepter un premier AS différent ne signifie pas accepter n’importe quoi. Le client garde ses limites de préfixes, ses règles d’importation, ses contrôles d’origine et la détection de son propre ASN dans le chemin. Le serveur propose une vue ; il ne reçoit pas la souveraineté sur la Loc-RIB du participant.

Une politique par client peut cacher le chemin de secours

Les participants utilisent des communautés, des données de registre ou un portail d’IXP pour demander qu’un préfixe soit diffusé à certains pairs et pas à d’autres. Ce pouvoir local est l’une des raisons d’adopter le service.

Mais l’ordre du calcul peut produire du « path hiding ». Supposons que le serveur connaisse deux chemins. Il sélectionne globalement celui de A. La politique de B interdit ensuite A. Si le serveur supprime seulement ce résultat à l’export, B ne reçoit rien, même si le second chemin aurait respecté sa politique.

Chaque étape prise isolément semble correcte : meilleure route valide, filtre valide, sortie vide. Le défaut vient de l’emploi d’une perspective commune pour répondre à une question propre à B.

RFC 7947 présente une Loc-RIB par client comme solution portable : appliquer les filtres avant de choisir la meilleure route pour ce destinataire. Certaines implémentations optimisent les états communs ; d’autres peuvent transmettre plusieurs chemins avec des mécanismes de diversité ou ADD-PATH. Dans ce dernier cas, le RFC recommande au serveur un usage en émission seulement vers les clients, afin de ne pas accepter en retour leurs chemins inactifs comme nouvelles entrées.

Le nom d’une option n’est pas une preuve. Il faut créer deux candidats, interdire le préféré pour un client et observer si l’alternative autorisée apparaît réellement dans son Adj-RIB-In.

Le NEXT_HOP intact concentre la validation en amont

Conserver le prochain saut permet le transfert direct. Cela permet aussi à un participant mal configuré de nommer l’adresse d’un autre participant. Si le courtier relaie l’annonce, plusieurs réseaux peuvent envoyer leurs paquets au mauvais routeur.

RFC 7948 recommande que le serveur compare le NEXT_HOP à l’adresse du client annonceur et rejette un écart entre AS. Une exception au sein du même AS peut servir une organisation disposant de plusieurs ports. La documentation d’IXP Manager montre ce contrôle dans une chaîne qui vérifie également le chemin, les préfixes, l’IRR et la RPKI.

Cette position est logique : après agrégation de centaines de clients sur une session, le destinataire ne peut pas facilement reconstruire l’autorisation de chaque prochain saut. Le courtier est le point qui connaît encore l’identité de l’annonceur.

Toutefois, une adresse autorisée peut rester injoignable. Une panne du tissu peut être non transitive : B atteint le serveur, le serveur atteint A, mais B n’atteint pas A. Les sessions BGP restent établies pendant que la résolution ARP ou NDP échoue. Une sonde vers le serveur de routes contrôle donc le plan de contrôle, pas le chemin de données.

Deux serveurs ne suffisent pas à faire deux services équivalents

RFC 7948 recommande plusieurs serveurs sur le domaine partagé. Ils peuvent employer des logiciels différents pour réduire le risque d’un défaut commun. La diversité est utile, mais elle rend l’équivalence observable indispensable.

Deux sessions actives peuvent s’appuyer sur des générations de politique, données IRR, états RPKI ou calculs par client différents. Deux totaux de préfixes identiques peuvent cacher un NEXT_HOP, un AS_PATH ou une communauté différente pour une même route.

Le contrôle pertinent compare, pour chaque client et chaque famille d’adresses, les NLRI et leurs attributs exacts. Toute différence attendue doit être expliquée. La configuration exécutée doit porter une identité de génération reliant l'intention à chaque processus vivant.

La redondance se mesure au résultat fourni, pas au nombre de boîtiers. Deux instances opaques du même état fautif n’apportent pas d’indépendance ; deux implémentations qui divergent sans explication n’apportent pas de service prévisible.

Sept preuves pour une seule route

La chaîne minimale traverse plusieurs autorités :

1. l’Adj-RIB-Out de A ou une capture montre l’annonce originale ;
2. l’Adj-RIB-In et les journaux du serveur montrent la réception et la validation ;
3. la vue propre à B et la version de politique expliquent la sélection ;
4. l’Adj-RIB-Out du serveur montre les attributs proposés à B ;
5. l’Adj-RIB-In de B montre ce qui a traversé la session ;
6. la route sélectionnée, la FIB et la table de voisinage montrent le prochain saut programmé et sa résolution ;
7. des compteurs, captures ou sondes montrent les paquets allant directement de B à A.

Chaque preuve répond à une question différente. La table maîtresse du serveur ne remplace pas la vue de B. Un looking glass montre souvent un résultat sélectionné, pas les candidats rejetés. Une FIB correcte à un instant ne reconstruit pas l’ordre d’événements d’une panne transitoire. Les horodatages et identités de politique doivent donc voyager avec les observations.

La responsabilité suit la même chaîne. A répond de l’annonce. L’opérateur du serveur répond de la validation et de l’exécution fidèle de la politique par client. B répond de sa décision d’importation. L’IXP répond de la connectivité du tissu commun. Aucun acteur ne peut prouver son propre résultat avec le voyant d’un autre.

Une mise en service par contradictions contrôlées

Le test initial doit précisément exercer ce que l’architecture rend inhabituel. À partir des données officielles de l’IXP, on identifie ASN, adresses, familles, capacités et communautés des serveurs. L’exception au premier AS est attachée uniquement à ces voisins.

Un préfixe témoin permet ensuite d’enregistrer le chemin et le prochain saut d’origine, puis de vérifier successivement validation, vue par client, Adj-RIB-Out et réception. Le test réussit lorsque l’AS de l’annonceur reste à gauche, que son adresse reste NEXT_HOP, que l’AS du serveur n’est pas ajouté par convenance et que les paquets évitent le courtier.

Il faut aussi tester le refus : autoriser B et interdire C, inverser le choix, proposer deux chemins dont le préféré est interdit, envoyer un prochain saut appartenant à un autre AS et exiger son rejet. IPv4 et IPv6 doivent être contrôlés séparément.

Enfin, les deux serveurs sont comparés attribut par attribut. Un écart inexpliqué arrête l’élargissement. Le retour arrière restaure la politique précédente et déclenche une réévaluation ou un retrait contrôlé ; supprimer une commande ne démontre pas que les routes déjà apprises ont disparu.

Sources et limites

Le mécanisme repose sur RFC 7947, avec RFC 4271 comme comportement BGP de référence. RFC 7948 décrit les enjeux d’exploitation, de redondance, de fuite et de détournement du prochain saut. RFC 7911 et RFC 6774 documentent les mécanismes de chemins multiples cités pour limiter le masquage.

Les exemples d’implémentation proviennent de la documentation de FRRouting, de BIRD et d’IXP Manager. Les pages officielles d’AMS-IX et de LINX montrent des pratiques actuelles, sans prouver l’état d’un IXP non nommé. Le scénario d’ouverture reste un cas de laboratoire.