Wenn das Netzwerk sich selbst widerspricht

Sechs Wahrheitsquellen, eine Antwort, und was zu tun ist, wenn sie einander widersprechen

16. August 2026 Michel Wijnberg

Osprey erfährt aus sechs Quellen etwas über ein Netzwerk:

Quelle	Sagt Ihnen
OSPF-/IS-IS-LSDB	wofür jedes Protokoll die Topologie hält
SNMP-Routing-Tabelle	was ein Router tatsächlich installiert hat
BMP Adj-RIB-In	was jeder BGP-Peer diesem Router angekündigt hat, und von wem
LLDP / CDP	was physisch mit was verkabelt ist
IP-MIB	welche Adresse auf welchem Port liegt
BGP-Sitzungstabelle	wer mit wem gepeert ist

Jede von ihnen ist über irgendetwas maßgeblich. Keine von ihnen ist über alles maßgeblich. Und sie stimmen nicht immer überein.

Die naive Antwort ist, global einen Sieger zu küren (“bei Topologie vertrauen wir LLDP, bei BGP vertrauen wir BMP”) und weiterzumachen. Das scheitert am ersten Netz, in dem LLDP auf einer Seite eines Links veraltet ist, oder in dem eine Bridge zwischen zwei Routern sitzt, die sich für direkt verbunden halten.

Die Antwort, bei der ich gelandet bin, ist langweiliger und funktioniert: Belege je Aussage einstufen und festhalten, woher jede Aussage stammt.

Ports: vier Situationen, vier verschiedene Antworten

Die schärfste Ausprägung dieses Problems ist, einen eBGP-Übergang mit physischen Ports zu annotieren. Zwei Router in verschiedenen autonomen Systemen haben eine Sitzung. Welches Kabel überquert sie?

Osprey unterscheidet vier Fälle und gibt auf jeden eine andere Art von Antwort:

Ein Linkpaar, keine Fabric-Alternative. Ports als Tatsache genannt:

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

Parallele Links. Das Paar ist nicht bestimmt, also behauptet es keines:

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

Beide Border-Router an einer gemeinsamen Bridge, kein direkter Link. Es meldet das Vorhandensein der Bridge samt Anschlussports, also die Aussage, dass es einen Weg darüber gibt, niemals die Behauptung, dass diese Sitzung ihn nimmt:

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

Sowohl ein direkter Link als auch eine gemeinsame Fabric. Mehrdeutigkeit, ausdrücklich benannt, ohne dass eines von beiden gewählt wird.

Dieser vierte Fall ist der, der den ganzen Entwurf rechtfertigt. Er ist an einem Exchange Point wirklich häufig, er ist aus L2 allein wirklich nicht entscheidbar, und er ist genau die Stelle, an der ein Werkzeug, das selbstbewusst wirken will, den direkten Link nimmt und stillschweigend falsch liegt.

Die Sprosse, die aus einer Vermutung eine Tatsache macht

Es gibt einen Ausweg, und er ist keine Heuristik. Wenn sich beide Adressen der BGP-Sitzung über die IP-MIB-Bindungen der Geräte konkreten Ports zuordnen lassen, dann sind die Ports nicht mehr erschlossen. Der Router selbst hat Ihnen gesagt, welches Interface diese Adresse besitzt. Dieser Beleg überstimmt die Mehrdeutigkeitsschranken:

Ein AS-übergreifender Pfad, dessen eBGP-Übergang beide physischen Ports mit ip-bound-Beleg benennt

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

Lesen Sie diese Klammer als lückenlose Beweiskette:

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 genau diesen Ports zugeordnet

Drei unabhängige Quellen, die übereinstimmen. Die Aussage ist so stark wie das Schwächste, worauf sie ruht, und die Notation sagt, was das ist.

Aktualität ist Teil des Belegs

L2-Daten veralten, und veraltete L2-Daten sind schlimmer als gar keine, weil sie genauso aussehen wie frische. Also gelten für die stützenden Zeilen Regeln:

Zeilen müssen jünger als 13 Stunden sein, um eine Port-Aussage überhaupt zu stützen
Ab 6 Stunden wird das Alter offengelegt
Eine Bridge, die nur über den Sysname zugeordnet wurde statt über eine aufgelöste Geräteidentität, verhindert eine Port-Aussage, ohne je selbst als Tatsache gezeigt zu werden

Der letzte Punkt ist subtil und gefällt mir: Schwache Belege dürfen Sicherheit zerstören, ohne sie erzeugen zu dürfen. Eine halb identifizierte Bridge ist Grund genug, ein direktes Portpaar nicht länger zu behaupten, und bei Weitem nicht Grund genug, die Bridge zu behaupten.

Herkunft: dieselbe Tabelle, zwei verschiedene Stammbäume

In Beitrag zwei habe ich die BGP-Peer-Tabelle gezeigt: 378 Sitzungen über 57 Peers. Was dieser Screenshot nicht zeigt: Sie sind nicht alle auf demselben Weg angekommen.

Quelle	Sitzungen
BMP: der Router schickt seine Adj-RIB-In (RFC 7854)	24
SNMP: ein BGP4-MIB-Walk zum Poll-Zeitpunkt	354

