Kein Fußabdruck

Wie Osprey ein Netzwerk sieht, ohne ein Teil davon zu werden

10. August 2026 Michel Wijnberg

Jedes Monitoring-Produkt auf diesem Planeten behauptet, “agentenlos” zu sein. Die meisten meinen damit, dass sie sich per SSH anmelden und die Ausgabe von show-Befehlen abgreifen, was in etwa so agentenlos ist, wie ein Einbrecher ein Hausgast ist.

Osprey geht einen anderen Weg, und ich möchte dabei genau sein, einschließlich der Stelle, an der der Marketingsatz nicht ganz stimmt.

Es gibt drei Wege, auf denen Osprey an Daten kommt. Alle drei sind für einen Betreiber sichtbar, der hinsieht (das hier ist kein heimliches Produkt), aber nur einer davon setzt Osprey in die eigene Datenbank eines Routing-Protokolls, und genau der verdient die genaue Prüfung.

1. Der GRE-Recorder: eine echte Nachbarschaft, die niemals Verkehr tragen kann

Der interessanteste Weg. Osprey kann über einen GRE-Tunnel eine echte IGP-Nachbarschaft aufbauen: eine richtige OSPFv2-, OSPFv3- oder IS-IS-Nachbarschaft, mit echten Hellos, echtem DBD-Austausch, echtem Fluten. Es lernt die LSDB so, wie ein Router sie lernt: indem sie ihm mitgeteilt wird.

Das ist strikt besser als eine MIB abzulaufen, denn Sie bekommen die Datenbank so, wie das Protokoll sie tatsächlich verteilt, mit intakten Sequenznummern, Altersangaben und Prüfsummen, und Sie sehen Änderungen in dem Moment, in dem sie geflutet werden, statt beim nächsten Poll-Intervall.

Es bedeutet aber auch, dass die Router tatsächlich einen Nachbarn sehen. Ich sage es unverblümt: Osprey erscheint in der LSDB. Das muss es. RFC 2328 §12.4.1 verlangt, dass jeder Router in einer Area ein Router-LSA vom Typ 1 erzeugt, und ein Router, der eine Nachbarschaft aufbaut, ohne eines zu erzeugen, ist ein kaputter Router.

Die Frage lautet also nicht “können wir unsichtbar sein”, denn das können wir nicht, sondern “können wir außerstande sein, die Weiterleitung zu beeinflussen”. Darauf gibt es eine echte Antwort:

// originateRouterLSA creates and installs our Router-LSA in the LSDB.
// RFC 2328 Section 12.4.1 requires every router to originate a Type 1 LSA.
// We use cost 65535 (maximum) so no router will ever route traffic through
// Osprey. Only the P2P link is advertised. NO stub network for the tunnel
// inner subnet. Advertising the tunnel subnet (even at max cost) causes SPF
// on other routers to install a route for the tunnel prefix, which can
// disrupt the GRE outer path and kill the adjacency.

Darin stecken zwei bewusste Entscheidungen, und die zweite habe ich erst nach einem Laborausfall richtig verstanden.

Maximale Metrik. Der Recorder wirbt seinen einzigen Punkt-zu-Punkt-Link mit den Kosten 65535, und das ist die schwächere der beiden Garantien. Eine Metrik macht einen Pfad nur unattraktiv, und ein unattraktiver Pfad gewinnt trotzdem, wenn er der einzige ist. Die echte Garantie ist die Form: Der Recorder hat genau eine Nachbarschaft, ist also ein Blatt im Graphen, und durch ein Blatt hindurch gibt es keinen Pfad, den irgendein SPF finden könnte. Dazu kommt, dass er kein eigenes Präfix ankündigt, es gibt also auch nichts, wohin man routen könnte. Die maximale Metrik ist doppelt genäht, oben auf einer Topologie, die ohnehin keinen Transit tragen kann.

Kein Stub-Netzwerk. Der Recorder wirbt den P2P-Link und sonst nichts. Insbesondere wirbt er das innere Subnetz des Tunnels nicht als Stub-Netzwerk. Das ist der subtile Teil. Täte er es, würde jeder Router in der Area eine Route in Richtung des Tunnel-Präfixes installieren. Diese Route kann dann den Underlay-Pfad überstimmen, auf dem der GRE-Tunnel selbst reitet, was den äußeren Transport zerstört, was die Nachbarschaft tötet, was den Recorder herauswirft: ein wunderbar selbst zugefügtes Flapping. Nichts Erreichbares anzukündigen vermeidet die ganze Problemklasse und genügt trotzdem RFC 2328.

Die IS-IS-Variante ist strenger

IS-IS bietet für genau diesen Zweck einen eigens dafür gebauten Mechanismus, also nutzt der IS-IS-Recorder ihn. Sein selbst erzeugtes LSP trägt eine Reihe harter Invarianten:

