IPv6 egy MPLS VPN-ben: három döntés, nem egy címcsalád
Az ügyfél VPN-útvonalai, a PE-k közötti BGP-munkamenet és a mag átvitele külön döntések. Egy munkamenet futhat az egyik családban, és szállíthat egy másikat.
Mondd egy tervellenőrzésen, hogy „futtass egy IPv6 L3VPN-t IPv6 BGP fölött”, és abban az egy mondatban három külön döntés rejtőzik. Mely előtagok tartoznak az ügyfél VPN-jéhez, mely címek hordozzák a forgalomirányítási munkamenetet a szolgáltató peremei között, és melyik mag mozgatja a címkézett csomagot, független választások. Mind lehet IPv6, lehetnek keverve, és a keverés szándékosan megengedett. Éppen a három szétválasztása teszi a homályos követelményt olyasmivé, ami ellen egy platform tesztelhető.
Válaszd szét a három feladatot
Az első feladat az ügyfélútvonal: IPv6-előtagok, amelyek egy VPN-forgalomirányítási kontextushoz tartoznak, és minden más kontextuson kívül kell maradniuk. A második a forgalomirányítási kapcsolat a szolgáltató peremrouterei között, amelyek ezeket az előtagokat cserélik. A harmadik az átvitel, amely a címkézett ügyfélsomagot a magon át a távoli peremig viszi. Csak egyet megnevezni még nem terv.
| 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 |
Minden feladatnak saját címcsaládja, saját hibaformái és gyakran saját csapata van. A táblázat éppen azért hasznos, mert egy mondat egy tervdokumentumban hajlamos mindhárom sort eggyé lapítani.
Az útvonal családja VPN-IPv6, nem IPv6 unicast
RFC 4659 definiálja a BGP/MPLS IPv6 VPN családot, és a tagság benne pontosabb, mint amit az IPv6 szó sugall. Az ottani útvonal egy útvonal-megkülönböztető, amely IPv6-előtaghoz kapcsolódik, és AFI 2, valamint SAFI 128 alatt van kódolva. A közönséges IPv6 unicast más család, ezért egy looking glassban előtagként kinéző hirdetés talán egyáltalán nem ugyanaz az objektum. A család félreolvasása az első módja annak, hogy ez a terv félresiklik.
A különbség a peremnél harap, ahol az útvonalnak előbb a helyes VPN-kontextusba kell landolnia, mielőtt bármit tenne. Egy előtag megérkezése bizonyítja, hogy a csere megtörtént, és semmit sem mond a telepítésről. Ez a rés termeli a klasszikus jelentést, amelyben a munkamenet áll, az ügyfél pedig még mindig sötétben van.
A munkamenet futhat a VPN-től eltérő családban
Semmi sem kényszeríti a két perem közötti BGP-kapcsolatot, hogy a VPN saját családját használja. A specifikáció megengedi az IPv4-es vagy IPv6-os munkamenetet, és az IPv6 VPN átvitel maga mindkét magtípus fölött definiált. Az IPv6-os munkamenet tehát semmit sem mond a szállított dolog családjáról, és az adatsíkot sem választja ki. Három független bit, és a tervnek mindhármat külön kell hordoznia.
Ez felszabadító, és ugyanabban a lélegzetben könnyű félreolvasni. Az IPv6-os ügyfélútvonalak futhatnak IPv4-címes munkameneten, az IPv4-es útvonalak pedig IPv6-oson, feltéve hogy a platform támogatja a kombinációt, és a következő ugrás feloldódik. Amit nem szabad hagyni, az az, hogy a munkamenet a hasznos terhelésre utaljon, a tervdokumentumban vagy a szolgáltatást később bizonyító monitorozásban.
Az IPv4-es magon a következő ugrásnak saját kódolása van
Amikor a VPN alatti mag IPv4, az útvonal nem olyan következő ugrással jelenik meg, amelyet a belépő perem közvetlenül használhatna. IPv4-be leképezett IPv6 formában érkezik, és így fejezi ki a specifikáció a kilépő peremet, amikor az alatta lévő átvitel IPv4. A belépő routernek ezt a leképezett címet olyasmivé kell tennie, amit a magon át valóban elér, és a feloldás az a lépés, amely csendesen elbukik.
Olvasd továbbítási függőségként, ne eszközök között másolandó karakterláncként. Erősíts meg három dolgot a platformon, amelyet valóban üzemeltetsz: a hirdetett következő ugrás használható útvonalra oldódik fel, a címeköteg elfogadásra kerül, és a cél a szándékolt VPN-kontextusba landol. Ha bármelyik elbukik, marad egy munkamenet, amely egészségesnek látszik és semmit sem továbbít, ezért az ellenőrzés az átvételi futásba tartozik, nem egy későbbi incidensbe.
Írd le a követelményt négy sorban
A tesztelésre érdemes követelmény négy dolgot nevez meg: a VPN családját, a munkamenet átvitelét, a következő ugrás kódolását és a mag elrendezését. Aztán megnevez egy ügyfélelőtagot, amelyet végig kell követni: cserén, telepítésen, címkefeloldáson és visszaúton át. Az „támogatja az IPv6 BGP-t” egyiket sem fedi le a négy közül, és elrejti, hol lakik valójában az eltérés.
Az egészséges munkamenet VPN-IPv6 csere nélkül hiányos, és a fogadott VPN-útvonal működő továbbítás nélkül ugyanolyan hiányos. Ha ezeket külön átvételi sorként tartjuk, a következő hibakeresési beszélgetés rövid lesz, mert a bukó sor már le van írva.