OSPF — Open Shortest Path First
Do fundamento ao nível especialista — o IGP link-state mais usado em backbone de ISP, com boas práticas reais de operadoras brasileiras e o padrão internacional por trás de cada decisão de projeto.
Nesta página
1. Nível Básico — Fundamentos Básico
Pré-requisito: nenhum além de entender endereço IP e o conceito geral de rota. Se você já leu a página de BGP, vai reconhecer a distinção IGP/EGP da seção 1.2 de lá.
1.1 O que é OSPF
OSPF (Open Shortest Path First) é um protocolo de roteamento interno (IGP — roteia dentro de um único Sistema Autônomo, ao contrário do BGP) da família link-state. "Open" porque é um padrão aberto, não proprietário — publicado pela IETF, hoje na versão 2 pra IPv4 (RFC 2328) e versão 3 pra IPv6 (RFC 5340). "Shortest Path First" porque usa o algoritmo de Dijkstra pra calcular o caminho de menor custo até cada destino.
1.2 Link-state vs. distance-vector
Existem duas famílias de protocolo de roteamento dinâmico interno:
- Distance-vector (ex: RIP) — cada roteador só conhece "distância" (número de saltos) até cada destino, informada por vizinhos diretos, sem mapa real da topologia. Convergência lenta, prevenção de loop frágil (depende de mecanismos como split-horizon e holddown timers), limite de 15 saltos no RIP.
- Link-state (OSPF, IS-IS) — cada roteador monta um mapa completo da topologia daquela área, através da troca de anúncios de estado de enlace (LSA). A partir desse mapa, cada roteador calcula independentemente a árvore de caminhos mais curtos (SPT) com o algoritmo de Dijkstra. Convergência muito mais rápida, sem limite prático de diâmetro de rede, e prevenção de loop naturalmente mais robusta — o roteador conhece a topologia inteira, não confia em "boato" de vizinho.
Analogia: distance-vector é como perguntar pra cada vizinho "quantas casas até o mercado?" e confiar na resposta. Link-state é como ter o mapa completo do bairro e calcular você mesmo a rota mais curta.
1.3 Vizinhança e adjacência
Antes de trocar qualquer informação de rota, dois roteadores OSPF precisam formar uma adjacência — um processo com pré-requisitos verificados (mesma área, mesma máscara de sub-rede, mesmos timers Hello/Dead, mesma autenticação, se configurada). Só depois de adjacentes é que trocam LSAs. Isso é bem diferente do RIP, que nem tem conceito real de vizinhança — só transmite a tabela de rotas periodicamente pra quem estiver ouvindo.
1.4 Custo (métrica) e banda de referência
A métrica do OSPF é o Cost, calculado por padrão como:
⚠️ Isso já é o primeiro erro clássico de projeto — ver seção 4 (boas práticas), item da banda de referência.
1.5 Quando usar OSPF (e quando não)
OSPF roteia o interior do seu AS — links internos, loopbacks dos roteadores, conectividade pra sessões iBGP. Rotas de clientes e rotas externas (trânsito, peering) são responsabilidade do BGP, não do OSPF — misturar as duas coisas é o erro de projeto mais citado por operadores experientes (ver seção 4.1).
2. Nível Intermediário — O protocolo em detalhe Intermediário
Pré-requisito: seção 1.
2.1 Tipos de LSA
| Tipo | Nome | Origem / Escopo |
|---|---|---|
| Type 1 | Router LSA | Todo roteador — descreve suas interfaces e vizinhos. Só dentro da área. |
| Type 2 | Network LSA | Gerado só pelo DR de cada rede broadcast/NBMA. Só dentro da área. |
| Type 3 | Summary LSA | Gerado pelo ABR — resume redes de uma área pro backbone (e vice-versa) |
| Type 4 | Summary ASBR LSA | Gerado pelo ABR — informa como alcançar um ASBR de outra área |
| Type 5 | AS External LSA | Gerado pelo ASBR — rota redistribuída de outro protocolo/domínio. Inunda todo o AS (exceto áreas Stub/NSSA) |
| Type 7 | NSSA External LSA | Gerado por ASBR dentro de área NSSA — convertido em Type 5 pelo ABR ao sair da área |
2.2 Tipos de rede OSPF (Network Types)
| Tipo | DR/BDR? | Uso típico |
|---|---|---|
| Broadcast | Sim, obrigatório | Padrão em interface Ethernet — mas só faz sentido de verdade quando 3+ roteadores dividem a mesma sub-rede |
| Point-to-point | Não | Enlace que conecta exatamente 2 roteadores — mesmo sendo Ethernet/fibra, forçar esse tipo tem benefício real (ver seção 4) |
| NBMA | Depende do modo | Legado (Frame Relay, ATM, X.25) — irrelevante em rede 100% Ethernet/fibra |
2.3 DR e BDR
Em redes do tipo Broadcast/NBMA com múltiplos roteadores, formar adjacência completa entre todos (full-mesh) geraria tráfego de LSA excessivo. O OSPF elege um DR (Designated Router) — e um BDR (Backup) — pra centralizar a distribuição de LSA naquele segmento: os demais roteadores formam adjacência completa só com o DR/BDR, não uns com os outros. Eleição por prioridade configurável (maior vence), desempate pelo maior Router ID.
2.4 Tipos de roteador
| Tipo | Definição |
|---|---|
| Interno | Todas as interfaces na mesma área |
| Backbone | Roteador interno, mas todas as interfaces na Área 0 |
| ABR | Area Border Router — pelo menos 1 interface na Área 0 e 1+ em outra(s) área(s) |
| ASBR | Autonomous System Boundary Router — redistribui rotas externas (outro protocolo/domínio) pro OSPF |
Nota importante: no OSPF, área é definida por interface, não por roteador inteiro (diferente do IS-IS) — um mesmo roteador pode ter interfaces em áreas diferentes simultaneamente (é exatamente o que faz dele um ABR).
3. Nível Avançado — Áreas especiais e projeto Avançado
Pré-requisito: seções 1 e 2.
3.1 Tipos de área — tabela completa
| Tipo | LSAs bloqueados | Quando usar |
|---|---|---|
| Regular | Nenhum | Padrão — todos os LSAs permitidos |
| Stub | Type 5 | Roteador de borda remota, 1 único link pro resto da rede, muitas rotas externas na Área 0 que não precisam entrar ali (recebe rota default do ABR) |
| NSSA | Type 5 (usa Type 7 internamente) | Igual Stub, mas a área precisa ter seu próprio ASBR redistribuindo rota externa local |
| Totally Stubby | Type 3, 4 e 5 | Igual Stub, mas ainda mais agressivo — só rota default entra, nem resumo de outras áreas |
| Totally NSSA | Type 3 e 5 (usa Type 7 internamente) | Combinação das duas restrições acima |
Área Backbone (Área 0) nunca pode ser Stub/NSSA/Totally — é sempre Regular por definição, e toda outra área precisa se conectar diretamente a ela (exceto via Virtual Link, ver 3.3).
3.2 Sumarização de rotas — só no ABR e no ASBR
Diferente de protocolos mais flexíveis, o OSPF só permite sumarizar rota em dois pontos específicos: no ABR (sumarização de rotas nativas de uma área ao gerar o Type 3 pra Área 0) e no ASBR (sumarização de rotas externas no momento da redistribuição). Não existe sumarização "dentro" da própria área de origem — o Type 3 já é, por definição, um resumo saindo daquela área. Isso significa: com uma única área OSPF (single-area), sumarização de rotas nativas simplesmente não é possível — só existe ABR em projeto com 2+ áreas.
3.3 Virtual Links — evite se possível
Todo projeto multi-área exige que toda área se conecte diretamente à Área 0. Quando isso não é fisicamente viável (ex: fusão de duas redes OSPF distintas, cada uma com sua própria Área 0), o Virtual Link permite "estender" o backbone através de uma área intermediária. Funciona, mas adiciona complexidade e fragilidade ao projeto — a recomendação amplamente compartilhada por operadores experientes é desenhar a topologia física de forma que Virtual Link nunca seja necessário, em vez de usá-lo como solução permanente.
3.4 OSPF em L3VPN MPLS (relação PE-CE) — cuidado com o "Backdoor Link"
Quando um cliente usa OSPF na relação PE-CE de uma L3VPN MPLS, rotas redistribuídas do BGP pro OSPF do cliente viram Inter-Area (Type 3), não External (Type 5) — isso evita problema em sites remotos configurados como área Stub. Mas cria uma armadilha real: a ordem de preferência do OSPF é Intra-Area > Inter-Area > External, independente do custo configurado.
Cenário real do "OSPF Backdoor Link": cliente tem link de 1 Gbps via L3VPN MPLS (operadora A) e link de 100 Mbps comum, não-MPLS, direto com outro site (operadora B) estendendo a mesma área OSPF.
A rota aprendida pelo link de 100 Mbps é Intra-Area; a rota aprendida pelo link MPLS de 1 Gbps é Inter-Area. Mesmo sendo 10x mais lento, o OSPF escolhe o link de 100 Mbps — porque Intra-Area sempre vence, não importa o custo. Correção: recurso OSPF Sham-Link, que faz o caminho MPLS parecer Intra-Area também.
3.5 OSPFv3 (IPv6) — mesma lógica, transporte diferente
RFC 5340 adapta o OSPF pra IPv6. Conceitos (áreas, LSA types, DR/BDR, SPF) permanecem os mesmos — a diferença técnica principal é que o OSPFv3 roda por link, não por sub-rede (múltiplas instâncias podem coexistir no mesmo link via Instance ID), e usa endereços link-local pra formar adjacência, não o endereço global configurado na interface.
4. Boas práticas de ISP — 12 recomendações Avançado
Sintetizado do guia "Boas Práticas para a Implantação do OSPF em Ambientes de ISP", de Leonardo Furtado (Brasil Peering Forum) — referência nacional mais completa sobre o tema, parafraseada aqui com organização própria.
Só 4 finalidades legítimas: transportar sessões iBGP, dar conectividade recursiva pro NEXT_HOP de rotas BGP, transportar sessões LDP (se MPLS), e serviços internos do ISP. Rotas de cliente e rotas externas são responsabilidade do BGP — nunca do OSPF. Erro clássico citado: injetar rotas /32 de assinantes PPPoE diretamente no OSPF. Alternativa correta: agregar o bloco (ex: /22) numa rota estática pra Null0 com tag, redistribuída pro OSPF como External. Limite prático recomendado pela indústria: até 40 mil rotas IGP na tabela, mesmo que o hardware suporte muito mais.
OSPF é o IGP mais exigente em organização topológica — projeto multi-área exige hierarquia de 2 níveis obrigatoriamente. Camadas de função (Acesso, Agregação, Core, Borda de Serviços) não são só nomenclatura bonita: sem essa organização, sumarização fica inviável e o LSDB incha.
Bloco contínuo dedicado pra loopbacks, bloco contínuo por área pra links ponto a ponto. Sem esse "encaixe" entre endereçamento e topologia, sumarização no ABR simplesmente não funciona, mesmo em projeto multi-área.
Mesmo sendo Ethernet/fibra, se o enlace conecta só 2 roteadores, defina como point-to-point em vez de broadcast — elimina eleição de DR/BDR desnecessária, reduz entrada no LSDB (menos um LSA Type 2), acelera formação de adjacência e melhora convergência.
Banda de referência padrão (100 Mbps) faz qualquer interface ≥100 Mbps ter custo "1" — um link de 1 Gbps e um de 100 Gbps ficam com custo idêntico, gerando roteamento subótimo. Ajuste a banda de referência pra capacidade máxima suportada por todos os equipamentos (ex: 100 Gbps), ou ajuste custo manualmente onde o ajuste global não bastar.
Sumarizar o bloco de loopbacks pode quebrar LSPs fim-a-fim (L2VPN/L3VPN) e túneis de engenharia de tráfego entre roteadores de Core. Se sumarizar, nunca sumarize o bloco de loopbacks especificamente — considere IP Event Dampening e LSA/SPF Throttling (seção 5) como alternativa ao problema de "falatório" excessivo em vez de sumarização agressiva.
Use Stub/NSSA/Totally quando fizer sentido (roteador remoto modesto, muitas rotas externas desnecessárias ali) — não por padrão. Desenhe a topologia física pra que Virtual Link nunca seja necessário; é um recurso de última instância, não de projeto permanente.
É o mais burocrático das opções (rotas conectadas, estáticas, RIP, EIGRP, IS-IS, BGP) — exige processo dedicado por cliente, conversões de redistribuição complexas, mecanismos extras de prevenção de loop (Down Bit, Route Tags), e risco do problema de Backdoor Link (seção 3.4). Às vezes é inevitável por exigência do cliente — mas não é a primeira escolha.
Manipular métrica do IGP pra forçar caminho de tráfego é gambiarra histórica que resolve um problema criando outros imprevistos. Prefira MPLS-TE ou SR-TE — tecnologias desenhadas especificamente pra isso, mais flexíveis e previsíveis.
5. Segurança e ajuste fino Avançado
5.1 Autenticação
OSPF suporta autenticação de vizinhança (texto simples — evitar; MD5; ou, em implementações modernas, HMAC-SHA), impedindo que um roteador não autorizado forme adjacência e injete LSAs falsos. Boa prática: sempre autenticar, no mínimo com MD5, idealmente com métodos mais fortes onde suportado.
5.2 IP Event Dampening
Mecanismo de decaimento exponencial que suprime a propagação de eventos de uma interface oscilando com muita frequência (flapping) — em vez de inundar LSA a cada oscilação "on/off", o recurso identifica o padrão e passivamente remove a interface da rede até ela se estabilizar. Mais inteligente que colocar a interface em shutdown manual e reativar depois.
5.3 LSA e SPF Throttling
LSA Throttling controla dinamicamente o intervalo entre gerações de LSA durante instabilidade — primeiro LSA sempre imediato, os seguintes com taxa limitada crescente. SPF Throttling faz o mesmo pro recálculo do algoritmo de Dijkstra — atrasa dinamicamente o recômputo quando a topologia está instável, evitando sobrecarga de CPU em eventos de flapping sucessivo. Ambos ativados por padrão na maioria das plataformas modernas, mas ajustáveis.
5.4 BFD em vez de ajustar Hello/Dead
Detectar falha de link só pelo Dead Interval do OSPF (padrão 40s em rede broadcast) é lento. Em vez de reduzir agressivamente os timers Hello/Dead (o que sobrecarrega processamento do OSPF), a recomendação é usar BFD (RFC 5880) — detecção de falha bidirecional na casa dos milissegundos, sinalizando o OSPF pra convergir imediatamente sem depender do timer nativo.
6. Por que OSPF ainda é relevante Intermediário
É comum ouvir que "OSPF é coisa antiga" — não é verdade tecnicamente. Os argumentos reais pra continuar escolhendo um IGP link-state (OSPF ou IS-IS) num backbone de ISP:
- Confiabilidade de troca de mensagens — adjacência formal + reconhecimento (ACK) de cada LSA, ao contrário de distance-vector que só "transmite e espera"
- Escalabilidade real — sem limite prático de diâmetro (diferente do RIP, travado em 15 saltos), desde que respeitadas as boas práticas de hierarquia
- Convergência muito mais rápida e confiável — mapa topológico completo por área, não "boato" de segunda mão
- Prevenção de loop naturalmente robusta — decorre diretamente de cada roteador conhecer a topologia real, não de mecanismos remediadores como no RIP
- Único caminho viável pra MPLS Traffic Engineering e Segment Routing — essas tecnologias exigem obrigatoriamente um IGP link-state (OSPF ou IS-IS) por baixo; não existe alternativa distance-vector pra isso
Em outras palavras: enquanto backbones de operadora continuarem migrando pra arquiteturas MPLS/Segment Routing (tendência que só cresce), o OSPF — ou o IS-IS — continua sendo pré-requisito técnico, não escolha de nostalgia.
7. Configuração de referência — multi-fabricante Intermediário
Cenário: roteador com loopback 203.0.113.1/32 na Área 0, enlace ponto a ponto 10.0.0.0/31 também na Área 0, banda de referência ajustada pra 100 Gbps.
Cisco IOS-XE
router ospf 1
router-id 203.0.113.1
auto-cost reference-bandwidth 100000
network 203.0.113.1 0.0.0.0 area 0
network 10.0.0.0 0.0.0.1 area 0
!
interface GigabitEthernet0/1
ip ospf network point-to-point
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 SENHA-FORTEJuniper JunOS
set protocols ospf reference-bandwidth 100g
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 authentication md5 1 key "SENHA-FORTE"
set interfaces lo0 unit 0 family inet address 203.0.113.1/32
set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.0/31Mikrotik RouterOS
/routing ospf instance
set default router-id=203.0.113.1
/routing ospf area
set backbone name=area-0
/routing ospf interface-template
add area=area-0 networks=10.0.0.0/31 type=ptp \
auth=md5 auth-id=1 auth-key=SENHA-FORTE
add area=area-0 networks=203.0.113.1/32 passive
/interface bridge
add name=loopbackFRRouting (Linux)
router ospf
ospf router-id 203.0.113.1
auto-cost reference-bandwidth 100000
network 203.0.113.1/32 area 0
network 10.0.0.0/31 area 0
!
interface eth1
ip ospf network point-to-point
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 SENHA-FORTERepare como o comando auto-cost reference-bandwidth (ajuste da boa prática 4.5) tem sintaxe quase idêntica entre Cisco, FRR e JunOS — é um dos parâmetros mais universalmente padronizados entre implementações.
8. Comandos de verificação e teste Intermediário
| O que checar | Cisco / FRR | JunOS | RouterOS |
|---|---|---|---|
| Vizinhos/adjacências | show ip ospf neighbor | show ospf neighbor | /routing ospf neighbor print |
| Banco de dados LSDB | show ip ospf database | show ospf database | /routing ospf lsa print |
| Rotas aprendidas via OSPF | show ip route ospf | show route protocol ospf | /ip route print where ospf |
| Interfaces habilitadas + custo | show ip ospf interface brief | show ospf interface | /routing ospf interface print |
| Estatística de eventos SPF | show ip ospf statistics | show ospf overview | /routing ospf statistics print |
Checklist mínimo de "OSPF pronto pra produção":
- Todos os vizinhos esperados em estado Full (não Init, 2-Way ou Exstart travado)
- Custo das interfaces reflete a banda real — confira depois de qualquer mudança de banda de referência
- Loopback anunciado corretamente (geralmente como interface passiva, sem formar adjacência nela mesma)
- Autenticação configurada e idêntica nas duas pontas de cada enlace
- Se multi-área: ABR sumarizando como esperado, sem vazar detalhamento de topologia entre áreas
9. Indicadores de operação (KPIs) Avançado
| Indicador | O que revela | Sinal de alerta |
|---|---|---|
| Adjacências Full vs. esperadas | Saúde geral das vizinhanças | Qualquer adjacência fora de Full por tempo prolongado |
| Frequência de execução do SPF | Estabilidade topológica | Picos frequentes indicam flapping em algum ponto da rede — revisar Throttling/Dampening |
| Tamanho do LSDB por área | Escala do projeto de área | Crescimento descontrolado sem sumarização correspondente |
| Convergence Time | Tempo entre falha de link e rota alternativa ativa | Alto — revisar BFD, Throttling, ou dependência excessiva de Dead Interval puro |
| Nº de rotas IGP na tabela | Higiene do projeto (rota externa não deveria estar ali) | Aproximando do limite prático (~40 mil) sem justificativa — revisar boa prática 4.1 |
10. Exercícios práticos Intermediário
Resolva antes de olhar o gabarito.
Exercício 1. Sua rede tem interfaces de 1 Gbps, 10 Gbps e 100 Gbps, banda de referência ainda no padrão de fábrica (100 Mbps). Qual o problema, e qual o comando genérico pra resolver?
Ver gabarito
Todas as 3 interfaces terão custo "1" (qualquer banda ≥100 Mbps satura o cálculo com referência de 100 Mbps) — o OSPF não vai distinguir um link de 1 Gbps de um de 100 Gbps, podendo gerar roteamento subótimo. Solução: ajustar a banda de referência pra pelo menos 100 Gbps em todos os roteadores (auto-cost reference-bandwidth 100000 ou equivalente) — precisa ser consistente na rede inteira, não só num roteador.
Exercício 2. Você tem uma área OSPF única (single-area) e quer sumarizar as rotas pra reduzir o tamanho da tabela de roteamento. É possível?
Ver gabarito
Não. Sumarização de rotas nativas do OSPF só acontece no ABR (Area Border Router), e ABR só existe em projeto com 2+ áreas. Com área única, não há ABR, então não há como sumarizar rota nativa — a única sumarização possível nesse cenário seria de rotas externas, no ASBR, no momento da redistribuição.
Exercício 3. Um cliente L3VPN MPLS tem link de 1 Gbps via sua rede e link de 100 Mbps direto com outro site, ambos na mesma área OSPF. O tráfego insiste em ir pelo link de 100 Mbps. Por quê, e como corrigir?
Ver gabarito
É o cenário clássico de OSPF Backdoor Link (seção 3.4): a rota via L3VPN MPLS é Inter-Area (Type 3), a rota pelo link direto é Intra-Area — e Intra-Area sempre vence, independente do custo. Correção: configurar OSPF Sham-Link entre os roteadores PE, fazendo o caminho MPLS ser tratado como Intra-Area também.
Exercício 4. Um roteador remoto, modesto em capacidade de processamento, tem 1 único link pro resto da rede e recebe centenas de rotas externas desnecessárias vindas da Área 0. Que tipo de área resolve isso, e o que ele passa a receber no lugar dessas rotas?
Ver gabarito
Configurar essa área como Stub (ou Totally Stubby, se quiser suprimir também os resumos inter-área). O roteador deixa de receber LSA Type 5 (rotas externas) e passa a receber uma rota padrão (default) gerada automaticamente pelo ABR — suficiente pra alcançar qualquer destino fora da área, com LSDB muito mais enxuto.
11. Troubleshooting comum Intermediário
Normal em rede Broadcast quando nenhum dos dois é DR/BDR entre si (2-Way é o estado final esperado entre dois DROthers) — não é bug. Se deveria formar adjacência completa, revisar se network type está correto (ver 4.4).
Causa clássica: MTU incompatível entre as duas interfaces — o processo de troca do LSDB (Database Description) trava exatamente nesse ponto. Confirme MTU idêntico dos dois lados.
Checar: mesma área configurada dos dois lados, mesma máscara de sub-rede, timers Hello/Dead idênticos, autenticação (se configurada) batendo, e conectividade IP/multicast básica (pacotes Hello vão pra 224.0.0.5).
Duas causas mais prováveis: banda de referência mal ajustada (seção 4.5), ou confusão Intra-Area vs. Inter-Area em cenário de Backdoor Link (seção 3.4).
Sintoma de flapping em algum enlace, propagando LSA constantemente. Identifique a interface instável (fibra com problema físico é a causa mais comum) e considere IP Event Dampening enquanto o problema físico não é corrigido.
12. Glossário
Ferramentas relacionadas
Perguntas da Comunidade sobre OSPF
Adjacência não forma, roteamento subótimo, dúvida sobre áreas especiais? Pergunte pra quem já passou por isso.
Fazer pergunta sobre OSPF13. Referências
Padrões internacionais (IETF)
- RFC 2328 — OSPF Version 2
- RFC 5340 — OSPF for IPv6 (OSPFv3)
- RFC 3623 — Graceful OSPF Restart
- RFC 5880 — Bidirectional Forwarding Detection (BFD)
Contexto nacional (Brasil)
- Boas Práticas para a Implantação do OSPF em Ambientes de ISP
- Interior Gateway Protocols: OSPF
Conteúdo técnico independente, contextualizado para o cenário brasileiro. Boas práticas citadas refletem consenso de operadores experientes, não obrigação normativa — avalie sempre contra o seu projeto técnico específico.