¿Los vecinos OSPF no se forman sobre una VPN? Compruebe esto en orden
Cinco comprobaciones, cada una con su propio síntoma: modelo de enlace, filtrado del protocolo 89, parámetros del vecino, estado de adyacencia y, por último, qué se anuncia realmente.
El túnel está activo, las interfaces están en la misma subred y OSPF sigue sin mostrar nada. La mayoría de las veces el túnel está bien y un requisito de OSPF no se cumple. Realice las cinco comprobaciones siguientes en orden y deténgase en la primera que falle.
Cada comprobación tiene un síntoma distinto, por eso el orden importa más que la lista.
Comprobación 1: ¿es correcto el modelo de enlace
Una interfaz punto a punto y una red compartida de acceso múltiple son entornos OSPF distintos. Copiar una configuración de LAN broadcast sobre un túnel es el error más común aquí. Configure el tipo de red que admite la implementación de VPN, normalmente punto a punto para un túnel enrutado. Luego confirme que la plataforma está de acuerdo, porque algunas implementaciones ignoran o sobrescriben el ajuste.
Si el modelo de enlace es incorrecto, nada de lo que sigue en la lista ayudará.
Comprobación 2: ¿se permite el paso de los paquetes
OSPFv2 es el protocolo IP 89, no un puerto TCP o UDP, así que una regla de firewall escrita para puertos lo descarta en silencio. Los hello también van a direcciones multicast, que una política puede no permitir. Permita el protocolo 89 entre los extremos del túnel y luego compruebe si la plataforma necesita declaraciones de vecino explícitas.
Un túnel que solo deja pasar ping es un problema de política, no de enrutamiento.
Comprobación 3: ¿coinciden los parámetros del vecino
El ID de área, los intervalos hello y dead, la autenticación y los indicadores stub deben coincidir. Una discrepancia suele dejar al vecino en un estado visible en lugar de fallar en silencio, lo cual es útil. Compare la configuración en ejecución en ambos extremos, no la prevista.
La discrepancia de MTU es la sutil. Bloquea el intercambio de base de datos en ExStart, así que el vecino nunca llega a Full.
Comprobación 4: ¿qué dice el estado
El estado nombra el fallo. Init significa que llegan hello pero este router no aparece en ellos, lo que apunta a una ruta unidireccional o a un problema de multicast. Two-Way es normal en un segmento broadcast con un vecino que no es DR y anómalo en un enlace punto a punto. Un ExStart o Exchange atascado indica un problema de MTU o de descripción de base de datos. Loading significa que no se responden las peticiones de estado de enlace.
Lea el estado antes de cambiar nada, porque elimina la mayor parte de la lista.
show ip ospf neighbor imprime el estado, la dirección del vecino y el temporizador dead. Compare ese temporizador con el intervalo hello en ambos lados: un intervalo dead cuatro veces el hello es normal, cualquier otra cosa es una discrepancia. La columna de estado es la lectura más rápida de toda la página.
Comprobación 5: ¿qué se anuncia realmente
Una adyacencia Full no es una ruta. Compruebe qué redes se originan, cuáles se aprenden y cuáles se instalan en la tabla de enrutamiento. Una declaración de red ausente o una política de redistribución que excluye el prefijo del sitio produce un vecino sano y una tabla vacía.
Luego pruebe una aplicación a nivel de host y la ruta de retorno, porque un protocolo de enrutamiento no abre un firewall.
Para IPv6, OSPFv3 tiene sus propios requisitos y no es un conmutador de familia de direcciones en cada ajuste de OSPFv2. Utilice el protocolo correspondiente y la documentación de la plataforma. Y si la conexión es un único enlace fijo, compare las rutas estáticas antes de añadir un plano de control que tenga que operar.