IPv6 en una VPN MPLS: tres decisiones, no una sola familia de direcciones
Las rutas de la VPN del cliente, la sesión BGP entre los PE y el transporte del núcleo son decisiones separadas. Una sesión puede ir en una familia y llevar otra.
Diga «ejecuta una IPv6 L3VPN sobre IPv6 BGP» en una revisión de diseño y dentro de esa sola frase se esconden tres decisiones separadas. Qué prefijos pertenecen a la VPN del cliente, qué direcciones llevan la sesión de enrutamiento entre los bordes del proveedor y qué núcleo mueve el paquete etiquetado son elecciones independientes. Todas pueden ser IPv6, pueden estar mezcladas, y mezclarlas está permitido a propósito. Desenredar las tres es lo que convierte un requisito vago en algo contra lo que se puede probar una plataforma.
Separe las tres tareas
La primera tarea es la ruta del cliente: prefijos IPv6 que pertenecen a un contexto de enrutamiento de la VPN y deben quedarse fuera de cualquier otro contexto. La segunda es la conexión de enrutamiento entre los routers de borde del proveedor que intercambian esos prefijos. La tercera es el transporte que lleva el paquete etiquetado del cliente por el núcleo hasta el borde remoto. Nombrar solo una de ellas todavía no es un diseño.
| 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 tarea tiene su propia familia de direcciones, sus propias formas de fallar y a menudo su propio equipo. La tabla es útil precisamente porque una sola frase en un documento de diseño tiende a colapsar las tres filas en una.
La familia de la ruta es VPN-IPv6, no IPv6 unicast
RFC 4659 define la familia BGP/MPLS IPv6 VPN, y pertenecer a ella es más específico de lo que sugiere la palabra IPv6. Una ruta allí es un distinguidor de ruta unido a un prefijo IPv6, codificado bajo AFI 2 y SAFI 128. El IPv6 unicast ordinario es otra familia, así que un anuncio que en un looking glass parece un prefijo puede no ser el mismo objeto en absoluto. Leer mal la familia es la primera forma en que este diseño sale mal.
La diferencia muerde en el borde, donde una ruta tiene que aterrizar en el contexto de VPN correcto antes de hacer nada. Recibir un prefijo demuestra que el intercambio ocurrió y no dice nada sobre la instalación. Esa brecha produce el informe clásico en el que la sesión está arriba y el cliente sigue a oscuras.
La sesión puede ir en una familia distinta de la VPN
Nada obliga a la conexión BGP entre dos bordes a usar la familia propia de la VPN. La especificación permite una sesión IPv4 o IPv6, y el transporte de IPv6 VPN está definido él mismo sobre ambos tipos de núcleo. Por tanto, una sesión IPv6 no dice nada sobre la familia de lo que lleva, y tampoco elige el plano de datos. Tres bits independientes, y el diseño debería llevar los tres por separado.
Eso libera y al mismo tiempo se lee mal con facilidad. Las rutas de cliente IPv6 pueden ir sobre una sesión con dirección IPv4, y las rutas IPv4 sobre una IPv6, siempre que la plataforma admita la combinación y el siguiente salto se resuelva. Lo que no debe pasar es dejar que la sesión implique la carga útil, ni en el documento de diseño ni en la monitorización que luego demuestra el servicio.
El siguiente salto en un núcleo IPv4 tiene su propia codificación
Cuando el núcleo bajo la VPN es IPv4, la ruta no aparece con un siguiente salto que el borde de entrada pueda usar directamente. Llega en forma de IPv6 mapeada a IPv4, y así es como la especificación expresa el borde de salida cuando el transporte por debajo es IPv4. El router de entrada tiene entonces que convertir esa dirección mapeada en algo que realmente pueda alcanzar por el núcleo, y la resolución es el paso que falla en silencio.
Léalo como una dependencia de reenvío y no como una cadena que se copia entre equipos. Confirme tres cosas en la plataforma que realmente opera: el siguiente salto anunciado se resuelve en una ruta utilizable, la pila de etiquetas se acepta y el destino aterriza en el contexto de VPN previsto. Cualquiera de ellas que falle deja una sesión que parece sana y no reenvía nada, y por eso la comprobación pertenece a la prueba de aceptación y no a un incidente posterior.
Escriba el requisito en cuatro líneas
Un requisito que merece probarse nombra cuatro cosas: la familia de la VPN, el transporte de la sesión, la codificación del siguiente salto y la disposición del núcleo. Después nombra un prefijo de cliente que seguir de extremo a extremo: por el intercambio, la instalación, la resolución de etiquetas y el camino de vuelta. «Admite IPv6 BGP» no cubre ninguna de las cuatro y esconde dónde vive realmente el desajuste.
Una sesión sana sin el intercambio VPN-IPv6 está incompleta, y una ruta VPN recibida sin reenvío funcionando lo está igualmente. Mantener esas como líneas de aceptación separadas hace corta la siguiente conversación de diagnóstico, porque la línea que falla ya está escrita.