Push statt Poll

Die eine Quelle, die zu Ihnen kommt, und die zwei Dinge, die sich daran ändern, was Sie glauben dürfen

4. September 2026 Michel Wijnberg

Jede Quelle in dieser Reihe ist bisher etwas, das Osprey hingeht und fragt. Ein GRE-Recorder tritt einem Bereich bei und fragt nach einer Datenbank. Ein SNMP-Walk fragt ein Gerät nach einer Tabelle. Fragen, warten, empfangen, wiederholen.

BMP ist die einzige, die von selbst ankommt. Der Router öffnet eine TCP-Sitzung zur Monitoring-Station und fängt an zu reden, und er redet weiter, solange er etwas zu sagen hat (RFC 7854). Niemand pollt irgendetwas.

Das klingt strikt besser, und in einer Dimension ist es das. In zwei anderen verändert es, was Sie schließen dürfen, und beide sind interessanter als die Geschwindigkeit.

Was das Von-selbst-Ankommen einbringt

Polling hat ein Abtastintervall, und ein Abtastintervall hat alle Eigenschaften eines Abtastintervalls. Alles, was innerhalb eines Zyklus passiert und sich wieder umkehrt, ist, was Ihre Daten angeht, nicht passiert. Eine Route, die zwischen zwei Walks zweimal flappt, sieht aus wie eine Route, die sich nie bewegt hat.

Ein gepushter Strom hat keinen Zyklus. Ein Withdraw kommt an, weil ein Withdraw passiert ist, und der Zeitstempel darauf ist der des Routers, nicht der des Pollers.

Für BGP zählt das mehr als für die meisten Dinge, denn BGP ändert sich weit häufiger als Topologie. Ein Fünf-Minuten-Walk einer Full Table ist zugleich enorm teuer und, für alles Kurzlebige, blind. Das Push-Modell ist das einzige, in dem die Frage “wann hat sich dieses Präfix geändert” eine vertrauenswürdige Antwort hat.

Kosten eins: Stille bedeutet nichts mehr

Nun der Teil, den Polling geschenkt bekommt.

Ein Poller, der fragt und nichts erhält, weiß genau, was passiert ist: Er hat gefragt und nichts erhalten. Die Abwesenheit ist selbst eine Beobachtung, mit Zeitstempel, und sie lässt sich wiederholen.

Ein Zuhörer, der nichts hört, hat diesen Luxus nicht. Stille ist auf dem Draht dieselbe, ob das Netz ruhig ist oder die Sitzung weg ist, und der zweite Fall ist vom ersten nicht zu unterscheiden, bis Ihnen etwas anderes das Gegenteil sagt.

Die konkrete Gefahr verdient einen Namen, denn sie kehrt die Metrik um, nach der Sie greifen würden. Behandeln Sie eine abgerissene Sitzung als Abwesenheit von Änderung, dann wird der Peer, von dem Sie nichts mehr hören, zum stabilsten Peer in Ihrem Bericht. Die ruhigste Zeile auf dem Schirm ist die, die Sie verloren haben. Jedes Ranking, das nach Churn sortiert, setzt Ihren blinden Fleck nach oben, etikettiert als Ihre gesündeste Beziehung.

Beitrag zwölf behandelt, was Osprey dagegen tut, nämlich einen Sitzungsabriss als Monitoring-Lücke statt als Massen-Withdraw zu erfassen, und ich erzähle das hier nicht noch einmal. Der Punkt für diese Reihe ist enger: Push verschiebt die Last, Stille zu deuten, vom Protokoll zu Ihnen. Das Polling-Modell hat Ihnen diese Antwort gegeben, und Sie mussten nicht darüber nachdenken.

Kosten zwei: Sie lesen das Gespräch von jemand anderem

Die zweite Kostenseite ist subtiler und erzeugt echte Parser-Bugs.

BMP gibt Ihnen keine BGP-Sitzung. Es gibt Ihnen eine Kopie der Nachrichten auf der Sitzung von jemand anderem, verpackt und weitergeleitet. Sie waren bei der Verhandlung nicht dabei, und BGP-Nachrichten sind nicht selbstbeschreibend: Wie Sie ein UPDATE dekodieren, hängt davon ab, worauf sich die beiden Peers in ihrem OPEN geeinigt haben.

Der naheliegende Ansatz ist, den Kontext zu rekonstruieren. Peer Up trägt beide OPEN-Nachrichten, Sie können also lesen, was verhandelt wurde, und es für die Sitzung behalten. Osprey tut das.

Und dann trägt der Per-Peer-Header jeder folgenden Nachricht ein A-Flag, das anzeigt, ob die eingekapselte PDU das alte Zwei-Byte-AS_PATH-Format verwendet (RFC 7854 §4.2). Es gilt pro Nachricht, also dekodiert der Parser diese Nachricht danach, statt das Format aus dem Peer-Up-Kontext anzunehmen.

Diese beiden können sich widersprechen. Wenn sie es tun, dekodiert Osprey nach dem Flag und protokolliert die Diskrepanz, statt sie stillschweigend aufzulösen, und die Begründung ist es wert, ausgesprochen zu werden, weil sie verallgemeinert: Die Capability hält fest, worauf sich zwei Router geeinigt haben, und das Flag beschreibt, was dieser Exporter mit dieser Nachricht getan hat. Wo Belege über eine Vereinbarung und Belege über die vorliegenden Bytes kollidieren, sind die vorliegenden Bytes die, die geparst werden.

