Trois IGP, une seule carte

J’ai un laboratoire. Ce n’est pas un schéma et ce n’est pas un simulateur. Ce sont 192 vrais routeurs qui font tourner de vraies piles protocolaires, et je m’en sers tous les jours pour construire Osprey face à quelque chose qui peut réellement me contredire.

Le laboratoire est volontairement inconfortable. Il abrite trois opérateurs qui ne partagent rien :

Locataire	ASN	IGP	Forme
Harrier-Broadband	200	OSPFv2 et OSPFv3	15 areas par protocole, double pile sur les mêmes câbles
Kestrel-Dynamics	100	EIGRP, IPv4 + IPv6	à plat, parce qu’EIGRP n’a pas d’areas
Merlin-Carrier	300	IS-IS, multi-AF	17 areas de niveau 1 sous un backbone de niveau 2

Trois protocoles, trois plans d’adressage, trois ASN, trois jeux d’identifiants. Aucun IGP commun nulle part. C’est à peu près le pire cas qu’on puisse soumettre à un outil de topologie, et c’est précisément pour cela que je l’ai construit.

Tout ce qui suit est une capture de ce laboratoire, prise en direct pendant l’écriture de ce billet. Rien n’est simulé.

---

Pourquoi la hiérarchie vient avant l’image

La plupart des outils de topologie commencent par un canvas et rajoutent la structure après coup. Cela fonctionne jusqu’au jour où le même routeur physique appartient légitimement à deux réponses différentes à la fois. Dans un réseau d’opérateur, c’est un mardi ordinaire.

Osprey inverse l’ordre. Chaque objet est accroché à une hiérarchie explicite :

Network → Autonomous System → Routing Domain → Protocol Instance → Area → Device

Cette chaîne n’est pas décorative. C’est elle qui permet au produit de répondre à « quel processus OSPF, dans quelle VRF, dans quel AS, sous quel locataire » sans deviner, et c’est elle qui permet à un équipement d’être ABR dans une instance et routeur interne ordinaire dans une autre sans que le modèle se noue.

Regardez ce que montre la barre latérale : OSPF 1 et OSPFv3 1 (v6) sont des instances de protocole distinctes, chacune portant son propre jeu de 15 areas, chacune avec sa LSDB et son SPF. Elles passent sur les mêmes liens physiques. Elles ne sont pas fusionnées en une abstraction « IGP » pleine d’espoir, parce qu’elles ne sont véritablement pas une seule chose. La RFC 5340 donne à OSPFv3 sa propre LSDB et sa propre topologie, et prétendre le contraire produit de mauvaises réponses dès l’instant où les deux divergent.

---

Harrier-Broadband : OSPF, 15 areas, double pile

Voici l’AS 200, coloré par area :

64 routeurs, 151 liens, 30 areas (15 en OSPFv2, 15 en OSPFv3). La masse bleue au milieu est l’area 0.0.0.0, le backbone. Chaque grappe colorée qui y pend est une area hors backbone qui rejoint le backbone par ses ABR.

À cette taille l’image reste lisible. À cinq fois cette taille elle ne le serait plus, et c’est pourquoi la même topologie peut se replier sur ses areas :

Chaque nuage est une area, chaque ligne un faisceau d’adjacences inter-area avec le compte dessus (4×, 8×, 2×). C’est la vue que j’utilise réellement pour répondre à « à quel point l’area 19.5.1.0 est-elle mal rattachée au backbone ? ». La réponse ici est « par quatre liens », et c’est un profil de risque très différent des areas à deux liens juste à côté.

---

Merlin-Carrier : IS-IS, et la famille d’adresses compte vraiment

L’AS 300 fait tourner IS-IS. Même forme physique, modèle protocolaire complètement différent :

IS-IS est l’endroit où beaucoup d’outils trébuchent discrètement, parce qu’IS-IS n’est pas « OSPF avec d’autres mots ». Une seule LSDB IS-IS peut porter simultanément la joignabilité pour CLNS, IPv4 et IPv6, et le plus court chemin correct s’entend par famille d’adresses.

Osprey le calcule donc par famille d’adresses, et vous dit laquelle vous regardez :

