Zusammenfassung

  • Revision 19 macht BFD Up nur dann zur ausgehandelten BGP-Zulassungsbedingung, wenn beide OPEN-Nachrichten Capability 74 enthalten; die lokale Konfiguration allein beweist diesen Vertrag nicht.
  • Neue Pending-Substates bewahren die Reihenfolge auseinanderlaufender Ereignisse, etwa wenn ein KEEPALIVE eintrifft, bevor das lokale BFD Up erreicht hat.
  • Eine belastbare Störungsanalyse muss Modus, Release, gesendete und empfangene Capability, beide Timer-Linien, Schließungsgrund und Verkehrsergebnis in einer reproduzierbaren Kausalkette erhalten.

Im ersten Protokoll stand: BFD wurde nicht rechtzeitig stabil. Im zweiten: BGP Hold Timer Expired. Das NOC ordnete dem Vorfall zwei Ursachen zu, weil jedes Gerät nur seine eigene Uhr und seinen eigenen Zustandsautomaten zeigte. Tatsächlich war es ein einziger Ablauf: Ein Peer durfte bereits Established sein, während der andere wegen seines lokalen Hold-down noch kein KEEPALIVE senden durfte.

Der Fehler lag nicht in einem der beiden Einträge. Er lag in der fehlenden Verbindung zwischen ihnen.

draft-ietf-idr-bgp-bfd-strict-mode-19 schafft für genau diese Verbindung eine präzisere Sprache. Die aktive IDR-Arbeitsgruppenfassung vom 26. August 2026 will, falls angenommen, RFC 4271 aktualisieren. Ihr Kopf nennt Standards Track, Datatracker führt sie weiterhin als I-D Exists. Die Operations- und Security-Reviews sowie die BGP-Directorate-Bewertung sind laufende Prüfevidenz, keine IETF-Zulassung und kein Nachweis, dass beliebige Produktpaare interoperabel sind.

Der Entwurf adressiert ein reales Ordnungsproblem. In der herkömmlichen Kopplung nach RFC 5882 kann BGP Established erreichen, obwohl die zugehörige BFD-Sitzung noch nicht einsatzbereit ist. Eine beschädigte Verbindung kann deshalb kurz Routen tragen, bevor BFD den Fehler meldet und BGP beendet. Strict Mode kehrt die Reihenfolge um: Erst lokales BFD Up, dann darf der BGP-Zustandsautomat weiter bis Established.

Diese Umkehr reduziert Flapping nur dann, wenn beide Seiten dasselbe Eintrittskriterium, dieselbe Art der Zustimmung und kompatible Zeitannahmen verwenden. Andernfalls wird aus dem Schutzmechanismus selbst die Ursache eines schwer lesbaren Ausfalls.

Ein Capability-Code ist noch keine Kausalkette

Revision 19 weist der BFD Strict-Mode Capability den Code 74 zu. Ein unterstützender Speaker sendet die leere Capability in OPEN. BfdStrictNegotiated wird erst wahr, wenn sowohl die lokale als auch die entfernte OPEN-Nachricht sie enthält. Der Entwurf trennt damit Konfigurationsabsicht, gesendetes Angebot, empfangenes Gegenangebot und ausgehandeltes Ergebnis.

Diese Trennung muss in der Telemetrie erhalten bleiben. Ein Feld strict=true kann nicht zeigen, ob das Gerät lediglich angeboten, bilateral vereinbart, unilateral blockiert oder einen Override angewandt hat. Aktuelle Cisco-Dokumentation unterscheidet einen proprietären beziehungsweise einseitigen Strict Mode, strict-mode-negotiate und ein Override, das die Schranke auch ohne Capability des Peers erzwingt. Juniper beschreibt die gegenseitige Ankündigung und empfiehlt übereinstimmende Konfiguration. Daraus folgt kein Produkturteil. Es folgt lediglich, dass ein gemeinsames Etikett mehrere Autoritätsmodelle überdeckt.

