Résumé

  • La RFC 4456 autorise un réflecteur à retransmettre des routes iBGP, exception indispensable au passage à l’échelle. ORIGINATOR_ID et CLUSTER_LIST empêchent cette exception de devenir une boucle.
  • Une égalité locale donne au récepteur le pouvoir d’ignorer l’annonce. Ce pouvoir est correct dans un cluster redondant ; une identité réutilisée hors de ce périmètre transforme une route légitime en faux retour.
  • La preuve doit réunir attributs reçus, motif exact de rejet, rôles client/non-client, RIB d’entrée et de sortie, FIB et paquets. L’état Established ne prouve rien sur la survie d’un NLRI.

Une identité copiée entre deux régions

Imaginons deux domaines de réflexion, chacun servi par une paire redondante. Dans le domaine est, les deux réflecteurs partagent volontairement 10.0.0.42. C’est le bon usage : ils appartiennent au même cluster logique et doivent reconnaître une route déjà traitée par leur partenaire.

Une automatisation déploie ensuite la même valeur sur la paire ouest. Le dessin hiérarchique, lui, n’a pas changé. Une route d’un client oriental arrive à l’ouest avec 10.0.0.42 dans son historique de réflexion. Le réflecteur local compare, conclut que l’information est revenue dans son cluster et l’ignore.

Le préfixe n’est ni mal formé ni désautorisé. TCP reste ouvert, les KEEPALIVE circulent et l’origine est encore présente. Le défaut est stable : une seule valeur a déclaré égaux deux ensembles qui ne l’étaient pas. Un tableau de bord centré sur les sessions décrit alors une infrastructure saine au moment même où la portée interne s’est rétrécie.

Pourquoi la réflexion a besoin d’un garde-fou

Le comportement iBGP ordinaire interdit de retransmettre à un pair interne une route apprise d’un autre pair interne. Sans cette règle, une information pourrait circuler sans que l’AS_PATH fournisse la protection utilisée entre AS. Mais l’interdiction oblige les locuteurs à former un maillage complet.

La réflexion remplace ce maillage par des rôles. Une meilleure route reçue d’un non-client est envoyée aux clients. Celle reçue d’un client peut être envoyée aux clients et aux non-clients. La relation n’est pas négociée : chaque équipement dépend d’une configuration locale. Deux sessions peuvent donc fonctionner tout en incarnant des cartes différentes du réseau.

Le protocole a besoin de mémoire pour borner cette dérogation. ORIGINATOR_ID, attribut optionnel non transitif de type 9, conserve l’identifiant BGP du locuteur à l’origine de la route dans l’AS. Un routeur qui y lit son propre identifiant doit ignorer l’annonce.

CLUSTER_LIST, attribut optionnel non transitif de type 10, conserve une séquence ordonnée d’identités de cluster. Chaque RR ajoute son identité en tête avant de réfléchir. S’il retrouve sa valeur locale dans une annonce entrante, il doit considérer que l’information a déjà traversé ce domaine.

Ces champs ne prouvent aucune propriété, aucune adresse et aucune origine cryptographique. La RFC 6286 exige seulement que le BGP Identifier soit une valeur non nulle de quatre octets, unique dans l’AS ; elle n’a même pas à être une adresse IPv4 attribuée. Une notation ressemblant à une adresse reste un symbole de protocole.

Le partage légitime et la collision destructrice

Deux réflecteurs redondants d’un même cluster peuvent et doivent parfois partager une identité. La RFC 4456 prévoit ce cas pour éviter que les partenaires se renvoient la même information. L’égalité exprime alors une décision d’architecture : ces machines représentent un même périmètre de réflexion.

Hors de ce périmètre, la même valeur fabrique une équivalence. Une fusion d’inventaires, une adresse de routeur recyclée, un modèle appliqué au mauvais site ou une option par voisin peuvent étendre silencieusement la portée. Le code n’a accès ni au schéma d’architecture ni à l’intention humaine ; il voit une comparaison vraie.

