Por que o comando show ip ospf neighbor revela vizinhos em estado init?
Índice
Introdução
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.
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
Convenções
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Problema
Olhe este 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#
Nestas saídas de exemplo, o estado de INIT indica que router-2 vê pacotes Hello do vizinho, mas uma comunicação em dois sentidos não foi estabelecida. Um roteador Cisco inclui o roteador ID de todos os vizinhos no estado do init (ou um mais alto) no campo vizinho de seus pacotes Hello. Para que uma comunicação em dois sentidos seja estabelecida com um vizinho, um roteador igualmente deve ver seu próprio Router ID no campo vizinho dos pacotes Hello do vizinho. Ou seja um roteador com um vizinho no estado de INIT tem pacotes de hello recebido do vizinho mas não viu seu próprio Router ID nos hellos do vizinho. Neste caso, se o roteador não recebe quatro hellos consecutivos, rasga para baixo a sessão e a adjacência de OSPF vai para baixo.
Possíveis causas e soluções de um travamento de vizinho no estado Init
A razão mais provável que um roteador local não está alistado nos pacotes Hello de um vizinho é que o vizinho não tem pacotes de hello recebido do roteador local. As razões possíveis para esta são:
-
Use os comandos ping and traceroute verificar que os links entre o Roteadores são operacionais. Se um sibilo entre o Roteadores não é bem sucedido, o link não está funcionando corretamente e você precisa de ser pesquisa-o defeitos. Refira as páginas de Troubleshooting relativas para mergulhar a tecnologia que 2 você está usando, como o ISDN, os Ethernet, o ATM, etc.
-
Se há alguma Listas de acesso definida na relação do vizinho, o IP de destino de 224.0.0.5 deve ser permitido na lista de acesso de entrada.
-
Os pacotes de hello de OSPF têm um endereço de destino de 224.0.0.5 (todo o endereço de multicast do Roteadores OSPF).
-
-
Pôde haver uma segundo camada ou problema de configuração que afetam pacotes de transmissão múltipla de alcançar o roteador vizinho. Você pode testar este com o comando ping no endereço de multicast 224.0.0.5 e confirmar que as respostas estão recebidas do roteador vizinho. Nas mídias de não-broadcast tais como o Frame Relay, o X.25, e o ISDN, traçando são exigidos entre a camada 2 e o endereço IP de Um ou Mais Servidores Cisco ICM NT. Em caso do mapeamento estático (por exemplo, o frame-relay map ip 1.1.1.1 100 do nível de interface roteador1 transmite ou do nome de transmissão do mapa de discadores IP 1.1.1.1 55346 comandos), você deve configurar o broadcast de palavra-chave para evitar a falha de encapsulamento cada vez que o OSPF tenta enviar o pacote de hello de transmissão múltipla. O comando debug ip packet detail usado com a lista de acessos mostra se há alguma falha de encapsulamento.
-
A autenticação não é permitida em ambos os lados. O roteador em que a autenticação não é permitida ainda processa pacotes Hello do vizinho e vê o vizinho no estado de INIT. A fim corrigir este problema, permita a autenticação em ambos os lados.
-
Se você está executando o Software Release 11.1.9 ou Anterior de Cisco IOS®, verifique a saída do comando show ip ospf interface para ver se há discrepâncias, como:
Neighbor Count is 0, Adjacent neighbor count is 1
-
Se o contagem de vizinho adjacente OSPF é mais alto do que o contagem vizinha, a lista vizinha pôde ser corrompida. Alcance a identificação de bug Cisco CSCdj01682 (clientes registrados somente) para mais informação.
Feedback