Es gibt eine entsprechende Feinheit bei Add-Path, und sie hat dieselbe Form. Ob die eingekapselte NLRI Path Identifier trägt, hängt von einer Verhandlung ab, die gerichtet ist, und welche Richtung gilt, hängt davon ab, welche RIB überwacht wird: die vorgabemäßige Adj-RIB-In oder die Adj-RIB-Out, die RFC 8671 hinzugefügt hat und die durch ein weiteres Flag im selben Per-Peer-Header signalisiert wird. Also liest der Parser dieses Flag zuerst und wählt danach, welcher Verhandlung er glaubt. Dasselbe Feld, zwei Lesarten, ausgewählt durch ein Bit, das Sie nicht konsultieren würden, wenn Sie Partei der Sitzung wären.

Nichts davon entsteht, wenn Sie ein Gerät pollen. Sie fragen ein Gerät über sich selbst, in einem Protokoll, in dem Sie erstklassige Partei sind. BMP reicht Ihnen die eigene Sicht des Routers und nimmt den Kontext weg, in dem sie verhandelt wurde, und jedes Feld, das diesen Kontext rekonstruiert, ist tragend.

Die BGP-Peers-Tabelle mit einer Spalte Source, in der BMP- und SNMP-Marker in derselben Liste stehen. Die BMP-Zeilen wurden zuletzt vor einem Tag gesehen und tragen ausgehandelte Timer und eine Router-ID; die SNMP-Zeilen sagen „gerade eben“ und lassen beides leer

Beide Erfassungswege landen in einer Tabelle, und der Unterschied ist in zwei Spalten sichtbar. Die BMP-Zeilen wurden zuletzt vor einem Tag gesehen, und das ist kein Fehler: an diesen Sitzungen hat sich nichts geändert, und eine Push-Quelle schweigt, wenn sich nichts ändert. Die SNMP-Zeilen sagen gerade eben, weil jemand hingegangen ist und gefragt hat. Dieselbe Aussage, zwei sehr verschiedene Gründe, sie zu glauben, und nur bei einem davon ist Schweigen eine Information.

Der Bericht, der nie kommt, wenn Sie nicht fragen

Eine letzte Sache, und es ist die kleinste und die ärgerlichste.

BMP definiert Statistics Reports: periodische Zähler pro Peer, einschließlich der Ablehn- und Treat-as-withdraw-Zähler, die Ihnen sagen, was die Policy eines Peers verwirft. Ausgezeichnete Daten. Genau das, was man für eine Scorecard will.

Sie kommen nicht an.

Nicht wegen eines Parser-Bugs, und nicht weil der Exporter kaputt wäre. IOS sendet Statistics Reports schlicht nicht, wenn ihm keine Reporting-Periode gesagt wurde, und es gibt keinen Default. Ohne stats-reporting-period unter der BMP-Serverkonfiguration erscheint dieser Nachrichtentyp nie auf dem Draht, und jedes Statistikfeld pro Peer bleibt für immer leer, ohne Fehler irgendwo.

Das Labor lief eine Weile so, und die ehrliche Lesart der leeren Spalten war nicht “dieser Peer lehnt nichts ab”. Sie war “niemand hat diesem Router je gesagt, dass er es sagen soll”. Der Fix war eine Konfigurationszeile auf sechs Routern, in die Startup-Config geschrieben, damit ein Reload die Messung nicht still rückgängig macht.

Das ist ein kleines betriebliches Detail mit einer allgemeinen Form: Eine Push-Quelle kann Ihnen nur sagen, was zu senden sie konfiguriert wurde. Beim Polling kontrollieren Sie, wann die Frage gestellt wird. Beim Push beobachten Sie nur, was der Exporter zu emittieren eingerichtet war, und eine nicht gesendete Nachricht ist von einer nie erzeugten nicht zu unterscheiden.

Der Punkt

Push ist besser, und Push ist nicht umsonst.

Sie gewinnen die einzige Zeitachse, der man für etwas trauen kann, das sich so schnell ändert wie BGP, und Sie geben die zwei Dinge auf, über die Polling Sie nie nachdenken ließ: dass Stille früher eine Beobachtung war, und dass Sie früher Partei des Gesprächs waren, das Sie gelesen haben.

Beide erscheinen in dieser Codebasis als kleine, konkrete Sorgfaltsstücke. Ein Sitzungsabriss, als Lücke erfasst. Eine AS_PATH-Breite, aus dem Flag statt aus der Capability genommen. Eine Statistikspalte, die leer bleibt und weiß, warum. Keines davon ist raffiniert. Sie sind alle dasselbe Eingeständnis, nämlich dass eine von selbst ankommende Nachricht Ihnen weniger über ihre eigene Abwesenheit sagt als eine Frage, die Sie selbst gestellt haben.

Damit schließt diese Reihe. Die Durchgangslinie, wenn es eine gibt, ist, dass jede Antwort in diesem Produkt genau so viel wert ist wie die Rechenschaft, die sie darüber ablegen kann, wie sie zustande kam.