Zusammenfassung

  • Der klassische HoldTimer misst den letzten empfangenen BGP-Nachrichtenverkehr. Er kann frisch bleiben, obwohl lokale UPDATEs, Rückzüge und KEEPALIVEs in Gegenrichtung blockiert sind.
  • RFC 9687 ergänzt einen lokal konfigurierten SendHoldTimer. Ohne erfolgreiche BGP-Sendung innerhalb der Frist protokolliert der Router den Grund, gibt Ressourcen frei, schließt TCP und wechselt nach Idle.
  • Sicherer Betrieb trennt Nachrichtenerzeugung, Sendeerfolg, entfernte Verarbeitung und Weiterleitung, setzt den Wert über den ausgehandelten HoldTime und begrenzt Wiederverbindungsschleifen.

Ein Edge-Router hat eine ausgefallene Route bereits verworfen und den Rückzug erzeugt. Der Nachbar sendet jedoch weiterhin alle dreißig Sekunden KEEPALIVE; jeder Empfang startet den HoldTimer neu. In der anderen Richtung liest die entfernte Anwendung nicht mehr. Die lokale Sendewarteschlange wächst, während die zuletzt zugestellte, nun veraltete Route am Nachbarn wirksam bleibt.

Die richtige Entscheidung existiert. Sie kann nur nicht mehr zu gemeinsamem Zustand werden.

Bidirektionales TCP garantiert keine Symmetrie

TCP stellt zwei Datenrichtungen bereit, koppelt deren Fortschritt aber nicht. Das kanonische Beispiel in RFC 9687 ist ein entferntes Empfangsfenster von null. Der Peer kann zum lokalen System weiter BGP senden und zugleich keine Bytes von ihm annehmen. Ein überlasteter Prozess, ein blockierter Leser oder eine defekte Queue erzeugen dieselbe Asymmetrie.

RFC 4271 startet den HoldTimer bei zulässigen UPDATEs oder KEEPALIVEs neu. Das belegt Eingang, nicht Ausgang. Ein erzeugtes UPDATE ist nicht zwingend übertragen; vom Kernel gepufferte Bytes sind nicht zwingend entfernt gelesen; TCP Established beweist keine aktive BGP-Anwendung.

Bei einem blockierten Rückzug behält eine überholte Route Autorität. Deshalb ist der Zeitpunkt der letzten erfolgreichen BGP-Sendung eine eigene, unverzichtbare Größe.

Die lokale Uhr aus RFC 9687

RFC 9687 ergänzt SendHoldTime, SendHoldTimer und Ereignis 29 SendHoldTimer_Expires. SendHoldTime ist eine lokale Richtlinie pro Peer, keine ausgehandelte Fähigkeit. Der Nachbar muss den Mechanismus nicht kennen.

Beim Eintritt in Established aus OpenConfirm startet der Timer, sofern der Wert ungleich null ist. Jede erfolgreich gesendete BGP-Nachricht startet ihn neu. Er stoppt beim Verlassen von Established sowie bei SendHoldTime oder ausgehandeltem HoldTime null. Ein Wert ungleich null muss größer als der ausgehandelte HoldTime sein.

RFC 9687 empfiehlt die standardmäßige Aktivierung und als Vorgabe den größeren Wert aus acht Minuten und dem Doppelten des HoldTime. Das ist kein universelles Tuning. Route-Server, Reflektoren, Transit-Peers und knappe Geräte haben andere Last- und Resetkosten.

Bei Ablauf muss das System Send Hold Timer Expired protokollieren, BGP-Ressourcen freigeben, TCP schließen, Wiederanlaufzustand aktualisieren und nach Idle wechseln. Eine NOTIFICATION darf nur versucht werden, wenn sie den Abbau nicht verzögert. IANA weist Fehlercode 8, Subcode 0 zu. Da die Störung selbst die Zustellung verhindern kann, bleibt die lokale Chronik maßgeblich.

Vier Instrumente, vier Fragen

HoldTimer beobachtet BGP-Empfang. SendHoldTimer beobachtet lokalen BGP-Sendefortschritt. BFD prüft die Kontinuität eines Weiterleitungspfads. TCP-Wiederholung und Keepalive betreffen Transport. Ihre Aussagen dürfen auseinanderfallen.

BFD und TCP können gesund erscheinen, eingehende KEEPALIVEs den HoldTimer erneuern und der SendHoldTimer dennoch ablaufen. Die Chronik muss lokalen Empfang, lokalen Versand, entfernte Routenverarbeitung und Paketweiterleitung getrennt führen.

SendHoldTimer erkennt nicht jeden BGP-Zombie und beweist keinen Datenebenenfehler. Er begrenzt das Warten bei anhaltender Unfähigkeit, eine BGP-Nachricht zu senden.

Ein Reset ist nicht kostenlos

Das Schließen der Sitzung entwertet gelernte Routen, löst Best-Path-, FIB- und Ersatzanzeigen aus und kann nach Wiederverbindung eine Volltabelle übertragen. Gleichzeitige Abläufe an Reflektor oder Route-Server werden zur Konvergenzwelle.

Eine zu kurze Zeit macht vorübergehende Planungspausen, Gegendruck oder ein kurzes Nullfenster zum vermeidbaren Ausfall. Bleibt der Empfänger überlastet, verstärken Wiederverbindung und Volltabelle die Ursache und erzeugen Oszillation. Eine zu lange Zeit verlängert veraltete Autorität.

Die Wahl berücksichtigt HoldTime, gemessene Pausen, UPDATE-Spitzen, CPU, Routenvolumen, Queues und Wiederanlaufkosten. Peerklassen brauchen eigene Margen. Oszillationsdämpfung kann Versuche verlangsamen, repariert aber keinen verhungerten Leser.

Der Canary muss den Pfad erhalten

Ein abgezogenes Interface testet BFD oder HoldTimer, nicht die gewünschte Asymmetrie. Der richtige Versuch hält Weiterleitung und eingehendes BGP am Leben, während die entfernte BGP-Lesefunktion kontrolliert stoppt.

BIRD 3.3.0 dokumentiert disable rx ausschließlich für Tests und warnt vor Produktion. Im isolierten Labor werden vorab Build, HoldTime, SendHoldTime, Timer und normale Queue aufgezeichnet. Während des Fehlers belegen fortlaufende KEEPALIVEs, eingefrorener letzter Versand, Queue oder Nullfenster und ein kontrollierter blockierter Rückzug den Zustand.

Beim Ablauf werden Grund, Zeitpunkt, NOTIFICATION-Versuch, TCP-Schluss und Idle erfasst. Danach sind Wiederverbindung ohne Schleife, korrigierte Route, FIB und Pakete zu prüfen. FRRouting-Supportliste und BIRD-Befehl sind Implementierungsbehauptungen; der eingesetzte Build braucht Laufzeitbelege.

Entscheidungsrecht verlangt Beweishoheit

Wer eine kritische Zusammenschaltung schließen darf, muss letzte erzeugte Nachricht, letzte erfolgreiche Sendung, Queuealter und -tiefe, TCP-Fenster, Wiederholungen, Eingänge, Timerverlauf und Endgrund aufbewahren. Auch blockierte Rückzüge, Dauer der entfernten Altsicht und spätere Konvergenz gehören dazu.

Die Daten liegen oft in Daemon, Betriebssystem, Collector, Peerportal und NOC getrennt. Praktische Datensouveränität heißt, sie verbinden, halten und verwenden zu können. Befugnis ohne Beleg ist willkürlich; Beleg ohne Handlungsrecht wirkungslos.