Vizinho OSPF travado ou rotas oscilando? Ler a máquina de estados para encontrar a falha
Um vizinho que não sobe, que trava em um estado específico, ou uma rota que fica oscilando — tudo isso parece misterioso até você posicionar isso na máquina de estados de vizinhos OSPF. Aqui está como lê-la, os comandos display para cada estado, e as causas que respondem pela maioria dessas falhas.
Por Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
Por que a máquina de estados é a entrada mais rápida
Os problemas de vizinhos OSPF parecem intimidantes de fora — Init, ExStart, 2-Way — até você perceber que cada estado travado corresponde a uma lista curta e específica de causas.
Um vizinho OSPF que não sobe, que trava em um estado particular, ou uma rota que fica oscilando sem razão aparente — tudo isso parece, à primeira vista, um profundo mistério do protocolo. Na prática, uma vez que se sabe em qual estado a adjacência está realmente travada, a lista de causas plausíveis diminui rapidamente, porque cada estado da máquina de estados de vizinhos OSPF corresponde a uma etapa específica da negociação, e apenas um punhado de coisas pode quebrar essa etapa específica.
A seguir está a própria máquina de estados, o que travar em cada estado realmente implica, os comandos display a verificar em cada um, as causas que aparecem repetidamente, e um caso real de convergência com saída show real do campo.
A máquina de estados de vizinhos OSPF
Sete estados entre Down e Full — e três deles são onde uma adjacência trava quase sempre.
Antes de executar qualquer comando, posicione o sintoma nesta cadeia. Isso indica exatamente qual seção abaixo ler em seguida.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Diagnosticar por estado
Comece verificando se o vizinho sequer aparece — depois leia o estado específico em que está travado.
Nenhum vizinho visível
Se o vizinho nunca aparece, ou aparece e depois cai para Down, verifique primeiro a palavra-chave do log antes de adivinhar uma causa.
- Execute display logbuffer e procure a palavra-chave NBR_DOWN_REASON NeighborDownImmediate reason. «Neighbor Down Due to Inactivity» significa que o temporizador dead expirou — nenhum hello chegou a tempo. «Neighbor Down Due to Kill Neighbor» aponta para uma interface caindo, uma sessão BFD caindo, ou alguém executando reset ospf process — verifique NeighborDownPrimeReason para saber qual. «Neighbor Down Due to 1-Way hello Received» ou «SequenceNum Mismatch» significa que o próprio estado OSPF do peer caiu primeiro — o problema está no outro roteador, não neste.
- Verifique o próprio link em busca de uma falha física.
- Verifique display cpu-usage — se o campo de CPU do processo de roteamento passar de cerca de 60%, o OSPF não consegue enviar e receber pacotes do protocolo de forma confiável, e os vizinhos oscilam como efeito colateral.
- Verifique display cpu-defend statistics em busca de pacotes OSPF descartados pela limitação de taxa de defesa contra ataques; se houver muito descarte, a taxa CPCAR para OSPF precisa ser ajustada.
- Verifique display interface para o estado físico Up, depois display ospf interface para o estado no nível OSPF (DR / BDR / DR Other / P2P são todos saudáveis; Down não é).
- Para redes broadcast ou NBMA, confirme que os endereços IP dos dois lados realmente estão na mesma sub-rede.
- Se ospf mtu-enable estiver configurado, confirme que os valores de MTU das duas interfaces são iguais — um MTU discordante bloqueia totalmente a negociação com essa configuração.
- Para redes broadcast/NBMA, confirme que pelo menos um dos lados tem a prioridade de interface diferente de zero, para que um DR possa realmente ser eleito.
- Compare o Router ID (display ospf brief), o Area ID (display ospf interface), e — executando display ospf error a cada 10 segundos por cerca de 5 minutos — observe os contadores Bad authentication type, Hello timer mismatch e Dead timer mismatch. Um contador subindo indica exatamente qual parâmetro alinhar.
<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 parameterTravado em um estado específico
Uma vez que um vizinho é visível, o estado em que ele está congelado reduz ainda mais a lista de causas.
- Travado em Down: verifique primeiro a camada física da interface, depois se ela está realmente Up no nível OSPF com display ospf interface.
- Travado em Init: o peer não está recebendo os pacotes hello deste roteador. Isso aponta para o link ou o próprio dispositivo peer, não para uma discrepância de parâmetro local.
- Travado em 2-Way: verifique se a dr-priority da interface é 0. Se for 0 e o estado mostrar DR Other, isso na verdade é esperado — com prioridade 0, este roteador não é DR nem BDR, então não tem LSAs para trocar com esse vizinho em particular, e 2-Way é o estado final correto, não uma falha. Se a prioridade não for 0, continue investigando.
- Travado em ExStart: a negociação DD continua acontecendo, mas nunca sincroniza. Duas coisas causam isso — pacotes grandes demais que não atravessam o link (teste com ping -s 1500 neighbor-address), ou, quando ospf mtu-enable está configurado, os valores de MTU das duas interfaces simplesmente não coincidem.
- Travado em Exchange: os dois roteadores estão trocando pacotes DD, mas não concluem — trate isso como a verificação do estado Init acima.
- Travado em Loading: raro. Se acontecer, reset ospf process-id process pode resolver — mas isso reconstrói todos os vizinhos daquele processo OSPF de uma vez e causa interrupção de serviço, então é um último recurso, não um primeiro passo.
<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 cause5 causas que aparecem repetidamente
Depois de saber o estado, essas cinco causas explicam a maior parte do que realmente está errado por baixo.
1. O Area ID, a máscara de sub-rede ou os temporizadores Hello/Dead não coincidem silenciosamente
SINTOMAO vizinho nunca passa de Down ou Init mesmo com as interfaces up e o link bom — e não há nenhum erro óbvio em lugar nenhum.
CAUSAVários parâmetros independentes precisam coincidir exatamente para que um vizinho sequer se forme: o Area ID do OSPF nos dois lados, a sub-rede e máscara para redes broadcast/NBMA/P2MP (P2P não tem essa exigência), e os intervalos dos temporizadores hello/dead. Nenhum deles produz um erro dramático — eles apenas impedem silenciosamente que a adjacência se forme.
SOLUÇÃOCompare primeiro o campo Area de display ospf interface nos dois lados. Depois execute display ospf error a cada 10 segundos por cerca de 5 minutos — um contador Hello timer mismatch ou Dead timer mismatch subindo indica exatamente qual temporizador alinhar com ospf timer hello ou 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 output2. Um MTU discordante trava o vizinho em ExStart
SINTOMAO estado do vizinho está congelado em ExStart — os pacotes DD ficam indo e voltando, mas a descrição do banco de dados nunca sincroniza.
CAUSAQuando ospf mtu-enable está configurado, os valores de MTU das duas interfaces precisam ser iguais, ou a sincronização DD não pode se completar. Além disso, pacotes grandes demais sendo descartados silenciosamente em algum ponto do caminho produzem exatamente o mesmo sintoma.
SOLUÇÃOExecute ping -s 1500 neighbor-address para verificar se pacotes grandes sobrevivem ao caminho. Se não, conserte o link. Se sim, compare e iguale o MTU das interfaces dos dois lados com o comando mtu.
<Huawei> ping -s 1500 -a 1.1.1.1 1.1.1.2
[Huawei-GigabitEthernet1/0/0] mtu 15003. Incompatibilidade de tipo de rede — Broadcast tentando falar com P2P ou um NBMA não padrão
SINTOMAUma relação de vizinhança nunca se forma com um roteador específico de terceiros, mesmo que o mesmo roteador local interopere bem com todos os outros vizinhos OSPF da rede.
CAUSAO OSPF exige que o tipo de rede da interface coincida nos dois lados de um link — Broadcast, NBMA, P2P e P2MP são os quatro tipos padrão, e broadcast/NBMA/P2MP exigem ainda que os dois lados compartilhem a mesma sub-rede e máscara (P2P não exige). Em um caso real de interoperabilidade, a interface de um roteador de terceiros foi configurada em um modo proprietário «point-to-multipoint non-broadcast» — que se comporta como P2MP NBMA no papel, mas na verdade roda um protocolo proprietário e não padrão por baixo. Os dois lados nunca falaram realmente o mesmo dialeto OSPF, e a relação de vizinhança falhou completamente.
SOLUÇÃOVerifique o tipo de rede nos dois lados com o equivalente de ospf network-type e force-os para um dos quatro tipos padrão do OSPF. Não aceite uma variante não padrão ou proprietária de um peer só porque o nome parece semelhante.
4. Conflito de Router ID
SINTOMAUm vizinho nunca aparece, ou a rede se comporta de forma inconsistente sem se conseguir rastrear a um único link — rotas ou adjacências que parecem funcionar em um lugar e não em outro.
CAUSADois roteadores no mesmo domínio OSPF estão configurados com o mesmo Router ID. Como o Router ID deveria ser único em todo o sistema autônomo, uma colisão produz sintomas confusos e inconsistentes em vez de um erro limpo.
SOLUÇÃOCompare o Router ID de display ospf brief nos dois lados, e reatribua um único com 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.25. Incompatibilidade de tipo de autenticação
SINTOMAO vizinho nunca se forma, e todas as outras verificações — interface, sub-rede, MTU, temporizadores — voltam limpas.
CAUSAOs dois roteadores que constroem a adjacência têm tipos de autenticação OSPF diferentes configurados para a área.
SOLUÇÃOExecute display ospf error a cada 10 segundos por cerca de 5 minutos. Se o contador Bad authentication type continuar subindo, isso confirma a incompatibilidade — configure o mesmo tipo de autenticação nos dois lados com 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 md5Projetos de soluções relacionadas
Um exemplo real: observando um vizinho cair e a rede reconvergir
Quatro switches, um link quebrado, e a diferença que o tipo de rede faz em quão rápido — e como — o OSPF realmente percebe.
A rede: quatro roteadores rodando OSPF area 0, com SW2 e SW4 compartilhando um segmento onde SW4 é o DR. O tráfego normal entre SW2 e um loopback no SW4 (4.4.4.4) transita por um terceiro roteador, SW3. O teste: manter um ping contínuo do SW2 para 4.4.4.4, depois desconectar fisicamente o link do SW2 para o SW4, e observar o que as próprias LSAs de cada roteador realmente fazem.
Com o link SW2–SW4 configurado no tipo de rede broadcast padrão, desconectá-lo não libera a adjacência imediatamente. O SW2 percebe na hora e reemite seu próprio router-LSA sem a rede compartilhada, e recalcula rápido suas próprias rotas. Mas o router-LSA do SW4 e seu network-LSA para aquele segmento ainda não mudam — o SW4 ainda está esperando seu temporizador dead expirar. Quando o SW4 recalcula sua própria árvore SPF nesse meio tempo, ele precisa verificar o router-LSA do SW2 em busca de um link de volta à rede compartilhada para validar aquela rota; como o novo LSA do SW2 não a lista mais, o SW4 corretamente se recusa a usar aquela rota, mas o segmento só é totalmente removido da topologia quando o próprio temporizador dead do SW4 se esgota.
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 expiresTrocar esse mesmo link SW2–SW4 para o tipo de rede ponto a ponto muda o resultado, não só o tempo. Em um link P2P, puxar o cabo (ou desligar a interface) derruba o vizinho imediatamente nos dois lados — não há relação DR/BDR nem uma camada de network-LSA para esperar. O SW2 para de anunciar o link no instante em que sua própria interface cai; o SW4 faz o mesmo no momento em que sua relação de vizinhança se rompe, porque um router-LSA P2P só carrega a entrada de link que descreve o vizinho enquanto a adjacência está realmente em Full. Nenhum dos lados fica esperando o temporizador dead do outro para que a rede reconvirja completamente.
A lição prática não é «P2P é sempre melhor» — é que o tipo de rede não é apenas um detalhe de configuração, ele muda de fato como uma falha se propaga pelo banco de dados de estado de link, e vale a pena conhecer isso deliberadamente em vez de por acidente quando a velocidade de convergência importa.
Limites honestos desta nota
Esta nota se baseia no fluxo de diagnóstico de estado de vizinhos OSPF do roteador Huawei série AR (display ospf interface / display ospf error / display logbuffer) mais um caso real de convergência multifabricante. Não cobre em profundidade o comportamento específico de NSSA, links virtuais, diferenças do OSPFv3, ou problemas de sumarização de ABR multiárea — cada um tem seus próprios modos de falha que merecem um olhar separado.
Referências
Normas e documentos do fabricante em que esta nota se baseia. A sintaxe dos comandos segue a documentação do fabricante; verifique o comportamento exato na sua versão de firmware.
Vizinho travado e as verificações acima não resolveram?
Conte-nos em qual estado ele está congelado e envie a saída de display ospf interface / display ospf error — ajudamos você a interpretá-la.