Zusammenfassung

  • RFC 9494 ergänzt pro AFI/SAFI eine zweite Haltezeit; der vom Peer angekündigte LLST belegt jedoch weder erhaltene Forwarding State noch erreichbaren Dienst.
  • Belastbare LLGR-Führung verbindet ausgehandelte Fähigkeiten und lokale Zeitgrenzen mit Communities, Auswahl, Weitergabe, FIB und Paketen sowie einem belegten Ende durch EoR, Ablauf oder Eingriff.

Ein bewusst konstruiertes Beispiel zeigt die Grenze. Eine BGP-Sitzung fällt aus, die gewöhnliche Graceful-Restart-Zeit endet, doch der Helper hält eine spezifischere Route weitere sechs Stunden. Sie wird stale und erhält die niedrigste Präferenz. Eine frische, aber weniger spezifische Route ist vorhanden. Für Ziele im gehaltenen Präfix gewinnt trotzdem der längste Treffer. Die Tabelle enthält weiterhin einen Weg, während der Dienst hinter diesem Weg bereits verschwunden ist.

Das setzt keinen Implementierungsfehler voraus. RFC 9494 erlaubt gerade eine längere Bewahrung, wenn ein Control Plane langsam wiederkehrt oder BGP Informationen verteilt, die eher Konfiguration als gewöhnliche Erreichbarkeit darstellen. Dieselbe Schonfrist kann auch ein Black Hole, eine widersprüchliche Auswahl oder eine veraltete Dienstbindung verlängern.

Die Führungsfrage lautet daher nicht, ob eine Plattform LLGR unterstützt. Sie lautet, wer altem Zustand weiterhin Wirkung geben darf, wer die vorgeschlagene Dauer beschränkt und welche laufende Beobachtung stärker ist als der Timer.

Zwei aufeinanderfolgende Verwahrungsphasen

RFC 4724 definiert BGP Graceful Restart. Capability 64 trägt Restart Time und familienbezogene Zustandsangaben. Nach einem Sitzungsabbruch kann der Receiving Speaker Routen des neu startenden Speakers vorübergehend halten. End-of-RIB markiert den Abschluss der ersten Aktualisierung für eine AFI/SAFI-Kombination.

Der Reset-Grund gehört zur Beweiskette. RFC 8538 erlaubt nach Austausch des N-Bits graceful Verfahren für viele NOTIFICATION-Ereignisse und für Hold-Time-Ablauf. Ein Cease mit Hard-Reset-Subcode verlangt hingegen vollständige Beendigung. „Session down“ ohne Fehlercode, Subcode und Zeitpunkt ist unvollständig.

RFC 9494 fügt Capability 71 hinzu. Ein Eintrag enthält AFI, SAFI, Flags und eine 24 Bit breite Long-Lived Stale Time. LLST wird in Sekunden ausgedrückt; einen allgemeinen Standardwert gibt es nicht. Herkömmliche IP-Erreichbarkeit, Route-Target-Zustand, FlowSpec und Discovery haben unterschiedliche sichere Lebensdauern.

LLGR ist kein unabhängiger Umweg. Wird LLGR ohne GR-Capability empfangen, muss es ignoriert werden. Das Verfahren verwendet EoR, Zustandsmaschine und Reset-Logik von GR. Eine Anzeige von Capability 71 ohne 64, Familie und Parameter beweist keine anwendbare Vereinbarung.

Die Phasen können seriell folgen. Während GR sinkt die Präferenz einer gehaltenen Route nicht allein wegen GR. Im LLGR-Zeitraum wird sie least preferred. Vor Wiederherstellung der Session entspricht die obere Protokollgrenze Restart Time plus LLST, vorbehaltlich lokaler Ober- oder Untergrenzen.

Jede Phase kann null Sekunden dauern. Der Empfänger kann den angebotenen LLST kürzen. Der Peer schlägt ein Zeitbudget vor; der Helper erzeugt die lokale Wirkung durch Annahme. Angekündigter und akzeptierter Wert müssen getrennt dokumentiert werden.

Niedrigste Präferenz ist noch keine Entfernung

Zu Beginn von LLGR startet der Helper einen Timer je AFI/SAFI und fügt LLGR_STALE hinzu. IANA führt den Wert 0xFFFF0006 beziehungsweise 65535:6. Jede nicht least-preferred Route muss die stale Route schlagen. Sind alle Kandidaten least preferred, gelten die gewöhnlichen Tie-Breaker.

Depreferenzierung schafft keine Alternative. Eine stale Route kann als einzige exakte Kandidatin weiterhin best sein. Eine frische weniger spezifische Route rettet die Ziele nicht zwingend, wenn die installierte stale more-specific den längeren Präfixtreffer liefert. RFC 9494 warnt ausdrücklich vor Konnektivitätsverlust.

In einem hop-by-hop weiterleitenden iBGP-Kern entsteht ein zweites Problem. Router sehen ihre eigenen Sitzungen und können denselben Pfad unterschiedlich einstufen. Einer wählt die frische Alternative, der andere den noch nicht abgesenkten Pfad. Die abweichende Auswahl kann eine Forwarding Loop bilden. Für solche Routensätze empfiehlt RFC 9494 LLGR nicht.

Tunnel begrenzen diese Schleifenklasse, bestätigen aber keinen Enddienst. Die Auflösbarkeitsregel aus RFC 4271 bleibt bestehen. RFC 9494 nennt BFD als mögliche zusätzliche Prüfung des Next Hops. BFD belegt weder Anwendung noch vollständige Dienstkette.

