OSPF ou EIGRP sobre uma VTI do ASA: qual a sua versão suporta
OSPFv2 e EIGRP só passam por uma VTI do ASA a partir da 9.19(1), e apenas com multicast ativado. Compare os dois na versão que você executa e depois verifique os vizinhos.
A maioria das discussões entre OSPF e EIGRP assume que o túnel já consegue transportar o protocolo, e num ASA é justamente essa suposição a parte que vale verificar primeiro. A comparação só fica interessante depois de confirmados a imagem, o tipo de VTI e o caminho de multicast. Erre essa ordem e você passa uma tarde ajustando timers num túnel que nunca vai formar adjacência. Começo cada um desses projetos pelas notas da versão e pela configuração em execução, não pela preferência de protocolo.
A versão decide antes do protocolo
O guia de VTI da Cisco para o ASA 9.24 é uma base documental utilizável: descreve VTIs estáticas e dinâmicas e lista roteamento estático, BGP, OSPF e EIGRP. O histórico de recursos coloca o suporte a OSPFv2 e EIGRP sobre VTI na 9.19(1). Qualquer coisa mais antiga é outra conversa.
Então as duas primeiras perguntas são chatas e decisivas:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
A afirmação de que um ASA não pode usar VTIs, ou não pode transportar um IGP, era verdadeira para algumas imagens antigas e não é uma matriz de suporte atual. Da mesma forma, o guia da 9.24 não é uma instrução para atualizar cada equipamento. Ele diz o que aquela versão suporta, e a sua versão implantada precisa responder por si mesma.
Unicast passando não significa que o IGP vai se formar
O mesmo guia observa que o unicast passa por padrão e que o multicast precisa ser habilitado para OSPFv2 ou EIGRP na VTI, com limites documentados nos grupos multicast. Essa única frase explica a maioria das adjacências que falharam e que vi neste projeto. Um ping funcionando pelo túnel, ou um status de IPsec verde, prova apenas o caminho unicast. A descoberta do protocolo precisa do caminho multicast, e os dois são configurados separadamente.
Verifique na configuração da interface do túnel esse ajuste de multicast antes de mexer nos timers hello ou hold. Se o ajuste não existir, a adjacência não está lenta, é impossível.
OSPF e EIGRP lado a lado no mesmo túnel
No próprio túnel os dois protocolos parecem o que são em qualquer outro lugar. O OSPF precisa de um tipo de rede correspondente, área, autenticação e parâmetros de vizinho; o EIGRP precisa do seu número de AS e dos ajustes no nível da interface que o acompanham.
A armadilha é copiar declarações de vizinho de outro modelo de túnel. Os conselhos sobre vizinhos estáticos num projeto sem VTI existiam para evitar multicast, e não se transferem para uma VTI que deve transportar o protocolo nativamente. Configure o comportamento de interface suportado e depois deixe o protocolo formar a própria adjacência.
Depois compare nos eixos que realmente diferem para a sua topologia: interoperabilidade com o outro lado, comportamento de convergência que você consegue testar e o conhecimento operacional da sua equipe. Uma anedota histórica sobre um protocolo ser mais rápido ou mais leve não é uma medição da sua rede.
Vizinhos não equivalem a rotas instaladas
Com a adjacência estabelecida, separe o que é originado do que é aceito. Veja quais prefixos de filial cada lado anuncia, quais são recebidos, quais são selecionados e quais realmente chegam à tabela de roteamento. O escopo de importação, exportação e redistribuição deve ser deliberado em vez de um anúncio indiscriminado de tudo o que o dispositivo sabe.
show ospf neighbor e show eigrp neighbors dizem que a sessão está viva. show route diz se o prefixo da filial chegou, e essas são perguntas diferentes.
O caminho da aplicação é de novo uma terceira pergunta. Uma relação de vizinhança distribui alcance; ela não concede permissão pelo firewall e não prova que os seletores de tráfego e as regras de filtragem concordam. Verifique o fluxo permitido e o caminho de resposta com um teste aprovado em vez de supor que a rota implica a política.
O que a comparação concluída deve registrar
Anote a interface do túnel, a versão que a suporta, a troca de controle que você verificou e a política de rotas que você delimitou. Acrescente o ajuste de multicast, porque é o detalhe que decide em silêncio se o resto funciona. Guarde esse registro junto da versão implantada para que uma mudança posterior de recurso possa ser revista sem recomeçar de uma suposição que já expirou.
Se faltar qualquer um desses quatro, você tem uma preferência e não um projeto. Corrija primeiro o fato que falta; a escolha do protocolo é a parte fácil.