Zusammenfassung

  • RFC 2918 erlaubt die erneute Ankündigung des aktuellen Adj-RIB-Out eines fähigen Peers für eine vereinbarte AFI/SAFI; dessen Export-Policy bleibt maßgeblich.
  • RFC 7313 begrenzt die Wiederholung mit BoRR und EoRR, markiert alte Einträge stale, ersetzt zurückkehrende und entfernt ausbleibende am Ende.
  • Erfolgreicher Befehl und stabile Sitzung beweisen keinen Effekt; Prefixe, Attribute, Auswahl, FIB und Verkehr müssen verglichen werden.

Ein Operator korrigiert einen Importfilter, der zweihundert erlaubte Prefixe verworfen hat. Der Commit gelingt. Ohne gespeicherte Roh-Updates besitzt die neue Regel dennoch keine Eingaben. Die Policy ist neu, der RIB-Zustand kann alt bleiben.

Bei einer strengeren Regel gilt dasselbe: Bereits akzeptierte Routen werden nicht durch Textänderung neu beurteilt. Repository und laufende Entscheidung können auseinanderlaufen.

Inbound Soft Reconfiguration bewahrte alle unveränderten Anzeigen einschließlich verworfener. Sie kaufte lokale Unabhängigkeit mit dauerhaftem Speicher- und CPU-Bedarf.

RFC 2918 verlagert den Zustand. Capability Code 2 signalisiert Empfang von ROUTE-REFRESH. Der Requester darf erst nach Empfang dieser Capability eine vereinbarte AFI/SAFI anfordern.

Der Peer kündigt sein aktuelles Adj-RIB-Out unter seiner Outbound-Policy erneut an. Der Anfordernde liest keine entfernte Datenbank und erzwingt keine gefilterte Route. Er hört nur noch einmal, was der Nachbar heute ausgeben will.

Das ist kein historisches Archiv. Alte Routen können zurückgezogen, Attribute oder entfernte Policies geändert und neue Wege hinzugekommen sein. Das Resultat verbindet zwei aktuelle Zustände.

Ein Count-Diff erklärt daher keine Ursache. Weniger Routen können aus lokaler Filterung, Remote-Withdraw oder verändertem Export stammen. Exakte Mengen und Zeiten sind nötig.

RFC 2918 markierte nicht, wann eine vollständige Wiederholung begann oder endete. Normale UPDATEs konnten sich mischen; eine vorläufig fehlende Route war noch kein bewiesener Rückzug.

RFC 7313 führt Enhanced Route Refresh Code 70 ein. BoRR öffnet, EoRR schließt die Epoch. Bei BoRR markiert der Empfänger alle Peer-Routen der AFI/SAFI stale. Wiederkehrende Einträge ersetzen sie; EoRR löscht den Rest.

Die Welt bleibt währenddessen aktiv. Änderungen im Zyklus werden in neuem Zustand gesendet. EoRR beweist Abschluss, nicht Korrektheit oder historische Gleichheit.

Eine lokale Obergrenze für stale retention verhindert unbegrenztes Festhalten alter Reachability, kann bei zu kurzer Wahl aber gesunde Routen vor Ende eines langsamen Refresh löschen.

EoRR ist nicht das End-of-RIB des Graceful Restart. Das eine schließt Replay, das andere koordiniert Control-Plane-Restart. RFC 7313 trennt beide, um vorzeitige Bereinigung zu vermeiden.

Inbound und outbound soft reset haben verschiedene Zustandsbesitzer. Inbound fordert Remote-Replay oder nutzt eine lokale Kopie; outbound erzeugt eigene Anzeigen neu. Gleiche Benennung verbirgt verschiedene Abhängigkeit.

Cisco-Dokumentation nennt drei Wege: dynamischer Request mit Capability, lokale Kopie bei Soft Reconfiguration oder Hard Reset, wenn beides fehlt. Der letzte zerstört die Session und betrifft alle ihre Routen.

Die Wahl tauscht Ressourcen gegen Abhängigkeit. Rohdatenhaltung kostet Speicher und gibt lokale Souveränität. Refresh spart Speicher und hängt vom Peer und dessen aktuellem Export ab. Hard Reset erweitert den Ausfallradius.

FRRouting zeigt, dass manche Kontrollen weiterhin verworfene Routen benötigen, etwa bestimmte Maximum-Prefix-Zählungen. Erneuter aktueller Feed ersetzt nicht jedes dauerhafte Inventar.

RFC 5291 definiert ORF als eigene Capability. Filterinformation kann zum Sender gelangen, doch gewöhnliches ROUTE-REFRESH editiert keine Remote-Policy.

Beweise beginnen vor der Änderung. Erfassen Sie advertised und received basic/enhanced Capability je Richtung und AFI/SAFI. Lokaler Support belegt keine Peer-Antwort; Basic belegt kein BoRR/EoRR.

Die Baseline enthält genaue Prefixe und Attribute, akzeptierte Sets, Best Paths, Policy-Version, Uptime und FIB Next Hops. Unsichtbare verworfene Routen sind als Lücke zu benennen.

Starten Sie mit einem Peer und einer Familie. Messen Sie Request, BoRR, EoRR und Dauer. Beobachten Sie fehlenden Abschluss, stale timeout, CPU, Reset, Withdraws und Path-Wechsel.

Vergleichen Sie Mengeninhalte. Zehn Abgänge plus zehn Zugänge ändern keinen Count. Aggregate und More-Specifics verändern Volumen. Attribute können Auswahl bei gleichem NLRI ändern.

Prüfen Sie Forwarding. Akzeptierte Route kann verlieren, Next Hop ungelöst oder neuer Link zu klein sein. Refresh liefert Eingabe, keine Paketgarantie.

Rollback braucht ebenfalls Replay. Alte Policy-Datei stellt Entscheidungen nicht automatisch wieder her. Bei verändertem Remote-Export ist die Startaufnahme eventuell nicht reproduzierbar.

Automation begrenzt Parallelität. Viele Peers erzeugen UPDATE-Last und Neuberechnung. Soft heißt ohne beabsichtigten Teardown, nicht ohne Arbeit.

Heng Lus Minimum-Spezifikation zeigt sich in Peer, Familie und Request. Jedes AS behält seine Policy. Running-Code-Primat verlangt Capability, beobachtete Epoch, RIB-Diff und FIB statt Erfolgsmeldung.

Route Refresh trennt Policy-Korrektur von Session-Zerstörung. Es trennt Korrektur nie vom Beweis. Erst zurückgekehrte, neu bewertete und im Forwarding sichtbare Routen geben der neuen Regel praktische Hoheit.

Sources