IPv6 într-o VPN MPLS: trei decizii, nu o singură familie de adrese
Rutele VPN ale clientului, sesiunea BGP dintre PE și transportul din nucleu sunt decizii separate. O sesiune poate rula într-o familie și transporta alta.
Spuneți „rulează un L3VPN IPv6 peste BGP IPv6” într-o revizuire de design, și în acea singură frază se ascund trei decizii separate. Ce prefixe aparțin VPN-ului clientului, ce adrese poartă sesiunea de rutare între marginile furnizorului și ce nucleu mută pachetul etichetat sunt alegeri independente. Toate pot fi IPv6, pot fi amestecate, iar amestecarea este permisă intenționat. Tocmai descurcarea celor trei transformă o cerință vagă în ceva împotriva căruia o platformă poate fi testată.
Separați cele trei sarcini
Prima sarcină este ruta clientului: prefixe IPv6 care aparțin unui singur context de rutare al VPN-ului și trebuie să rămână în afara oricărui alt context. A doua este conexiunea de rutare între routerele de margine ale furnizorului care schimbă acele prefixe. A treia este transportul care duce pachetul etichetat al clientului prin nucleu până la marginea îndepărtată. A numi doar una dintre ele nu este încă un 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 |
Fiecare sarcină are propria familie de adrese, propriile moduri de eșec și adesea propria echipă. Tabelul este util exact pentru că o singură frază dintr-un document de design tinde să strivească toate cele trei rânduri într-unul.
Familia rutei este VPN-IPv6, nu IPv6 unicast
RFC 4659 definește familia BGP/MPLS IPv6 VPN, iar apartenența la ea este mai specifică decât sugerează cuvântul IPv6. O rută acolo este un distingător de rută unit cu un prefix IPv6, codificat sub AFI 2 și SAFI 128. IPv6 unicast obișnuit este altă familie, așa că un anunț care într-un looking glass pare un prefix poate să nu fie deloc același obiect. Citirea greșită a familiei este primul mod în care acest design o ia razna.
Diferența mușcă la margine, unde o rută trebuie să aterizeze în contextul VPN corect înainte de a face orice. Primirea unui prefix dovedește că schimbul a avut loc și nu spune nimic despre instalare. Acea lipsă produce raportul clasic în care sesiunea este sus și clientul este încă în întuneric.
Sesiunea poate rula într-o familie diferită de cea a VPN-ului
Nimic nu obligă conexiunea BGP dintre două margini să folosească familia proprie a VPN-ului. Specificația permite o sesiune IPv4 sau IPv6, iar transportul IPv6 VPN este el însuși definit peste ambele tipuri de nucleu. Așadar o sesiune IPv6 nu spune nimic despre familia a ceea ce transportă și nu alege nici planul de date. Trei biți independenți, iar designul ar trebui să le poarte pe toate trei separat.
Asta eliberează și, în aceeași răsuflare, se citește ușor greșit. Rutele de client IPv6 pot merge pe o sesiune cu adresă IPv4, iar rutele IPv4 pe una IPv6, cu condiția ca platforma să sprijine combinația și următorul salt să se rezolve. Ce nu trebuie să se întâmple este ca sesiunea să implice încărcătura, în documentul de design sau în monitorizarea care dovedește serviciul mai târziu.
Următorul salt pe un nucleu IPv4 are propria codificare
Când nucleul de sub VPN este IPv4, ruta nu apare cu un următor salt pe care marginea de intrare să îl poată folosi direct. Ea sosește în formă IPv6 mapată în IPv4, și așa exprimă specificația marginea de ieșire când transportul de dedesubt este IPv4. Routerul de intrare trebuie atunci să transforme acea adresă mapată în ceva ce poate atinge într-adevăr prin nucleu, iar rezolvarea este pasul care eșuează în tăcere.
Citiți-o ca pe o dependență de forwarding și nu ca pe un șir de copiat între echipamente. Confirmați trei lucruri pe platforma pe care chiar o operați: următorul salt anunțat se rezolvă într-o cale utilizabilă, stiva de etichete este acceptată și destinația aterizează în contextul VPN dorit. Dacă oricare dintre ele eșuează, rămâne o sesiune care pare sănătoasă și nu forwardează nimic, de aceea verificarea aparține rulării de acceptare și nu unui incident ulterior.
Scrieți cerința în patru rânduri
O cerință care merită testată numește patru lucruri: familia VPN-ului, transportul sesiunii, codificarea următorului salt și aranjamentul nucleului. Apoi numește un prefix de client de urmărit de la un capăt la altul: prin schimb, instalare, rezolvarea etichetelor și calea de întoarcere. „Suportă BGP IPv6” nu acoperă niciuna dintre cele patru și ascunde unde se află de fapt nepotrivirea.
O sesiune sănătoasă fără schimbul VPN-IPv6 este incompletă, iar o rută VPN primită fără forwarding funcțional este la fel de incompletă. Păstrarea lor ca linii de acceptare separate scurtează următoarea conversație de depanare, pentru că linia care eșuează este deja scrisă.