Résumé

  • Une confédération BGP expose un AS Confederation Identifier unique tout en conservant plusieurs domaines Member-AS. Les segments AS_CONFED_SEQUENCE et AS_CONFED_SET tracent le parcours interne, puis doivent disparaître avant toute annonce à un voisin extérieur.
  • L’effacement protège l’interopérabilité et l’autonomie de l’architecture interne ; il ne prouve ni l’unité des politiques ni la continuité du forwarding. LOCAL_PREF, MED, NEXT_HOP, les ensembles de candidats et les identités de membre peuvent changer sans modifier le chemin public.
  • Une direction responsable n’autorise cette compression qu’avec un registre des membres, des observations avant et après policy, une preuve FIB et paquets, ainsi qu’un plan de migration qui restaure l’ancienne identité et l’ancien état de routage.

Imaginons une opération nocturne. Delta, routeur de bordure du Member-AS 65021, doit rejoindre le Member-AS 65031. Les deux appartiennent à la confédération AS 64500. L’objectif commercial est raisonnable : aucun fournisseur, client ni partenaire de peering ne devrait reconfigurer son réseau parce qu’une équipe interne redessine ses domaines d’exploitation.

À 01 h 40, le contrôleur confirme la nouvelle configuration. Les sessions de Delta avec l’extérieur sont vertes. Un collecteur public voit toujours 64500. L’autorisation d’origine publique n’a pas changé. Le tableau de bord de migration conclut que l’identité est stable.

Echo, voisin interne de Delta, possède encore l’ancienne carte. Delta se présente comme 65031 ; Echo attend un membre 65021. Selon le logiciel et la configuration, l’adjacence ne se forme pas ou un chemin de secours survit avec un NEXT_HOP inaccessible depuis le nouvel IGP. Ailleurs, l’ensemble de routes comparées par MED n’est plus le même. Le peer client reste Established, mais le préfixe utile n’atteint pas la FIB.

L’incident est fictif ; les frontières protocolaires ne le sont pas. Le chemin public n’a pas omis accidentellement le détail décisif. RFC 5065 exige justement que le parcours Member-AS soit retiré avant l’export externe. La confédération a tenu sa promesse envers Internet. L’organisation n’avait pas tenu la sienne envers ses opérateurs : conserver la réalité que l’abstraction publique ne peut plus montrer.

Trois identités qu’il ne faut jamais confondre

Une AS Confederation est un ensemble de systèmes autonomes membres présenté aux speakers extérieurs comme un seul AS. Son AS Confederation Identifier constitue l’identité visible dans les échanges externes. Chaque Member-AS possède en parallèle un Member-AS Number employé à l’intérieur de la confédération.

Le routeur utilise l’identifiant de confédération dans l’OPEN et dans l’AS_PATH adressés à un véritable voisin externe. Entre membres, il emploie son numéro de membre. Les sessions entre Member-AS ont la mécanique EBGP, mais plusieurs règles de décision les traitent comme internes au même ensemble administratif.

Cette architecture répond d’abord à une contrainte d’échelle. Sans route reflection ni confédération, un grand AS impose un full mesh IBGP. La subdivision réduit le nombre de connexions à l’échelle globale et permet de créer des surfaces de policy régionales ou organisationnelles. Chaque membre conserve néanmoins son propre besoin de maillage ou de reflectors, son IGP et parfois une équipe différente.

L’identifiant public ne certifie donc pas une réalité indivisible. Il offre aux voisins la déclaration minimale dont ils ont besoin : cet ensemble parle sous AS 64500. Il ne dit pas quel membre a appris la route, qui a modifié LOCAL_PREF, quel domaine sait résoudre le next hop, ni quelle carte a programmé le trafic. La coordination publique devient dangereuse lorsqu’elle est promue en preuve d’autorité interne.

Le protocole mémorise le parcours avant de le retirer

AS_CONFED_SEQUENCE contient une suite ordonnée de Member-AS traversés. AS_CONFED_SET représente un ensemble non ordonné, notamment lorsque des informations sont agrégées. Lorsqu’un speaker transmet une route à un membre voisin, il ajoute son propre numéro en tête de la séquence ou crée le segment.

Cette histoire sert à empêcher les boucles. Un membre qui retrouve son propre numéro dans un segment de confédération traite la route comme s’il avait vu son AS dans un AS_PATH ordinaire. De même, la présence de l’AS Confederation Identifier local signale un retour vers l’identité externe du même ensemble.

