RD frente a RT en una VPN MPLS: unicidad frente a política de importación

Dos sedes de cliente pueden anunciar 10.20.0.0/24 y ambas siguen siendo válidas dentro de una sola red de proveedor. El distinguidor de ruta mantiene esos anuncios separados; el objetivo de ruta decide qué VRF de cliente puede tomar una copia. Aparecen uno junto al otro en la configuración y hacen trabajos completamente distintos. Confundirlos lleva a cambios que parecen razonables y no arreglan nada.

Siga una ruta desde el borde del cliente hasta una VRF remota y la división se vuelve concreta: la identidad se adjunta antes de que la ruta entre en BGP, y la política de distribución se evalúa cuando la ruta llega al borde del proveedor que la recibe.

Una ruta VPN-IPv4 es un RD más un prefijo IPv4

La RFC 4364 define la familia de direcciones VPN-IPv4 como un distinguidor de ruta de ocho bytes seguido de una dirección IPv4 de cuatro bytes. El RD se antepone al prefijo del cliente, de modo que dos prefijos idénticos de sedes distintas se convierten en dos rutas BGP distintas.

Esa construcción es todo el mecanismo de unicidad. El proveedor no necesita que los clientes acuerden un espacio de direcciones sin solapamiento, y una ruta de una sede no puede sustituir en silencio un prefijo idéntico de otra sede.

El propio formato del RD es un valor elegido por el administrador, normalmente un número de sistema autónomo y un número local. Su forma numérica es una convención, no una señal de que los dos campos compartan significado con un objetivo de ruta que casualmente usa los mismos dígitos.

El RD hace distinguibles los prefijos solapados

Considere dos anuncios del mismo prefijo. La sede A lleva el RD 65000:101 y la sede B lleva el RD 65000:202, ambos para 10.20.0.0/24. BGP mantiene ahora dos rutas VPN-IPv4 que pueden compararse, filtrarse y seleccionarse de forma independiente.

El RD no dice qué VRF debe recibir ninguna de las dos rutas, ni identifica a un cliente o a un servicio. Es un campo de identidad de la ruta, no una lista de pertenencia. El RD propio de una VRF no tiene por qué coincidir con el RD de una ruta que importa.

Por eso cambiar un RD para que coincida con el número de otra sede no arregla nada. Si falta una ruta en el otro extremo, hacer coincidir los dígitos crea un problema de identidad distinto en lugar de reparar la decisión de importación.

El RT es un atributo BGP, no una etiqueta del paquete

Una política de exportación adjunta uno o varios objetivos de ruta a la ruta como atributos de comunidad extendida de BGP. El borde del proveedor que recibe compara esos atributos con la política de importación de cada VRF. El RT viaja con la ruta por el plano de control. La comparación ocurre por completo en la política de encaminamiento, antes de que se reenvíe cualquier paquete del cliente.

Los paquetes de datos del cliente no llevan el RT. Una vez instalada una ruta en una VRF, el reenvío usa la tabla de esa VRF y la pila de etiquetas MPLS que asigna la arquitectura. El borde del proveedor no lee un objetivo de ruta de cada paquete del cliente.

Una ruta puede llevar varios RT, y una VRF puede importar varios. La configuración suele parecer un bloque corto:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Lea ese bloque como dos sentencias separadas. La línea de exportación controla qué se adjunta a las rutas que salen de esta VRF; la línea de importación controla qué está dispuesta a considerar esta VRF. Que los números coincidan es cómodo, no obligatorio.

La elegibilidad de importación no es la instalación

Una ruta puede ser elegible para una VRF y aun así no aparecer en su tabla de reenvío. La elegibilidad es un filtro; después el proceso normal de decisión de BGP compara las rutas elegibles y selecciona una. Una ruta más antigua o menos preferida puede perder frente a otra ruta elegible.

Compruebe la ruta seleccionada, no solo la política de importación. Una VRF que importa el RT 65000:500 y no muestra ninguna ruta para 10.20.0.0/24 puede haber recibido la ruta y haberla rechazado en la selección, o puede que nunca la recibiera.

Esta distinción también importa cuando aparece un prefijo inesperado. Una política de importación demasiado amplia puede atraer rutas que la sede no pretendía usar, y la unicidad del RD no lo impide en absoluto. El alcance de distribución es una cuestión de política de RT.

Depure una ruta que falta en el orden del plano de control

Empiece por el anuncio: ¿exporta la VRF de origen el RT previsto y existe la ruta como ruta VPN-IPv4 en el reflector de rutas o en el PE receptor? Después compruebe el atributo tal como se ha recibido, no como está configurado en el emisor.

A continuación compare la lista de importación de la VRF receptora con los valores reales de RT de la ruta. Por último inspeccione la ruta seleccionada en esa VRF y la vinculación de la etiqueta. Cada paso responde a una pregunta distinta, y saltar al RD normalmente omite el que está mal.

Anote el RD, el RT exportado, el RT importado y el siguiente salto seleccionado para la sede que funciona y la que falla. Cuatro valores uno al lado del otro convierten un vago “la VPN no pasa rutas” en el paso exacto del plano de control que difiere.