OSPF-Avanado

Prévia do material em texto

Jerônimo Aguiar Bezerra
OSPF 
Avançado 
A RNP – Rede Nacional de Ensino 
e Pesquisa – é qualificada como 
uma Organização Social (OS), 
sendo ligada ao Ministério da 
Ciência, Tecnologia e Inovação 
( M C T I ) e r e s p o n s á v e l p e l o 
Programa Interministerial RNP, 
que conta com a participação dos 
ministérios da Educação (MEC), da 
Saúde (MS) e da Cultura (MinC). 
Pioneira no acesso à Internet no 
Brasil, a RNP planeja e mantém a 
rede Ipê, a rede óptica nacional 
acadêmica de alto desempenho. 
Com Pontos de Presença nas 
27 unidades da federação, a rede 
tem mais de 800 instituições 
conectadas. São aproximadamente 
3,5 milhões de usuários usufruindo 
de uma infraestrutura de redes 
avançadas para comunicação, 
computação e experimentação, 
que contribui para a integração 
entre o sistema de Ciência e 
Tecnologia, Educação Superior, 
Saúde e Cultura. 
Jerônimo Aguiar Bezerra
OSPF 
Avançado 
 
Jerônimo Aguiar Bezerra
Rio de Janeiro
Escola Superior de Redes
2016
OSPF 
Avançado 
Copyright © 2016 – Rede Nacional de Ensino e Pesquisa – RNP 
Rua Lauro Müller, 116 sala 1103 
22290-906 Rio de Janeiro, RJ
Diretor Geral 
Nelson Simões
Diretor de Serviços e Soluções 
José Luiz Ribeiro Filho
Escola Superior de Redes
Coordenador Nacional 
Leandro Marcos Oliveira Guimarães
Edição 
Lincoln da Mata
Coordenador Acadêmico da Área e Administração de Projetos de Redes 
Luiz Carlos Lobo Lobato
Equipe ESR (em ordem alfabética) 
Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlinéa Miranda, Elimária Barbosa, 
Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato , 
Renato Duarte e Yve Marcial.
Capa, projeto visual e diagramação 
Tecnodesign
Versão 
1.0.0
Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de 
conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e 
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a 
pessoas ou bens, originados do uso deste material. 
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Distribuição 
Escola Superior de Redes 
Rua Lauro Müller, 116 – sala 1103 
22290-906 Rio de Janeiro, RJ 
http://esr.rnp.br 
info@esr.rnp.br
Dados Internacionais de Catalogação na Publicação (CIP)
B574o Bezerra, Jerônimo Aguiar 
 OSPF Avançado / Jerônimo Aguiar Bezerra. – Rio de Janeiro: RNP/ESR, 2015. 
 160 p. : il. ; 27,5 cm.
 ISBN 978-85-63630-57-5
 1. OSPF (Open Shortest Path First). 2. Protocolos de rede de computador. 
 3. Telecomunicações – Trafico – Gestão. I. Título.
 CDD 004.62
iii
Sumário
Escola Superior de Redes
A metodologia da ESR vii
Sobre o curso  viii
A quem se destina  ix
Convenções utilizadas neste livro ix
Permissões de uso x
Sobre os autores x
1. Funcionamento do banco de 
dados do OSPF
Entendendo o funcionamento do banco de dados do OSPF 1
Tipos de pacotes OSPF 2
Pacotes Hello 4
Formato do pacote Hello 5
Responsabilidades do protocolo Hello 7
Processo de eleição dos roteadores Designated Router e Backup Designated Router 10
Database Description – DD 13
Link State Request ou LSR 16
Link State Update ou LSU 18
Link State Acknowledgement ou LSAck 19
Transição de Estados no Sincronismo do OSPF 20
Link State Advertisement ou LSA 22
Router LSA 24
iv
Network Summary LSA e ASBR Summary LSA 26
AS External LSA 27
NSSA External LSA 28
Remoção de LSAs 29
Conclusão 31
Comandos OSPF 32
2. Entendendo as áreas do OSPF
Por que o OSPF faz uso do conceito de áreas? 33
Quais são os tipos de áreas e como elas se comportam em um ambiente OSPF 35
Área Backbone 36
Área Normal 37
Área Stub 37
Área Not-So-Stubby ou NSSA 38
Interconectando áreas com Virtual Links 38
Entendendo o LSDB 40
A: Observando o funcionamento do LSDB na Área Backbone 41
A1: Router-LSA e Network-LSA 41
A.2: Summary-LSA 48
A.3: AS External LSA 53
A.4: ASBR Summary LSA 57
A.5: NSSA-LSA 59
A.6: Virtual Links 61
Conclusão 66
Comandos OSPF 66
3. Engenharia de tráfego com OSPF
Introdução 69
Sumarização de rotas 69
Agregação de rotas 76
Métricas 80
Escolha de caminhos pelo OSPF 81
Observe o LSDB de R1 a seguir. 83
Controlando atualizações de roteamento 86
v
Interfaces Passivas (Passive Interfaces) 86
Rotas padrão 89
Filtrando prefixos 92
Lista de Controle de Acesso (Access Control List: ACL) 93
Lista de Prefixos (Prefix-List) 93
Listas de Distribuição (Distributed Lists) 94
Mapas de Rotas (Route-Maps) 94
Filtragem de prefixos Intra-Área OSPF 99
Agregação de LSAs AS-External 103
 Comandos OSPF 106
4. Otimização e tópicos avançados
Introdução 109
Escalabilidade e Estabilidade do OSPF 110
Incremental OSPF 110
Propriedade 1 113
Propriedade 2 117
Propriedade 3 119
Graceful Restart 121
BFD para OSPF 126
Supressão de Prefixos 133
Monitorando o OSPF com a RFC 4750: OSPF Version 2 MIB 142
Explorando a tabela ospfGeneralGroup (Variáveis Globais) 146
Explorando a tabela ospfAreaTable 148
Explorando a tabela ospfStubAreaTable 150
Explorando a tabela ospfLsdbTable 151
Explorando a tabela ospfHostTable 152
Explorando a tabela ospfIfTable 153
Explorando a tabela ospfVirtIfTable 156
Explorando a tabela ospfNbrTable 156
Explorando a tabela ospfAreaAggregateTable 158
Conclusão 160
Comandos OSPF 160
vi
vii
A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) 
responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunica-
ção (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências 
em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e 
unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do 
corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicá-
veis ao uso eficaz e eficiente das TIC. 
A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto 
de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e 
Governança de TI.
A ESR também participa de diversos projetos de interesse público, como a elaboração e 
execução de planos de capacitação para formação de multiplicadores para projetos edu-
cacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil 
(UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de 
cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na 
aprendizagem como construção do conhecimento por meio da resolução de problemas típi-
cos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza 
teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não 
apenas como expositor de conceitos e informações, mas principalmente como orientador do 
aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. 
A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema 
semelhantes às encontradas na prática profissional, que são superadas por meio de análise, 
síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do pro-
blema, em abordagem orientada ao desenvolvimento de competências. 
Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno paraas 
atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de apren-
dizagem não é considerada uma simples exposição de conceitos e informações. O instrutor 
busca incentivar a participação dos alunos continuamente. 
Escola Superior de Redes
viii
As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das 
atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de 
estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atua-
ção do futuro especialista que se pretende formar. 
As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo 
para as atividades práticas, conforme descrição a seguir:
Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). 
O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema 
da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor 
levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando 
a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o 
aluno se coloque em posição de passividade, o que reduziria a aprendizagem. 
Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). 
Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e 
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto 
no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e 
oferecer explicações complementares. 
Terceira etapa: discussão das atividades realizadas (30 minutos). 
O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, 
devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a 
comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, 
estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem 
soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.
Sobre o curso 
O curso descreve os detalhes do funcionamento do protocolo OSPF, permitindo ao aluno 
entender como o OSPF monta sua hierarquia em áreas e quais mensagens e tipos de 
pacotes são utilizados. Além disso, serão apresentadas alternativas para trabalhar com 
engenharia de tráfego, serão apresentados modos de como mudar as métricas e forçar 
o roteamento de tráfego por caminhos mais otimizados. Também serão apresentadas 
técnicas para controlar a redistribuição de prefixos utilizando os mapas de rotas (ou 
route-maps). O curso termina com uma sessão de sugestões de otimizações para a conver-
gência do OSPF além de apresentar o SNMP como uma ferramenta de monitoramento do 
ambiente OSPF. Ao final do curso o aluno estará capacitado a:
 6 Descrever o funcionamento do OSPF
 6 Descrever os tipos de pacotes OSPF
 6 Descrever quais são e como são utilizados os LSA (Link State Advertisements)
 6 Descrever quais são os estados possíveis de um roteador OSPF
 6 Distinguir os tipos de áreas existentes
 6 Projetar e justificar quais tipos de área deseja utilizar
 6 Entender o porquê de cada estado de cada banco de dados por área
 6 Entender as técnicas de Engenharia de Tráfego com OSPF
 6 Entender e configurar ajustes finos avançados no OSPF
ix
 6 Entender o processo de escolha de rotas do OSPF 
 6 Entender Incremental OSPF
 6 Entender Graceful Restart
 6 Configurar BFD para OSPF
 6 Configurar Supressão de Prefixos
 6 Implementar Monitoramento da MIB para OSPF
