Tipo de rota OSPF através de uma VPN: nem sempre externa

Um prefixo de cliente atravessa a nuvem do provedor como uma rota BGP VPN e chega ao site remoto com aparência de rota OSPF externa, o que muitos engenheiros esperam e não é o único resultado possível. O que o CE remoto vê depende do domínio OSPF de onde o prefixo veio e do seu tipo de rota original, e ambos viajam com a rota VPN. Assumir que todo prefixo redistribuído se torna tipo 5 leva a mudanças de preferência que não podem funcionar. Compare primeiro o identificador de domínio, não a distância administrativa.

O modelo PE-CE carrega contexto suficiente para que o PE receptor reconstrua um anúncio OSPF em vez de inventá-lo.

O que viaja com a rota

A RFC 4577 define os atributos OSPF que acompanham uma rota VPN: o identificador de domínio, a métrica e o tipo de rota do site de origem. O PE receptor usa-os para decidir como um prefixo elegível deve aparecer perante o seu processo OSPF local. Sem esses atributos, o PE remoto não teria base para nada além de uma redistribuição externa. Por isso uma rota pode chegar como uma LSA interárea embora o BGP a tenha transportado pelo meio.

O tipo de área também importa. Uma área stub ou NSSA restringe quais LSA podem entrar, pelo que a mesma rota VPN pode ser apresentada de forma diferente consoante o local onde está a instância OSPF recetora. A política de exportação configurada também pode substituir a apresentação predefinida, o que é uma decisão deliberada e não um efeito secundário.

Mesmo domínio, apresentação diferente

Uma rota intraárea ou interárea do mesmo domínio chega normalmente ao site remoto como uma rota interárea, uma LSA de tipo 3. Um prefixo de outro domínio, uma origem que nunca falou OSPF ou um anúncio OSPF inicialmente externo seguem as regras externas, e é aí que aparecem o tipo 5 e o seu equivalente NSSA. Ambos os comportamentos estão corretos; a entrada é diferente. Compare identificadores de domínio e atributos anunciados antes de tocar nos valores de preferência.

A distância administrativa escolhe entre fontes num único router. Não reescreve um tipo de LSA nem cria a relação de domínio em falta.

Quando um sham link é a resposta certa

Imagine dois sites na mesma área ligados por uma ligação direta de retaguarda. O OSPF mantém esse caminho intraárea em vez do caminho interárea oferecido pelo provedor, mesmo quando os custos configurados tornariam o caminho do provedor atrativo. Um sham link representa uma relação intraárea através da VPN para que os custos possam participar na decisão. Existe para esse problema específico de seleção de caminho, não para fazer todas as rotas do mesmo domínio parecerem internas.

Um sham link precisa de extremos alcançáveis e de configuração recíproca nos dois PE. Configurá-lo apenas de um lado produz uma relação que nunca se forma, e a tabela de encaminhamento mantém a sua preferência antiga, o que parece indicar que a funcionalidade não fez nada.

Não quebre a proteção contra ciclos

O modelo PE-CE define o bit DN nas rotas que distribui para que um prefixo não possa regressar através de outro CE e ser redistribuído uma segunda vez. É essa proteção que impede um prefixo de entrar em ciclo entre sites que partilham um domínio OSPF. Removê-la ou ignorá-la para fazer uma rota parecer interna pode criar exatamente o ciclo que foi concebida para evitar. Quando um prefixo parecer errado, trate o bit DN como informação e não como obstáculo.

A mesma cautela aplica-se aos filtros de redistribuição e aos mapas de rotas que removem comunidades. Cada um remove contexto de que o lado remoto precisa, e o anúncio resultante pode parecer plausível embora esteja errado. Altere um atributo de cada vez e verifique o que o CE remoto instala realmente.

Depois verifique a partir do site remoto: o tipo de LSA, o router anunciante e o caminho escolhido. Essa evidência responde à pergunta que o ticket colocou.