IPv6 i et MPLS-VPN: tre valg, ikke én adressefamilie
Kundens VPN-ruter, BGP-økten mellom PE-ene og transporten i kjernen er separate beslutninger. En økt kan kjøre i én familie og bære en annen.
Si «kjør en IPv6 L3VPN over IPv6 BGP» i en designgjennomgang, og i den ene setningen skjuler det seg tre separate beslutninger. Hvilke prefikser som hører til kundens VPN, hvilke adresser som bærer rutingsøkten mellom leverandørens kanter, og hvilken kjerne som flytter den merkede pakken, er uavhengige valg. De kan alle være IPv6, de kan være blandet, og blanding er med vilje tillatt. Det er oppklaringen av de tre som gjør et vagt krav om til noe en plattform kan testes mot.
Skill de tre oppgavene
Den første oppgaven er kunderuten: IPv6-prefikser som hører til én VPN-rutingskontekst og må holdes utenfor enhver annen kontekst. Den andre er rutingsforbindelsen mellom leverandørens kantrutere som utveksler disse prefiksene. Den tredje er transporten som bærer den merkede kundepakken gjennom kjernen til den fjerne kanten. Å navngi bare én av dem er ennå ikke et 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 |
Hver oppgave har sin egen adressefamilie, sine egne feilmåter og ofte sitt eget team. Tabellen er nyttig nettopp fordi én setning i et designdokument har en tendens til å presse alle tre radene sammen til én.
Rutefamilien er VPN-IPv6, ikke IPv6 unicast
RFC 4659 definerer BGP/MPLS IPv6 VPN-familien, og medlemskap i den er mer spesifikt enn ordet IPv6 antyder. En rute der er en rutedistinguisher knyttet til et IPv6-prefiks, kodet under AFI 2 og SAFI 128. Vanlig IPv6 unicast er en annen familie, så en annonse som ser ut som et prefiks i et looking glass, er kanskje ikke det samme objektet i det hele tatt. Å lese familien feil er den første måten dette designet går galt.
Forskjellen biter ved kanten, der en rute må lande i riktig VPN-kontekst før den gjør noe som helst. Å motta et prefiks beviser at utvekslingen skjedde og sier ingenting om installasjonen. Det gapet gir den klassiske rapporten der økten er oppe og kunden fortsatt er mørk.
Økten kan kjøre i en annen familie enn VPN-en
Ingenting tvinger BGP-forbindelsen mellom to kanter til å bruke VPN-ens egen familie. Spesifikasjonen tillater en IPv4- eller IPv6-økt, og IPv6 VPN-transport er selv definert over begge kjernetypene. En IPv6-økt sier derfor ingenting om familien til det den bærer, og den velger heller ikke dataplanet. Tre uavhengige biter, og designet bør bære alle tre hver for seg.
Det er frigjørende og lett å lese feil i samme åndedrag. IPv6-kunderuter kan ri på en økt med IPv4-adresse, og IPv4-ruter på en IPv6-økt, forutsatt at plattformen støtter kombinasjonen og at neste hopp løses opp. Det som ikke må skje, er å la økten implisere nyttelasten, i designdokumentet eller i overvåkingen som senere beviser tjenesten.
Neste hopp på en IPv4-kjerne har sin egen koding
Når kjernen under VPN-en er IPv4, dukker ikke ruten opp med et neste hopp som inngangskanten kan bruke direkte. Den kommer i IPv4-mappet IPv6-form, og slik uttrykker spesifikasjonen utgangskanten når transporten under er IPv4. Inngangsruteren må da gjøre den mappede adressen om til noe den faktisk kan nå gjennom kjernen, og oppløsningen er trinnet som stille feiler.
Les det som en videresendingsavhengighet og ikke som en streng som skal kopieres mellom enheter. Bekreft tre ting på plattformen du faktisk drifter: det annonserte neste hoppet løses opp til en brukbar vei, labelstakken godtas, og destinasjonen lander i den tiltenkte VPN-konteksten. Feiler ett av dem, står man igjen med en økt som ser sunn ut og ikke videresender noe, og derfor hører kontrollen hjemme i akseptkjøringen og ikke i en senere hendelse.
Skriv kravet på fire linjer
Et krav som er verdt å teste navngir fire ting: VPN-familien, øktens transport, kodingen av neste hopp og oppsettet av kjernen. Deretter navngir det ett kundeprefiks som skal følges fra ende til annen: gjennom utveksling, installasjon, labeloppløsning og returvei. «Støtter IPv6 BGP» dekker ingen av de fire og skjuler hvor uoverensstemmelsen faktisk bor.
En sunn økt uten VPN-IPv6-utvekslingen er ufullstendig, og en mottatt VPN-rute uten fungerende videresending er like ufullstendig. Å holde dem som separate akseptlinjer gjør den neste feilsøkingssamtalen kort, fordi linjen som feiler allerede er skrevet ned.