Hop-für-Hop-Wahrheit

Ihr Pfadwerkzeug zeichnet einen Korridor. Router leiten Hop für Hop weiter. Hier ist die Messung über 4.032 Paare, die den Abstand beziffert.

10. August 2026 Michel Wijnberg

Fast jedes Netzwerk-Pfadwerkzeug, das ich benutzt habe (bis vor Kurzem auch meines), arbeitet so:

Nimm den Quellrouter.
Lass Dijkstra über die Topologie laufen.
Zeichne den resultierenden kürzesten Pfad.

Das ist ein von der Quelle aus gewurzelter Korridor, und er ist ein subtil falsches Modell der IP-Weiterleitung. Echte Weiterleitung kennt keinen Korridor. Jeder Router gleicht die Zieladresse unabhängig mit seiner eigenen Routing-Tabelle ab und wählt einen Next Hop. Die beiden Antworten stimmen nur so lange überein, wie Entscheidungsregel und Eingangsdaten jedes Zwischenrouters denen der Quelle entsprechen.

Bei OSPF tun sie das regelmäßig nicht.

Ein Paket, das nie ankommt

Hier ein Fall aus meinem Labor, auf jedem beteiligten Router mit show ip route gemessen, nicht modelliert, sondern von den Geräten abgelesen:

Router	Sagt über das Ziel	Leitet weiter an
`dfw1-gw2`	`metric 20031, type inter area`	`dfw1-cr1`
`dfw1-cr1`	`metric 30001, type intra area`	`ord1-cr1` ← nicht `dfw2-cr1`
`ord1-cr1`	`metric 20001, type intra area`	`jfk1-cr1`
`jfk1-cr1`	`metric 10001, type intra area`	`lhr1-cr1`
`lhr1-cr1`	`metric 1, connected`	zugestellt

Der von der Quelle gewurzelte Korridor zeichnete das hier:

dfw1-gw2 → dfw1-cr1 → dfw2-cr1 → iad2-cr1 → ams1-cr1 → lhr1-cr1

Das Paket erreicht dfw2-cr1 nie. Der Korridor ist ein billigerer Pfad. Er ist nur kein Pfad, den irgendein Router bauen wird. Zwei voneinander unabhängige Regeln aus RFC 2328 sorgen dafür, dass dfw1-cr1 ihn ablehnt:

§16 Schritt (3) / §16.2 ¶1: das Backbone-Tor. Ein Router, der an mehreren Areas hängt, betrachtet ausschließlich Summary-LSAs aus dem Backbone. Das billigere Summary von dfw2-cr1 mit Kosten 20011 liegt tatsächlich in der Datenbank von dfw1-cr1 für Area 4.6.23.0 (ich habe das mit show ip ospf database summary bestätigt), aber es ist kein Kandidat, weil dfw1-cr1 ein ABR ist und dieses Summary nicht über Area 0 eingetroffen ist. RFC 3509 §2.1/§2.2 (das ABR-Verhalten von Cisco, das auf diesen Geräten tatsächlich läuft) knüpft das an eine aktive Backbone-Verbindung, die dfw1-cr1 hat.

§16.2 Schritt (6): intra schlägt inter, Punkt. “If the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred).” dfw1-cr1 hält bereits einen Intra-Area-Pfad mit Metrik 30001. Das Summary mit 20011 verliert dagegen. Die Metrik ist irrelevant: Das ist eine Regel über den Pfadtyp, und ein Kostenvergleich findet gar nicht erst statt.

Jede der beiden Regeln allein erledigt den Korridor. Ein Werkzeug, das ein einziges SPF von der Quelle aus rechnet, kann keine von beiden sehen, denn es fragt dfw1-cr1 nie, was dfw1-cr1 denkt.

Wie oft spielt das tatsächlich eine Rolle?

Das ist der Teil, der mich interessiert, denn “Ihr Modell ist theoretisch ungenau” ist eine viel schwächere Aussage als eine Zahl.

Also habe ich die vollständige OSPF-Routing-Tabelle von allen 64 Routern in AS 200 ausgelesen und jedes der 4.032 geordneten Quelle/Ziel-Paare verglichen:

