Início / Notas técnicas / Configuração básica de OSPF

Configuração básica de OSPF em roteadores empresariais: de área única a multiárea

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

Configuração do zero, não solução de problemas

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.

Plano de áreas: duas etapas do mesmo projeto

Primeiro consolide uma única Area 0 por conta própria — depois estenda uma área stub a partir do único roteador que toca ambas.

Area 0 — Backbone RouterA Router ID 1.1.1.1 LAN 192.168.2.0/24 (direct) 192.168.0.0/24 RouterB — ABR Router ID 2.2.2.2 Area 1 — Stub 192.168.1.0/24 RouterC Router ID 3.3.3.3 Sees only 0.0.0.0/0 from ABR Stage 1: RouterA ↔ RouterB, everything in Area 0. Stage 2: RouterB becomes the ABR and RouterC joins as a stub-area router.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Endereçamento etapa 1 — Area 0 única

Roteador / InterfaceEndereço IPÁrea OSPF
RouterA — Vlanif10192.168.1.1/24Area 0.0.0.0
RouterA — GigabitEthernet3/0/0192.168.0.1/24Area 0.0.0.0
RouterA — LoopBack0 (Router ID)1.1.1.1/32Apenas ID do roteador
RouterB — Vlanif20192.168.2.1/24Area 0.0.0.0
RouterB — GigabitEthernet3/0/0192.168.0.2/24Area 0.0.0.0
RouterB — LoopBack0 (Router ID)2.2.2.2/32Apenas ID do roteador

Endereçamento etapa 2 — Adicionando a Area 1 como área stub

Roteador / InterfaceEndereço IPÁrea OSPF
RouterA — GigabitEthernet1/0/0192.168.2.1/24Fora do OSPF — importada via import-route direct
RouterA — GigabitEthernet2/0/0192.168.0.1/24Area 0.0.0.0
RouterB (ABR) — GigabitEthernet2/0/0192.168.0.2/24Area 0.0.0.0
RouterB (ABR) — GigabitEthernet1/0/0192.168.1.2/24Area 0.0.0.1 — stub
RouterC — GigabitEthernet1/0/0192.168.1.1/24Area 0.0.0.1 — stub

Configuração passo a passo

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.

  1. Atribua a cada roteador um ID de roteador exclusivo — configure um endereço LoopBack0 e use-o como ID do roteador; essa identidade precisa ser exclusiva em todo o domínio OSPF antes que qualquer outra coisa funcione corretamente.
  2. Primeiro coloque em funcionamento o menor projeto viável: dois roteadores, um processo, tudo na Area 0 — anuncie a rede de cada interface com o comando network sob area 0.0.0.0 e confirme que o vizinho se forma antes de adicionar uma segunda área.
  3. Quando a rede cresce além de um único prédio ou um único link, identifique qual roteador toca tanto a Area 0 quanto a nova área — esse roteador se torna o ABR, e isso é um fato de topologia mais do que uma escolha.
  4. No ABR, adicione a instrução network da nova área e marque-a como stub se os roteadores atrás dela só precisarem de uma rota padrão de saída, não da tabela de roteamento completa do backbone.
  5. Configure a mesma palavra-chave stub sob essa área em todos os roteadores dentro dela, incluindo o ABR — uma incompatibilidade do atributo stub entre roteadores que compartilham uma área é um erro de configuração silencioso, não apenas um recurso ausente.
  6. Em qualquer segmento broadcast (multiacesso) com mais de um roteador OSPF — Ethernet, VLANIF — decida a prioridade DR deliberadamente com o comando de interface ospf dr-priority em vez de deixar a eleição padrão para o roteador que simplesmente subiu primeiro.

Etapa 1 — RouterA: Area 0 única

#
 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
#

Etapa 1 — RouterB: Area 0 única

#
 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
#

Etapa 2 — Evoluindo para um backbone mais uma área stub

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.

RouterA — borda da Area 0, com uma LAN conectada diretamente

#
 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
#

RouterB — o ABR, Area 0 e Area 1 stub

#
 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
#

RouterC — dentro da área 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.

Projetos de soluções relacionados

Como confirmar cada etapa antes de adicionar a próxima

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.

  1. Após a etapa 1, execute display ospf peer brief em RouterA e RouterB — o estado do vizinho deve mostrar Full antes de avançar para uma segunda área.
  2. Após a etapa 2, execute display ospf peer brief no RouterB (o ABR) — ele deve mostrar duas relações Full independentes, uma na Area 0.0.0.0 e outra na Area 0.0.0.1.
  3. No RouterC, execute display ip routing-table — em vez de cada rota individual da Area 0, ele deve carregar uma única rota padrão (0.0.0.0/0) injetada pelo ABR, além de suas próprias rotas intra-área.
  4. Em qualquer segmento broadcast com mais de um roteador, confirme qual roteador realmente se tornou DR — deve ser aquele ao qual você deliberadamente deu o dr-priority mais alto, não simplesmente o que subiu primeiro.
<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.

4 armadilhas de configuração

As que transformam uma área única funcional em um projeto multiárea que só funciona pela metade.

1. A prioridade DR é 1 em todo lugar por padrão — ninguém vence de propósito

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.

2. Uma área stub precisa que todos os roteadores concordem, não apenas o ABR

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.

3. O comando network se baseia na máscara curinga, não na máscara de sub-rede

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.

4. Colisões de ID de roteador parecem um vizinho inativo, não um problema de nomenclatura

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.

Limites honestos desta nota

Limites honestos desta nota

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.

Cinco perguntas que merecem uma resposta

Extraídas dos mesmos casos de configuração nos quais esta nota se baseia.

Preciso de várias áreas desde o primeiro dia, ou posso começar com tudo na Area 0?

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 que decide qual roteador deve ser o ABR?

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.

Por que o roteador da área stub só recebe uma rota padrão em vez das rotas reais do backbone?

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.

Em que isso difere da sua nota de solução de problemas de vizinhos OSPF?

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.

A prioridade DR importa em links ponto a ponto?

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.

E se as duas pontas de uma adjacência forem Huawei e um roteador de outro fornecedor?

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.

Está planejando uma implantação de OSPF além de uma única área?

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.

WhatsApp com um engenheiro →

Leituras relacionadas

Usamos cookies apenas para análises anônimas — sem anúncios, sem rastreamento entre sites.Política de privacidade