Zusammenfassung

  • RFC 1267 ließ zu Beginn die vollständige BGP-Routingtabelle und danach nur Änderungen übertragen; jeder Sprecher musste deshalb die aktuelle Peer-Tabelle für die Dauer der Verbindung halten.
  • RFC 4271 machte den Verbindungsabbruch zum impliziten Rückzug. RFC 4724 erlaubte ausgehandelte, pro Adressfamilie als stale markierte Ausnahmen bis zu Ersatz, End-of-RIB oder Ablauf.
  • RFC 8538 stellte mit Hard Reset die vollständige Invalidierung ausdrücklich wieder her; RFC 9494 band längere LLGR-Erinnerung an Kennzeichnung, niedrigste Präferenz, Ausbreitungsgrenzen und positive Konfiguration.

Die Peer-Tabelle hatte eine Sitzungsnummer

RFC 1267 organisierte BGP-3 um eine vollständige Anfangsübertragung. Nach Aufbau des Transportkanals und Austausch der Eröffnungsnachrichten floss die gesamte BGP-Routingtabelle. Anschließend enthielten UPDATE-Nachrichten nur noch die Änderungen.

Die eingesparte Wiederholung verlangte einen gemeinsamen Ausgangszustand. Ein Inkrement ist ohne seine Vorgeschichte unvollständig. Daher musste jeder Sprecher die aktuelle Fassung der Routingtabelle jedes Peers während der Verbindung behalten.

Die Dauer der Verbindung war zugleich der Gültigkeitsrahmen. KEEPALIVE prüfte ihre Lebendigkeit. Ein Fehler führte zu NOTIFICATION und Schließung; der Zustandsautomat gab verbindungsbezogene Ressourcen frei und kehrte in Richtung Idle oder Active zurück.

Die gespeicherte Tabelle war somit kein dauerhaftes Identitäts-, Eigentums- oder Berechtigungsregister. Sie war eine Kontrollplaneingabe aus einer bestimmten Unterhaltung. Eine laufende TCP-Verbindung bestätigte weder jede Route noch passende Weiterleitung. Ein Speicherfund war kein Liefernachweis.

Die Grundregel führte ein Invalidierungsbuch

RFC 4271 trennte Adj-RIBs-In für empfangene Routen, Loc-RIB für die lokale Auswahl und Adj-RIBs-Out für vorbereitete Ankündigungen. Empfang, Entscheidung und Export bleiben dadurch prüfbare, verschiedene Schritte.

Für den Rückzug nennt die Spezifikation drei Wege: explizit zurückgezogene NLRI, Ersatz durch eine neue Route oder das Schließen der BGP-Verbindung. Beim Schließen werden sämtliche vom Sprecherpaar ausgetauschten Routen implizit aus dem Dienst entfernt.

Die Fehlerbehandlung leert die zugehörige Adj-RIB-In, erklärt davon abhängige Loc-RIB-Einträge für ungültig, berechnet die beste Route neu und kündigt Rückzüge oder Ersatz an. Nicht der physische Nachbar wird damit für verschwunden erklärt. Seine sitzungsspezifische Kontrollebenenevidenz verliert die reguläre Gültigkeit.

Eine abgeleitete Weiterleitung kann vorübergehend noch existieren. Sie gehört in ein anderes Register. Ihr bloßes Fortbestehen schreibt der abgelaufenen Eingabe keine neue Autorität zu.

Graceful Restart buchte eine befristete Ausnahme

RFC 4724 behandelte den Fall, dass die BGP-Kontrollebene neu startet, während Weiterleitungszustand möglicherweise erhalten bleibt. Diese Möglichkeit wird nicht aus einem TCP-Abbruch erraten. Die Graceful Restart Capability muss ausgehandelt und auf konkrete AFI/SAFI bezogen sein.

Capability-Unterstützung, Restart State und Forwarding State beantworten getrennte Fragen. Den Mechanismus zu verstehen ist kein Neustart. Ein Neustart beweist keine erhaltene Weiterleitung. Eine Weiterleitungsbehauptung beweist keinen Paketweg.

Der Empfänger darf nur Routen der ausgehandelten Familien behalten und muss sie als stale markieren. Die Markierung ist kein Gütesiegel. Sie weist aus, dass die Route trotz verlorener Sitzung vorübergehend unter einer Ausnahme verwendet wird.

Die Ausnahme wird mehrfach fällig. Kehrt die Sitzung nicht innerhalb der Restart Time zurück, müssen die alten Routen weg. Bestätigt die neue Sitzung den Forwarding State nicht, fehlt die Familie oder fehlt die Capability, endet die Aufbewahrung sofort. Neue UPDATEs ersetzen passende alte Einträge.

End-of-RIB schließt anschließend die Anfangslieferung einer Adressfamilie. Auch ohne eine einzige Route kann ein leeres UPDATE das Ende erklären. Danach werden alle noch stale gebliebenen Routen dieser Familie gelöscht. Schweigen wird durch einen ausdrücklichen Abschlussbeleg ersetzt.

Dieser Beleg betrifft die Kontrollebene. RFC 4724 warnt weiterhin vor vorübergehenden Schleifen und Blackholes sowie vor geringerem Nutzen, wenn IGP und BGP gleichzeitig ohne abgestimmte Kontinuität neu starten. Tabellenabschluss, Weiterleitung und Dienstwiederkehr sind keine Synonyme.

Hard Reset strich die Ausnahme

RFC 8538 führte das ausgehandelte N-Bit ein. Wenn beide Peers es ausgetauscht haben, kann Graceful Restart auch nach NOTIFICATION-Empfang oder Hold-Time-Ablauf greifen. Eine Fehlerklasse wird dadurch ausdrücklich zugelassen, nicht pauschal jeder Fehler.

Cease/Hard Reset verlangt dagegen das vollständige Verhalten der Grundregel. Der verschachtelte Fehlergrund und die Entscheidung, alten Zustand nicht zu halten, müssen getrennt aufgezeichnet werden. Hard Reset diagnostiziert die Ursache nicht vollständig; es streicht die Speichererlaubnis.

Die Spezifikation verlangt einen konfigurierbaren stale-Timer, schlägt 180 Sekunden vor und untersagt unendliche Aufbewahrung als Standard. Wiederholte Resets dürfen einen nie erneuerten Eintrag nicht unbegrenzt verlängern.

LLGR erhöhte Laufzeit und Haftung

RFC 9494 verlängert mit Long-Lived Graceful Restart die Aufbewahrung über die gewöhnliche Restart Time hinaus. Der Helper setzt die transitive Community LLGR_STALE; NO_LLGR schließt eine Route aus. Langzeit-stale-Routen erhalten die niedrigste Präferenz und werden normalerweise nicht an Peers ohne LLGR weitergegeben.

Long-Lived Stale Time gilt je AFI/SAFI und darf lokal verkürzt werden. Für jede Familie ist eine positive Konfiguration nötig; standardmäßig darf LLGR nicht aktiv sein. Die zusätzliche Zeit erscheint damit als verantwortete Entscheidung.

Das Dokument warnt, dass eine langzeitig alte Route für gewöhnliche Erreichbarkeit Verbindungsverlust verursachen kann. Niedrigste Präferenz hilft nur, wenn eine bessere Alternative existiert. Begrenzte Ausbreitung beweist weder Next-Hop-Funktion noch aktuelle Policy oder Weiterleitung.

Quellen