Ruta ausente en la VRF: ¿local, VPNv4 o tabla de reenvío?

Un cliente dice que falta un prefijo tras un cambio de objetivo de ruta, y la primera captura de pantalla que envía suele ser la tabla equivocada. Tres tablas distintas responden tres preguntas distintas: si el prefijo existe dentro de la VRF, si se anunció e importó como ruta VPNv4, y si se instaló realmente una entrada de reenvío. Leerlas fuera de orden produce conclusiones seguras y equivocadas. Este manual lleva un prefijo local y uno remoto por las tres tablas, en orden, y termina con un plan de reversión para el cambio de RT que lo empezó.

Nombre el prefijo y la tabla a la que pertenece

Anote dos prefijos antes de escribir nada. Uno es local del sitio del cliente, aprendido de una interfaz conectada o de un anuncio CE. El otro es remoto, y se espera que llegue por la red troncal del proveedor. Toman caminos distintos hacia la misma VRF, y un fallo en uno no dice nada del otro.

Mantenga clara la distinción entre los dos identificadores, porque de ella viene la mayor parte de la confusión en estos tickets. El distinguidor de ruta forma parte del NLRI de VPNv4 y existe para hacer únicos en la red troncal prefijos de cliente que de otro modo serían idénticos. El objetivo de ruta es una comunidad extendida que se transporta como atributo, y es con ella con la que casa la política de importación y exportación. No es un segundo nombre del distinguidor y no se transporta en los paquetes del cliente.

Paso 1: demuestre que el prefijo está en la VRF

Empiece por la vista local y luego por los RT que gobiernan la importación. Si el prefijo local falta aquí, nada aguas arriba puede tener la culpa:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Un prefijo que aparece como conectado o estático está aprendido localmente, y su presencia no dice nada sobre si se exportó. Esa es la lectura errónea más habitual en este flujo de trabajo: una tabla de VRF sana solo es evidencia de aprendizaje local. El lado de la exportación es una pregunta aparte, que responden la vista del vecino y el objetivo de exportación asociado.

Revise las listas de RT de la VRF mientras está aquí. Si el objetivo de importación previsto no está en la lista, todo lo que hay aguas abajo es irrelevante. Si está pero difiere de lo que exporta el PE remoto, ha encontrado el fallo sin abrir ni una sola captura de paquetes.

Paso 2: lea la tabla VPNv4 y sus objetivos

La tabla VPNv4 muestra qué intercambió realmente el plano de control. Busque el prefijo remoto bajo el distinguidor correcto y luego mire las comunidades que tiene asociadas:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Una entrada con el objetivo de ruta correcto pero sin instalación local apunta a la política de importación o a la selección de ruta, no a la alcanzabilidad. Una entrada que no aparece nunca en la tabla VPNv4 apunta aguas arriba: puede que el PE de origen no la exportara o que la sesión no transporte la familia de direcciones.

Hay un tercer caso que desconcierta a la gente durante los cambios. Algunas plataformas limitan qué rutas VPN solicitan o retienen, usando información de pertenencia a objetivos de ruta, así que la ausencia de una NLRI remota en una vista filtrada no es prueba de que el anuncio no exista en ningún sitio. Revise la tabla sin filtrar y las rutas anunciadas del vecino antes de concluir que una ruta se retiró globalmente.

Paso 3: confirme que se instaló y etiquetó algo

Una entrada BGP es una decisión, no un camino. Las tablas de reenvío le dicen si los paquetes tienen adónde ir:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Una entrada CEF con una adyacencia resuelta y una etiqueta de salida significa que el tráfico del plano de datos debería funcionar, y cualquier síntoma restante pertenece a la aplicación o al filtrado dentro de la VRF. Una entrada CEF que muestra un siguiente salto sin resolver significa que la ruta de etiquetas está incompleta aunque BGP parezca sana, y ese es justo el caso en el que una captura de la tabla BGP ha engañado a una revisión de cambio.

Compare la etiqueta que impone el PE local con la que el PE remoto espera recibir. Una discrepancia entre las dos vistas es un problema de asignación de etiquetas o de sesión, y no se corregirá editando objetivos de ruta por muchas veces que lo haga.

Revierta el cambio de RT con un alcance declarado

Si el fallo empezó con una edición de objetivo de ruta, deshágala como un solo paso deliberado y diga qué alcance cambia. Quitar un objetivo de importación retira la elegibilidad dentro de esa VRF. No borra el anuncio VPNv4 de la red troncal, y en algunas plataformas la ruta se queda retenida en la tabla. Son resultados distintos y el efecto visible para el usuario depende de cuál de los dos quiera decir.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Una reconfiguración suave de entrada basta cuando la sesión ya almacena los prefijos; un reinicio duro de una sesión orientada al proveedor en horario laboral es una decisión que debe tomar otra persona. En Junos las comprobaciones equivalentes leen directamente la tabla por VRF y la tabla VPN, y la reversión es un retorno en el commit y no un deshacer por comando, así que capture la diferencia de configuración antes de empezar.

Termine con los mismos tres comandos con los que empezó, en el mismo orden, y registre su salida con una marca de tiempo. Un ticket que dice que el RT estaba mal y que ahora está bien no es reutilizable; uno que muestra el prefijo presente en la VRF, presente en VPNv4 e instalado en CEF es evidencia con la que la siguiente persona puede comparar. Si solo cambiaron los dos primeros, no ha terminado el cambio.