Zusammenfassung

  • RFC 8326 senkt vor einer absichtlichen EBGP-Abschaltung die Präferenz eines Pfades; RFC 4724 hält während eines BGP-Neustarts Forwarding-Zustand und vorübergehend veraltete Routen fest.
  • Der Wartungsauftrag muss Verfahren, Zustand der Datenebene, Peer-Policy, Konvergenznachweis, Zeitgrenzen und Abbruchentscheidung miteinander verbinden.

Entlasten oder erhalten

Graceful Shutdown ist für Wartung gedacht, die die Weiterleitung eines Pfades beendet. RFC 8326 definiert die Community GRACEFUL_SHUTDOWN. Der Pfad wird nicht sofort zurückgezogen, sondern mit niedriger LOCAL_PREF weiter angekündigt, bis alternative Routen ausgewählt und verbreitet sind. Empfohlen wird ein Wert von null.

Der Empfänger braucht vorher eine Eingangs-Policy, die die Community erkennt und die lokale Präferenz senkt. Zum Wartungszeitpunkt markiert der Initiator seine ausgehenden Routen, senkt auch die Präferenz der über die betroffene Sitzung empfangenen Pfade, wartet auf Neuankündigung und Konvergenz und beendet erst dann EBGP. Das Verfahren räumt einen Pfad, dessen Forwarding verschwinden wird.

Graceful Restart beginnt mit einer anderen Annahme. RFC 4724 erlaubt, Weiterleitungszustand während eines BGP-Neustarts zu erhalten. Die Fähigkeit wird ausgehandelt, Routen bleiben befristet als stale erhalten, die Sitzung wird neu aufgebaut, Updates ersetzen den alten Zustand und End-of-RIB schließt die Rekonstruktion ab. Hier soll Verkehr bleiben, nicht ausweichen.

Shutdown bedeutet: Diesen Pfad vor dem Eingriff nicht mehr bevorzugen. Restart bedeutet: Dem erhaltenen Forwarding für einen begrenzten Zeitraum weiter vertrauen. „Graceful“ allein trifft keine dieser Entscheidungen.

Das Signal ist keine Bescheinigung

Die Community hat den Wert 65535:0. RFC 1997 beschreibt Communities als optionales transitives Attribut, das ein Empfänger gemäß lokaler Policy verändern kann. Der Initiator teilt seine Absicht mit, kontrolliert aber nicht die Routenauswahl im benachbarten AS.

LOCAL_PREF ist nach RFC 4271 eine interne Präferenz; der höhere Wert gewinnt, und das Attribut wird normalerweise nicht an externe Peers gesendet. Der Nachbar übersetzt also ein externes Signal in seine interne Entscheidung. Ein Drain ist erst bewiesen, wenn die Alternative ausgewählt und in RIB sowie FIB installiert ist.

Die Community garantiert weder verfügbare Kapazität noch den physischen Ausfall des Wartungspfades. Absicht, Zustand und Kapazität benötigen getrennte Nachweise.

Stale-Routen sind befristetes Vertrauen

Graceful Restart begrenzt die Aufbewahrung. Kommt die Sitzung nicht innerhalb der Restart Time zurück, muss der Empfänger die stale Routen löschen. Bestätigt die neue Sitzung den Forwarding-Zustand für die betreffende Adressfamilie nicht, gilt dasselbe. Nach End-of-RIB dürfen nicht ersetzte alte Routen nicht unbegrenzt bestehen bleiben.

RFC 4724 warnt vor vorübergehenden Schleifen oder Blackholes, wenn der Forwarding-Zustand nicht wirklich erhalten blieb oder sich Routing-Informationen vor Abschluss der Konvergenz ändern. Eine wiederhergestellte BGP-Sitzung ist deshalb kein ausreichender Beleg. Datenebene, AFI/SAFI, Timer, stale Routen und End-of-RIB gehören in denselben Nachweis.

Ein prüfbarer Change-Vertrag

Vor der Freigabe müssen Modus, Forwarding-Annahme, bestätigte Peer-Policy oder Capability, Alternative und Kapazität, Konvergenzereignis, Abbruchschwelle und Rollback-Verantwortung feststehen.

Automatisierung, Telemetrie, Koordination und Wartezeit verursachen Kosten. Diese Kosten gehören zum Betreiber, der den Eingriff veranlasst. Ohne sie werden sie als Paketverlust auf Kunden und als beweisarme Fehlersuche auf Betriebsteams verlagert.

Quellen und Evidenzgrenze

Die Analyse stützt sich auf RFC 8326, RFC 4724, RFC 1997 und RFC 4271. Sie belegen die veröffentlichten Verfahren, nicht weltweite Verbreitung, identische Herstellerimplementierungen, konkrete Ersatzkapazität oder die korrekte Ausführung in einem genannten Netz.