IPv6 en una VPN MPLS: tres decisions, no una sola família d'adreces
Les rutes de la VPN del client, la sessió BGP entre els PE i el transport del nucli són decisions separades. Una sessió pot anar en una família i portar-ne una altra.
Digueu «executa una IPv6 L3VPN sobre IPv6 BGP» en una revisió de disseny i dins d'aquesta sola frase s'amaguen tres decisions separades. Quins prefixos pertanyen a la VPN del client, quines adreces porten la sessió d'encaminament entre les vores del proveïdor i quin nucli mou el paquet etiquetat són eleccions independents. Totes poden ser IPv6, poden estar barrejades, i barrejar-les està permès a propòsit. Desfer el nus de les tres és el que converteix un requisit vague en una cosa que es pot provar en una plataforma.
Separeu les tres feines
La primera feina és la ruta del client: prefixos IPv6 que pertanyen a un context d'encaminament de la VPN i que han de quedar fora de qualsevol altre context. La segona és la connexió d'encaminament entre els encaminadors de vora del proveïdor que intercanvien aquests prefixos. La tercera és el transport que porta el paquet etiquetat del client a través del nucli fins a la vora remota. Anomenar-ne només una encara no és un disseny.
| 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 |
Cada feina té la seva família d'adreces, les seves formes de fallar i sovint el seu equip. La taula és útil precisament perquè una sola frase en un document de disseny sol col·lapsar les tres files en una.
La família de la ruta és VPN-IPv6, no IPv6 unicast
RFC 4659 defineix la família BGP/MPLS IPv6 VPN, i la pertinença a ella és més específica del que suggereix la paraula IPv6. Una ruta allà és un distingidor de ruta unit a un prefix IPv6, codificat sota AFI 2 i SAFI 128. L'IPv6 unicast ordinari és una família diferent, així que un anunci que en un looking glass sembla un prefix pot no ser el mateix objecte en absolut. Llegir malament la família és la primera manera com aquest disseny va tort.
La diferència mossega a la vora, on una ruta ha d'aterrar dins del context de VPN correcte abans de fer res. Rebre un prefix demostra que l'intercanvi ha passat i no diu res sobre la instal·lació. Aquest buit produeix l'informe clàssic on la sessió està aixecada i el client continua a les fosques.
La sessió pot anar en una família diferent de la VPN
Res no obliga la connexió BGP entre dues vores a fer servir la família pròpia de la VPN. L'especificació permet una sessió IPv4 o IPv6, i el transport d'IPv6 VPN està definit ell mateix sobre tots dos tipus de nucli. Per tant, una sessió IPv6 no diu res sobre la família del que porta, i tampoc no tria el pla de dades. Tres bits independents, i el disseny ha de portar-los tots tres per separat.
Això allibera i alhora és fàcil de llegir malament. Les rutes de client IPv6 poden anar per una sessió amb adreça IPv4, i les rutes IPv4 per una d'IPv6, sempre que la plataforma admeti la combinació i el següent salt es resolgui. El que no ha de passar és deixar que la sessió impliqui la càrrega útil, ni al document de disseny ni al monitoratge que després demostra el servei.
El següent salt en un nucli IPv4 té la seva pròpia codificació
Quan el nucli sota la VPN és IPv4, la ruta no apareix amb un següent salt que la vora d'entrada pugui fer servir directament. Arriba en forma d'IPv6 mapat a IPv4, i així és com l'especificació expressa la vora de sortida quan el transport de sota és IPv4. L'encaminador d'entrada ha de convertir llavors aquella adreça mapada en una cosa que realment pugui assolir a través del nucli, i la resolució és el pas que falla en silenci.
Llegiu-ho com una dependència de reenviament i no com una cadena per copiar entre dispositius. Confirmeu tres coses a la plataforma que realment executeu: el següent salt anunciat es resol en un camí utilitzable, la pila d'etiquetes s'accepta i la destinació aterra al context de VPN previst. Qualsevol d'aquestes que falli deixa una sessió que sembla sana i no reenvia res, i per això la comprovació pertany a la prova d'acceptació i no a un incident posterior.
Escriviu el requisit en quatre línies
Un requisit que val la pena provar anomena quatre coses: la família de la VPN, el transport de la sessió, la codificació del següent salt i l'arranjament del nucli. Després anomena un prefix de client per seguir-lo de punta a punta: per l'intercanvi, la instal·lació, la resolució d'etiquetes i el camí de tornada. «Admet IPv6 BGP» no cobreix cap de les quatre i amaga on viu realment el desajustament.
Una sessió sana sense l'intercanvi VPN-IPv6 és incompleta, i una ruta VPN rebuda sense reenviament operatiu ho és igualment. Mantenir-ho com a línies d'acceptació separades fa curt el proper debat de diagnosi, perquè la línia que falla ja està escrita.