¿Necesita VPNv4 MPLS en el núcleo? No necesariamente

Activar la familia de direcciones VPNv4 entre dos routers solo crea un contexto de distribución de rutas y nada más. No instala una ruta de reenvío ni indica qué encapsulación llevará un paquete de cliente hasta el punto final remoto. Una vez separados esos dos hechos, la pregunta de si esto necesita MPLS en el núcleo se convierte en una cuestión más estrecha y respondible sobre el plano de datos que admite la plataforma.

Qué negocia realmente la familia de direcciones

BGP multiprotocolo transporta la información de alcanzabilidad de la capa de red VPNv4 bajo AFI 1 y SAFI 128, y cada entrada empareja un distinguidor de ruta con un prefijo y una etiqueta. La sesión negocia que ambos interlocutores pueden codificar y decodificar esa información. Lo que no negocia es un plano de datos. Todo lo que sigue a este párrafo se refiere al reenvío, y nada de ello queda resuelto por el establecimiento de la sesión.

Así que una sesión correcta es prueba de capacidad del plano de control, no del reenvío. Un router puede mantener miles de entradas VPNv4 y aun así descartar cada paquete de cliente, y por eso las dos clases de fallo se confunden desde el principio.

Fíjese en la etiqueta del NLRI. Es una etiqueta de servicio, ligada a un prefijo dentro de una VRF, y tiene un papel de reenvío cuando el paquete llega al punto final de salida. Si algún dispositivo de tránsito la lee es una decisión de diseño aparte.

Recepción, importación y reenvío son tres pasos

Recibir una ruta, tener permiso para usarla y poder reenviar con ella los realizan partes distintas del equipo. BGP almacena lo que oye; la política de importación y la coincidencia de objetivo de ruta deciden qué VRF puede considerarla; después el plano de reenvío debe resolver el siguiente salto anunciado en algo que realmente pueda poner en un cable.

Es en ese paso intermedio donde viven los fallos más sorprendentes. Una ruta puede estar presente en la tabla BGP, válida e incluso ser la mejor, mientras la tabla de rutas de la VRF queda vacía porque ningún objetivo de ruta coincidió con la lista de importación. Nada registra un error de protocolo, porque no se produjo ningún error de protocolo.

El último paso es donde se nota el soporte de la plataforma. Un siguiente salto alcanzable en la capa subyacente no se resuelve automáticamente como transporte de servicio VPN, y el equipo puede exigir un tipo de túnel concreto, una operación de etiqueta concreta o ambas cosas. Leer el estado de resolución es más informativo que leer el recuento de rutas.

Un núcleo IP puede transportar una pila que nunca conmuta

La distinción que merece conservarse es entre «el núcleo no ejecuta MPLS» y «no existe ninguna etiqueta en el servicio». Son afirmaciones distintas, y solo la primera habla de dispositivos de tránsito. RFC 4023 define el transporte de MPLS por túneles IP o GRE, y ese es el mecanismo que hace posible la segunda afirmación en un núcleo totalmente IP.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Los routers de tránsito reenvían por el destino IP exterior y no necesitan ni los prefijos de cliente ni la conmutación de etiquetas nativa. En el extremo lejano se retira el túnel exterior y la etiqueta de servicio retoma su trabajo. El núcleo movió una carga opaca, que es exactamente para lo que sirve una red IP.

Lo que este diseño no le da es una garantía universal. No es prueba de que cada router resuelva cada siguiente salto VPNv4 por cualquier interfaz GRE, ni es motivo para borrar una configuración MPLS nativa que funciona. Es un contraejemplo a la afirmación universal, y la pregunta práctica sigue siendo local a la plataforma. Anote esa pregunta como una limitación de la plataforma y no como una regla del protocolo.

Recorra la cadena en el equipo hasta que se rompa

Empiece por la ruta recibida y deténgase en el primer paso que falle, porque los pasos posteriores no se pueden diagnosticar mientras uno anterior está roto. Cuatro comandos cubren buena parte de ello en una implementación típica.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Léalos como una secuencia y no como cuatro comprobaciones independientes. El primero confirma que la familia está activa y que el vecino intercambia rutas; el segundo muestra si el prefijo llegó con un siguiente salto utilizable; el tercero demuestra la elegibilidad para la importación; el cuarto muestra si el plano de reenvío le ligó una etiqueta o un túnel.

Después pruebe el camino de la carga de trabajo en ambas direcciones, con una MTU que sobreviva a la encapsulación. GRE añade bytes de cabecera, y un camino que supera sondas pequeñas puede fallar en paquetes de tamaño completo solo en una dirección, lo que parece un fallo de aplicación y no de transporte.

Dos notas operativas cierran el círculo. GRE es encapsulación, no confidencialidad, así que una red de tránsito no fiable necesita una disposición de seguridad admitida por encima y no una suposición. Y anote qué encapsulación admite realmente la plataforma antes de la revisión de diseño, porque esa única respuesta decide si un núcleo solo IP es una opción válida o un plan que no puede reenviar.