À la sortie, le border speaker doit supprimer tous les segments AS_CONFED_SEQUENCE et AS_CONFED_SET. Il traite ensuite le chemin restant et préfixe l’identifiant de confédération comme AS_SEQUENCE normal. RFC 6793 interdit aussi ces segments dans AS4_PATH : la transition vers les ASN à quatre octets ne doit pas divulguer indirectement l’histoire interne.

Le collecteur externe reçoit alors une affirmation correcte mais limitée. Il sait que la route a traversé AS 64500 ; il ne peut pas reconstruire la suite 65021, 65017 et 65009. Cette opacité évite qu’une réorganisation interne oblige le reste d’Internet à refaire ses policies. Elle crée en retour une obligation locale : enregistrer le dernier chemin complet avant sanitisation.

Dire que le détail est masqué n’est pas dire qu’il est sans importance. Une abstraction ne détruit pas son objet. Elle réduit la quantité d’information offerte à un autre domaine de décision. La preuve publique est donc adéquate pour contrôler l’export public et inadéquate pour attribuer une panne interne.

La qualité de membre s’exécute

Une mention dans un document d’architecture ne forme aucune adjacency. Les deux extrémités doivent configurer des identités et une appartenance cohérentes. La documentation Juniper actuelle avertit que l’adjacence ne se forme pas lorsque les voisins ne sont pas d’accord sur son appartenance à la confédération.

Le chemin lui-même impose d’autres invariants. Une UPDATE reçue d’un autre Member-AS doit commencer par AS_CONFED_SEQUENCE. Un speaker ne doit jamais envoyer un segment de confédération à un voisin véritablement extérieur. Tout participant doit comprendre les nouveaux types de segment, tandis qu’un speaker externe n’en a pas besoin puisqu’il ne doit jamais les recevoir.

Le traitement d’erreur moderne peut préserver la session. RFC 7606 demande généralement treat-as-withdraw pour un AS_PATH malformé. La route concernée disparaît tandis que TCP, KEEPALIVE et l’état Established demeurent. Sur un lien interne, des décisions divergentes peuvent ensuite causer une perte de reachability, un trajet sous-optimal ou une boucle durable.

Le test de santé doit ainsi suivre une chaîne plus longue : identité locale configurée, identité attendue du peer, OPEN observé, type de segment reçu, résultat de policy, présence dans Adj-RIB-In et Loc-RIB, résolution récursive, installation FIB et paquets. La lumière verte de la session n’en couvre qu’une étape.

Un lien EBGP soumis à des règles internes

Le terme « confed EBGP » comprime lui aussi trop d’idées. Entre deux Member-AS, BGP établit une relation externe. Pour la sélection, RFC 5065 exige pourtant qu’une route apprise d’un membre de la même confédération soit traitée comme interne lors de la comparaison IBGP/EBGP.

Les segments de confédération ne comptent pas dans la longueur d’AS_PATH. LOCAL_PREF peut franchir la frontière. NEXT_HOP et MED peuvent rester inchangés. Ces permissions donnent à la confédération la capacité d’appliquer une politique commune malgré les sous-domaines.

Elles introduisent aussi des dépendances. Si les membres partagent un IGP, le next hop conservé peut être joignable partout. Avec des IGP indépendants, il peut devenir une adresse sans route récursive. RFC 5065 prévoit alors une modification explicite de NEXT_HOP par policy. Une route valide au niveau BGP peut donc rester absente du matériel.

Pour MED, le comportement normal ignore les segments de confédération afin d’identifier le premier AS_SEQUENCE externe. Certaines implémentations permettent d’autres comparaisons entre chemins de membres. Le résultat dépend de la liste de candidats réellement visible, des réglages et de la topology. Deux routeurs peuvent recevoir le même attribut sans décider de la même route.

Cette asymétrie justifie un contrat d’exploitation précis. Il faut documenter non seulement le type de session, mais aussi les attributs conservés, les familles concernées, la reachability du next hop, les règles de comparaison et le propriétaire de chaque décision.

Une oscillation interne peut rester invisible dehors

RFC 5065 prévient qu’une mauvaise configuration peut dupliquer les annonces, consommer CPU et mémoire, provoquer des flaps et retarder la convergence. Les confédérations, comme les route reflectors, peuvent également présenter des candidats différents selon le point de décision. Avec certains MED, RFC 3345 montre qu’un cycle permanent devient possible.