LLGR verschiebt den Withdraw-Zeitpunkt. Es authentisiert keine Route, autorisiert kein Präfix, bestätigt keine Hardwareprogrammierung und garantiert keine Paketlieferung.

Ein ausdrücklicher Weg aus der Langzeithaltung

NO_LLGR trägt den IANA-Wert 0xFFFF0007 oder 65535:7. Eine damit markierte Route darf nicht in die lange Haltephase gelangen. Der Sender kann sie markieren, oder lokale Policy kann die Ausnahme hinzufügen.

Das ist ein Ablehnungssignal, keine Signatur. RFC 1997 definiert Communities als Pfadattribut. Der Wert authentisiert seinen Schreiber nicht. Zwischenpolicy kann Communities entfernen, ersetzen oder ergänzen. Daher sind received und advertised attributes an jeder wesentlichen Grenze erforderlich.

Eine LLGR_STALE Route soll nicht an Nachbarn gehen, die LLGR nicht angekündigt haben. Damit bleibt alter Zustand in einem Kreis, der die niedrigste Präferenz versteht. Lokales Halten und weitere Ankündigung sind getrennte Befugnisse.

Für teilweise Einführung existiert eine enge Ausnahme. An einen nicht LLGR-fähigen iBGP- oder Confederation-Nachbarn darf stale Zustand nur mit NO_EXPORT und LOCAL_PREF null gehen. Der AS sollte null einheitlich behandeln. Auswahlkonsistenz, nicht bloße Kennzeichnung, begründet diese Regel.

Eine grüne Session stoppt die Uhr nicht

Das familienbezogene F-Bit beschreibt, ob Zustand beim vorherigen Neustart tatsächlich erhalten blieb. Es ist kein allgemeines Gesundheitssignal. Fehlt nach Wiederaufbau die AFI/SAFI, das F-Bit oder eine erforderliche GR/LLGR-Capability, muss der Helper die betreffenden stale Routen sofort löschen.

Wiederholte Resets erneuern den Kredit nicht beliebig. Ohne manuellen Eingriff wird ein laufender LLST nicht aktualisiert, bevor der Peer eine neue Session aufgebaut und synchronisiert hat. Synchronisation erfolgt je Familie durch EoR oder Ablauf des Selection_Deferral_Timer.

LLST läuft nach Established bis zum EoR weiter. Läuft er während der Synchronisation ab, müssen nicht erneuerte stale Routen entfernt werden. Eine grüne Session kann deshalb mit einem schrumpfenden Altbestand koexistieren. Entscheidend ist der Vergleich zwischen gehaltenen und fristgerecht neu angekündigten Routen.

EoR beendet eine anfängliche Update-Epoche, nicht die Datenebenenprüfung. Eine neu angekündigte Route kann am Next Hop, FIB, Label oder Dienst scheitern. Control-Plane-Vollständigkeit und Lieferung bleiben verschiedene Tatsachen.

Wo langes Halten sinnvoll sein kann

BGP verteilt auch Route Target Constraints, FlowSpec, Discovery und VPN-Zustand. Solche Informationen ähneln verteilter Konfiguration und können langsam rekonstruiert werden. Sofortige Entfernung kann unnötigen Churn oder Dienstverlust erzeugen, obwohl der zugrunde liegende Zustand noch gültig ist.

Trotzdem verlangt RFC 9494 positive Konfiguration pro AFI/SAFI und verbietet standardmäßige Aktivierung. LLGR ist keine allgemeine Hochverfügbarkeitsfunktion. Es ist eine Ausnahme, deren Sicherheit von Bedeutung, Forwarding-Modell und Lebensdauer jeder Abhängigkeit abhängt.

In MPLS VPN kann die Abhängigkeit ein Label sein. Eine stale VPN-Route verweist womöglich noch auf ein zurückgezogenes Label. Wird es für ein anderes VPN wiederverwendet, bevor alle Ingress-PEs die alte Route aufgeben, wird aus Verfügbarkeit ein Isolationsrisiko. Die untere Wiederverwendungsgrenze muss über der oberen LLST-Grenze liegen.

Aktuelle Dokumentation von Cisco, Juniper und Nokia zeigt zudem, warum Produkt und Release erfasst werden müssen. Cisco trennt gesendete und akzeptierte Zeiten. Juniper trennt Receiver, Restarter, Familie, Policy und manuelles Clear. Nokia zeigt SR-OS-spezifische Families und Zustände. Kein Herstellerstandard darf verallgemeinert werden.

Belege für eine stale Epoche

Zuerst wird die Aushandlung gesichert: beide OPEN oder autoritative Neighbor-Ausgabe mit GR, LLGR, AFI/SAFI, Restart Time, LLST sowie N/F-Bits. Der angekündigte Wert steht getrennt neben der lokalen Annahmegrenze.

Dann folgen Reset-Grund, Subcode, Zeit, Ende von GR und Beginn von LLGR. Je Route werden LLGR_STALE, NO_LLGR, Loc-RIB-Entscheidung und relevante Weitergabe erfasst. Eine sichtbare Community ohne Policywirkung ist kein vollständiger Beleg.

Die Datenebene liefert recursive resolution, FIB oder Dienstzustand, nötigenfalls Label und Encapsulation sowie Paket- oder Anwendungsproben. Best path ohne beobachtetes Ergebnis bleibt Absicht.

Schließlich werden EoR, Ablauf oder manuelles Clear den entfernten, nicht erneuerten Routen zugeordnet. Bei Erholung ist saubere Neuankündigung, andernfalls Withdraw bis zur wesentlichen Grenze zu belegen. Owner für Kürzung und Rollback muss vor dem Vorfall feststehen.

Quellen