A quem se destina 
Profissionais de TI que administram redes TCP/IP baseadas no protocolo OSPF e que já 
tenham um conhecimento básico do protocolo OSPF. Estudantes de Ciência da Computação 
interessados em aprofundar os conhecimentos em protocolo de roteamento OSPF. 
Convenções utilizadas neste livro
As seguintes convenções tipográficas são usadas neste livro:
Itálico 
Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto. 
Largura constante
 
Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída 
de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem 
o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).
Conteúdo de slide q 
Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula. 
Símbolo w 
Indica referência complementar disponível em site ou página na internet.
Símbolo d 
Indica um documento como referência complementar.
Símbolo v 
Indica um vídeo como referência complementar. 
Símbolo s 
Indica um arquivo de aúdio como referência complementar.
Símbolo 
Indica um aviso ou precaução a ser considerada.
Símbolo p 
Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao 
entendimento do tema em questão.
Símbolo l 
Indica notas e informações complementares como dicas, sugestões de leitura adicional ou 
mesmo uma observação.
x
Permissões de uso
Todos os direitos reservados à RNP. 
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. 
Exemplo de citação: TORRES, Pedro et al. Administração de Sistemas Linux: Redes e Segurança. 
Rio de Janeiro: Escola Superior de Redes, RNP, 2013.
Comentários e perguntas
Para enviar comentários e perguntas sobre esta publicação: 
Escola Superior de Redes RNP 
Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo 
Rio de Janeiro – RJ – 22290-906 
E-mail: info@esr.rnp.br
Sobre os autores
Jerônimo Aguiar Bezerra é mestre em Mecatrônica e Bacharel em Ciência da Computação 
pela Universidade Federal da Bahia, Jeronimo Aguiar Bezerra tem vasta experiência com 
redes de computadores, sistemas operacionais, VoIP e GNU/Linux. Possuindo algumas cer-
tificações de mercado, como Cisco, Juniper e Linux LPI, “Jab” - como é conhecido - trabalhou 
por 9 anos na Universidade Federal da Bahia (UFBA), onde participou ativamente de diver-
sos projetos de larga escala, como a implementação da Rede REMESSA e do Ponto de Troca 
de Tráfego da Bahia. Jab esteve envolvido com redes acadêmicas e comerciais pelos últimos 
13 anos, com passagem pela Rede Nacional de Ensino e Pesquisa (RNP) e tendo feito parte 
de Grupos de Trabalho do IETF.
1
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
 
 
ob
je
tiv
os
conceitos
1
Funcionamento do banco de 
dados do OSPF
Descrever o funcionamento do OSPF; Descrever os tipos de pacotes OSPF; 
Descrever quais são e como são utilizados os Link State Advertisements; Descrever 
quais são os estados possíveis de um roteador OSPF. 
Funcionamento do protocolo OSPF; Tipos de pacotes OSPF; Transição de Estados 
no Sincronismo do OSPF; Link State Advertisement ou LSA; Router LSA; Network LSA; 
Network Summary LSA; ASBR Summary LSA; AS External LSA; NSSA External LSA; 
Remoção de LSAs.
 
Entendendo o funcionamento do banco de dados do OSPF
q 1 OSPF está definido na RFC 2328 (atualmente usa-se a versão 2 para IPv4 
e versão 3 para IPv6). 
 1 Funcionamento se baseia em um banco de dados topológico.  
 1 Existe apenas um banco de dados topológico por área (chamado de Link-State 
Database ou LSDB). 
 1 Todos os roteadores da área têm de ter o mesmo LSDB. 
 1 Banco de dados criados a partir da troca de mensagens Link State Advertisements (LSAs). 
 1 Roteadores enviam LSAs com informações de enlaces conectados e seus custos. 
 1 Algoritmo SPF utilizado para calcular as rotas. 
 1 Cinco tipos de pacotes OSPF existem para fazer a troca das mensagens LSA. 
O funcionamento do protocolo OSPF se baseiano banco de dados topológico (ou Link-State 
Database – LSDB), criado com informações dos enlaces de todos os roteadores que fazem 
parte da mesma área hierárquica, ou seja, todos os roteadores de cada área precisam 
manter um banco de dados síncrono para garantir o roteamento adequado dos pacotes IP. 
É através desse banco de dados topológico que o processo do OSPF calcula o menor 
caminho para cada destino, utilizando o algoritmo SPF Short Path First. O modo de funcio-
namento desse algoritmo foi detalhado e exemplificado na sessão de aprendizagem 3 do 
curso "Protocolos de Roteamento IP".
SPF – Short Path First
Ou algoritmo de 
Dijkstra. Criado por 
Edsger Dijkstra 
em 1956.
2
 
O
SP
F 
Av
an
ça
do
O banco de dados topológico do OSPF é criado a partir dos LSAs, ou Link State Advertisements, 
que são as estruturas de dados responsáveis pelas informações topológicas dos roteadores 
OSPF, ou seja, contém informações sobre o estado de cada enlace pelo qual um determinado 
roteador é responsável. Nas mensagens LSA estão indicados o prefixo IP e a máscara de 
subrede do enlace, qual o roteador responsável pelo prefixo, qual é a métrica (ou custo) para 
alcançar aquele destino, um tempo de expiração e outras informações.
É através dessas informações que o algoritmo SPF define qual é o melhor caminho para 
alcançar um destino IP. Após essa definição, uma rota IP é criada e enviada para o software 
gerenciador da tabela de rotas (Plano de Controle do roteador) decidir se vai ou não instalar 
na tabela de rotas.
Para entender como o banco de dados topológico é montado e sincronizado, é impor-
tante conhecer os tipos de pacotes OSPF existentes, como os pacotes funcionam e em que 
momento eles são utilizados.
Tipos de pacotes OSPF
qSincronização do banco de dados OSPF ocorre a partir de cinco pacotes OSPF:
 1 Hello. 
 1 DD: database Description. 
 1 LSR: link State Request. 
 1 LSU: link State Update. 
 1 LSAck: link State Acknowledgement. 
O protocolo OSPF, diferentemente do RIP e do BGP, opera diretamente sobre o protocolo 
IP (usando o número de protocolo 89), ou seja, não utiliza o protocolo TCP para garantir a 
consistência dos dados trocados. Então, cabe ao próprio protocolo OSPF definir os meca-
nismos de controle e garantia na troca de informações entre os roteadores OSPF. Entre 
outros métodos, o OSPF utiliza confirmação de recebimento, controle de versão por registro 
e números de sequência.
De acordo com a RFC 2328, existem cinco pacotes OSPF que rodam sobre o protocolo IP e 
são responsáveis pelas operações do OSPF, cada método com sua abordagem de controle 
e garantia. Esses cinco pacotes OSPF serão detalhados a seguir e seus cabeçalhos serão 
apresentados. Porém, todos compartilham de um cabeçalho comum, então é importante 
detalhá-lo antecipadamente. Observe na figura 1.1 o formato desse cabeçalho, que possui 
nove campos e 24 bytes de tamanho total sem autenticação (se utilizar autenticação MD5, 
são 40 bytes).
qTodos os cinco pacotes OSPF contêm um cabeçalho comum de 24 bytes (sem autenti-
cação com MD5) ou 40 bytes (com autenticação com MD5):
3
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
Versão=2
32 bits
8 bits 8 bits 8 bits 8 bits
Tipo Tamanho do Pacote
Autenticação
Autenticação
Tipo de AutenticaçãoChecksum
Area ID
Router ID
Os campos estão detalhados a seguir:
 1 Versão: para o protocolo IPv4, a versão atual do protocolo OSPF é a versão 2; para IPv6 é 
a versão 3;
 1 Tipo: identifica um dos cinco pacotes OSPF (Hello (1), DD(2), LSR(3), LSU(4), LSAck(5));
 1 Tamanho do Pacote: tamanho do pacote OSPF em Bytes, somando o cabeçalho e o con-
teúdo, sem contar com a mensagem de autenticação MD5;
 1 Router ID: endereço IP selecionado pelo processo OSPF para identificar o roteador. 
Geralmente está associado ao endereço IP da interface Loopback ou é configurado 
manualmente;
 1 Area ID: identifica a área OSPF;
 1 Checksum: valor de checksum do pacote OSPF, utilizado para verificar se o pacote está 
íntegro ou não na sua recepção. Usa o mesmo algoritmo do checksum do pacote IP;
 1 Tipo de Autenticação: informa qual esquema de autenticação está sendo utilizado. Pode 
assumir os seguintes valores:
 2 0: Sem autenticação;
 2 1: Autenticação simples, utilizando texto sem criptografia. Pode utilizar senhas de até 
oito caracteres. Nesse tipo de autenticação, os dois campos Autenticação acima arma-
zenam o valor da senha, como se fossem um único campo;
 2 2: Autenticação criptográfica. Nesse caso, os dois campos Autenticação assumem o 
seguinte formato: 
Número de Sequência Criptográfico
TamanhoKey ID0x0000
 3 Key ID: identifica a chave a ser utilizada (várias chaves são possíveis na configu-
ração OSPF);
 3 Tamanho: tamanho da mensagem criptográfica (digest). Esse tamanho não está 
incluso no tamanho informado anteriormente no campo Tamanho do Pacote;
 3 Número de Sequência Criptográfico: utilizado para evitar ataques do tipo Replay, 
por isso fica sempre incrementando.
 2 Além dessas modificações no formato dos campos Autenticação do cabeçalho, o cabe-
çalho é aumentado com mais um campo, de 16 bytes, onde a mensagem digest do MD5 
é inserida. Caso a autenticação com MD5 seja utilizada, o cabeçalho OSPF passa de 24 
bytes para 40 bytes. No final, o cabeçalho OSPF completo com autenticação MD5 teria a 
estrutura apresentada na figura 1.3.
Figura 1.1 
Cabeçalho OSPF 
compartilhado.
Figura 1.2 
Informações de 
Criptografia do 
cabeçalho OSPF 
para MD5.  Os 
dois campos 
Autenticação viram 
novos campos.
4
 
O
SP
F 
Av
an
ça
do
Número de Sequência Criptográfico
Digest MD5
TamanhoKey ID0x0000
Versão=2
32 bits
8 bits 8 bits 8 bits 8 bits
Tipo Tamanho do Pacote
Tipo de AutenticaçãoChecksum
Area ID
Router ID
q 1 Pacotes OSPF usam o protocolo IP com TTL de “1”;
 1 IP de origem do pacote OSPF é sempre o IP da interface conectada à área, não o 
Router-ID;
 1 IP de destino pode ser o endereço IP do roteador adjacente ou um dos grupos multi-
cast definidos: allSPFRouters (224.0.0.5) ou AllDRouters (224.0.0.6).
É importante ressaltar que, por tratar apenas de adjacências, todos os pacotes IP utilizados 
pelo OSPF são criados para serem enviados apenas para os roteadores adjacentes e, por 
isso, são criados com o campo Time to Live (TTL) do pacote IP configurado como "1". Isso 
garante que os pacotes não serão roteados para outras redes da qual o roteador OSPF não 
faz parte.
O endereço IP de origem dos pacotes OSPF é sempre o endereço IP da interface de rede 
onde existe a adjacência, e o endereço IP de destino pode ser o endereço IP do roteador 
OSPF adjacente ou um endereço IP multicast: AllSPFRouters (224.0.0.5) ou AllDRouters 
(224.0.0.6).
A seguir, os pacotes OSPF e o uso serão detalhados.
Pacotes Hello
qPacotes Hello possuem diversas funções:
 1 Descobrir roteadores OSPF adjacentes. 
 1 Estabelecer adjacências com esses roteadores. 
 1 Manter as adjacências. 
 1 Detectar falhas de enlaces e roteadores. 
 1 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em 
