Zusammenfassung

  • Route Target Constraints übersetzen den Importbedarf eines PE in Disclosure-Zustand je Peer: Membership NLRI laufen zu den Quellen, passende VPN-Erreichbarkeit fließt im inversen Graphen zurück.
  • Für Join, Leave oder Migration zählen ausgehandeltes AFI 1/SAFI 132, exakte Membership, begrenzte Synchronisation, Adj-RIB-Out-Differenzen, unabhängige Sicherheitspolitik sowie VRF-, Label-, FIB- und Paketbelege.

Der Change sieht abgeschlossen aus. Der Ziel-PE enthält den neuen VRF, sein Import RT stimmt mit der erwarteten Route überein. Am Quell-PE steht der Präfix in der VPN-Tabelle. Die Route Reflectors sind erreichbar, alle Sitzungen grün. Nur am Empfänger fehlt die Route.

Die erste Lücke kann in der Gegenrichtung liegen. Hat der PE seine RT Membership NLRI noch nicht erzeugt oder hat ein RR den benötigten Pfad nicht bewahrt, fehlt die Grundlage für den peer-spezifischen Ausgabefilter. Der RR kennt die Route, offenbart sie diesem Nachbarn aber nicht.

RFC 4684 definiert diesen Mechanismus als RTC beziehungsweise RT-Constrain. Statt alle VPN-Routen dicht an alle PEs zu verteilen und dort Unnötiges zu verwerfen, meldet der Empfänger seinen Bedarf. Der RR leitet daraus einen Filter ab und sendet nur passende VPN NLRI zurück.

Bei dünner Membership spart das Zustand, Rechenzeit und Updates. Es verändert zugleich den Nachweis. Eine gültige Quellroute und eine stabile Sitzung beweisen nicht, dass ein bestimmter Peer im aktuellen Disclosure-Graphen Anspruch auf diese Sicht hatte.

Route Targets eröffnen Importfähigkeit, keine Lieferung

RFC 4364 trennt Route Distinguisher und Route Target. Der RD macht überlappende VPN-Präfixe in BGP eindeutig. Der RT ist eine Extended Community, mit der VRFs Export- und Importbeziehungen ausdrücken.

Passt mindestens ein RT einer Route zu einem Import RT des VRF, ist die Route für diesen VRF geeignet. Installiert ist sie damit nicht. BGP-Auswahl, lokale Policy, PE/CE-Verfahren, Next-Hop- und Labelauflösung sowie RIB- und FIB-Programmierung folgen noch.

RTC ändert diese Grenze nicht. Membership drückt Verteilungsinteresse aus, keine Kundenidentität. Sie erzeugt keinen VRF, authentisiert keinen RT-Nutzer, validiert keine VPN-Route und beweist keinen Paketfluss.

Eine fehlende Route kann daher an vielen Stellen entstehen: Ursprung, Aufnahme durch den RR, RTC-Interesse, Reflection eines Membership-Pfads, abgeleiteter Filter, VPN Adj-RIB-Out, Import, Auswahl, Label, FIB oder Datenebene. Die Analyse sucht die erste Grenze ohne den erwarteten Zustand.

Nachfrage und Erreichbarkeit bewegen sich gegeneinander

Der entscheidende Gegenstand in RFC 4684 ist der inverse Graph. Der Empfänger kündigt Interesse in Richtung der Systeme an, die VPN-Routen halten oder verteilen. Passende VPN-Erreichbarkeit kehrt in Gegenrichtung zurück. Membership ist dabei ein BGP-Erreichbarkeitsobjekt, keine Fernsteuerung; Auswahl, Policy und Reflection wirken darauf.

Die Membership NLRI wird mit MP_REACH_NLRI oder MP_UNREACH_NLRI aus RFC 4760 für AFI 1 und SAFI 132 übertragen. Außer beim Default enthält der Schlüssel eine vier Oktett lange Origin AS und einen acht Oktett langen Route Target, dargestellt als 32- bis 96-Bit-Präfix. Kürzere Präfixe fassen Interesse breiter und vergrößern damit auch Zustand und Offenlegung.

Ein Präfix der Länge null ist die Default RT Membership. Der Peer erklärt damit Bereitschaft für alle relevanten VPN-Ankündigungen dieser Beziehung. Das ist keine IP-Default-Route, kein Default-VRF, kein universeller Kunde und kein Installationsbefehl.

Ein RR kann rollenbedingt dichten Empfang benötigen; gemischte Einführungen können ebenfalls einen breiten Pfad behalten. Default Membership bleibt eine zu begründende Ausnahme, weil sie Selektivität, Konvergenzbudget und Informationsgrenze verändert.

Capability beweist den Kanal, nicht seinen Inhalt

Beide Seiten müssen AFI 1/SAFI 132 im BGP OPEN aushandeln. Das belegt die Austauschfläche. Es belegt weder eine konkrete Membership NLRI noch ihren Empfang, ihre Auswahl oder den daraus entstehenden VPN-Filter.

Auch rtfilter oder family route-target in einer Konfiguration sind nur Absicht. Der Mindestnachweis umfasst beide Capability-Ansichten, das genaue UPDATE, die empfangene RTC RIB, relevante alternative Pfade, Policy-Ergebnisse und den tatsächlich verwendeten Filter je VPN Adj-RIB-Out.

Der Cisco-Hinweis zu Route Target Constraint zeigt für eine Produktfamilie, wie VRF Import RTs rtfilter-Updates und empfangene Filter speisen. Die Juniper-Referenz zu family route-target beschreibt dieselbe Richtung von PE-Interesse und selektiver RR-Antwort.

