Zusammenfassung

  • RFC 9494 kann Routen über das gewöhnliche Graceful-Restart-Fenster hinaus behalten, jedoch nur je ausgehandeltem AFI/SAFI und für eine endliche Long-Lived Stale Time. LLGR_STALE kennzeichnet und depreferenziert sie.
  • Enke Chen ist Mitautor von RFC 4724 und RFC 9494. Die Erweiterung bestätigt keinen alten Pfad: lokale Zeitgrenzen, NO_LLGR, End-of-RIB-Synchronisierung, Ablauf und dokumentierte Loop-Risiken halten die Nutzung widerruflich.

Ein gespeicherter Pfad ist noch keine Gegenwart

Nach dem Verlust eines BGP-Nachbarn bleiben Nexthops, Labels oder Tunnel mitunter im Forwarding-Chip erhalten. Eine sofortige vollständige Rücknahme kann einen beherrschbaren Neustart des Control Plane zu einem Ausfall machen. Ein langes Festhalten kann dagegen Paketverlust verbergen, weil die Tabelle ruhig aussieht, obwohl niemand den alten Zustand erneuert.

Nicht jede über BGP verteilte Information altert gleich. Konventionelle Unicast-Reachability steht nahe an einer Hop-by-Hop-Entscheidung. VPN-Entdeckung, Signalisierung oder Zustände über einem getunnelten Netz können einen anderen Zusammenhang mit der ausgefallenen Sitzung haben. Genau deshalb wäre ein globaler Standardwert keine neutrale Vereinfachung.

Die Aufgabe lautet vielmehr: Das Protokoll muss den schwächeren Status ausdrücken; der Betreiber muss entscheiden, ob dieser Status für eine bestimmte Familie noch nützlich ist. Dauer, Forwarding-Modell und Abbruchgrund gehören zusammen.

Das erste Zeitfenster ist zwölf Bit breit

RFC 4724 erschien 2007 und nennt Srihari Sangli, Enke Chen, Ramachandra Fernando, John Scudder und Yakov Rekhter als Autoren. Sie definiert Graceful Restart Capability und End-of-RIB. Der neu startende Speaker kann Forwarding-Zustand bewahren; der Empfänger darf Routen des Peers als stale markieren und während der Rekonstruktion vorerst behalten.

Restart Time ist ein 12-Bit-Feld, also höchstens 4.095 Sekunden groß. Als Vorgabe empfiehlt RFC 4724 einen Wert, der den HOLDTIME aus OPEN nicht übersteigt. Kehrt die Sitzung nicht rechtzeitig zurück, müssen die Routen weg. Erkennt der Empfänger früher, dass das Forwarding des Peers nicht mehr lebensfähig ist, darf er sie vorher löschen.

Während dieses gewöhnlichen GR-Fensters sinkt die Routenpräferenz nicht. Das Verfahren unterdrückt Churn unter der Annahme einer kurzen Wiederherstellung. RFC 8538 erweiterte später die Sitzungsabbrüche, nach denen GR möglich ist, und führte Hard Reset für die vollständige Bereinigung ein. Der erhaltene Zustand blieb eine zeitlich begrenzte Annahme.

Eine zweite Phase mit geringerem Rang

RFC 9494 wurde im November 2023 mit James Uttaro, Enke Chen, Bruno Decraene und John G. Scudder als Autoren veröffentlicht. Chens Namensnennung in Basis und Erweiterung belegt seinen Anteil an zwei kollektiven IETF-Ergebnissen. Sie belegt weder eine Einzelerfindung noch eine bestimmte Hersteller- oder Betreiberimplementierung.

LLGR Capability hat Code 71 und führt Tupel aus <AFI, SAFI, Flags, LLST>. Pro Adressfamilie kann eine andere Long-Lived Stale Time gelten. Das Dokument nennt bewusst keinen Default. Anwendung, Dynamik und Fehlerfolge unterscheiden sich. Der Empfänger kann lokal Ober- und Untergrenzen setzen und die vom Peer angebotene Dauer kürzen.

Die Fähigkeit funktioniert nicht ohne gewöhnliches GR. Fehlt die begleitende Graceful Restart Capability, muss LLGR ignoriert werden. Sind beide Zeiten positiv, folgen die Phasen aufeinander: zuerst GR ohne Preference-Änderung, danach LLGR mit Depreference. Eine Restart Time von null überspringt die erste Phase.

Damit wird nicht nur eine Uhr verlängert. Im kurzen Fenster genießt der Zustand eine knappe Erwartung baldiger Bestätigung. Im langen Fenster ist die Evidenz bereits schwächer. Fortgesetzte Verwendbarkeit darf dort nicht dieselbe Auswahlmacht behalten.

Die Unsicherheit muss mitwandern

Beim Beginn von LLGR startet der Helper einen LLST-Timer je AFI/SAFI und hängt die Well-known Community LLGR_STALE, Wert 0xFFFF0006, an. Die Route muss hinter jeder nicht als least preferred gekennzeichneten Route stehen. Nur wenn alle Kandidaten auf dieser niedrigsten Stufe liegen, greifen die gewöhnlichen Tie-Breaks.

Eine frische Alternative verdrängt also den alten Pfad. Ohne frische Alternative kann die stale Route weiterhin Best Path werden und Pakete tragen. Das ist eine Option auf Restfunktion, keine Zusicherung von Erreichbarkeit.

