IPv6 yn in MPLS-VPN: trije karren, net ien adresfamylje
De VPN-rûtes fan de klant, de BGP-sesje tusken de PE's en it ferfier yn 'e kearn binne aparte besluten. In sesje kin yn ien famylje rinne en in oare drage.
Sis „rin in IPv6 L3VPN oer IPv6 BGP“ yn in ûntwerpreview en trije aparte besluten ferskûlje har yn dy iene sin. Hokker prefiksen by de VPN fan 'e klant hearre, hokker adressen de routing-sesje tusken de rânen fan 'e provider drage en hokker kearn it markearre pakket ferpleatst, binne ûnôfhinklike karren. Se kinne allegear IPv6 wêze, se kinne mingd wêze, en mingje is mei opsetsin tastien. Krekt it losmeitsjen fan dy trije makket in ûndúdlike eask ta eat dêr't in platfoarm tsjin test wurde kin.
Skied de trije taken
De earste taak is de klantrûte: IPv6-prefiksen dy't by ien VPN-routingkontekst hearre en bûten elke oare kontekst bliuwe moatte. De twadde is de routingferbining tusken de rânerûters fan 'e provider dy't dy prefiksen útwikselje. De tredde is it ferfier dat it markearre klantpakket troch de kearn nei de fiere râne bringt. Mar ien fan har neame is noch gjin ûntwerp.
| 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 |
Elke taak hat syn eigen adresfamylje, syn eigen flatermodus en faaks syn eigen team. De tabel is krekt nuttich om't ien sin yn in ûntwerpdokumint de neiging hat alle trije rigen yn ien te drukjen.
De rûtefamylje is VPN-IPv6, net IPv6 unicast
RFC 4659 definiearret de BGP/MPLS IPv6 VPN-famylje, en it lidmaatskip deryn is spesifiker as it wurd IPv6 suggerearret. In rûte dêr is in rûte-ûnderskieder ferbûn oan in IPv6-prefiks, kodearre ûnder AFI 2 en SAFI 128. Gewoane IPv6 unicast is in oare famylje, dus in oankundiging dy't yn in looking glass op in prefiks liket, is miskien hielendal net itselde objekt. De famylje ferkeard lêze is de earste manier wêrop dit ûntwerp misgiet.
It ferskil byt oan 'e râne, dêr't in rûte earst yn 'e goede VPN-kontekst lânje moat foardat er eat docht. In prefiks ûntfange bewiist dat de útwikseling barde en seit neat oer ynstallaasje. Dat gat leveret it klassike rapport op wêryn de sesje oan is en de klant noch altyd tsjuster is.
De sesje kin yn in oare famylje rinne as de VPN
Neat twingt de BGP-ferbining tusken twa rânen om de eigen famylje fan 'e VPN te brûken. De spesifikaasje lit in IPv4- of IPv6-sesje ta, en IPv6 VPN-ferfier is sels oer beide kearntypen definiearre. In IPv6-sesje seit dus neat oer de famylje fan wat er draacht, en hy kiest ek it datflak net. Trije ûnôfhinklike bits, en it ûntwerp soe alle trije apart drage moatte.
Dat befrijt en is tagelyk maklik ferkeard te lêzen. IPv6-klantrûtes kinne op in sesje mei IPv4-adres ride, en IPv4-rûtes op in IPv6-sesje, mits it platfoarm de kombinaasje stipet en de folgjende hop him oplost. Wat net barre mei is dat de sesje de lading ymplisearret, yn it ûntwerpdokumint of yn 'e monitoring dy't de tsjinst letter bewist.
De folgjende hop op in IPv4-kearn hat syn eigen kodearring
As de kearn ûnder de VPN IPv4 is, ferskynt de rûte net mei in folgjende hop dy't de yngongsrâne direkt brûke kin. Hy komt yn IPv4-mapped IPv6-foarm, en sa drukt de spesifikaasje de útgongsrâne út as it ferfier derûnder IPv4 is. De yngongsrûter moat dan dat mapped adres omsette yn eat dat er wier oer de kearn berikke kin, en oplossing is de stap dy't stil misgiet.
Lês it as in trochstjoerôfhinklikens en net as in tekenrige om tusken apparaten te kopiearjen. Befêstigje trije dingen op it platfoarm dat jo wier beheare: de oankundige folgjende hop lost op nei in brûkber paad, de labelstapel wurdt akseptearre en de bestimming lânet yn 'e bedoelde VPN-kontekst. As ien fan dy mist, bliuwt der in sesje oer dy't sûn liket en neat trochstjoert, en dêrom heart de kontrôle yn 'e akseptaasjerin, net yn in letter ynsidint.
Skriuw de eask yn fjouwer rigels
In eask dy't it wurdich is om te testen neamt fjouwer dingen: de VPN-famylje, it ferfier fan 'e sesje, de kodearring fan 'e folgjende hop en de opbou fan 'e kearn. Dêrnei neamt er ien klantprefiks om fan begjin oant ein te folgjen: troch útwikseling, ynstallaasje, labeloplossing en weromwei. „Stipet IPv6 BGP“ dekt net ien fan 'e fjouwer en ferberget wêr't de misferhâlding wier sit.
In sûne sesje sûnder de VPN-IPv6-útwikseling is ûnfolslein, en in ûntfongen VPN-rûte sûnder wurkjend trochstjoeren is like ûnfolslein. Se as aparte akseptaasjerigels hâlde makket it folgjende probleemûndersyk koart, want de rigel dy't mist is al opskreaun.