Invariante	Warum
OL-Bit = 1	Das Overload-Bit. ISO 10589 schreibt vor, dass jeder andere Router einen überlasteten Router als Nicht-Transit behandelt. Das ist die primäre Garantie, kein Metrik-Trick.
ATT-Bits = 0000	Zieht niemals L1-Default-Routen an. Ein reiner L1-Router darf seinen Default nicht auf Osprey richten.
P-Bit = 0	Keine Partitionsreparatur.
TLV 22 Metrik = 0xFFFFFF	Maximale Wide Metric, doppelt genäht neben dem OL-Bit.
Kein TLV 128 / 130 / 135 / 236	Das sind die TLVs für IP-Erreichbarkeit. Eines davon zu senden hieße, Routen zu injizieren.
Kein TLV 134	Keine TE-Router-ID. Würde Osprey in die Traffic-Engineering-Datenbank eintragen.
Kein TLV 222 / 242	Keine Multi-Topologie, keine Router Capability, kein Segment Routing.

Lesen Sie diese Tabelle als eine Liste von Dingen, die der Code nicht kann, und nicht als eine Liste von Einstellungen. Es gibt keine Konfigurationsoption, die das Overload-Bit abschaltet, und keinen Codepfad, der ein TLV für IP-Erreichbarkeit zusammenbaut, denn der sicherste Weg, niemals ein Präfix anzukündigen, ist, das Ankündigen gar nicht erst zu implementieren.

Also: sichtbar, teilnehmend und strukturell außerstande, auch nur ein einziges Paket anzuziehen. Das ist eine viel stärkere Aussage als “unsichtbar”, und anders als “unsichtbar” ist sie wahr.

2. SNMP: die LSDB auf die langweilige Art, plus alles, was die LSDB nicht trägt

Nicht jedes Gerät lässt Sie eine Nachbarschaft aufbauen, und manche Dinge stehen schlicht in keiner Link-State-Datenbank. Also fragt Osprey auch ab.

SNMP-Ziele: 192 Geräte, alle aktiv, 300-Sekunden-Poll-Intervall, Zugangsdaten maskiert

192 Ziele in diesem Labor, jedes grün, im 300-Sekunden-Takt abgefragt, letzter Poll in Sekunden gemessen.

Die Spalte mit den Zugangsdaten zeigt ***, und es lohnt sich, genau zu sein, wo diese Schwärzung passiert: im API-Handler, nicht im Browser. Zugangsdaten werden mit AES-256-GCM verschlüsselt gespeichert, und jeder Lesepfad schickt die Antwort vor dem Serialisieren durch eine Maske. Das Frontend bekommt den Community-String und die v3-Auth-/Priv-Passwörter also gar nicht erst, und deshalb gibt es keinen “Anzeigen”-Knopf, und es könnte auch keinen geben, ohne den Server zu ändern.

Maskieren im Client ist Theater. Maskieren im Handler ist eine Kontrolle.

SNMP erledigt hier vier Aufgaben:

LSDB-Rekonstruktion dort, wo kein Recorder angeschlossen ist (daher stammen die 13.382 LSAs aus dem vorherigen Beitrag, mit den ehrlich deklarierten fehlenden Header-Feldern)
Interface-Zähler für Traffic, Fehler und Auslastung
EIGRP, das überhaupt keine Datenbank zum Beitreten hat und vollständig aus der CISCO-EIGRP-MIB gelesen wird
L2-Nachbarn über LLDP und CDP

Der letzte Punkt wiegt schwerer, als er klingt:

CDP-/LLDP-Nachbarn: 303 Nachbarschaften, 66 eindeutige Gegenstellen

303 L2-Nachbarschaften, 66 eindeutige Gegenstellen. Das ist die Schicht, die Osprey sagen lässt, welchen physischen Port eine AS-übergreifende BGP-Sitzung tatsächlich überquert, statt vage auf “irgendeinen Link zwischen diesen beiden Routern” zu deuten, und einen dieser AS-übergreifenden Links sehen Sie direkt in der Tabelle: den CDP-Eintrag von ams1-gw1 Et1/1 nach e-ams1-gw1, das ist die Grenze zwischen AS 200 und AS 100.

3. BMP: die Router reden lassen

Bei BGP ist der bevorzugte Weg nicht, zu fragen. Sondern zuzuhören.

BMP (RFC 7854) ist ein Protokoll, bei dem der Router seine Adj-RIB-In, also die Pfade, die seine Peers ihm angekündigt haben, über eine einfache TCP-Sitzung an eine Monitoring-Station schickt. Es gibt keine Poll-Schleife, kein Parsen von show ip bgp und keine Abfragelast auf der Control Plane über die Sitzung hinaus. Der Router entscheidet, was er wann sendet.

BGP-Peers: 378 Sitzungen über 57 Peers, 374 up, 4 down

