De una ruta RIP del CE a una VRF remota: dónde ocurre la exportación

Una actualización RIPv2 llega al borde del proveedor, cae en una tabla de enrutamiento VRF y se detiene ahí salvo que algo la exporte explícitamente. Tres decisiones ocurren en secuencia, y cada una puede rechazar el prefijo por su propio motivo. Leerlas como un solo evento es la razón por la que la gente busca la caja equivocada cuando un sitio remoto no alcanza una red que el CE anuncia claramente. Siga la ruta a través del PE y la secuencia se vuelve obvia.

Qué hace el PE con una actualización RIP

El PE recibe la actualización en la interfaz VRF, comprueba que el origen sea un vecino permitido e instala el prefijo en la tabla de enrutamiento VRF con un conteo de saltos derivado del anuncio. Esa tabla es una tabla de enrutamiento normal, con sus propias distancias administrativas y su propia elección de mejor ruta. Si el CE anuncia el mismo prefijo dos veces con métricas distintas, solo el mejor sobrevive en la tabla. Nada en este paso involucra la red troncal del proveedor.

El prefijo existe ahora dentro del contexto de enrutamiento de un solo cliente, lo que está muy lejos de ser alcanzable en cualquier otro lugar.

La exportación es un acto de política, no una consecuencia del protocolo

Para salir de la VRF, una ruta debe redistribuirse al proceso MP-BGP que transporta rutas VPN, y necesita una comunidad extendida de tipo route target que identifique qué VRF remotas pueden importarla. La arquitectura de RFC 4364 mantiene esos intercambios separados del protocolo CE-a-PE exactamente por este motivo. Usar RIP en el borde no dice nada sobre qué debe cruzar la red del proveedor.

Escriba el contrato de exportación antes de configurar cualquier cosa: los prefijos del cliente que deben ser alcanzables en remoto, las rutas que deben quedarse locales y cualquier ruta por defecto, más específica o excepción de servicio compartido. Contraste ese contrato con la VRF real y no con una de nombre parecido que pertenezca a otro cliente.

El lado de importación es una segunda política con sus propios route targets, y una exportación coincidente con una importación no coincidente produce un prefijo que existe en la troncal y no aparece en ninguna tabla remota.

La redistribución y el origen explícito se comportan de forma distinta

La redistribución toma rutas que ya existen en la tabla VRF y las copia a BGP, filtradas por un mapa de rutas. El mapa decide qué prefijos son elegibles y qué atributos llevan, y la métrica debe establecerse explícitamente porque un conteo de saltos RIP no tiene significado como métrica BGP. Todo lo que deje sin establecer se hereda de una forma que suele sorprender a quien lee la configuración seis meses después.

La redistribución mutua es donde ocurre el daño silencioso. Un prefijo exportado a BGP puede volver por un segundo punto de redistribución, y sin etiquetas ni filtros la ruta oscila mientras ambas tablas parecen plausibles en cualquier instante. Filtre por etiquetas aplicadas en el borde en lugar de confiar en que la topología impida el camino de vuelta.

El origen explícito parece más ordenado y no es incondicional. Una declaración de red normalmente necesita una ruta coincidente en la tabla de enrutamiento antes de que el prefijo se origine, así que el anuncio desaparece en el momento en que el CE deja de anunciarlo. A menudo ese es el comportamiento que desea, y no es lo mismo que una ruta estática que permanece configurada para siempre. Compruebe la regla real de la plataforma en lugar de suponer cualquiera de los dos comportamientos.

En cualquier caso, la pregunta sobre cada prefijo es qué origen activo lo hace elegible y qué ocurre cuando ese origen desaparece.

Verifique la cadena en cuatro puntos

Mire el anuncio del CE, la tabla de enrutamiento VRF, la tabla de rutas VPN con su route target y la importación de la VRF remota, en ese orden. En IOS eso significa la salida del vecino CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, y el mismo comando en el PE remoto. En IOS-XR la salida equivalente se encuentra bajo show bgp vrf CUSTOMER ipv4 unicast. Los nombres de los comandos difieren, los cuatro puntos de control no.

Compruebe un prefijo que debería ser rechazado con tanto cuidado como uno que debería pasar, porque una política que lo permite todo es idéntica a una correcta hasta que llega la primera excepción. Luego observe una retirada: apague la interfaz del CE y confirme que la entrada remota desaparece dentro del temporizador esperado en lugar de quedarse.

Registre quién es dueño de cada política. Cuando el proveedor opera el CE, el comportamiento entregado pertenece al contrato de servicio, y un protocolo o una política de retirada distintos en el dispositivo gestionado son un problema de documentación antes que un problema de enrutamiento.