IPv6 in 'n MPLS-VPN: drie keuses, nie een adresfamilie nie
Klantroetes in die VPN, die PE-tot-PE-BGP-sessie en die kerntransport is afsonderlike besluite. 'n Sessie kan een familie gebruik terwyl dit 'n ander dra.
Sê jy “hardloop 'n IPv6-L3VPN oor IPv6-BGP” in 'n ontwerphersiening, dan skuil daar drie afsonderlike besluite in daardie een sin. Watter prefikse aan die klant se VPN behoort, watter adresse die roeteringsessie tussen die verskafferrande dra, en watter kern die gemerkte pakkie vervoer, is onafhanklike keuses. Hulle kan almal IPv6 wees, hulle kan gemeng wees, en gemengdheid word doelbewus toegelaat. Om die drie uitmekaar te haal, is wat 'n vae vereiste omskep in iets waarteen 'n platform getoets kan word.
Skei die drie take
Die eerste taak is die klantroete: IPv6-prefikse wat aan een VPN-roeteringskonteks behoort en uit elke ander konteks gehou moet word. Die tweede is die roeteringsverbinding tussen die verskafferrande se roeteerders wat daardie prefikse uitruil. Die derde is die transport wat die gemerkte klantpakkie oor die kern na die verre rand dra. Om net een van hulle te noem, is nog nie 'n ontwerp nie.
| 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 het sy eie adresfamilie, sy eie foutmodusse en dikwels sy eie span. Die tabel is juis nuttig omdat 'n enkele sin in 'n ontwerpdokument geneig is om al drie rye in een saam te val.
Die roetefamilie is VPN-IPv6, nie IPv6-unicast nie
RFC 4659 definieer die BGP/MPLS IPv6-VPN-familie, en lidmaatskap daarvan is spesifiker as wat die woord IPv6 laat vermoed. 'n Roete daarin is 'n roete-onderskeier wat aan 'n IPv6-prefiks gekoppel is en onder AFI 2 en SAFI 128 geënkodeer word. Gewone IPv6-unicast is 'n ander familie, so 'n advertensie wat in 'n looking glass soos 'n prefiks lyk, is moontlik glad nie dieselfde objek nie. Om die familie verkeerd te lees, is die eerste manier waarop hierdie ontwerp skeefloop.
Die verskil byt by die rand, waar 'n roete eers binne die regte VPN-konteks moet beland voordat dit enigiets doen. Om 'n prefiks te ontvang, bewys dat die uitruil plaasgevind het en sê niks oor installasie. Daardie gaping lewer die klassieke verslag op waarin die sessie op is en die klant steeds donker is.
Die sessie kan 'n ander familie as die VPN gebruik
Niks dwing die BGP-verbinding tussen twee rande om die VPN se eie familie te gebruik nie. Die spesifikasie laat 'n IPv4- of 'n IPv6-sessie toe, en IPv6-VPN-transport word self oor beide kerntipes gedefinieer. 'n IPv6-sessie sê dus niks oor die familie van wat dit dra nie, en dit kies ook nie die datavlak nie. Drie onafhanklike bisse, en die ontwerp behoort al drie afsonderlik te dra.
Dit is bevrydend en tegelyk maklik om verkeerd te lees. IPv6-klantroetes kan op 'n IPv4-geadresseerde sessie ry, en IPv4-roetes kan op 'n IPv6-een ry, mits die platform die kombinasie ondersteun en die volgende hop oplos. Wat nie mag gebeur nie, is om die sessie die vrag te laat impliseer, in die ontwerpdokument of in die monitering wat die diens later bewys.
Volgende hop op 'n IPv4-kern het sy eie enkodering
Wanneer die kern onder die VPN IPv4 is, verskyn die roete nie met 'n volgende hop wat die inkomende rand direk kan gebruik nie. Dit kom in IPv4-gekaarteerde IPv6-vorm aan, en dit is hoe die spesifikasie die uitgaande rand uitdruk wanneer die transport daaronder IPv4 is. Die inkomende roeteerder moet dan daardie gekaarteerde adres omskep in iets wat dit werklik oor die kern kan bereik, en resolusie is die stap wat stil misluk.
Lees dit as 'n aansturingsafhanklikheid eerder as 'n string om tussen toestelle te kopieer. Bevestig drie dinge op die platform wat jy werklik bestuur: die geadverteerde volgende hop los op na 'n bruikbare pad, die etiketstapel word aanvaar, en die bestemming beland in die beoogde VPN-konteks. Enige een wat faal, laat 'n sessie wat gesond lyk en niks aanstuur nie, en daarom hoort die kontrole in die aanvaardingsloop eerder as in 'n latere voorval.
Skryf die vereiste in vier reëls
Die vereiste wat die moeite werd is om te toets, noem vier dinge: die VPN-familie, die sessietransport, die volgende-hop-enkodering en die kernreëling. Dit noem dan een klantprefiks om van begin tot end te volg, deur uitruil, installasie, etiketresolusie en terugpad. “Ondersteun IPv6 BGP” dek nie een van die vier nie en verberg waar die wanverhouding werklik sit.
'n Gesonde sessie sonder die VPN-IPv6-uitruil is onvolledig, en 'n ontvangde VPN-roete sonder werkende aansturing is ewe onvolledig. Om dit as afsonderlike aanvaardingslyne te hou, maak die volgende probleemoplossingsgesprek kort, want die falende lyn is reeds neergeskryf.