VPNv4 entre AS: qué exige el contrato de reenvío de etiquetas

Leer una etiqueta VPNv4 en un router de frontera de AS dice poco hasta que sabe qué modelo entre AS implementa la entrega. La etiqueta no es una propiedad de la ruta por sí sola; registra un acuerdo sobre encapsulación y entrega entre dos routers. Identifique el modelo antes de leer la pantalla. Si no, está depurando un contrato que nadie escribió.

Qué modelo implementa la frontera

El arreglo VRF a VRF une VRF coincidentes mediante adjunciones enrutadas. Cada lado ve al otro como vecino de borde de cliente e intercambian rutas IPv4 ordinarias, así que nada en esa frontera necesita MPLS.

Un segundo arreglo intercambia rutas VPNv4 etiquetadas entre los propios routers de frontera. Eso solo funciona con una trayectoria coherente conmutada por etiquetas a través de la interconexión y con una distribución de objetivos de ruta y un modelo de confianza que ambos lados acepten. Si falta cualquiera de las dos piezas, el modelo no está en uso, diga lo que diga la configuración.

El tercero distribuye accesibilidad PE etiquetada mientras las rutas VPN viajan entre extremos o reflectores de ruta a través de AS. Cada uno de los tres deja trabajo distinto en la frontera, y mezclar el plano de control de uno con las suposiciones de interfaz de otro es el fallo clásico. Esa discrepancia suele aparecer como una etiqueta que parece correcta en un lado y desaparece en el otro.

Lea un prefijo de extremo a extremo

Tome un solo prefijo de cliente autorizado y recórralo. Mire qué se anunció, qué llegó, el siguiente salto, la etiqueta y la política de importación que lo admitió. Luego mire cómo resuelve el router el reenvío hacia ese siguiente salto, porque ahí es donde una etiqueta se convierte en paquete. Omita cualquiera de las dos mitades y estará describiendo un plano de control que puede no estar moviendo tráfico. Las dos lecturas solo significan algo juntas.

El número es local. Significa algo en relación con el router que lo asignó y con la ruta que lleva paquetes hasta allí, por eso el mismo valor puede aparecer dos veces y significar dos cosas distintas. Compárelo con lo que dice haber recibido el lado receptor.

La etiqueta es local, y la promesa también

La capacidad se comprueba en ambos extremos de la interconexión, no en uno. Un comando en su interfaz no hace nada a la interfaz del proveedor vecino, y una ruta que BGP aceptó no compromete por sí sola al vecino a reenviar un paquete etiquetado.

El RFC 4364 restringe el emparejamiento VPNv4 etiquetado a arreglos de confianza y advierte contra aceptar etiquetas que nunca se anunciaron a ese par. Es una declaración de seguridad tanto como de protocolo. Mantenga la relación de enrutamiento de la internet pública lejos del intercambio privado de rutas VPN. Si la interconexión es IP simple, no espere que ninguna etiqueta sobreviva. Y donde el enlace está etiquetado, confirme que la etiqueta de transporte externa se conmuta correctamente en cada salto.

Una etiqueta que parece correcta en un lado y desaparece en el otro suele ser esa discrepancia, no un fallo de enrutamiento.

Qué anotar en la aceptación

La aceptación es una prueba de paquetes, no una revisión de tablas. Siga un paquete de cliente hasta la VRF remota y siga su respuesta de vuelta, y luego anote qué modelo implementa la entrega. Añada los responsables de la entrega en ambos lados y si la frontera transporta IP simple o tráfico etiquetado.

Esa nota es lo que permite al siguiente operador leer correctamente la misma pantalla de etiquetas. Sin ella, el modelo se infiere de la configuración, y las suposiciones inferidas son la forma en que se repite el mismo error. La sección del RFC 4364 sobre inter-AS es donde debe decidirse qué modelo se pretendía.