IPv6 an engem MPLS-VPN: dräi Wiel, net eng Adressfamill
D'Client-VPN-Routen, d'BGP-Sessioun tëschent de PE an den Transport am Kär sinn getrennt Entscheidungen. Eng Sessioun kann an enger Famill lafen an eng aner droen.
Sot an enger Design-Review „laf en IPv6 L3VPN iwwer IPv6 BGP“, an an deem eenzegen Saz verstoppen sech dräi getrennt Entscheidungen. Wéi eng Präfixer zur VPN vum Client gehéieren, wéi eng Adressen d'Routing-Sessioun tëschent de Provider-Kanten droen a wéi e Kär de markéierte Pak beweegt, sinn onofhängeg Wahlen. Si kënnen all IPv6 sinn, si kënnen gemëscht sinn, an d'Mëschen ass bewosst erlaabt. Genau d'Entwéckelen vun dësen dräi mécht aus enger vageller Ufuerderung eppes, géint dat eng Plattform getest ka ginn.
Trennt déi dräi Aufgaben
Déi éischt Aufgab ass d'Client-Route: IPv6-Präfixer, déi zu engem VPN-Routing-Kontext gehéieren an aus all anere Kontext erausbleiwe mussen. Déi zweet ass d'Routing-Verbindung tëschent de Randroutere vum Provider, déi dës Präfixer austauschen. Déi drëtt ass den Transport, deen de markéierte Clientspak iwwer de Kär bis op de wäite Rand bréngt. Nëmmen eng dovun ze benennen ass nach keen 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 |
All Aufgab huet seng eegen Adressfamill, seng eege Fehlermuster an dacks säin eegent Team. D'Tabell ass just dofir nëtzlech, well ee Saz an engem Designdokument gär all dräi Zeilen an eng quetscht.
D'Famill vun der Route ass VPN-IPv6, net IPv6-Unicast
RFC 4659 definéiert d'Famill BGP/MPLS IPv6 VPN, an d'Memberschaft dran ass méi spezifesch wéi d'Wuert IPv6 et wëlle mécht. Eng Route do ass en Route Distinguisher, verbonne mat engem IPv6-Präfix, kodéiert ënner AFI 2 an SAFI 128. Gewéinlechen IPv6-Unicast ass eng aner Famill, also ass eng Annonce, déi an engem Looking Glass wéi e Präfix ausgesäit, vläicht guer net datselwecht Objet. D'Famill falsch ze liesen ass den éischte Wee, op deem dësen Design schif geet.
Den Ënnerscheed bäisst um Rand, wou eng Route muss an de richtege VPN-Kontext landen, ier se iergendeppes mécht. E Präfix ze kréien beweist, datt den Austausch stattfonnt huet, a seet näischt iwwer d'Installatioun. Dee Gruef produzéiert de klassesche Rapport, an deem d'Sessioun uewen ass an de Client nach ëmmer am Däischteren.
D'Sessioun kann an enger anerer Famill lafe wéi d'VPN
Näischt zwingt d'BGP-Verbindung tëschent zwou Kanten, d'eegen Famill vun der VPN ze benotzen. D'Spezifikatioun erlaabt eng IPv4- oder IPv6-Sessioun, an den IPv6-VPN-Transport ass selwer iwwer béid Kärtypen definéiert. Eng IPv6-Sessioun seet also näischt iwwer d'Famill vun deem, wat se dréit, a se wielt och net d'Dateplang. Dräi onofhängeg Bits, an den Design sollt all dräi getrennt droen.
Dat befrait an ass am selwechten Otem liicht falsch ze liesen. IPv6-Client-Route kënnen op enger Sessioun mat IPv4-Adress reiden, an IPv4-Route kënnen op enger IPv6-Sessioun, soulaang d'Plattform d'Kombinatioun ënnerstëtzt an den nächsten Hop sech opléist. Wat net dierf geschéien, ass datt d'Sessioun d'Payload implizéiert, am Designdokument oder an der Iwwerwaachung, déi de Service méi spéit beweise soll.
Den nächsten Hop op engem IPv4-Kär huet seng eege Kodéierung
Wann de Kär ënner der VPN IPv4 ass, erschéngt d'Route net mat engem nächsten Hop, deen d'Ingress-Kant direkt ka benotzen. Si kënnt an enger IPv4-gemappter IPv6-Form, an esou dréckt d'Spezifikatioun d'Egress-Kant aus, wann den Transport dorënner IPv4 ass. Den Ingress-Router muss dann déi gemappte Adress an eppes ëmwandelen, dat hien iwwer de Kär wierklech erreecht, an d'Opléisung ass de Schrëtt, dee stiil verfelt.
Liest dat als eng Forwarding-Ofhängegkeet an net als eng Zeechenkette, déi een tëschent Apparater kopéiert. Bestätegt dräi Saachen op der Plattform, déi Dir wierklech bedreift: den annoncéierten nächsten Hop léist sech op en notzbare Wee op, de Label-Stap gëtt ugeholl, an d'Destinatioun landet am virgesinnen VPN-Kontext. Wann ee vun deenen ausfält, bleift eng Sessioun, déi gesond ausgesäit an näischt weiderleet, an dofir gehéiert d'Préifung an den Ofname-Laf an net an en Accident méi spéit.
Schreift d'Ufuerderung a véier Zeilen
Eng Ufuerderung, déi et wäert ass ze testen, nennt véier Saachen: d'Famill vun der VPN, den Transport vun der Sessioun, d'Kodéierung vum nächsten Hop an d'Uerdnung vum Kär. Duerno nennt se ee Client-Präfix, deen een Enn bis dat anert verfollegt: duerch Austausch, Installatioun, Label-Opléisung a Retourwee. „Ënnerstëtzt IPv6 BGP“ deckt keng vun de véier of a verstoppt, wou d'Onstëmmegkeet wierklech sëtzt.
Eng gesond Sessioun ouni den VPN-IPv6-Austausch ass onkomplett, an eng empfaangen VPN-Route ouni funktionéierend Forwarding ass et genee esou. Se als getrennt Ofname-Zeilen ze halen mécht déi nächst Fehlersich-Gespréich kuerz, well déi feelend Zeil schonn opgeschriwwe steet.