OSPF ou EIGRP sobre unha VTI de ASA: cal admite a súa versión
OSPFv2 e EIGRP só circulan por unha VTI de ASA desde a 9.19(1), e só co multicast activado. Compare ambos na versión que executa e despois verifique os veciños.
A maioría das discusións entre OSPF e EIGRP dan por feito que o túnel xa pode transportar o protocolo, e nun ASA esa suposición é xustamente a parte que convén comprobar primeiro. A comparación só se volve interesante despois de confirmar a imaxe, o tipo de VTI e a ruta de multicast. Se se equivoca nesa orde, pasará unha tarde axustando temporizadores nun túnel que nunca formará unha adxacencia. Empezo cada un destes deseños coas notas da versión e a configuración en execución, non coa preferencia de protocolo.
A versión decide antes que o protocolo
A guía de VTI de Cisco para ASA 9.24 é unha base documental aproveitábel: describe VTI estáticas e dinámicas e enumera enrutamento estático, BGP, OSPF e EIGRP. O seu historial de funcións sitúa o soporte de OSPFv2 e EIGRP sobre VTI na 9.19(1). Calquera cousa máis antiga é outra conversa.
Así que as dúas primeiras preguntas son aburridas 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 afirmación de que un ASA non pode usar VTI, ou non pode transportar un IGP, era certa nalgunhas imaxes antigas e non é unha matriz de soporte actual. Do mesmo xeito, a guía da 9.24 non é unha instrución para actualizar cada dispositivo. Di o que admite esa versión, e a súa versión despregada ten que responder por si mesma.
Que pase unicast non significa que se forme o IGP
A mesma guía sinala que o unicast pasa por defecto e que o multicast se debe activar para OSPFv2 ou EIGRP na VTI, con límites documentados nos grupos de multicast. Esa soa frase explica a maioría das adxacencias fallidas que vin neste deseño. Un ping que funcione polo túnel, ou un estado de IPsec en verde, só demostra a ruta unicast. O descubrimento do protocolo necesita a ruta multicast, e ambas se configuran por separado.
Revise a configuración da interface do túnel para ese axuste de multicast antes de tocar os temporizadores hello ou hold. Se o axuste non está, a adxacencia non é lenta, é imposible.
OSPF e EIGRP lado a lado no mesmo túnel
No propio túnel os dous protocolos parece que son como noutro sitio calquera. OSPF necesita un tipo de rede coincidente, área, autenticación e parámetros de veciño; EIGRP necesita o seu número de AS e os axustes a nivel de interface que o acompañan.
O engano está en copiar sentenzas de veciño doutro modelo de túnel. O consello sobre veciños estáticos nun deseño sen VTI existía para evitar o multicast, e non se traslada a unha VTI que se espera que transporte o protocolo de forma nativa. Configure o comportamento de interface admitido e despois deixe que o protocolo forme a súa propia adxacencia.
Despois compare nos eixes que de verdade difiren para a súa topoloxía: interoperabilidade co outro lado, comportamento de converxencia que poida probar e o coñecemento operativo do seu equipo. Unha anécdota histórica sobre que un protocolo é máis rápido ou máis lixeiro non é unha medición da súa rede.
Os veciños non equivalen a rutas instaladas
Unha vez levantada a adxacencia, separe o que se orixina do que se acepta. Mire que prefixos de sucursal anuncia cada lado, cales se reciben, cales se seleccionan e cales chegan realmente á táboa de enrutamento. O alcance de importación, exportación e redistribución debe ser deliberado e non un anuncio indiscriminado de todo o que o dispositivo sabe.
show ospf neighbor e show eigrp neighbors dinlle que a sesión está viva. show route dille se chegou o prefixo da sucursal, e esas son preguntas distintas.
A ruta da aplicación é de novo unha terceira pregunta. Unha relación de veciños distribúe alcanzabilidade; non concede permiso a través da devasa e non demostra que os selectores de tráfico e as regras de filtrado coinciden. Verifique o fluxo permitido e a súa ruta de resposta cunha proba aprobada en lugar de supor que a ruta implica a política.
Que debe rexistrar a comparación rematada
Anote a interface do túnel, a versión que a admite, o intercambio de control que verificou e a política de rutas que delimitou. Engada o axuste de multicast, porque é o detalle que decide en silencio se algo do resto funciona. Garde ese rexistro xunto á versión despregada para que un cambio de función posterior poida revisarse sen partir dunha suposición que xa caducou.
Se falta calquera deses catro, ten unha preferencia e non un deseño. Corrixa primeiro o dato que falta; escoller o protocolo é a parte fácil.