Uma rede construída do zero, não uma rede já com falhas — ID do roteador e endereçamento de interfaces, ativando o OSPF em uma única Area 0, depois crescendo para um backbone mais uma área stub com um ABR à medida que a rede se expande, prioridade DR em segmentos compartilhados, e os comandos de verificação que confirmam cada etapa antes de adicionar a próxima.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
A maioria dos conteúdos sobre OSPF pressupõe que o OSPF já está em funcionamento e que algo está errado. Esta nota não pressupõe nenhuma das duas coisas — um núcleo roteado que ainda não existe, planejado e construído área por área.
Uma implantação de OSPF também costuma não começar sua vida como uma única área plana. Começa com um roteador, depois dois, depois um caminho redundante entre dois prédios, depois uma filial que não deveria ver todas as rotas da matriz. Configurar o OSPF corretamente em cada uma dessas etapas — não apenas fazer uma relação de vizinhança subir uma vez e torcer para que se mantenha — é um problema diferente de solucionar um que já existe.
Esta nota começa com a menor rede OSPF funcional: dois roteadores, uma área, compartilhando rotas. Em seguida, expande o mesmo projeto para duas áreas — uma Area 0 de backbone e uma Area 1 stub na borda da rede, o ponto até onde a maioria dos projetos OSPF empresariais realmente precisa chegar. Se uma relação de vizinhança se recusa a subir na sua própria rede, nossa nota de solução de problemas da máquina de estados de vizinhos OSPF trata disso separadamente; se as duas pontas forem de fornecedores diferentes, veja nossa nota de interoperabilidade OSPF Huawei-Cisco para as armadilhas de DR/BDR e temporizadores específicas dessa combinação.
Primeiro consolide uma única Area 0 por conta própria — depois estenda uma área stub a partir do único roteador que toca ambas.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Endereçamento etapa 1 — Area 0 única
| Roteador / Interface | Endereço IP | Área OSPF |
|---|---|---|
| RouterA — Vlanif10 | 192.168.1.1/24 | Area 0.0.0.0 |
| RouterA — GigabitEthernet3/0/0 | 192.168.0.1/24 | Area 0.0.0.0 |
| RouterA — LoopBack0 (Router ID) | 1.1.1.1/32 | Apenas ID do roteador |
| RouterB — Vlanif20 | 192.168.2.1/24 | Area 0.0.0.0 |
| RouterB — GigabitEthernet3/0/0 | 192.168.0.2/24 | Area 0.0.0.0 |
| RouterB — LoopBack0 (Router ID) | 2.2.2.2/32 | Apenas ID do roteador |
Endereçamento etapa 2 — Adicionando a Area 1 como área stub
| Roteador / Interface | Endereço IP | Área OSPF |
|---|---|---|
| RouterA — GigabitEthernet1/0/0 | 192.168.2.1/24 | Fora do OSPF — importada via import-route direct |
| RouterA — GigabitEthernet2/0/0 | 192.168.0.1/24 | Area 0.0.0.0 |
| RouterB (ABR) — GigabitEthernet2/0/0 | 192.168.0.2/24 | Area 0.0.0.0 |
| RouterB (ABR) — GigabitEthernet1/0/0 | 192.168.1.2/24 | Area 0.0.0.1 — stub |
| RouterC — GigabitEthernet1/0/0 | 192.168.1.1/24 | Area 0.0.0.1 — stub |
Seis passos: ID do roteador e endereçamento, uma única área funcionando, decidir o ABR, adicionar a área stub, igualar o atributo stub em todos os roteadores que precisam dele, e prioridade DR em segmentos compartilhados.
#
sysname RouterA
#
router id 1.1.1.1
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Ethernet2/0/0
port link-type trunk
port trunk allow-pass vlan 10
#
interface GigabitEthernet3/0/0
ip address 192.168.0.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
#
sysname RouterB
#
router id 2.2.2.2
#
vlan batch 20
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Ethernet2/0/0
port link-type trunk
port trunk allow-pass vlan 20
#
interface GigabitEthernet3/0/0
ip address 192.168.0.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
Uma rede diferente e maior ilustra a próxima etapa: o RouterB se torna o ABR entre a Area 0 e uma nova Area 1, e a Area 1 é marcada como stub para que o RouterC só precise de uma rota padrão para alcançar tudo atrás do backbone.
#
sysname RouterA
#
router id 1.1.1.1
#
interface GigabitEthernet1/0/0
ip address 192.168.2.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 192.168.0.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 2
import-route direct
area 0.0.0.0
network 192.168.0.0 0.0.0.255
#
#
sysname RouterB
#
router id 2.2.2.2
#
interface GigabitEthernet1/0/0
ip address 192.168.1.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 192.168.0.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
#
#
sysname RouterC
#
router id 3.3.3.3
#
interface GigabitEthernet1/0/0
ip address 192.168.1.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 2
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
#
A LAN do RouterA em GigabitEthernet1/0/0 é deliberadamente deixada de fora da instrução network do OSPF e importada com import-route direct — um padrão comum para um segmento conectado localmente que não precisa de sua própria adjacência OSPF.
Primeiro estado Full no par de área única, depois estado Full em ambos os lados do ABR, e então uma tabela de roteamento no roteador da área stub visivelmente mais curta que a do backbone.
<RouterA> display ospf peer brief
OSPF Process 2 with Router ID 1.1.1.1
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet3/0/0 2.2.2.2 Full
----------------------------------------------------------------------------
Total Peer(s): 1
<RouterB> display ospf peer brief
OSPF Process 2 with Router ID 2.2.2.2
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet2/0/0 1.1.1.1 Full
0.0.0.1 GigabitEthernet1/0/0 3.3.3.3 Full
----------------------------------------------------------------------------
Total Peer(s): 2
<RouterC> display ip routing-table
Destinations : 2 Routes : 2
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 O_ASE 150 1 192.168.1.2 GigabitEthernet1/0/0
192.168.1.0/24 Direct 0 0 192.168.1.1 GigabitEthernet1/0/0
A tabela de roteamento do RouterC permanece curta de propósito — esse é todo o sentido de marcar a Area 1 como stub; ela nunca recebe as rotas externas ou inter-área individuais que uma área comum carregaria.
As que transformam uma área única funcional em um projeto multiárea que só funciona pela metade.
SINTOMAEm um segmento Ethernet ou VLANIF compartilhado com três ou mais roteadores OSPF, o DR acaba sendo o roteador que você menos queria — muitas vezes simplesmente aquele cuja interface subiu primeiro.
CAUSAToda interface com OSPF habilitado começa com prioridade DR 1 por padrão. Quando as prioridades empatam, vence o roteador com o ID de roteador mais alto — o que não tem nada a ver com qual roteador realmente tem o melhor hardware ou posicionamento para ser DR.
SOLUÇÃODefina explicitamente ospf dr-priority em cada interface do segmento — um valor mais alto no roteador que você deseja como DR, prioridade 0 em qualquer roteador que nunca deva se tornar DR ou BDR.
SINTOMAUm roteador na borda do que deveria ser uma área stub não forma nenhuma adjacência, ou a área não se comporta como stub — rotas externas completas ainda aparecem em algum lugar dentro dela.
CAUSAO atributo stub é negociado nos sinalizadores de opções do pacote Hello. Se o ABR estiver configurado como stub, mas um roteador dentro dessa área não estiver (ou vice-versa), essa incompatibilidade sozinha já basta para bloquear a adjacência — não é uma configuração que um único roteador possa sustentar para toda a área.
SOLUÇÃOConfigure a palavra-chave stub sob essa área em cada um dos roteadores dentro dela, incluindo o ABR. A mesma regra se aplica ao NSSA — é um requisito de correspondência, não opcional, para cada roteador que compartilha essa área.
SINTOMAUma interface que claramente deveria pertencer a uma área OSPF nunca estabelece um vizinho, ou uma interface que não deveria rodar OSPF de forma alguma acaba sendo anunciada.
CAUSAO comando network sob uma área OSPF usa uma máscara curinga, não uma máscara de sub-rede — network 192.168.0.0 0.0.0.255 corresponde à faixa 192.168.0.0/24, mas um erro de digitação aqui (um bit a mais ou a menos) muda silenciosamente quais interfaces são incluídas na área.
SOLUÇÃOVerifique novamente o cálculo da máscara curinga em relação ao endereço real da interface, e confirme com display ospf interface quais interfaces o processo realmente pegou — não confie apenas na configuração como foi digitada.
SINTOMAUm roteador recém-adicionado não forma adjacência com ninguém em uma rede OSPF existente, apesar das interfaces alcançáveis e da configuração parecer correta em ambos os lados.
CAUSASe o ID de roteador do novo roteador colidir com um já ativo em outro lugar do domínio OSPF — fácil de acontecer com IDs de roteador selecionados automaticamente ou configurações copiadas e coladas — o domínio vê um conflito em vez de um segundo roteador utilizável.
SOLUÇÃOAtribua o ID do roteador explicitamente com router id sob o processo OSPF, vinculado a um endereço LoopBack0 estável — nunca deixe para a seleção automática a partir de um endereço de interface física que possa mudar ou já esteja em uso em outro lugar.
Esta nota é baseada em duas configurações concretas: uma rede de dois roteadores com uma única Area 0, e um projeto de três roteadores com um ABR e uma Area 1 stub. Ela não explica o NSSA por completo (uma variante próxima, descrita brevemente acima), os links virtuais OSPF através de uma área de trânsito, a agregação de rotas no ABR, nem a autenticação OSPF — todos passos seguintes razoáveis assim que o projeto multiárea básico estiver em vigor. Também não cobre o que acontece quando roteadores adjacentes são de fornecedores diferentes — veja nossa nota de interoperabilidade OSPF Huawei-Cisco para isso, ou nossa nota de solução de problemas de vizinhos OSPF se uma adjacência na sua própria rede se recusar a subir.
Extraídas dos mesmos casos de configuração nos quais esta nota se baseia.
Comece de forma plana. Uma única Area 0 é o projeto correto até que a rede realmente cresça além do que uma área consegue lidar confortavelmente — áreas extras adicionam planejamento de ABR e decisões stub/NSSA que você ainda não precisa. Adicione a Area 1 (ou mais) quando houver uma fronteira genuína a traçar: uma filial, um bloco de data center, ou um link onde você queira ocultar informações detalhadas de roteamento em vez de deixar tudo passar.
O ABR é simplesmente o roteador que toca fisicamente tanto a Area 0 quanto a nova área — é um fato de topologia mais do que uma escolha. O que é uma escolha é o que você configura nele: se a área atrás dele permanece uma área comum, se torna uma área stub, ou se torna um NSSA, dependendo de essa área precisar originar suas próprias rotas externas.
Esse é todo o propósito de uma área stub — o ABR substitui cada LSA externa (Tipo 5) que de outra forma inundaria nessa área por uma única rota padrão, reduzindo a tabela de roteamento e a inundação de LSA que um pequeno roteador de borda precisa suportar. Se esse roteador de borda também precisar originar suas próprias rotas externas na área, o NSSA é a variante construída para isso.
Aquela nota pressupõe que uma rede OSPF já existe e que uma relação de vizinhança está travada ou instável — ela lê a máquina de estados de vizinhos para descobrir o porquê. Esta nota não pressupõe que nada exista ainda: é a configuração que leva você a uma relação de vizinhança funcional e a um projeto multiárea funcional desde o início.
Não — a eleição de DR/BDR é um conceito de rede broadcast (multiacesso). Interfaces do tipo ponto a ponto não têm nenhum DR para eleger, então o dr-priority não tem nada sobre o que atuar ali; ele só importa em segmentos broadcast do tipo Ethernet/VLANIF com mais de um roteador OSPF conectado.
A lógica de áreas, network e stub aqui é um comportamento de OSPF neutro em relação ao fornecedor, mas os temporizadores padrão, a elegibilidade de DR em certos tipos de interface e o cálculo de custo podem diferir o suficiente entre fornecedores para impedir que um projeto que funciona dentro de um fornecedor funcione entre fornecedores. Veja nossa nota de interoperabilidade OSPF Huawei-Cisco para os padrões específicos que não coincidem de fábrica.
Diga-nos quantos sites, quantos roteadores, e onde você espera que caiam os limites das áreas, e ajudaremos você a planejar o projeto de áreas e o posicionamento do ABR.