IPv6 in einem MPLS-VPN: drei Entscheidungen, nicht eine Adressfamilie
Kundenrouten im VPN, die BGP-Sitzung zwischen den PE und der Transport im Kern sind getrennte Entscheidungen. Eine Sitzung kann in einer Familie laufen und eine andere tragen.
Sagen Sie in einem Design-Review „betreib ein IPv6-L3VPN über IPv6-BGP“, und in diesem einen Satz verstecken sich drei getrennte Entscheidungen. Welche Präfixe zum VPN des Kunden gehören, welche Adressen die Routing-Sitzung zwischen den Provider-Kanten tragen und welcher Kern das markierte Paket bewegt, sind unabhängige Wahlen. Sie können alle IPv6 sein, sie können gemischt sein, und das Mischen ist absichtlich erlaubt. Erst das Entwirren der drei macht aus einer vagen Anforderung etwas, wogegen eine Plattform getestet werden kann.
Trennen Sie die drei Aufgaben
Die erste Aufgabe ist die Kundenroute: IPv6-Präfixe, die zu einem VPN-Routing-Kontext gehören und aus jedem anderen Kontext herausbleiben müssen. Die zweite ist die Routing-Verbindung zwischen den Edge-Routern des Providers, die diese Präfixe austauschen. Die dritte ist der Transport, der das markierte Kundenpaket über den Kern zur entfernten Kante bringt. Nur eine davon zu benennen ist noch kein Design.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Jede Aufgabe hat ihre eigene Adressfamilie, ihre eigenen Fehlerbilder und oft ihr eigenes Team. Die Tabelle ist gerade deshalb nützlich, weil ein einziger Satz in einem Designdokument dazu neigt, alle drei Zeilen in eine zu quetschen.
Die Routenfamilie ist VPN-IPv6, nicht IPv6-Unicast
RFC 4659 definiert die BGP/MPLS-IPv6-VPN-Familie, und die Mitgliedschaft darin ist spezifischer, als das Wort IPv6 vermuten lässt. Eine Route dort ist ein Route Distinguisher, verbunden mit einem IPv6-Präfix, kodiert unter AFI 2 und SAFI 128. Gewöhnliches IPv6-Unicast ist eine andere Familie, also ist eine Ankündigung, die in einem Looking Glass wie ein Präfix aussieht, womöglich gar nicht dasselbe Objekt. Die Familie falsch zu lesen ist der erste Weg, auf dem dieses Design schiefgeht.
Der Unterschied beißt an der Kante, wo eine Route erst im richtigen VPN-Kontext landen muss, bevor sie irgendetwas tut. Ein Präfix zu empfangen beweist, dass der Austausch stattfand, und sagt nichts über die Installation. Diese Lücke erzeugt den klassischen Bericht, in dem die Sitzung steht und der Kunde trotzdem dunkel bleibt.
Die Sitzung darf in einer anderen Familie laufen als das VPN
Nichts zwingt die BGP-Verbindung zwischen zwei Kanten, die eigene Familie des VPN zu verwenden. Die Spezifikation erlaubt eine IPv4- oder IPv6-Sitzung, und IPv6-VPN-Transport ist selbst über beide Kerntypen definiert. Eine IPv6-Sitzung sagt daher nichts über die Familie dessen aus, was sie trägt, und sie wählt auch nicht die Datenebene. Drei unabhängige Bits, und das Design sollte alle drei getrennt führen.
Das befreit und ist im selben Atemzug leicht falsch zu lesen. IPv6-Kundenrouten können auf einer Sitzung mit IPv4-Adresse reiten, und IPv4-Routen auf einer IPv6-Sitzung, sofern die Plattform die Kombination unterstützt und der Next Hop auflöst. Was nicht passieren darf, ist die Sitzung die Nutzlast implizieren zu lassen, im Designdokument oder im Monitoring, das den Dienst später belegt.
Der Next Hop auf einem IPv4-Kern hat seine eigene Kodierung
Wenn der Kern unter dem VPN IPv4 ist, erscheint die Route nicht mit einem Next Hop, den die Eingangskante direkt nutzen kann. Sie kommt in IPv4-gemappter IPv6-Form an, und so drückt die Spezifikation die Ausgangskante aus, wenn der Transport darunter IPv4 ist. Der Eingangsrouter muss diese gemappte Adresse dann in etwas verwandeln, das er über den Kern tatsächlich erreichen kann, und die Auflösung ist der Schritt, der still scheitert.
Lesen Sie es als Weiterleitungsabhängigkeit und nicht als Zeichenkette, die man zwischen Geräten kopiert. Bestätigen Sie drei Dinge auf der Plattform, die Sie wirklich betreiben: Der angekündigte Next Hop löst zu einem nutzbaren Pfad auf, der Label-Stack wird akzeptiert, und das Ziel landet im beabsichtigten VPN-Kontext. Fällt eines davon aus, bleibt eine Sitzung, die gesund aussieht und nichts weiterleitet, und deshalb gehört die Prüfung in den Abnahmelauf statt in einen späteren Vorfall.
Schreiben Sie die Anforderung in vier Zeilen
Eine prüfenswerte Anforderung benennt vier Dinge: die VPN-Familie, den Transport der Sitzung, die Kodierung des Next Hop und die Anordnung des Kerns. Dann benennt sie ein Kundenpräfix, das von Ende zu Ende verfolgt wird: durch Austausch, Installation, Label-Auflösung und Rückweg. „Unterstützt IPv6-BGP“ deckt keines der vier ab und verbirgt, wo die Unstimmigkeit tatsächlich sitzt.
Eine gesunde Sitzung ohne den VPN-IPv6-Austausch ist unvollständig, und eine empfangene VPN-Route ohne funktionierende Weiterleitung ist es ebenso. Beides als getrennte Abnahmezeilen zu führen macht das nächste Fehlersuchegespräch kurz, weil die fehlschlagende Zeile schon aufgeschrieben ist.