Quand le réseau se contredit lui-même

Six sources de vérité, une réponse, et que faire quand elles se contredisent

16 août 2026 Michel Wijnberg

Osprey apprend ce qu’il sait d’un réseau à six endroits :

Source	Vous dit
LSDB OSPF / IS-IS	ce que chaque protocole croit être la topologie
Table de routage SNMP	ce qu’un routeur a réellement installé
Adj-RIB-In BMP	ce que chaque voisin BGP a annoncé à ce routeur, et de qui
LLDP / CDP	ce qui est physiquement câblé à quoi
IP-MIB	quelle adresse vit sur quel port
Table des sessions BGP	qui est appairé avec qui

Chacune fait autorité sur quelque chose. Aucune ne fait autorité sur tout. Et elles ne s’accordent pas toujours.

La réponse naïve est de désigner un vainqueur global (« pour la topologie on croit LLDP, pour BGP on croit BMP ») et de passer à autre chose. Cela échoue sur le premier réseau où LLDP est périmé d’un côté d’un lien, ou bien où un bridge se glisse entre deux routeurs qui se croient directement connectés.

La réponse à laquelle je suis arrivé est plus terne et fonctionne : classer les preuves par affirmation, et enregistrer d’où vient chaque affirmation.

Ports : quatre situations, quatre réponses différentes

La forme la plus aiguë de ce problème est l’annotation d’une transition eBGP avec des ports physiques. Deux routeurs dans des systèmes autonomes différents ont une session. Quel câble traverse-t-elle ?

Osprey distingue quatre cas et donne à chacun un type de réponse différent :

Une paire de liens, pas d’alternative par fabric. Ports énoncés comme un fait :

jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2

Liens parallèles. La paire n’est pas déterminée, donc il n’en revendique aucune :

3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)

Les deux bordures sur un bridge partagé, sans lien direct. Il rapporte la présence du bridge avec les ports de raccordement, l’affirmation qu’un chemin existe à travers lui, jamais l’affirmation que cette session l’emprunte :

shared L2 fabric: ix-sw (wn-edge Et0/3 ↔ ix-sw Et0/1; ix-sw Et0/2 ↔ nn-edge Et0/3) (session path unconfirmed)

À la fois un lien direct et une fabric partagée. Ambiguïté, explicitement nommée, sans qu’aucun ne soit choisi.

Ce quatrième cas est celui qui justifie toute la conception. Il est vraiment courant sur un point d’échange, il est vraiment indécidable à partir de la seule couche 2, et c’est exactement là qu’un outil qui veut paraître sûr de lui choisira le lien direct et se trompera discrètement.

Le barreau qui transforme une supposition en fait

Il existe une sortie, et ce n’est pas une heuristique. Si les deux adresses de la session BGP se résolvent sur des ports précis via les liaisons IP-MIB des équipements, alors les ports ne sont plus inférés. Le routeur lui-même vous a dit quelle interface possède cette adresse. Cette preuve prime sur les garde-fous d’ambiguïté :

Un chemin inter-AS dont la transition eBGP nomme les deux ports physiques avec la preuve ip-bound

eBGP transition 200 → 300 jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 (bmp-peer+l2; ip-bound)

Lisez cette parenthèse comme une chaîne de possession :

bmp-peer : une session eBGP établie entre eux, vue via BMP
+l2 : le côté distant apparié via l’adjacence LLDP/CDP des routeurs de bordure
ip-bound : les deux adresses de session résolues sur ces ports exacts via IP-MIB

Trois sources indépendantes qui concordent. L’affirmation vaut ce que vaut le plus faible de ses appuis, et la notation dit lequel c’est.

La fraîcheur fait partie de la preuve

Les données L2 se périment, et des données L2 périmées sont pires que rien parce qu’elles ressemblent trait pour trait à des données fraîches. Les lignes de soutien portent donc des règles :

Les lignes doivent être plus fraîches que 13 heures pour soutenir la moindre affirmation de port
L’âge est divulgué au-delà de 6 heures
Un bridge apparié uniquement sur le sysname, plutôt que sur une identité d’équipement résolue, oppose son veto à une affirmation de port sans jamais être lui-même présenté comme un fait

Ce dernier point est subtil et il me plaît : une preuve faible a le droit de détruire la confiance sans avoir le droit d’en créer. Un bridge à demi identifié est une raison suffisante d’arrêter de revendiquer une paire de ports directe, et très loin d’être une raison suffisante de revendiquer le bridge.

Provenance : le même tableau, deux pedigrees différents

Dans le billet deux j’ai montré la table des voisins BGP : 378 sessions sur 57 pairs. Ce que cette capture ne montre pas, c’est qu’elles ne sont pas toutes arrivées de la même façon :

