Drei IGPs, eine Karte

Ich habe ein Labor. Es ist kein Diagramm und kein Simulator. Es sind 192 echte Router mit echten Protokoll-Stacks, und ich benutze es jeden Tag, um Osprey gegen etwas zu bauen, das mir tatsächlich widersprechen kann.

Das Labor ist mit Absicht unbequem. Es beherbergt drei Carrier, die sich nichts teilen:

Mandant	ASN	IGP	Aufbau
Harrier-Broadband	200	OSPFv2 und OSPFv3	15 Areas je Protokoll, Dual-Stack auf denselben Leitungen
Kestrel-Dynamics	100	EIGRP, IPv4 + IPv6	flach, weil EIGRP keine Areas kennt
Merlin-Carrier	300	IS-IS, mehrere AF	17 Level-1-Areas unter einem Level-2-Backbone

Drei Protokolle, drei Adresspläne, drei ASNs, drei Sätze Zugangsdaten. Nirgends ein gemeinsames IGP. Das ist ungefähr der schlimmste Fall, den man einem Topologie-Werkzeug vorsetzen kann, und genau deshalb habe ich es gebaut.

Alles Folgende ist ein Screenshot aus diesem Labor, live aufgenommen während des Schreibens. Nichts ist nachgestellt.

---

Warum die Hierarchie vor dem Bild kommt

Die meisten Topologie-Werkzeuge fangen mit einem Canvas an und schrauben die Struktur nachträglich daran. Das funktioniert, bis derselbe physische Router berechtigterweise zu zwei verschiedenen Antworten gleichzeitig gehört. In einem Carrier-Netz ist das ein ganz normaler Dienstag.

Osprey dreht das um. Jedes Objekt hängt an einer expliziten Hierarchie:

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

Diese Kette ist keine Dekoration. Sie ist der Grund, warum das Produkt die Frage “welcher OSPF-Prozess, in welcher VRF, in welchem AS, unter welchem Mandanten” ohne Raten beantworten kann, und sie ist der Grund, warum ein Gerät in einer Instanz ABR und in einer anderen ein gewöhnlicher interner Router sein kann, ohne dass sich das Modell dabei verknotet.

Achten Sie darauf, was die Seitenleiste zeigt: OSPF 1 und OSPFv3 1 (v6) sind getrennte Protokollinstanzen, jede mit ihren eigenen 15 Areas, ihrer eigenen LSDB und ihrem eigenen SPF. Sie laufen über dieselben physischen Links. Sie werden nicht zu einer hoffnungsvollen “IGP”-Abstraktion verschmolzen, weil sie schlicht nicht dasselbe sind. RFC 5340 gibt OSPFv3 eine eigene LSDB und eine eigene Topologie, und so zu tun als wäre es anders, liefert falsche Antworten, sobald die beiden voneinander abweichen.

---

Harrier-Broadband: OSPF, 15 Areas, Dual-Stack

Hier ist AS 200, eingefärbt nach Area:

64 Router, 151 Links, 30 Areas (15 in OSPFv2, 15 in OSPFv3). Der blaue Block in der Mitte ist Area 0.0.0.0, das Backbone. Jeder farbige Cluster daran ist eine Nicht-Backbone-Area, die das Backbone über ihre ABRs erreicht.

In dieser Größe ist das Bild noch lesbar. Beim Fünffachen wäre es das nicht mehr, und genau deshalb kann dieselbe Topologie in ihre Areas zusammenfallen:

Jede Wolke ist eine Area, jede Linie ein Bündel von Inter-Area-Nachbarschaften mit der Anzahl daran (4×, 8×, 2×). Das ist die Ansicht, die ich tatsächlich benutze, um zu beantworten: “wie schlecht hängt Area 19.5.1.0 am Backbone?”. Die Antwort lautet hier “an vier Links”, und das ist ein ganz anderes Risikoprofil als bei den Zwei-Link-Areas daneben.

---

Merlin-Carrier: IS-IS, und die Adressfamilie ist wirklich entscheidend

AS 300 fährt IS-IS. Gleiche physische Form, völlig anderes Protokollmodell:

IS-IS ist die Stelle, an der viele Werkzeuge stillschweigend umfallen, denn IS-IS ist nicht “OSPF mit anderen Wörtern”. Eine einzige IS-IS-LSDB kann Erreichbarkeit für CLNS, IPv4 und IPv6 gleichzeitig tragen, und der korrekte kürzeste Pfad gilt je Adressfamilie.

Also berechnet Osprey ihn je Adressfamilie und sagt Ihnen, welche Sie gerade ansehen:

