IPv6 in een MPLS-VPN: drie keuzes, niet één adresfamilie
De VPN-routes van de klant, de BGP-sessie tussen de PE's en het transport in de kern zijn aparte beslissingen. Een sessie kan in de ene familie draaien en een andere dragen.
Zeg in een ontwerpbespreking „draai een IPv6 L3VPN over IPv6 BGP”, en in die ene zin schuilen drie aparte beslissingen. Welke prefixen bij de VPN van de klant horen, welke adressen de routersessie tussen de randen van de provider dragen en welke kern het gelabelde pakket verplaatst, zijn onafhankelijke keuzes. Ze kunnen allemaal IPv6 zijn, ze kunnen gemengd zijn, en mengen is met opzet toegestaan. Juist het ontwarren van die drie maakt van een vage eis iets waar een platform tegen getest kan worden.
Scheid de drie taken
De eerste taak is de klantroute: IPv6-prefixen die bij één VPN-routeringscontext horen en buiten elke andere context moeten blijven. De tweede is de routeringsverbinding tussen de randrouters van de provider die die prefixen uitwisselen. De derde is het transport dat het gelabelde klantpakket door de kern naar de verre rand brengt. Alleen één ervan benoemen is nog geen ontwerp.
| 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 |
Elke taak heeft zijn eigen adresfamilie, zijn eigen faalwijzen en vaak zijn eigen team. De tabel is juist nuttig omdat één zin in een ontwerpdocument geneigd is alle drie de rijen in één samen te persen.
De routefamilie is VPN-IPv6, niet IPv6-unicast
RFC 4659 definieert de BGP/MPLS IPv6 VPN-familie, en lidmaatschap daarvan is specifieker dan het woord IPv6 suggereert. Een route daarin is een route-distinguisher gekoppeld aan een IPv6-prefix, gecodeerd onder AFI 2 en SAFI 128. Gewone IPv6-unicast is een andere familie, dus een aankondiging die in een looking glass op een prefix lijkt, is misschien helemaal niet hetzelfde object. De familie verkeerd lezen is de eerste manier waarop dit ontwerp misgaat.
Het verschil bijt aan de rand, waar een route eerst in de juiste VPN-context moet landen voordat ze iets doet. Een prefix ontvangen bewijst dat de uitwisseling plaatsvond en zegt niets over de installatie. Dat gat levert het klassieke rapport op waarin de sessie staat en de klant nog steeds donker is.
De sessie mag in een andere familie draaien dan de VPN
Niets dwingt de BGP-verbinding tussen twee randen om de eigen familie van de VPN te gebruiken. De specificatie staat een IPv4- of IPv6-sessie toe, en IPv6-VPN-transport is zelf over beide kerntypen gedefinieerd. Een IPv6-sessie zegt dus niets over de familie van wat ze draagt, en ze kiest ook het dataplane niet. Drie onafhankelijke bits, en het ontwerp zou alle drie apart moeten dragen.
Dat bevrijdt en is tegelijk makkelijk verkeerd te lezen. IPv6-klantroutes kunnen op een sessie met IPv4-adres rijden, en IPv4-routes op een IPv6-sessie, mits het platform de combinatie ondersteunt en de volgende hop oplost. Wat niet mag gebeuren, is dat de sessie de lading impliceert, in het ontwerpdocument of in de monitoring die de dienst later bewijst.
De volgende hop op een IPv4-kern heeft zijn eigen codering
Wanneer de kern onder de VPN IPv4 is, verschijnt de route niet met een volgende hop die de ingangsrand direct kan gebruiken. Ze komt in IPv4-gemapte IPv6-vorm aan, en zo drukt de specificatie de uitgangsrand uit wanneer het transport eronder IPv4 is. De ingangsrouter moet dat gemapte adres dan omzetten in iets wat hij daadwerkelijk over de kern kan bereiken, en de resolutie is de stap die stilletjes faalt.
Lees het als een doorstuur-afhankelijkheid en niet als een string om tussen apparaten te kopiëren. Bevestig drie dingen op het platform dat je werkelijk beheert: de aangekondigde volgende hop lost op naar een bruikbaar pad, de labelstack wordt geaccepteerd, en de bestemming landt in de bedoelde VPN-context. Faalt één daarvan, dan blijft er een sessie over die gezond lijkt en niets doorstuurt, en daarom hoort de controle in de acceptatierun en niet in een later incident.
Schrijf de eis in vier regels
Een eis die het testen waard is, noemt vier dingen: de VPN-familie, het transport van de sessie, de codering van de volgende hop en de opzet van de kern. Daarna noemt ze één klantprefix om van begin tot eind te volgen: via uitwisseling, installatie, labelresolutie en terugweg. „Ondersteunt IPv6 BGP” dekt geen van de vier en verbergt waar de mismatch werkelijk zit.
Een gezonde sessie zonder de VPN-IPv6-uitwisseling is onvolledig, en een ontvangen VPN-route zonder werkende doorsturing is net zo onvolledig. Ze als aparte acceptatieregels aanhouden maakt het volgende probleemoplossingsgesprek kort, omdat de regel die faalt al is opgeschreven.