Source	Sessions
BMP : le routeur pousse sa Adj-RIB-In (RFC 7854)	24
SNMP : un parcours de la BGP4-MIB au moment du relevé	354

Les deux sont vraies. Elles ne se valent pas. BMP porte tous les chemins que le voisin a annoncés, plus les Peer Up et Peer Down tels que le routeur les voit, en temps réel. Un parcours SNMP vous donne la table des sessions telle qu’au dernier relevé et rien sur ce qui s’est passé entre-temps.

Il vaut la peine d’être précis sur la RIB concernée, car elle décide de ce que vous avez le droit d’affirmer. La RFC 7854 supervise la Adj-RIB-In : ce qui est arrivé de chaque voisin, avant que ce routeur ne choisisse quoi que ce soit. La table effectivement retenue par le routeur, la Loc-RIB, est une extension ultérieure et distincte (RFC 9069) que les exportateurs ici n’envoient pas. Ce laboratoire peut donc dire « le voisin X m’a proposé ce chemin » avec l’autorité d’un routeur, tandis que « voici le chemin que le routeur a installé » est le calcul propre d’Osprey sur ces candidats. Ce sont des affirmations différentes et elles sont étiquetées différemment.

Chaque ligne enregistre donc laquelle des deux elle est, dans une colonne source, et cette valeur est porteuse plutôt que décorative. Quand Osprey assemble un chemin inter-AS et a besoin d’un saut interdomaine, une session eBGP compte comme preuve avec sa provenance attachée : bmp-peer et snmp-peer sont des barreaux différents de l’échelle, et l’annotation du chemin dit sur lequel elle s’est tenue.

Il y a une règle voisine que j’aime bien, enfouie dans le moteur de chemin. Pour classer une route BGP comme interne ou externe, l’heuristique évidente est de regarder l’AS_PATH : un chemin à un seul élément implique de l’iBGP. Osprey ne fait pas cela en premier. Il joint la route au vrai type de voisin issu de la table des sessions, en direct depuis bgp_peer ou à l’instant T depuis bgp_peer_history, et ne retombe sur l’heuristique de l’AS_PATH que si aucun voisin source ne se résout. L’heuristique a presque toujours raison. « Presque toujours » est exactement le mode de défaillance dont parle toute cette série.

Là où rien ne concorde : le dire

Parfois les sources ne se contentent pas de diverger, elles s’épuisent. L’assemblage de chemins interdomaines note chaque segment sur une échelle stricte :

Barreau	Preuve	Confiance
a	Une ligne de RIB sur une bordure couvrant la destination	`resolved`
a2	Un serveur de routes dont la RIB BMP la couvre via l’AS suivant	`inferred` (`bmp-rib-rs`)
b	Une session eBGP établie vers l’AS suivant	`inferred`
c	Rien	`opaque` : un segment avec une note et aucun saut dessiné

Et la note est par segment, pas par chemin, parce qu’un chemin peut être certain dans un AS et conjectural dans le suivant. C’est pour cela que la capture interdomaine plus haut porte deux badges différents sur deux moitiés de la même réponse.

Le barreau (a2) existe pour une raison précise qui mérite d’être nommée : un serveur de routes transparent n’apparaît jamais dans l’AS_PATH. Sans lire la RIB propre du serveur de routes, il n’y a aucun moyen de voir un détour par un IX. Le chemin paraîtrait direct alors qu’il ne l’est pas. Toute une classe de topologie internet réelle reste invisible tant qu’on ne va pas chercher ce qui la cache.

La règle

Quand deux sources divergent, vous pouvez faire trois choses :

En choisir une. Rapide, l’air décidé, silencieusement faux à des moments inconnus.
Les moyenner. Produit un nombre qui ne décrit rien d’existant.
Les classer, et dire laquelle vous avez utilisée.

Osprey fait la troisième, partout, et c’est pour cela que je fais plus confiance à sa sortie qu’à mon propre souvenir de l’état d’un réseau mardi dernier.

Le coût, c’est que l’interface doit porter plus de mots que celle d’un concurrent : resolved, inferred, opaque, ip-bound, session link undetermined, bmp-peer contre snmp-peer. Chacun de ces mots est un endroit où un produit plus joli aurait montré une ligne nette.

Une ligne nette est une affirmation. Si vous ne pouvez pas l’étayer, ne la dessinez pas.

Ensuite, le billet où cette philosophie se retourne contre son auteur : le jour où j’ai découvert que mon propre outil dessinait de la fiction : Le jour où ma topologie m’a menti.