IPv6 në një VPN MPLS: tri zgjedhje, jo një familje e vetme adresash
Rrugët e VPN-së së klientit, sesioni BGP mes PE-ve dhe transporti në bërthamë janë vendime të veçanta. Një sesion mund të punojë në një familje dhe të mbajë një tjetër.
Thuaj në një rishikim dizajni „ekzekuto një L3VPN IPv6 mbi BGP IPv6“, dhe në atë fjali të vetme fshihen tre vendime të veçanta. Cilat prefikse i përkasin VPN-së së klientit, cilat adresa mbajnë sesionin e rrugëzimit mes skajeve të ofruesit dhe cila bërthamë lëviz paketën e etiketuar janë zgjedhje të pavarura. Të gjitha mund të jenë IPv6, mund të jenë të përziera, dhe përzierja lejohet me qëllim. Është pikërisht zbërthimi i këtyre treve që e kthen një kërkesë të vagullt në diçka kundër së cilës një platformë mund të testohet.
Ndaji tre punët
Puna e parë është rruga e klientit: prefikse IPv6 që i përkasin një konteksti të vetëm të rrugëzimit të VPN-së dhe duhet të mbeten jashtë çdo konteksti tjetër. E dyta është lidhja e rrugëzimit mes ruterave të skajit të ofruesit që shkëmbejnë këto prefikse. E treta është transporti që çon paketën e etiketuar të klientit përmes bërthamës deri në skajin e largët. Të përmendësh vetëm njërën prej tyre nuk është ende dizajn.
| 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 |
Çdo punë ka familjen e vet të adresave, mënyrat e veta të dështimit dhe shpesh ekipin e vet. Tabela është e dobishme pikërisht sepse një fjali në një dokument dizajni ka prirje t'i shtypë të tre rreshtat në një.
Familja e rrugës është VPN-IPv6, jo IPv6 unicast
RFC 4659 përcakton familjen BGP/MPLS IPv6 VPN, dhe anëtarësimi në të është më specifik nga sa sugjeron fjala IPv6. Një rrugë atje është një dallues rruge i lidhur me një prefiks IPv6, i koduar nën AFI 2 dhe SAFI 128. IPv6 unicast i zakonshëm është familje tjetër, prandaj një reklamim që në një looking glass duket si prefiks mund të mos jetë fare i njëjti objekt. Leximi i gabuar i familjes është mënyra e parë se si ky dizajn shkon keq.
Diferenca kafshon në skaj, ku rruga duhet të ulet në kontekstin e duhur të VPN përpara se të bëjë çdo gjë. Marrja e një prefiksi provon se shkëmbimi ndodhi dhe nuk thotë asgjë për instalimin. Ai boshllëk prodhon raportin klasik ku sesioni është lart dhe klienti është ende në errësirë.
Sesioni mund të punojë në një familje tjetër nga VPN-ja
Asgjë nuk e detyron lidhjen BGP mes dy skajeve të përdorë familjen e vetë VPN-së. Specifikimi lejon një sesion IPv4 ose IPv6, dhe transporti IPv6 VPN është vetë i përcaktuar mbi të dy tipet e bërthamës. Prandaj një sesion IPv6 nuk thotë asgjë për familjen e asaj që mbart, dhe as nuk zgjedh rrafshin e të dhënave. Tre bit të pavarur, dhe dizajni duhet t'i mbajë të tre veçmas.
Kjo çliron dhe në të njëjtën frymë lexohet lehtë gabimisht. Rrugët e klientit IPv6 mund të udhëtojnë mbi një sesion me adresë IPv4, dhe rrugët IPv4 mbi një sesion IPv6, me kusht që platforma ta mbështesë kombinimin dhe hopi tjetër të zgjidhet. Ajo që nuk duhet të ndodhë është t'i lërë sesionit të nënkuptojë ngarkesën, në dokumentin e dizajnit ose në monitorimin që provon shërbimin më vonë.
Hopi tjetër mbi një bërthamë IPv4 ka kodimin e vet
Kur bërthama nën VPN është IPv4, rruga nuk shfaqet me një hop tjetër që skaji i hyrjes mund ta përdorë drejtpërdrejt. Ajo vjen në formë IPv6 të hartëzuar në IPv4, dhe kështu specifikimi shpreh skajin e daljes kur transporti poshtë është IPv4. Ruteri i hyrjes pastaj duhet ta kthejë atë adresë të hartëzuar në diçka që ai vërtet arrin përmes bërthamës, dhe zgjidhja është hapi që dështon në heshtje.
Lexoje si një varësi përcjelljeje dhe jo si një varg për t'u kopjuar mes pajisjeve. Konfirmo tre gjëra në platformën që vërtet operon: hopi tjetër i shpallur zgjidhet në një rrugë të përdorshme, pirgja e etiketave pranohet dhe destinacioni ulet në kontekstin e synuar të VPN. Nëse ndonjëra prej tyre dështon, mbetet një sesion që duket i shëndetshëm dhe nuk përcjell asgjë, prandaj kontrolli i përket provës së pranimit dhe jo një incidenti të mëvonshëm.
Shkruaje kërkesën në katër rreshta
Një kërkesë që ia vlen të testohet emërton katër gjëra: familjen e VPN-së, transportin e sesionit, kodimin e hopit tjetër dhe rregullimin e bërthamës. Pastaj emërton një prefiks klienti për ta ndjekur nga fillimi në fund: përmes shkëmbimit, instalimit, zgjidhjes së etiketave dhe rrugës së kthimit. „Mbështet BGP IPv6“ nuk mbulon asnjërën nga të katërtat dhe fsheh se ku ndodhet vërtet mospërputhja.
Një sesion i shëndetshëm pa shkëmbimin VPN-IPv6 është i paplotë, dhe një rrugë VPN e marrë pa përcjellje funksionale është po aq e paplotë. T'i mbash si rreshta pranimi të veçantë e shkurton bisedën e ardhshme për zgjidhjen e problemeve, sepse rreshti që dështon është shkruar tashmë.