redes tipo Broadcast e NBMA. 
 1 Utiliza o grupo Multicast AllSPFRouters (224.0.0.5) em redes Broadcast e NBMA. 
Figura 1.3 
Cabeçalho OSPF 
completo com 
Autenticação MD5.
5
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
Relembrando:  O OSPF pode funcionar em três tipos diferentes de rede:
 1 Redes Ponto-a-Ponto: conecta um par de roteadores; 
 1 Redes Broadcast: suportam múltiplos roteadores e endereço IP que 
representam todos osroteadores da rede (endereço Broadcast); 
 1 Redes Non-Broadcast: suportam múltiplos roteadores, mas não suportam 
broadcast. No contexto do OSPF, podem ser operadas de duas maneiras: 
 2 Simulação de uma rede Broadcast na rede Non-Broadcast, denominada 
non-broadcast multi-access ou NBMA; 
 2 Tratando a rede como uma coleção de enlaces ponto-a-ponto, denominada 
redes Ponto-a-Multiponto. 
Apesar de ser um tipo de pacote do OSPF, o Hello também é considerado um protocolo por 
si só. Esse protocolo possui as seguintes responsabilidades:
 1 Descobrir roteadores OSPF adjacentes; 
 1 Estabelecer adjacências com esses roteadores; 
 1 Manter as adjacências; 
 1 Detectar falhas de enlaces e roteadores; 
 1 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em redes 
tipo Broadcast e NBMA. 
Esse é considerado o principal pacote OSPF, pois é a partir dele que todas as descobertas e 
adjacências são criadas, além de ser o responsável por detectar falhas de enlaces e rote-
adores. Por ser o primeiro pacote OSPF a ser utilizado, funciona enviando pacotes Hello 
para o endereço IP multicast AllSPFRouters (224.0.0.5).  Os roteadores OSPF que recebem o 
pacote Hello enviam outro pacote Hello de volta para iniciar as adjacências.
Formato do pacote Hello
A figura 1.4 apresenta o pacote Hello. Observe que o cabeçalho OSPF apresentado anterior-
mente é simplificado, mostrando apenas o número que representa o tipo do pacote Hello, 
que é o tipo “1”.
6
 
O
SP
F 
Av
an
ça
do
Intervalo de Roteador Morto
Designated Router
Backup Designated Router
Vizinhos Ativos
Vizinhos Ativos
 . . .
PrioridadeOpções Intervalo Hello
32 bits
8 bits 8 bits 8 bits 8 bits
Tipo=1
Máscara de sub-rede
Cabeçalho OSPF
Os campos estão detalhados a seguir:
 1 Máscara de sub-rede: máscara de sub-rede da interface que está enviando o pacote 
Hello. Essa máscara deve ser a mesma em todas as interfaces dos roteadores conectados 
no mesmo segmento, por exemplo, na mesma VLAN ou no enlace serial;
 1 Intervalo Hello: tempo em segundos entre o envio dos pacotes Hello. O valor tem de ser 
o mesmo nos roteadores conectados no mesmo segmento. Em caso de discrepâncias, a 
adjacência não será estabelecida; 
 1 Opções: existem cinco tipos de opções definidas na RFC 2328. Essas opções são utili-
zadas para estender as capacidades do roteador OSPF, além de informar outros rotea-
dores dessas capacidades. As possibilidades são apresentadas a seguir:
 2 E-bit: descreve como os LSA AS-External são anunciados na rede; 
 2 MC-bit : descreve se os datagramas IP multicast são enviados de acordo com a RFC 
1584 (Multicast OSPF); 
 2 N/P bit: esse bit descreve como manipular os LSAs do Tipo 7; 
 2 EA bit: descreve o interesse do roteador para receber e encaminhar LSA 
External-Attributes; 
 2 DC bit: descreve se o roteador manipula circuitos sob demanda. 
 1 Prioridade: utilizado para a eleição do DR (Designated Router) e BDR (Backup Designated 
Router) em redes Broadcast e NBMA. Prioridade “0” significa que o roteador não é ele-
gível para virar DR ou BDR. O roteador com a maior prioridade é eleito o DR; 
 1 Intervalo de Roteador Morto (Dead Interval): intervalo em segundos para definir que 
o roteador adjacente está desconectado da rede e assim encerrar a adjacência. Assim 
como o “Intervalo Hello”, o valor tem de ser o mesmo nos roteadores conectados no 
mesmo segmento. Em caso de discrepâncias, a adjacência não será estabelecida; 
Figura 1.4 
Pacote Hello com 
o cabeçalho OSPF 
simplificado.
7
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
 1 Designated Router: endereço IP da interface do DR no segmento de rede (não o Router-ID). 
Caso não seja uma rede tipo Broadcast ou NBMA, esse campo é preenchido com 0.0.0.0; 
 1 Backup Designated Router: endereço IP da interface do BDR no segmento de rede (não 
o Router-ID). Caso não seja uma rede tipo Broadcast ou NBMA, esse campo é preenchido 
com 0.0.0.0; 
 1 Vizinhos Ativos: lista dos roteadores vizinhos do qual o roteador OSPF que está enviando 
o pacote recebeu pacotes Hello válidos. Em redes do tipo Broadcast e NBMA, são listados 
todos os roteadores OSPF que fazem parte do segmento. Em redes ponto-a-ponto, o ende-
reço IP do roteador remoto é informado nesse campo. 
Responsabilidades do protocolo Hello
O protocolo Hello é responsável por um conjunto grande de tarefas em uma rede OSPF, con-
forme citado anteriormente. Então, de posse das informações sobre os campos do pacote 
Hello, as principais atividades terão seu funcionamento detalhado a seguir.
Descobrir roteadores OSPF adjacentes e estabelecer adjacências
q 1 Protocolo Hello é utilizado para descobrir e estabelecer as adjacências. 
 1 As adjacências OSPF são iniciadas logo após um roteador OSPF detectar outro na rede. 
 1 A figura 1.5 será usada para exemplificar o estabelecimento das adjacências. 
No momento em que o roteador OSPF finaliza sua inicialização e habilita suas interfaces, 
o processo OSPF começa a enviar pacotes Hello por todas as interfaces que estão configu-
radas para fazerem parte do OSPF. Considere a topologia na figura a seguir.
s1/0
10.1.1.0/24
R3 R4
s0/0
q 1 Nesse exemplo, ambos os roteadores estão configurados na Área Backbone ou 
Área 0.0.0.0; 
 1 Pacotes Hello são enviados; 
 1 Primeiro pacote não possui o campo “Vizinho Ativo” (Active Neighbor); 
 1 DR e BDR não são utilizados em enlaces seriais. 
Ambos os roteadores R3 e R4 estão conectados por um enlace serial, utilizando o endereça-
mento IP 10.1.1.0/24, onde R3 possui IP 10.1.1.1 e R4 possui IP 10.1.1.2. Suponha que o rote-
ador R4 acabou de ser ligado e configurado, e suponha também que ambos os roteadores 
foram configurados com OSPF nas interfaces mostradas, todas na Área Backbone (também 
conhecida como Área 0.0.0.0). No momento em que R4 inicia seu processo OSPF, suas estru-
turas de dados são criadas, porém o banco de dados topológico está vazio. O primeiro passo 
é enviar pacotes Hello pela interface serial 0/0.
O primeiro pacote OSPF seria montado como está na figura 1.6. Observe como os campos 
do pacote Hello foram preenchidos:
Figura 1.5 
Topologia de 
Exemplo para 
exemplificar a 
funcionamento do 
protocolo Hello.
8
 
O
SP
F 
Av
an
ça
do
Cabeçalho comum:
 1 OSPF Version: 2; 
 1 Type: 1 (Pacote Hello); 
 1 Packet Length: 44 (24 bytes do cabeçalho OSPF mais 20 bytes do pacote Hello); 
 1 Source OSPF Router ou Router ID: 10.1.1.2 (IP da interface); 
 1 Area ID: 0.0.0.0, conhecida como Área Backbone; 
 1 Auth Type: null, ou seja, sem autenticação. 
Pacote Hello:
 1 Network Mask: 255.255.255.0 (pois a rede é 10.1.1.0/24); 
 1 Hello Interval: (intervalo entre os Hellos): 10 segundos; 
 1 Router Priority: 1; 
 1 Router Dead Interval: 40 segundos; 
 1 Designated Router: 0.0.0.0 (enlace serial não tem DR); 
 1 Backup Designated Router: 0.0.0.0 (enlace serial não tem BDR). 
Podemos observar que o campo de Vizinhos Ativos não está presente, pois o roteador 
R4 ainda não conhece o roteador remoto.  
qR4 envia o primeiro pacote Hello: 
Open Shortest Path First
 OSPF Header
