Tipo de ruta OSPF a través dunha VPN: non sempre é externa

Un prefixo de cliente cruza a nube do provedor como unha ruta BGP VPN e chega ao sitio remoto con aspecto de ruta OSPF externa, que é o que moitos enxeñeiros esperan e non o único resultado posible. O que ve o CE remoto depende do dominio OSPF do que procede o prefixo e do seu tipo de ruta orixinal, e ambos viaxan coa ruta VPN. Supoñer que cada prefixo redistribuído se converte en tipo 5 leva a cambios de preferencia que non poden funcionar. Compare primeiro o identificador de dominio, non a distancia administrativa.

O modelo PE-CE leva suficiente contexto para que o PE receptor reconstruía un anuncio OSPF en lugar de inventalo.

Que viaxa coa ruta

A RFC 4577 define os atributos OSPF que acompañan unha ruta VPN: o identificador de dominio, a métrica e o tipo de ruta do sitio de orixe. O PE receptor úsaos para decidir como debe aparecer un prefixo elixible ante o seu proceso OSPF local. Sen eses atributos, o PE remoto non tería base para nada agás unha redistribución externa. Por iso unha ruta pode chegar como unha LSA interárea aínda que BGP a transportase entre medias.

O tipo de área tamén importa. Unha área stub ou NSSA restrinxe que LSA poden entrar, así que a mesma ruta VPN pode presentarse de forma distinta segundo onde se atope a instancia OSPF receptora. A política de exportación configurada tamén pode anular a presentación predeterminada, o que é unha decisión deliberada e non un efecto secundario.

Mesmo dominio, presentación distinta

Unha ruta intraárea ou interárea do mesmo dominio adoita chegar ao sitio remoto como unha ruta interárea, unha LSA de tipo 3. Un prefixo doutro dominio, unha orixe que nunca falou OSPF ou un anuncio OSPF inicialmente externo seguen as regras externas, e aí aparecen o tipo 5 e o seu equivalente NSSA. Ambos os comportamentos son correctos; a entrada é distinta. Compare identificadores de dominio e atributos anunciados antes de tocar os valores de preferencia.

A distancia administrativa escolle entre fontes nun só router. Non reescribe un tipo de LSA nin crea a relación de dominio que falta.

Cando un sham link é a resposta correcta

Imaxine dous sitios na mesma área unidos por unha ligazón posterior directa. OSPF mantén esa ruta intraárea en lugar da interárea que ofrece o provedor, mesmo cando os custos configurados farían atractiva a ruta do provedor. Un sham link representa unha relación intraárea a través da VPN para que os custos poidan participar na decisión. Existe para ese problema concreto de selección de ruta, non para facer que todas as rutas do mesmo dominio parezan internas.

Un sham link necesita extremos accesibles e configuración recíproca nos dous PE. Configuralo só nun lado produce unha relación que nunca se forma, e a táboa de encamiñamento conserva a súa preferencia anterior, o que parece indicar que a función non fixo nada.

Non rompa a protección contra bucles

O modelo PE-CE establece o bit DN nas rutas que distribúe para que un prefixo non poida volver a través doutro CE e ser redistribuído por segunda vez. Esa protección é o que impide que un prefixo entre en bucle entre sitios que comparten un dominio OSPF. Eliminala ou ignorala para que unha ruta pareza interna pode crear exactamente o bucle que estaba deseñada para evitar. Cando un prefixo pareza incorrecto, trate o bit DN como información e non como un obstáculo.

A mesma precaución se aplica aos filtros de redistribución e aos mapas de rutas que eliminan comunidades. Cada un elimina contexto que o lado remoto necesita, e o anuncio resultante pode parecer plausible mentres é incorrecto. Cambie un atributo cada vez e comprobe que instala realmente o CE remoto.

Despois verifique desde o sitio remoto: o tipo de LSA, o router anunciante e a ruta que escolleu. Esa evidencia responde á pregunta que expuña o ticket.