Auch beim Export bleibt die Kennzeichnung erhalten. Eine LLGR_STALE Route sollte nicht an einen Nachbarn gehen, der die Capability nicht angeboten hat, abgesehen von der eng gefassten optionalen internen IBGP-/Konföderationsregel. Wird sie weitergegeben, darf die Community nicht verschwinden. Sonst wird bekannte Unsicherheit am nächsten Router wieder zu scheinbar normaler Reachability.

NO_LLGR, Wert 0xFFFF0007, stellt die Gegenentscheidung bereit. Eine so markierte Route darf nicht langfristig behalten werden und wird nach normalem BGP entfernt. Der Sender kann ungeeignete Information ausschließen; der Empfänger kann dieselbe Schranke per lokaler Policy setzen. Technische Fähigkeit ist keine pauschale Zustimmung.

Eine zurückgekehrte Sitzung verjüngt nichts

TCP und BGP können wieder sprechen, bevor alle Routen einer Familie aktualisiert sind. Die Synchronisierung endet erst mit End-of-RIB oder an der Grenze des Selection Deferral. Der LLST-Timer läuft weiter. Läuft er ab, verschwinden alle noch nicht aufgefrischten Routen.

Auch aufeinanderfolgende Restarts geben altem Zustand nicht automatisch immer neue volle Zeiträume. Sonst ließe sich eine nie bestätigte Route durch wiederholte Abbrüche unendlich verjüngen. Fehlen nach der Rückkehr die erforderlichen Capabilities, das AFI/SAFI oder der benötigte Hinweis auf erhaltenen Forwarding-Zustand, endet die Ausnahme ebenfalls.

Ein RFC-Beispiel setzt Restart Time auf eine Sekunde und LLST auf 3.600 Sekunden. Nach der ersten Sekunde werden die Routen mit LLGR_STALE markiert und herabgestuft. Ohne Backup nutzt der Border Router sie weiter und kündigt sie einem LLGR-fähigen externen Peer mit Kennzeichnung erneut an. Bei Ablauf löscht er sie und sendet Withdrawals. Ist nach 180 Sekunden synchronisiert, verlieren die frischen Routen die Markierung. Ein externer Peer ohne Capability erhält schon beim Beginn der langen Phase einen Rückzug.

Longest Prefix kennt keine Schonfrist

Die erste Gefahr liegt in zwei verschiedenen Auswahlstufen. BGP vergleicht Paths für dasselbe Präfix. IP-Forwarding nimmt zunächst das längste passende Präfix. Eine stale More-Specific kann daher Pakete abfangen, obwohl eine frische Less-Specific vorhanden ist. Die BGP-Route ist sichtbar depreferenziert, der Datenverkehr fällt dennoch in das engere Blackhole.

Die zweite Gefahr entsteht aus unterschiedlichen Entscheidungen im AS. RFC 9494 zeigt Router, von denen einer nach der Herabstufung zu einem anderen Ausgang wechselt, während der andere den alten Ausgang bevorzugt. Die Geräte schicken sich die Pakete gegenseitig. Gewöhnliches GR kann ebenfalls kurze Inkonsistenzen erzeugen; LLGR kann sie erheblich verlängern.

Darum lautet die Kardinalregel: Für Routen, die innerhalb eines AS Hop-by-Hop-Forwarding steuern, wird LLGR nicht empfohlen. Tunnel wie MPLS beseitigen einige dieser Schleifen. BGP-Information, die eher Konfiguration als konventioneller Next Hop ist, birgt weniger unmittelbares Risiko. F bit und Forwarding State müssen trotzdem tatsächlichen Erhalt abbilden.

Bei VPNs kommt Label-Wiederverwendung hinzu. Nach einem Withdrawal kann ein altes Label einem neuen Kontext zugewiesen werden. Lebt die stale Route weiter, zeigt dieselbe Zahl plötzlich auf etwas anderes. Vor LLGR für eine VPN-Familie sollte die minimale Label-Reuse-Zeit über der maximalen LLST liegen. Die Zeitgrenze schützt hier Isolation.

Gemeinsame Bedeutung, lokale Annahme

Lu Hengs spätere Ausarbeitung zu Minimum Initial Specification, Localized Future Decision and Voluntary Adoption bietet eine passende Trennung. Gemeinsam bleiben Capability, Scope je Familie, Degradations- und Ablehnungsmarker, niedrigster Rang und deterministischer Ablauf. Der riskierende Betreiber entscheidet über Peers, Zeitobergrenze, Forwarding-Architektur und vorzeitigen Abbruch.

Damit wird der Standard nicht zur zentralen Anweisung, alte Routen zu behalten. Lokale Freiheit erlaubt aber auch nicht, LLGR_STALE zu entfernen und Vergangenheit als aktuelle Information auszugeben. Interoperabilität definiert den Zustand; die Risikotragenden entscheiden über seine Verwendung.

Running-Code Primacy verschärft den Nachweis: ausgehandelte AFI/SAFI-Tupel, empfangene und lokal begrenzte LLST, Zahl der LLGR-Routen, Best-Path-Wechsel, Withdrawals zu unfähigen Peers, End-of-RIB-Fortschritt, Packet Loss, Loop-Indikatoren und vollständige Bereinigung. Das ist Sofia Rens spätere Anwendung von Lu Hengs Analyse, keine Chen oder den RFC-Autoren zugeschriebene Privatabsicht.

RFC 9494 bewahrt ihren wichtigsten Vorbehalt im Namen der Route. Sie bleibt stale. Solange alte Evidenz als letzte Möglichkeit nützt, darf sie Zeit erhalten. Sie darf aber weder ihren Warnhinweis noch ihr Verfallsdatum verlieren. Erst diese Offenheit macht Fortbestand zu beherrschbarer Kontinuität.

Quellen