Início / Notas técnicas / Solução de problemas de vizinhos OSPF

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 Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · 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 parameter

Travado 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 cause

5 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 output

2. 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 1500

3. 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.2

5. 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 md5

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 expires

Trocar 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

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.

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.

WhatsApp com um engenheiro →