IPv6 i eit MPLS-VPN: tre val, ikkje éin adressefamilie
VPN-rutene til kunden, BGP-økta mellom PE-ane og transporten i kjernen er separate avgjerder. Ei økt kan køyre i éin familie og bera ein annan.
Sei «køyr ein IPv6 L3VPN over IPv6 BGP» i ein designgjennomgang, og i den eine setninga ligg tre separate avgjerder gøymde. Kva prefiks som høyrer til VPN-en til kunden, kva adresser som ber rutingsøkta mellom kantane til leverandøren, og kva kjerne som flyttar den merkte pakken, er uavhengige val. Dei kan alle vere IPv6, dei kan vere blanda, og blanding er med vilje tillaten. Det er oppklaringa av dei tre som gjer eit vagt krav om til noko ein plattform kan testast mot.
Skil dei tre oppgåvene
Den første oppgåva er kunderuta: IPv6-prefiks som høyrer til éin VPN-rutingskontekst og må haldast utanfor kvar annan kontekst. Den andre er rutingssambandet mellom kantrutarane til leverandøren som byter desse prefiksa. Den tredje er transporten som ber den merkte kundepakken gjennom kjernen til den fjerne kanten. Å nemne berre éin av dei er enno ikkje eit 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 |
Kvar oppgåve har sin eigen adressefamilie, sine eigne feilmåtar og ofte sitt eige team. Tabellen er nyttig nettopp fordi éi setning i eit designdokument har ein tendens til å presse alle tre radene saman til éi.
Rutefamilien er VPN-IPv6, ikkje IPv6 unicast
RFC 4659 definerer BGP/MPLS IPv6 VPN-familien, og medlemskap i han er meir spesifikt enn ordet IPv6 antydar. Ei rute der er ein rutedistinguisher knytt til eit IPv6-prefiks, koda under AFI 2 og SAFI 128. Vanleg IPv6 unicast er ein annan familie, så ei kunngjering som ser ut som eit prefiks i eit looking glass, er kanskje ikkje same objektet i det heile. Å lese familien feil er den første måten dette designet går gale.
Skilnaden bit ved kanten, der ei rute må lande i rett VPN-kontekst før ho gjer noko som helst. Å ta imot eit prefiks provar at utvekslinga skjedde og seier ingenting om installasjonen. Det gapet gjev den klassiske rapporten der økta er oppe og kunden framleis er mørk.
Økta kan køyre i ein annan familie enn VPN-en
Ingenting tvingar BGP-sambandet mellom to kantar til å bruke den eigen familien til VPN-en. Spesifikasjonen tillèt ei IPv4- eller IPv6-økt, og IPv6 VPN-transport er sjølv definert over begge kjernetypane. Ei IPv6-økt seier derfor ingenting om familien til det ho ber, og ho vel heller ikkje dataplanet. Tre uavhengige bitar, og designet bør bera alle tre kvar for seg.
Det er frigjerande og lett å lese feil i same andedrag. IPv6-kunderuter kan ri på ei økt med IPv4-adresse, og IPv4-ruter på ei IPv6-økt, føresett at plattformen støttar kombinasjonen og at neste hopp blir løyst opp. Det som ikkje må skje, er å la økta implisere nyttelasta, i designdokumentet eller i overvakinga som seinare provar tenesta.
Neste hopp på ein IPv4-kjerne har si eiga koding
Når kjernen under VPN-en er IPv4, dukkar ikkje ruta opp med eit neste hopp som inngangskanten kan bruke direkte. Ho kjem i IPv4-mappa IPv6-form, og slik uttrykkjer spesifikasjonen utgangskanten når transporten under er IPv4. Inngangsrutaren må då gjere den mappa adressa om til noko han faktisk kan nå gjennom kjernen, og oppløysinga er trinnet som stille feilar.
Les det som ein videresendingsavhengigheit og ikkje som ein streng som skal kopierast mellom einingar. Stadfest tre ting på plattformen du faktisk driftar: det kunngjorde neste hoppet blir løyst opp til ein brukbar veg, labelstakken blir godteken, og destinasjonen landar i den tiltenkte VPN-konteksten. Feilar eitt av dei, står ein att med ei økt som ser sunn ut og ikkje videresender noko, og difor høyrer kontrollen heime i akseptkøyringa og ikkje i ei seinare hending.
Skriv kravet på fire linjer
Eit krav som er verdt å teste nemner fire ting: VPN-familien, transporten til økta, kodinga av neste hopp og oppsettet av kjernen. Deretter nemner det eitt kundeprefiks som skal følgjast frå ende til annan: gjennom utveksling, installasjon, labeloppløysing og returveg. «Støttar IPv6 BGP» dekkjer ingen av dei fire og gøymer kvar uoverensstemminga faktisk bur.
Ei sunn økt utan VPN-IPv6-utvekslinga er ufullstendig, og ei motteken VPN-rute utan fungerande videresending er like ufullstendig. Å halde dei som separate akseptlinjer gjer den neste feilsøkingssamtalen kort, fordi linja som feilar allereie er skriven ned.