¿Por qué el comando show ip ospf neighbor informa que los vecinos se encuentran en el estado inicial?
Contenido
Introducción
Este documento explica las causas y soluciones posibles por las que el comando show ip ospf neighbor revela los vecinos de Open Shortest Path First (OSPF) en el estado init.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Convenciones
Problema
Eche un vistazo a este ejemplo de salida del comando show ip ospf neighbor:
router2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 170.170.5.1 1 INIT/- 00:00:34 170.170.1.1 Serial0 router-2#
En este resultado de ejemplo, el estado init indica que el router 2 ve los paquetes hello del vecino, pero no se ha establecido la comunicación bidireccional. Un router Cisco incluye los ID de router de todos los vecinos en el estado init (o superior) en el campo neighbor de sus paquetes hello. Para establecer una comunicación bidireccional con un vecino, un router también debe ver su propio ID de router en el campo Neighbor (vecino) de los paquetes de saludo del vecino. En otras palabras, un router con un vecino en estado init ha recibido paquetes hello del vecino pero no ha visto su propio ID de router en los saludos del vecino. En este caso, si el router no recibe cuatro saludos consecutivos, desgarra la sesión y la adyacencia OSPF se desactiva.
Posibles causas y soluciones de un bloqueo de vecino en estado de inicialización
La razón más probable de que un router local no aparezca en los paquetes hello de un vecino es que el vecino no ha recibido paquetes hello del router local. Las posibles razones para ello son las siguientes:
-
Utilice los comandos ping y traceroute para verificar que los links entre los routers estén operativos. Si un ping entre routers no funciona correctamente, el link no funciona correctamente y debe resolver problemas. Consulte las páginas de solución de problemas relacionadas con la tecnología de Capa 2 que está utilizando, como ISDN, Ethernet, ATM, etc.
-
Si hay alguna lista de acceso definida en la interfaz del vecino, se debe permitir la IP de destino de 224.0.0.5 en la lista de acceso de entrada.
-
Los paquetes hello OSPF tienen una dirección de destino de 224.0.0.5 (la dirección multicast de todos los routers ospf).
-
-
Puede que haya un problema de configuración o de segunda capa que afecte a los paquetes multicast para que no lleguen al router vecino. Puede probar esto con el comando ping en la dirección multicast 224.0.0.5 y confirmar que se reciben respuestas de los routers vecinos. En medios no broadcast como Frame Relay, X.25 e ISDN, se requiere la asignación entre la capa 2 y la dirección IP. En caso de mapping estático (por ejemplo, los comandos frame-relay map ip 1.1.1.1 100 broadcast o dialer map ip 1.1.1.1 broadcast name router1 55346), debe configurar la palabra clave broadcast para evitar la falla de encapsulación cada vez que OSPF intenta enviar el paquete multicast. El comando debug ip packet detail utilizado con la lista de acceso muestra si hay fallas de encapsulación.
-
La autenticación no está habilitada en ambos lados. El router en el que la autenticación no está habilitada sigue procesando los paquetes hello del vecino y ve al vecino en el estado init. Para corregir este problema, habilite la autenticación en ambos lados.
-
Si está ejecutando Cisco IOS® Software Release 11.1.9 o una versión anterior, verifique la salida del comando show ip ospf interface para ver si hay discrepancias, como:
Neighbor Count is 0, Adjacent neighbor count is 1
-
Si el conteo de vecinos adyacentes OSPF es mayor que el conteo de vecinos, la lista de vecinos podría estar dañada. Acceda al ID de bug de Cisco CSCdj01682 (sólo clientes registrados) para obtener más información.
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
10-Aug-2005 |
Versión inicial |
Comentarios