Os veciños OSPF non se forman sobre unha VPN? Comproba isto por orde
Cinco comprobacións, cada unha co seu propio síntoma: modelo de enlace, filtrado do protocolo 89, parámetros do veciño, estado de adxacencia e, por último, que se anuncia realmente.
O túnel está activo, as interfaces están na mesma subrede e OSPF segue sen mostrar nada. A maioría das veces o túnel está ben e un requisito de OSPF non se cumpre. Fai as cinco comprobacións de abaixo por orde e detente na primeira que falle.
Cada comprobación ten un síntoma distinto, por iso a orde importa máis ca a lista.
Comprobación 1: é correcto o modelo de enlace
Unha interface punto a punto e unha rede compartida de acceso múltiple son contornos OSPF distintos. Copiar unha configuración de LAN broadcast sobre un túnel é o erro máis común aquí. Define o tipo de rede que admite a implementación de VPN, normalmente punto a punto para un túnel encamiñado. Despois confirma que a plataforma está de acordo, porque algunhas implementacións ignoran ou sobrescriben o axuste.
Se o modelo de enlace é incorrecto, nada do que segue na lista axudará.
Comprobación 2: permítese o paso dos paquetes
OSPFv2 é o protocolo IP 89, non un porto TCP ou UDP, así que unha regra de devasa escrita para portos descártao en silencio. Os hello tamén van a enderezos multicast, que unha política pode non permitir. Permite o protocolo 89 entre os extremos do túnel e despois comproba se a plataforma precisa declaracións de veciño explícitas.
Un túnel que só deixa pasar ping é un problema de política, non de encamiñamento.
Comprobación 3: coinciden os parámetros do veciño
O ID de área, os intervalos hello e dead, a autenticación e os indicadores stub deben coincidir. Unha discrepancia adoita deixar o veciño nun estado visible en lugar de fallar en silencio, o que é útil. Compara a configuración en execución nos dous extremos, non a prevista.
A discrepancia de MTU é a sutil. Bloquea o intercambio de base de datos en ExStart, así que o veciño nunca chega a Full.
Comprobación 4: que di o estado
O estado nomea o fallo. Init significa que chegan hello pero este encamiñador non aparece neles, o que apunta a un camiño unidireccional ou a un problema de multicast. Two-Way é normal nun segmento broadcast cun veciño que non é DR e anómalo nun enlace punto a punto. Un ExStart ou Exchange atascado indica un problema de MTU ou de descrición da base de datos. Loading significa que non se responden as peticións de estado de enlace.
Le o estado antes de cambiar nada, porque elimina a maior parte da lista.
show ip ospf neighbor imprime o estado, o enderezo do veciño e o temporizador dead. Compara ese temporizador co intervalo hello nos dous lados: un intervalo dead catro veces o hello é normal, calquera outra cousa é unha discrepancia. A columna de estado é a lectura máis rápida de toda a páxina.
Comprobación 5: que se anuncia realmente
Unha adxacencia Full non é unha ruta. Comproba que redes se orixinan, cales se aprenden e cales se instalan na táboa de encamiñamento. Unha declaración de rede ausente ou unha política de redistribución que exclúe o prefixo do sitio produce un veciño san e unha táboa baleira.
Despois proba unha aplicación a nivel de host e o camiño de volta, porque un protocolo de encamiñamento non abre unha devasa.
Para IPv6, OSPFv3 ten os seus propios requisitos e non é un conmutador de familia de enderezos en cada axuste de OSPFv2. Usa o protocolo correspondente e a documentación da plataforma. E se a conexión é un único enlace fixo, compara as rutas estáticas antes de engadir un plano de control que teñas que operar.