Messung	Ergebnis
Inter-Area-Paare, bei denen der Korridor ≥1 Hop zeichnete, den kein Router nimmt	360 von 2.839 (12,68 %)
Intra-Area-Paare mit demselben Defekt	0 von 1.193
Insgesamt	360 von 4.032 (8,93 %)

Die Null bei Intra-Area ist die Plausibilitätsprobe. Innerhalb einer Area rechnet jeder Router SPF über eine identische LSDB, und ein kürzester Pfad bleibt von jedem Punkt darauf aus der kürzeste, die beiden Modelle haben also allen Grund, übereinzustimmen. Der Punkt ist, dass die Übereinstimmung gemessen und nicht angenommen wurde: 1.193 Paare, keine Abweichung. Sobald ein ABR und ein Summary-LSA ins Spiel kommen, ist einer von acht Pfaden Fiktion.

Nicht “leicht suboptimal”. Fiktion, mit einem Router darin, den das Paket nachweislich nie besucht. Wenn Sie diesen Pfad benutzen, um ein Wartungsfenster zu planen oder einen Vorfall zu erklären, denken Sie über eine Route nach, die es nicht gibt.

Die Korrektur: jeden Router fragen

Osprey läuft die Kette inzwischen ab. Bei jedem Hop wertet es die eigene installierte Route dieses Routers zur Zieladresse aus, mit dessen eigener LSDB, dessen eigenen Area-Mitgliedschaften, dessen eigenem ABR-Status und dessen eigener Mischung administrativer Distanzen, folgt dann dem Next Hop, den er tatsächlich wählt, und wiederholt das.

Gegen dieselben 4.032 Paare validiert:

Prüfung	Ergebnis
Eigene Metrik des Routers exakt reproduziert	4.032 / 4.032
Pfadtyp (intra / inter / extern) exakt	4.032 / 4.032
Vollständige installierte ECMP-Next-Hop-Menge identisch	4.032 / 4.032
Kette endet mit `delivered` am angefragten Ziel	4.032 / 4.032

Nicht “nahe dran”. Identisch, bei jedem Paar, einschließlich der vollständigen Menge gleichwertiger Next Hops statt eines willkürlich gewählten Mitglieds.

So sieht das auf dem Canvas aus: Hinweg in Orange, Rückweg in Blau, alles außerhalb des Pfades zu einem Korridor abgedunkelt:

Ein OSPF-Pfad über die Topologie gezeichnet, mit Hin- und Rückweg-Overlays und vier gleichwertigen Pfaden

Achten Sie auf die Auswahl 4 equal-cost paths und die Beschriftung per-flow hash. Osprey zählt die vollständige ECMP-Menge auf, statt ein Mitglied herauszugreifen und es als den Pfad zu präsentieren, denn Ihr Verkehr wird über alle vier gehasht, und eine Fehlersuche, die nur einen davon ansieht, findet in drei von vier Fällen nichts.

Und hier derselbe Pfad, aufgeklappt:

Ein OSPF-Pfad über 10 Hops mit Tabelle je Hop, ABR-Kennzeichen, Ein- und Ausgangsports und der nummerierten Erklärung

Jeder Hop trägt den Router, der die Entscheidung getroffen hat, die Area, in der er sie getroffen hat, die physischen Ein- und Ausgangs-Interfaces mit ihren Adressen und die Kosten. Die ABR-Kennzeichen stammen aus den LSDBs, nicht aus Hostnamen. Das Area-Band darunter zeigt, wie der Pfad 12.1.24.0 → 0.0.0.0 → 6.18.1.0 durchquert, also den Backbone-Transit, den RFC 2328 für Inter-Area-Verkehr verlangt.

Und die angezeigten Gesamtkosten, 30061, sind die selbst installierte Metrik der Quelle. Es ist buchstäblich die Zahl, die show ip route auf lax1-gw1 ausgibt, Stub-Kosten inklusive, und keine Summe, die Osprey aus Links berechnet hat, die ihm gefielen.

Die Erklärung wird erzeugt, sie ist keine Dekoration:

Route type: O IA (inter-area): Source 172.16.2.33 and destination 172.16.5.23 have no shared area, routing via backbone (area 0.0.0.0)