378 Sitzungen über 57 Peers hier, aber nicht alle sind auf demselben Weg angekommen, und dieser Unterschied wird festgehalten statt weggeglättet.

Sechs Router in diesem Labor sind BMP-Exporter (ams1-gw1, jfk1-gw1, e-ams1-gw1, e-sin1-gw1, i-jfk1-gw1, i-sin1-gw1), und auf sie entfallen 24 Sitzungen: darunter jede eBGP-Sitzung im Labor. Die übrigen 354 kommen aus SNMP-Walks der BGP4-MIB auf Routern, die überhaupt kein BMP exportieren.

Beide Wege zu den Daten sind legitim und beide sind es wert, gegangen zu werden; sie sind nur nicht gleich gut. Ein BMP-Feed trägt jeden Pfad, den der Peer angekündigt hat, dazu Peer Up und Peer Down so, wie der Router sie sieht. Ein SNMP-Walk gibt Ihnen die Sitzungstabelle zum Poll-Zeitpunkt und nichts zwischen zwei Polls. Welche RIB hier zählt: RFC 7854 überwacht die Adj-RIB-In, also das, was 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 diese Exporter nicht senden. Die Best-Path-Auswahl über diese Kandidaten ist daher Ospreys eigene Berechnung und wird auch so gekennzeichnet.

Deshalb trägt jede Zeile eine Spalte source, die festhält, woher sie stammt, und dieser Wert ist weiter oben im Stapel tragend. Wenn Osprey später einen AS-übergreifenden Pfad zusammensetzt und einen domänenübergreifenden Hop begründen muss, zählt eine eBGP-Sitzung als Beleg mit angehängter Herkunft (bmp-peer gegenüber snmp-peer), niemals als anonyme Tatsache. Dieselbe Tabelle, aber abgestuft.

Beide Adressfamilien reiten auf einer einzigen BMP-Sitzung je Exporter, und deshalb sehen Sie IPv4- und IPv6-Zeilen, die sich einen meldenden Router teilen.

Die eBGP-Zeilen in dieser Tabelle sind die interessanten, denn sie sind die Nähte zwischen den drei Mandanten:

Von	AS	Nach	AS
`e-ams1-gw1`	100	`ams1-gw1`	200
`i-sin1-gw1`	300	`e-sin1-gw1`	100
`i-jfk1-gw1`	300	`jfk1-gw1`	200

Ein Dreieck: AS 200 ↔ AS 100 in Amsterdam, AS 100 ↔ AS 300 in Singapur, AS 200 ↔ AS 300 in New York. Sechs Sitzungen, zwölf Zeilen über beide Familien. Dieses Dreieck ist überhaupt erst der Grund, warum domänenübergreifendes Zusammensetzen von Pfaden möglich ist, und es ist das Thema von Beitrag drei.

Was Osprey strukturell nicht kann

Manche Einschränkungen sollte man als Einschränkungen benennen und nicht als Funktionen, denn sie sind der Grund, warum der Rest vertrauenswürdig ist:

Keine Routeninjektion. Der Recorder erzeugt genau ein Router-LSA, das genau einen P2P-Link mit maximalen Kosten beschreibt, und sonst nichts. Es gibt keinen Codepfad, der ein Präfix ankündigt.
Keine Paketweiterleitung. Osprey ist nicht in der Data Plane. Es gibt keine Weiterleitungstabelle, keine FIB, nichts, das man falsch programmieren könnte.
Keine Konfigurationsschreibvorgänge. Das SSH-Terminal in der Oberfläche ist ein Terminal. Die Tastenanschläge sind Ihre, die Sitzung wird zur Prüfung aufgezeichnet, und Osprey selbst setzt nie einen Konfigurationsbefehl ab.
Datenfluss in eine Richtung. Collectors und BMP nehmen auf und veröffentlichen nach NATS; die Engine schreibt nach PostgreSQL; die API bedient das Frontend. Kein Dienst ruft stromaufwärts zurück. Es gibt keinen Weg von der Weboberfläche zu einem Router, außer ein Mensch tippt in ein Terminal.

Die ehrliche Zusammenfassung

Osprey ist passiv in dem Sinne, auf den es ankommt: Es kann keinen Verkehr anziehen, keine Route injizieren und kein Paket weiterleiten. Aber es ist nicht unsichtbar, und das sage ich Ihnen lieber selbst, als dass Sie es aus einem show ip ospf neighbor erfahren, das eine Zeile mehr hat als erwartet.

Wenn ein Hersteller Ihnen erzählt, sein Werkzeug trete Ihrem IGP bei und niemand merke etwas davon, fragen Sie ihn, wie sein Router-LSA aussieht.

Als Nächstes: warum Ihr Pfadwerkzeug Sie vermutlich anlügt, und die Messung über 4.032 Paare, die es beweist: Hop-für-Hop-Wahrheit.