OSPF o EIGRP sobre una VTI de ASA: cuál admite su versión
OSPFv2 y EIGRP solo circulan por una VTI de ASA desde la 9.19(1), y solo con multicast habilitado. Compare ambos en la versión que ejecuta y luego verifique los vecinos.
La mayoría de las discusiones entre OSPF y EIGRP dan por hecho que el túnel ya puede transportar el protocolo, y en un ASA esa suposición es justo la parte que conviene comprobar primero. La comparación solo se vuelve interesante después de confirmar la imagen, el tipo de VTI y la ruta de multicast. Si se equivoca en ese orden, pasará una tarde ajustando temporizadores en un túnel que nunca formará una adyacencia. Empiezo cada uno de estos diseños con las notas de la versión y la configuración en ejecución, no con la preferencia de protocolo.
La versión decide antes que el protocolo
La guía de VTI de Cisco para ASA 9.24 es una base documental aprovechable: describe VTI estáticas y dinámicas y enumera enrutamiento estático, BGP, OSPF y EIGRP. Su historial de funciones sitúa el soporte de OSPFv2 y EIGRP sobre VTI en la 9.19(1). Cualquier cosa más antigua es otra conversación.
Así que las dos primeras preguntas son aburridas y 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 |
La afirmación de que un ASA no puede usar VTI, o no puede transportar un IGP, era cierta en algunas imágenes antiguas y no es una matriz de soporte actual. Del mismo modo, la guía de la 9.24 no es una instrucción para actualizar cada dispositivo. Dice qué admite esa versión, y su versión desplegada tiene que responder por sí misma.
Que pase unicast no significa que se forme el IGP
La misma guía señala que el unicast pasa por defecto y que el multicast debe habilitarse para OSPFv2 o EIGRP en la VTI, con límites documentados en los grupos de multicast. Esa sola frase explica la mayoría de las adyacencias fallidas que he visto en este diseño. Un ping que funcione por el túnel, o un estado de IPsec en verde, solo demuestra la ruta unicast. El descubrimiento del protocolo necesita la ruta multicast, y ambas se configuran por separado.
Revise la configuración de la interfaz del túnel para ese ajuste de multicast antes de tocar los temporizadores hello o hold. Si el ajuste no está, la adyacencia no es lenta, es imposible.
OSPF y EIGRP lado a lado en el mismo túnel
En el túnel mismo los dos protocolos lucen como en cualquier otro sitio. OSPF necesita un tipo de red coincidente, área, autenticación y parámetros de vecino; EIGRP necesita su número de AS y los ajustes a nivel de interfaz que lo acompañan.
La trampa es copiar sentencias de vecino de otro modelo de túnel. El consejo sobre vecinos estáticos en un diseño sin VTI existía para evitar el multicast, y no se traslada a una VTI que se espera que transporte el protocolo de forma nativa. Configure el comportamiento de interfaz admitido y luego deje que el protocolo forme su propia adyacencia.
Después compare en los ejes que de verdad difieren para su topología: interoperabilidad con el otro lado, comportamiento de convergencia que pueda probar y el conocimiento operativo de su equipo. Una anécdota histórica sobre que un protocolo es más rápido o más ligero no es una medición de su red.
Los vecinos no equivalen a rutas instaladas
Una vez levantada la adyacencia, separe lo que se origina de lo que se acepta. Mire qué prefijos de sucursal anuncia cada lado, cuáles se reciben, cuáles se seleccionan y cuáles llegan realmente a la tabla de enrutamiento. El alcance de importación, exportación y redistribución debe ser deliberado y no un anuncio indiscriminado de todo lo que el dispositivo sabe.
show ospf neighbor y show eigrp neighbors le dicen que la sesión está viva. show route le dice si llegó el prefijo de la sucursal, y esas son preguntas distintas.
La ruta de la aplicación es de nuevo una tercera pregunta. Una relación de vecinos distribuye alcanzabilidad; no concede permiso a través del firewall y no demuestra que los selectores de tráfico y las reglas de filtrado coincidan. Verifique el flujo permitido y su ruta de respuesta con una prueba aprobada en lugar de suponer que la ruta implica la política.
Qué debe registrar la comparación terminada
Anote la interfaz del túnel, la versión que la admite, el intercambio de control que verificó y la política de rutas que delimitó. Añada el ajuste de multicast, porque es el detalle que decide en silencio si algo del resto funciona. Guarde ese registro junto a la versión desplegada para que un cambio de función posterior pueda revisarse sin partir de una suposición que ya caducó.
Si falta cualquiera de esos cuatro, tiene una preferencia y no un diseño. Corrija primero el dato que falta; elegir el protocolo es la parte fácil.