Un vecino que no se establece, que se atasca en un estado específico, o una ruta que sigue fluctuando — todo esto parece misterioso hasta que lo ubica en la máquina de estados de vecinos OSPF. Aquí se explica cómo leerla, los comandos display para cada estado, y las causas que explican la mayoría de estas fallas.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Los problemas de vecinos OSPF parecen intimidantes desde fuera — Init, ExStart, 2-Way — hasta que uno se da cuenta de que cada estado atascado corresponde a una lista corta y específica de causas.
Un vecino OSPF que no se establece, que se atasca en un estado particular, o una ruta que sigue fluctuando sin razón evidente — todo esto parece a primera vista un profundo misterio del protocolo. En la práctica, una vez que se sabe en qué estado está realmente atascada la adyacencia, la lista de causas plausibles se reduce rápido, porque cada estado de la máquina de estados de vecinos OSPF corresponde a un paso específico de la negociación, y solo un puñado de cosas puede romper ese paso específico.
A continuación, la máquina de estados en sí, lo que implica realmente atascarse en cada estado, los comandos display a verificar en cada uno, las causas que aparecen una y otra vez, y un caso real de convergencia con salida show real del campo.
Siete estados entre Down y Full — y tres de ellos son donde una adyacencia se atasca casi siempre.
Antes de ejecutar cualquier comando, ubique el síntoma en esta cadena. Le indica exactamente qué sección leer a continuación.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Empiece por ver si el vecino siquiera aparece — luego lea el estado específico en el que está atascado.
Si el vecino nunca aparece, o aparece y luego cae a Down, revise primero la palabra clave del registro antes de adivinar una causa.
<Huawei> display ospf interface
OSPF Process 1 with Router ID 1.1.1.1
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 1 192.168.1.1 0.0.0.0
<Huawei> display ospf error
General packet errors:
0 : Bad authentication type 0 : Bad authentication key
HELLO packet errors:
0 : Hello timer mismatch 0 : Dead timer mismatch
// counters climbing here point straight at the mismatched parameterUna vez que un vecino es visible, el estado en el que está congelado reduce aún más la lista de causas.
<Huawei> display ospf interface
IP Address Type State Cost Pri DR BDR
1.1.1.1 Broadcast DROther 1 0 1.1.1.2 0.0.0.0
// Pri 0 + DROther = expected 2-Way, not a fault
<Huawei> ping -s 1500 -a 1.1.1.1 1.1.1.2
// tests whether oversized packets survive the path -- common ExStart causeUna vez que conoce el estado, estas cinco causas explican la mayor parte de lo que realmente falla debajo.
SÍNTOMAEl vecino nunca pasa de Down o Init aunque las interfaces estén up y el enlace esté bien — y no hay ningún error evidente en ningún lado.
CAUSAVarios parámetros independientes deben coincidir exactamente para que un vecino se forme siquiera: el Area ID de OSPF en ambos extremos, la subred y máscara para redes broadcast/NBMA/P2MP (P2P no tiene ese requisito), y los intervalos de temporizador hello/dead. Ninguno de estos produce un error dramático — simplemente impiden silenciosamente que la adyacencia se forme.
SOLUCIÓNCompare primero el campo Area de display ospf interface en ambos extremos. Luego ejecute display ospf error cada 10 segundos durante unos 5 minutos — un contador Hello timer mismatch o Dead timer mismatch que sube indica exactamente qué temporizador alinear con ospf timer hello o ospf timer dead.
<Huawei> display ospf interface
OSPF Process 1 with Router ID 10.1.1.1
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
10.1.1.1 Broadcast BDR 1 1 10.1.1.2 10.1.1.1
// compare Area against the peer's own display ospf interface outputSÍNTOMAEl estado del vecino está congelado en ExStart — los paquetes DD van y vienen pero la descripción de la base de datos nunca se sincroniza.
CAUSACuando ospf mtu-enable está configurado, se requiere que los valores de MTU de las dos interfaces sean iguales, o la sincronización DD no puede completarse. Además, paquetes sobredimensionados descartados silenciosamente en algún punto de la ruta producen exactamente el mismo síntoma.
SOLUCIÓNEjecute ping -s 1500 neighbor-address para verificar si los paquetes grandes sobreviven la ruta. Si no, repare el enlace. Si sí, compare e iguale el MTU de las interfaces de ambos extremos con el comando mtu.
<Huawei> ping -s 1500 -a 1.1.1.1 1.1.1.2
[Huawei-GigabitEthernet1/0/0] mtu 1500SÍNTOMAUna relación de vecino nunca se forma con un router específico de un tercero, aunque el mismo router local interopera bien con todos los demás vecinos OSPF de la red.
CAUSAOSPF exige que el tipo de red de la interfaz coincida en ambos extremos de un enlace — Broadcast, NBMA, P2P y P2MP son los cuatro tipos estándar, y broadcast/NBMA/P2MP además exigen que ambos extremos compartan la misma subred y máscara (P2P no). En un caso real de interoperabilidad, la interfaz de un router de un tercero estaba configurada en un modo propietario «point-to-multipoint non-broadcast» — que se comporta como P2MP NBMA sobre el papel pero en realidad ejecuta un protocolo propietario y no estándar por debajo. Los dos lados nunca hablaron realmente el mismo dialecto OSPF, y la relación de vecino falló por completo.
SOLUCIÓNVerifique el tipo de red en ambos extremos con el equivalente de ospf network-type y fuércelos a uno de los cuatro tipos estándar de OSPF. No acepte una variante no estándar o propietaria de un peer solo porque su nombre suene parecido.
SÍNTOMAUn vecino nunca aparece, o la red se comporta de forma inconsistente sin poder rastrearlo a ningún enlace único — rutas o adyacencias que parecen funcionar en un lugar y no en otro.
CAUSADos routers en el mismo dominio OSPF están configurados con el mismo Router ID. Como el Router ID se supone que es único en todo el sistema autónomo, una colisión produce síntomas confusos e inconsistentes en lugar de un error limpio.
SOLUCIÓNCompare el Router ID de display ospf brief en ambos extremos, y reasigne uno único con ospf router-id.
<Huawei> display ospf brief
OSPF Process 1 with Router ID 1.1.1.1
OSPF Protocol Information
[Huawei] ospf router-id 1.1.1.2SÍNTOMAEl vecino nunca se forma, y todas las demás comprobaciones — interfaz, subred, MTU, temporizadores — salen limpias.
CAUSALos dos routers que construyen la adyacencia tienen configurados tipos de autenticación OSPF diferentes para el área.
SOLUCIÓNEjecute display ospf error cada 10 segundos durante unos 5 minutos. Si el contador Bad authentication type sigue subiendo, eso confirma la discrepancia — configure el mismo tipo de autenticación en ambos extremos con area-authentication-mode.
<Huawei> display ospf error
General packet errors:
0 : Bad authentication type 0 : Bad authentication key
// a climbing Bad authentication type counter confirms the mismatch
[Huawei-ospf-1-area-0.0.0.0] area-authentication-mode md5Cuatro switches, un enlace roto, y la diferencia que hace el tipo de red en qué tan rápido — y cómo — OSPF realmente se da cuenta.
La red: cuatro routers ejecutando OSPF area 0, con SW2 y SW4 compartiendo un segmento donde SW4 es el DR. El tráfico normal entre SW2 y una loopback en SW4 (4.4.4.4) transita por un tercer router, SW3. La prueba: mantener un ping continuo de SW2 a 4.4.4.4, luego desconectar físicamente el enlace de SW2 a SW4, y observar qué hacen realmente las LSA propias de cada router.
Con el enlace SW2–SW4 configurado en el tipo de red broadcast por defecto, desconectarlo no libera la adyacencia de inmediato. SW2 se da cuenta enseguida y vuelve a emitir su propio router-LSA sin la red compartida, y recalcula rápido sus propias rutas. Pero el router-LSA de SW4 y su network-LSA para ese segmento aún no cambian — SW4 sigue esperando que expire su temporizador dead. Cuando SW4 recalcula mientras tanto su propio árbol SPF, tiene que revisar el router-LSA de SW2 en busca de un enlace de vuelta a la red compartida para validar esa ruta; como el nuevo LSA de SW2 ya no la incluye, SW4 correctamente se niega a usar esa ruta, pero el segmento no se libera por completo de la topología hasta que expira el propio temporizador dead de SW4.
SW4#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:37 1.1.24.2 GigabitEthernet0/24
1.1.1.1 1 FULL/DR 00:00:39 1.1.14.1 GigabitEthernet0/1
// after SW4's dead timer actually expires:
*Mar 1 01:18:54.681: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on GigabitEthernet0/24
from FULL to DOWN, Neighbor Down: Dead timer expired
SW4#show ip ospf database router self-originate
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.24.0
(Link Data) Network Mask: 255.255.255.0
// the segment only changes from Transit to Stub -- and the matching
// network-lsa is only withdrawn -- once SW4's own dead timer expiresCambiar ese mismo enlace SW2–SW4 al tipo de red punto a punto cambia el resultado, no solo el tiempo. En un enlace P2P, desconectar el cable (o apagar la interfaz) hace caer al vecino de inmediato en ambos lados — no hay relación DR/BDR ni una capa de network-LSA que esperar. SW2 deja de anunciar el enlace en el instante en que su propia interfaz cae; SW4 hace lo mismo en el momento en que se rompe su relación de vecino, porque un router-LSA P2P solo lleva la entrada de enlace que describe al vecino mientras la adyacencia está realmente en Full. Ningún lado se queda esperando el temporizador dead del otro para que la red reconverja por completo.
La lección práctica no es «P2P siempre es mejor» — es que el tipo de red no es solo un detalle de configuración, cambia realmente cómo se propaga una falla por la base de datos de estado de enlace, y vale la pena conocerlo deliberadamente en lugar de por accidente cuando la velocidad de convergencia importa.
Esta nota se basa en el flujo de diagnóstico de estado de vecinos OSPF del router Huawei serie AR (display ospf interface / display ospf error / display logbuffer) más un caso real de convergencia multifabricante. No cubre en profundidad el comportamiento específico de NSSA, los enlaces virtuales, las diferencias de OSPFv3, ni los problemas de resumen de ABR multiárea — cada uno tiene sus propios modos de falla que merecen una mirada aparte.
Cuéntenos en qué estado está congelado y envíe la salida de display ospf interface / display ospf error — le ayudamos a interpretarla.