IPv6 v MPLS VPN: tri rozhodnutia, nie jedna adresná rodina
Trasy klientskej VPN, BGP relácia medzi PE a transport v jadre sú oddelené rozhodnutia. Relácia môže bežať v jednej rodine a niesť inú.
Povedzte na návrhovej revízii „spusti IPv6 L3VPN cez IPv6 BGP“ a v tej jedinej vete sa skrývajú tri oddelené rozhodnutia. Ktoré prefixy patria klientskej VPN, ktoré adresy nesú smerovaciu reláciu medzi hranami poskytovateľa a ktoré jadro prenáša označený paket, sú nezávislé voľby. Všetky môžu byť IPv6, môžu byť zmiešané a miešanie je zámerne povolené. Práve rozpletenie tých troch premení neurčitú požiadavku na niečo, proti čomu sa platforma dá otestovať.
Oddeľte tri úlohy
Prvá úloha je klientska trasa: prefixy IPv6, ktoré patria jednému smerovaciemu kontextu VPN a musia zostať mimo každého iného kontextu. Druhá je smerovacie spojenie medzi hraničnými smerovačmi poskytovateľa, ktoré tie prefixy vymieňajú. Tretia je transport, ktorý nesie označený klientsky paket cez jadro k vzdialenej hrane. Pomenovať len jednu z nich ešte nie je návrh.
| 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 |
Každá úloha má vlastnú adresnú rodinu, vlastné spôsoby zlyhania a často vlastný tím. Tabuľka je užitočná práve preto, že jedna veta v návrhovom dokumente má sklon zlisovať všetky tri riadky do jedného.
Rodina trasy je VPN-IPv6, nie IPv6 unicast
RFC 4659 definuje rodinu BGP/MPLS IPv6 VPN a členstvo v nej je konkrétnejšie, než naznačuje slovo IPv6. Trasa je tam rozlišovač trasy spojený s prefixom IPv6 a kódovaný pod AFI 2 a SAFI 128. Bežný IPv6 unicast je iná rodina, takže inzerát, ktorý v looking glass vyzerá ako prefix, nemusí byť vôbec ten istý objekt. Nesprávne čítanie rodiny je prvý spôsob, akým tento návrh zlyhá.
Rozdiel hryzie na hrane, kde musí trasa najprv pristáť v správnom kontexte VPN, než čokoľvek urobí. Prijať prefix dokazuje, že výmena prebehla, a nič nehovorí o inštalácii. Táto medzera produkuje klasickú správu, keď je relácia hore a klient je stále v tme.
Relácia môže bežať v inej rodine ako VPN
Nič nenúti BGP spojenie medzi dvoma hranami používať vlastnú rodinu VPN. Špecifikácia povoľuje reláciu IPv4 alebo IPv6 a transport IPv6 VPN je sám definovaný nad oboma typmi jadra. Relácia IPv6 teda nič nehovorí o rodine toho, čo nesie, a nevyberá ani dátovú rovinu. Tri nezávislé bity a návrh by mal niesť všetky tri oddelene.
To oslobodzuje a zároveň sa to ľahko prečíta nesprávne. Klientske trasy IPv6 môžu ísť po relácii s adresou IPv4 a trasy IPv4 po relácii IPv6, ak platforma tú kombináciu podporuje a ďalší hop sa vyhodnotí. Čo nesmie nastať je, aby relácia naznačovala obsah, v návrhovom dokumente ani v monitoringu, ktorý službu neskôr preukazuje.
Ďalší hop na jadre IPv4 má vlastné kódovanie
Keď je jadro pod VPN IPv4, trasa sa neobjaví s ďalším hopom, ktorý by vstupná hrana mohla použiť priamo. Príde vo forme IPv6 mapovanej do IPv4, a tak špecifikácia vyjadruje výstupnú hranu, keď je transport pod ňou IPv4. Vstupný smerovač potom musí tú mapovanú adresu premeniť na niečo, na čo cez jadro skutočne dosiahne, a vyhodnotenie je krok, ktorý ticho zlyháva.
Čítajte to ako závislosť od preposielania, nie ako reťazec na kopírovanie medzi zariadeniami. Potvrďte tri veci na platforme, ktorú skutočne prevádzkujete: inzerovaný ďalší hop sa vyhodnotí na použiteľnú cestu, zásobník značiek sa prijme a cieľ pristane v zamýšľanom kontexte VPN. Ak čokoľvek z toho zlyhá, zostane relácia, ktorá vyzerá zdravo a nič nepreposiela, a preto kontrola patrí do akceptačného behu, nie do neskoršieho incidentu.
Napíšte požiadavku v štyroch riadkoch
Požiadavka, ktorá stojí za testovanie, pomenúva štyri veci: rodinu VPN, transport relácie, kódovanie ďalšieho hopu a usporiadanie jadra. Potom pomenúva jeden klientsky prefix, ktorý treba sledovať od začiatku do konca: cez výmenu, inštaláciu, vyhodnotenie značiek a spätnú cestu. „Podporuje IPv6 BGP“ nepokrýva ani jedno zo štyroch a skrýva, kde nezrovnalosť skutočne sídli.
Zdravá relácia bez výmeny VPN-IPv6 je neúplná a prijatá trasa VPN bez funkčného preposielania je rovnako neúplná. Držať ich ako oddelené akceptačné riadky skracuje ďalší rozhovor o riešení problémov, pretože zlyhávajúci riadok je už napísaný.