Syntax und Defaults sind produktspezifisch. Der Cisco-Befehl bgp default route-target filter und Juniper Route Target Filtering dokumentieren lokale Steuerung. Konfigurationspräsenz beweist keinen ausgehandelten RFC-4684-Zustand.

Ein gewöhnlicher Best Path repräsentiert nicht alle Interessenten

Mehrere PEs derselben AS können dasselbe {Origin AS, Route Target}-Präfix erzeugen. Würde ein RR nur den normalen besten iBGP-Pfad berücksichtigen, könnte der Bedarf anderer Clients verschwinden, obwohl sie passende VPN-Routen erhalten müssen.

RFC 4684 verlangt deshalb, alle verfügbaren iBGP-Pfade des RT-Präfixes in die Filterbildung einzubeziehen, und verändert die Werbung lokal erzeugter Membership. Das baut auf einer korrekten Reflection-Topologie nach RFC 4456 auf, ist aber mehr als gewöhnliche Best-Path-Auswahl.

Es ist auch kein ADD-PATH für VPN-Erreichbarkeit. Nicht mehrere Alternativen sollen zum Empfänger, sondern alle Nachfragerichtungen erhalten bleiben. „Der RT steht in BGP“ sagt weder, welche PEs Interesse erzeugten, noch welche Peer-Filter und VPN-Ausgabemengen daraus folgten.

Join und Leave sind Änderungen eines lebenden Graphen

Nach Membership-Ankündigung oder -Rücknahme soll der Sender VPN RIB-OUT neu bewerten und mit möglichst wenigen Updates vom alten zum neuen Zustand wechseln. Ein VRF-Commit beendet keinen Join; das Entfernen eines RT aus der Konfiguration beendet keinen Leave.

Beim Join werden genehmigte Importabsicht, Membership-Ursprung, Empfang und Reflection, Filtererweiterung, VPN Adj-RIB-Out, Empfang am PE, VRF-Import, Next Hop, Label, FIB und Pakete nacheinander bewiesen.

Beim Leave muss zuerst feststehen, dass kein anderer lokaler VRF den RT braucht. Eine Route mit einem weiteren aktiven passenden RT bleibt erhalten. Da Routen mehrere RTs und VRFs mehrere Imports tragen können, kann eine unveränderte Anzahl einen Tausch zwischen erwarteter und unerwarteter Route verbergen. Identitäten und Attribute sind exakt abzugleichen.

EoR setzt der Anfangswarteschleife ein Ende

RFC 4684 empfiehlt ein End-of-RIB für die RTC-Familie auch ohne Graceful Restart. Ein RR kann damit auf das anfängliche Membership-Set warten, bevor er VPN-Routen freigibt.

Diese Wartezeit muss begrenzt sein; der spezifizierte Default beträgt 60 Sekunden. Das ist kein allgemeines Serviceziel, sondern verhindert eine unbegrenzte Störung durch die Optimierung. Effektiver Timer, EoR-Zeitpunkt und Verhalten nach Ablauf gehören in den Nachweis.

RTC UPDATE und Route Refresh sind getrennt. RTC ändert aktuelles Interesse; Route Refresh fordert erneute Werbung des Exportzustands. RFC 5291 transportiert ORF als typisierte Einträge mit ROUTE-REFRESH. RFC 7543 zeigt, wie Covering Prefix ORF RTC Membership anstoßen kann, um fehlende VPN-Routen zu erhalten; gewöhnliches RTC setzt das nicht voraus.

Selektive Offenlegung ist keine Sicherheitsfreigabe

RFC 4684 stellt ausdrücklich fest, dass aus RT Membership gebaute Ausgabefilter nicht für Sicherheit bestimmt sind. Über Verwaltungsgrenzen bleiben unabhängige NLRI-Ein- und Ausgangsfilter sowie Filter für Membership selbst erforderlich.

Eine Membership NLRI ist eine BGP-Aussage eines Peers. Sie authentisiert keinen Kunden, belegt keinen Vertrag, erlaubt nicht jeden RT, validiert keine VPN-Route und begrenzt nicht allein die Datenebene. Wird beliebiges Interesse als Erlaubnis behandelt, kann der Peer seine Informationssicht ausweiten.

Die unabhängige Kontrolle umfasst genehmigte RT-Namespaces, Peer-Rollen, Übersetzung an Grenzen, Membership-Eingang, VPN-NLRI-Ausgang, Zustandslimits, Protokollierung und Rollback. RTC optimiert innerhalb dieser Regeln; es ersetzt sie nicht.

Der Beleg muss beide Richtungen durchlaufen

Das Adj-RIB-In-, Loc-RIB- und Adj-RIB-Out-Modell aus RFC 4271 verhindert, dass ein Screenshot den ganzen Prozess vertritt. Für RTC wird es auf Membership- und VPN-Familie angewandt.

Am Ziel-PE beginnen: genehmigte VRF-Absicht und Import RTs, Capability, Membership UPDATE, Policy und alle relevanten iBGP-Pfade. Am RR folgen RTC RIB und Peer-Filter. Danach die VPN-Route vom Ursprung über RR Loc-RIB und Ziel-Adj-RIB-Out bis zur VPN RIB des PE verfolgen.

Zum Abschluss VRF-Import, Auswahl, Label, Next Hop, FIB sowie positive und negative Paket-Canaries prüfen. Bei Rücknahme, RR-Migration und Upgrade denselben Pfad wiederholen und belegen, dass der alte Disclosure-Graph verschwunden ist.

Quellen