Sehen Sie sich die Hop-Tabelle an. Weil die Adressfamilie CLNS ist, werden die Hops über die System-ID (0100.6600.8003) und den Circuit identifiziert, nicht über eine IPv4-Adresse, die in einem CLNS-Pfad bedeutungslos wäre. Stellen Sie die Auswahl auf IPv4 oder IPv6, und derselbe Pfad wird mit der Adressierung neu gezeichnet, die diese Familie tatsächlich verwendet.

(Dieser Screenshot legt zugleich etwas über die Hop-für-Hop-Modellierung in IS-IS offen. Das ist Thema eines späteren Beitrags, und ich werde es hier nicht verstecken.)

---

Kestrel-Dynamics: EIGRP, das überhaupt keine Link-State-Datenbank hat

Und dann ist da AS 100:

Eine Farbe. Zwei “Areas”. Das ist kein Darstellungsfehler. Das ist EIGRP, das ehrlich über sich selbst ist.

EIGRP ist ein Distanzvektor-Protokoll ohne Link-State-Datenbank, der man beitreten könnte, und ohne Area-Begriff, nach dem man einfärben könnte. Die beiden Einträge sind schlicht die IPv4- und die IPv6-Instanz. EIGRP baut zwar Nachbarschaften auf, über sein eigenes Hello-Protokoll, aber dahinter liegt keine Link-State-Datenbank, die man ablaufen könnte, und kein SPF, das man rechnen könnte: Nachbarn tauschen Distanzvektoren aus, keine synchronisierte Karte. Also liest Osprey es nur lesend aus der CISCO-EIGRP-MIB und rekonstruiert den Nachbarschaftsgraphen daraus, was jeder Router über seine eigenen Nachbarn berichtet. In diesem Labor sind das 580 aktive Nachbarschaftsbeziehungen.

Dieser Unterschied wirkt bis in die Pfadberechnung hinein, und man sieht ihn:

Auf diesem Pfad gibt es keine “Gesamtkosten”, und das war auch nie zu erwarten. Die zusammengesetzte Metrik von EIGRP beschreibt einen ganzen Pfad, nicht einen einzelnen Hop; Hop-Kosten zu summieren ergäbe eine Zahl ohne Bedeutung. Was Sie stattdessen bekommen, ist die eigene, aktuell berechnete Distanz jedes Routers zum Ziel, fallend entlang der Kette: 712704 → 710144 → 658944 → … → 128256. Genau das würden Sie ablesen, wenn Sie die Router einzeln abfragen. (Die Feasible Distance aus DUAL ist eine fein davon verschiedene Größe: das Minimum, seit die Route zuletzt passiv wurde, also die Feasibility-Schwelle. Die Hop-Tabelle hält beide auseinander, statt das eine als das andere zu etikettieren.)

Drei Protokolle, drei wirklich verschiedene Modelle, drei richtige Antworten. Nicht eine Abstraktion, die so tut, als wären sie dasselbe.

---

Unter dem Bild: die LSDB selbst

Der Canvas ist eine Darstellung. Das Modell darunter ist die Link-State-Datenbank, und Osprey hält sie durchsuchbar:

13.382 LSAs, aufgeteilt nach Typ: Router (1), Network (2), Summary (3), ASBR (4), External (5) und NSSA (7). Die ABR- und ASBR-Kennzeichen werden aus den LSAs selbst abgeleitet, nicht aus einer Namenskonvention.

Lesen Sie die Zeile unter der Überschrift genau:

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

Diese LSAs wurden aus SNMP-Walks rekonstruiert, nicht über eine Protokollnachbarschaft empfangen. Ein SNMP-Walk der OSPF-MIB liefert Ihnen den Inhalt der LSAs, aber nicht die aktuellen Header-Felder. Also zeigt Osprey den Inhalt und sagt klar, dass drei Felder fehlen, statt drei Spalten Nullen zu zeichnen, die wie Daten aussehen würden.

Das ist eine Kleinigkeit. Es ist zugleich die ganze Entwurfsphilosophie in einer Zeile, und es ist der Grund, warum ich den anderen 13.382 Zahlen auf diesem Bildschirm vertraue.

---

Der Punkt

Die Karte ist nicht das Produkt. Das Modell ist es.

Drei Carrier, die kein Protokoll, keinen Adressplan und keine ASN teilen, sitzen in einem Werkzeug, ohne dass einer von ihnen auf einen kleinsten gemeinsamen Nenner eingeebnet wird. OSPF behält seine Areas und seine zwei LSDBs, IS-IS behält seine Level und seine Adressfamilien, EIGRP behält seine DUAL-Distanzen und sein vollständiges Fehlen einer Link-State-Datenbank.

Wo sie sich wirklich unterscheiden, unterscheidet sich das Produkt. Wo es etwas nicht wissen kann, sagt es das.

---

Osprey ist passiv: keine Agenten auf den Routern, keine Routeninjektion, keine Paketweiterleitung. Wie das tatsächlich funktioniert und was es kostet, steht im nächsten Beitrag.