Für eine Ursachenanalyse braucht das Inventar deshalb den exakten Befehl samt Scope, seine Bedeutung im laufenden Release, Capability 74 gesendet und empfangen, das Verhandlungsergebnis und jeden Override mit Besitzer. Fehlt eines davon, lässt sich aus dem Endzustand Idle nicht rekonstruieren, ob eine Vereinbarung fehlte oder eine lokale Regel sie bewusst ersetzte.

Der Security-Review setzt eine weitere Klammer. Capability-Verhandlung ist nur so vertrauenswürdig wie die Integrität des OPEN-Austauschs. Ein On-Path-Angreifer, der Capability 74 entfernt, könnte den bilateralen Mechanismus abschalten, sofern der BGP-Kanal nicht angemessen geschützt ist. Umgekehrt kann ein lokaler Override die Schranke trotz fehlender Remote-Ankündigung aufrechterhalten. Beobachtete Bits sind Belege für Nachrichten; sie sind kein selbstauthentisierendes Mandat.

Pending-Substates erhalten den zeitlichen Zusammenhang

Nach erfolgreicher Verhandlung führt Revision 19 Wartezustände für Connect, Active und OpenSent. Ein Gerät kann OPEN ausgetauscht haben und sein KEEPALIVE dennoch zurückhalten, weil das lokale BFD noch nicht Up ist. Die andere Seite kann BFD früher hochbringen und ein KEEPALIVE senden. Dann gilt gleichzeitig: Der entfernte BGP-Handshake ist fortgeschritten, und die lokale Zulassungsbedingung ist noch nicht erfüllt.

OpenSentConfirmedBfdUpPending hält beide Aussagen fest. Genau darin liegt sein diagnostischer Wert. Eine vereinfachte Ampel müsste entweder das empfangene KEEPALIVE unterschlagen oder fälschlich behaupten, die lokale BFD-Bedingung sei erfüllt. Der BGP-Directorate-Review zu Revision 18 hatte den Race hervorgehoben: Gewöhnliche OpenSent-Verarbeitung könnte das frühe KEEPALIVE als FSM-Fehler behandeln und TCP zurücksetzen. Revision 19 gibt dem Ereignis einen expliziten Ort.

Ein Substate ist daher mehr als interne Implementierungsprosa. Er ist ein kausaler Beleg: Dieses Ereignis ist eingetroffen, jenes lokale Prädikat aber noch falsch. Ohne Zeitstempel und Sichtbarkeit dieses Belegs bleibt dem Operator nur das spätere Cease oder Idle – also die Wirkung ohne ihren Weg.

Fällt BFD vor der Etablierung im ausgehandelten Strict Mode, sendet BGP Cease mit dem Subcode BFD Down, schließt TCP, gibt Ressourcen frei und kehrt zu Idle zurück. Nach Established werden zusätzlich die über die Verbindung gelernten Routen gelöscht. RFC 9384 verbessert damit die unmittelbare Schließungsbegründung. Der Subcode beweist aber nicht, ob ein physischer Fehler, asymmetrische Konfiguration, Timer-Geometrie, Paketunterdrückung, Überlastung, Authentisierung oder Softwareverhalten dahinterstand.

Zwei lokale Uhren bilden keinen gemeinsamen Timer

Der Entwurf definiert eine konfigurierbare BfdHoldTime mit 30 Sekunden Vorgabe sowie BfdHoldTimer für den Fall, dass die ausgehandelte BGP-Holdtime null ist. Zusätzlich kann ein BFD-Hold-down verlangen, dass BFD erst eine Stabilitätsdauer in Up verbringt. Diese Hold-down-Werte sind lokal. Der Text empfiehlt ähnliche Einstellungen, handelt aber keine gemeinsame Zahl aus.

Damit kann ein Peer Established erreichen und seine BGP-Holdtime starten, während der andere noch im BFD-Hold-down steckt und kein KEEPALIVE senden darf. Läuft die erste Uhr ab, beendet der eine Peer die Verbindung; der andere meldet weiterhin eine legitime Pending-Bedingung. Beide Protokolle sind sachlich richtig, aber erst ihre Zeitachsen erklären den Vorfall.

