Summary

  • BGP End-of-RIB meldet den Abschluss des initialen Updates für eine Adressfamilie nach Sitzungsaufbau; es bestätigt nicht die Aktualität aller AFI/SAFI.
  • Graceful Restart erlaubt bewusst, Routen als stale zu behalten, während Forwarding weiterläuft. Ersetzung, Entfernung, lokale Auswahl, FIB und Data-Plane-Funktionsfähigkeit bleiben eigene Beweise.
  • Ein Prüfprotokoll pro Peer und Familie muss Neustartursache, ausgehandelte Capability, den Bestand zurückgehaltener Routen, EOR, Bereinigung, FIB und reale Pfadtests verbinden.

Die Sitzung war wieder da, die Belege noch nicht

Stellen wir uns vor, eine BGP-Sitzung wird nach einem Neustart wieder aufgebaut. Der IPv4-Unicast-EOR trifft ein, die Überwachung wird grün. Eine zweite Familie enthält jedoch weiterhin Routen aus der alten Sitzung, und ein Flow nutzt einen Forwarding-Eintrag aus der Zeit vor dem Neustart.

Das widerspricht dem ersten EOR nicht. Er schließt das initiale Update genau einer Familie. Er spricht weder für andere ausgehandelte Familien noch prüft er die Nutzbarkeit des erhaltenen Forwarding-Zustands. Der Fehler liegt nicht im Vertrauen auf EOR, sondern darin, eine begrenzte Protokolltatsache zum globalen Aktualitätsurteil zu machen.

Graceful Restart soll Kontinuität schaffen. Erhaltenes Forwarding kann unnötige Schwankungen und Verluste verhindern. Derselbe Mechanismus erzeugt aber ein Zeitfenster, in dem „wird weitergeleitet“ und „wurde neu validiert“ nicht identisch sind.

Was EOR tatsächlich abschließt

RFC 4724 definiert IPv4-Unicast-EOR als UPDATE ohne erreichbare oder zurückgezogene NLRI. Für andere Familien enthält das UPDATE nur MP_UNREACH_NLRI ohne Rückzüge für das betreffende <AFI, SAFI>. Der Speaker sendet den Marker nach Abschluss des initialen Updates dieser Familie, auch wenn nichts anzukündigen ist.

Der Umfang steckt in der Kodierung. IPv4-EOR sagt nichts über IPv6, VPN, EVPN oder andere Familien. Auch innerhalb der Familie bedeutet er nur, dass der Sender seine geplante Übermittlung beendet hat. Der Empfänger muss Updates anwenden, stale Routen ersetzen, Reste löschen, lokal auswählen und das Forwarding programmieren.

Die RFC trennt EOR-Erzeugung von der Fähigkeit, Forwarding zu erhalten. Ein Speaker kann Graceful Restart ohne irgendeine Adressfamilie ankündigen, nur um EOR-Absicht und Unterstützung für einen neu startenden Peer zu signalisieren. Capability und Marker beweisen daher keinen nutzbaren erhaltenen Zustand.

Das Restart-State-Bit löst ein anderes Abstimmungsproblem. Der neu startende Speaker setzt es im neuen OPEN; sein Peer darf dann nicht auf den EOR dieses Speakers warten, bevor er ihm Routen erneut ankündigt. Nach Wiederaufbau der Sitzung verschiebt der neu startende Speaker die Auswahl für eine Adressfamilie, bis die EORs der maßgeblichen Peers eingetroffen sind oder der Selection_Deferral_Timer abläuft. Erst danach wählt er Routen aus, aktualisiert die Weiterleitung, entfernt seine eigenen stale Informationen und sendet den EOR dieser Familie.

Ein EOR-Zeitpunkt ohne diese Abfolge verwechselt den Abschluss der Peer-Updates mit dem Abschluss der lokalen Weiterleitung.

Gehaltene Routen sind ausdrücklich stale

Verliert der Empfänger die Sitzung eines Peers, der Graceful Restart für eine Familie angekündigt hat, hält er dessen Routen und markiert sie stale. Beim Forwarding unterscheidet er sie nicht von anderen Informationen. Das ist beabsichtigte Kontinuität, keine Aktualitätsaussage.

Die Bereinigungsregeln liefern die Zeitgrenze. Kommt die Sitzung nicht innerhalb der Restart Time zurück, werden die stale Routen gelöscht. Nach dem Wiederaufbau gilt dasselbe sofort, wenn die neue Capability die Familie auslässt, das Forwarding-State-Bit fehlt oder keine Capability empfangen wird. Neue Updates ersetzen stale Routen; mit dem EOR der Familie werden verbleibende stale Einträge entfernt.

Entscheidend sind Identität und Schicksal der Routen, nicht die Farbe der Sitzung. Vor EOR können Routen auf Ersatz warten. EOR setzt die Grenze zur Restbereinigung. Danach müssen lokale Auswahl und FIB noch ein nutzbares Ergebnis erzeugen.

Forwarding-Funktionsfähigkeit ist eine andere Beobachtung

Das Forwarding-State-Bit je Familie betrifft die Erhaltung während des Neustarts. RFC 4724 bindet es, mit einer Einschränkung für konfigurierte Ausnahmen, an die tatsächlich bewahrte Weiterleitungsinformation. Es ist kein Pakettest. Wie die Nutzbarkeit der Weiterleitung beim Peer bestimmt wird, bleibt außerhalb des RFC; BFD und Layer-2-Überwachung sind nur Beispiele.

Ein beibehaltener Next Hop kann ausfallen, während Routen weiter vorgehalten werden. Das lokale FIB kann dem RIB hinterherlaufen. Blackholes oder Schleifen sind trotz wiedergekehrter Sitzung und verarbeitetem EOR möglich. Umgekehrt bedeutet stale nicht automatisch Ausfall: Die Weiterleitung kann die gewünschte Kontinuität liefern.

RFC 8538 erweitert die Graceful-Restart-Verarbeitung bei ausgetauschtem N-Bit auf geeignete NOTIFICATION-Nachrichten und den Ablauf der Hold Time. Beide Speaker agieren dann als Empfänger und halten gegenseitig Routen. Hard Reset verlangt einen vollständigen Neustart. Bei ausgetauschtem N-Bit wird die Regel gelockert, nach der eine bereits als stale markierte Route bei aufeinanderfolgenden Neustarts gelöscht wird; der stale timer wird damit zur entscheidenden Grenze gegen unbegrenzte Aufbewahrung. Die Erweiterung schreibt diesen konfigurierbaren Timer vor, schlägt 180 Sekunden vor und warnt vor langer oder unbegrenzter Erhaltung.

Quellen