RD gegen RT im MPLS-VPN: Eindeutigkeit gegen Importrichtlinie

Ein Route Distinguisher macht überlappende Präfixe eindeutig, ein Route Target bestimmt, welche Routen ein VRF importieren darf. Folgen Sie einer MPLS-Route durch beide Rollen.

Zwei Kundensites können 10.20.0.0/24 annoncieren, und beide bleiben innerhalb eines Providernetzes gültig. Der Route Distinguisher hält diese Annoncen auseinander; der Route Target entscheidet, welches Kunden-VRF eine Kopie übernehmen darf. In der Konfiguration stehen sie nebeneinander und erledigen völlig unterschiedliche Aufgaben. Eine Verwechslung führt zu Änderungen, die vernünftig aussehen und nichts reparieren.

Folgen Sie einer Route von der Kundenseite bis zu einem entfernten VRF und die Trennung wird konkret: Die Identität wird angehängt, bevor die Route in BGP gelangt, und die Verteilungspolitik wird bewertet, wenn die Route den empfangenden Provider-Rand erreicht.

Eine VPN-IPv4-Route ist ein RD plus ein IPv4-Präfix

RFC 4364 definiert die VPN-IPv4-Adressfamilie als acht Byte Route Distinguisher, gefolgt von einer vier Byte langen IPv4-Adresse. Der RD wird dem Kundenpräfix vorangestellt, sodass zwei identische Präfixe aus verschiedenen Sites zu zwei verschiedenen BGP-Routen werden.

Diese Konstruktion ist der gesamte Eindeutigkeitsmechanismus. Der Provider braucht keine Einigung der Kunden auf überlappungsfreien Adressraum, und eine Route von einer Site kann ein identisches Präfix einer anderen Site nicht still ersetzen.

Das RD-Format selbst ist ein vom Administrator gewählter Wert, üblicherweise eine autonome Systemnummer und eine lokale Nummer. Seine numerische Form ist eine Konvention, kein Signal dafür, dass die beiden Felder eine Bedeutung mit einem Route Target teilen, das zufällig dieselben Ziffern verwendet.

Der RD macht überlappende Präfixe unterscheidbar

Betrachten Sie zwei Annoncen für dasselbe Präfix. Site A trägt RD 65000:101 und Site B trägt RD 65000:202, beide für 10.20.0.0/24. BGP hält nun zwei VPN-IPv4-Routen, die unabhängig verglichen, gefiltert und ausgewählt werden können.

Der RD sagt nicht, welches VRF eine der beiden Routen erhalten soll, und er identifiziert weder einen Kunden noch einen Dienst. Er ist ein Identitätsfeld der Route, keine Mitgliederliste. Das eigene RD eines VRF muss nicht zum RD einer von ihm importierten Route passen.

Deshalb repariert es nichts, ein RD auf die Nummer einer anderen Site zu ändern. Fehlt eine Route auf der Gegenseite, erzeugen die passenden Ziffern ein anderes Identitätsproblem, statt die Importentscheidung zu reparieren.

Der RT ist ein BGP-Attribut, kein Paket-Tag

Eine Exportrichtlinie hängt einen oder mehrere Route Targets als erweiterte BGP-Community-Attribute an die Route. Der empfangende Provider-Rand vergleicht diese Attribute mit der Importrichtlinie jedes VRF. Der RT reist mit der Route durch die Steuerungsebene. Der Vergleich findet vollständig in der Routingrichtlinie statt, bevor ein Kundenpaket weitergeleitet wird.

Kundendatenpakete tragen den RT nicht. Sobald eine Route in einem VRF installiert ist, nutzt die Weiterleitung die Tabelle dieses VRF und den MPLS-Labelstapel, den die Architektur vergibt. Der Provider-Rand liest kein Route Target aus jedem Kundenpaket.

Eine Route kann mehrere RTs tragen, und ein VRF kann mehrere importieren. Die Konfiguration sieht oft wie ein kurzer Block aus:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Lesen Sie diesen Block als zwei getrennte Aussagen. Die Exportzeile steuert, was an Routen angehängt wird, die dieses VRF verlassen; die Importzeile steuert, was dieses VRF zu berücksichtigen bereit ist. Übereinstimmende Nummern sind praktisch, nicht zwingend.

Importberechtigung ist keine Installation

Eine Route kann für ein VRF berechtigt sein und trotzdem nicht in dessen Weiterleitungstabelle erscheinen. Die Berechtigung ist ein Filter; danach vergleicht der normale BGP-Entscheidungsprozess die berechtigten Routen und wählt eine aus. Eine ältere oder weniger bevorzugte Route kann gegen einen anderen berechtigten Pfad verlieren.

Prüfen Sie die ausgewählte Route, nicht nur die Importrichtlinie. Ein VRF, das RT 65000:500 importiert und keine Route für 10.20.0.0/24 zeigt, hat die Route möglicherweise erhalten und bei der Auswahl verworfen, oder es hat sie nie erhalten.

Diese Unterscheidung zählt auch, wenn ein unerwartetes Präfix auftaucht. Eine zu breite Importrichtlinie kann Routen hereinziehen, die die Site nicht nutzen wollte, und die Eindeutigkeit des RD verhindert das keineswegs. Der Verteilungsumfang ist eine Frage der RT-Richtlinie.

Debuggen Sie eine fehlende Route in der Reihenfolge der Steuerungsebene

Beginnen Sie mit der Annonce: Exportiert das Ursprungs-VRF den vorgesehenen RT, und existiert die Route als VPN-IPv4-Route auf dem Route Reflector oder dem empfangenden PE? Prüfen Sie dann das Attribut so, wie es empfangen wurde, nicht wie es beim Sender konfiguriert ist.

Vergleichen Sie als Nächstes die Importliste des empfangenden VRF mit den tatsächlichen RT-Werten der Route. Prüfen Sie schließlich die ausgewählte Route in diesem VRF und die Labelbindung. Jeder Schritt beantwortet eine andere Frage, und ein Sprung zum RD überspringt meist genau den falschen.

Notieren Sie das RD, den exportierten RT, den importierten RT und den ausgewählten Next Hop für die funktionierende und die fehlerhafte Site. Vier Werte nebeneinander verwandeln ein vages „das VPN leitet keine Routen weiter“ in den genauen Steuerungsebenen-Schritt, der sich unterscheidet.

Ähnliche Artikel