IPv6 sa isang MPLS VPN: tatlong pagpipilian, hindi isang pamilya ng address
Ang mga ruta ng VPN ng customer, ang sesyon ng BGP sa pagitan ng PE at ang transport sa core ay magkakaibang desisyon. Maaaring tumakbo ang isang sesyon sa isang pamilya at magdala ng iba.
Sabihin sa isang pagsusuri ng disenyo ang “magpatakbo ng IPv6 L3VPN sa ibabaw ng IPv6 BGP”, at sa isang pangungusap na iyon ay may tatlong magkakaibang desisyong nakatago. Aling mga prefix ang pag-aari ng VPN ng customer, aling mga address ang nagdadala ng sesyon ng routing sa pagitan ng mga gilid ng provider, at aling core ang naglilipat ng may-label na pakete ay magkahiwalay na pagpipilian. Maaaring lahat ito ay IPv6, maaaring haluin, at ang paghahalo ay sinasadyang pinapayagan. Ang paghihiwalay ng tatlong ito ang gumagawa sa malabong pangangailangan na maging isang bagay na masusubok sa isang plataporma.
Paghiwalayin ang tatlong gawain
Ang unang gawain ay ang ruta ng customer: mga prefix ng IPv6 na kabilang sa isang konteksto ng routing ng VPN at dapat manatili sa labas ng bawat iba pang konteksto. Ang pangalawa ay ang koneksyon ng routing sa pagitan ng mga router sa gilid ng provider na nagpapalitan ng mga prefix na iyon. Ang pangatlo ay ang transport na nagdadala ng may-label na pakete ng customer sa core hanggang sa malayong gilid. Ang pagbanggit lamang ng isa sa kanila ay hindi pa disenyo.
| 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 |
Bawat gawain ay may sariling pamilya ng address, sariling paraan ng pagpalya at kadalasan ay sariling koponan. Kapaki-pakinabang ang talahanayan dahil ang isang pangungusap sa dokumento ng disenyo ay may ugaling pipiin ang tatlong hilera sa isa.
Ang pamilya ng ruta ay VPN-IPv6, hindi IPv6 unicast
RFC 4659 ang naglalarawan ng pamilya ng BGP/MPLS IPv6 VPN, at ang pagiging kasapi nito ay mas tiyak kaysa ipinahihiwatig ng salitang IPv6. Ang ruta doon ay isang tagapaghiwalay ng ruta na nakaugnay sa isang prefix ng IPv6, na naka-encode sa ilalim ng AFI 2 at SAFI 128. Ang ordinaryong IPv6 unicast ay ibang pamilya, kaya ang isang anunsyo na mukhang prefix sa isang looking glass ay maaaring hindi talaga ang parehong bagay. Ang maling pagbasa ng pamilya ang unang paraan ng pagkapalya ng disenyong ito.
Ang pagkakaiba ay kumakagat sa gilid, kung saan ang isang ruta ay dapat munang lumapag sa tamang konteksto ng VPN bago ito gumawa ng anuman. Ang pagtanggap ng prefix ay nagpapatunay na nangyari ang pagpapalitan at wala itong sinasabi tungkol sa pag-install. Ang puwang na iyon ang gumagawa ng klasikong ulat kung saan nakabangon ang sesyon ngunit madilim pa rin ang customer.
Maaaring tumakbo ang sesyon sa ibang pamilya kaysa sa VPN
Walang pumipilit sa koneksyon ng BGP sa pagitan ng dalawang gilid na gamitin ang sariling pamilya ng VPN. Pinapayagan ng espesipikasyon ang sesyon na IPv4 o IPv6, at ang transport ng IPv6 VPN mismo ay tinukoy sa ibabaw ng dalawang uri ng core. Kaya ang sesyon na IPv6 ay walang sinasabi tungkol sa pamilya ng dinadala nito, at hindi rin ito pumipili ng data plane. Tatlong malayang bit, at dapat dalhin ng disenyo ang tatlo nang hiwalay.
Nakapagpapalaya iyon at kasabay nito ay madaling mabasa nang mali. Ang mga rutang customer na IPv6 ay maaaring sumakay sa sesyon na may address na IPv4, at ang mga rutang IPv4 sa sesyon na IPv6, basta sinusuportahan ng plataporma ang kombinasyon at nareresolba ang susunod na hop. Ang hindi dapat mangyari ay hayaang ipahiwatig ng sesyon ang payload, sa dokumento ng disenyo o sa monitoring na magpapatunay ng serbisyo mamaya.
Ang susunod na hop sa isang core na IPv4 ay may sariling encoding
Kapag ang core sa ilalim ng VPN ay IPv4, hindi lumilitaw ang ruta na may susunod na hop na magagamit nang direkta ng papasok na gilid. Dumarating ito sa anyong IPv6 na naka-map sa IPv4, at ganoon ang pagpapahayag ng espesipikasyon sa palabas na gilid kapag ang transport sa ilalim ay IPv4. Kailangan ng papasok na router na gawing isang bagay na talagang maabot nito sa core ang naka-map na address na iyon, at ang resolusyon ang hakbang na tahimik na pumapalya.
Basahin ito bilang dependency ng forwarding at hindi bilang string na kokopyahin sa pagitan ng mga aparato. Tiyakin ang tatlong bagay sa platapormang talagang pinapatakbo mo: nareresolba ang inanunsyong susunod na hop sa magagamit na landas, tinatanggap ang stack ng label, at lumalapag ang destinasyon sa intended na konteksto ng VPN. Kung may isang pumalya, may natitirang sesyon na mukhang malusog at walang ipinapasa, kaya kabilang ang pagsusuring ito sa acceptance run at hindi sa susunod na insidente.
Isulat ang pangangailangan sa apat na linya
Ang pangangailangang karapat-dapat subukan ay nagbabanggit ng apat na bagay: ang pamilya ng VPN, ang transport ng sesyon, ang encoding ng susunod na hop at ang kaayusan ng core. Pagkatapos ay nagbabanggit ito ng isang prefix ng customer na susubaybayan mula simula hanggang wakas: sa pagpapalitan, pag-install, resolusyon ng label at landas ng pagbabalik. Ang “Sinusuportahan ang IPv6 BGP” ay hindi sumasakop sa alinman sa apat at itinatago kung saan talaga naroroon ang hindi pagkakatugma.
Ang malusog na sesyon na walang pagpapalitan ng VPN-IPv6 ay hindi kumpleto, at ang rutang VPN na natanggap na walang gumaganang forwarding ay gayon din. Ang pag-iingat sa mga ito bilang magkahiwalay na linya ng acceptance ay nagpapaikli sa susunod na usapan sa pag-troubleshoot, dahil nakasulat na ang linyang pumapalya.