Regardez le tableau des sauts. Comme la famille d’adresses est CLNS, les sauts sont identifiés par System ID (0100.6600.8003) et par circuit, et non par une adresse IPv4, qui n’aurait aucun sens dans un chemin CLNS. Basculez le sélecteur sur IPv4 ou IPv6 et le même chemin se redessine avec l’adressage que cette famille utilise réellement.

(Cette capture fait aussi un aveu sur la modélisation saut par saut en IS-IS. C’est le sujet d’un billet ultérieur et je ne vais pas l’enterrer ici.)

---

Kestrel-Dynamics : EIGRP, qui n’a aucune base à état de liens

Et puis il y a l’AS 100 :

Une seule couleur. Deux « areas ». Ce n’est pas un défaut d’affichage. C’est EIGRP qui est honnête sur lui-même.

EIGRP est un protocole à vecteur de distance sans base à état de liens à rejoindre et sans notion d’area pour colorer. Les deux entrées sont simplement les instances IPv4 et IPv6. EIGRP forme bien des adjacences de voisinage, via son propre protocole Hello, mais il n’y a derrière aucune base à état de liens à parcourir et aucun SPF à faire tourner : les voisins échangent des vecteurs de distance, pas une carte synchronisée. Osprey le lit donc en lecture seule depuis CISCO-EIGRP-MIB et reconstruit le graphe d’adjacence à partir de ce que chaque routeur rapporte de ses propres voisins. Dans ce laboratoire, cela fait 580 relations de voisinage actives.

Cette différence se propage jusqu’au calcul de chemin, et elle se voit :

Il n’y a pas de « coût total » sur ce chemin, et il n’allait jamais y en avoir. La métrique composite d’EIGRP décrit un chemin entier, pas un saut isolé : additionner des coûts de saut produirait un nombre qui ne signifie rien. Ce que vous obtenez à la place, c’est la distance calculée courante de chaque routeur vers la destination, décroissante le long de la chaîne : 712704 → 710144 → 658944 → … → 128256. C’est exactement ce que vous liriez sur les routeurs un par un. (La Feasible Distance de DUAL est une grandeur subtilement différente : le minimum depuis le dernier passage de la route à l’état passif, le seuil de faisabilité. Le tableau des sauts garde les deux distinctes plutôt que d’étiqueter l’une comme l’autre.)

Trois protocoles, trois modèles véritablement différents, trois réponses correctes. Pas une abstraction qui prétend qu’ils sont la même chose.

---

Sous l’image : la LSDB elle-même

Le canvas est un rendu. Le modèle en dessous est la base à état de liens, et Osprey la garde consultable :

13 382 LSA, répartis par type : Router (1), Network (2), Summary (3), ASBR (4), External (5) et NSSA (7). Les indicateurs ABR et ASBR sont dérivés des LSA eux-mêmes plutôt que d’une convention de nommage.

Lisez attentivement la ligne sous le titre :

13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)

Ces LSA ont été reconstruits à partir de parcours SNMP, pas reçus par une adjacence protocolaire. Un parcours SNMP de la MIB OSPF vous donne le contenu des LSA mais pas les champs d’en-tête vivants. Osprey affiche donc le contenu et déclare clairement que trois champs manquent, plutôt que d’afficher trois colonnes de zéros qui ressembleraient à des données.

C’est une petite chose. C’est aussi toute la philosophie de conception en une ligne, et c’est pour cela que je fais confiance aux 13 382 autres nombres de cet écran.

---

Le fond de l’affaire

La carte n’est pas le produit. Le modèle l’est.

Trois opérateurs qui ne partagent ni protocole, ni plan d’adressage, ni ASN tiennent dans un seul outil sans qu’aucun soit aplati sur un plus petit dénominateur commun. OSPF garde ses areas et ses deux LSDB, IS-IS garde ses niveaux et ses familles d’adresses, EIGRP garde ses distances DUAL et son absence complète de base à état de liens.

Là où ils diffèrent réellement, le produit diffère. Là où il ne peut pas savoir quelque chose, il le dit.

---

Osprey est passif : aucun agent sur les routeurs, aucune injection de route, aucun acheminement de paquet. Comment cela fonctionne réellement, et ce que cela coûte, c’est le billet suivant.