IPv6 MPLS VPN-is: kolm otsust, mitte üks aadressiperekond
Kliendi VPN-i marsruudid, PE-de vaheline BGP-sessioon ja põhivõrgu transport on eraldi otsused. Sessioon võib töötada ühes perekonnas ja kanda teist.
Ütle projekteerimise ülevaatusel „jooksuta IPv6 L3VPN-i üle IPv6 BGP“ ja selles ühes lauses peitub kolm eraldi otsust. Millised prefiksid kuuluvad kliendi VPN-i, millised aadressid kannavad marsruutimissessiooni teenusepakkuja servade vahel ja milline põhivõrk liigutab märgistatud paketi, on sõltumatud valikud. Kõik need võivad olla IPv6, need võivad olla segatud ja segamine on meelega lubatud. Just nende kolme lahtiharutamine muudab häguse nõude millekski, mille vastu platvormi saab testida.
Eralda kolm tööd
Esimene töö on kliendi marsruut: IPv6 prefiksid, mis kuuluvad ühte VPN-i marsruutimiskonteksti ja peavad jääma igast teisest kontekstist välja. Teine on marsruutimisühendus teenusepakkuja servamarsruuterite vahel, mis neid prefikseid vahetavad. Kolmas on transport, mis kannab märgistatud kliendipaketi läbi põhivõrgu kaugemasse serva. Ainult ühe neist nimetamine ei ole veel projekt.
| 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 |
Igal tööl on oma aadressiperekond, oma rikkerežiimid ja sageli oma meeskond. Tabel on kasulik just seetõttu, et üks lause projekteerimisdokumendis kipub kõik kolm rida üheks kokku suruma.
Marsruudi perekond on VPN-IPv6, mitte IPv6 unicast
RFC 4659 määratleb BGP/MPLS IPv6 VPN-i perekonna ja liikmelisus selles on täpsem, kui sõna IPv6 vihjab. Marsruut seal on marsruudi eristaja, mis on ühendatud IPv6 prefiksiga ja kodeeritud AFI 2 ning SAFI 128 all. Tavaline IPv6 unicast on teine perekond, seega looking glassis prefiksina näiv teadaanne ei pruugi üldse olla sama objekt. Perekonna vale lugemine on esimene viis, kuidas see projekt untsu läheb.
Erinevus lööb välja servas, kus marsruut peab enne millegi tegemist jõudma õigesse VPN-i konteksti. Prefiksi vastuvõtmine tõestab, et vahetus toimus, ja ei ütle paigaldamise kohta midagi. See lünk tekitab klassikalise aruande, kus sessioon on püsti ja klient on ikka pimedas.
Sessioon võib joosta VPN-ist erinevas perekonnas
Miski ei sunni kahe serva vahelist BGP-ühendust kasutama VPN-i enda perekonda. Spetsifikatsioon lubab IPv4 või IPv6 sessiooni ning IPv6 VPN-i transport on ise määratletud mõlema põhivõrgu tüübi peal. Nii ei ütle IPv6 sessioon midagi selle perekonna kohta, mida ta kannab, ja ei vali ka andmetasandit. Kolm sõltumatut bitti ja projekt peaks kandma kõiki kolme eraldi.
See vabastab ja on samal hingetõmbel lihtne valesti lugeda. IPv6 kliendimarsruudid võivad sõita IPv4-aadressiga sessioonil ja IPv4 marsruudid IPv6 sessioonil, kui platvorm seda kombinatsiooni toetab ja järgmine hüpe laheneb. Mis juhtuda ei tohi, on lasta sessioonil lasti vihjata, olgu projekteerimisdokumendis või monitooringus, mis teenust hiljem tõestab.
Järgmisel hüppel IPv4 põhivõrgus on oma kodeering
Kui VPN-i all olev põhivõrk on IPv4, ei ilmu marsruut järgmise hüppega, mida sissesõidu serv saaks otse kasutada. See saabub IPv4-sse kaardistatud IPv6 kujul ja nii väljendab spetsifikatsioon väljasõidu serva, kui transport selle all on IPv4. Sissesõidu marsruuter peab selle kaardistatud aadressi siis muutma millekski, mida ta tegelikult läbi põhivõrgu kätte saab, ja lahendamine on samm, mis vaikselt ebaõnnestub.
Lugege seda edastussõltuvusena, mitte stringina, mida seadmete vahel kopeerida. Kinnitage kolme asja platvormil, mida te tegelikult jooksutate: teadaannetatud järgmine hüpe laheneb kasutatavaks teeks, siltide virn võetakse vastu ja sihtkoht maandub kavandatud VPN-i konteksti. Ükskõik millise neist ebaõnnestumine jätab sessiooni, mis näeb terve välja ja ei edasta midagi, seepärast kuulub kontroll vastuvõtujooksu, mitte hilisemasse intsidenti.
Kirjutage nõue nelja reaga
Testimist väärt nõue nimetab nelja asja: VPN-i perekond, sessiooni transport, järgmise hüppe kodeering ja põhivõrgu korraldus. Seejärel nimetab ühe kliendi prefiksi, mida otsast otsani jälgida: läbi vahetuse, paigaldamise, siltide lahendamise ja tagasitee. „Toetab IPv6 BGP-d“ ei kata ühtegi neist neljast ja varjab, kus lahknevus tegelikult asub.
Terve sessioon ilma VPN-IPv6 vahetuseta on puudulik ja vastuvõetud VPN-i marsruut ilma toimiva edastuseta on sama puudulik. Nende hoidmine eraldi vastuvõtureadadena teeb järgmise tõrkeotsingu vestluse lühikeseks, sest ebaõnnestuv rida on juba kirja pandud.