Introdução ao Open Shortest Path First - OSPF
O Open Shortest Path First (mais conhecido como OSPF) é um protocolo de roteamento open standard (RFC 2328 para IPv4 e RFC 5340 para IPv6) que foi implementado por uma ampla variedade de fornecedores de rede, incluindo Cisco e Juniper. Justamente por ser um protocolo aberto, o OSPF se destaca por sua flexibilidade e interoperabilidade, características que contribuem significativamente para sua popularidade.
O OSPF utiliza o algoritmo chamado de Dijkstra, ele é usado para criar uma "árvore" com os caminhos mais curtos para as rotas que ele recebe, incluindo todos os destinos acessíveis dentro da área OSPF. Essa "árvore" determina o caminho de menor custo para cada destino, e é usada para preencher a tabela de roteamento do roteador. Outro ponto importante do OSPF é a capacidade de convergência muito rápida, um dos principais motivos pelos quais ele é amplamente adotado. Além disso, o OSPF oferece suporte a múltiplos caminhos de custo igual para um mesmo destino, bem como suporte tanto a IPv4 quanto a IPv6.
Abaixo podemos conferir uma lista que resume alguns dos melhores recursos do OSPF:
- Permite a criação de áreas;
- Minimiza o tráfego de atualização de roteamento;
- É altamente flexível, versátil e escalonável;
- Suporta VLSM e CIDR;
- Oferece uma contagem de saltos ilimitada;
- É um padrão aberto e oferece suporte à implantação de vários fornecedores.
Como o OSPF é geralmente o primeiro protocolo de roteamento do tipo link-state que muitos profissionais de Rede tem contato, é comum comparar ele com os protocolos mais antigos baseados em vetor de distância, como RIPv1 e RIPv2.
Uma das funcionalidades mais poderosas do OSPF é seu design hierárquico. Ele permite dividir uma grande internetwork em áreas menores, otimizando o roteamento e a gestão da rede. Essa estrutura hierárquica traz grandes benefícios, como:
- Redução da sobrecarga de roteamento;
- Aceleração da convergência em caso de mudanças na rede;
- Isolamento de falhas ou instabilidades a áreas específicas da rede.
Internetwork é o termo usado para descrever um conjunto de redes de computadores interconectadas, que funcionam como se fossem uma única rede lógica. Essa interligação é feita por meio de dispositivos como roteadores, que encaminham pacotes entre as redes com base em endereços IP.
Quando redes individuais, como LANs (redes locais), são conectadas entre si através de links de comunicação e roteadores, forma-se uma internetwork. Esse conceito é fundamental para a arquitetura da Internet, que nada mais é do que uma gigantesca internetwork global.
Ao observarmos um projeto típico de rede com OSPF, fica evidente que certos roteadores devem se conectar à chamada "área 0", ou área de backbone. Iso é obrigatório no OSPF, todas as demais áreas precisam estar conectadas a área 0 diretamente ou através de links virtuais. O roteador que interliga outras áreas à área 0 é conhecido como ABR (Area Border Router), e deve possuir pelo menos uma interface conectada diretamente ao backbone. Esse modelo hierárquico tem como principal vantagem a contenção das alterações de topologia, limitando seu impacto à área onde elas ocorrem.
O OSPF também tem a capacidade de interconectar diferentes Sistemas Autônomos. Quando isso ocorre, o roteador responsável por essa função é chamado de ASBR (Autonomous System Boundary Router). Em redes maiores, criar áreas auxilia na redução da propagação de atualizações e limita os efeitos de falhas, mantendo a rede mais estável.
Antes de avançarmos, é essencial entender alguns termos-chave do OSPF, eles serão a base para o aprendizado das próximas seções.
Terminologia Essencial do OSPF
Antes de explorarmos as funcionalidades e configurações, é fundamental conhecer os termos que formam a base do funcionamento do OSPF.
Link
O termo link representa uma interface de rede conectada a uma determinada rede. No OSPF, quando uma interface é incluída no processo de roteamento, ela passa a ser considerada um link, contendo informações como seu estado (ativo ou inativo) e um ou mais endereços IP associados.Router ID (RID)
O Router ID (RID) é o identificador único de cada roteador no processo OSPF. É um endereço IP atribuído ao roteador, que pode ser escolhido automaticamente com base na interface de loopback. Caso não exista uma loopback configurada, a escolha recai sobre o IP mais alto entre as interfaces físicas ativas. O RID funciona como se fosse o "nome" do roteador dentro do domínio OSPF.Neighbors
Os Vizinhos (neighbors) são roteadores que compartilham uma rede comum, como uma conexão ponto a ponto. Para que se tornem vizinhos OSPF de fato, é necessário que diversas configurações estejam idênticas entre eles, como: ID da área, flag de área stub, senhas de autenticação (se usadas) e os intervalos Hello e Dead.Adjacência
A adjacência é o próximo passo após a descoberta de vizinhos. Trata-se de um relacionamento mais estreito entre dois roteadores OSPF, permitindo a troca direta de informações de roteamento. Diferentemente do EIGRP, que compartilha rotas com todos os vizinhos, o OSPF só troca LSAs (Anúncios de Estado de Link) com roteadores com os quais mantém adjacências, e nem todos os vizinhos se tornam adjacentes, o que depende do tipo de rede e da configuração.Designated router
Em redes de acesso múltiplo, é necessário eleger um roteador designado (DR) para coordenar a comunicação entre os roteadores da rede. Isso evita a formação de adjacências desnecessárias e otimiza a troca de informações. A escolha do DR é feita com base na prioridade do roteador, em caso de empate, vence o que tiver o RID mais alto.Backup designated router
O roteador designado de backup (BDR) assume o papel do DR caso este atual DR falhe, mas ele não propaga LSAs enquanto não for necessário.Hello Protocol
O Hello Protocol é a base da descoberta de vizinhos e da manutenção das adjacências. Por meio dos pacotes Hello, enviados para o endereço multicast 224.0.0.5, os roteadores descobrem uns aos outros e verificam se os parâmetros estão alinhados para formar uma vizinhança. Esses pacotes também ajudam a manter a relação ativa com os vizinhos.
O padrão é enviar um hello a cada 10 segundos.Dead Interval
O Dead Interval é o tempo máximo que um roteador pode ficar sem receber pacotes Hello de um vizinho antes de considerá-lo inativo. Se esse tempo expira, o vizinho é declarado como "down", e a adjacência é encerrada. O valor padrão do dead interval é 40 segundos, ou seja, quatro vezes o hello interval padrão (10s). Esse intervalo é fundamental para detectar falhas de conectividade rapidamente e iniciar a convergência da rede.neighborship database
O banco de dados de vizinhança (neighborship database) registra todos os roteadores dos quais se recebeu pacotes Hello, incluindo suas IDs e estados. Já o banco de dados topológico armazena todas as informações de LSAs recebidas dentro de uma área. É com base nesse banco que o algoritmo de Dijkstra calcula os melhores caminhos para cada rede.Link State Advertisement - LSA
O LSA (Link State Advertisement) é o pacote com as informações de roteamento e estado dos links que os roteadores trocam. Eles são compartilhados exclusivamente entre roteadores que mantêm adjacência entre si, garantindo consistência e controle.Link-state database - LSDB
O LSDB (Link-State Database) é um banco de dados onde cada roteador OSPF mantém uma cópia da topologia da sua área. Todos os roteadores dentro da mesma área possuem exatamente o mesmo LSDB, o que garante uma visão consistente da rede. Esse banco armazena os LSAs (Link-State Advertisements), que descrevem os links, vizinhos e custos associados.
Com base no LSDB, cada roteador executa localmente o algoritmo SPF (Shortest Path First), também conhecido como algoritmo de Dijkstra, para calcular a árvore de caminhos mais curtos com ele próprio como raiz. O resultado desse cálculo é o que preenche a tabela de roteamento OSPF, sempre evitando loops.OSPF areas
Uma área OSPF é um agrupamento de redes e roteadores que compartilham um ID comum. Cada interface de um roteador pode pertencer a uma área distinta, o que permite a divisão da rede em segmentos menores e mais gerenciáveis. A área 0 é obrigatória e serve como backbone, conectando todas as demais áreas e promovendo uma arquitetura hierárquica altamente escalável.Broadcast (multi-access)
Redes de broadcast (multiacesso), como a Ethernet, permitem que múltiplos dispositivos compartilhem a mesma rede. Nesse tipo de rede, é necessária a eleição de um DR e um BDR para que a troca de LSAs seja eficiente e organizada.Nonbroadcast multi-access
Já as redes NBMA (Non-Broadcast Multi-Access), como Frame Relay, X.25 e ATM, também oferecem acesso múltiplo, mas sem suporte nativo à transmissão em broadcast. Por isso, demandam configurações OSPF específicas.Point-to-point
A topologia ponto a ponto define uma conexão direta entre dois roteadores. Essa simplicidade elimina a necessidade de DRs e BDRs, tornando o processo de formação de adjacência mais direto e rápido.Point-to-multipoint
Por fim, a topologia ponto a multiponto conecta uma única interface de um roteador a diversos outros roteadores, todos compartilhando a mesma rede. Dependendo de como essa rede lida com broadcast, diferentes tipos de configuração OSPF poderão ser usados.
Compreender esses conceitos é essencial para dominar o funcionamento interno do OSPF. Com eles em mente, você estará preparado para aplicar corretamente as próximas etapas da configuração e do design de redes baseadas nesse poderoso protocolo de roteamento.
Operações do OSPF
A operação do OSPF pode ser dividida em três fases principais: a inicialização de vizinhos e adjacências, a propagação dos LSAs e o cálculo da árvore SPF (Shortest Path First).
Tudo começa com a formação de vizinhanças e adjacências, um processo essencial no funcionamento do protocolo. Assim que o OSPF é iniciado em um roteador, ele reserva memória para armazenar as tabelas de vizinhança e de topologia. Em seguida, identifica quais interfaces estão configuradas para operar com OSPF, verifica se estão ativas e começa a enviar pacotes Hello por essas interfaces.
O protocolo Hello é o responsável por descobrir outros roteadores OSPF na rede, estabelecer adjacências e manter esses relacionamentos. Esses pacotes são enviados periodicamente por cada interface OSPF habilitada, utilizando o endereço de multicast 224.0.0.5 para IPv4 e FF02::5 para IPv6.
A frequência com que os pacotes Hello são enviados varia conforme o tipo de rede. Em redes de broadcast e ponto a ponto, o intervalo padrão é de 10 segundos. Já em redes non-broadcast e ponto a multiponto, esse intervalo é geralmente de 30 segundos. Essa troca regular de mensagens permite que os roteadores detectem rapidamente falhas nos vizinhos e mantenham suas tabelas de roteamento sempre atualizadas.
A partir desse processo inicial, o OSPF segue para a propagação de LSAs e, finalmente, utiliza o algoritmo de Dijkstra para calcular a árvore SPF, que define os caminhos de menor custo até cada destino conhecido, completando assim o ciclo de funcionamento interno do protocolo.
LSA Flooding
O OSPF precisa que todos os roteadores dentro de uma mesma área tenham as mesmas informações sobre a rede. Para isso, ele usa um processo chamado de inundação de LSA. Quando alguma coisa muda, por exemplo, um novo roteador aparece ou um link cai, o OSPF envia um tipo específico de pacote chamado LSU (Link State Update). O LSU carrega os LSAs, é como se o LSU fosse o envelope e os LSAs fossem as cartas dentro do envelope.
Então, quando uma mudança acontece na rede, o roteador cria um ou mais LSAs com essas informações e coloca tudo dentro de um pacote LSU. Esse pacote LSU é enviado para todos os roteadores da área, usando o endereço multicast 224.0.0.5 para IPv4 e FF02::5 para IPv6, se a rede permitir.
Os roteadores que recebem o LSU verificam os LSAs que vieram dentro dele, atualizam sua base de dados de topologia se a informação for nova ou mais recente, e respondem com um pacote de confirmação chamado LSAck, para garantir que o envio foi bem-sucedido.
SPF Tree Calculation
Dentro de uma área OSPF, cada roteador precisa descobrir qual é o melhor caminho para chegar a cada rede daquela área. Pra fazer isso, ele usa as informações que tem guardadas no banco de dados de topologia (que são os LSAs recebidos dos outros roteadores) e roda um cálculo usando o algoritmo SPF (Shortest Path First), também conhecido como algoritmo de Dijkstra.
Esse cálculo cria uma estrutura chamada de árvore SPF. Essa árvore começa no próprio roteador e vai se ramificando até alcançar todas as redes e dispositivos daquela área, sempre escolhendo os caminhos de menor custo, ou seja, os mais eficientes.
O importante aqui é entender que essa árvore só mostra as rotas da mesma área. Se o roteador participa de mais de uma área, ele vai calcular uma árvore separada para cada uma delas. Além disso, esse cálculo não é usado para redes que estão em outras áreas, nesse caso, o OSPF usa outros mecanismos para lidar com essas rotas.
Um ponto essencial no cálculo do SPF é o custo de cada caminho. O roteador compara os custos e sempre escolhe a rota mais barata (com menor métrica) para colocar na tabela de roteamento. É isso que garante que o OSPF sempre escolha os caminhos mais eficientes dentro da área.
OSPF Metrics
No OSPF, cada rota tem um "peso", que a gente chama de custo. Esse custo é o que o OSPF usa pra decidir qual caminho é melhor. Quanto menor o custo, melhor o caminho. O custo é somado com base nas interfaces por onde os pacotes vão passar. Então, se um pacote vai sair por uma interface, passar por mais duas até chegar no destino, o OSPF soma o custo de cada uma dessas interfaces pra saber o custo total do caminho.
A RFC que define o OSPF não diz exatamente como calcular esse custo, então a Cisco criou o próprio método: ela usa uma fórmula simples, 100.000.000 dividido pela largura de banda da interface em bps. Por exemplo, se a interface é de 100 Mbps, o custo vai ser 1. Se for de 1 Gbps, também vai ser 1, porque o valor arredondado ainda dá 1. Em interfaces mais lentas, o custo vai ser maior.
Mas se você quiser, pode mudar esse valor manualmente usando o comando ip ospf cost
. Você pode colocar um valor de 1 até 65535. Essa mudança é feita direto na interface onde você quer controlar o custo. Assim, dá pra forçar o OSPF a preferir ou evitar certos caminhos, mesmo que a largura de banda seja igual.
Você pode alterar o cost de um link OSPF diretamente na interface, é ali que o roteador decide qual será o "peso" (ou custo) daquela interface para o cálculo do SPF.
interface GigabitEthernet0/1
ip ospf cost 50
Rotas preferidas
A seleção da melhor rota para um prefixo segue uma hierarquia clara de preferência baseada no tipo de rota, e só depois entra em cena o custo para desempate. Primeiro o protocolo classifica as rotas possíveis com base na origem do LSA e na posição topológica do prefixo. A ordem de preferência é a seguinte:
Intra-area: rotas aprendidas por LSAs tipo 1 (Router-LSA) ou tipo 2 (Network-LSA), ou seja, que descrevem destinos dentro da mesma área. Essas são as mais preferidas porque vêm diretamente da base de conhecimento local do roteador, sem intermediários.
Inter-area: rotas recebidas por meio de LSAs tipo 3 (Summary-LSA), que são geradas por ABRs para divulgar rotas de uma área em outra. Apesar de envolverem mais hops lógicos, ainda são consideradas mais confiáveis do que rotas externas.
Externas tipo 1 (E1): rotas de fora do domínio OSPF, redistribuídas por um ASBR e divulgadas com LSA tipo 5 e métrica do tipo E1. Nesse caso, o custo final da rota considera a soma do custo até o ASBR mais a métrica externa.
Externas tipo 2 (E2): também originadas em redistribuição, mas com métrica E2. Aqui, o OSPF só considera a métrica externa, ignorando o custo interno até o ASBR. Por isso, são menos preferidas que rotas E1.
Rotas NSSA (N1/N2): aprendidas por LSAs tipo 7 dentro de áreas NSSA e convertidas em LSAs tipo 5 por ABRs. A lógica de seleção é a mesma das externas, N1 soma custos internos e externos; N2 considera só o externo.
Depois que o OSPF identifica as rotas disponíveis e as organiza conforme essa hierarquia, ele compara os custos dentro de cada categoria para escolher a rota final. Por exemplo, entre duas rotas intra-area para o mesmo prefixo, vence a de menor custo acumulado até o destino. O mesmo vale para rotas inter-area, ou entre rotas E1.
OSPF e Loopback
Quando falamos em OSPF, a melhor maneira de garantir que cada roteador fique estável na topologia é criar uma interface loopback antes mesmo de iniciar o processo. A Cisco recomenda explicitamente esse padrão porque a loopback, sendo puramente lógica, nunca cai com falhas de cabo ou porta e, portanto, mantém o protocolo em pleno funcionamento mesmo quando todas as interfaces físicas se alternam entre up e down.
Quando você configura OSPF, cada roteador precisa ter um identificador único, que é o chamado Router ID (RID). Esse ID geralmente é o IP de uma interface loopback, que é um endereço fixo e confiável porque essa interface nunca "cai" como uma interface física pode cair. Para eleger o Router ID, o algoritmo do OSPF usa a seguinte ordem: primeiro usa o endereço IP mais alto em qualquer loopback, caso não exista, o IP mais alto entre as interfaces físicas ativas. Por fim, um valor manual se você usar router-id
.
Se você esquecer a loopback e mais tarde decide criá-la, será preciso reiniciar o processo (ou o roteador) para que o novo RID seja assumido, porque o RID é fotografado apenas na inicialização. Criando a loopback antes, você fixa de forma definitiva essa identidade, e ela será usada em LSAs, na eleição de DR/BDR e em tudo que dependa de um identificador consistente.
Há ainda impacto no design de endereço. Como a loopback não precisa pertencer a nenhuma rede de usuário, costuma-se atribuir a ela um prefixo /32 (host-mask). Isso economiza sub-redes e evita desperdício de espaço de endereçamento.
Operacionalmente a loopback facilita os diagnósticos, sempre há um endereço que pode ser pingado e usado em SNMP, SSH ou testes de rota, mesmo quando interfaces físicas estão em manutenção. Se você optar por anunciar essa rede no OSPF, todos os nós da área aprenderão um prefixo /32
que aponta diretamente para o RID, se preferir mantê-la fora da tabela, basta omitir a declaração correspondente no network
ou aplicar um passive-interface
, poupando ainda mais espaço de endereços.
Por isso o fluxo correto é: crie a loopback com máscara /32, dê ip address 10.255.255.1 255.255.255.255
, depois inicie o processo OSPF. Assim, você já começa com o protocolo estável e evita ter que limpar o processo ou reiniciar o roteador mais tarde.
Para escolher os endereçamentos de loopback que vão ser usados no OSPF, devemos reservar um bloco exclusivo para esse uso, normalmente um bloco que esteja na RFC 1918. Vamos supor que sua empresa usa a rede 10.0.0.0/8 para a rede interna (que é um bloco privado). Em vez de sair escolhendo qualquer endereço IP solto da rede pra colocar nas loopbacks, uma estratégia comum é reservar uma parte alta da rede, por exemplo:
10.255.0.0/16 → reservada só para loopbacks dos roteadores
Isso significa que todos os RIDs e interfaces loopback dos roteadores vão ter endereços dentro dessa faixa, como:
- 10.255.1.1/32 para o R1
- 10.255.2.2/32 para o R2
- 10.255.3.3/32 para o R3
Esse método de configuração evita conflito, já que você está garantindo que ninguém vai usar esses IPs em estações de trabalho ou servidores. Facilita o gerenciamento, se você quiser identificar ou filtrar pacotes que vêm de roteadores, basta olhar os IPs que começam com 10.255
. Ajudam na sumarização, se um dia quiser criar uma rota resumida para todos os roteadores, você pode simplesmente anunciar 10.255.0.0/16
, cobrindo todos de uma vez só.
Por precaução, defina manualmente o Router ID, essa prática nos da maior controle e previsibilidade da Rede.
Outro ponto é decidir se o prefixo deve ou não ser anunciado. Antes, você precisa entender que, ao criar uma interface loopback em um roteador (como 10.255.1.1/32
) ela vai funcionar mesmo que não seja anunciada no OSPF. Isso porque a loopback é uma interface local. Isso já é suficiente para ela servir como Router ID (RID) e Endereço de gerenciamento para SNMP, SSH, etc.
Mas então, vale a pena anunciar esse endereço no OSPF ou não? A resposta depende do seu objetivo. Se você deseja pingar ou acessar o roteador por esse IP de qualquer lugar da rede, então sim, você deve anunciar a loopback no OSPF. Isso faz com que os outros roteadores da rede aprendam o caminho até esse IP, e ele apareça na tabela de roteamento como uma rota de host (/32
).
Agora, se você só quer que esse IP sirva para identificação (RID) e acesso interno, mas não precisa ser acessível pela rede inteira, aí você não precisa anunciar a loopback no OSPF. Nesse caso, pode fazer de duas formas:
Deixe a interface loopback como passive, ou seja, o OSPF sabe que ela existe, mas não tenta formar vizinhanças por ela e nem anuncia para fora.
Coloque a loopback em uma VRF (Virtual Routing and Forwarding) de gestão, que está fora do OSPF. Isso isola o IP da rede de roteamento e o deixa só para acesso administrativo.
A mesma lógica vale para IPv6, escolha um bloco unique-local (por exemplo, fd00:255::/48) e crie uma loopback /128, o RID do OSPFv3 continua sendo IPv4, mas o endereço v6 garante gestão dual-stack.
Normalmente, um roteador tem uma única tabela de roteamento, onde ele guarda todas as rotas da rede. Se você quiser separar redes diferentes, como a rede de usuários e a rede de gestão, normalmente precisaria de roteadores separados ou equipamentos complexos.
Com VRF, isso muda. Você pode criar várias tabelas de roteamento separadas dentro do mesmo roteador. É como se você tivesse vários roteadores virtuais dentro de um só equipamento, e cada um com sua própria tabela, isolada das outras.
Por exemplo:
- VRF Geral → usada para o tráfego normal de dados.
- VRF Gestão → usada só para acessar os roteadores por SSH ou SNMP.
- VRF Clientes → uma para cada cliente, no caso de um provedor.
Essas VRFs não se enxergam entre si, a não ser que você configure uma forma específica de comunicação (como route leaking ou redistribuição).
Neighbor Adjacency
O Neighbor Adjacency é a relação entre dois roteadores que estão diretamente conectados em um mesmo link e que trocaram pacotes Hello. O processo de formação de vizinhança passa por vários estados, e nem todo vizinho necessariamente atinge o estado final (FULL). O nível de adjacência que se estabelece depende do tipo de rede (broadcast, ponto-a-ponto, NBMA etc.) e da função do roteador (como DR, BDR ou roteador comum).
Essa troca de estados é o que permite que os roteadores decidam com quem formar adjacência completa, com quem apenas manter hello, e como sincronizar o LSDB. Abaixo podemos conferir uma tabela de estados do processo de vizinhança:
Estado | Descrição |
---|---|
DOWN | Estado inicial de qualquer vizinho OSPF. Nenhum pacote Hello foi recebido ainda. |
ATTEMPT | Específico para redes NBMA. O roteador ainda não recebeu Hello do vizinho, então envia Hellos unicast em intervalos configurados. |
INIT | Um pacote Hello foi recebido, mas o roteador local ainda não aparece na lista de vizinhos, sem comunicação bidirecional. |
2WAY | O Hello recebido contém a ID do roteador local, indicando que a comunicação bidirecional foi estabelecida. É o fim da negociação em redes broadcast para roteadores que não são DR/BDR. |
EXSTART | Os roteadores negociam quem será o mestre no processo de sincronização da base de dados. O de maior Router ID assume o controle. |
EXCHANGE | Os roteadores trocam pacotes DBD (Database Description), contendo resumos de seus LSDBs. |
LOADING | Após comparar os DBDs, o roteador solicita LSAs que ainda não possui, sincronizando seu LSDB. |
FULL | Estado final: adjacência completa com LSDBs idênticos. Só é alcançado com DR/BDR ou em redes ponto-a-ponto. |
Interfaces Passivas
O comando passive interface
é aplicado dentro do modo de configuração do protocolo de roteamento (router rip, router eigrp, router ospf...) quando queremos que uma determinada porta continue presente na tabela de roteamento, mas deixe de "conversar" com o vizinho naquela ponta.
O efeito exato muda conforme o protocolo, mas a ideia comum é silenciar o tráfego de controle que sairia por ali, poupando banda e evitando formar adjacências ou expor informações em segmentos onde elas não fazem sentido (por exemplo, um link até o provedor ou uma LAN de usuários).
Com essa explicação, cuidado quando você for tornar a interface de rede passiva, já que uma interface passiva não envia Hellos OSPF e não processa nenhum pacote OSPF recebido.
Áreas no OSPF
Quando você olha para uma rede que roda OSPF, pode imaginar um grande mapa de uma cidade. Assim como esse mapa é dividido em bairros, o OSPF divide a rede em áreas. Cada área representa uma parte menor e mais organizada da rede. Apenas os roteadores dentro de uma área conhecem todos os detalhes das rotas ali existentes — como se fossem os moradores daquele bairro que conhecem bem suas ruas. Já os roteadores fora dessa área não enxergam o que acontece lá dentro, sabem apenas como chegar até ela.
No centro da rede fica sempre a área 0, também chamada de backbone. Todas as outras áreas precisam se conectar à área 0, porque o tráfego entre áreas diferentes sempre passa por ela, a área 0 funciona como uma ponte que liga todas as outras áreas. Se por algum motivo uma área não conseguir se conectar diretamente ao backbone, existe uma "gambiarra" chamada virtual link, que permite essa conexão de forma indireta. Mas a regra geral continua sendo clara, todas as áreas devem estar conectadas à área 0.
Os roteadores que estão dentro de uma área são chamados de internos, já os roteadores que ficam entre uma área e a área 0 são chamados de ABR (Area Border Router). Cada ABR mantém uma cópia separada da Base de Estado de Enlace (Link State Database - LSDB) para cada área que ele pertence, resumindo rotas de um lado antes de anunciá-las ao outro. Com isso, quem está dentro de uma área guarda apenas o catálogo daquela área, as mudanças em áreas vizinhas não o obrigam a recalcular tudo, poupando CPU, memória e tempo de convergência.
Existe um limite importante que você deve ficar esperto, o desenho é sempre de dois níveis. Existe um backbone único no alto e várias áreas penduradas nele. Áreas fora do backbone não podem conversar diretamente entre si, o tráfego sobe ao anel, cruza por lá e desce na outra ponta. Esse formato simplifica o controle e evita os loops que poderiam surgir se as áreas laterais trocassem rotas diretamente.
Para o iniciante basta guardar três ideias-chave:
- Área é só um jeito de dividir a base de dados do OSPF, não muda IP nem cabeamento.
- Sempre existe a área 0, ligando todas as outras.
- Cortar a rede em áreas pequenas faz o protocolo escalar com muito menos dor de cabeça. Quando esse trio de conceitos fizer sentido, configurar ABRs, escolher onde resumir rotas e até usar áreas especiais (stub, NSSA) vira apenas detalhe de sintaxe.
Tipos de LSA
Os tipos de LSA que circulam em uma área dependem do tipo da área. Cada tipo de LSA transporta um tipo de informação específico, e o protocolo impõe restrições conforme o perfil da área (normal, stub, totally stubby, NSSA). Aqui vai um resumo do comportamento em cada caso, respeitando a lógica técnica dos materiais de referência.
Nas áreas normais, todos os tipos de LSA são permitidos:
- Tipo 1 (Router-LSA): gerado por todos os roteadores para descrever seus links dentro da área.
- Tipo 2 (Network-LSA): gerado por DRs em redes multiacesso, descreve os roteadores conectados ao segmento.
- Tipo 3 (Summary-LSA): usado pelos ABRs para anunciar prefixos de outras áreas.
- Tipo 4 (ASBR Summary): usado para anunciar o caminho até um ASBR em outra área.
- Tipo 5 (External-LSA): transporta rotas externas ao OSPF, como redistribuições de OSPF, BGP, RIP, etc.
Nas áreas stub, os LSAs tipo 5 são bloqueados, em vez disso, o ABR injeta um LSA tipo 3 com rota default (0.0.0.0/0), mas os tipos 1, 2 e 3 continuam normais.
Nas áreas totally stubby (Cisco), só entram LSAs tipo 1 e 2. O ABR injeta apenas um único LSA tipo 3 com rota default, bloqueando todos os outros LSAs tipo 3 e 5. Os roteadores internos perdem visibilidade de prefixos de outras áreas, além dos externos.
Já nas áreas NSSA (Not So Stubby Area), aceita redistribuição de rotas externas, mas não usam LSA tipo 5. Em vez disso, usam LSA tipo 7, que é convertido em tipo 5 pelo ABR ao sair da NSSA. Os tipos 1, 2, 3 e 7 são permitidos.
Essas distinções são fundamentais para controlar o tamanho da LSDB e o tráfego de controle, especialmente em ambientes grandes ou com roteadores com recursos limitados. O controle de LSAs define o comportamento da área e seu papel dentro do domínio OSPF.
Configurando o OSPF área 0
Configurar OSPF é um pouco mais detalhado do que configurar RIP ou EIGRP. Enquanto esses dois protocolos exigem poucos comandos para funcionar, o OSPF envolve mais passos e mais atenção, principalmente porque ele tem muitas opções. Mas se você focar no essencial — ou seja, em uma configuração básica com uma única área — o processo fica bem mais tranquilo.
Pra começar, você precisa fazer duas coisas:
- Ativar o OSPF no roteador, com um número de processo (esse número pode ser qualquer um, só serve pra identificar o processo no roteador).
- Informar quais redes fazem parte do OSPF e associar cada uma delas a uma área, normalmente a área 0, que é a área de backbone e sempre precisa existir.
Esses são os dois pontos que realmente importam pra uma configuração básica de OSPF em uma rede pequena. Mais pra frente, dá pra explorar outras opções, como múltiplas áreas, tipos de roteadores e ajustes finos de custo e métricas, mas por enquanto isso já é o suficiente pra colocar o OSPF em funcionamento.
Configurando o Ambiente
Antes de começar a configurar o OSPF, temos que configurar o ambiente para nossa rede de exemplo. Vamos começar criando um lab simples usando a topologia da imagem abaixo.
Configurando o Router 1
enable
configure terminal
hostname router1
no ip domain-lookup
!
! Configurar o DHCP:
ip dhcp pool REDE_LOCAL
network 192.168.32.0 255.255.255.0
default-router 192.168.32.1
dns-server 8.8.8.8
!
ip dhcp excluded-address 192.168.32.1
!
exit
conf t
!
interface GigabitEthernet0/0
description LAN
ip address 192.168.32.1 255.255.255.0
no shut
!
interface GigabitEthernet0/1
description OSPF com Bird
ip address 10.253.35.1 255.255.255.252
ip ospf network point-to-point
ip ospf 10 area 0
no shut
!
interface GigabitEthernet0/2
description OSPF com Router2
ip address 10.253.35.6 255.255.255.252
ip ospf network point-to-point
ip ospf 10 area 0
no shut
end
wr
Se você desejar, pode configurar senhas de acesso:
enable
configure terminal
enable secret cisco123
line console 0
password console123
login
exit
line vty 0 4
password vtypass
login
Configurando o Switch do Router 1
Agora vamos configurar o switch:
enable
configure terminal
hostname switch1
# Configurar a interface com o cliente:
interface ethernet0/1
switchport mode access
no shutdown
exit
# Configurar a interface com o router:
interface ethernet0/0
switchport mode access
no shutdown
end
copy running-config startup-config
Se você desejar, pode configurar mais recursos:
# Configurar a senha de modo privilegiado:
enable secret cisco123
# Configurar acesso via console:
line console 0
password console123
login
exit
# Configurar acesso via Telnet/SSH (VTY lines):
line vty 0 4
password vtypass
login
exit
# Configurar a interface VLAN 1 com um endereço IP para gerenciamento remoto:
interface vlan 1
ip address 192.168.1.2 255.255.255.0
no shutdown
# Configurar o gateway padrão (necessário para gerenciar o switch fora da sub-rede local):
ip default-gateway 192.168.1.1
Configurando o Router 2
enable
configure terminal
hostname router2
no ip domain-lookup
!
! Configurar o DHCP:
ip dhcp pool REDE_LOCAL
network 172.16.0.0 255.255.255.0
default-router 172.16.0.1
dns-server 8.8.8.8
!
ip dhcp excluded-address 172.16.0.1
!
exit
conf t
!
interface GigabitEthernet0/0
description LAN
ip address 172.16.0.1 255.255.255.0
no shut
!
interface GigabitEthernet0/1
description OSPF com router1
ip address 10.253.35.5 255.255.255.252
ip ospf network point-to-point
ip ospf 10 area 0
no shut
!
end
wr
Se você desejar, pode configurar senhas de acesso:
enable
configure terminal
enable secret cisco123
line console 0
password console123
login
exit
line vty 0 4
password vtypass
login
Configurando o Switch do Router 2
Agora vamos configurar o switch:
enable
configure terminal
hostname switch1
# Configurar a interface com o router:
interface ethernet0/1
switchport mode access
no shutdown
exit
# Configurar a interface com o cliente:
interface ethernet0/0
switchport mode access
no shutdown
end
copy running-config startup-config
Se você desejar, pode configurar mais recursos:
# Configurar a senha de modo privilegiado:
enable secret cisco123
# Configurar acesso via console:
line console 0
password console123
login
exit
# Configurar acesso via Telnet/SSH (VTY lines):
line vty 0 4
password vtypass
login
exit
# Configurar a interface VLAN 1 com um endereço IP para gerenciamento remoto:
interface vlan 1
ip address 192.168.1.2 255.255.255.0
no shutdown
# Configurar o gateway padrão (necessário para gerenciar o switch fora da sub-rede local):
ip default-gateway 192.168.1.1
Configurando o Loopback e OSPF
No Cisco, a loopback é criada como se fosse mais uma interface, mas puramente lógica. Após entrar no modo de configuração global, dê um nome numérico à interface e atribua um endereço /32
para que ele nunca seja mal interpretado como rede de trânsito.
Loopback e OSPF do Router 1
enable
configure terminal
interface Loopback0
ip address 10.255.0.11 255.255.255.255
router ospf 10 ! escolha qualquer process-ID
router-id 10.255.0.11 ! opcional, mas garante que o RID bata com a loopback
network 192.168.32.0 0.0.0.255 area 0 ! Anunciando minha rede interna conectada no Router 1
passive-interface GigabitEthernet0/0 ! Não propaga e nem espera receber nenhum LSA
end
wr
Loopback e OSPF do Router 2
enable
configure terminal
interface Loopback0
ip address 10.255.0.13 255.255.255.255
router ospf 10 ! escolha qualquer process-ID
router-id 10.255.0.13 ! opcional, mas garante que o RID bata com a loopback
network 172.16.0.0 0.0.0.255 area 0 ! Anunciando minha rede interna conectada no Router 2
passive-interface GigabitEthernet0/0 ! Não propaga e nem espera receber nenhum LSA
end
wr
Loopback e OSPF no BIRD
No Linux, a interface lo
já existe, só precisamos dar a ela um endereço estático e depois ensinar o BIRD a usá-lo como router ID. No sistema (Debian/Ubuntu, por exemplo) adicione o IP e torne-o persistente:
# ParaConfigurar a loopback no modo persistente:
vim /etc/netplan/01-loopback.yaml
network:
version: 2
ethernets:
lo:
addresses:
- 10.255.0.12/32
optional: true
# Configurando ponto a ponto com o router de moto persistente:
vim /etc/netplan/01-ens4.yaml
network:
version: 2
ethernets:
ens4:
dhcp4: no
addresses:
- 10.253.35.2/30
optional: true
# Aplicar:
netplan apply
No /etc/bird.conf
defina o RID e inclua a loopback na área como stub, evitando que ela seja tratada como enlace de trânsito:
log syslog all;
router id 10.255.0.12; # valor fixo – BIRD também aceita definir a partir de uma interface
protocol kernel {
scan time 15;
import all;
export all;
}
protocol device {
scan time 10;
}
protocol ospf {
import all;
export all;
area 0 {
interface "ens4" {
type broadcast;
};
};
}
Reinicie o serviço com birdc configure
(ou systemctl restart bird
). Depois execute birdc show ospf neighbors
para ver se o roteador passou a anunciar o /32
da loopback e usar 10.255.0.21 como router-ID.
$ birdc show ospf neighbors
ospf_v2:
Router ID Pri State DTime Interface Router IP
10.255.0.11 1 Full/PtP 00:38 ens4 10.253.35.1
$ birdc show protocols all
name proto table state since info
kernel1 Kernel master up 00:54:20
Preference: 10
Input filter: REJECT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 2 2 0 --- 0
Export withdraws: 0 --- --- --- 0
device1 Device master up 00:54:20
Preference: 240
Input filter: ACCEPT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0
ospf_v2 OSPF master up 00:54:20 Running
Preference: 150
Input filter: ACCEPT
Output filter: ACCEPT
Routes: 2 imported, 0 exported, 2 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 2 0 0 0 2
Import withdraws: 0 0 --- 0 0
Export updates: 2 2 0 --- 0
Export withdraws: 0 --- --- --- 0
Outra forma de ativar o OSPF
Existem duas maneiras de ativar o OSPF, na maioria das implementações do OSPF, vão existir essas duas maneiras, vai mudar apenas a forma como isso será realizado.
- Configurando o OSPF diretamente na interface
Neste método, você configura OSPF dentro da própria interface, dizendo explicitamente que ela fará parte de uma determinada área OSPF. É como avisar ao roteador "essa interface participa do OSPF, e pertence à área X".
Se você não ativar o OSPF na interface, ele simplesmente não vai funcionar por ali, a interface não enviará pacotes Hello, não formará adjacência, e nada será anunciado.
Em algumas implementações de OSPF, como o BIRD ou o JunOS, você não configura o OSPF dentro da interface, como é feito no Cisco. Em vez disso, você declara diretamente no processo OSPF quais interfaces devem participar, listando os nomes delas no bloco de configuração do protocolo. Isso elimina a etapa de varrer faixas de IP com máscaras coringas, o roteador já sabe exatamente onde ativar o OSPF, porque você informou a interface de forma explícita.
Esse é o método que usamos nas configurações acima.
- Anunciando o bloco IP usado entre os roteadores
Esse é o método tradicional no Cisco IOS. Nele, você informa ao OSPF a faixa de IP usada na comunicação entre os roteadores. Por exemplo, se o Router1 tem o IP10.253.35.5
e o Router2 tem o10.253.35.6
, ambos estão na rede10.253.35.4/30
. Para que o OSPF funcione, é preciso anunciar essa rede no processo OSPF de cada roteador usando o comandonetwork
.
Ao fazer isso, o roteador procura qual interface possui um IP que pertence àquela rede, e ativa o OSPF automaticamente nessa interface. Isso permite que ela envie Hellos, forme adjacência com o vizinho e participe da troca de rotas.
Quando você anuncia a rede ponto a ponto (por exemplo, 10.253.35.4/30) via OSPF, você está inserindo essa rota na tabela de todos os roteadores OSPF da área. Isso acaba permitindo que qualquer roteador naquela área (ou mesmo em áreas redistribuídas) saiba como chegar até aquele link. Isso torna os IPs dessas interfaces roteáveis e acessíveis de qualquer lugar da rede OSPF. Tome cuidado ao fazer isso.
Configurando os dois métodos
Abaixo podemos ver um exemplo do comando network
num Roteador Cisco para anunciar a rede ponto a ponto com outro roteador e assim fazer o OSPF procurar qual interface possui o IP que está na rede que você está anunciando:
router ospf 10
network 10.0.0.0 0.0.0.255 area 0
Configurando a interface para trabalhar com o OSPF
Vamos ver como configurar a interface para funcionar com o OSPF, para que não seja necessário anunciar o bloco de comunicação entre os routers.
# No Cisco:
interface GigabitEthernet0/1
ip address 10.253.35.5 255.255.255.252
ip ospf 10 area 0
ip ospf network point-to-point
# No BIRD:
protocol ospf ospf_v2 {
import all;
export all;
area 0 {
interface "ens4" {
type pointopoint;
};
};
}
# No Juniper:
set interfaces ge-0/0/1 unit 0 family inet address 10.253.35.5/30
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
Tipos de Rede OSPF
O tipos de Rede OSPF é usado para definir como o OSPF enxerga o meio físico ou lógico em que ele está operando. Dependendo da configuração, você elimina o DR/BDR (não sendo necessário), controla como os pacotes Hello são enviados (multicast, unicast, manual) e se a interface tenta formar adjacência com mais de um vizinho ou não.
Os tipos de rede OSPF são:
Tipo de Rede | Multicast? | DR/BDR? | Quando Usar |
---|---|---|---|
broadcast | Sim | Sim | Ethernet tradicional |
point-to-point | Sim | Não | Links seriais ou Ethernet ponto a ponto (como /30) |
non-broadcast | Não | Sim | Frame Relay, ATM, DMVPN sem multicast |
point-to-multipoint | Sim | Não | Topologias hub-and-spoke simplificadas |
Abaixo podemos conferir como configurar o tipo de rede OSPF de uma interface. Por padrão, a Cisco/Juniper trata interfaces Ethernet como broadcast
, que envolve eleição de DR/BDR. Mas em links ponto a ponto (ex: /30 entre dois roteadores), o ideal é forçar o ponit-to-point
.
# No Cisco:
interface GigabitEthernet0/1
ip address 10.253.35.5 255.255.255.252
ip ospf 10 area 0
ip ospf network point-to-point
No JunOS, você define o tipo de rede OSPF usando a opção link-type
na interface OSPF.
# No JunOS:
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 link-type p2p
Outros tipos possíveis no JunOS são:
- broadcast
- non-broadcast
- p2p (point-to-point)
- p2mp (point-to-multipoint)
No BIRD, você define o tipo diretamente dentro do bloco interface:
# No BIRD:
protocol ospf {
import all;
export all;
area 0 {
interface "ens4" {
type pointopoint;
};
};
}
Comandos OSPF no Cisco
Eu esqueci de colocar os comandos para vermos que o OSPF estava funcionando no lab acima, como não tenho mais o lab, vou deixar apenas os comandos.
show ip protocols # mostra quais redes e interfaces participam do OSPF
show ip ospf # mostra o processo OSPF (router-id, áreas, SPF runs)
show ip ospf interface # detalhes por interface (estado OSPF, timers, DR/BDR)
show ip ospf interface brief # resumo das interfaces no OSPF
show ip ospf neighbor # status de adjacência com vizinhos
show ip ospf database # exibe a LSDB (por tipo de LSA)
show ip ospf database router # LSAs tipo 1 (origem de cada roteador)
show ip ospf database network # LSAs tipo 2 (DR em redes broadcast)
show ip ospf database summary # LSAs tipo 3 (áreas diferentes)
show ip route ospf # rotas aprendidas via OSPF