Entenda como funciona o OSPF, áreas, LSAs, custos, DR/BDR, sumarização, redistribuição, OSPFv2/v3, convergência e critérios de projeto de redes.
Confira!
OSPF (Open Shortest Path First) é um protocolo de roteamento interno do tipo link-state usado para distribuir rotas dentro de um mesmo sistema autônomo. Em vez de anunciar apenas destinos e distâncias, os roteadores OSPF constroem uma visão lógica da topologia, sincronizam uma base de estado de enlaces e calculam os melhores caminhos com o algoritmo SPF. Em redes corporativas, o projeto correto de OSPF depende menos de “ativar o protocolo” e mais de definir limites de domínio, áreas, sumarização, custos, redundância, redistribuição, autenticação, temporização e critérios de convergência de forma coerente com a arquitetura física e lógica.
O OSPFv2 é a especificação clássica para IPv4 e permanece documentado pelo RFC 2328. Para IPv6, o OSPFv3 mantém os mecanismos fundamentais — flooding, eleição de DR, áreas e cálculo SPF — com alterações de semântica e formato descritas pelo RFC 5340. Em ambos os casos, a qualidade da implementação depende da modelagem da rede: uma topologia mal hierarquizada, excesso de redistribuição, áreas mal definidas ou custos incoerentes podem gerar instabilidade, rotas subótimas e troubleshooting difícil mesmo quando a configuração está sintaticamente correta.
Como o OSPF forma e mantém rotas
O funcionamento do OSPF pode ser entendido como um ciclo contínuo de descoberta, formação de adjacências, troca de informações de estado, sincronização de base topológica e cálculo de rotas. O objetivo é que os roteadores pertencentes ao mesmo escopo de área mantenham uma visão compatível da topologia relevante e consigam recalcular caminhos quando ocorre uma mudança.
Em termos de engenharia, isso significa que o plano de controle é fortemente dependente da estabilidade das adjacências e da coerência da LSDB. Uma interface oscilando, um MTU incompatível, autenticação divergente ou parâmetros de área inconsistentes não afetam apenas “uma rota”: podem impedir sincronização, provocar recálculos repetitivos e alterar o comportamento de vários caminhos simultaneamente.
Hello, vizinhança e adjacência
Os roteadores OSPF utilizam mensagens Hello para descobrir vizinhos e verificar se parâmetros essenciais são compatíveis. Nem todo vizinho precisa necessariamente formar uma adjacência completa em todos os tipos de rede; o comportamento depende do tipo de enlace e, em redes multiacesso, da eleição de Designated Router (DR) e Backup Designated Router (BDR).
Uma sessão que não ultrapassa estados intermediários deve ser tratada como sintoma técnico. A análise precisa verificar, entre outros pontos:
- área configurada nas interfaces;
- timers Hello e Dead;
- autenticação e chaves;
- MTU e características do enlace;
- tipo de rede OSPF;
- Router ID;
- filtros ou ACLs que afetem o protocolo;
- duplicidade de endereçamento ou instabilidade de interface.
LSDB e cálculo SPF
A Link-State Database representa a topologia conhecida dentro do escopo aplicável. A partir dela, cada roteador executa o algoritmo Shortest Path First para construir uma árvore de menores custos com origem em si próprio. O resultado alimenta a tabela de roteamento, respeitando regras do protocolo, preferências de rotas e possíveis informações externas.
Esse mecanismo explica por que alterações de topologia podem ter impacto diferente de alterações apenas de encaminhamento. Uma mudança que gere novos LSAs e modifique a LSDB pode provocar novo cálculo SPF; por isso, redes com enlaces instáveis, excesso de adjacências ou desenho pouco hierarquizado tendem a aumentar a pressão sobre o plano de controle.
Métrica de custo no OSPF
O OSPF seleciona caminhos com base em custo. Em implementações comuns, o custo da interface é derivado de uma referência de largura de banda ou configurado explicitamente. Em redes modernas, confiar cegamente no valor padrão pode eliminar a diferenciação entre enlaces de capacidades muito distintas, especialmente quando a referência foi concebida para velocidades menores que as atuais.
O projeto deve, portanto, definir uma política de custos. Essa política precisa ser documentada e aplicada de modo consistente, considerando:
- capacidade nominal do enlace;
- função arquitetural do caminho;
- preferência primária e secundária;
- enlaces metropolitanos ou WAN com características diferentes;
- assimetria intencional ou não intencional;
- caminhos de contingência;
- necessidade de ECMP quando há custos equivalentes.
Custo não é latência real
É um erro comum interpretar a métrica OSPF como medição dinâmica de latência, perda ou utilização. O custo é uma métrica do protocolo e não substitui telemetria operacional. Dois enlaces podem apresentar o mesmo custo e, ainda assim, ter latências, perdas, jitter, políticas de QoS ou níveis de saturação distintos.
Por isso, o projeto de roteamento deve conversar com o monitoramento de rede e com a engenharia de capacidade. O protocolo decide o caminho conforme sua lógica; a operação precisa verificar se esse caminho entrega o nível de serviço esperado.
Áreas OSPF e arquitetura hierárquica
Antes de alterar áreas, custos ou redistribuição, é recomendável reconstruir o As-Is do domínio de roteamento: adjacências, LSDB, Router IDs, caminhos ativos, sumarizações e pontos de redistribuição.
O conceito de áreas permite limitar a propagação de determinadas informações topológicas e criar hierarquia. A Area 0 é o backbone lógico ao qual as demais áreas devem se conectar conforme o modelo do protocolo. Em redes empresariais, a divisão em áreas deve refletir limites arquiteturais reais, e não ser criada apenas para “usar o recurso”.
Uma rede pequena pode operar adequadamente em uma única área. Multiplicar áreas sem necessidade aumenta a quantidade de papéis, regras de sumarização, pontos de fronteira e cenários de troubleshooting. Por outro lado, redes extensas, multi-site ou com muitos domínios de acesso podem se beneficiar de desenho hierárquico quando existe justificativa de escala e isolamento operacional.
Papéis de roteadores
A terminologia ajuda a documentar responsabilidades:
- Internal Router: possui interfaces OSPF em uma única área;
- Backbone Router: participa da Area 0;
- ABR — Area Border Router: conecta áreas e mantém informações separadas por área;
- ASBR — Autonomous System Boundary Router: injeta no OSPF rotas provenientes de outro domínio ou mecanismo de roteamento.
Esses papéis devem aparecer nos diagramas lógicos. Em uma rede crítica, a função de ABR ou ASBR não deveria surgir acidentalmente de uma configuração pontual; ela deve ser uma decisão de arquitetura.
Tipos de área: normal, stub e NSSA
Áreas especiais existem para controlar a quantidade e a natureza de informações externas recebidas. O uso de stub ou NSSA deve partir de uma necessidade concreta, como reduzir a presença de rotas externas em uma área ou permitir importação externa controlada em uma área que não deve receber toda a informação externa do domínio.
O RFC 3101 define a NSSA como uma área semelhante a stub, mas com capacidade de importar rotas externas de maneira limitada. A decisão entre área normal, stub e NSSA deve considerar o papel daquele domínio na arquitetura e a necessidade de redistribuição local.
Quando não usar área especial
Não é recomendável introduzir uma área especial apenas para simplificar uma tabela que poderia ser tratada por sumarização e desenho hierárquico. Cada tipo especial adiciona comportamento que precisa ser conhecido pela equipe de operação e testado em cenários de falha.
O critério deve ser funcional: que informação precisa entrar, sair e permanecer naquela área? A resposta deve estar no projeto de rede, não apenas na configuração do equipamento.
LSAs: o que eles representam no projeto
Link-State Advertisements são as unidades pelas quais o OSPF descreve elementos da topologia e informações de roteamento. Não é necessário decorar todos os formatos para projetar corretamente uma rede, mas é essencial entender que diferentes LSAs possuem escopos e funções distintas.
No OSPFv2, os tipos mais relevantes para engenharia de redes corporativas incluem:
| Tipo | Papel principal | Implicação de projeto |
| 1 | Router LSA | descreve links do roteador dentro da área |
| 2 | Network LSA | representa segmento multiacesso associado ao DR |
| 3 | Summary LSA | transporta informação entre áreas via ABR |
| 4 | ASBR Summary | informa alcance até ASBR |
| 5 | AS External | divulga rotas externas em áreas compatíveis |
| 7 | NSSA External | transporta rotas externas dentro de NSSA antes de tradução |
A análise de LSAs é particularmente útil em troubleshooting porque permite distinguir um problema de aprendizagem topológica de um problema posterior de seleção ou instalação de rota.
DR e BDR em redes multiacesso
Em segmentos broadcast com múltiplos roteadores, o OSPF utiliza DR e BDR para reduzir a quantidade de adjacências completas e organizar a troca de LSAs. Isso evita que cada roteador precise manter adjacência completa com todos os demais como em uma malha total.
A eleição é baseada em prioridade OSPF e Router ID. Como a eleição não é preemptiva da mesma forma que muitos protocolos de gateway de primeiro salto, a ordem de inicialização e a configuração de prioridades podem afetar quem assume os papéis.
Em ambientes em que a escolha do DR importa operacionalmente, a prioridade deve ser intencional e documentada. Em enlaces ponto a ponto, a lógica de DR/BDR não é necessária e o tipo de rede deve refletir a natureza real do enlace sempre que a plataforma permitir.
Router ID e identidade operacional
O Router ID é a identidade lógica do roteador no domínio OSPF. Usar uma estratégia previsível, normalmente baseada em loopbacks estáveis e endereçamento planejado, facilita diagnóstico, documentação e correlação com sistemas de monitoramento.
O Router ID deve ser único. Duplicidades podem produzir efeitos severos e de difícil interpretação. Por isso, o plano de endereçamento não deve tratar loopbacks apenas como detalhe de configuração: elas fazem parte da identidade operacional dos equipamentos e devem estar registradas no diagrama de rede e no IPAM.
Sumarização e controle de alcance
Uma das vantagens da arquitetura hierárquica é poder sumarizar prefixos em pontos de fronteira. Sumarização reduz a quantidade de rotas propagadas, melhora a legibilidade e pode limitar o impacto de mudanças de topologia mais específicas.
Mas sumarização exige um plano de endereçamento compatível. Se sub-redes de uma mesma região, site ou função estiverem dispersas em blocos sem agregação possível, o ABR terá pouca capacidade de representar aquela área de forma compacta.
Esse é um dos motivos para integrar subnetting e planejamento de sub-redes ao desenho do roteamento. Endereçamento e OSPF não devem ser projetados isoladamente.
Risco de blackhole por sumarização
Uma rota sumarizada representa um conjunto de prefixos. Se o resumo continuar anunciado mesmo quando parte dos componentes deixa de existir, pode haver tráfego encaminhado para um domínio sem rota específica correspondente. A estratégia precisa prever comportamento de descarte, rotas de summary e condições em que o anúncio deve permanecer ou desaparecer.
Redistribuição entre OSPF e outros domínios
Redistribuição é uma das áreas de maior risco no projeto de roteamento. Ela ocorre quando rotas aprendidas por outro protocolo, rotas estáticas ou conectadas são injetadas no OSPF. O roteador que faz isso assume papel de ASBR.
A redistribuição deve ser controlada por política explícita:
- quais prefixos podem ser importados;
- quais devem ser bloqueados;
- qual métrica externa será aplicada;
- se a rota será externa tipo 1 ou tipo 2;
- como evitar reentrada da mesma rota por outro ponto;
- como identificar origem com tags ou mecanismos equivalentes;
- qual será o comportamento em caso de perda do domínio de origem.
Redistribuição bidirecional em múltiplos pontos, sem política e sem marcação, cria risco real de loops de roteamento e rotas subótimas.
OSPF e BGP não exercem a mesma função
OSPF é um IGP para distribuição interna de rotas dentro de um sistema autônomo. BGP opera com lógica de políticas e sistemas autônomos, sendo usado em interconexões externas e também em arquiteturas internas específicas. A comparação correta não é “qual é melhor”, mas qual função de roteamento precisa ser desempenhada.
Quando o projeto envolve Internet, múltiplos provedores ou política inter-AS, o BGP e seus critérios de projeto devem ser tratados separadamente do IGP interno.
OSPFv2 e OSPFv3
O OSPFv3 foi desenvolvido para suportar IPv6 mantendo os mecanismos fundamentais do OSPF. O RFC 5340 registra que flooding, eleição de DR, áreas e cálculo SPF permanecem, mas há mudanças importantes: processamento por link, novas estruturas de LSAs, tratamento de endereçamento e possibilidade de múltiplas instâncias por link.
Uma migração IPv4/IPv6 não deve assumir que OSPFv3 é simplesmente “OSPFv2 com endereço maior”. O plano deve considerar capacidades da plataforma, modelo de segurança, operação dual-stack e coexistência dos planos de controle.
Segurança do protocolo
O plano de controle de roteamento é infraestrutura crítica. Uma adjacência indevida pode introduzir informações topológicas falsas, causar blackholes ou redirecionar tráfego. Por isso, as interfaces que participam do OSPF devem ser explicitamente definidas e as interfaces sem necessidade de formar vizinhança devem permanecer passivas ou fora do processo, conforme a plataforma.
Também devem ser considerados:
- autenticação quando suportada e aplicável;
- filtragem do plano de controle;
- proteção de CPU/CoPP conforme o fabricante;
- restrição de gerenciamento aos equipamentos;
- logging de mudanças de adjacência;
- monitoramento de LSDB e eventos de roteamento;
- sincronização de tempo para correlação forense.
Convergência e comportamento em falha
Convergência é o processo pelo qual a rede volta a uma visão consistente após mudança de topologia. O tempo percebido pela aplicação é resultado de várias etapas: detecção da falha, mudança de estado da interface ou vizinhança, geração e flooding de LSAs, cálculo SPF, atualização das tabelas e programação do plano de encaminhamento.
Reduzir timers sem entender essas etapas pode aumentar sensibilidade a instabilidades e consumo de recursos. O objetivo de projeto não deve ser “menor timer possível”, mas atender a um requisito de recuperação compatível com aplicações e capacidade dos equipamentos.
Fast failure detection
Quando o requisito de recuperação é mais agressivo do que os mecanismos padrão atendem, podem existir técnicas complementares como BFD, detecção física rápida e arquiteturas com ECMP. A aplicabilidade depende dos equipamentos e do desenho, e precisa ser ensaiada em laboratório ou comissionamento quando a disponibilidade é crítica.
Capacidade do plano de controle
A escala de OSPF não deve ser analisada apenas pelo número de rotas. Quantidade de adjacências, LSAs, áreas, frequência de mudanças, capacidade de CPU e memória e políticas de sumarização influenciam o comportamento do sistema.
Uma rede com milhares de rotas estáveis pode ser menos onerosa que uma rede menor com links oscilando repetidamente. Por isso, o levantamento As-Is deve registrar tanto escala quanto estabilidade histórica.
Como diagnosticar problemas de OSPF
O troubleshooting deve seguir uma sequência para evitar conclusões prematuras.
- Confirmar estado físico e lógico da interface.
- Verificar endereçamento, máscara/prefixo e conectividade local.
- Confirmar presença do OSPF na interface correta e área correta.
- Verificar estado de vizinhança e adjacência.
- Comparar parâmetros relevantes entre pares.
- Analisar LSDB e presença do prefixo esperado.
- Confirmar cálculo da rota e preferência administrativa frente a outros protocolos.
- Verificar instalação na RIB/FIB.
- Validar encaminhamento de dados e caminho de retorno.
Essa separação entre plano físico, plano de controle e plano de dados reduz o risco de “corrigir” uma rota quando a origem do problema está em adjacência, política ou endereçamento.
OSPF em redes corporativas e campus
Em campus corporativos, o OSPF é frequentemente associado a fronteiras L3 entre distribuição/core, domínios de acesso roteados e interconexões entre prédios ou sites. A arquitetura deve definir claramente onde termina o domínio Layer 2 e onde começa o roteamento.
Quanto maior o domínio Layer 2, maior a dependência de mecanismos de prevenção de loop e maior o raio de impacto de determinados eventos Ethernet. Introduzir Layer 3 mais próximo do acesso pode reduzir domínio de falha, mas aumenta quantidade de interfaces roteadas e adjacências. Não há desenho universal; a decisão depende de escala, mobilidade, políticas, operação e plataforma.
OSPF em redes multi-site e WAN
Em redes multi-site, deve-se avaliar se o OSPF será estendido fim a fim, usado apenas localmente ou combinado com outro protocolo na WAN. Estender o mesmo IGP através de links de terceiros pode aumentar acoplamento operacional entre sites e serviços contratados.
O projeto deve documentar:
- quem controla o roteamento em cada domínio;
- quais rotas atravessam a WAN;
- como defaults e sumarizações são distribuídos;
- comportamento em perda parcial de conectividade;
- preferência entre links primários e secundários;
- pontos de redistribuição;
- limites de responsabilidade entre contratante e operadora.
Critérios de projeto OSPF
O desenho OSPF deve ser consequência da arquitetura lógica, do endereçamento e dos requisitos de disponibilidade. A documentação de projeto transforma parâmetros de roteamento em critérios verificáveis de implantação.
Uma especificação técnica de OSPF deveria materializar decisões verificáveis, e não apenas dizer “usar OSPF”. Entre os critérios relevantes estão:
| Critério | Decisão esperada no projeto |
| Escopo | quais equipamentos/interfaces participam |
| Áreas | mapa de áreas e backbone |
| Router IDs | padrão e unicidade |
| Custos | política e exceções |
| Sumarização | pontos e prefixos agregados |
| Redistribuição | origem, filtros, tags e métricas |
| Segurança | autenticação, interfaces passivas e proteção do plano de controle |
| Convergência | requisitos e método de teste |
| Alta disponibilidade | caminhos redundantes, ECMP e cenários de falha |
| Operação | comandos, dashboards, alarmes e evidências |
Como contratar projeto ou revisão de OSPF
A validação final precisa provar comportamento em falha, rotas, convergência, redundância e ausência de anúncios indevidos. Adjacência Full, isoladamente, não constitui aceite técnico.
Uma contratação tecnicamente consistente deve partir da arquitetura existente e dos requisitos de negócio. O escopo pode envolver levantamento As-Is, coleta de configurações, diagramas, inventário de roteadores, análise da LSDB, matriz de adjacências, plano de endereçamento, requisitos de disponibilidade e histórico de incidentes.
O entregável To-Be deve indicar topologia de roteamento, áreas, custos, sumarizações, redistribuições, critérios de segurança e plano de migração. Também é recomendável uma matriz de testes com cenários de falha, convergência e validação de caminho.
A implantação não deve ser aceita apenas porque as adjacências ficaram Full. O aceite precisa comprovar rotas esperadas, ausência de rotas indevidas, comportamento de redundância, tempos compatíveis com o requisito e documentação As-Built atualizada.
Considerações finais
OSPF é um protocolo maduro, mas seu desempenho operacional depende diretamente da engenharia da topologia. Áreas, custos, sumarização, Router IDs, redistribuição, segurança e convergência precisam ser tratados como elementos de projeto e não como parâmetros isolados de CLI.
Uma rede OSPF previsível é aquela em que o comportamento de cada caminho pode ser explicado antes da falha e comprovado durante testes. A combinação entre arquitetura hierárquica, endereçamento agregável, políticas explícitas e comissionamento reduz a complexidade do troubleshooting e aumenta a confiabilidade do domínio de roteamento.
Referências técnicas
[1] MOY, John. RFC 2328: OSPF Version 2. IETF, 1998. Disponível em: https://www.rfc-editor.org/rfc/rfc2328.html
[2] COLTUN, R.; FERGUSON, D.; MOY, J.; LINDEM, A. RFC 5340: OSPF for IPv6. IETF, 2008. Disponível em: https://www.rfc-editor.org/rfc/rfc5340.html
[3] MURPHY, P. RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option. IETF, 2003. Disponível em: https://www.rfc-editor.org/rfc/rfc3101.html
[4] CISCO. Designing Cisco Enterprise Networks (ENSLD): conteúdo de projeto de roteamento OSPF para redes empresariais. Disponível em: https://www.cisco.com/site/us/en/learn/training-certifications/training/courses/ensld.html
Perguntas frequentes
OSPF é um protocolo IGP link-state usado para distribuir rotas dentro de um sistema autônomo. Ele sincroniza informações de topologia em uma LSDB e calcula os melhores caminhos com o algoritmo SPF.
OSPF é voltado ao roteamento interno de um sistema autônomo, enquanto BGP é orientado a políticas e interconexão entre sistemas autônomos ou arquiteturas que exigem controle de política mais amplo.
Não. Redes pequenas podem operar adequadamente em uma única área. Novas áreas devem ser criadas quando há justificativa de escala, hierarquia, sumarização ou isolamento operacional.
A Area 0 é o backbone lógico do domínio OSPF. As demais áreas se conectam a esse backbone conforme a arquitetura definida pelo protocolo.
Não. O custo é a métrica de seleção de caminho do OSPF e não representa, por si só, latência, perda, jitter ou utilização real do enlace.
Devem ser verificados adjacências, LSDB, rotas esperadas e indevidas, redundância, convergência, redistribuição, sumarização, caminhos de ida e volta e documentação As-Built.
Materiais técnicos complementares
Conteúdos principais sobre o tema
- Guia Completo sobre Arquitetura de Redes: topologias, projeto e infraestrutura
- Projeto de Rede: etapas, arquitetura e documentação técnica
Conteúdos técnicos correlatos
- BGP: o que é, como funciona, ASN, peering e critérios de projeto
- Subnetting: como funciona o subnetting IPv4 e como dimensionar sub-redes
- Diagrama de Rede: tipos, arquitetura lógica e física e documentação técnica
- Monitoramento de Rede: métricas, disponibilidade, desempenho e observabilidade
