IPv6 i et MPLS VPN: tre valg, ikke én adressefamilie
Kundens VPN-ruter, BGP-sessionen mellem PE og transporten i kernen er separate beslutninger. En session kan køre i én familie og bære en anden.
Sig „kør en IPv6 L3VPN over IPv6 BGP“ i et designreview, og der gemmer sig tre separate beslutninger i den ene sætning. Hvilke præfikser der hører til kundens VPN, hvilke adresser der bærer routing-sessionen mellem udbyderens kanter, og hvilken kerne der flytter den mærkede pakke, er uafhængige valg. De kan alle være IPv6, de kan være blandede, og blanding er tilladt med vilje. Det er opklaringen af de tre, der gør et vagt krav til noget, en platform kan testes imod.
Adskil de tre opgaver
Den første opgave er kunderuten: IPv6-præfikser der hører til én VPN-routingkontekst og skal holdes ude af enhver anden kontekst. Den anden er routingforbindelsen mellem udbyderens kantroutere, som udveksler de præfikser. Den tredje er transporten, der bærer den mærkede kundepakke gennem kernen til den fjerne kant. At navngive kun én af dem er endnu 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 opgave har sin egen adressefamilie, sine egne fejlmåder og ofte sit eget team. Tabellen er nyttig netop fordi én sætning i et designdokument har en tendens til at presse alle tre rækker sammen til én.
Rutefamilien er VPN-IPv6, ikke IPv6 unicast
RFC 4659 definerer BGP/MPLS IPv6 VPN-familien, og medlemskab af den er mere specifikt, end ordet IPv6 antyder. En rute der er en routedistinguisher knyttet til et IPv6-præfiks, kodet under AFI 2 og SAFI 128. Almindelig IPv6 unicast er en anden familie, så en annoncering, der i et looking glass ligner et præfiks, er måske slet ikke det samme objekt. Forkert læsning af familien er den første måde, dette design går galt.
Forskellen bider ved kanten, hvor en rute skal lande i den rigtige VPN-kontekst, før den gør noget som helst. At modtage et præfiks beviser, at udvekslingen skete, og siger intet om installation. Det hul giver den klassiske rapport, hvor sessionen er oppe, og kunden stadig er mørk.
Sessionen kan køre i en anden familie end VPN'en
Intet tvinger BGP-forbindelsen mellem to kanter til at bruge VPN'ens egen familie. Specifikationen tillader en IPv4- eller IPv6-session, og IPv6 VPN-transport er selv defineret over begge kernetyper. En IPv6-session siger derfor intet om familien af det, den bærer, og den vælger heller ikke dataplanet. Tre uafhængige bits, og designet bør bære alle tre hver for sig.
Det er befriende og let at læse forkert i samme åndedrag. IPv6-kunderuter kan køre på en session med IPv4-adresse, og IPv4-ruter kan køre på en IPv6-session, forudsat at platformen understøtter kombinationen, og at næste hop opløses. Det, der ikke må ske, er at lade sessionen antyde nyttelasten, i designdokumentet eller i den overvågning, der senere beviser tjenesten.
Næste hop på en IPv4-kerne har sin egen kodning
Når kernen under VPN'en er IPv4, vises ruten ikke med et næste hop, som indgangskanten kan bruge direkte. Den ankommer i IPv4-mappet IPv6-form, og det er sådan specifikationen udtrykker udgangskanten, når transporten nedenunder er IPv4. Indgangsrouteren skal derefter gøre den mapperede adresse til noget, den faktisk kan nå gennem kernen, og opløsningen er det trin, der stilfærdigt fejler.
Læs det som en videresendelsesafhængighed og ikke som en streng, der skal kopieres mellem enheder. Bekræft tre ting på den platform, du faktisk kører: det annoncerede næste hop opløses til en brugbar sti, labelstakken accepteres, og destinationen lander i den tilsigtede VPN-kontekst. Hvis blot én af dem fejler, står man med en session, der ser sund ud og ikke videresender noget, og derfor hører kontrollen hjemme i acceptkørslen og ikke i en senere hændelse.
Skriv kravet i fire linjer
Et krav, der er værd at teste, navngiver fire ting: VPN-familien, sessionens transport, kodningen af næste hop og kernens opbygning. Derefter navngiver det ét kundepræfiks, der skal følges fra ende til anden: gennem udveksling, installation, labelopløsning og returvej. „Understøtter IPv6 BGP“ dækker ingen af de fire og skjuler, hvor uoverensstemmelsen faktisk bor.
En sund session uden VPN-IPv6-udvekslingen er ufuldstændig, og en modtaget VPN-rute uden fungerende videresendelse er lige så ufuldstændig. At holde dem som separate acceptlinjer gør den næste fejlfindingssamtale kort, fordi den fejlende linje allerede er skrevet ned.