Dois roteadores, o mesmo link rompido, a mesma área OSPF — e a apenas uma configuração de tipo de rede de uma diferença de quarenta segundos em quanto tempo o resto da rede leva para perceber. Aqui está o que realmente acontece dentro do banco de dados de estado de link em cada tipo de rede, um failover real de quatro roteadores com a saída LSA real, e os comandos para verificar qual você está realmente executando.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O tipo de rede geralmente é escolhido por razões de adjacência — correspondência de sub-rede, elegibilidade de DR — mas ele decide silenciosamente, com antecedência, quão rápido a rede percebe um link morto.
Duas interfaces OSPF podem alcançar Full usando o tipo de rede Broadcast ou Ponto a Ponto — a adjacência em si não se importa com qual você escolheu. O que importa é o momento em que esse link realmente falha. Em um segmento Broadcast, a falha precisa passar por um Roteador Designado e um network-LSA que só o DR controla. Em um link ponto a ponto, não há DR, não há network-LSA, e nada esperando o temporizador de outra parte. Mesma falha, mesmo protocolo, dois caminhos de recuperação diferentes.
Esta nota trata estritamente dessa lacuna: o que realmente acontece no banco de dados de estado de link de cada roteador quando o link cai, um caso real de quatro roteadores com a saída LSA de ambos os lados da mesma falha, a sobrecarga de DR/BDR que só os segmentos broadcast carregam, e os comandos para verificar qual tipo de rede um segmento está realmente executando antes que isso se torne o motivo de um failover ter demorado mais do que deveria. Para o fluxo da máquina de estados de vizinhos quando uma adjacência não se forma de jeito nenhum, veja OSPF Neighbor Troubleshooting; para onde os padrões de tipo de rede e o comportamento de DR/BDR diferem entre fabricantes, veja a nota Huawei-Cisco OSPF Interop.
Mesmo evento físico, mesma área OSPF — o diagrama abaixo mostra o que cada roteador realmente precisa fazer, e quanto tempo isso leva.
Broadcast em cima, Ponto a Ponto embaixo. A estrutura DR/BDR que o broadcast introduz é exatamente a parte da linha do tempo que o ponto a ponto pula por completo.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
A diferença não está em o roteador perceber ou não uma falha — está em quais estruturas precisam mudar antes que o resto da rede possa agir a respeito.
Em um link ponto a ponto, os dois roteadores conectados trocam apenas router-LSAs, e cada um carrega uma entrada de link que descreve o vizinho diretamente — mais uma entrada stub-network separada para a própria interface. Essa entrada que descreve o vizinho só existe enquanto a adjacência está realmente em Full. No momento em que a interface cai, o roteador que a possui para de carregar essa entrada em seu próximo router-LSA. Nada mais precisa mudar antes.
Em um segmento broadcast, a mesma falha física precisa se refletir em duas estruturas separadas: o próprio router-LSA de cada roteador (uma entrada Transit Network apontando para o DR do segmento), e um network-LSA separado que só o DR origina, listando cada roteador conectado ainda considerado Full. Um roteador não-DR que perde seu link pode atualizar seu próprio router-LSA imediatamente e recalcular suas próprias rotas rápido. Mas o network-LSA — e a própria entrada do router-LSA do DR para aquele segmento — não mudam até que o próprio DR perceba que o vizinho sumiu, o que em um segmento compartilhado significa esperar seu próprio temporizador dead para aquele vizinho expirar, não a interface cair.
<Huawei> display ospf lsdb router
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 2.2.2.2 2.2.2.2 12 48 8000001C 0
// P2P: this router-LSA carries the neighbor link only while the adjacency is Full
<Huawei> display ospf lsdb network
Type LinkState ID AdvRouter Age Len Sequence Metric
Network 1.1.24.4 4.4.4.4 23 32 80000001 0
// Broadcast only: originated solely by the DR -- absent entirely on a P2P segmentA eleição de DR/BDR existe para impedir que cada roteador em um segmento de acesso múltiplo forme uma malha completa de adjacências com todos os outros roteadores nele — em vez disso, todos formam adjacência apenas com o DR e o BDR. Esse é um ganho real de eficiência quando um segmento realmente tem vários roteadores. Mas também significa que a própria existência do segmento no banco de dados de estado de link agora depende da visão de um roteador específico: enquanto o próprio DR não tiver declarado um vizinho morto, o resto da rede precisa assumir que a topologia do segmento não mudou, mesmo que o link de um roteador conectado a ele claramente tenha mudado. Um link ponto a ponto pula isso completamente — não há DR, nada para eleger, e nada que precise esperar o temporizador de terceiros antes que o resto da rede possa confiar na atualização.
<Huawei> display ospf interface GigabitEthernet1/0/0
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
1.1.24.4 Broadcast DR 1 1 1.1.24.4 1.1.24.2
// forcing point-to-point removes DR/BDR from the picture entirely
[Huawei-GigabitEthernet1/0/0] ospf network-type p2pSINTOMAUm link que na verdade é só dois roteadores em um segmento dedicado ainda demora o caminho longo para reconvergir após uma falha, como se fosse uma grande LAN de acesso múltiplo.
CAUSAO tipo de rede padrão em interfaces Ethernet é Broadcast, não importa quantos roteadores realmente compartilhem o segmento. Um segmento com exatamente dois roteadores ainda elege um DR e um BDR, ainda constrói um network-LSA, e a remoção desse network-LSA ainda fica condicionada ao próprio temporizador dead do DR — mesmo que nunca tenha existido um terceiro roteador que precisasse do mecanismo DR/BDR.
SOLUÇÃOSe um segmento é dedicado a exatamente dois roteadores e sempre será, configure deliberadamente os dois lados como ponto a ponto com ospf network-type p2p, em vez de aceitar o broadcast padrão por omissão.
SINTOMAA convergência parece assimétrica — o roteador que realmente perdeu o link recalcula rotas quase imediatamente, mas o resto da rede só reconverge totalmente cerca de um intervalo de temporizador dead depois.
CAUSAQuando o link com falha pertence a um roteador não-DR, esse roteador atualiza seu próprio router-LSA imediatamente. Mas o network-LSA do segmento só é originado pelo DR, e o DR não sabe que o vizinho sumiu até que seu próprio temporizador dead para aquele vizinho expire — ele não está observando a interface que falhou, está observando a adjacência que mantém com aquele vizinho.
SOLUÇÃOAntes de tratar uma reconvergência que parece travada como uma falha, verifique qual roteador é o DR do segmento afetado com display ospf interface — se for o próprio temporizador dead do DR se esgotando, isso é comportamento esperado de um segmento broadcast, não um bug.
SINTOMADepois de mudar um link para o tipo de rede ponto a ponto, alguém verifica a LSDB esperando os mesmos tipos de LSA de antes, e presume que algo quebrou porque o network-LSA daquele segmento simplesmente sumiu.
CAUSAUm router-LSA P2P ainda carrega uma entrada de link descrevendo o vizinho — só que faz isso diretamente, como parte do próprio router-LSA de cada roteador, em vez de por meio de um network-LSA compartilhado. Nunca existiu um network-LSA separado para procurar assim que o link é P2P.
SOLUÇÃOVerifique display ospf lsdb nos dois lados — espere duas entradas do tipo Router com links no estilo ponto a ponto, e confirme que não há entrada do tipo Network para aquele segmento; essa ausência é correta para P2P, não um sintoma de problema.
SINTOMANo momento em que ospf network-type p2p é aplicado em um lado, a relação de vizinhança cai imediatamente, mesmo que nada tenha mudado fisicamente no próprio link.
CAUSAO tipo de rede é um dos parâmetros que precisam coincidir entre dois vizinhos OSPF para que a adjacência se mantenha. Mudá-lo em um lado sem o outro cria uma incompatibilidade imediata, e mesmo mudando os dois lados juntos, isso força a máquina de estados a reiniciar, já que o status de DR/BDR e os tipos de LSA envolvidos mudam ao mesmo tempo.
SOLUÇÃOAplique a mudança nos dois lados dentro da mesma janela de manutenção, e reverifique com display ospf interface e display ospf peer verbose logo em seguida.
SINTOMAApós um failover, uma atualização de LSA esperada nunca aparece na própria LSDB de um vizinho, e parece que o próprio mecanismo de convergência falhou.
CAUSAO comando ospf filter-lsa-out (all / summary / ase / nssa) é uma otimização legítima para reduzir inundações desnecessárias de LSA em uma interface de saída específica — muitas vezes implantada deliberadamente para reduzir o tamanho da LSDB e melhorar a velocidade de convergência quando existem múltiplos links paralelos entre dois roteadores. Se alguém a configurou antes e isso foi esquecido, um tipo de LSA filtrado que simplesmente nunca chega parece exatamente uma convergência travada.
SOLUÇÃOAntes de tratar uma atualização de LSA ausente como uma falha, verifique display current-configuration interface em busca de uma instrução ospf filter-lsa-out na interface em questão.
O mesmo teste físico, realizado duas vezes — uma com o tipo de rede padrão, outra forçado para ponto a ponto — torna a diferença concreta em vez de teórica.
A rede: quatro roteadores rodando OSPF area 0. SW2 e SW4 compartilham um segmento, com SW4 atuando como 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 LSAs de cada roteador realmente fazem em cada tipo de rede.
Com o link SW2–SW4 deixado 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, depois recalcula suas próprias rotas rápido. O router-LSA do SW4 e seu network-LSA para aquele segmento ainda não mudam — o SW4 ainda está contando regressivamente seu próprio temporizador dead para o vizinho que perdeu. A saída de show ip ospf nei abaixo foi capturada no meio da contagem regressiva, antes de o temporizador se esgotar:
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
// remaining dead-time counting down out of a 40-second interval -- the wait is real, not a display artifact
SW4#show ip ospf database network self-originate
OSPF Router with ID (4.4.4.4) (Process ID 100)
Net Link States (Area 0)
Link State ID: 1.1.24.4 (address of Designated Router)
Attached Router: 4.4.4.4
Attached Router: 2.2.2.2
// still lists SW2 as attached -- SW4 hasn't yet noticed the neighbor is gone
// once 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
// the segment only flips from Transit to Stub -- and the network-lsa is only withdrawn -- once the dead timer runs outTrocar 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 não há relação DR/BDR nem nenhuma 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 totalmente — toda a espera visível no traço broadcast acima simplesmente não existe em ponto a ponto.
A lição prática não é «P2P é sempre melhor» — um link P2P de qualquer forma não pode atender um segmento com três ou mais roteadores. É que o tipo de rede não é apenas um detalhe de configuração decidido no momento da formação da adjacência: ele decide de antemão como uma falha realmente se propaga pelo banco de dados de estado de link, e vale a pena configurá-lo deliberadamente — com display ospf interface confirmado nos dois lados — em vez de descobri-lo por acidente durante uma interrupção quando a velocidade de convergência realmente importa.
Esta nota se baseia em um caso real de convergência OSPF de quatro roteadores, usando a saída show original do material fonte, além da mecânica padrão de LSA Broadcast/P2P descrita na própria referência de filtragem de LSA OSPF da Huawei. Não cobre os tipos de rede NBMA ou P2MP, OSPFv3, detecção de falha acelerada por BFD, ou como esses números mudam em um segmento protegido com autenticação — cada um merece um olhar separado.
As perguntas que surgem sempre que essa lacuna de convergência está realmente em discussão.
Não à seleção de caminho em condições normais — o custo é definido independentemente do tipo de rede. O que muda é inteiramente sobre o caminho de falha: quais estruturas LSA precisam ser reconstruídas, e o temporizador de quem o resto da rede está esperando quando o link realmente cai.
A espera está ligada a qual roteador está atuando como DR daquele segmento, porque só o DR origina o network-LSA. Se o lado com falha é DR-Other nos dois lados, o DR do segmento é um terceiro roteador que precisa notar a perda do vizinho através do seu próprio temporizador dead — o mecanismo é o mesmo, só que condicionado pelo temporizador de outro roteador, não necessariamente aquele cujo link fisicamente falhou.
Só se o roteador que sai é o próprio DR ou BDR. Se o link de um roteador que não é DR nem BDR falha, não há reeleição alguma — o DR e o BDR existentes simplesmente atualizam o network-LSA para remover aquele roteador assim que seu próprio temporizador dead expira. A reeleição só acontece quando o próprio DR ou BDR é quem cai.
Não — ponto a ponto é especificamente para um link que conecta exatamente dois roteadores sem nenhum outro vizinho compartilhando aquele segmento. Uma LAN de acesso múltiplo com três ou mais roteadores OSPF precisa rodar Broadcast (ou NBMA), porque ponto a ponto não tem mecanismo algum para mais de um vizinho por interface.
Esta nota assume que a adjacência já funciona e trata do que acontece a uma adjacência funcional quando seu link falha. Para o fluxo completo de diagnóstico da máquina de estados — de Down a Init, 2-Way, ExStart, Exchange, Loading até Full — veja OSPF Neighbor Troubleshooting.
Envie-nos a saída de display ospf interface dos dois lados — diremos o que acontece com aquele segmento assim que o link cair.