Le risque existe aussi pour ORIGINATOR_ID. Deux BGP Identifiers identiques dans un AS peuvent faire croire au second routeur que la route du premier est son propre retour. Il n’est pas nécessaire qu’un paquet ait déjà bouclé. La collision suffit à exercer le droit de suppression.

La bonne règle n’est donc pas « tout doit être unique partout ». Le BGP Identifier doit être unique à l’échelle de l’AS. L’identité de cluster doit correspondre à une classe d’équivalence explicite : commune aux RRs réellement redondants, distincte sur tout trajet qui relie des domaines différents.

Rejet sémantique, erreur de forme et sélection

Une liste bien formée contenant la valeur locale n’est pas un message corrompu. Elle déclenche une décision sémantique anti-boucle. La RFC 7606 traite une autre situation, celle d’un attribut mal encodé. Les réunir sous un compteur « erreur UPDATE » détruit la causalité.

Même sans égalité, les attributs influencent le choix. ORIGINATOR_ID remplace l’identifiant de l’annonceur au départage concerné. Entre deux routes encore égales, la RFC 4456 préfère la liste de clusters la plus courte. Cette longueur ne mesure ni latence, ni distance physique, ni confiance. Elle décrit seulement le nombre de domaines de réflexion visibles dans cette représentation.

Une migration peut donc changer le meilleur chemin sans supprimer entièrement le préfixe. Contrôler seulement le total de routes manquerait ce déplacement. Il faut comparer les candidats, la raison du choix et la sortie vers chaque voisin.

ORR ne résout pas cette collision : il déplace le point de vue IGP utilisé par le réflecteur. ADD-PATH peut exposer plusieurs chemins, mais chacun reste soumis aux contrôles de boucle. Les RFC 3345 et 7964 concernent l’oscillation créée par la réduction d’information et les MED ; une fausse identité peut au contraire produire une absence parfaitement stable. Une session authentifiée protège les octets, pas la vérité de la carte de clusters.

La chaîne de preuve

L’inventaire minimal relie AS, VRF, famille d’adresses, identifiant BGP, identités de cluster globale et par voisin, rôle de la session, groupe de redondance, niveau hiérarchique, version logicielle et propriétaire du changement. Toute valeur partagée doit porter une justification de périmètre.

Pour le préfixe, conserver l’UPDATE reçu, ORIGINATOR_ID, la liste complète dans son ordre, les valeurs locales comparées et le verdict exact. Distinguer : erreur de syntaxe, égalité d’origine, égalité de cluster, refus par politique et perte au meilleur chemin. Continuer jusqu’au Loc-RIB, à l’Adj-RIB-Out par voisin, au RIB du destinataire, au FIB et aux paquets.

Cette méthode suit des couches de réalité différentes. La configuration annonce une intention. L’UPDATE porte un état. Le test local exerce une autorité. Le RIB retient un candidat. Le FIB programme un chemin. Le paquet révèle enfin le service rendu. Aucun niveau ne remplace les autres.

Tester le graphe avant les identités

Avant une migration, écrire le graphe dirigé client/non-client et les groupes réellement redondants. Simuler chaque trajet valable ; aucune route ne doit rencontrer prématurément son origine ou son propre cluster. Lancer des canaris depuis chaque classe de client et à travers chaque niveau, famille, fournisseur et version.

Vérifier l’ordre des valeurs, pas seulement leur présence. Chaque réflexion ajoute l’identité attendue devant l’historique existant. Suspendre si un cluster sans lien partage une valeur, si une route protégée disparaît sans événement de session ou si deux versions construisent des listes différentes. Revenir en arrière si la portée baisse, si une vraie boucle n’est plus bloquée ou si les paquets quittent l’enveloppe autorisée.

Le retour arrière inclut la réévaluation et la réannonce. Restaurer une ligne de configuration sans prouver que les RIB aval ont remplacé l’ancien état ne restaure pas le service.

Sources