Dieselbe /24 für zwei Kunden? VPNv4 braucht ein RD und ein Label
Zwei Mandanten können dieselbe /24 nur ankündigen, weil das RD jeder Route eine eigene Identität gibt. Das Label beantwortet eine andere Frage: wie weitergeleitet wird.
Zwei Mandanten nummerieren ihre Filiale mit derselben 10.50.0.0/24, und nach einer Änderung verschwindet die Route des einen Mandanten vom Provider-Edge, während die des anderen weiterläuft. Die Vereinfachung hinter einem solchen Ticket ist meistens, den Route Distinguisher wegzulassen, weil „das Label den Kunden ja schon identifiziert“. Das tut es nicht. RD und Label beantworten zwei verschiedene Fragen, und die Lücke wird erst sichtbar, wenn überlappende Adressen sie erzwingen.
Eine Route, wo zwei sein sollten
Einfaches IPv4-Unicast vergleicht zwei Pfade zum selben Präfix und installiert den besseren. 10.50.0.0/24 von Mandant A und 10.50.0.0/24 von Mandant B sind ein Schlüssel, also gewinnt einer, und der andere überlebt nur als Ersatzpfad. Das Protokoll tat, was ihm gesagt wurde; die Kontrollebene sollte zwei verschiedene Routen unter einer einzigen Kennung speichern.
Das Ergebnis sieht eher wie eine fehlende Route aus als wie ein Fehler: Der PE, der den Wettbewerb verloren hat, leitet seinen eigenen Mandanten weiterhin lokal weiter, sodass ein Ping innerhalb des Standorts gelingt und der Test zwischen den Standorten scheitert. Zählen Sie die Einträge für dieses Präfix in der VPNv4-Tabelle, bevor Sie irgendeine Policy anfassen.
Das RD macht aus einem Schlüssel zwei
Ein acht Byte langer Route Distinguisher wird dem IPv4-Präfix vorangestellt, und das Objekt, das BGP transportiert, wird zu einer VPN-IPv4-Adresse statt zu einem IPv4-Präfix. Zwei Mandanten können dieselben 32 Bit halten, weil sich die 64 Bit davor unterscheiden. Es gibt Formattypen für ein AS-basiertes RD und für ein adressbasiertes, und die Wahl gehört zum ursprünglichen PE. Ein AS-basiertes RD ist üblich, wenn die PEs ein AS teilen, ein adressbasiertes, wenn nicht.
Lesen Sie das RD nicht als Mitgliedschaftsetikett. Route Targets steuern Import und Export und entscheiden, welche VRFs die Route installieren dürfen; das RD garantiert nur, dass die Route eine eigene Identität hat. Jedem VRF sein eigenes RD zu geben ist gängige Praxis, weil es diese Zuordnung in einer Routenübersicht lesbar hält.
Das Label ist eine lokale Weiterleitungsanweisung
Jede Ankündigung trägt außerdem ein MPLS-Label, dessen Bedeutung auf den Router beschränkt ist, der es vergeben hat. Ein anderer PE kann dieselbe Nummer für ein unabhängiges Ziel ausgeben. Genau deshalb kann das Label die Kundenidentität nicht ersetzen: Die Nummer stimmt nur neben dem nächsten Hop und dem Weiterleitungszustand, der sie installiert hat.
Die Vergabegranularität hängt von Implementierung und Design ab: Manche Plattformen vergeben ein Label pro VRF, andere pro Präfix, und das Label kann eine Weiterleitungsaktion statt eines Kunden bezeichnen. Zwei verschiedene Labels, die dasselbe Ziel erreichen, sind kein Widerspruch, und dieselbe Labelnummer an zwei PEs auch nicht.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
Warum das eine das andere nicht ersetzen kann
Eine Ankündigung zu lesen heißt, vier Dinge zusammen zu betrachten: das RD-qualifizierte Präfix, die Route Targets, den nächsten Hop und das Label. Ein Nutzerpaket zu lesen heißt, den daraus installierten Stack zu betrachten. Ein gesundes Design zeigt beide Seiten übereinstimmend, und ein kaputtes hat meist eine Seite richtig und die andere veraltet. Dieser Vergleich trennt ein Identitätsproblem von einem Weiterleitungsproblem.
Der saubere Gegensatz zwischen Kontroll- und Datenebene ist ein Lehrhilfsmittel, keine Beschreibung der Kodierung. RFC 8277 legt das Label in die gelabelte NLRI, sodass die Ankündigung selbst die Bindung trägt; es zur Weiterleitung zu nutzen ist der spätere, getrennte Schritt.
Wenn eine Mandantenroute fehlt, prüfen Sie in dieser Reihenfolge: zwei VPNv4-Einträge für das Präfix, das richtige Route Target auf jedem, einen auflösbaren nächsten Hop und ein Label, für das der empfangende PE Zustand hat. Identität mit einem Weiterleitungswert zu reparieren, oder umgekehrt, besteht die eine Prüfung und scheitert an der nächsten.