Résumé

  • Un orateur BGP écoute TCP 179 et peut aussi initier. Si les deux côtés démarrent ensemble, deux connexions TCP distinctes peuvent représenter un seul peering ; RFC 4271 impose d’en fermer une.
  • La connexion initiée par l’orateur dont le BGP Identifier est le plus grand est conservée. Pour deux pairs externes ayant le même Identifier, RFC 6286 départage par le numéro d’AS le plus grand.
  • Ce classement est déterministe, pas authentifiant. Il faut des identifiants uniques et stables, une protection du transport et un canari capable de prédire la socket survivante.

À la fin d’une maintenance, chaque automatisation active son voisin. A ouvre vers B, B ouvre vers A. Les deux tentatives atteignent l’écoute opposée et produisent deux quadruplets inversés, deux espaces de séquence TCP, deux FSM BGP et deux OPEN.

Ce n’est pas l’ouverture simultanée de TCP, où des SYN croisés convergent vers une connexion. Ici, deux connexions complètes existent déjà. Leurs historiques ne peuvent être fusionnés ; les garder donnerait deux autorités à un même peering.

Choisir plutôt que laisser la latence décider

RFC 4271 définit la collision lorsque source et destination de la première connexion sont l’inverse de celles de la seconde pour les mêmes orateurs. L’OPEN révèle normalement le BGP Identifier distant et permet de relier les FSM.

Les valeurs sont comparées comme des entiers non signés de quatre octets. Seule demeure la connexion initiée par l’orateur dont l’Identifier est le plus élevé. Si l’identifiant local est inférieur, le système ferme sa connexion OpenConfirm existante et accepte celle initiée par le pair. Sinon, il ferme la nouvelle et garde l’existante.

« Nouvelle » et « existante » sont des perspectives locales opposées. Le classement commun fait pourtant converger les deux côtés sur le même transport. Un numéro supérieur ne rend pas un routeur plus important ; il fournit seulement un ordre stable.

RFC 4486 attribue le sous-code Cease 7, Connection Collision Resolution. Il explique la fermeture, mais ne prouve pas quelle socket a continué. Il faut suivre le quadruplet conservé jusqu’à OPEN, KEEPALIVE et aux routes.

Toute session parallèle n’est pas une collision

Deux mêmes routeurs peuvent avoir plusieurs peerings configurés par des paires d’adresses différentes. Une session de loopback et une session d’interface peuvent être des objets distincts. Regrouper par ASN puis supprimer tout sauf une détruirait une redondance voulue ; distinguer seulement par port éphémère masquerait une vraie collision.

L’inventaire doit associer adresse locale, adresse distante, instance de routage et politique de voisin. Les rôles actif et passif appartiennent aussi à TCP, pas à une hiérarchie permanente entre organisations. Une fois Established, le contenu BGP ne dépend pas de qui utilisait le port 179.

RFC 6286 a détaché l’identité de l’adresse IPv4

RFC 6286 redéfinit l’Identifier comme un entier non nul de quatre octets, unique dans l’AS, sans obligation d’être une adresse IPv4 unicast valide. Les valeurs choisies sous l’ancienne règle restent compatibles.

Deux AS distincts peuvent donc employer la même valeur. Lors d’une collision externe à Identifiers égaux, la connexion initiée par le plus grand numéro d’AS survit. Cette extension ne corrige pas deux identifiants égaux dans un même AS : ce cas viole l’unicité. Une confédération entière compte comme un AS.

Le partage externe n’est sûr que si les deux logiciels appliquent RFC 6286. Sans cette preuve, l’égalité peut produire des décisions différentes au moment même où l’accord doit être déterministe.

Un petit nombre traverse plusieurs surfaces

Le BGP Identifier intervient aussi dans l’agrégation, la réflexion de routes et certaines comparaisons finales. Le modifier n’est pas une retouche d’affichage : sessions, identité de routes réfléchies et continuité du diagnostic peuvent changer.

FRRouting expose bgp router-id et indique qu’en l’absence d’informations d’interface la valeur automatique peut rester 0.0.0.0, invalide. BIRD exige lui aussi une valeur non nulle et unique dans l’AS, avec un autre choix par défaut. Il faut donc fixer et inventorier la valeur effective par processus et VRF.

Les clones, remplacements et interfaces retardées créent des doublons ou des changements. Le registre opérationnel doit contenir AS, instance, valeur configurée, valeur observée dans OPEN, origine de l’attribution, domaine d’unicité et durée de vie.

Une résolution correcte peut boucler

Une collision unique, résolue rapidement, n’est pas une panne. Deux sockets apparaissent, le même choix est calculé, l’une disparaît, l’autre passe Established. Compter chaque Cease comme une indisponibilité crée du bruit.

Mais regarder uniquement le badge final masque les répétitions. Identifiant instable, pare-feu bloquant le gagnant, configuration divergente ou automatisation qui relance l’écoute peuvent former la boucle : deux connexions, élimination, échec du gagnant, nouvel essai. Chaque tour peut retirer des routes et augmenter CPU, journaux et état TCP.

Le classement assure l’accord sur la connexion qui devrait vivre ; il ne garantit ni pare-feu, ni authentification, ni KEEPALIVE. La télémétrie doit regrouper deux sockets et deux OPEN en un épisode, puis alerter sur la récidive, l’échec du gagnant et le mouvement de routes.

Ordonner n’est pas authentifier

L’Identifier reçu dans OPEN est une déclaration, pas une identité cryptographique. RFC 4272 décrit un scénario borné où un tiers capable d’achever la séquence TCP/BGP au bon moment et de choisir un Identifier gagnant pourrait faire supprimer la connexion légitime. Un OPEN arbitraire ne suffit pas : séquences TCP, timing, admission et authentification restent des barrières.

RFC 2385 fournit l’option TCP MD5 historiquement citée ; RFC 5925 définit TCP-AO et une gestion plus structurée des clés. Ces mécanismes protègent le transport sous une clé configurée. Ils ne valident pas les UPDATE et n’empêchent pas un pair légitime de dupliquer son Identifier.

Adresses couvertes, propriétaire des clés, rotation, période de chevauchement et alarmes doivent être gouvernés avec l’identifiant. Une migration de router ID et une rotation de clé mal coordonnées peuvent faire paraître fautive une sélection correcte.

Le canari annonce son résultat avant l’essai

Documenter d’abord une seule paire d’adresses, les AS, Identifiers et clés, et exclure un peering parallèle intentionnel. Faire ensuite initier les deux côtés ensemble dans un environnement borné, puis capturer SYN, quadruplets, OPEN et FSM.

Avant d’observer le résultat, calculer le gagnant par Identifier, ou par numéro d’AS dans le cas externe égal compatible. Saisir Cease 7, fermeture, élimination de FSM et compteurs de reprise. La connexion prédite doit atteindre Established.

Enfin, vérifier routes importées et exportées, absence de doublon ou de retrait inexpliqué, FIB et paquets si la continuité est revendiquée. Le retour rétablit un Identifier unique, des clés connues et une paire documentée ; il ne consiste pas à effacer le voisin jusqu’à obtenir un hasard favorable.