Zusammenfassung

  • Route Refresh fordert die erneute Ankündigung eines AFI/SAFI ohne BGP-Neustart an; Enhanced Route Refresh markiert Beginn und Ende.
  • BoRR und EoRR belegen den Austauschrahmen, nicht Konfigurationsversion, Policy-Richtung, Loc-RIB, FIB oder Zustellung.
  • Ein belastbarer Abschluss verbindet Commit, Refresh, Kontrollpräfix, Forwarding, Verkehr, Ausnahmen und Rollback.

Der Austausch endet vor der Betriebsfrage

Eine Import-Policy soll eine bestimmte Route eines Transit-Nachbarn künftig ablehnen. Das Konfigurationssystem meldet den Commit als erfolgreich. Der Router fordert Route Refresh an; Beginning-of-RIB, die Ankündigungen und End-of-RIB folgen. Das Change-Ticket scheint erledigt.

Eine Kontrolle zeigt das Präfix dennoch auf einem Produktions-Edge als ausgewählt. Die Marker können vollkommen korrekt sein. Falsch war die Schlussfolgerung: „Der Nachbar hat die Neuanzeige beendet“ wurde mit „Die lokale Policy hat das Soll-Ergebnis erzeugt“ gleichgesetzt.

RFC 2918 definiert Route Refresh, damit Policies ohne Reset einer BGP-Sitzung erneut angewendet werden können. Die Fähigkeit wird beim Sitzungsaufbau signalisiert. Eine spätere Nachricht benennt AFI und SAFI; der Nachbar kündigt den entsprechenden Ausgangszustand erneut an.

Die Nachricht enthält weder Hash der lokalen Policy noch Konfigurationstransaktion, Freigabe oder Soll-Zustand eines Präfixes. Sie startet einen Protokollvorgang, ist aber kein Nachweis der Betriebsabsicht.

Die genaue Aussage von BoRR und EoRR

RFC 7313 ergänzt Enhanced Route Refresh. Beginning-of-RIB und End-of-RIB umschließen den erneut angekündigten Satz, sodass der Empfänger nicht erneuerte alte Routen erkennen und behandeln kann.

Das ist präzise Evidenz: Der Refresh dieses Nachbarn und dieser Familie begann und endete. Sie beweist nicht, dass die neue Konfiguration vor dem ersten UPDATE aktiv war, alle Geräte erreichte oder in der richtigen Richtung galt. Auch FIB-Installation und Paketzustellung bleiben eigene Fragen.

Ein IPv4-Unicast-Refresh deckt weder IPv6 noch VPN-Routen oder andere SAFIs ab. Eine Sitzung steht nicht für einen zweiten Peer, Route Reflector oder eine andere Edge-Gruppe. Ein EoRR als netzweites Grün zu behandeln, löscht seinen notwendigen Geltungsbereich.

Import und Export brauchen getrennte Belege

RFC 4271 trennt empfangene Routen, die im Loc-RIB gewählten Routen und die zur Ankündigung vorbereiteten Routen. Nach einer Importänderung verarbeitet der Empfänger neue Anzeigen mit der neuen Regel. Nach einer Exportänderung muss der Sender zeigen, dass er die neue Regel zum benannten Nachbarn verwendete.

Das sind verschiedene Verantwortungs- und Beobachtungsketten. Der Peer spielt seinen Ausgangszustand ab, während der lokale Router den Eingang neu verarbeitet. Ein Refresh zertifiziert nicht beide Seiten.

RFC 5291 führt Outbound Route Filtering ein. ORF-Fähigkeit, Filtertyp, Modus und installierter Zustand sind eigene Daten. Ein nachfolgender Refresh beweist allein nicht, dass der erwartete Filter vorhanden und aktuell war.

Ein Kontrollpräfix verbindet die Ebenen

Eine Importablehnung wird an empfangener Route und Policy-Ergebnis geprüft. Eine neue Best Route wird im Loc-RIB geprüft. Eine Verkehrsverlagerung verlangt FIB, Next-Hop-Auflösung und einen repräsentativen Paketpfad.

Diese Ansichten können auseinanderlaufen. Ein Präfix kann von einem Peer abgelehnt und von einem anderen gelernt werden. Eine BGP-Route kann gewinnen, aber bei der Auflösung scheitern. Ein FIB-Eintrag kann existieren, während Tunnel, ACL oder nachgelagerter Fehler die Zustellung verhindert.

Darum braucht es ein Kontrollpräfix mit bekanntem Soll. Vor dem Commit, während BoRR–EoRR und danach werden Peer, AS-Pfad, Attribute, Entscheidungsgrund und finaler Next Hop festgehalten. Ein Test für die betroffene Familie und den Dienst vervollständigt die Kette.

Diese Grenze erhält den Wert von Route Refresh. Ein abgeschlossener Vorgang ist starker Beleg für die Neuanzeige eines begrenzten Routensatzes. Mit angrenzender Evidenz lassen sich falsche Version, Teilverteilung, falsche Familie, fehlende Fähigkeit, anderer ORF-Zustand oder Forwarding-Fehler nach korrekter BGP-Entscheidung unterscheiden.