Tipo de ruta OSPF a través de una VPN: no siempre es externa

Un prefijo de cliente cruza la nube del proveedor como una ruta BGP VPN y llega al sitio remoto con aspecto de ruta OSPF externa, que es lo que muchos ingenieros esperan y no el único resultado posible. Lo que ve el CE remoto depende del dominio OSPF del que procede el prefijo y de su tipo de ruta original, y ambos viajan con la ruta VPN. Suponer que cada prefijo redistribuido se convierte en tipo 5 conduce a cambios de preferencia que no pueden funcionar. Compare primero el identificador de dominio, no la distancia administrativa.

El modelo PE-CE aporta suficiente contexto para que el PE receptor reconstruya un anuncio OSPF en lugar de inventarlo.

Qué viaja con la ruta

La RFC 4577 define los atributos OSPF que acompañan a una ruta VPN: el identificador de dominio, la métrica y el tipo de ruta del sitio de origen. El PE receptor los usa para decidir cómo debe aparecer un prefijo elegible ante su proceso OSPF local. Sin esos atributos, el PE remoto no tendría base para nada salvo una redistribución externa. Por eso una ruta puede llegar como una LSA interárea aunque BGP la haya transportado entre medias.

El tipo de área también importa. Un área stub o NSSA restringe qué LSA pueden entrar, así que la misma ruta VPN puede presentarse de forma distinta según dónde se sitúe la instancia OSPF receptora. La política de exportación configurada también puede anular la presentación predeterminada, lo que es una decisión deliberada y no un efecto secundario.

Mismo dominio, presentación distinta

Una ruta intraárea o interárea del mismo dominio suele llegar al sitio remoto como una ruta interárea, una LSA de tipo 3. Un prefijo de otro dominio, un origen que nunca habló OSPF o un anuncio OSPF inicialmente externo siguen las reglas externas, y ahí aparecen el tipo 5 y su equivalente NSSA. Ambos comportamientos son correctos; la entrada es distinta. Compare identificadores de dominio y atributos anunciados antes de tocar los valores de preferencia.

La distancia administrativa elige entre fuentes en un solo router. No reescribe un tipo de LSA ni crea la relación de dominio que falta.

Cuándo un sham link es la respuesta correcta

Imagine dos sitios en la misma área unidos por un enlace trasero directo. OSPF mantiene esa ruta intraárea en lugar de la interárea que ofrece el proveedor, incluso cuando los costes configurados harían atractiva la ruta del proveedor. Un sham link representa una relación intraárea a través de la VPN para que los costes puedan participar en la decisión. Existe para ese problema concreto de selección de ruta, no para hacer que todas las rutas del mismo dominio parezcan internas.

Un sham link necesita extremos accesibles y configuración recíproca en ambos PE. Configurarlo solo en un lado produce una relación que nunca se forma, y la tabla de enrutamiento conserva su preferencia anterior, lo que parece indicar que la función no hizo nada.

No rompa la protección contra bucles

El modelo PE-CE establece el bit DN en las rutas que distribuye para que un prefijo no pueda volver a través de otro CE y ser redistribuido por segunda vez. Esa protección es lo que impide que un prefijo entre en bucle entre sitios que comparten un dominio OSPF. Eliminarla o ignorarla para que una ruta parezca interna puede crear exactamente el bucle que estaba diseñada para evitar. Cuando un prefijo parezca incorrecto, trate el bit DN como información y no como un obstáculo.

La misma precaución se aplica a los filtros de redistribución y a los mapas de rutas que eliminan comunidades. Cada uno elimina contexto que el lado remoto necesita, y el anuncio resultante puede parecer plausible mientras es incorrecto. Cambie un atributo cada vez y compruebe qué instala realmente el CE remoto.

Después verifique desde el sitio remoto: el tipo de LSA, el router anunciante y la ruta que eligió. Esa evidencia responde a la pregunta que planteaba el ticket.