Este documento explica as possíveis causas e soluções para situações em que o comando show ip ospf neighbor revela os vizinhos do Open Shortest Path First (OSPF) no estado INIT.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Dê uma olhada neste exemplo de saída do 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#
Neste exemplo de saída, o estado init indica que o roteador 2 vê pacotes hello do vizinho, mas a comunicação bidirecional não foi estabelecida. Um roteador Cisco inclui as IDs de roteador de todos os vizinhos no estado init (ou superior) no campo vizinho de seus pacotes hello. Para que a comunicação bidirecional seja estabelecida com um vizinho, um roteador também deve ver a própria ID de roteador no campo Neighbor (Vizinho) dos pacotes de HELLO do vizinho. Em outras palavras, um roteador com um vizinho no estado init recebeu pacotes de saudação do vizinho, mas não viu seu próprio ID de roteador nas saudações do vizinho. Nesse caso, se o roteador não receber quatro saudações consecutivas, ele derrubará a sessão e a adjacência OSPF ficará inativa.
O motivo mais provável para que um roteador local não esteja listado nos pacotes de saudação de um vizinho é que o vizinho não recebeu pacotes de saudação do roteador local. As possíveis razões para isso são:
Use os comandos ping e traceroute para verificar se os links entre os roteadores estão operacionais. Se um ping entre os roteadores não for bem-sucedido, o link não está funcionando corretamente e você precisa solucioná-lo. Consulte as páginas de solução de problemas relacionados à tecnologia de Camada 2 que você está usando, como ISDN, Ethernet, ATM, etc.
Se houver alguma lista de acesso definida na interface do vizinho, o IP de destino 224.0.0.5 deve ser permitido na lista de acesso de entrada.
Os pacotes hello do OSPF têm um endereço de destino 224.0.0.5 (o endereço multicast de todos os roteadores ospf).
Pode haver um problema de segunda camada ou de configuração que afete os pacotes multicast de alcançar o roteador vizinho. Você pode testar isso com o comando ping no endereço multicast 224.0.0.5 e confirmar se as respostas foram recebidas dos roteadores vizinhos. Em meios não broadcast, como Frame Relay, X.25 e ISDN, o mapeamento é necessário entre a camada 2 e o endereço IP. No caso de mapeamento estático (por exemplo, o mapa frame-relay de nível de interface ip 1.1.1.1 100 broadcast ou dialer map ip 1.1.1.1 broadcast name router1 55346 comandos), você deve configurar a palavra-chave broadcast para evitar falha de encapsulamento toda vez que o OSPF tente enviar pacote de hello multicast. O comando debug ip packet detail usado com a lista de acesso mostra se há falhas de encapsulamento.
A autenticação não está ativada em ambos os lados. O roteador no qual a autenticação não está habilitada ainda processa pacotes hello do vizinho e vê o vizinho no estado init. Para corrigir esse problema, habilite a autenticação em ambos os lados.
Se você estiver executando o software Cisco IOS® versão 11.1.9 ou anterior, verifique a saída do comando show ip ospf interface para verificar se há discrepâncias, como:
Neighbor Count is 0, Adjacent neighbor count is 1
Se a contagem de vizinhos adjacentes do OSPF for superior à contagem de vizinhos, a lista de vizinhos pode estar corrompida. Acesse o bug da Cisco ID CSCdj01682 (somente clientes registrados) para obter mais informações.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
10-Aug-2005 |
Versão inicial |