Beides ist wahr. Beides ist nicht gleich gut. BMP trägt jeden Pfad, den der Peer angekündigt hat, dazu Peer Up und Peer Down so, wie der Router sie sieht, in Echtzeit. Ein SNMP-Walk gibt Ihnen die Sitzungstabelle zum Stand des letzten Polls und nichts darüber, was dazwischen geschah.

Es lohnt sich, genau zu sein, um welche RIB es geht, denn davon hängt ab, was Sie behaupten dürfen. RFC 7854 überwacht die Adj-RIB-In: das, was von jedem Peer ankam, bevor dieser Router irgendetwas ausgewählt hat. Die vom Router selbst gewählte Tabelle, die Loc-RIB, ist eine spätere, eigene Erweiterung (RFC 9069), die die Exporter hier nicht senden. Dieses Labor kann also mit der Autorität eines Routers sagen “Peer X hat mir diesen Pfad angeboten”, während “das ist der Pfad, den der Router installiert hat” Ospreys eigene Berechnung über diese Kandidaten ist. Das sind verschiedene Aussagen, und sie werden verschieden gekennzeichnet.

Deshalb hält jede Zeile in einer Spalte source fest, welche von beiden es ist, und dieser Wert ist tragend und nicht dekorativ. Wenn Osprey einen AS-übergreifenden Pfad zusammensetzt und einen domänenübergreifenden Hop braucht, zählt eine eBGP-Sitzung als Beleg mit angehängter Herkunft: bmp-peer und snmp-peer sind verschiedene Sprossen auf der Leiter, und die Pfad-Annotation sagt, auf welcher sie stand.

Es gibt eine verwandte Regel, die ich mag, tief in der Pfad-Engine vergraben. Um eine BGP-Route als intern oder extern einzustufen, wäre die naheliegende Heuristik, in den AS_PATH zu schauen: Ein Pfad mit einem einzigen Element deutet auf iBGP hin. Osprey macht das nicht zuerst. Es verknüpft die Route mit dem echten Peer-Typ aus der Sitzungstabelle, live aus bgp_peer oder als-of-T aus bgp_peer_history, und fällt nur dann auf die AS_PATH-Heuristik zurück, wenn sich kein Quell-Peer auflösen lässt. Die Heuristik trifft fast immer zu. “Fast immer” ist genau der Fehlermodus, um den es in dieser ganzen Reihe geht.

Wo nichts übereinstimmt: sagen Sie es

Manchmal widersprechen sich die Quellen nicht nur, sie gehen aus. Das domänenübergreifende Zusammenfügen von Pfaden stuft jedes Segment auf einer strengen Leiter ein:

Sprosse	Beleg	Verlässlichkeit
a	Eine RIB-Zeile an einem Border-Router, die das Ziel abdeckt	`resolved`
a2	Ein Route Server, dessen eigene BMP-RIB es über das nächste AS abdeckt	`inferred` (`bmp-rib-rs`)
b	Eine bestehende eBGP-Sitzung in Richtung des nächsten AS	`inferred`
c	Nichts	`opaque`: ein Segment mit Hinweis und ohne gezeichnete Hops

Und die Einstufung gilt je Segment, nicht je Pfad, denn ein Pfad kann in einem AS sicher und im nächsten geraten sein. Deshalb trägt der domänenübergreifende Screenshot oben zwei verschiedene Kennzeichen auf zwei Hälften derselben Antwort.

Sprosse (a2) gibt es aus einem bestimmten Grund, den man benennen sollte: Ein transparenter Route Server taucht nie im AS_PATH auf. Ohne die eigene RIB des Route Servers zu lesen, gibt es keine Möglichkeit, einen Umweg über einen IX überhaupt zu sehen. Der Pfad sähe direkt aus, obwohl er es nicht ist. Eine ganze Klasse echter Internet-Topologie bleibt unsichtbar, solange man nicht gezielt nach dem sucht, was sie verbirgt.

Die Regel

Wenn zwei Quellen sich widersprechen, können Sie drei Dinge tun:

Eine auswählen. Schnell, wirkt entschlossen, ist zu unbekannten Zeitpunkten stillschweigend falsch.
Sie mitteln. Ergibt eine Zahl, die nichts Existierendes beschreibt.
Sie einstufen und sagen, welche Sie benutzt haben.

Osprey macht das Dritte, überall, und deshalb vertraue ich seiner Ausgabe mehr als meiner eigenen Erinnerung daran, wie ein Netz letzten Dienstag aussah.

Der Preis ist, dass die Oberfläche mehr Wörter tragen muss als die eines Wettbewerbers: resolved, inferred, opaque, ip-bound, session link undetermined, bmp-peer gegenüber snmp-peer. Jedes davon ist eine Stelle, an der ein hübscheres Produkt eine saubere Linie gezeigt hätte.

Eine saubere Linie ist eine Behauptung. Wenn Sie sie nicht belegen können, zeichnen Sie sie nicht.

Als Nächstes der Beitrag, in dem sich diese Haltung gegen ihren Autor richtet: der Tag, an dem ich herausfand, dass mein eigenes Werkzeug Fiktion gezeichnet hatte: Der Tag, an dem meine Topologie mich anlog.