OSPF Version: 2
Message Type: Hello Packet (1)
Packet Length: 44
Source 0SPF Router: 10.1.1.2 (10.1.1.2)
Area ID: 0.0.0.0 (Backbone)
Packet Checksum: 0xe19b [correct]
Auth Type: Null
Auth Data (none)
 OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x12 (L, E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
Após receber o pacote Hello vindo de R4 (10.1.1.2), o R3 envia um pacote Hello,conforme 
figura 1.7.
q 1 R3 envia seu primeiro pacote Hello, porém após receber o Hello do R4 (nesse exemplo); 
 1 Campo Vizinho Ativo ou Active Neighbor é preenchido a partir do Hello do roteador R4; 
Figura 1.6 
Captura do 
primeiro pacote 
Hello enviado 
por R4.
9
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Open Shortest Path First
 OSPF Header
OSPF Version: 2
Message Type: Hello Packet (1)
Packet Length: 48
Source OSPF Router: 10.1.1.1 (10.1.1.1)
Area ID: 0.0.0.0 (Backbone)
Packet Checksum: 0xd695 [correct]
Auth Type: Null
Auth Data (none)
 OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x12 (L, E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
Active Neighbor: 10.1.1.2
Open Shortest Path First
 OSPF Header
 OSPF Version: 2
 Message Type: Hello Packet (1)
 Packet Length: 48
 Source OSPF Router: 10.1.1.2 (10.1.1.2)
 Area ID: 0.0.0.0 (Backbone)
 Packet Checksum: 0xd695 [correct]
 Auth Type: Null
 Auth Data (none)
 OSPF Hello Packet
 Network Mask: 255.255.255.0
 Hello Interval: 10 seconds
 Options: 0x12 (L, E)
 Router Priority: 1
 Router Dead Interval: 40 seconds
 Designated Router: 0.0.0.0
 Backup Designated Router: 0.0.0.0
 Active Neighbor: 10.1.1.1
 
Observe que o R3 envia um pacote Hello similar, porém com campo Source OSPF Router 
indicando seu endereço IP (10.1.1.1) e com o campo Active Neighbor com o valor 10.1.1.2. 
Isso ocorre pois R3 recebeu o pacote Hello vindo do R4. Na próxima vez que o R4 enviar um 
pacote Hello, o campo Active Neighbor estará presente (conforme a figura 1.8). Ter o campo 
Active Neighbor no pacote Hello significa que ambos os roteadores concordam em estabe-
lecer a adjacência. Outros pontos que requerem atenção:
Figura 1.7 
Captura do pacote 
Hello de R3 (Source 
OSPF Router: 
10.1.1.1
Figura 1.8 
Captura do pacote 
Hello de R4 agora 
informando ter 
visto R3.
10
 
O
SP
F 
Av
an
ça
do
 1 Na figura 1.6, o Packet Length tinha 44 bytes, porém nas figura 1.7 e figura 1.8, tem 48 
Bytes. Isso se deve ao fato de que o campo Active Neighbor estava presente com o ende-
reço IP do vizinho nas figura 1.7 e figura 1.8 (lembre-se de que o endereço IPv4 possui 
4 bytes de tamanho, ou 32 bits); 
 1 A adjacência só foi estabelecida devido aos roteadores possuírem as mesmas configurações 
de temporizadores (Hello Interval e Router Dead Interval) e área (0.0.0.0).  
q 1 Observe os campos Packet Length: por que mudou? 
 1 Para evitar problemas ao criar adjacências no OSPF, garanta que os temporizadores, 
área ID e máscara de subrede estejam sempre de acordo em todos os roteadores OSPF. 
Processo de eleição dos roteadores Designated Router e Backup 
Designated Router
q 1 Redes Broadcast e NBMA precisam ter um DR e um BDR por questões 
de escalabilidade. 
 1 Roteadores da área somente vão sincronizar com o DR. 
 1 Três tipos de roteadores OSPF na área: 
 2 Designated Router (DR). 
 2 Backup Designated Router (BDR). 
 2 DR Others (DROther). 
 1 Grupo Multicast AllDRouters (224.0.0.6) criado para comunicação com o DR e o BDR. 
No cenário do exemplo anterior, por ser uma rede ponto-a-ponto, o processo de estabeleci-
mento de adjacência foi bastante simplificado, uma vez que em circuitos ponto-a-ponto só 
temos dois roteadores envolvidos. Porém, em redes tipo Broadcast ou NBMA, por questões 
de escalabilidade, o processo requer etapas extras, para que sejam escolhidos os rotea-
dores Designated Router e Backup Designated Router.
Esses papéis existem nas redes Broadcast e NBMA para servirem de centralizadores de 
atualização das informações topológicas, evitando assim que todos os roteadores tenham 
de sincronizar seus bancos de dados com todos os outros roteadores da mesma sub-rede, 
melhorando a escalabilidade do OSPF, além de reduzir a quantidade de mensagens tro-
cadas. Nesses casos, teremos três papéis:
 1 Designated Router (DR); 
 1 Backup Designated Router (BDR); 
 1 DR Others (DROther). 
Apenas o DR tem o papel de sincronizar o banco de dados topológico com os demais. Agora, 
em caso de alterações na rede, os roteadores DROthers terão de notificar o DR e o BDR 
dessas alterações, e o DR atualizará o banco de dados dos demais roteadores da rede. Para 
que o DROthers possam notificar apenas o DR e o BDR, um novo grupo multicast foi criado, 
chamado de AllDRouters (224.0.0.6). Apesar de apenas o DR ser responsável por encami-
nhar as atualizações recebidas para os demais roteadores OSPF da rede, é importante que 
o BDR também seja notificado, uma vez que este será o responsável por substituir o DR em 
caso de falha.
11
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
Para exemplificar o processo de escolha do DR e do BDR em uma rede Broadcast, vamos 
utilizar a topologia proposta na figura 1.9.
R1
f0/0
f0/0
f0/0
10.1.0.0/24
SW1
1 2
3
R2
R3
Nessa topologia, o roteador R1 possui endereço IP 10.1.0.1, o roteador R2 possui endereço 
10.1.0.2 e o roteador R3 possui endereço 10.1.0.3. O switch (sw1) na figura 1.9 atua sem con-
figuração especial. O processo OSPF em cada roteador está configurado para operar apenas 
na interface fastEthernet 0/0. Supondo que os roteadores R1 e R2 são inicializados e o R3 
permanece desligado, o processo ocorrerá da seguinte maneira:
a. Ambos os roteadores, ao terminarem de inicializar o processo OSPF, vão verificar se 
na rede já foram definidos o DR e/ou o BDR. Caso verifiquem que já foram definidos, o 
roteador aceita a escolha. Essa verificação é feita através dos pacotes Hello no grupo 
multicast AllSPFRouters (224.0.0.5), observando os campos Designated Router e Backup 
Designated Router; 
b. Nesse exemplo, como ambos foram recém-inicializados e não existem outros roteadores, 
ambos os roteadores enviarão pacotes Hello sem o campo Active Neighbors. Nesse momento, 
os campos Designated Router e Backup Designated Router estão preenchidos com 0.0.0.0; 
c. Ao receberem o pacote Hello, cada roteador passará a enviar os próximos pacotes Hello 
com o campo Active Neighbors indicando o IP do roteador remoto; por exemplo, R2 vai 
enviar o pacote com Router-ID 10.1.0.2 e Active Neighbor 10.1.0.1;  
d. Nesse momento, o processo de escolha do BDR é iniciado. Caso algum roteador tenha 
preenchido o próprio IP no campo Backup Designated Router, aquele com a maior Router 
Priority será escolhido. Em caso de empate, aquele com o endereço IP mais alto será 
o escolhido. Caso nenhum roteador tenha preenchido, o roteador com a maior Router 
Priority será escolhido. Novamente, em caso de empate, aquele com o endereço IP mais 
alto será escolhido. Após esse processo, nesse exemplo, o R2 será escolhido tempora-
riamente como BDR, pois ambos estão com a Router Priority configurada com o valor 
padrão (1) e o Router-ID de R2 é maior que o Router-ID de R1; 
Figura 1.9 
Rede tipo 
Broadcast.
12
 
O
SP
F 
Av
an
ça
do
e. Após a escolha do R2 como BDR, o processo de escolha do DR é iniciado. Caso mais de 
um roteador tenha preenchido o próprio IP no campo Designated Router, aquele com a 
maior Router Priority será escolhido. Caso ambos tenham o mesmo valor de prioridade, 
aquele com o endereço IP mais alto será eleito o DR. Caso apenas um roteador tenha 
preenchido, esse será considerado o DR. Se nenhum roteador tiver preenchido o campo 
de Designated Router,o BDR é escolhido para ser o DR. Nesse caso, o R2 também será 
considerado o Designated Router desse segmento; 
f. Como o DR e o BDR não podem estar associados ao mesmo roteador, uma nova eleição 
para o BDR é estabelecida, seguindo os passos detalhados no passo D. Com isso, R1 será 
escolhido BDR do segmento; 
g. Após a escolha do novo BDR, o DR e o BDR ficarão com seus papéis até que o processo 
OSPF seja forçado pelo administrador a acontecer novamente ou em caso de queda de 
algum dos dois. Se o DR cair, o BDR assumirá o papel de DR e uma eleição para o BDR 
acontecerá. Caso o BDR caia, apenas uma eleição para BDR acontecerá;
h. Caso o administrador da rede inicialize o roteador R3 agora, este vai observar nos pacotes 
Hello que o DR e o BDR já estão definidos, logo ele se caracterizará como DROther, esta-
belecendo adjacências com o DR e o BDR.
q 1 Roteadores, ao entrarem na rede, verificam se já há um DR e/ou um BDR:
 2 Checam os campos Designated Router e Backup Designated Router do pacote Hello; 
 1 Caso positivo, aceitam a escolha; 
 1 No exemplo, não existem outros roteadores, então iniciam da forma normal; 
 1 Enviam pacotes Hello sem o campo Active Neighbors; 
 1 Campos Designated Router e Backup Designated Router preenchidos com 0.0.0.0; 
 1 Ao receber um pacote Hello, campo Active Neighbors passa a conter o IP do roteador 
remoto; 
 1 Processo de escolha do BDR é iniciado. Depende de quem tiver maior Router Priority. 
Desempate com o maior endereço IP; 
 2 Roteadores com Router Priority 0 não são elegíveis;  
 1 Após escolha do BDR, processo de escolha do DR é iniciado; 
 2 Mesmos critérios de desempate do processo do BDR; 
 1 DR e BDR não mudam mesmo que outro roteador tenha prioridade maior; 
 2 Evita instabilidade na rede; 
 1 BDR só assume no momento em que o DR fica inativo; 
 1 Outros roteadores que entrarem na rede serão os DROthers. 
O fato de que, após escolhidos, o DR e o BDR não mudam, mesmo com a entrada de outros 
roteadores com prioridade mais alta, serve para garantir a estabilidade da rede, uma vez que a 
cada eleição todo o processo de adjacência tem de ocorrer novamente, gerando instabilidade 
no roteamento da rede. Observe na figura 1.10 o pacote Hello com o DR e o BDR definidos.
13
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
Open Shortest Path First
 OSPF Header
 OSPF Version: 2
 Message Type: Hello Packet (1)
 Packet Length: 48
 Source OSPF Router: 10.1.0.2 (10.1.0.2)
 Area ID: 0.0.0.0 (Backbone)
 Packet Checksum: 0xc490 [correct]
 Auth Type: Null
 Auth Data (none)
 OSPF He11o Packet
 Network Mask: 255.255.255.0
 Hello Interval: 10 seconds
 Options: 0x12 (L, E)
 Router Priority: 1
 Router Dead Interval: 40 seconds
 Designated Router: 10.1.0.2
 Backup Designated Router: 10.1.0.1
 Active Neighbor: 10.1.0.1
Como ambos os roteadores estão utilizando a mesma prioridade (1), o R2 foi eleito DR por ter 
o IP mais alto (10.1.0.2 > 10.1.0.1). É importante ressaltar que, caso o roteador seja configurado 
com Router Priority igual a zero, esse roteador não poderá ser candidato à DR ou BDR.
Após o estabelecimento das adjacências, os roteadores OSPF precisam trocar informações 
de estado de enlace para, assim, sincronizar seus bancos de dados topológicos e calcular a 
melhor rota para cada destino. Essa troca de informação de estado de enlace é feita pelos 
pacotes OSPF Database Description, Link State Request, Link State Update e Link State 
Acknowledgement, apresentados a seguir.
Database Description – DD
q 1 Após os roteadores OSPF tornarem-se adjacentes, os bancos de dados topológicos 
precisam ser sincronizados; 
 1 Pacotes Database Description são utilizados para esta atividade; 
 1 Pacotes DD são os pacotes OSPF do Tipo “2” 
 1 Database Exchange Process é iniciado: 
 2 Eleição Master/Slave; 
 2 Envio dos cabeçalhos LSA; 
 2 Verificação do aging para descobrir se o LSA é mais novo ou não; 
 2 Caso verifique que não está atualizado, uma lista de cabeçalhos LSA é criada para 
solicitar o LSA completo no próximo passo; 
 2 Utiliza endereçamento Unicast em redes Broadcast e NBMA e endereçamento 
Multicast em redes ponto a ponto. 
Figura 1.10 
R2 escolhido como 
DR, R1 como BDR.
14
 
O
SP
F 
Av
an
ça
do
Após os roteadores OSPF estabelecerem adjacências, estes precisam verificar se seus 
bancos de dados topológicos estão sincronizados.  Para essa tarefa, o pacote OSPF Database 
Description – DD – (pacote OSPF tipo “2”) é utilizado. Durante o período chamado “Database 
Exchange Process”, um processo de eleição de Master/Slave acontecerá e, após eleito, o 
Master começará a enviar os cabeçalhos dos LSAs existentes no seu banco de dados topo-
lógico. Como cada cabeçalho LSA contém um aging (tempo de existência), o roteador Slave 
conseguirá verificar se seu banco de dados está mais atualizado ou não. Caso perceba que 
não está, este registra essa informação para solicitar o LSA completo na próxima etapa. 
O mesmo acontece com o Master, que ao receber o pacote DD do Slave verifica se seu banco 
está atualizado a partir dos cabeçalhos LSAs recebidos e os respectivos tempos de aging.
Assim como o pacote Hello, o pacote DD também usa o cabeçalho OSPF apresentado ante-
riormente, adicionando apenas os campos listados a seguir. A troca dos pacotes de DD 
ocorre utilizando endereçamento Unicast (em redes Broadcast e NBMA) e Multicast 
(em redes ponto a ponto).
8 bits 8 bits 8 bits 8 bits
Tipo=2
Cabeçalho OSPF
32 bits
Opções MTU 00000 I M Ms
Número de Sequência
Cabeçalhos LSA
 1 MTU: tamanho do Maximum Transmission Unit da interface OSPF a ser utilizada para sin-
cronismo dos bancos de dados topológicos. Caso sejam diferentes entre os roteadores, o 
processo de sincronismo não vai ocorrer; 
 1 Options: mesmas opções definidas no pacote Hello; 
 1 Bit I (Initial): caso esteja marcado com “1”, indica que esse é o primeiro pacote DD da 
sequência de sincronismo; 
 1 Bit M (More): caso esteja marcado com “1”, indica que o pacote atual não é o último da 
sequência. “0” indica que é o último; 
 1 Bit MS (Master/Slave): se esse bit estiver marcado como “1”, significa que roteador origi-
nador é o Master na relação de sincronismo entre os dois roteadores. Se estiver marcado 
como “0”, esse roteador é o Slave do processo; 
 1 Número de Sequência: utilizado pelo Master para definir o sequenciamento dos pacotes DD; 
 1 Cabeçalhos LSA: lista dos cabeçalhos de parte ou todos os LSAs contidos no banco de dados 
do originador do pacote. A partir desse campo, o recebedor do pacote poderá confirmar se 
possui todos os LSAs e, caso não tenha, solicitará tais LSAs faltantes no próximo processo. 
Para ilustrar, vamos utilizar a topologia apresentada na figura 1.9. Como as adjacências já 
foram criadas, o passo seguinte é o Database Exchange Process. Observe a figura 1.12, a 
figura 1.13 e a figura 1.14. 
Figura 1.11 
Pacote Database 
Description. 
Também usa o 
cabeçalho OSPF.
15
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
OSPF Header
 OSPF version: 2
 Message Type: DB Description (2)
 Packet Length: 32
 Source OSPF Router: 10.1.0.1 (10.1.0.1)
 Area ID: 0.0.0.0 (Backbone)
 Packet checksum: 0x8386 [correct]
 Auth Type: Null
 Auth Data (none)
OSPF DB Description
 Interface MTU: 1500
 Options: 0x52 (O, L, E)
 DB Description: 0x07 (I, M, MS)
 .... 0... = R: OOBResync bit is NOT set
 .... .1.. = I: Init bit is SET
 .... ..1. = M: More bit is SET
 .... ...1 = MS: Master/Slave bit is SET
 DDSequence: 6258
OSPF Header
 OSPF version: 2
 Message Type: DB Description (2)
 Packet Length: 32
 Source OSPF Router: 10.1.0.2 (10.1.0.2)
 Area ID: 0.0.0.0 (backbone)
 Packet checksum: 0x7f27 [correct]
 Auth Type: Null
 Auth Data (none)
OSPF DB Description
 Interface MTU: 1500
 Options: 0x52 (O, L, E)
 DB Description: 0x07 (I, M, MS)
 .... 0... = R: OOBResync bit is NOT set
 .... .1.. = I: Init bit is SET
 .... ..1. = M: More bit is SET
 .... ...1 = MS: Master/Slave bit is SET
 DD Sequence: 7376
Na figura 1.12 é possível observar que ambos os roteadores R1 (10.1.0.1) e R2 (10.1.0.2) 
enviam o pacote DD informando serem Masters do processo. Cada um envia seu próprio 
número de sequência (R1 envia 6258 e R2 envia 7376).
Na figura 1.13., o roteador R1 envia o pacote com o bit M/S configurado para “0”, indicando 
ser o Slave da relação. No mesmo pacote R1 já envia o número de sequência recebido do R2 
(7376) e os cabeçalhos dos LSAs que estão no seu banco de dados (a explicação sobre LSA 
se dará mais à frente).
OSPF Header
 OSPF version: 2
 Message Type: DB Description (2)
 Packet Length: 52
 Source OSPF Router: 10.1.0.1 (10.1.0.1)
 Area ID: 0.0.0.0 (Backbone)
 Packet checksum: 0x7ffe [correct]
 Auth Type: Null
 Auth Data (none)
OSPF DB Description
 Interface MTU: 1500
 Options: 0x52 (O, L, E)
 DB Description: 0x02 (M)
 .... 0... = R: OOBResync bit is NOT set
 .... .0.. = I: Init bit is NOT SET
 .... ..1. = M: More bit is SET
 .... ...0 = MS: Master/Slave bit is NOT SET
 DD Sequence: 7376
LSA Header
OSPF Header
 OSPF version: 2
 Message Type: DB Description (2)
 Packet Length: 32
 Source OSPF Router: 10.1.0.2 (10.1.0.2)
 Area ID: 0.0.0.0 (backbone)
 Packet checksum: 0x7f27 [correct]
 Auth Type: Null
 Auth Data (none)
OSPF DB Description
 Interface MTU: 1500
 Options: 0x52 (O, L, E)
 DB Description: 0x07 (I, M, MS)
 .... 0... = R: OOBResync bit is NOT set
 .... .1.. = I: Init bit is SET
 .... ..1. = M: More bit is SET
 .... ...1 = MS: Master/Slave bit is SET
 DD Sequence: 7376
Figura 1.12 
Database Exchange 
Process: eleição 
do Master.
Figura 1.13 
Database Exchange 
Process: início 
da troca de 
pacotes DD.
16
 
O
SP
F 
Av
an
ça
do
Na figura 1.14, podemos observar que o R2 envia agora os cabeçalhos dos seus LSAs com 
um novo número de sequência (7377) e o R1 confirma recebimento enviando um pacote DD 
com o mesmo número de sequência.
OSPF Header
 OSPF: version: 2
 Message Type: DB Description (2)
 Packet Length: 32
 Source OSPF Router: 10.1.0.1 (10.1.0.1)
 Area ID: 0.0.0.0 (Backbone)
 Packet checksum: 0x7f2e [correct]
 Auth Type: Null
 Auth Data (none)
OSPF DB Description
 Interface MTU: 1500
 Options: 0x52 (O, L, E)
 DB Description: 0x00
 .... 0... = R: OOBResync bit is NOT set
 .... .0.. = I: Init bit is NOT set
 .... ..0. = More bit is NOT set
 .... ...0 = MS: Master/Slave bit is NOT set
 DD Sequence: 7377
OSPF Header
 OSPF: version: 2
 Message Type: DB Description (2)
 Packet Length: 52
 Source OSPF Router: 10.1.0.2 (10.1.0.2)
 Area ID: 0.0.0.0 (Backbone)
 Packet checksum: 0x8fe9 [correct]
 Auth Type: Null
 Auth Data (none)
OSPF DB Description
 Interface MTU: 1500
 Options: 0x52 (O, L, E)
 DB Description: 0x03 (M, MS)
 .... 0... = R: OOBResync bit is NOT set
 .... .0.. = I: Init bit is NOT set
 .... ..1. = M: More bit is SET
 .... ...1 = MS: Master/Slave bit is SET
 DD Sequence: 7377
LSA Header
Após isso, R2 envia mais um pacote DD com o bit M configurado como “0” e um novo 
número de sequência (7378), indicando o fim do processo, e R1 confirma com um pacote DD 
com o mesmo número. Agora, de posse dos cabeçalhos LSAs existentes no roteador remoto, 
ambos os roteadores enviarão pacotes OSPF chamados Link State Request, solicitando os 
LSAs completos para serem inseridos no banco de dados topológico. O processo de requi-
sição será apresentado a seguir. 
Link State Request ou LSR
q 1 Após o Database Exchange Process, os roteadores OSPF têm uma lista com LSAs que 
precisam ser solicitados. 
 1 A solicitação dos LSAs acontece via pacote OSPF Link State Request ou LSR. 
 1 Pacote OSPF do Tipo 3. 
 1 Também faz uso do cabeçalho OSPF, assim como o Hello e o DD. 
 1 Adiciona apenas três campos novos, que podem ocorrer diversas vezes. 
Concluído o Database Exchange Process, o próximo passo para o sincronismo dos bancos de 
dados é solicitar os LSAs completos que cada roteador recebeu do roteador remoto, seja por 
não possuir tal LSA, seja devido ao aging recebido ser mais novo que o existente no banco 
de dados atual.
Para fazer tal requisição ao roteador remoto, o pacote OSPF Link State Request (pacote 
OSPF tipo 3) é utilizado. Também fazendo uso do mesmo cabeçalho do Hello e do DD, 
esse pacote apenas adiciona três campos, conforme pode ser visto na figura 1.15. Esses 
campos podem se repetir.
Figura 1.14 
Database Exchange 
Process – R2 
enviando 
seus LSAs.
17
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
32 bits
8 bits 8 bits 8 bits 8 bits
Tipo=3
Cabeçalho OSPF
Tipo de Link-State 1
ID do Link-State 1
Advertising Router 1
...
Tipo de Link-State n
ID do Link-State n
Advertising Router n
 1 Tipo do LSA: identifica o tipo do LSA (os tipos estão listados na tabela 1.1); 
 1 ID do LSA: varia de acordo com o tipo do LSA; 
 1 Advertising Router: o Router-ID do roteador que originou o LSA. 
Esses campos podem se repetir diversas vezes, para solicitar múltiplos LSAs no mesmo 
pacote. Assim como a comunicação no Database Exchange Process, a comunicação entre 
os roteadores OSPF ocorre utilizando endereçamento Unicast (redes Broadcast e NBMA) e 
Multicast (redes Ponto-a-Ponto). Na figura 1.16 é possível ver um pacote LSR sendo enviado 
do R2 para R1:
 OSPF Version: 2
 Message Type: LS Request (3)
 Packet Length: 36
 Source OSPF Router: 10.1.0.2 (10.1.0.2)
 Area ID: 0.0.0.0 (Backbone)
 Packet Checksum: 0xdfd0 [correct]
 Auth Type: Null
 Auth Data (none)
Link State Request
 Link-State Advertisement Type: Router-LSA (1)
 Link State ID: 10.1.0.1
 Advertising Router: 10.1.0.1 (10.1.0.1)
Uma vez enviado o LSR solicitando os LSAs que precisam ser atualizados, o roteador remoto 
envia pacotes OSPF de Link State Update, que contém o LSA completo. A seguir será expli-
cado o formato desse pacote.
 
Figura 1.15 
Pacote Link 
State Request.
Figura 1.16 
Pacote LSR saindo 
de R2 para R1. 
Nesse caso, R2 está 
solicitando o LSA 
que tem os campos 
circulados na figura.
18
 
O
SP
F 
Av
an
ça
do
Link State Update ou LSU
q 1 Recebido o Link State Request, o roteador OSPF receptor verifica no seu banco de 
dados e responde com um pacote Link State Update. 
 1 O Link State Update é o pacote OSPF Tipo “4”. 
 1 O pacote pode ser enviado por Unicast ou Multicast. 
 1 Também faz uso do cabeçalho OSPF. 
Recebida a solicitação do LSA via pacote LSR, o roteador OSPF enviará um pacote OSPF Link 
State Update, cujo tipo é o 4. Esse pacote utiliza o mesmo cabeçalho OSPF, e a resposta é 
feita via uma das possibilidades a seguir:
 1 Um pacote LSU via Unicast para o solicitante; 
 1 Um pacote LSU via Multicast para o grupo AllSPFRouters. 
Apenas dois campos existem nesse pacote, conforme pode ser observado na figura 1.17.
32 bits
8 bits 8 bits 8 bits 8 bits
Tipo=4
Cabeçalho OSPF
Número de LSAs
LSAs
 1 Número de LSAs: informa a quantidadede LSAs que estão sendo enviados nesse pacote; 
 1 LSAs: nesse campo são enviados os LSAs requisitados pelo LSR. 
Na figura 1.18 é possível verificar um pacote LSU respondendo com um LSA completo. 
Porém, para garantir que o roteador remoto realmente recebeu o LSU, o roteador remoto 
precisa informar ao originador a confirmação de recebimento. Essa confirmação ocorre 
através do pacote OSPF Link State Acknowledgement ou LSAck.
Figura 1.17 
Pacote Link State 
Update. Apenas 
dois campos 
adicionados.
19
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
OSPF Header
 OSPF Version: 2 
 Message Type: LS Update (4)
 Packet Length: 64
 Source OSPF Router : 10.1. 0.1 (10.1. 0.1)
 Area ID: 0.0.0.0 (Backbone)
 Packet Checksum: 0xe898 [correct]
 Auth Type: Null
 Auth Data (none)
LS Update Packet
 Number of LSAs: 1
 LS Type: Router-LSA
Os tipos e o conteúdo dos LSAs serão apresentados no item "Link State Advertisement ou LSA".
Link State Acknowledgement ou LSAck
q 1 Depois de enviado o LSU, o roteador OSPF precisa da confirmação do roteador 
remoto que esse recebeu o pacote enviado. 
 1 A confirmação pode se dar de duas maneiras: 
 2 O receptor envia um pacote LSU com o mesmo conteúdo de volta para o originador. 
 2 O receptor gera um pacote Link State Acknowlegdement e envia para o originador. 
 1 Pacote Link State Acknowledgement ou LSAck possui o Tipo “5”. 
 1 Também utiliza o cabeçalho OSPF.
 Como o LSU também ocorre em modo flooding: enviando as informações para todos os 
roteadores OSPF do segmento de rede do qual faz parte: o LSAck é importante para garantir 
confiabilidade ao protocolo OSPF. Cada LSA recebido deve ser explicitamente confirmado 
pelo recebedor através do pacote LSAck. Essa confirmação ocorre quando o recebedor envia 
os cabeçalhos do LSA no pacote LSAck, podendo confirmar um ou diversos LSAs em uma 
única mensagem. O LSAck é o pacote de tipo número “5” do OSPF.
8 bits 8 bits 8 bits 8 bits
Tipo=5
Cabeçalho OSPF
32 bits
Cabeçalhos LSAs
Figura 1.18 
Resposta do R1 ao 
LSR de R2.
Figura 1.19 
Pacote Link State 
Acknowledgement.
20
 
O
SP
F 
Av
an
ça
do
É importante salientar que a especificação do OSPF também permite que a confirmação 
se dê através do próprio LSU, onde o recebedor enviaria um LSU de volta com os mesmos 
dados. Em redes Broadcast ou NBMA, a confirmação pode ocorrer também via Unicast 
(diretamente para o originador) ou via Multicast. Na figura 1.20, podemos observar a confir-
mação do roteador R2 ao LSU do R1 via pacote LSAck.
OSPF Header
 OSPF Version: 2
 Message Type: LS Acknowledge (5)
 Packet Length: 64
 Source OSPF Router: 10.1.0.2 (10.1.0.2)
 Area ID: 0.0.0.0 (Backbone)
 Packet Checksum: 0x6b41 [correct]
 Auth Type: Null
 Auth Data (none)
LSA Header
Após a confirmação de todos os LSAs recebidos por todos os roteadores OSPF, estes entram no 
estado chamado “FULL”, uma vez que seus bancos de dados estão sincronizados. A partir desse 
momento, apenas alterações de estado dos enlaces gerarão novas atualizações na rede.
q 1 Após todos os LSA serem trocados e confirmados, os roteadores entram no 
estado FULL; 
 1 Nesse estado, o algoritmo SFP faz o cálculo das rotas para serem inseridas no roteador; 
 1 Só haverá novos LSU/LSAck em caso de alterações no estado de algum enlace: 
 2 Enlace inativo, queda de circuito, queda de roteador etc.; 
 1 Caso o LSA não seja atualizado por 30 minutos, o roteador deve anunciá-lo nova-
mente para os roteadores da área: 
 2 Garantir que os bancos de dados estão sincronizados; 
 2 Esse tempo é chamado de LSRefreshTime e é fixo; 
 2 Nota: o anúncio é feito por LSA, e não de todo o banco de dados.  
Apesar do protocolo OSPF só enviar notificações de atualizações quando estas ocorrem (por 
exemplo, um enlace fica inativo), para garantir que todos os bancos de dados estão atualizados, 
toda vez que um LSA atingir o tempo aging de 30 minutos, uma atualização será enviada para 
o grupo Multicast AllSPFRouters, mesmo que no final o mesmo LSA permaneça no banco de 
dados OSPF. Esse tempo é fixo e chamado de LSRefreshTime na especificação do OSPF.
É importante salientar que o anúncio é feito por LSA, e não para todo o banco de dados. 
O OSPF não faz flooding da tabela de roteamento ou do banco de dados topológico.
Transição de Estados no Sincronismo do OSPF
Cada etapa do processo de sincronização do banco de dados topológico do OSPF tem um 
nome de estado associado. Esses nomes são importantes para entender o funcionamento 
do OSPF e para a resolução de problemas. A figura 1.21 ilustra essa transição de estados.
Figura 1.20 
LSAck do R2 
para R1.
21
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
R1 R2
HELLO (DR=0, Vizinhos=0)
HELLO (DR=R2, Vizinhos=R1) 
D-D (Seq =X, I, M, Master)
D-D (Seq =Y, l, M, Master) 
D-D (Seq =Y, M, Slave)
D-D (Seq =Y+1, l, M, Master) 
D-D (Seq =Y+1, M, Slave)
(...) 
D-D (Seq =Y+n, Master) 
D-D (Seq =Y+n, Slave)
LS Request
LS Update
LS Request
LS Update
DOWN DOWN
INIT
ExStart
ExStart
Exchange
Exchange
Full
Full
Loading
De maneira resumida, o processo de sincronização da figura 1.21 ocorre da seguinte maneira:
a. R1 inicializa seu processo OSPF no estado DOWN e envia um pacote Hello sem DR e sem 
indicação de vizinhos ativos; 
b. R2 recebe o pacote Hello, e sai do estado DOWN para o estado INIT. R2 então envia uma 
mensagem Hello informando ser o DR e, na lista de vizinhos ativos, adiciona o IP de R1; 
c. Ao receber o pacote Hello vindo de R2 com seu endereço IP no campo de vizinhos ativos, 
R1 sai do estado DOWN e passa para o estado ExStart. Nesse estado, R1 e R2 farão a 
verificação do banco de dados topológicos entre eles. Primeiramente, R1 envia um pacote 
DD informando ser o Master do processo; 
d. Ao receber o pacote DD, R2 entende que o R1 quer estabelecer a adjacência, e sai do 
estado INIT para o estado ExStart, e envia um pacote DD para R1 também informando ser 
o Master; 
e. Ao receber o pacote DD de R2, como este é o DR, R1 aceita ser o Slave do processo e 
passa do estado ExStart para o estado Exchange. Um pacote DD é enviado de volta com o 
número de sequência informado por R2; 
f. R2 recebe o pacote DD com seu número de sequência e passa para o estado Exchange. A 
partir desse momento, começa a troca de mensagens DD com os cabeçalhos dos LSAs de 
cada banco de dados; 
g. Após todos os cabeçalhos serem trocados, R1 entra no estado de Loading, pois agora vai 
solicitar os LSAs completos de R2. Mensagens de LSR são enviadas com os cabeçalhos 
dos LSA desejados; 
Figura 1.21 
Transição de 
estados OSPF.
22
 
O
SP
F 
Av
an
ça
do
h. Ao receber o LSR vindo de R1, se o R2 não precisar de nenhum LSA do R1, o este entra 
no estado FULL direto. Se R2 precisar, um pacote LSR será enviado para R1 e entrará no 
estado LOADING. No exemplo, como o R2 não precisará de informações do R1, R2 já foi 
para o estado FULL, e enviará os pacotes LSU com os LSAs requisitados; 
i. Quando o R1 receber todos os LSU requisitados, fará a confirmação de recebimento com os 
LSAck e entrará no estado FULL também. A partir desse momento, o banco de dados OSPF 
estará completo e as rotas serão calculadas e inseridas na tabela de rotas do roteador. 
Caso um novo roteador entre na rede OSPF, este fará o processo acima com o DR apenas. 
Com os outros DROthers da rede, as adjacências serão criadas, porém os roteadores 
DROthers ficarão parados no estado ExStart (ou 2-Way para algunsfabricantes) entre eles, 
pois não há necessidade do sincronismo. Em redes não Broadcast e NBMA, onde não há 
DR e BDR, ambos os roteadores devem chegar até o estado FULL.
q 1 Em redes Broadcast e NBMA, esse processo ocorre entre o roteador OSPF 
(DROther)e o DR; 
 2 Entre os DROthers, o maior estado é o ExStart; 
 1 Em redes Ponto-a-Ponto, ambos os roteadores têm de chegar ao estado FULL. 
Agora que o processo de sincronização do banco de dados topológico já está claro, será 
apresentada a estrutura de dados chamada Link State Advertisement, ou LSA, que são as 
estruturas que contêm as informações topológicas que populam o banco de dados do OSPF.
Link State Advertisement ou LSA
q 1 Link State Advertisement é a estrutura de dados responsável por armazenar as infor-
mações sobre os estados de enlaces; 
 2 Endereço IP, máscara de sub-rede, métrica etc.; 
 1 Pacotes OSPF DD e LSR usam apenas o cabeçalho; pacote LSU usa o LSA completo; 
 1 Através das informações no LSA é que o roteador faz os cálculos para definir as rotas; 
 1 Existem onze tipos, porém seis utilizados rotineiramente: router LSA, Network LSA, 
Network Summary LSA, ASBR Summary LSA, AS External LSA e NSSA External LSA. 
Link State Advertisement é a estrutura de dados responsável por armazenar as diversas 
informações usadas pelo processo OSPF sobre os estados de enlaces, como tipo de enlace, 
IP, máscara de subrede, métrica, origem etc. Foi apresentado anteriormente que, nos 
pacotes OSPF DD e LSR, apenas o cabeçalho do LSA é trocado, enquanto que no LSU o LSA 
completo é enviado.
Como os LSAs são os responsáveis por todas as informações e métricas da rede OSPF, 
diversos tipos foram criados, com propósitos específicos. Na tabela 1.1, os onze tipos exis-
tentes atualmente para IPv4 são apresentados. Porém, nas redes OSPF atuais, apenas seis 
tipos são realmente utilizados e serão detalhados nas sessões a seguir: router LSA, Network 
LSA, Network Summary LSA, ASBR Summary LSA, AS External LSA e NSSA External LSA.
23
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
Código Nome Quem faz uso? Descrição Definição
1 Router LSA Todos Descreve o ambiente 
do roteador, inter-
faces, métricas
RFC2328
2 Network LSA DR Informa todos os 
roteadores na rede 
Broadcast/NBMA
RFC2328
3 Network Summary 
LSA
ABRs Anuncia rotas de 
outra área do OSPF
RFC2328
4 ASBR Summary LSA ABRs Anuncia a rota para 
chegar no roteador 
ASBR
RFC2328
5 AS external LSA ASBRs Anuncia rota de fora 
do AS
RFC2328
6 Group Membership 
LSA
- Usado para Multicast 
OSPF
RFC1584
7 NSSA External LSA ASBRs em NSSA Anuncia rota de fora 
do AS
RFC3101
8 External Attributes 
LSA
- Possível substituto 
do iBGP
Pendente
9 Opaque LSA - Usado em MPLS RFC5250
10 Opaque LSA - Usado em MPLS RFC5250
11 Opaque LSA - Usado em MPLS RFC5250
Assim como os pacotes OSPF, o LSA também tem um cabeçalho que é compartilhado por 
todos os tipos de LSA. Esse cabeçalho possui 20 Bytes e está apresentado na figura 1.22, 
sendo detalhado a seguir.
Sequence Number
Age
32 bits
8 bits 8 bits 8 bits 8 bits
Opções Tipo
Advertising Router
Link-State ID
TamanhoChecksum
 1 Age (Tempo de vida): tempo em segundos desde que o LSA foi gerado; 
 1 Opções: mesmas definições do campo de Opções do protocolo Hello; 
 1 Tipo: identifica o Tipo do LSA;  
 1 Link-State ID: conteúdo dependente do Tipo do LSA. Será detalhado à frente; 
 1 Advertising Router: router-ID do roteador que originou o LSA; 
 1 Sequence Number: utilizado como controle de versão do LSA;  
Tabela 1.1 
Lista dos tipos 
 de LSA.
Figura 1.22 
Cabeçalho LSA 
utilizado por todos 
os tipos de LSA.
24
 
O
SP
F 
Av
an
ça
do
 1 Checksum: utilizado para garantir integridade. Não inclui o campo Age; 
 1 Tamanho: tamanho do LSA em Bytes, incluindo o cabeçalho. 
A seguir, os principais tipos de LSA serão apresentados, e seus cabeçalhos serão detalhados, 
bem como seu modo de uso.
Router LSA
q 1 Router LSA é utilizado para informar os roteadores adjacentes com informações 
como Router-ID, enlaces locais e métricas de saída. 
 1 Esse é o primeiro LSA enviado pelo roteador OSPF; 
 1 Contém todas as informações de todos os enlaces que o roteador possui; 
 1 Todas as informações de estado de enlace enviadas em apenas um LSA; 
 1 É o LSA Tipo “1”; 
 1 Todos os roteadores OSPF enviam LSAs do tipo Router LSA; 
 1 O Router LSA é mantido apenas dentro da área que faz parte. 
LSA tipo “1”, o Router LSA é utilizado para informar os roteadores adjacentes da área OSPF 
de informações como Router-ID, enlaces locais e métricas de saída. Esse é o primeiro LSA 
enviado pelo roteador e nele devem conter todas as informações de todos os enlaces que 
o roteador possui, em apenas uma mensagem. O formato do Router LSA é apresentado na 
figura 1.23. Os campos em azul pertencem ao cabeçalho LSA, detalhado na figura 1.22.
Sequence Number
Link ID
Link Data
00000 V E B 0x00 Número de Links
Age
32 bits
8 bits 8 bits 8 bits 8 bits
Opções Tipo = 1
Advertising Router
Link-State ID
TamanhoChecksum
 
 
Tipo de Link
TOS
Número TOS Métrica
0x00 Métrica TOS
A seguir, os campos do Router LSA são apresentados:
 1 Bit V (Virtual): informa se o roteador é a ponta de um Virtual Link; 
 1 Bit E (External): indica que o roteador originador é um ASBR; 
 1 Bit B (Border): indica que o roteador originador é um ABR; 
 1 Número de Links: número de enlaces incluídos no LSA. 
Figura 1.23 
Router LSA.
25
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
Os campos a seguir são utilizados para descrever cada enlace do roteador. Cada enlace 
possui um tipo.
 1 Link ID: identifica o objeto ao qual o enlace se conecta. Valor depende do campo Tipo de Link; 
 1 Link Data: conteúdo depende do Tipo de Link; 
 1 Tipo de Link: informa o tipo de enlace e define o conteúdo dos campos Link ID e Link 
Data. Os tipos estão informados na tabela 1.2; 
 1 Número TOS: não utilizado; 
 1 Métrica: custo do enlace; 
 1 TOS: não utilizado, mantido por compatibilidade com o OSPFv1; 
 1 Métrica TOS: não utilizado, mantido por compatibilidade com o OSPFv1. 
Tipo de 
Link
Tipo de Conexão Descrição Valor do Link 
ID
Valor do Link Data
1 Ponto a Ponto Uma conexão para outro roteador Router-ID do 
Vizinho
IP da interface do 
roteador originador
2 Rede de Trânsito Carrega tráfego de trânsito IP da interface 
do DR
IP da interface do 
roteador originador
3 Rede Stub Deve carregar pacotes tendo o 
Router-ID como origem ou destino
Prefixo da 
Rede IP
IP da Rede Stub ou 
Máscara de Rede
4 Virtual Link Usado por virtual links Router-ID do 
Vizinho
Valor of Ifindex do 
Virtual
q 1 A partir do Tipos de Link, o valor dos campos Link ID e Link Data podem mudar
A utilização dos campos da tabela 1.2 será apresentada na sessão de aprendizagem 2, 
“Áreas OSPF”, bem como exemplos.  
Tabela 1.2 
Router LSA: 
tipos de Link.
Network LSA
q 1 LSA tipo “2”; 
 1 Network LSA é utilizado pelo Designated Router para informar aos demais roteadores 
OSPF da área sobre os roteadores com os quais o DR possui adjacências; 
 1 Essa informação é utilizada para saber quais roteadores estão na mesma sub-rede e 
calcular as rotas entre eles; 
 1 Apenas o DR de cada segmento faz uso desse tipo de LSA. 
LSA tipo “2”, o Network LSA é utilizado pelo Designated Router para informar aos demais 
roteadores OSPF da área sobre os roteadores com os quais o DR possui adjacências. 
A estrutura da Network LSA está apresentada nafigura 1.24. É possível verificar que este é 
mais simples que o Router LSA. 
26
 
O
SP
F 
Av
an
ça
do
Age
32 bits
8 bits 8 bits 8 bits 8 bits
Opções Tipo = 2
Advertising Router
Sequence Number
Máscara de Sub-rede
Link-State ID
TamanhoChecksum
Roteador Ativo
Roteador Ativo
Os campos são preenchidos da seguinte maneira:
 1 Link-State ID: endereço IP da interface do DR na área; 
 1 Máscara de Sub-rede: máscara de sub-rede da interface do DR conectada à área; 
 1 Roteador Ativo: router-ID dos roteadores com os quais o DR possui adjacência.  
Network Summary LSA e ASBR Summary LSA
q 1 Network Summary LSA é o Tipo “3”. 
 1 ASBR Summary LSA é o Tipo “4”. 
 1 Ambos são utilizados apenas pelos ABR: Area Border Router: 
 2 Network Summary LSA é utilizado para enviar as rotas entre áreas. 
 2 ASBR Summary LSA é utilizado para informar o endereço IP dos roteadores ASBR: 
Autonomous System Boundary Routers.  
 1 O formato dos campos é o mesmo, porém o preenchimento varia nos seguintes campos: 
 2 Tipo. 
 2 Link-State ID. 
 2 Máscara de Sub-rede. 
 1 Também é utilizado para gerar a rota default dentro de uma área Stub. 
O formato do Network Summary LSA (ou Summary LSA) e do ASBR Summary LSA são 
idênticos. As únicas diferenças então no preenchimento dos campos Tipo, Link-State ID e 
Máscara de Sub-rede.
O Network Summary LSA é utilizado para informar os roteadores de uma das áreas do ABR 
sobre as rotas das outras áreas do ABR. Por isso, quanto o roteador ABR quer enviar um 
Network Summary LSA, o campo Tipo é preenchido com valor “3”. O campo Link-State ID é 
preenchido com o prefixo IP da rede a ser anunciada, e o campo Máscara de sub-rede é preen-
chido com a máscara do prefixo informado. Caso o ABR queira, é possível fazer agregação dos 
prefixos, além de ser possível o envio da rota padrão (ou rota default). No caso da rota padrão, 
ambos os campos Link-State ID e Máscara de Sub-rede são preenchidos com o valor 0.0.0.0.
Figura 1.24 
Network LSA.
27
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
O ASBR Summary LSA é utilizado pelo ABR para informar sobre os roteadores ASBR exis-
tentes em outra área da qual o ABR faz parte. Quanto for enviar um ASBR Summary LSA, 
o ABR precisa preencher o campo Tipo com valor “4”, e, no campo Link-State ID, é preciso 
informar o Router-ID do ASBR (geralmente o endereço de loopback). Nesse caso, o campo 
Máscara de Sub-rede não tem serventia e é preenchido com o valor 0.0.0.0.
Métrica0x00
Métrica TOSTOS
Age
32 bits
8 bits 8 bits 8 bits 8 bits
Opções Tipo = 3 ou 4
Advertising Router
Sequence Number
Máscara de Sub-rede
Link-State ID
TamanhoChecksum
O campo Métrica é preenchido com o custo associado para se chegar ao endereço IP infor-
mado no campo Link-State ID. Os campos TOS e Métrica TOS não são utilizados.
AS External LSA
q 1 LSA Tipo “5”. 
 1 Utilizado para enviar rotas externas ao AS ou externas ao processo OSPF. 
 1 É enviado para todas as áreas, menos para as áreas Stub e NSSA. 
 1 AS External LSA não possuem relação com nenhuma área e por isso são transpor-
tados intactos entre áreas. 
 2 Daí a necessidade do ASBR Summary LSA (Tipo “4”) para ajudar os roteadores a 
localizarem o ASBR. 
 1 Possui dois tipos de rotas externas: 
 2 Tipo “1”: além do custo externo, adiciona o custo interno da rede para alcançar o 
ASBR. 
 2 Tipo “2”: somente tem o custo externo. 
Quando um ASBR precisa enviar rotas que são externas ao AS ou externas ao processo OSPF 
(redistribuição, por exemplo), o ASBR o faz enviando LSAs do tipo “5”, ou AS External LSA. 
Esse LSA é enviado para todas as áreas OSPF, com exceção das áreas Stub e NSSA. 
O formato do AS External LSA está apresentado na figura 1.26.
O preenchimento dos campos é feito da seguinte maneira:
 1 Link-State ID: prefixo IP da rota a ser anunciada; 
 1 Máscara de Sub-rede: máscara de sub-rede do prefixo IP a ser anunciado; 
Figura 1.25 
Network ou ASBR 
Summary LSA.
28
 
O
SP
F 
Av
an
ça
do
 1 Bit E (External): é utilizado para marcar a rota com duas opções: e1 ou E2. Quando o bit 
E está configurado com “0”, a rota é dita E1 e possui como métrica o custo da rota externa 
recebida pelo ASBR, mais o custo interno para se chegar até o ASBR. Quando o bit E está 
configurado com “1”, a rota é dita E2 e possui como métrica apenas o custo externo. 
No caso da rota E2, o custo é maior que qualquer outro enlace interno. A configuração 
padrão é configurar a rota como E2. 
 1 Métrica: custo da rota; 
 1 Endereço de Encaminhamento: endereço IP do roteador responsável pelo prefixo. Se 
estiver configurado como “0.0.0.0”, significa que é para enviar para o próprio ASBR; 
 1 Tag da Rota Externa: campo extra, que pode ser utilizado pelas políticas de roteamento 
do AS. Não é utilizado pelo OSPF em si. 
Os campos TOS, Métrica TOS, Endereço de Encaminhamento TOS e Tag da Rota Externa TOS são 
campos de compatibilidade, e não são utilizados. 
 
 
Endereço de EncaminhamentoEndereço de Encaminhamento
Endereço de Encaminhamento TOS
MétricaE 0000000
Age
32 bits
8 bits 8 bits 8 bits 8 bits
Opções Tipo = 5
Advertising Router
Sequence Number
Máscara de Sub-rede
Link-State ID
TamanhoChecksum
 
 
 
 
Tag da Rota Externa
E TOS Métrica TOS
Tag da Rota Externa TOS
NSSA External LSA
q 1 LSA Tipo “7”. 
 1 Também é criado pelo ASBR, quando este está em uma área Not-so-Stub-Area. 
 1 Mesmo cabeçalho do AS External LSA, porém preenchimento diferente no campo 
Endereço de Encaminhamento. 
 1 Por padrão, o NSSA External LSA é traduzido para AS External LSA nos ABRs. 
Figura 1.26 
AS External LSA.
29
 
C
ap
ítu
lo
 1
 - 
Fu
nc
io
na
m
en
to
 d
o 
ba
nc
o 
de
 d
ad
os
 d
o 
O
SP
F
O LSA tipo “7” é o NSSA External LSA. Esse LSA também é criado pelo ASBR, porém, apenas 
quando o ASBR está dentro de uma Área NSSA (Not-so-Stub-Area). Todos os campos são 
utilizados da mesma maneira que no AS External LSA, com exceção do campo Endereço de 
Encaminhamento. O NSSA External LSA está detalhado na figura 1.27.
Endereço de EncaminhamentoEndereço de Encaminhamento
Endereço de Encaminhamento TOS
MétricaE 0000000
Age
32 bits
8 bits 8 bits 8 bits 8 bits
Opções Tipo = 7
Advertising Router
Sequence Number
Máscara de Sub-rede
Link-State ID
TamanhoChecksum
 
 
 
 
Tag da Rota Externa
E TOS Métrica TOS
Tag da Rota Externa TOS
O campo Endereço de Encaminhamento pode assumir um dos seguintes valores:
 1 Endereço IP do roteador na rede responsável pelo prefixo se a rede já for redistribuída 
como interna; por exemplo, redistribuição do protocolo RIP; 
 1 Router-ID do roteador ASBR caso seja uma rota externa ao AS. 
A utilização dos seis LSAs apresentados até aqui será demonstrada na sessão 2.
Remoção de LSAs
q 1 A remoção de um LSA do LSDB pode ocorrer devido a dois fatores: 
 2 LSA aging atinge o MaxAge. 
 2 Acontece alguma alteração topológica na rede. 
 1 Alterações topológicas na rede incluem: 
 2 Enlace que muda de estado (de UP para DOWN ou DOWN para UP). 
 2 Roteador adicionado ou removido da rede.  
 1 Em caso de mudança de estado, duas ações podem fazer a remoção de um LSA do LSDB. 
 2 Expiração da adjacência detectada pelo protocolo Hello. 
 2 Envio de LSU com o LSA atualizado. 
 1 A Figura 1.28 mostra uma topologia onde a expiração via protocolo Hello aconteceria. 
 1 A figura 1.29 mostra uma topologia onde o envio de um LSU acontece.  
Figura 1.27 
NSSA External LSA.
30
 
O
SP
F 
Av
an
ça
do
Conforme