Zusammenfassung

  • RFC 7313 macht aus einem Refresh ein abgegrenztes Abgleichfenster: BoRR markiert die Routen des Nachbarn für eine AFI/SAFI als veraltet, erneute Ankündigungen ersetzen sie und EoRR entfernt nur die weiterhin markierten Einträge.
  • Das Verfahren gilt erst nach Empfang der Enhanced Route Refresh Capability. Es erhält die Sitzung, authentifiziert jedoch keine Route und macht veralteten Zustand nicht risikofrei.

Eine Wiederholung ohne Ende beweist keine Abwesenheit

RFC 2918 erlaubt es, das Adj-RIB-Out eines Nachbarn erneut anzufordern. Dadurch muss die Sitzung nicht allein für bestimmte Richtlinienänderungen neu aufgebaut werden. Dem normalen Refresh fehlt jedoch eine explizite Grenze. Der Empfänger sieht UPDATEs, weiß aus dem Protokoll aber nicht, wann die vollständige Wiederholung abgeschlossen ist und wann eine nicht erschienene Route als zurückgezogen gelten darf.

Das ist bei fehlenden Withdrawals entscheidend. Eine alte Route kann in der lokalen RIB verbleiben, obwohl alle neuen Ankündigungen korrekt wirken. Ohne Schlussmarke muss der Betreiber offline vergleichen, das Ende aus Schweigen ableiten oder die Sitzung neu aufbauen. RFC 7313 ersetzt diese Vermutung durch eine abgegrenzte Sequenz.

Der Sprecher kündigt zunächst Fähigkeit 70 an. Vor der Wiederholung sendet er BoRR; nachdem er das beim Start vorhandene Adj-RIB-Out vollständig erneut angekündigt hat, sendet er EoRR. Die Marker bestätigen nicht die Wahrheit einer Route. Sie legen fest, wann der Abgleich beginnt und wann eine Auslassung eine Aktion rechtfertigt.

BoRR macht Zustand vorläufig, EoRR beendet die Befugnis

Beim Empfang von BoRR markiert der Empfänger alle Routen dieses Nachbarn für die bezeichnete AFI/SAFI als stale. Er löscht sie nicht sofort. Neu angekündigte Routen ersetzen die markierten Kopien. Mit EoRR werden alle noch stale markierten Routen unverzüglich entfernt. Sitzung und andere Adressfamilien bleiben außerhalb des Vorgangs.

Die Befugnis ist stark, aber eng. Nur im ausgehandelten Umfang und im erklärten Fenster darf Nichterscheinen als Withdrawal interpretiert werden. Die Fähigkeitsanzeige belegt Unterstützung für Untertypen und Verfahren; sie erlaubt keine Änderung fremder Richtlinien, keine Annahme unerwünschter Pfade und keine Ausdehnung auf andere Familien.

Eine Implementierung darf eine lokal konfigurierbare Obergrenze für die Aufbewahrung setzen. Bleibt EoRR aus, dürfen die restlichen stale Routen nach Ablauf entfernt werden. Die Frist verhindert dauerhaften Übergangszustand, doch RFC 7313 nennt keine universell sichere Dauer. Der Betreiber verantwortet die Abwägung zwischen Kontinuität und Gewissheit.

Kontinuität verlagert Kosten

Der Nutzen ist ein Online-Abgleich ohne Abbruch der Nachbarschaft. Gültige Routen können bestehen bleiben, fehlende Withdrawals werden sichtbar und nicht betroffene Ziele vermeiden unnötige Rekonvergenz.

Der Sender muss dennoch das anfängliche Adj-RIB-Out der Familie wiederholen. Der Empfänger trägt vorläufige stale Zustände, verarbeitet den Strom und trennt Wiederholung von laufenden Änderungen. Eine lange Frist kann eine falsche Route erhalten; eine kurze kann einen nützlichen Pfad vor einem verspäteten EoRR löschen. Weniger Reset-Schaden bedeutet nicht weniger Unsicherheit.

Graceful Restart setzt eine weitere Grenze. BoRR darf für dieselbe AFI/SAFI nicht vor End-of-RIB gesendet werden. Hat der Empfänger die Graceful-Restart-Fähigkeit erhalten, muss er ein verfrühtes BoRR ignorieren. Ein Wiederherstellungsverfahren darf die Bereinigung nicht freigeben, bevor das andere seine stale Phase beendet hat.

Fehler erhalten keine stillschweigende Befugnis

Ein Untertyp 1 oder 2 mit falscher Länge löst ROUTE-REFRESH Message Error Code 7, Subcode 1 aus. Andere Untertypen als 0, 1 und 2 müssen ignoriert und sollten protokolliert werden. Ein EoRR ohne zugehöriges BoRR darf ebenfalls ignoriert und protokolliert werden. Unbekannte oder fehlerhafte Steuerzeichen erhalten damit keine heimliche Löschbefugnis.

Belege und Grenzen

RFC 7313 belegt Fähigkeit, Marker, stale Lebenszyklus, Frist, Graceful-Restart-Reihenfolge und Fehlerbehandlung. RFC 2918, 4271, 4724 und 5492 liefern die Grundlagen; IANA bestätigt Code 70. Die Deutung als delegierte Betriebsbefugnis ist Analyse. Die Quellen beweisen keinen Einsatz bei einem genannten Betreiber, keine universelle Frist und weder Routenauthentizität noch vollständige Reparatur.

Quellen