Path traverses: area 12.1.24.0 (cost 10) → area 0.0.0.0 (cost 30040) → area 6.18.1.0 (cost 10)

Total cost: 30061 via 10 hops

ECMP: 4 equal-cost paths available

Über die AS-Grenze hinweg

Innerhalb eines IGP ist die Kette berechenbar, weil die LSDB vollständig ist. Über eine AS-Grenze hinweg ist gar nichts vollständig. Es gibt keine gemeinsame Datenbank, keinen gemeinsamen Metrikraum und keine gemeinsame Politik für administrative Distanzen.

Die ehrliche Antwort ist nicht aufzugeben, und ganz sicher nicht so zu tun, als ließen sich die Metriken zusammensetzen. Sie lautet: Belege zusammenfügen.

Ein Pfad über 15 Hops von AS 200 nach AS 300, mit Kosten je Segment und einem eBGP-Übergang

Fünfzehn Hops von lax1-gw1 in AS 200 (Mandant Harrier-Broadband, OSPF) zu i-sin1-gw1 in AS 300 (Mandant Merlin-Carrier, IS-IS). Lesen Sie, was da passiert:

Hop 8 jfk1-gw1 trägt ein BGP-Kennzeichen: Hier hört das IGP auf und die BGP-Entscheidung übernimmt.
Hop 9 i-jfk1-gw1 trägt ein IS-IS-Kennzeichen: ein völlig anderes Protokoll, ein anderer Adressplan, ein anderer Mandant.
In der Fußzeile steht “Per-segment costs (never summed) | 15 hops”. Eine OSPF-Metrik von 20051 und eine IS-IS-Metrik von 1320 sind Zahlen aus unverwandten Metrikräumen. Sie zu addieren ergäbe 21371, und das ist keine Größe, die existiert. Osprey weigert sich, sie auszugeben.

Die erzeugte Erklärung benennt bei jedem Schritt ihre Belege:

BGP border selection: jfk1-gw1 holds 10.66.0.0/15 for 10.66.15.3 (AS path: 300)

AS 200: IGP segment: lax1-gw1 → jfk1-gw1, cost 20051

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

AS 300: IGP segment: i-jfk1-gw1 → i-sin1-gw1, cost 1320

Schritt 3 ist meine Lieblingszeile im ganzen Produkt. Da steht nicht “diese beiden Router sind vermutlich irgendwie verbunden”. Da werden physische Ports auf beiden Seiten benannt, und dann legt die Klammer die Arbeit offen:

bmp-peer: eine bestehende eBGP-Sitzung zwischen den beiden, über BMP gesehen
+l2: die Gegenseite wurde über die LLDP-/CDP-Nachbarschaft der Border-Router zugeordnet
ip-bound: beide Sitzungsadressen wurden über die IP-MIB-Bindungen der Geräte genau diesen Ports zugeordnet

Drei voneinander unabhängige Belege, die übereinstimmen. Wenn sie das nicht tun, sagt das Produkt es stattdessen, und genau darum geht es im nächsten Beitrag.

Warum mir das wichtiger ist als Funktionen

Eine Pfadzeichnung ist eine Behauptung darüber, was Ihr Netzwerk mit einem Paket tun wird. Wenn diese Behauptung in einem von acht Fällen falsch ist und nichts auf dem Bildschirm die falschen von den richtigen unterscheidet, ist die Zeichnung schlimmer als nutzlos. Sie ist selbstbewusst nutzlos, und man wird ihr genau in dem Moment glauben, in dem ein Irrtum teuer wird.

Von “plausibel” zu “reproduziert alle 64 Routing-Tabellen exakt, 4.032 von 4.032” zu kommen, brauchte ein Validierungsgerüst, ein Labor, aus dem ich die Wahrheit ablesen kann, und die Bereitschaft herauszufinden, dass mein eigenes Werkzeug 360-mal Fiktion gezeichnet hatte.

Dafür ist das Labor da.

Als Nächstes die andere Seite derselben Medaille: die Stellen, an denen Osprey die Antwort nicht berechnen kann und das auch sagt: Was Osprey nicht raten will.