IPv6 MPLS VPN: trys pasirinkimai, o ne viena adresų šeima
Kliento VPN maršrutai, BGP sesija tarp PE ir transportas branduolyje yra atskiri sprendimai. Sesija gali veikti vienoje šeimoje ir pernešti kitą.
Pasakykite projektavimo apžvalgoje „paleisk IPv6 L3VPN per IPv6 BGP“ ir tame viename sakinyje slypi trys atskiri sprendimai. Kurie prefiksai priklauso kliento VPN, kurie adresai neša maršrutizavimo sesiją tarp tiekėjo kraštų ir kuris branduolys perkelia paženklintą paketą, yra nepriklausomi pasirinkimai. Visi jie gali būti IPv6, gali būti sumaišyti, o maišymas leidžiamas tyčia. Būtent šių trijų atskyrimas paverčia neaiškų reikalavimą kažkuo, prieš ką platformą galima išbandyti.
Atskirkite tris darbus
Pirmas darbas yra kliento maršrutas: IPv6 prefiksai, priklausantys vienam VPN maršrutizavimo kontekstui ir turintys likti už kiekvieno kito konteksto. Antrasis yra maršrutizavimo ryšys tarp tiekėjo krašto maršrutizatorių, kurie keičiasi tais prefiksais. Trečiasis yra transportas, nešantis paženklintą kliento paketą per branduolį į tolimą kraštą. Pavadinti tik vieną iš jų dar nėra projektas.
| 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 |
Kiekvienas darbas turi savo adresų šeimą, savo gedimo būdus ir dažnai savo komandą. Lentelė naudinga būtent todėl, kad vienas sakinys projektavimo dokumente linkęs sutraukti visas tris eilutes į vieną.
Maršruto šeima yra VPN-IPv6, o ne IPv6 unicast
RFC 4659 apibrėžia BGP/MPLS IPv6 VPN šeimą, o priklausymas jai yra konkretesnis, nei leidžia suprasti žodis IPv6. Maršrutas ten yra maršruto skiriamasis elementas, sujungtas su IPv6 prefiksu ir užkoduotas pagal AFI 2 ir SAFI 128. Įprastas IPv6 unicast yra kita šeima, todėl skelbimas, kuris looking glass atrodo kaip prefiksas, gali būti visai ne tas pats objektas. Neteisingas šeimos perskaitymas yra pirmas būdas, kuriuo šis projektas pakrypsta ne taip.
Skirtumas kandus krašte, kur maršrutas pirmiausia turi nusileisti į teisingą VPN kontekstą, prieš ką nors darydamas. Prefikso gavimas įrodo, kad keitimasis įvyko, ir nieko nesako apie įdiegimą. Šis tarpas sukuria klasikinę ataskaitą, kai sesija veikia, o klientas vis dar tamsu.
Sesija gali veikti kitoje šeimoje nei VPN
Niekas neverčia BGP ryšio tarp dviejų kraštų naudoti pačios VPN šeimos. Specifikacija leidžia IPv4 arba IPv6 sesiją, o IPv6 VPN transportas pats apibrėžtas abiejų tipų branduolyje. Todėl IPv6 sesija nieko nesako apie šeimą to, ką ji neša, ir taip pat nepasirenka duomenų plokštumos. Trys nepriklausomi bitai, ir projektas turėtų nešti visus tris atskirai.
Tai išlaisvina ir tuo pačiu metu lengva perskaityti neteisingai. IPv6 kliento maršrutai gali važiuoti sesija su IPv4 adresu, o IPv4 maršrutai – su IPv6, jei platforma palaiko šį derinį ir kitas šuolis išsprendžiamas. Netaip neturi atsitikti tai, kad sesija užsimintų apie naudingąją apkrovą, nei projektavimo dokumente, nei stebėjime, kuris vėliau įrodo paslaugą.
Kitas šuolis IPv4 branduolyje turi savo kodavimą
Kai branduolys po VPN yra IPv4, maršrutas nepasirodo su kitu šuoliu, kurį įėjimo kraštas galėtų naudoti tiesiogiai. Jis ateina IPv4 susieto IPv6 pavidalu, ir taip specifikacija išreiškia išėjimo kraštą, kai transportas po juo yra IPv4. Tada įėjimo maršrutizatorius turi paversti tą susietą adresą kažkuo, ką iš tikrųjų pasieks per branduolį, o sprendimas yra žingsnis, kuris tyliai nepavyksta.
Skaitykite tai kaip persiuntimo priklausomybę, o ne kaip eilutę, kurią reikia kopijuoti tarp įrenginių. Patvirtinkite tris dalykus platformoje, kurią iš tikrųjų valdote: paskelbtas kitas šuolis išsprendžiamas į naudingą kelią, etikečių rietuvė priimama, o paskirties vieta nusileidžia numatytame VPN kontekste. Jei kuris nors nepavyksta, lieka sesija, kuri atrodo sveika ir nieko nepersiunčia, todėl šis patikrinimas priklauso priėmimo bandymui, o ne vėlesniam incidentui.
Parašykite reikalavimą keturiomis eilutėmis
Reikalavimas, kurį verta bandyti, įvardija keturis dalykus: VPN šeimą, sesijos transportą, kito šuolio kodavimą ir branduolio išdėstymą. Tada įvardija vieną kliento prefiksą, kurį reikia sekti nuo pradžios iki galo: per keitimąsi, įdiegimą, etikečių sprendimą ir grįžimo kelią. „Palaiko IPv6 BGP“ neapima nė vieno iš keturių ir paslepia, kur iš tikrųjų yra neatitikimas.
Sveika sesija be VPN-IPv6 keitimosi yra nepilna, o gautas VPN maršrutas be veikiančio persiuntimo yra lygiai taip pat nepilnas. Laikyti juos atskiromis priėmimo eilutėmis sutrumpina kitą trikčių šalinimo pokalbį, nes nepavykstanti eilutė jau užrašyta.