Die Juniper-Dokumentation zu 23.2R2 enthält ein besonders nützliches Warnsignal: Strict Mode plus Holddown auf einer Seite und fehlende entsprechende Einstellungen auf der anderen können zu dauerhaftem Idle führen – eine Seite wartet auf BFD, die andere auf BGP. Das ist weder ein Beleg für einen konkreten Kundenfall noch für einen universellen Defekt. Es ist ein dokumentiertes Beispiel dafür, dass lokale Abhängigkeiten gemeinsam einen Kreis bilden können.

Auch die Implementierungsstände gehören in die Zeitachse. Der Anhang des Entwurfs nennt Junos ab 23.2R1 mit Bezug auf Revision 17, IOS XR ab 24.3.1 mit Bezug auf Revision 12 und Nokia 23.7R1 mit Bezug auf Revision 07; bei der genannten Nokia-Fassung fehlt BfdHoldTimer. Diese Selbstauskünfte in einem Arbeitsentwurf sind keine Zertifizierung. Sie zeigen aber, dass Capability 74 mehrere Entwicklungszeitpunkte verbinden kann. Ein später hinzugefügter Event, Timer oder Übergang ist nicht automatisch Teil jedes laufenden Codes, der denselben Capability-Code sendet.

Der Betriebsbeleg muss einen Graphen statt einer Liste bilden

Vor dem Change braucht jeder Peer eine eigene Zeile: Plattform, Release, genauer semantischer Modus, dokumentierter Verhaltensstand, BGP-Holdtime, BFD-Holdtime, Hold-down, Authentisierung und erwartete Pending-Substates. Während des Tests müssen Capability 74 gesendet und empfangen, BfdStrictNegotiated, BFD-Endpunkte und Discriminators, Übergangszeiten, BGP-Substate, Notification-Grund und das tatsächliche Verkehrsergebnis erfasst werden.

Diese Werte dürfen nicht nur nebeneinanderstehen. Sie müssen über gemeinsame Sitzungskennung und monotone Zeit zu einem Graphen verbunden sein: OPEN wurde hier gesendet; dort empfangen; BFD ging auf der Westseite hoch; dort begann Hold-down; das frühe KEEPALIVE traf ein; die Ostseite blieb im benannten Pending-State; anschließend lief jene Holdtime aus. Erst dann lässt sich eine Ursache falsifizieren oder reproduzieren.

Ein guter Canary provoziert die schwierigen Reihenfolgen. Nur eine Seite bietet Verhandlung an. Die Hold-down-Werte unterscheiden sich. Lokales BFD wird verzögert, während der Peer voranschreitet. BFD-Pakete werden kontrolliert unterdrückt, nachdem Routen aktiv sind. Für jede Sequenz wird geprüft, ob der erwartete Substate, Schließungsgrund, Routenabbau und Rollback erscheinen. Ein einmaliges „Session kam hoch“ testet nicht die Fälle, für die Strict Mode gebaut wurde.

Auch der Rollback braucht eine Kausalkette. Das Entfernen der lokalen Schranke beweist nicht, dass der Peer nicht mehr wartet. Eine Konfigurationsänderung nach Established kann für die laufende Sitzung ignoriert werden und erst beim Neustart wirken. Daher legt der Plan Reihenfolge und Neustartpunkt fest, bestätigt beide effektiven Modi und bewahrt die Daten der gescheiterten Sequenz.

Heng Lus Prinzip der Running-Code Primacy ordnet die Evidenz richtig. Die Spezifikation definiert die kleinste gemeinsame Regel. Implementierungen bilden Kompatibilitätsmengen. Betreiber übernehmen ein Verhalten, indem sie genau diese Paarung ausführen, testen und als Gegenpartei akzeptieren. Ein CLI-Name kann diesen Nachweis nicht ersetzen.

BFD Strict Mode ist wertvoll, weil er einen Pfad nicht vor seinem Fehlerdetektor freigeben soll. Doch eine Schranke, deren Ursache nicht über beide Enden erklärt werden kann, ist kein verlässlicher Kontrollpunkt. Der eine Timer lief lokal. Der Ausfall entstand dort, wo zwei lokale Bedeutungen aufeinandertrafen – und nur ein bilateraler Beleg macht diese Stelle sichtbar.

Quellen