Un reflector choisit une route, ce choix modifie celle que voit un autre membre, et la nouvelle décision fait réapparaître le candidat précédent. Le système ne converge pas nécessairement vers un état fixe. Pourtant, le peer externe ne voit que la route qui passe la dernière policy d’export après suppression des segments internes.

Des métriques IGP conçues selon la topologie, un tie-break cohérent, des filtres de doublons et une distribution plus complète des candidats peuvent réduire le risque. Aucun de ces moyens ne prouve à lui seul que tous les points de décision disposent du bon univers de routes.

L’observation doit conserver l’ensemble candidat, l’origine de chaque route, le MED comparable, la raison de rejet et l’époque de topology. Une simple série temporelle du best path ne suffit pas : elle montre les gagnants successifs, pas les informations dont chaque speaker disposait au moment de choisir.

Les ASN privés ne sont uniques que dans un périmètre

De nombreux opérateurs choisissent des ASN privés pour les Member-AS. RFC 6996 réserve 64512–65534 et 4200000000–4294967294. Ce choix est logique lorsque les numéros sont destinés à disparaître au border externe, mais le mot « privé » ne signifie pas « universellement unique ».

Une acquisition peut réunir deux réseaux ayant chacun un Member-AS 65021. Tant qu’ils restent isolés, il n’existe aucun conflit. Dès qu’un interconnect temporaire rapproche les scopes, la même valeur peut désigner deux owners, deux IGP et deux policies. Loop detection, filtres AS_PATH et journaux deviennent ambigus.

Le registre interne doit associer numéro, propriétaire, région, IGP, cluster RR, AFI/SAFI, capacités quatre octets et date de retrait. Une due diligence de réseau compare ce registre avant de brancher les infrastructures. Si un conflit apparaît, le renumérotage doit posséder son propre canary, une période d’observation et un rollback.

Le mécanisme remove-private ne remplace pas cette discipline. La documentation Juniper indique qu’il intervient après le retrait des Member-AS de confédération. Le premier filtre des valeurs privées dans un chemin externe ordinaire ; le second retire des types de segments internes selon RFC 5065. Un résultat public propre ne démontre pas lequel a fonctionné.

La preuve doit précéder la sanitisation

Pour chaque adjacency et AFI/SAFI, le ledger minimal contient Member-AS local, Member-AS attendu, identifiant de confédération, capacités négociées, segments bruts reçus et envoyés, version de policy, LOCAL_PREF, MED, NEXT_HOP, motif du best path et action d’erreur.

Il faut ensuite relier les étapes : Adj-RIB-In pre-policy, Adj-RIB-In post-policy, candidats Loc-RIB, Adj-RIB-Out vers le membre suivant, puis Adj-RIB-Out public après suppression des segments. Les hashes de topology et de policy rattachent la route à l’état exact qui l’a évaluée.

Enfin viennent la résolution récursive, la FIB ou l’ASIC et le paquet. Un segment parfait ne rend pas le next hop joignable. Une FIB présente ne garantit pas le chemin prévu. Le collecteur public confirme la dernière déclaration ; il ne constitue pas un témoin indépendant de la décision interne effacée.

Les alertes doivent viser les divergences : identité OPEN différente de la configuration, segment confed reçu d’un externe, segment absent entre membres, collision d’ASN privé, treat-as-withdraw sans chute de session, changement du best path sans changement public et cycle répété du même ensemble MED.

Migrer un Member-AS comme un protocole

Changer le numéro d’un membre modifie le segment préfixé, l’identité de loop detection, les règles de policy, les dimensions de telemetry et parfois le domaine de reflection. La classification des sessions peut passer d’intra-membre à inter-membre ou d’inter-membre à externe. Ce n’est pas une retouche cosmétique.

Le plan commence par une matrice ancien-vers-nouveau couvrant routeurs, neighbors, policies, communities, collectors, alertes et owners. Il prouve l’unicité du futur numéro dans tous les scopes qui pourront se rencontrer et inventorie les capacités confédération et quatre octets.

Le canary se limite à une frontière redondante, une AFI/SAFI et quelques préfixes. Avant et après, l’équipe compare OPEN, segments exacts, candidats, décision, recursion, FIB et paquets dans les deux sens. Elle attend assez longtemps pour voir les effets différés des reflectors et les cycles MED.

Le rollback restaure le numéro, la liste de membres, le type de peer, les policies, la relation RR, les labels et l’état de route. S’il ne sait remettre que le texte de configuration, il ne restaure pas le système. S’il a besoin du chemin public pour deviner le passé interne, il n’a jamais été un rollback vérifiable.