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
Conformemencionado anteriormente, uma vez no estado FULL, os roteadores OSPF não 
enviam novas atualizações de estado de enlace a menos que:
 1 O aging do LSA atinje o LSRefreshTime (30 minutos); 
 1 Haja alguma alteração topológica na rede. 
Alterações topológicas na rede incluem: 
 1 Enlace que muda de estado (de UP para DOWN ou DOWN para UP); 
 1 Roteador adicionado ou removido da rede (seja por problemas no roteador ou intencional). 
Os casos que refletem adição de enlace ou roteador foram explicados anteriormente, 
porém, é importante detalhar como os prefixos são removidos do LSDB. A remoção de um 
LSA do LSDB acontece, na maioria dos casos, diante de dois cenários: 
 1 Expiração da adjacência detectada via protocolo Hello; 
 1 Envio de LSU com LSA atualizado informando a alteração. 
Vamos utilizar como exemplo a topologia da figura 1.28. Nessa rede Broadcast, todos os 
roteadores estão conectados a um switch Ethernet. Todos os três roteadores enviam, a cada 
intervalo definido no protocolo Hello (Interval), um pacote Hello para garantir que a adjacência 
está formada. Suponha agora que todas as adjacências estão formadas, porém, em algum 
momento futuro, o roteador R1 muda de estado para DOWN (por falta de energia, intervenção 
do administrador, problemas no equipamento etc.). Como eles estão interconectados via um 
switch Ethernet, as  interfaces f0/0 dos roteadores R2 e R3 vão continuar UP, e após o Dead 
Interval do protocolo Hello, R2 e R3 vão ter as entradas LSA referentes ao roteador R1 remo-
vidas do LSDB. Essa remoção acontecerá devido à expiração da adjacência OSPF.
R1
f0/0
f0/0
f0/0
10.1.0.0/24
SW1
1 2
3
R2
R3
Observe agora topologia da figura 1.29. Nessa figura, temos dois momentos: momento 
A, onde a rede está funcional entre os roteadores R1, R2 e R3, com todos os roteadores 
no estado FULL. Nesse estado, o roteamento acontece normalmente e os três roteadores 
possuem o mesmo LSDB.
Assuma agora que algum tempo depois o enlace entre R1 e R2 mudou de estado, de UP para 
DOWN. Esse novo estado está representado pelo Momento B da figura 1.29.
Figura 1.28 
Rede Broadcast.
31
 
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
F0/0 F0/010.1.2.0/24
.1 .2 .1 .2
F0/1 F0/010.2.3.0/24
R1 R2 R3
a.
F0/0 F0/010.1.2.0/24
.1 .2 .1 .2
F0/1 F0/010.2.3.0/24
R1 R2
LSU + LSA
R3
b.
Após a queda do enlace entre R1 e R2, houve uma mudança no estado do enlace da 
interface f0/0 do roteador R2, e essa mudança precisa ser informada ao roteador R3. 
Essa mudança será informada através do pacote OSPF LSU (Link State Update), e um dos 
seguintes campos do LSA pode ser utilizado:
 1 Age (ou Tempo de Vida): uma das constantes do OSPF é o MaxAge, que representa o 
valor de 1 hora (3.600 segundos). Qualquer LSA que atinja esse período no LSDB deve ser 
removido, pois subentende-se que não foi atualizado no tempo LSRefreshTime. Então, 
é possível um roteador OSPF informar outro roteador da remoção de um LSA simples-
mente preenchendo o campo Age do cabeçalho do LSA com o valor MaxAge. Essa abor-
dagem é utilizada principalmente pelo Network-LSA; 
 1 Métrica: uma outra constante que pode ser utilizada para informar que o LSA deve ser 
removido é a LSInfinity. Essa constante, utilizada como métrica máxima (infinita) do 
OSPF, é definida com os 24 bits todos configurados como 1 (0xffffff). Ou seja, caso o LSA 
tenha seu campo Métrica preenchido com o valor LSInfinity, o roteador OSPF recebedor 
de tal LSA deve removê-lo do LSDB. Essa abordagem é utilizada principalmente pelo 
Summary-LSA e pelo AS-External LSA. 
Conclusão
Nesta sessão, foram apresentados os cinco diferentes tipos de pacotes OSPF: Hello, 
Database Description, Link State Request, Link State Update e Link State Acknowledgement, 
e como eles são utilizados pelos roteadores OSPF para sincronizar os bancos de dados. 
Além disso, o LSA, seus seis principais tipos e seus papéis também foram apresentados. 
De posse dessas informações, será possível entender como o OSPF cria o conceito de hie-
rarquia em áreas, e como e quais LSAs são filtrados e/ou encaminhados pelos ABRs para 
que a hierarquia e a escalabilidade da rede OSPF possa ser alcançada. Na próxima sessão, 
essa interação entre LSA, pacotes OSPF e as áreas será apresentada, permitindo ao aluno 
planejar, projetar e operar as mais diversas configurações de redes OSPF existentes.
Figura 1.29 
Rede Broadcast 
com momentos 
A e B.
32
 
O
SP
F 
Av
an
ça
do
Comandos OSPF
A seguir, uma lista de comandos de configuração que têm relação com os temas abordados 
na sessão de aprendizagem 1, para serem utilizados no Quagga. Os comandos a seguir são 
aplicados por interface.
 1 Altera o tempo em segundos entre pacotes Hello (padrão de 10 segundos):
ip ospf hello-interval <1-65535>
 1  Altera o tempo em segundos para considerar um vizinho como inativo (padrão de 
40 segundos):
ip ospf dead-interval <1-65535>: tempo para considerar o vizinho como inativo
 1 Fast Hello: número de Hellos para enviar em um intervalo dead-interval de 1 segundo:
ip ospf dead-interval minimal hello-multiplier <1-10>
 
 1 Configura o tipo de rede OSPF:
ip ospf network <broadcast|non-broadcast|point-to-multipoint|point-to-point>
 
 1 Define a prioridade no processo de escolha do DR/BDR. 0 significa não elegível:
ip ospf priority <0-255>
 
 1 Configura autenticação simples:
ip ospf authentication-key SENHA
 
 1 Configura autenticação MD5:
ip ospf authentication message-digest
ip ospf message-digest-key <1-255> md5 SENHA
A seguir, uma lista dos comandos de observação que têm relação com os assuntos abor-
dados na sessão de aprendizagem 1:
 1 Exibe informações sobre o processo OSPF:
show ip ospf
 
 1 Exibe informações resumidas sobre o banco de dados OSPF:
show ip ospf database
 
 1 Exibe informações resumidas sobre o banco de dados OSPF por tipo de LSA:
show ip ospf database <router|network|summary|asbr-summary|external|nssa-
external>
 
 1 Exibe informações sobre o processo OSPF em uma determinada interface: 
show ip ospf interfaces
 
 1 Exibe as adjacências OSPF estabelecidas:
show ip ospf neighbor
33
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
 
 
ob
je
tiv
os
conceitos
2
Entendendo as áreas do OSPF
Distinguir os tipos de áreas utilizadas pelo OSPF; Projetar e justificar quais tipos de área 
deseja utilizar; Entender o porquê de cada estado de cada banco de dados por área.
Por que o OSPF faz uso do conceito de áreas?; Quais são os tipos de áreas e como 
elas se comportam em um ambiente OSPF; Área Backbone; Área Normal; Área Stub; 
Área Not-So-Stubby ou NSSA; Interconectando áreas com Virtual Links; Entendendo 
o LSDB; Observando o funcionamento do LSDB na Área Backbone.
 
Por que o OSPF faz uso do conceito de áreas?
q 1 LSDB precisa ser idêntico em todos os roteadores da rede. 
 1 Redes muito grandes possuem LSDB muito grandes. 
 2 Aumenta o consumo de memória e CPU. 
 2 Diminui o tempo de convergência da rede. 
 1 Redes com muitos enlaces que oscilam tendem a sofrer mais com LSDB muito grandes. 
O protocolo OSPF, por ser um protocolo de estado de enlace, requer a criação e manutenção 
de um banco de dados com a topologia completa da rede. Esse banco de dados, chamado 
de Link-State Data Base (LSDB) deve conter todos os enlaces de uma determinada rede, seus 
estados e suas métricas. A partir desse banco de dados, as rotas para todos os destinos são 
calculadas, otimizadas para usar o melhor caminho possível e garantir que não haverá loops 
de roteamento.
Paraque isso aconteça, é imprescindível que todos os roteadores da rede tenham exatamente 
o mesmo LSDB. Em redes pequenas e médias, com poucos roteadores, a complexidade para 
manter esse LSDB sincronizado e a rede estável é bem pequena. Porém, em redes grandes, 
com mais de vinte roteadores, maior é a quantidade de enlaces e maior a quantidade de 
possíveis caminhos para chegar até um determinado endereço IP.
Esses enlaces podem fazer uso de diversas tecnologias, como circuitos seriais, Frame-Relay 
e mesmo circuitos ópticos, cada um sujeito a diversos tipos de situações adversas que fazem 
com que oscilem. Com essas oscilações, toda vez que um enlace enfrenta uma indisponibi-
lidade, ou seja, ocorre uma mudança do estado do enlace, o roteador responsável por tal 
34
 
O
SP
F 
Av
an
ça
do
enlace deve informar todos os outros roteadores que compartilham do mesmo LSDB. Cada 
roteador deverá fazer a confirmação (LSAck), executar o algoritmo SPF e calcular e instalar 
novas rotas. Ou seja, quanto maior a quantidade de roteadores e enlaces, maior o custo 
computacional para manter a rede operando adequadamente.
q 1 Especificação do OSPF permite o particionamento da rede: Áreas; 
 1 Áreas são utilizadas para criar redes OSPF menores; 
 1 Topologia da área é transparente para as demais áreas; 
 1 Com LSDB menor, menos recursos computacionais são necessários; 
 1 Cada área no ABR possui um LSDB separado; 
 1 Roteamento Intra-Area não necessita de informações externas. 
Diante dessa situação, a especificação do OSPF foi criada para permitir o particionamento 
da rede, criando zonas de roteamento menores. Essas zonas de roteamento – chamadas 
de áreas – permitem com que pedaços da rede sejam criados, gerando LSDBs menores que 
podem ser processados de maneira mais rápida, economizando recursos computacionais dos 
roteadores e diminuindo o tempo de convergência da rede. Essas áreas podem ser criadas 
para agrupar roteadores com papéis similares, por exemplo, roteadores de datacenter; 
roteadores conectados a serviços menos confiáveis, como enlaces seriais; ou mesmo para 
permitir que roteadores com menos recursos de CPU e memória possam fazer parte do 
roteamento dinâmico da rede.
Para permitir que as áreas sejam alcançáveis dentro da rede, roteadores chamados de Area 
Border Routers (ABR) são conectados a duas ou mais áreas ao mesmo tempo, efetuando o 
roteamento entre estas. No roteador ABR, a quantidade de LSDBs vai depender da quanti-
dade de áreas às quais o ABR se conecta: se estiver conectado a duas áreas OSPF, o ABR terá 
dois LSDB separados. Se estiver conectado a três áreas OSPF, o ABR terá três LSDB sepa-
rados, e assim sucessivamente.
Por causa disso, os roteadores ABR são escolhidos por terem melhores recursos 
computacionais do que aqueles que tipicamente ficam em redes Stub.  
Como cada roteador de uma área possui no seu LSDB apenas informações da sua área, a topo-
logia externa é completamente transparente. O tráfego que é roteado dentro de uma área 
(intra-area) – endereço de origem e de destino estão inclusos no mesmo LSDB: não necessita 
de informação alguma externa àquela área. No tráfego em que o endereço de destino ou o de 
origem são de áreas diferentes, informações de roteamento vindas do ABR são necessárias.
q 1 Para fazer a interconexão entre áreas, o roteador ABR é utilizado: 
 2 LSAs Router e Network ficam confinados por área; 
 2 LSA Summary é gerado para permitir a alcançabilidade da rede. 
 1 LSA Externos continuam sendo encaminhados entre áreas (menos áreas Stub e NSSA). 
A transparência criada pelo ABR é feita através da filtragem dos Link State Advertisements: 
em vez de encaminhar os LSAs Router e Network entre áreas, o ABR gera um sumário e 
envia um LSA Summary para a área remota, que assim passa a saber quais prefixos são 
alcançáveis dentro de cada área.  Como no LSA Summary não há indicações de como os 
enlaces estão conectados, os roteadores externos não precisam gerar toda a árvore SFP por 
enlace. Logo, o processo SFP é simplificado.
35
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
Para fazer o particionamento de uma rede OSPF em áreas, é importante conhecer quais são 
as áreas suportadas, como elas funcionam e como se relacionam. Além disso, é fundamental 
saber quais são os LSAs utilizados por cada roteador de cada área e como eles são filtrados 
ou gerados nos ABRs.
Quais são os tipos de áreas e como elas se comportam em 
um ambiente OSPF
q 1 As RFCs 2328 e 3101 definem a criação das seguintes áreas OSPF:
 2 Área Backbone. 
 2 Área Não Backbone. 
 3 Área "Normal". 
 3 Área Stub. 
 3 Área Not-So-Stubby. 
 2 Virtual-Links. 
A RFC 2328 possui as definições das principais áreas atualmente suportadas pelo OSPF. 
São elas:
 1 Área 0 ou Backbone: área principal do OSPF, conecta todos os ABRs; 
 1 Área Não Backbone: área OSPF, que está conectada à Área Backbone. 
Para aumentar o controle, a flexibilidade e a escalabilidade do LSDB, as áreas não backbone 
podem ser divididas em:
 1 Área Normal: área OSPF que se conecta à Área Backbone e suporta todos os tipos de LSAs; 
 1 Área Stub: área OSPF que se conecta à Área Backbone, porém não suporta LSAs Tipo 5 
e Tipo 7. 
Além destas, a RFC 3101 adicionou uma nova Área Não Backbone às redes OSPF: a 
Not-So-Stubby-Area – ou NSSA. A NSSA funciona basicamente como uma área Stub que 
permite ASBR dentro da área.
A Área Backbone não pode ser particionada, ou seja, deve ser contígua ao longo de toda a 
rede do Sistema Autônomo. Em casos onde ocorre esse particionamento, seja por rote-
ador ou enlace indisponível, é necessário que essas duas partes da Área Backbone sejam 
reconectadas através de Virtual Links, que é um recurso criado justamente para reconectar 
áreas, sejam partições da mesma Área Backbone ou Áreas Não Backbone à Área Backbone.
A seguir cada área OSPF será detalhada. A figura 2.1, a seguir, será utilizada como caso de 
uso das áreas OSPF.
36
 
O
SP
F 
Av
an
ça
do
Rede 4
Rede 3
Rede 6Rede 5
R5
R6
R7
R9 R10
Rede 2
R2
R3
R11
R4
Rede 1
R1
Internet 
BGP
R8 Área 3 Área 4
Área Backbone
Área 2
Área Backbone
q 1 Conhecida como Área 0 ou Área 0.0.0.0. É o núcleo da rede. 
 1 Responsável por interconectar todas as demais áreas.  
 1 Não pode ser particionada. 
 1 Deve possuir roteadores com memória e CPU suficientes para manipular vários LSDBs. 
A Área Backbone, também conhecida como Área 0 ou Área 0.0.0.0, é considerada a principal 
área OSPF, pois é a responsável por interconectar todas as demais áreas OSPF. Nessa área 
estão todos os roteadores ABR, ou seja, todas as áreas devem estar diretamente conectadas 
à Área Backbone. Por ser a área principal, essa área não pode ser particionada. Por isso, 
o engenheiro de redes responsável pela configuração da rede OSPF deve ter cuidado na 
definição da rede.
Além disso, devido ao fato de ter todos os ABRs e todos os tipos de LSA, incluindo Summary 
e AS-Externo, a Área Backbone também deve possuir roteadores com memória e proces-
samento suficiente para manipular o LSDB. Na figura 2.1, os roteadores R3, R4, R5, R6 e 
R7 fazem parte da Área Backbone. Desses, R3, R4 e R7 são roteadores ABR e R5 e R6 são 
Roteadores Internos (Internal Routers). Observe na figura que no OSPF o roteador pode ter 
interfaces em diversas áreas.
Figura 2.1 
Rede OSPF com 
Diversas Áreas.
37
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
Área Normal
q 1 Aceita LSAs Externos. 
 1 Não faz trânsito. 
 1 Roteadores com perfis similares. 
 1 Geralmente possui múltiplos roteadores ABRs.Apesar de suportar os principais LSAs (Router, Network, Summary, ASBR-Summary e 
AS-External), as Áreas Normais são diferentes da Área Backbone, pois não fazem trânsito 
ao longo da sua extensão (a menos que Virtual Links sejam utilizados). Normalmente, essas 
áreas possuem um conjunto de roteadores com perfis similares (por exemplo, roteadores de 
data center ou roteadores em uma mesma localidade) e podem possuir múltiplos roteadores 
ABR conectados à Área Backbone. Na figura 2.1, a Área 2 pode ser caracterizada como uma 
Área Normal, pois não provê trânsito para outras áreas OSPF, além de possuir dois ABRs.
 
As Áreas 3 e 4 podem ser consideradas Áreas Normais mesmo tendo apenas um 
ABR. A especificação do OSPF apenas sugere mais de um ABR. Em casos com apenas 
um ABR, a sugestão é configurar Área Stub.
Área Stub
q 1 Área Stub 
 1 Usada quando 
 2 Roteadores com recursos computacionais limitados 
 2 Apenas um ABR por área 
 1 Opção de LSA-Summary gerado pelo ABR com a rota padrão 
 1 LSA Externos são descartados (AS External LSA e NSSA-LSA) 
As Áreas Stubs são muito utilizadas em cenários onde os roteadores que fazem parte da 
área não possuem recursos computacionais suficientes para manter toda a topologia, ou 
em casos onde existe um único ABR conectando a Área Backbone. Por exemplo, observe a 
figura 2.1. É possível observar que a Área 3 e a Área 4 possuem mais de um roteador OSPF 
por área, porém apenas um roteador ABR. 
Nesse caso, não faria sentido que os roteadores R8, R9, R10 e R11 tivessem informações 
sobre a topologia da Área 2 ou da Área Backbone, por exemplo, pois todo acesso às outras 
redes se dá via o único ABR da área. Neste caso, o procedimento recomendado seria confi-
gurar os roteadores como fazendo parte de uma área Stub, e o ABR de cada área gerar uma 
rota padrão (default route) que seria enviada para os demais roteadores da área. Nesse caso, 
R8 e R9 receberiam uma rota padrão vinda do roteador R4 e os roteadores R10 e R11 recebe-
riam uma rota padrão vinda do roteador R7. Nos LSDB de R8, R9, R10 e R11 constaria apenas 
as rotas da própria área (Router-LSA e Network-LSA) mais a rota padrão gerada (Summary-LSA). 
Uma vez configurado o processo OSPF como parte de uma Área Stub, os LSAs Tipo 5 
(AS External LSA) passam a ser descartados pelos roteadores ABR.
38
 
O
SP
F 
Av
an
ça
do
Área Not-So-Stubby ou NSSA
Nas redes OSPF em geral, o LSDB possui mais LSAs do Tipo 5 (AS External LSA) do que os 
demais tipos. Isso se deve, principalmente, ao uso de redistribuição nos roteadores, seja 
redistribuição das rotas estáticas, das rotas de outro IGP (RIP, IS-IS, etc.) ou mesmo de inter-
faces diretamente conectadas no processo OSPF. Então, pode acontecer de um roteador que 
está em uma área Stub precisar redistribuir informações de estado de enlace que devem ser 
propagadas para todos os roteadores da rede. Conforme explicado anteriormente, os rote-
adores configurados em uma área Stub descartam os LSAs AS-External-LSA. Logo, utilizando 
como exemplo a rede da figura 2.1 e assumindo-se que a Área 3 está configurada como um 
Área Stub, se o roteador R8 necessitar redistribuir algum prefixo recebido do processo BGP, 
esse prefixo seria filtrado no roteador R4 por ser um prefixo externo ao processo OSPF.
No âmbito do OSPF, a palavra redistribuição refere-se à inserção de estado de 
enlaces que estão fora do processo OSPF no processo OSPF. Por exemplo: redistri-
buir um prefixo IP do processo de roteamento do RIP no processo de roteamento do 
OSPF. Ou, redistribuir uma rota estática no processo OSPF. Sempre que há redistri-
buição é utilizado o LSA AS-External-LSA, que é filtrado nas áreas Stub.
Para evitar ter que migrar a Área 3 de Stub para Normal apenas porque um roteador precisa 
fazer redistribuição, a RFC 3101 criou um novo tipo de área, chamada Not-So-Stubby-Area 
ou NSSA. Basicamente, a NSSA é uma área Stub que permite que prefixos externos sejam 
inseridos na área e encaminhados pelo ABR para a Área Backbone. Dentro da Área NSSA, o 
prefixo é divulgado para os outros roteadores utilizando o LSA External-NSSA. Ao chegar no 
ABR, este converte de External-NSSA (Tipo 7) para um AS-External LSA (Tipo 5) e encaminha 
para os demais roteadores da Área Backbone.
q 1 Área Not-So-Stubby
 2 Criada na RFC 3101
 2 Comportamente similar a Área Stub porém permite redistribuição
 2 Prefixos externos são redistribuídos com LSA External-NSSA
 2 ABR converte de External-NSSA para AS External LSA
Interconectando áreas com Virtual Links
q 1 Evitar o particionamento da Área Backbone. 
 1 Utilizado para reconectar área que desconectou da Área Backbone via outra Área. 
 1 OSPF trata o Virtual Link como uma rede ponto-a-ponto unnumbered.  
 1 Funcionalidade de uso temporário. 
 1 Não suportado via Áreas Stub. 
Virtual Link é um recurso criado na RFC 2328 para garantir que a mudança de estado de 
enlaces não segregue alguma área, principalmente a Área Backbone, e gere problemas de 
roteamento, ou seja, o objetivo do Virtual Link é conectar dois ABRs via uma área que não 
seja a Área Backbone. Com o Virtual Link, o OSPF trata os dois roteadores como se esti-
vessem conectados a uma rede ponto-a-ponto unnumbered (ou seja, sem endereçamento 
IP nas pontas).
39
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
Como exemplo, observe novamente a figura 2.1. Nela, o roteador R4 faz parte da Área Back-
bone através do enlace entre R4 e R5. Caso esse enlace mude de estado (de UP para DOWN), 
R4 ficaria desconectado e a Área Backbone seria particionada, o que não pode acontecer. 
Mesmo R4 tendo conexão via Rede 3 com R3, os LSAs com os prefixos da Área 3 não seriam 
encaminhados para a Área Backbone ou para a Área 2 por R3, pois não foram recebidos pela 
interface que faz parte da Área Backbone.
Ou seja, a Área 3 ficaria desconectada da rede mesmo que R4 tivesse um enlace de backup via 
Rede 3. Nesse caso, a solução é criar um Virtual Link entre R3 e R4 via Área 2. Esse Virtual Link 
seria tratado como uma extensão da Área Backbone, desfazendo o particionamento criado 
pela mudança de estado do enlace entre R4 e R5. A nova topologia ficaria igual à figura 2.2.
Rede 3
R3
R4
R8 Área 3
Área Bac
Área 2
VL
É importante ressaltar que o Virtual Link é uma funcionalidade que deve ser utilizada para 
remediar um problema temporário, e não ser uma solução definitiva.
A principal função das áreas no OSPF é permitir que a topologia interna das áreas seja trans-
parente para as demais áreas. Isso é resolvido pelo roteador ABR, que filtra os LSAs Router e 
Network, gerando LSAs do tipo Summary. Então, mesmo que o LSA Router não seja recebido 
por roteadores OSPF de outras áreas, estes ainda receberão o LSA Summary para cada prefixo 
existente na área. Isso garante que a rede seja alcançável. Porém, se o Administrador da Rede 
quiser reduzir a quantidade de prefixos IP na tabela de rotas, é recomendável que os prefixos 
IP utilizados em uma área sejam agregáveis, ou seja, parte de um mesmo prefixo maior.
Figura 2.2 
Virtual Link entre 
R4 e R3.
NVirtual Links não 
podem ser criados via 
Área Stub. 
l
40
 
O
SP
F 
Av
an
ça
do
Dessa maneira, o ABR poderia sumarizar as rotas internas de uma Área e enviar apenas um 
LSA Summary com um prefixo agregado. Isso economizaria recursos de memória e aumenta 
a estabilidade da rede, pois caso um enlace oscile, os roteadores externos à área não pre-
cisam processar o LSDB novamente.
Entendendo o LSDB
De posse das informações sobre o tipos de Link State Advertisements vistos na sessão de 
aprendizagem 1 com as informações sobre as áreas OSPF da sessão 2, nesta sessãovamos 
estudar como funciona o banco de dados do OSPF, o Link State Data Base, quando múltiplas 
áreas são utilizadas. Conhecer o LSDB é extremamente importante para entender se as confi-
gurações estão corretas e para resolução de problemas. Para guiar nosso estudo, a figura 2.3 
será utilizada. Essa topologia está configurada no arquivo adr9-cap2-entendendo-lsdb.imn.
Área 2 Normal Área 3 
NSSA
Área 4 
Stub
R2
R3
R5
R7
R6
R4
5.5.5.5/32
6.6.6.6/32
1.1.1.1/32
R1
Área
Backbone
10.1.2.0/24
10.1.3.0/24
10.2.4.0/24
10.3.4.0/24
10.4.5.0/24
10.5.7.0/24
10.4.6.0/24
A seguir, detalhes da topologia:
 1 Existem seis roteadores OSPF (R1 até R6) e um roteador não OSPF (R7); 
 1 As conexões entre roteadores são feitas por enlaces Ethernet; 
 1 O prefixo IP entre dois roteadores seguirá a lógica 10.X.Y.0/24, onde X representa o 
número do menor roteador e Y o número do maior roteador. Por exemplo, entre R2 e R4, 
a rede será 10.2.4.0/24; 
 1 O último octeto será sempre o número do roteador. Por exemplo, em R2, no enlace que 
conecta com R4, o endereço da interface será 10.2.4.2/24. Em R4 será 10.2.4.4/24; 
 1 Todos os roteadores terão a interface loopback (lo) configurada com o prefixo IP, onde todos 
os octetos representam o número do roteador. Por exemplo, roteador R6 será 6.6.6.6/32; 
 1 Quando a interface Loopack estiver representada em uma nuvem dentro do retângulo 
que representa a área, a interface Loopback fará parte do processo OSPF; 
 1 Quando a interface Loopback estiver representada em uma nuvem fora do retângulo que 
representa a área, a interface Loopback será redistribuída no processo OSPF; 
 1 As Loopbacks dos roteadores R2, R3, R4 e R7 não estão representadas, mas serão 
configuradas seguindo a mesma ideia do item E. R2, R3 e R4 terão suas Loopbacks na 
Área Backbone; 
 1 Em R5 há uma rota estática apontando para a Loopback de R7; 
Figura 2.3 
Rede OSPF 
Multi-Área.
41
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
 1 Em R7 há uma rota padrão apontando para a interface de R5; 
 1 As conexões entre R1 e R3 e R3 e R4 terão custo alterado para 64; 
 1 As interfaces entre R1 e R3, além de R3 e R4, serão configuradas para funcionar no modo 
OSPF Ponto-a-Ponto.  
A: Observando o funcionamento do LSDB na Área Backbone
A1: Router-LSA e Network-LSA
q 1 Roteadores R2, R3 e R4 compõem a Área Backbone. 
 1 LSDB visto a partir de R4: 
R4# show ip ospf database
OSPF Router with ID (4.4.4.4)
Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Link count
2.2.2.2 2.2.2.2 412 0x80000006 0x8b60 2
3.3.3.3 3.3.3.3 13 0x80000010 0xd118 3
4.4.4.4 4.4.4.4 7 0x80000010 0x6e1d 4
Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum
10.2.4.4 4.4.4.4 412 0x80000001 0x27f6
 1 É possível observar a quantidade de enlaces (links) por roteador, além de um 
LSA Network. 
A composição mais simples do LSDB ocorre quando existe apenas uma área, a Área 
Backbone (também conhecida como Area 0.0.0.0). Na figura 2.3, a Área Backbone é composta 
pelos roteadores R2, R3 e R4. Entre R3 e R4 o enlace está configurado como Ponto-a-Ponto. 
Observe a estrutura do LSDB a partir do R4 (Router-ID 4.4.4.4) listando apenas os registros 
da Área 0 e LSAs Router e Network:
R4# show ip ospf database
OSPF Router with ID (4.4.4.4)
Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Link count
2.2.2.2 2.2.2.2 412 0x80000006 0x8b60 2
3.3.3.3 3.3.3.3 13 0x80000010 0xd118 3
4.4.4.4 4.4.4.4 7 0x80000010 0x6e1d 4
Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum
10.2.4.4 4.4.4.4 412 0x80000001 0x27f6
É possível observar que o LSDB possui três LSAs do Tipo 1 (Router LSA) e um LSA do Tipo 
2 (Network-LSA). Conforme apresentado na sessão de aprendizagem 1, o Router-LSA é 
utilizado por todos os roteadores OSPF para informar os estados dos seus enlaces, ou seja, 
prefixo IP, máscara, métrica, tempo de vida, status etc. A coluna ADV Router informa qual foi 
o roteador que gerou aquele LSA. No Router-LSA, a coluna Link ID sempre informa o Router 
ID do roteador OSPF. É possível ver o tempo de vida (Age), número de sequência (Seq), 
checksum e quantidade de enlaces por Router LSA. Como o LSDB é o mesmo em todos os 
roteadores da área, essa saída é a mesma nos roteadores R2 e R3.
42
 
O
SP
F 
Av
an
ça
do
Observe agora o Router-LSA gerado pelo roteador R2, primeiro Router-LSA da saída anterior 
(Advertising Router: 2.2.2.2) na Área Backbone:
R4# show ip ospf database router 2.2.2.2
Router Link States (Area 0.0.0.0)
LS age: 1119
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6 
Flags: 0x1 : ABR
LS Type: router-LSA
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 80000006
Checksum: 0x8b60
Length: 48
 Number of Links: 2
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.2.4.4
 (Link Data) Router Interface address: 10.2.4.2
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: Stub Network
 (Link ID) Net: 2.2.2.2
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
qDetalhamento do Router-LSA  gerado pelo Roteador R2:
R4# show ip ospf database router 2.2.2.2
Router Link States (Area 0.0.0.0)
LS age: 1119
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6 
Flags: 0x1 : ABR
LS Type: router-LSA
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 80000006
Checksum: 0x8b60
Length: 48
 Number of Links: 2
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.2.4.4
 (Link Data) Router Interface address: 10.2.4.2
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: Stub Network
 (Link ID) Net: 2.2.2.2
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
43
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
Alguns campos foram destacados em negrito e itálico, pois são as informações mais impor-
tantes. Primeiro campo que requer atenção é o campo “Flags”. Nele o bit E está configurado 
como 1, o que significa que esse LSA foi gerado por um roteador OSPF em uma área que 
suporta AS External LSA. Em uma área Stub, esse bit estaria configurado como 0. No campo 
das Flags, é possível ver que o roteador R2 se apresenta como um roteador ABR, pois este 
está conectado à Área Backbone e à Área 2. As informações de estado de enlace estão apre-
sentadas logo após o campo “Length”, e é possível ver duas entradas:
 1 Transit Network: indica que essa enlace é de uma rede de trânsito, ou seja, enlace 
que possui um Designated Router. Nesse caso, o campo “Link ID” é preenchido com o 
endereço IP do DR e o campo “Link Data” é preenchido com o IP do roteador que originou 
o LSA. Observe que os endereços IP utilizados são os endereços das interfaces, não o 
Router-ID (a tabela 1.1 da sessão de aprendizagem 1 explica como funciona o preenchi-
mento dos campos “Link ID” e “Link Data”); 
 1 Stub Network: uma vez que o endereço IP configurado na interface Loopback é utilizado 
como destino ou origem do tráfego (e não trânsito), o enlace da Loopback é anunciado 
como uma rede Stub (não confunda com Área Stub). 
A última informação de cada enlace é a métrica para chegar neste, que no caso está apre-
sentado como 10 (enlace FastEtherneté utilizado entre R2 e R4).
Observe agora o Router LSA gerado pelo roteador R4 (Advertising Router: 4.4.4.4):
R4# show ip ospf database router 4.4.4.4
 Router Link States (Area 0.0.0.0)
 LS age: 250
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x3 
 Flags: 0x3 : ABR ASBR
 LS Type: router-LSA
 Link State ID: 4.4.4.4
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000011
 Checksum: 0x6c1e
 Length: 60
 Number of Links: 4
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.2.4.4
 (Link Data) Router Interface address: 10.2.4.4
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 3.3.3.3
 (Link Data) Router Interface address: 10.3.4.4
 Number of TOS metrics: 0
 TOS 0 Metric: 64
 Link connected to: Stub Network
 (Link ID) Net: 10.3.4.0
 (Link Data) Network Mask: 255.255.255.0
 Number of TOS metrics: 0
44
 
O
SP
F 
Av
an
ça
do
 TOS 0 Metric: 64
 Link connected to: Stub Network
 (Link ID) Net: 4.4.4.4
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
qDetalhamento do Router-LSA gerado pelo Roteador R4:
R4# show ip ospf database router 4.4.4.4
 Router Link States (Area 0.0.0.0)
 LS age: 250
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x3 
 Flags: 0x3 : ABR ASBR
 LS Type: router-LSA
 Link State ID: 4.4.4.4
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000011
 Checksum: 0x6c1e
 Length: 60
 Number of Links: 4
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.2.4.4
 (Link Data) Router Interface address: 10.2.4.4
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Continuação:
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 3.3.3.3
 (Link Data) Router Interface address: 10.3.4.4
 Number of TOS metrics: 0
 TOS 0 Metric: 64
 Link connected to: Stub Network
 (Link ID) Net: 10.3.4.0
 (Link Data) Network Mask: 255.255.255.0
 Number of TOS metrics: 0
 TOS 0 Metric: 64
 Link connected to: Stub Network
 (Link ID) Net: 4.4.4.4
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
45
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
É possível observar que R4, além de ser um roteador ABR, é também um roteador ASBR, 
devido ao fato de estar conectado à área NSSA (todo roteador de borda de uma área NSSA 
é considerado um ASBR). Além disso, o Router-LSA mostra que R4 possui quatro registros 
de estado de enlace configurados na rede OSPF: um registro que faz parte de uma rede de 
trânsito, um que faz parte de uma rede ponto-a-ponto e dois registros de redes Stub:
 1 Transit Network: essa rede de trânsito é a mesma descrita no Router-LSA anterior, só 
que agora vista a partir do roteador R4 e preenchida da mesma maneira: no campo “Link 
ID” está o endereço IP do roteador DR (o próprio R4), e no campo “Link Data” o endereço 
IP do roteador que originou o LSA (nesse caso, próprio R4). Observe pelo endereçamento 
IP (10.2.4.4) que esse LSA se refere ao enlace entre os roteadores R2 e R4 
 1 another Router (point-to-point): esse LSA se refere ao enlace entre R3 e R4 (observe 
o endereçamento para confirmar: 10.3.4.4). Como a especificação da topologia dizia 
que o tipo de rede OSPF entre R3 e R4 seria Ponto-a-Ponto e redes ponto-a-ponto não 
fazem eleição de DR, não temos um LSA de Transit Network entre R3 e R4, e sim um LSA 
de Ponto-a-Ponto. Nesse caso, o Link Data é preenchido com o endereço IP no enlace 
do roteador originador, e o campo “Link ID” é preenchido com o Router ID do roteador 
vizinho. Como na especificação também dizia que o custo OSPF da interface seria alte-
rado para 64 (especificação K), é possível ver que o LSA possui métrica 64; 
 1 Stub Network com Link ID 10.3.4.0: toda vez que uma rede ponto-a-ponto for anun-
ciada pelo processo OSPF, além da entrada Tipo do Link 1 acima, outra entrada de Tipo do 
Link 3 deve ser criada. Nesse caso, a rede ponto-a-ponto também é considerada do tipo 
Stub e deve ser preenchida da seguinte maneira: o campo “Link ID” deve possuir o prefixo 
IP do enlace e o campo “Link Data” deve possuir a máscara de sub-rede. Observe que a 
métrica é a mesma: 64, que foi configurada manualmente na interface; 
 1 Stub Network com Link ID 4.4.4.4: essa entrada apresenta informações sobre a interface 
Loopback do roteador R4. Uma vez que o endereço IP configurado na interface Loopback 
é utilizado como destino ou origem do tráfego (e não trânsito), o enlace da Loopback é 
anunciado como uma rede Stub. 
A seguir, para finalizar o detalhamento dos Router-LSAs da Área Backbone (Area 0.0.0.0), 
observe o Router-LSA gerado pelo roteador R3:
R4# show ip ospf database router 3.3.3.3
 Router Link States (Area 0.0.0.0)
 LS age: 222
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x1 : ABR
 LS Type: router-LSA
 Link State ID: 3.3.3.3
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000017
 Checksum: 0xfd3c
 Length: 60
 Number of Links: 3
46
 
O
SP
F 
Av
an
ça
do
 Link connected to: Stub Network
 (Link ID) Net: 3.3.3.3
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 4.4.4.4
 (Link Data) Router Interface address: 10.3.4.3
 Number of TOS metrics: 0
 TOS 0 Metric: 64
 Link connected to: Stub Network
 (Link ID) Net: 10.3.4.0
 (Link Data) Network Mask: 255.255.255.0
 Number of TOS metrics: 0
 TOS 0 Metric: 64
qDetalhamento do Router-LSA gerado pelo Roteador R3:
R4# show ip ospf database router 3.3.3.3
 Router Link States (Area 0.0.0.0)
 LS age: 222
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x1 : ABR
 LS Type: router-LSA
 Link State ID: 3.3.3.3
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000017
 Checksum: 0xfd3c
 Length: 60
 Number of Links: 3
 Link connected to: Stub Network
 (Link ID) Net: 3.3.3.3
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 4.4.4.4
 (Link Data) Router Interface address: 10.3.4.3
 Number of TOS metrics: 0
 TOS 0 Metric: 64
 Link connected to: Stub Network
 (Link ID) Net: 10.3.4.0
 (Link Data) Network Mask: 255.255.255.0
 Number of TOS metrics: 0
 TOS 0 Metric: 64
47
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
É possível verificar que o roteador R3 possui três registros com informações de estado de 
enlace: dois registros para redes Stub e um registro para uma rede ponto-a-ponto. Assim 
como nos detalhamentos anteriores, a interface Loopback (3.3.3.3/255.255.255.255) está 
anunciada como uma rede Stub. O enlace entre os roteadores R3 e R4 foi manualmente 
configurado com o tipo de rede Ponto-a-Ponto. Logo se apresenta como tal (point-to-point), 
informando o Router-ID do roteador vizinho no campo “Link ID”. Por consequência, o prefixo IP 
usado nesse enlace ponto-a-ponto é anunciado como uma rede Stub (10.3.4.0/255.255.255.0).
Observeas métricas de 64 nas duas últimas entradas: lembre-se de que o custo da 
interface foi manualmente configurado como 64.
Apresentados os LSAs do Tipo 1 da Área Backbone, vamos apresentar o LSA do Tipo 2, 
ou Network LSA. Observe novamente a saída do Roteador R4 com LSAs do Tipo 1 e 2 da 
Área Backbone:
R4# show ip ospf database
OSPF Router with ID (4.4.4.4)
Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Link count
2.2.2.2 2.2.2.2 412 0x80000006 0x8b60 2
3.3.3.3 3.3.3.3 13 0x80000010 0xd118 3
4.4.4.4 4.4.4.4 7 0x80000010 0x6e1d 4
Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum
10.2.4.4 4.4.4.4 412 0x80000001 0x27f6
Apesar de o roteador R4 ter adjacências com R2 e R3, é possível ver que há apenas um 
Network LSA na Área Backbone, que se refere ao enlace entre R2 e R4 (observe o endereça-
mento IP no campo “Link ID”). Vamos analisar esse LSA:
R4# show ip ospf database network
 OSPF Router with ID (4.4.4.4)
 Net Link States (Area 0.0.0.0)
 LS age: 79
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x3 
 LS Type: network-LSA
 Link State ID: 10.2.4.4 (address of Designated Router)
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000001
 Checksum: 0x27f6
 Length: 32
 Network Mask: /24
 Attached Router: 2.2.2.2
 Attached Router: 4.4.4.4
48
 
O
SP
F 
Av
an
ça
do
qDetalhamento do Network-LSA gerado pelo Roteador R4:
R4# show ip ospf database network
 OSPF Router with ID (4.4.4.4)
 Net Link States (Area 0.0.0.0)
 LS age: 79
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x3 
 LS Type: network-LSA
 Link State ID: 10.2.4.4 (address of Designated Router)
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000001
 Checksum: 0x27f6
 Length: 32
 Network Mask: /24
 Attached Router: 2.2.2.2
 Attached Router: 4.4.4.4
É possível observar que esse LSA foi gerado pelo roteador R4 (o campo “Advertising Router” 
informa que originou o LSA), uma vez que ele é o Designated Router desse enlace. Apenas 
o DR gera LSAs do Tipo 2. Nele é possível ver qual é a máscara da rede (/24) e quais são os 
roteadores que fazem parte dessa rede (R2 e R4).
Neste momento você pode estar se perguntando: "Se R3 não está na lista de Attached 
Router nem tem um LSA do Tipo 2 que o inclua, o que aconteceu com R3"? Lembre-se de que 
o enlace entre R3 e R4 foi manualmente definido como um enlace ponto-a-ponto (ip ospf 
network point-to-point), logo, não há eleição de DR nesse tipo de rede.
q 1 Observe que o LSDB da Área Backbone não possui nenhum Network-LSA que inclua o 
roteador R3, e R3 não está na lista de Attached Router; 
 1 Isso acontece porque R3 tem seus enlaces configurados como Ponto-a-Ponto, logo 
não há DR ou BDR; 
 1 Lembre-se: apenas o DR gera LSAs do tipo Network. 
Nesse ponto, já temos melhor compreensão dos LSAs do Tipo 1 e do Tipo 2. Como ambos os 
tipos são restritos por área, é possível compreender que cada área possuirá um LSDB que 
inclua esses LSAs.
 1 Pudemos observar que o tipo de rede OSPF Broadcast gera dois registros: um LSA Router 
(Transit) e um LSA Network. No tipo de rede OSPF Ponto-a-Ponto, dois registros também 
são criados, porém ambos do tipo LSA Router (Point-to-Point e Stub).  
Uma vez que já foram apresentados ambos LSAs na sessão 1 e nas descrições anteriores, fica 
como atividade para o aluno detalhar os Router-LSAs ou os Network-LSAs das Áreas 2, 3 e 4.
A.2: Summary-LSA
Como cada área possui um LSDB próprio, é fundamental que os ABRs informem os demais 
roteadores OSPF sobre os prefixos ali contidos. Nesse caso, os ABRs vão gerar LSAs do Tipo 
3, ou Summary-LSAs que incluem os prefixos internos da área, ou seja, a partir dos LSA do 
Tipo 1, LSAs do Tipo 3 serão gerados para as outras áreas OSPF. Observe os LSDBs exis-
tentes no roteador R3 (LSAs Tipo 4 e 5 foram removidos):
49
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
R3# show ip ospf database
 OSPF Router with ID (3.3.3.3)
 Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Link count
2.2.2.2 2.2.2.2 1561 0x80000006 0x8b60 2
3.3.3.3 3.3.3.3 1560 0x80000006 0xb329 3
4.4.4.4 4.4.4.4 1401 0x80000009 0x3653 3
 Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum
10.2.4.4 4.4.4.4 1561 0x80000001 0x27f6
 Summary Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Route
1.1.1.1 2.2.2.2 282 0x80000002 0xc774 1.1.1.1/32
1.1.1.1 3.3.3.3 620 0x80000002 0xc73a 1.1.1.1/32
6.6.6.6 4.4.4.4 1014 0x80000001 0xa67a 6.6.6.6/32
10.1.2.0 2.2.2.2 1601 0x80000001 0xee4f 10.1.2.0/24
10.1.2.0 3.3.3.3 1580 0x80000001 0x53a6 10.1.2.0/24
10.1.3.0 2.2.2.2 1557 0x80000001 0x6696 10.1.3.0/24
10.1.3.0 3.3.3.3 1600 0x80000001 0xe31f 10.1.3.0/24
10.4.5.0 4.4.4.4 329 0x80000001 0x6dc2 10.4.5.0/24
10.4.6.0 4.4.4.4 641 0x80000002 0x60cd 10.4.6.0/24
 Router Link States (Area 0.0.0.2)
Link ID ADV Router Age Seq# CkSum Link count
1.1.1.1 1.1.1.1 1561 0x80000007 0xac8c 4
2.2.2.2 2.2.2.2 1562 0x80000004 0xf91e 1
3.3.3.3 3.3.3.3 1590 0x80000003 0x4244 2
 Net Link States (Area 0.0.0.2)
Link ID ADV Router Age Seq# CkSum
10.1.2.2 2.2.2.2 1562 0x80000001 0x1324
 Summary Link States (Area 0.0.0.2)
Link ID ADV Router Age Seq# CkSum Route
2.2.2.2 2.2.2.2 1601 0x80000001 0x370c 2.2.2.2/32
2.2.2.2 3.3.3.3 270 0x80000002 0xdf4a 2.2.2.2/32
3.3.3.3 2.2.2.2 1552 0x80000001 0xd159 3.3.3.3/32
3.3.3.3 3.3.3.3 1600 0x80000001 0xea50 3.3.3.3/32
4.4.4.4 2.2.2.2 1402 0x80000001 0x3ff1 4.4.4.4/32
4.4.4.4 3.3.3.3 1400 0x80000001 0x210c 4.4.4.4/32
6.6.6.6 2.2.2.2 1015 0x80000001 0x47d7 6.6.6.6/32
6.6.6.6 3.3.3.3 1013 0x80000001 0x29f1 6.6.6.6/32
10.2.4.0 2.2.2.2 1601 0x80000001 0xcc6e 10.2.4.0/24
10.2.4.0 3.3.3.3 1550 0x80000001 0x131a 10.2.4.0/24
10.3.4.0 2.2.2.2 1552 0x80000001 0x250b 10.3.4.0/24
10.3.4.0 3.3.3.3 1600 0x80000001 0xa293 10.3.4.0/24
10.4.5.0 2.2.2.2 329 0x80000001 0x0e20 10.4.5.0/24
10.4.5.0 3.3.3.3 327 0x80000001 0xef3a 10.4.5.0/24
10.4.6.0 2.2.2.2 1552 0x80000001 0x032a 10.4.6.0/24
10.4.6.0 3.3.3.3 1550 0x80000001 0xe444 10.4.6.0/24
50
 
O
SP
F 
Av
an
ça
do
qObserve que o ABR R3 possui um LSDB por área e cada área possui seus LSAs do tipo 
Summary:
R3# sh ip ospf database summary
 Summary Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Route
1.1.1.1 2.2.2.2 282 0x80000002 0xc774 1.1.1.1/32
1.1.1.1 3.3.3.3 620 0x80000002 0xc73a 1.1.1.1/32
6.6.6.6 4.4.4.4 1014 0x80000001 0xa67a 6.6.6.6/32
10.1.2.0 2.2.2.2 1601 0x80000001 0xee4f 10.1.2.0/24
10.1.2.0 3.3.3.3 1580 0x80000001 0x53a6 10.1.2.0/24
10.1.3.0 2.2.2.2 1557 0x80000001 0x6696 10.1.3.0/24
10.1.3.0 3.3.3.31600 0x80000001 0xe31f 10.1.3.0/24
10.4.5.0 4.4.4.4 329 0x80000001 0x6dc2 10.4.5.0/24
10.4.6.0 4.4.4.4 641 0x80000002 0x60cd 10.4.6.0/24
LSAs do Tipo Summary da Área 2:
R3# sh ip ospf database summary
 Summary Link States (Area 0.0.0.2)
Link ID ADV Router Age Seq# CkSum Route
2.2.2.2 2.2.2.2 1601 0x80000001 0x370c 2.2.2.2/32
2.2.2.2 3.3.3.3 270 0x80000002 0xdf4a 2.2.2.2/32
3.3.3.3 2.2.2.2 1552 0x80000001 0xd159 3.3.3.3/32
3.3.3.3 3.3.3.3 1600 0x80000001 0xea50 3.3.3.3/32
4.4.4.4 2.2.2.2 1402 0x80000001 0x3ff1 4.4.4.4/32
4.4.4.4 3.3.3.3 1400 0x80000001 0x210c 4.4.4.4/32
6.6.6.6 2.2.2.2 1015 0x80000001 0x47d7 6.6.6.6/32
6.6.6.6 3.3.3.3 1013 0x80000001 0x29f1 6.6.6.6/32
10.2.4.0 2.2.2.2 1601 0x80000001 0xcc6e 10.2.4.0/24
10.2.4.0 3.3.3.3 1550 0x80000001 0x131a 10.2.4.0/24
10.3.4.0 2.2.2.2 1552 0x80000001 0x250b 10.3.4.0/24
10.3.4.0 3.3.3.3 1600 0x80000001 0xa293 10.3.4.0/24
10.4.5.0 2.2.2.2 329 0x80000001 0x0e20 10.4.5.0/24
10.4.5.0 3.3.3.3 327 0x80000001 0xef3a 10.4.5.0/24
10.4.6.0 2.2.2.2 1552 0x80000001 0x032a 10.4.6.0/24
10.4.6.0 3.3.3.3 1550 0x80000001 0xe444 10.4.6.0/24
É possível observar que os prefixos IP que fazem parte do processo OSPF de cada área são 
inseridos como Summary-LSAs no LSDB das outras áreas. Por exemplo:
 1 Na Área Backbone (Area 0.0.0.0), é possível observar os prefixos 1.1.1.1 (Loopback de R1, 
que faz parte da Área 2) e 6.6.6.6 (Loopback de R6, que faz parte da Área 4). Esses pre-
fixos foram inseridos na Área Backbone pelos roteadores listados na coluna ADV Router; 
 1 Na Área 0.0.0.2, é possível observar o prefixo 6.6.6.6 como sendo anunciado pelos 
roteadores ABR da área. Nesse caso, os roteadores R2 e R3. Observe que os endereços 
Loopback de R2 e R3 também foram inseridos como Summary-LSAs na Área 2, devido ao 
fato de que eles estão configurados para operar na Área Backbone (conforme apresen-
tado nas descrições sobre Router-LSA). 
Os Summary-LSAs criados pelos roteadores R2 e R3 a partir dos Router-LSAs da Área 2 são 
enviados para os demais roteadores da Área Backbone. Ao receber esses Summary-LSAs, 
o roteador ABR R4 deverá executar uma das duas ações:
 1 Enviar para os roteadores de outras áreas (R5 e R6); 
51
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
 1 Não enviar para os roteadores de outras áreas. 
A opção por enviar ou não depende das configurações de cada área. Se o administrador da 
rede optar por não enviar os Summary-LSAs para os roteadores internos de cada área (seja 
por questão de engenharia de tráfego, economia de recursos dos roteadores ou devido ao 
fato de que há apenas um roteador ABR na área), essa configuração deverá ser feita no ABR, 
e nesse caso, uma rota padrão deverá ser gerada por esse ABR.
q 1 Em casos onde uma Área OSPF possui apenas um roteador ABR, por exemplo, as 
Áreas 3 e 6, o Engenheiro de Redes pode optar por enviar ou não os LSAs do tipo 
Summary recebidos de outros ABRs; 
 1 Como exemplo, observe o LSDB de R6 para cada caso: em um caso R4 envia os LSAs 
do tipo Summary, em outro não. 
Observe em R6 o LSDB nos dois casos. Primeiramente, sem filtragem alguma dos Summary-LSAs 
em R4 (comando OSPF area 4 stub em R4):
R6# show ip ospf database
 OSPF Router with ID (6.6.6.6)
 Router Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum Link count
4.4.4.4 4.4.4.4 7 0x80000013 0x3aac 1
6.6.6.6 6.6.6.6 6 0x8000000a 0x5755 2
 Net Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum
10.4.6.6 6.6.6.6 6 0x80000004 0x6995
 Summary Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum Route
1.1.1.1 4.4.4.4 3600 0x80000001 0x101d 1.1.1.1/32
2.2.2.2 4.4.4.4 3600 0x80000001 0x7db5 2.2.2.2/32
3.3.3.3 4.4.4.4 3600 0x80000001 0x4fdf 3.3.3.3/32
4.4.4.4 4.4.4.4 3600 0x80000001 0xbc78 4.4.4.4/32
10.1.2.0 4.4.4.4 3600 0x80000001 0x35f8 10.1.2.0/24
10.1.3.0 4.4.4.4 3600 0x80000001 0x48ae 10.1.3.0/24
10.2.4.0 4.4.4.4 3600 0x80000001 0xae86 10.2.4.0/24
10.3.4.0 4.4.4.4 3600 0x80000001 0xa291 10.3.4.0/24
10.4.5.0 4.4.4.4 3600 0x80000001 0x8ba6 10.4.5.0/24
qRoteador R4 configurado para criar a Área 4 como Stub:
R6# show ip ospf database
 OSPF Router with ID (6.6.6.6) 
 Summary Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum Route
1.1.1.1 4.4.4.4 3600 0x80000001 0x101d 1.1.1.1/32
2.2.2.2 4.4.4.4 3600 0x80000001 0x7db5 2.2.2.2/32
3.3.3.3 4.4.4.4 3600 0x80000001 0x4fdf 3.3.3.3/32
4.4.4.4 4.4.4.4 3600 0x80000001 0xbc78 4.4.4.4/32
10.1.2.0 4.4.4.4 3600 0x80000001 0x35f8 10.1.2.0/24
10.1.3.0 4.4.4.4 3600 0x80000001 0x48ae 10.1.3.0/24
10.2.4.0 4.4.4.4 3600 0x80000001 0xae86 10.2.4.0/24
10.3.4.0 4.4.4.4 3600 0x80000001 0xa291 10.3.4.0/24
10.4.5.0 4.4.4.4 3600 0x80000001 0x8ba6 10.4.5.0/24
52
 
O
SP
F 
Av
an
ça
do
Agora, observe o LSDB de R6 com a filtragem de LSAs do Tipo 3 aplicada em R4 (comando 
OSPF area 4 stub no-summary em R4):
R6# show ip ospf database
 OSPF Router with ID (6.6.6.6)
 Router Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum Link count
4.4.4.4 4.4.4.4 1063 0x80000007 0x52a0 1
6.6.6.6 6.6.6.6 532 0x80000006 0x5f51 2
 Net Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum
10.4.6.6 6.6.6.6 242 0x80000002 0x6d93
 Summary Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum Route
0.0.0.0 4.4.4.4 253 0x80000002 0x1934 0.0.0.0/0
qRoteador R4 configurado para criar a Área 4 como Stub com o parâmetro no-summary:
router ospf
area 4 stub no-summary
R6# show ip ospf database
 OSPF Router with ID (6.6.6.6)
 Summary Link States (Area 0.0.0.4 [Stub])
Link ID ADV Router Age Seq# CkSum Route
0.0.0.0 4.4.4.4 253 0x80000002 0x1934 0.0.0.0/0
 1 Com o parâmetro no-summary, o ABR gera uma rota padrão para a Área 4; 
 1 Como há apenas um ABR na Área 4, não haverá chance de os roteadores internos 
terem roteamento sub-otimizado. 
O Quagga 0.99 utilizado durante a escrita deste material mantém os registros do 
LSDB por algum tempo após o fim das adjacências e trocas de configuração, como 
essa informada. É necessário aguardar que os registros do LSBD expirem para serem 
removidos. As rotas são removidas normalmente. 
Enquanto que no primeiro exemplo R6 possui informações sobre todos os prefixos da rede, 
no segundo havia apenas um Summary-LSA gerado por R4, contendo a rota padrão. A seguir 
está o Summary-LSA com a rota padrão:
R6# sh ip ospf database summary
 OSPF Router with ID (6.6.6.6)
 Summary Link States (Area 0.0.0.4 [Stub])
 LS age: 831
 Options: 0x0 : *|-|-|-|-|-|-|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 0.0.0.0 (summaryNetwork Number)
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000002
53
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
 Checksum: 0x1934
 Length: 28
 Network Mask: /0
 TOS: 0 Metric: 1
qA seguir o LSA Summary com a rota padrão:
R6# sh ip ospf database summary
 OSPF Router with ID (6.6.6.6)
 Summary Link States (Area 0.0.0.4 [Stub])
 LS age: 831
 Options: 0x0 : *|-|-|-|-|-|-|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 0.0.0.0 (summary Network Number)
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000002
 Checksum: 0x1934
 Length: 28
 Network Mask: /0
 TOS: 0 Metric: 1
É possível observar que esse LSA é do Tipo 3, Summary-LSA, que o Link State ID é preenchido 
com o valor 0.0.0.0 e o campo “Network Mask” está preenchido com /0 (0.0.0.0). Nesse caso, 
0.0.0.0/0 indica a rota padrão a ser utilizada.
Observe que em ambos os casos as redes externas à área serão alcançáveis. Porém, 
ao usarmos a opção de envio de rota padrão, o LSDB do R6 possui menos registros 
para serem gerenciados. 
A.3: AS External LSA
Na topologia da figura 2.3, foi definido que o roteador R5 faria redistribuição de dois prefixos 
na Área 3: a sua loopback (5.5.5.5) e a rota estática que aponta para a loopback do roteador 
R7 (7.7.7.7). Essas interfaces estão sendo redistribuídas no processo OSPF para demonstrar 
uma rota externa ao processo OSPF. Dentro da Área 3, que é uma área NSSA, é utilizado o 
LSA Tipo 7. Porém, uma vez que esse LSA chega ao ABR da rede, esse é convertido para o LSA 
do Tipo 5, AS-External-LSA, e enviado para todos os roteadores OSPF da Área Backbone e 
pelos ABRs para as outras áreas (menos Stub e NSSA). Observe o LSDB do roteador R1:
R1# sh ip ospf database external
 OSPF Router with ID (1.1.1.1)
 AS External Link States
 LS age: 324
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: AS-external-LSA
 Link State ID: 5.5.5.5 (External Network Number)
54
 
O
SP
F 
Av
an
ça
do
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000008
 Checksum: 0x6417
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 10.4.5.5
 External Route Tag: 0
 LS age: 330 mnbv
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: AS-external-LSA
 Link State ID: 7.7.7.7 (External Network Number)
 Advertising Router: 4.4.4.4
 LS Seq Number: 8000000a
 Checksum: 0x046d
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 10.4.5.5
 External Route Tag: 0
q 1 Roteador R5 faz redistribuição de uma rota estática (7.7.7.7/32) e da sua interface 
Loopack (5.5.5.5/32); 
 1 Rotas redistribuídas são anunciadas com LSAs do tipo AS-External ou NSSA, depen-
dendo da Área; 
 1 Área 3 é uma Área NSSA, logo os prefixos 7.7.7.7/32 e 5.5.5.5/32 são anunciados com 
LSA NSSA External; 
 1 ABR da Área 3 converte para LSA AS-External e envia para a Área Backbone; 
 1 Como LSAs do tipo AS-External se mantêm inalterados pela Rede OSPF, R1 os enxerga 
da maneira que é criado pelo R4/ABR da Área 3. 
É possível constatar que ambos os prefixos redistribuídos constam no LSDB do roteador 
R1, e ambos como LSAs do Tipo 5 (AS-External-LSA). É possível ver que o roteador que 
originou o LSA foi o roteador R4 (4.4.4.4) e ambos possuem o endereço IP 10.4.5.5 como 
endereço de encaminhamento (Forward Address). Além disso, observe que ambos os pre-
fixos foram redistribuídos como métrica do tipo E2 (Metric Type: 2) e possuem custo de 20. 
É importante observar que R4 consta no campo “Advertising Router” por ter sido o res-
ponsável pela tradução do LSA do Tipo 7 para o LSA do Tipo 5. O verdadeiro originador do 
prefixo é o roteador R5, porém, esse está em uma área NSSA.
55
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
q 1 LSA AS-External em R1; 
 1 Prefixo 5.5.5.5/32. 
R1# sh ip ospf database external
 OSPF Router with ID (1.1.1.1)
 AS External Link States
 LS age: 324
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: AS-external-LSA
 Link State ID: 5.5.5.5 (External Network Number)
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000008
 Checksum: 0x6417
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 10.4.5.5
 External Route Tag: 0
 1 LSA AS-External em R1; 
 1 Prefixo 7.7.7.7/32. 
 LS age: 330
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
LS Type: AS-external-LSA
 Link State ID: 7.7.7.7 (External Network Number)
 Advertising Router: 4.4.4.4
 LS Seq Number: 8000000a
 Checksum: 0x046d
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 10.4.5.5
 External Route Tag: 0
Observe que o roteador que criou o LSA foi o R4 (Advertising Router: 4.4.4.4). 
Apenas como exemplo, vamos alterar a configuração do roteador R1 e remover sua Loopback 
do processo OSPF (comando: no network 1.1.1.1/32 area 2) e redistribuí-la no OSPF (comando: 
redistribute connected). Observe como ficaria o LSA do ponto de vista do roteador R4:
R4# sh ip ospf database external
 OSPF Router with ID (4.4.4.4)
 AS External Link States
 LS age: 18
 Options: 0x2 : *|-|-|-|-|-|E|*
56
 
O
SP
F 
Av
an
ça
do
 LS Flags: 0x6 
 LS Type: AS-external-LSA
 Link State ID: 1.1.1.1 (External Network Number)
 Advertising Router: 1.1.1.1
 LS Seq Number: 80000001
 Checksum: 0x5f57
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 0.0.0.0
 External Route Tag: 0
qObserve como o LSA AS-External é criado em uma Área não NSSA:
R4# sh ip ospf database external
 OSPF Router with ID (4.4.4.4)
 AS External Link States
 LS age: 18
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: AS-external-LSA
 Link State ID: 1.1.1.1 (External Network Number)
 Advertising Router: 1.1.1.1
 LS Seq Number: 80000001
 Checksum: 0x5f57
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 0.0.0.0
 External Route Tag: 0
Observe o comportamento padrão do ASBR ao criar LSAs do tipo AS-External: o campo 
”Forward Address” foi preenchido com IP 0.0.0.0, diferente dos LSA do tipo NSSA-External.
Como é possível verificar, tanto o prefixo (Link State ID) quanto o originador (Advertising 
Router) estão preenchidos com o endereço do Router-ID de R1 (1.1.1.1). Como os roteadores 
ABR não fazem alteração em LSA do Tipo 5, o LSA é mantido intacto ao longo da rede OSPF. 
Lembre-se de que quando o Forward Address estiver preenchido com 0.0.0.0, os pacotes 
devem ser enviados ao IP do Advertising Router.
Observe que o AS-External-LSA não é associado a área alguma; logo, não tem 
nenhuma informação de área, tipo (Area 0.0.0.0). Por isso, não deve ser manipulado 
pelos ABRs. 
57
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
A.4: ASBR Summary LSA
Já que os roteadores OSPF devempreservar os AS-External-LSAs intactos e estes são gerados 
por roteadores ASBR, é necessário ter um mecanismo que permita que os demais roteadores 
OSPF saibam como chegar no ASBR. Com esse propósito, foi criado o ASBR-Summary-LSA, 
conforme apresentado na sessão de aprendizagem 1, que indica como chegar ao ASBR. Como 
no AS-External-LSA visto por R1 consta R4 como Advertising Router, R1 precisa saber como 
chegar em R4. Para isso, R1 deve verificar se possui algum ASBR-Summary-LSA com o ende-
reço de R4. Observe a saída a seguir:
R1# sh ip ospf database asbr-summary
 OSPF Router with ID (1.1.1.1)
 ASBR-Summary Link States (Area 0.0.0.2)
 LS age: 770
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 4.4.4.4 (AS Boundary Router address)
 Advertising Router: 2.2.2.2
 LS Seq Number: 80000008
 Checksum: 0xbe74
 Length: 28
 Network Mask: /32
 TOS: 0 Metric: 10
 LS age: 1130
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 4.4.4.4 (AS Boundary Router address)
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000007
 Checksum: 0xa28d
 Length: 28
 Network Mask: /32
 TOS: 0 Metric: 10
qComo R4 gerou LSAs do tipo AS-External, um LSA do tipo ASBR-Summary precisa ser 
criado. Observe como R1 aprende o caminho para 4.4.4.4 via R2 (2.2.2.2).
R1# sh ip ospf database asbr-summary 
 OSPF Router with ID (1.1.1.1)
 ASBR-Summary Link States (Area 0.0.0.2)
 LS age: 770
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 4.4.4.4 (AS Boundary Router address)
 Advertising Router: 2.2.2.2
58
 
O
SP
F 
Av
an
ça
do
q LS Seq Number: 80000008
 Checksum: 0xbe74
 Length: 28
 Network Mask: /32
 TOS: 0 Metric: 10
Observe como R1 aprende o caminho para 4.4.4.4 via R3 (3.3.3.3):
 LS age: 1130
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 4.4.4.4 (AS Boundary Router address)
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000007
 Checksum: 0xa28d
 Length: 28
 Network Mask: /32
 TOS: 0 Metric: 10
Como os ASBR Summary LSAs são gerados pelos roteadores ABR, através do campo Advertising 
Router, R1 consegue ver quais são os roteadores ABR da Área da qual faz parte (Área 0.0.0.2) 
que devem ser utilizados para encaminhar os pacotes. Nesse caso, como a Área 0.0.0.2 
possui dois ABRs (R2 e R3), cada um gera um ASBR Summary LSA.
No caso do nosso exemplo que altera a Loopback de R1, observe como R4 se informa sobre 
como chegar a R1:
R4# sh ip ospf database asbr-summary
 OSPF Router with ID (4.4.4.4)
 ASBR-Summary Link States (Area 0.0.0.0)
 LS age: 749
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 1.1.1.1 (AS Boundary Router address)
 Advertising Router: 2.2.2.2
 LS Seq Number: 80000001
 Checksum: 0x57ee
 Length: 28
 Network Mask: /32
 TOS: 0 Metric: 10
 LS age: 749
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: summary-LSA
 Link State ID: 1.1.1.1 (AS Boundary Router address)
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000001
59
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
 Checksum: 0x57b4
 Length: 28
 Network Mask: /32
 TOS: 0 Metric: 64
Novamente, como R1 está em uma área com dois roteadores ABR na Área 2, duas entradas 
são observadas no LSDB de R4: uma via R2, outra via R3.
A.5: NSSA-LSA
O último LSA existente na rede OSPF da figura 2.3 é o NSSA-External-LSA. Como existem 
apenas dois roteadores OSPF na Área NSSA, utilize a saída a seguir para verificar os LSAs do 
Tipo 7 existentes no LSDB do roteador R4:
R4# sh ip ospf database nssa-external
 OSPF Router with ID (4.4.4.4)
 NSSA-external Link States (Area 0.0.0.3 [NSSA])
 LS age: 125
 Options: 0xa : *|-|-|-|N/P|-|E|*
 LS Flags: 0x6 
 LS Type: NSSA-LSA
 Link State ID: 5.5.5.5 (External Network Number for NSSA)
 Advertising Router: 5.5.5.5
 LS Seq Number: 80000001
 Checksum: 0xbfb4
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 NSSA: Forward Address: 10.4.5.5
 External Route Tag: 0
 LS age: 2
 Options: 0xa : *|-|-|-|N/P|-|E|*
 LS Flags: 0x6 
 LS Type: NSSA-LSA
 Link State ID: 7.7.7.7 (External Network Number for NSSA)
 Advertising Router: 5.5.5.5
 LS Seq Number: 80000003
 Checksum: 0x5f0b
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 NSSA: Forward Address: 10.4.5.5
 External Route Tag: 0
60
 
O
SP
F 
Av
an
ça
do
qComo R5 fez redistribuição na Área 3, que é uma Área NSSA, os prefixos redistribuídos 
são com LSAs do tipo NSSA-External.
Observe o LSDB do ABR da Área 3, com LSAs do tipo NSSA-External:
R4# sh ip ospf database nssa-external
 OSPF Router with ID (4.4.4.4)
 NSSA-external Link States (Area 0.0.0.3 [NSSA])
 LS age: 125
 Options: 0xa : *|-|-|-|N/P|-|E|*
 LS Flags: 0x6 q LS Type: NSSA-LSA
 Link State ID: 5.5.5.5 (External Network Number for NSSA)
 Advertising Router: 5.5.5.5
 LS Seq Number: 80000001
 Checksum: 0xbfb4
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 NSSA: Forward Address: 10.4.5.5
 External Route Tag: 0
 LS age: 2
 Options: 0xa : *|-|-|-|N/P|-|E|*
 LS Flags: 0x6 
 LS Type: NSSA-LSA
 Link State ID: 7.7.7.7 (External Network Number for NSSA)
 Advertising Router: 5.5.5.5
 LS Seq Number: 80000003
 Checksum: 0x5f0b
 Length: 36
 Network Mask: /32
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 NSSA: Forward Address: 10.4.5.5
 External Route Tag: 0
Observe o comportamento padrão do ASBR em Áreas NSSA: o campo “Forward Address” 
foi preenchido com o IP da interface OSPF, diferente dos LSA do tipo AS-External.
O formato do pacote é idêntico ao AS-External-LSA, mudando apenas o preenchimento dos 
campos “LS Type”, de Tipo 5 para Tipo 7, e o Forward Address. Nos roteadores externos à 
área NSSA, após a tradução de Tipo 7 para LSA do Tipo 5, para que a rota seja instalada, o 
roteador remoto precisa fazer uso do ASBR-Summary-LSA, que é gerado pelo ABR.
Apesar de permitir a redistribuição de prefixos externos ao processo OSPF, as áreas NSSA 
têm as características das áreas Stub; logo, não há encaminhamento de AS-External-LSAs. 
Além disso, caso o Engenheiro de Rede responsável deseje, podemos controlar o envio de 
Summary LSAs, injetando apenas a rota padrão na área.
61
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
A.6: Virtual Links
Como apresentado anteriormente, Virtual Links devem ser utilizados para conectar partes 
desconexas da mesma área. Vamos ilustrar também utilizando a figura 2.3. Como estudo de 
caso, vamos utilizar o endereço 2.2.2.2/32, que é a Loopback do roteador R2. A Loopback 
faz parte da Área Backbone, conforme a descrição apresentada anteriormente e as saídas 
apresentadas a seguir.
q 1 Vamos utilizar o endereço 2.2.2.2/32 como estudo de caso para Virtual Link; 
 1 Interface Loopback de R2 está configurado como parte da Área Backbone; 
 1 Observe oLSDB em R4 com o registro do IP 2.2.2.2/32 (saída abreviada): 
R4# show ip ospf database router
 OSPF Router with ID (4.4.4.4)
 Router Link States (Area 0.0.0.0)
 Flags: 0x1 : ABR
 LS Type: router-LSA
 Link State ID: 2.2.2.2
 Advertising Router: 2.2.2.2
 (...)
 Link connected to: Stub Network
 (Link ID) Net: 2.2.2.2
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
Observe que o roteador R4 possui em seu LSDB um Router LSA recebido de R2 (Advertising 
Router: 2.2.2.2), e que há um registro Stub para a rede 2.2.2.2/255.255.255.255. Observe 
também que há um registro de Transit Network com DR sendo roteador R4 (10.2.4.4).
R4# show ip ospf database router
 OSPF Router with ID (4.4.4.4)
 Router Link States (Area 0.0.0.0)
 LS age: 103
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x1 : ABR
 LS Type: router-LSA
 Link State ID: 2.2.2.2
 Advertising Router: 2.2.2.2
 LS Seq Number: 80000007
 Checksum: 0x8961
 Length: 48
 Number of Links: 2
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.2.4.4
 (Link Data) Router Interface address: 10.2.4.2
 Number of TOS metrics: 0
 TOS 0 Metric: 10
62
 
O
SP
F 
Av
an
ça
do
 Link connected to: Stub Network
 (Link ID) Net: 2.2.2.2
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
Observe a seguir que R2 e R4 possuem uma adjacência OSPF; logo, utilizando o Router LSA 
anterior e a informação de adjacência. O roteador R4 cria uma rota para 2.2.2.2/32, com 
métrica 20 (10 do registro Transit Network mais 10 do registro Stub Network).
R4# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 
2.2.2.2 1 Full/Backup 35.275s 10.2.4.2 eth0:10.2.4.4 
R4# show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
 Known via "ospf", distance 110, metric 20, best
 Last update 00:00:51 ago
 * 10.2.4.2, via eth0
qÉ possível ver que R4 possui adjacência com R2:
R4# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 
2.2.2.2 1 Full/Backup 35.275s 10.2.4.2 eth0:10.2.4.4 
R4# show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
 Known via "ospf", distance 110, metric 20, best
 Last update 00:00:51 ago
 * 10.2.4.2, via eth0
Com o registro LSA e a adjacência com R2, R4 cria a rota para 2.2.2.2/32 diretamente; 
 1 Para testar o Virtual Link, o enlace entre R2 e R4 será removido; logo a Loopback de 
R2 ficará em uma partição separada da Área Backbone; 
 1 Após a remoção do LSA, a rota é removida de R4: 
R4# show ip route 2.2.2.2
% Network not in table
Vamos desativar o enlace entre R2 e R4. Como esse enlace é o único utilizado por R2 para se 
conectar à Área Backbone, há uma segregação da Área Backbone, onde a Loopback de R2 ficou 
isolada. Observe a seguir as saídas para confirmar que não há mais uma rota para 2.2.2.2/24:
R4# show ip route 2.2.2.2
% Network not in table
Observe que ainda assim há um Router LSA do roteador R2 no LSDB de R4. O Quagga não 
remove o registro imediatamente; porém, como não há mais adjacência, a rota não é criada.
Vamos agora configurar um Virtual Link entre R2 e R3, via R1. A Área 2 será utilizada para 
criar esse Virtual Link. A configuração de Virtual Link é feita nos dois roteadores, cada um 
utilizando o Router-ID do roteador remoto.
63
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
qCriação do Virtual Link entre R2 e R3:
 1  Configuração aplicada em R2: 
router ospf
area 2 virtual-link 3.3.3.3
 1 Configuração aplicada em R3: 
router ospf
area 2 virtual-link 2.2.2.2
A seguinte configuração será aplicada em R2 para criar o Virtual Link:
router ospf
area 2 virtual-link 3.3.3.3
A seguinte configuração será aplicada em R3 para criar o Virtual Link:
router ospf
area 2 virtual-link 2.2.2.2
qObserve a adjacência criada entre R2 e R3:
R2# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 
3.3.3.3 1 Full/DROther 39.483s 10.1.3.3 VLINK0 
R3# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 
2.2.2.2 1 Full/DROther 39.656s 10.1.2.2 VLINK0 
A rota é então criada novamente em R4, apontando para R3:
R4# show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
 Known via "ospf", distance 110, metric 40, best
 Last update 00:00:07 ago
 * 10.3.4.3, via eth1
Observe que agora há uma rota para 2.2.2.2/24 em R4, via R3 (10.3.4.3). Observe também 
que a métrica não é mais 20, e sim 40 (10 para R4 chegar em R3, 20 do Virtual Link e 10 para 
a Loopback).
R4# show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
 Known via "ospf", distance 110, metric 40, best
 Last update 00:00:07 ago
 * 10.3.4.3, via eth1
Observe em R2 e R3 a adjacência utilizando o Virtual Link (VLINK0)
R2# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 
3.3.3.3 1 Full/DROther 39.483s 10.1.3.3 VLINK0 
R3# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 
2.2.2.2 1 Full/DROther 39.656s 10.1.2.2 VLINK0 
64
 
O
SP
F 
Av
an
ça
do
Observe a seguir como R4 recebe o registro para o prefixo 2.2.2.2/32. Primeiro, observe o 
Router LSA de R3 informando o Virtual Link.
R4# show ip ospf database router
 OSPF Router with ID (4.4.4.4)
 Router Link States (Area 0.0.0.0)
 LS age: 690
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x1 : ABR
 LS Type: router-LSA
 Link State ID: 3.3.3.3
 Advertising Router: 3.3.3.3
 LS Seq Number: 8000000a
 Checksum: 0x1c7e
 Length: 60
 Number of Links: 3
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.3.4.4
 (Link Data) Router Interface address: 10.3.4.3
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: Stub Network
 (Link ID) Net: 3.3.3.3
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: a Virtual Link
 (Link ID) Neighboring Router ID: 2.2.2.2
 (Link Data) Router Interface address: 10.1.3.3
 Number of TOS metrics: 0
 TOS 0 Metric: 20
qObserve o Router LSA de R3 (10.1.3.3) informando o Virtual Link.
R4# show ip ospf database router
 OSPF Router with ID (4.4.4.4)
 Router Link States (Area 0.0.0.0)
(...)
 Link connected to: a Virtual Link
 (Link ID) Neighboring Router ID: 2.2.2.2
 (Link Data) Router Interface address: 10.1.3.3
 Number of TOS metrics: 0
 TOS 0 Metric: 20
65
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
A seguir observe como R4 agora possui um Router LSA originado por R2 com o registro Stub 
da interface Loopback.
R4# show ip ospf database router
 OSPF Router with ID (4.4.4.4)
 Router Link States (Area 0.0.0.0)
 LS age: 895
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x1 : ABR
 LS Type: router-LSA
 Link State ID: 2.2.2.2
 Advertising Router: 2.2.2.2
 LS Seq Number: 8000000d
 Checksum: 0x578c
 Length: 48
 Number of Links: 2
 Link connected to: Stub Network
 (Link ID) Net: 2.2.2.2
 (Link Data) Network Mask: 255.255.255.255
 Number of TOS metrics: 0TOS 0 Metric: 10
 Link connected to: a Virtual Link
 (Link ID) Neighboring Router ID: 3.3.3.3
 (Link Data) Router Interface address: 10.1.2.2
 Number of TOS metrics: 0
 TOS 0 Metric: 20
Observe o Router LSA de R2 (2.2.2.2) informando o Virtual Link.
R4# show ip ospf database router
 OSPF Router with ID (4.4.4.4)
 Router Link States (Area 0.0.0.0)
 LS age: 895
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x1 : ABR
 LS Type: router-LSA
 Link State ID: 2.2.2.2
 Advertising Router: 2.2.2.2
 (...)
 Link connected to: a Virtual Link
 (Link ID) Neighboring Router ID: 3.3.3.3
 (Link Data) Router Interface address: 10.1.2.2
 Number of TOS metrics: 0
 TOS 0 Metric: 20
Observe que o Quagga não coloca no campo “Link Data” o endereço da interface conforme 
sugere a RFC2328. Em vez de adicionar o ifIndex da interface do Virtual Link, o endereço IP 
do roteador é utilizado.
66
 
O
SP
F 
Av
an
ça
do
Conclusão
Nesta sessão, foram apresentados os tipos de área existentes, como cada área funciona e 
quais LSAs são utilizados. Na próxima sessão, serão apresentadas técnicas que podem ser 
utilizadas para melhorar ou ajustar o roteamento dos pacotes em uma rede OSPF e como 
otimizar a convergência.
Comandos OSPF
A seguir, uma lista de comandos de configuração que têm relação com o tema da sessão de 
aprendizagem 2, para serem utilizados no Quagga.  
Todos os comandos são aplicados na sessão de OSPF do roteador. Em destaque, as 
palavras-chave.
 1 Adiciona as interfaces que são parte do prefixo informado na Área Backbone:
network prefixo máscara área 0
 1  Adiciona as interfaces que são parte do prefixo informado em uma área Stub:
network prefixo máscara área X.X.X.X
area X.X.X.X stub
 1 Gera uma rota padrão em uma área Stub (utilizado no ABR):
area X.X.X.X stub no-summary
 
 1 Origina uma rota padrão na rede OSPF:
Default-information originate [always] [metric METRICA] [metric-type 1|2]
 
 1 Criar uma Área NSSA em um roteador interno:
network prefixo máscara área Z.Z.Z.Z
area Z.Z.Z.Z nssa
 1 Criar uma Área NSSA e gera uma rota padrão na área (utilizado no ABR):
network prefixo máscara área Z.Z.Z.Z
area Z.Z.Z.Z nssa no-summary
 1 Redistribui rotas estáticas no OSPF:
redistribute static
 
 1 Redistribui interfaces conectadas no OSPF:
redistribute connected
 
 1 Redistribui rotas do protocolo RIP no OSPF:
redistribute rip metric 2
 
 1 Cria um Virtual Link:
area Area_Transito virtual-link Router_ID_ABR
67
 
C
ap
ítu
lo
 2
 - 
En
te
nd
en
do
 a
s 
ár
ea
s 
do
 O
SP
F
A seguir, uma lista dos comandos de observação que têm relação com o tema da sessão de 
aprendizagem 2.
 1 Exibe informações sobre o processo OSPF:
show ip ospf
 
 1 Exibe informações resumidas sobre o banco de dados OSPF:
show ip ospf database
 
 1 Exibe informações detalhadas por LSA:
show ip ospf database <router|network|summary|asbr-summary|external|nssa-
external>
 
 1 Exibe informações por tipo de LSA originado pelo roteador:
show ip ospf database self-originated
 1  Exibe informações sobre o processo OSPF em uma determinada interface: 
show ip ospf interfaces
 
 1 Exibe as adjacências OSPF estabelecidas:
show ip ospf neighbor
68
 
O
SP
F 
Av
an
ça
do
69
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
 
 
ob
je
tiv
os
conceitos
3
Engenharia de tráfego com OSPF
Aprender sobre sumarização; Conhecer agregação de rotas; Entender como funciona 
a manipulação de rotas; Conhecer sobre filtragem de prefixos.
 
Sumarização de rotas; Agregação de Rotas; Métricas; Escolha de Caminhos pelo OSPF; 
Controlando Atualizações de Roteamento.
 
 
Introdução
As sessões de aprendizagem 1 e 2 apresentaram detalhes avançados sobre o funciona-
mento do OSPF, permitindo ao aluno entender como o OSPF contrói o LSDB e como as 
mensagens são negociadas, além de detalhar o funcionamento das áreas OSPF. Até esse 
momento, as configurações OSPF utilizadas ficaram muito próximas das configurações 
padrão do OSPF.
Mesmo essas configurações mais simples permitiram que as diversas topologias ilustradas 
tivessem um roteamento dinâmico eficaz e livre de loops. Porém, o OSPF permite ajustes 
mais finos para refletir necessidades de redes mais complexas, o que inclui escolha de cami-
nhos alternativos, economia de recursos dos roteadores e filtros de prefixos. Esta sessão vai 
detalhar alguns desses ajustes finos possíveis, entre eles sumarização e agregação de rotas; 
manipulação de rotas e filtragem de prefixos.
Sumarização de rotas
q 1 Sumarização de rotas; 
 1 Áreas OSPF permitem que a topologia de uma área seja abstraída das demais áreas; 
 1 Roteadores ABR criam LSAs do tipo Summary para cada LSA do tipo Router e envia 
para as demais Áreas OSPF. 
 2 Caso um LSA Router seja removido do LSDB, um LSA Summary é enviado infor-
mando da remoção; 
 2 Demais roteadores OSPF precisam recalcular as rotas; 
 2 Recursos computacionais são consumidos a cada incidente. 
 1 Existem otimizações possíveis. 
70
 
O
SP
F 
Av
an
ça
do
Foi mostrado nas sessões anteriores que uma das principais vantagens de usar particiona-
mento da rede criando áreas OSPF é a contenção de detalhes da topologia inerentes de cada 
área. Como os LSAs Router e Network ficam contidos no LSDB da área, a topologia é abstraída 
das demais áreas e apenas LSAs do tipo Summary são enviados com os prefixos internos.
Na configuração padrão do OSPF, cada LSA Router recebido pelo roteador ABR dispara a criação 
de um LSA Summary que, apesar de não prover detalhes da topologia interna, ainda assim é 
processado pelos demais roteadores OSPF da Área Backbone como parte da topologia da rede. 
Apesar de esse procedimento estar correto, em determinadas situações, esse modo de 
funcionamento pode ser otimizado. Observe a figura 3.1.
Área Backbone
192.168.1.0/24
R5
192.168.0.0/24
R4
192.168.2.0/24
R6
192.168.3.0/24
R7
192.168.6.0/24
R10
192.168.7.4/31
192.168.7.2/31
19
2.1
68
.7.
12
/3
119
2.16
8.7.
6/31
192.168.7.0/31
ABR
R2
R3
(. . .)
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
Área 1
A rede OSPF da figura 3.1 tem as seguintes características:
 1 Duas áreas OSPF: Área Backbone e Área 1; 
 1 Um roteador ABR (Router-ID 10.1.2.1); 
 1 Sete roteadores OSPF internos na Área 1 (R4 até R10); 
 1 Sete enlaces saindo do ABR para os roteadores OSPF internos (com prefixos 
192.168.7.x/31); 
 1 Sete redes internas com prefixo 192.168.[0-6].0/24; 
 1 Além do roteador ABR, a Área Backbone possui outros dois roteadores OSPF (R2 e R3). 
Figura 3.1 
Área 1 com 
configuração 
padrão OSPF.
71
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
qABR vai criar um LSA Summary para cada LSA Router recebido:
 1 Quatorze LSAs do tipo Summary vão virar 14 rotas em R2 e R3; 
Cada vez que um enlace entre ABR e um roteador da Área 1 mudar de estado, dois LSAs 
do tipo Summary serão criados pelo ABR. 
 1 R2 e R3 vão recalcular as rotas; 
 1 Como não há outro caminho para tais prefixos, R2 e R3 vão remover os prefixos infor-
mados pelos LSAs do tipo Summary recebidos do ABR; 
 1 Quando o enlace for restaurado, R2 e R3 vão recriar as rotas a partir dos LSAs recebidos. 
Nessa topologia, para cadaLSA Router da Área 1, o roteador ABR vai gerar um LSA Summary 
para os demais roteadores da Área Backbone. Assim que a rede é estabelecida, os rotea-
dores R2 e R3 vão criar 14 rotas, uma por LSA Summary recebido do roteador ABR. Apesar 
de a topologia da Área 1 ser desconhecida para os roteadores R2 e R3, toda vez que um dos 
enlaces entre o ABR e um roteador OSPF interno cair, o ABR vai gerar e enviar dois LSAs do 
tipo Summary: um para informar que o enlace com o roteador OSPF interno está indispo-
nível, e outro para informar que a rede atrás do roteador OSPF interno está inacessível.
Cada roteador da Área Backbone vai então recalcular o LSDB, removendo as rotas para 
os destinos recém-informados. Observe a seguir o LSDB do roteador R2 com os 14 LSAs 
do tipo Summary recebidos do roteador ABR (teste você mesmo com o arquivo 
adr9-cap3-sumarizacao.imn):
R2# show ip ospf database
 OSPF Router with ID (10.1.2.2)
 Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Link count
10.1.2.1 10.1.2.1 41 0x80000008 0x913e 2
10.1.2.2 10.1.2.2 45 0x80000007 0xd4f6 2
10.1.3.3 10.1.3.3 41 0x80000006 0xfcc6 2
 Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum
10.1.2.2 10.1.2.2 45 0x80000001 0x67b7
10.1.3.3 10.1.3.3 41 0x80000001 0x60b8
10.2.3.3 10.1.3.3 51 0x80000001 0x5eb8
 Summary Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Route
192.168.0.0 10.1.2.1 234 0x80000001 0x0cc5 192.168.0.0/24
192.168.1.0 10.1.2.1 234 0x80000001 0x01cf 192.168.1.0/24
192.168.2.0 10.1.2.1 234 0x80000001 0xf5d9 192.168.2.0/24
192.168.3.0 10.1.2.1 234 0x80000001 0xeae3 192.168.3.0/24
192.168.4.0 10.1.2.1 233 0x80000001 0xdfed 192.168.4.0/24
192.168.5.0 10.1.2.1 233 0x80000001 0xd4f7 192.168.5.0/24
192.168.6.0 10.1.2.1 233 0x80000001 0xc902 192.168.6.0/24
192.168.7.0 10.1.2.1 284 0x80000001 0x5481 192.168.7.0/31
192.168.7.2 10.1.2.1 284 0x80000001 0x4093 192.168.7.2/31
192.168.7.4 10.1.2.1 284 0x80000001 0x2ca5 192.168.7.4/31
192.168.7.6 10.1.2.1 284 0x80000001 0x18b7 192.168.7.6/31
192.168.7.8 10.1.2.1 284 0x80000001 0x04c9 192.168.7.8/31
192.168.7.10 10.1.2.1 284 0x80000001 0xefdb 192.168.7.10/31
192.168.7.12 10.1.2.1 284 0x80000001 0xdbed 192.168.7.12/31
72
 
O
SP
F 
Av
an
ça
do
Vamos utilizar como exemplo a topologia da figura 3.1: imagine que o enlace entre ABR 
e o roteador R4 teve seu estado alterado para DOWN (por problemas na operadora, por 
exemplo). ABR, vendo que o enlace com R4 mudou de estado, vai recalcular seu LSDB. 
Devido ao cálculo, o ABR vai remover a rede 192.168.0.0/24 que era alcançada via o enlace 
192.168.7.0/31. Após o cálculo, ABR vai gerar dois LSAs do tipo Summary e enviar para R2 e 
R3: um sobre o enlace 192.168.0.0/24 e outro sobre o enlace 192.168.7.0/24, ambos com o 
campo “Age” do LSA preenchido com MaxAge (3600). Ao receber os LSAs, R2 e R3 recalculam 
seus respectivos LSDBs e removem ambas as rotas.
Observe que não há alternativa para chegar ao prefixo 192.168.0.0/24.
Assim que o enlace com R4 ficar operante novamente, ABR vai anunciar os prefixos antes 
removidos para R2 e R3 via LSA Summary e as rotas serão recriadas, apontando para ABR. 
Suponha agora que a operadora ainda está recuperando o circuito entre o ABR e o R4, e esse 
enlace ainda oscile algumas vezes. A cada oscilação, o processo vai ser re-executado por ABR, 
R2 e R3, consumindo recursos de R2 e R3 que nem conhecem a topologia interna da Área 1.
Nesse caso específico, como a rede 192.168.0.0/24 só é alcançada via ABR, não faz sentido os 
roteadores R2 e R3 ficarem recalculando as rotas a cada oscilação, uma vez que ou o prefixo 
vai estar fora (já que não há redundância de acesso) ou vai estar ativo via ABR. Então, para 
evitar que R2 e R3 sejam afetados pela instabilidade do circuito, o que o Engenheiro de Rede 
pode fazer é: como nessa rede o acesso é via ABR, o roteador ABR não precisa ficar enviando 
LSAs do tipo Summary a cada oscilação. Ou seja, o Engenheiro de Redes pode configurar o 
ABR para enviar o LSA Summary apenas para informar que a rede está acessível (no início 
do funcionamento da rede OSPF e a cada refresh). No Quagga, essa configuração é feita pelo 
comando a seguir:
router ospf
 area NÚMERO_ÁREA range IP_A_SER_SUMARIZADO [cost métrica]
  qPara evitar consumo de recursos de R2 e R3 a cada oscilação na Área 1, o comando range 
pode ser utilizado:
area NÚMERO_ÁREA range IP_A_SER_SUMARIZADO [cost métrica]
IP_A_SER_SUMARIZADO deve incluir mais do que apenas um prefixo IP ou LSA Router
Para que inclua mais do que apenas um prefixo IP, prefixos IP utilizados na área devem 
fazer parte de um prefixo IP maior, ou seja, devem ser agregáveis.
Para que esse comando seja aplicado de maneira satisfatória, o prefixo IP em IP_A_SER_
SUMARIZADO deve incluir mais de um LSA Router, ou seja, deve contemplar mais do que 
apenas um prefixo IP. Por exemplo, observe a configuração a seguir. Nela, cada LSA Router 
da Área 1 estaria associado a um comando range, porém essa configuração não seria útil 
para manter as rotas em R2 e R3, ou seja, não evitaria que R2 e R3 recalculassem seus 
LSDBs a cada oscilação na Área 1.
! Configuração INCORRETA
router ospf
 area 0.0.0.1 range 192.168.0.0/24
 area 0.0.0.1 range 192.168.1.0/24
 area 0.0.0.1 range 192.168.2.0/24
 area 0.0.0.1 range 192.168.3.0/24
73
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
 area 0.0.0.1 range 192.168.4.0/24
 area 0.0.0.1 range 192.168.5.0/24
 area 0.0.0.1 range 192.168.6.0/24
 area 0.0.0.1 range 192.168.7.0/31
 area 0.0.0.1 range 192.168.7.4/31
 area 0.0.0.1 range 192.168.7.6/31
 area 0.0.0.1 range 192.168.7.8/31
 area 0.0.0.1 range 192.168.7.10/31
 area 0.0.0.1 range 192.168.7.12/31
Para usar o comando range de maneira satisfatória, é necessário mais de um prefixo IP con-
templado pelo comando range. Como na topologia da figura 3.1 os prefixos IP fazem parte de 
um prefixo IP maior, a seguinte configuração deveria ser inserida no roteador ABR:
! Configuração CORRETA
router ospf
 area 0.0.0.1 range 192.168.0.0/20
Uma vez que as rotas são criadas em R2 e R3 a partir do LSA Summary, ambos vão sempre 
enviar os pacotes para ABR, mesmo que o circuito oscile. Ao aplicar esse comando para 
o prefixo 192.168.0.0/20, observe o que acontece com o LSDB de R2 (LSAs Router e 
Network removidos):
R2# show ip ospf database
 OSPF Router with ID (10.1.2.2)
 Summary Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Route
192.168.0.0 10.1.2.1 3600 0x80000001 0x0cc5 192.168.0.0/24
192.168.1.0 10.1.2.1 3600 0x80000001 0x01cf 192.168.1.0/24
192.168.2.0 10.1.2.1 3600 0x80000001 0xf5d9 192.168.2.0/24
192.168.3.0 10.1.2.1 3600 0x80000001 0xeae3 192.168.3.0/24
192.168.4.0 10.1.2.1 3600 0x80000001 0xdfed 192.168.4.0/24
192.168.5.0 10.1.2.1 3600 0x80000001 0xd4f7 192.168.5.0/24
192.168.6.0 10.1.2.1 3600 0x80000001 0xc902 192.168.6.0/24
192.168.7.0 10.1.2.1 3600 0x80000001 0x5481 192.168.7.0/31
192.168.7.2 10.1.2.1 3600 0x80000001 0x4093 192.168.7.2/31
192.168.7.4 10.1.2.1 3600 0x80000001 0x2ca5 192.168.7.4/31
192.168.7.6 10.1.2.1 3600 0x80000001 0x18b7 192.168.7.6/31
192.168.7.810.1.2.1 3600 0x80000001 0x04c9 192.168.7.8/31
192.168.7.10 10.1.2.1 3600 0x80000001 0xefdb 192.168.7.10/31
192.168.7.12 10.1.2.1 3600 0x80000001 0xdbed 192.168.7.12/31
192.168.15.255 10.1.2.1 4 0x80000001 0x1bb6 192.168.0.0/20
74
 
O
SP
F 
Av
an
ça
do
q 1 Após a inserção do comando range, LSAs do tipo Summary são enviados com campo 
Age preenchido com MaxAge;  
 1 Roteadores OSPF removem os LSAs do tipo Summary; 
 1 Apenas um LSA Summary é mantido: aquele informado no comando range; 
 1 Por exemplo, usando a figura 36, em vez de 14 prefixos na tabela de rotas e no LSDB, 
apenas um existirá: 
R2# show ip ospf database
Summary Link States (Area 0.0.0.0)
192.168.15.255 10.1.2.1 4 0x80000001 0x1bb6 192.168.0.0/20
Ao inserir esse comando, o ABR enviou um novo LSA Summary para cada LSA Router exis-
tente na Área 1; porém, agora com o campo “Age” configurado como MaxAge. Conforme 
apresentado na sessão 1, enviar um LSA com o campo “Age” configurado com MaxAge força 
os demais roteadores OSPF a removerem tal registro do LSDB. Observe o LSDB do roteador 
R2 alguns segundos após a saída anterior, já sem os registros LSA mais específicos:
R2# show ip ospf database
 OSPF Router with ID (10.1.2.2)
 Summary Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Route
192.168.15.255 10.1.2.1 84 0x80000001 0x1bb6 192.168.0.0/20
Observe que há apenas uma rota em R2 para a rede 192.168.0.0/20:
R2# show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
 > 
O>* 192.168.0.0/20 [110/30] via 10.1.2.1, eth0, 00:01:06
Com essa configuração, apenas um LSA Summary foi gerado por ABR e enviado para R2 e 
R3. O LSDB da Área Backbone ficaria mais otimizado com apenas um LSA Summary em vez 
de 14. A figura 3.2 ilustra essa modificação.
75
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Área Backbone
192.168.1.0/24
R5
192.168.0.0/24
R4
192.168.2.0/24
R6
192.168.3.0/24
R7
192.168.6.0/24
R10
192.168.7.4/31
192.168.7.2/31
19
2.1
68
.7.
12
/3
119
2.16
8.7.
6/31
192.168.7.0/31
ABR
R2
R3
(. . .)
LSA Summary – 192.168.0.0/20
Área 1
É importante salientar que a sumarização só acontece com duas condições:
 1 Pelo menos um LSA Network para a rede a ser sumarizada tem de estar no LSDB. 
Ou seja, se todos os enlaces entre ABR e os roteadores OSPF internos estiverem fora, o 
LSA Summary não será gerado; 
 1 A sumarização só acontece para LSA Router, não para LSA AS-External. 
qImportante salientar:
 1 Pelo menos um LSA Network para a rede a ser sumarizada tem de estar no LSDB. 
Ou seja, se todos os enlaces entre ABR e os roteadores OSPF internos estiverem fora, 
o LSA Summary não será gerado; 
 1 A sumarização só acontece para LSA Router, não para LSA AS-External. 
Figura 3.2 
Rede OSPF com 
Sumarização.
76
 
O
SP
F 
Av
an
ça
do
Normalmente, três questões são levantadas por quem está vendo essa abordagem pela 
primeira vez:
1. Se R2 e R3 enviarem os pacotes para ABR mesmo que a rede esteja indisponível, isso 
não vai sobrecarregar o ABR desnecessariamente?
Quando R2 e R3 enviarem os pacotes para ABR, os enlaces entre eles vão ser utilizados, 
porém essa carga será mínima, já que não haverá comunicação no sentido contrário. 
Mesmo com essa utilização de recursos da rede, os benefícios tendem a superar esse 
custo, uma vez que o consumo de CPU e memória em R2 e R3 será menor, além de que 
com o LSDB sendo menor, a convergência da rede é mais rápida.
2.  Quando os pacotes destinados à rede 192.168.0.0/24 chegarem ao ABR e o enlace 
com R4 estiver fora, não há risco de criar-se um loop de roteamento, caso o ABR 
tenha uma rota padrão apontando para R2 ou R3?
Para evitar que haja loops de roteamento nessas situações, os roteadores OSPF criam 
uma rota estática com baixa prioridade apontando para Null, ou seja, caso a rota OSPF 
para 192.168.0.0/24 seja removida por queda no enlace, a rota estática para o prefixo 
sumarizado 192.168.0.0/20 apontando para Null será utilizada, descartando os pacotes 
para a rede 192.168.0.0/24, e não enviando via rota padrão.
3.  Qual é a métrica que ficará associada ao LSA Summary configurado?
O comando range apresentado anteriormente permite que o engenheiro de redes 
estabeleça a métrica para aquele LSA Summary configurado. Como aquele parâmetro é 
opcional, caso não estabelecido, a métrica a ser utilizada será a menor métrica dos LSAs 
do tipo Router associados ao LSA Summary.
qTrês questões podem ser levantadas por quem está vendo essa abordagem pela 
primeira vez:
 1 Se R2 e R3 enviarem os pacotes para ABR mesmo que a rede esteja indisponível, isso 
não vai sobrecarregar o ABR desnecessariamente? 
 1 Quando os pacotes destinados à rede 192.168.0.0/24 chegarem ao ABR e o enlace 
com R4 estiver fora, não há risco de criar-se um loop de roteamento, caso o ABR 
tenha uma rota padrão apontando para R2 ou R3? 
 1 Qual é a métrica que ficará associada ao LSA Summary configurado? 
Agregação de rotas
q 1 Também é possível otimizar e agregar prefixos oriundos de LSAs do Tipo AS-External. 
 1 O seguinte comando pode ser utilizado: 
router ospf
 summary-address prefixo máscara [tag TAG]
Conforme apresentado na sessão anterior, o comando range apenas é utilizado para criar 
LSAs do tipo Summary a partir de LSAs do tipo Router. Quando o objetivo é agregar LSAs do 
tipo AS-External, utiliza-se o comando a seguir.
router ospf
 summary-address prefixo máscara [tag TAG]
77
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Diferentemente do comando range, o comando summary-address não é associado a 
nenhuma área, uma vez que os LSAs do tipo AS-External também não são associados com 
área alguma. Além disso, o comando summary-address deve ser inserido no roteador ASBR, 
e não no ABR.
Para ilustrar o LSDB, vamos utilizar a topologia da figura 3.3.
Área Backbone
192.168.1.0/24
R5
192.168.0.0/24
R4
192.168.2.0/24
R6
192.168.3.0/24
R7
192.168.6.0/24
R10
192.168.7.4/31
192.168.7.2/31
19
2.1
68
.7.
12
/3
119
2.16
8.7.
6/31
192.168.7.0/31
ASBR
R2
R3
(. . .)
External
Apesar de ser semelhante à topologia da figura 3.1, o roteador ABR foi substituído pelo 
roteador ASBR, e não há adjacências OSPF entre ASBR e os roteadores R4 até R10. ASBR tem 
uma rota estática para cada rede interna e redistribui essas rotas mais as interfaces 
conectadas no processo OSPF. Observe a configuração a seguir do ASBR:
router ospf
 ospf router-id 10.1.2.1
 redistribute connected
 redistribute static
 network 10.1.2.0/24 area 0.0.0.0
 network 10.1.3.0/24 area 0.0.0.0
!
ip route 192.168.0.0/24 192.168.7.1
ip route 192.168.1.0/24 192.168.7.3
Figura 3.3 
Redistribuição e 
Agregação.
78
 
O
SP
F 
Av
an
ça
do
ip route 192.168.2.0/24 192.168.7.5
ip route 192.168.3.0/24 192.168.7.7
ip route 192.168.4.0/24 192.168.7.9
ip route 192.168.5.0/24 192.168.7.11
ip route 192.168.6.0/24 192.168.7.13
 q 1 O roteador ASBR não possui adjacências OSPF com os roteadores R4 a R10; 
 1 Uma rota estática é criada para cada rede interna; 
 1 Rotas Estáticas são redistribuídas no processo OSPF; 
 1 Roteadores R2 e R3 recebem quatorze LSAs do tipo AS-External: 
 2 Todos apontam para o ASBR; 
 2 Não existe alternativa de caminho. 
As configurações dessa topologiapodem ser vistas no arquivo adr9-cap3-agregacao.imn.
Como o ASBR está redistribuindo as rotas estáticas no processo OSPF, LSAs do tipo 
AS-External estão sendo gerados e enviados para R2 e R3. Observe o LSDB do roteador R2:
R2# show ip ospf data
 OSPF Router with ID (10.1.2.2)
 Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Link count
10.1.2.1 10.1.2.1 87 0x80000009 0x923b 2
10.1.2.2 10.1.2.2 86 0x80000007 0xd4f6 2
10.1.3.3 10.1.3.3 92 0x80000006 0xfcc6 2
 Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum
10.1.2.2 10.1.2.2 91 0x80000001 0x67b7
10.1.3.3 10.1.3.3 92 0x80000001 0x60b8
10.2.3.3 10.1.3.3 92 0x80000001 0x5eb8
 AS External Link States
Link ID ADV Router Age Seq# CkSum Route
192.168.0.0 10.1.2.1 5 0x80000001 0x83c3 E2 192.168.0.0/24 [0x0]
192.168.1.0 10.1.2.1 5 0x80000001 0x78cd E2 192.168.1.0/24 [0x0]
192.168.2.0 10.1.2.1 5 0x80000001 0x6dd7 E2 192.168.2.0/24 [0x0]
192.168.3.0 10.1.2.1 5 0x80000001 0x62e1 E2 192.168.3.0/24 [0x0]
192.168.4.0 10.1.2.1 5 0x80000001 0x57eb E2 192.168.4.0/24 [0x0]
192.168.5.0 10.1.2.1 5 0x80000001 0x4cf5 E2 192.168.5.0/24 [0x0]
192.168.6.0 10.1.2.1 5 0x80000001 0x41ff E2 192.168.6.0/24 [0x0]
192.168.7.0 10.1.2.1 92 0x80000003 0x2c13 E2 192.168.7.0/31 [0x0]
192.168.7.2 10.1.2.1 92 0x80000003 0x1825 E2 192.168.7.2/31 [0x0]
192.168.7.4 10.1.2.1 92 0x80000003 0x0437 E2 192.168.7.4/31 [0x0]
192.168.7.6 10.1.2.1 92 0x80000003 0xef49 E2 192.168.7.6/31 [0x0]
192.168.7.8 10.1.2.1 92 0x80000003 0xdb5b E2 192.168.7.8/31 [0x0]
192.168.7.10 10.1.2.1 92 0x80000003 0xc76d E2 192.168.7.10/31 [0x0]
192.168.7.12 10.1.2.1 92 0x80000003 0xb37f E2 192.168.7.12/31 [0x0]
79
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Essa saída mostra a configuração padrão do OSPF sem agregação ou sumarização. Observe 
os LSAs do Tipo AS-External para as redes internas. Cada LSA do tipo AS-External vai gerar 
uma rota a ser instalada no roteador R2:
R2# show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
O>* 192.168.0.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00
O>* 192.168.1.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00
O>* 192.168.2.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00
O>* 192.168.3.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00
O>* 192.168.4.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00
O>* 192.168.5.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00
O>* 192.168.6.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00
O>* 192.168.7.0/31 [110/20] via 10.1.2.1, eth0, 00:34:21
O>* 192.168.7.2/31 [110/20] via 10.1.2.1, eth0, 00:34:21
O>* 192.168.7.4/31 [110/20] via 10.1.2.1, eth0, 00:34:21
O>* 192.168.7.6/31 [110/20] via 10.1.2.1, eth0, 00:34:21
O>* 192.168.7.8/31 [110/20] via 10.1.2.1, eth0, 00:34:21
O>* 192.168.7.10/31 [110/20] via 10.1.2.1, eth0, 00:34:21
O>* 192.168.7.12/31 [110/20] via 10.1.2.1, eth0, 00:34:21
Vamos aplicar o comando summary-address a seguir no ASBR para agregarmos os prefixos. 
O comando a seguir será aplicado:
router ospf
 summary-address 192.168.0.0/20
Ao aplicarmos esse comando, novos LSAs do tipo AS-External serão enviados informando 
aos roteadores remotos para removê-los (campo “Age” com valor MaxAge) e um novo LSA 
AS-External será criado. Observe novamente o LSDB do roteador R2:
R2# show ip ospf database
 OSPF Router with ID (10.1.2.2)
 AS External Link States
Link ID ADV Router Age Seq# CkSum Route
192.168.0.0 10.1.2.1 34 0x80000001 0x381e E2 192.168.0.0/20 [0x0]
R2# show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
O>* 192.168.0.0/20 [110/20] via 10.1.2.1, eth0, 00:03:04
q 1 Após receber os 14 LSAs do tipo AS-External, 14 rotas são criadas  por R2 e R3; 
 1 Com o comando summary-address 192.168.0.0/20, novos LSAs do tipo AS-External 
são gerados com o campo “Age” com valor MaxAge, forçando sua remoção; 
 1 Um LSA AS-External com o valor agregado será enviado e apenas uma rota será 
criada em R2 e R3. 
80
 
O
SP
F 
Av
an
ça
do
Até o presente momento, o comando summary-address, apesar de comum e útil, não foi 
implementado no Quagga, apesar de ser bastante comum em outras plataformas. Porém, 
existe outra abordagem que permite o mesmo resultado, e será explicado na sessão de 
route-maps (ou mapas de rotas). Essa outra abordagem foi utilizada para gerar a saída acima.
Métricas
q 1 Cálculo das Rotas utiliza as métricas ou custos das interfaces. 
 1 Rotas com menores custos são escolhidas. 
 1 Custo padrão de cada interface no Quagga é definida a partir da equação: 
 2 Custo padrão = 100Mbps/(Largura de Banda da Interface). 
 1 Como interfaces com mais capacidade que 100Mbps estão disponíveis, Engenheiro de 
Redes pode: 
 2 Usar o comando de interface ip ospf cost VALOR por interface com o valor desejado. 
 2 Usar o comando do OSPF auto-cost reference-bandwidth VALOR. 
 3 O comando auto-cost muda o custo de todas as interfaces do roteador. 
 1 Comando ip ospf cost VALOR é útil para configurações customizadas ou enlaces 
virtuais com capacidade menor que a capacidade da interface física. 
 1 OSPF suporta Equal Cost Multi-Path (ECMP) ou seja, todas rotas de mesmo custo 
devem ser instaladas. 
No curso Protocolos de Roteamento IP, o aluno aprendeu que o OSPF define as rotas a 
partir de cálculos de menor caminho usando algoritmo de Dijkstra ou Short Path First. Para 
calcular o menor custo para cada destino, já foi visto que é utilizada a informação do campo 
“Métrica do LSA”. Para evitar que o Engenheiro de Rede tenha de definir manualmente o 
custo de cada interface, as implementações de OSPF utilizam a largura de banda disponível 
de cada interface para definir a métrica a ser utilizada. O Quagga e alguns outros fabricantes 
definem essa métrica por interface dividindo o custo de referência, 100Mbps, pela largura 
de banda da interface física. Ou seja, o custo padrão é:
Custo padrão = 100Mbps/(Largura de Banda da Interface)
Como no OSPF, quanto menor for o valor da métrica, maior a preferência, uma interface 
FastEthernet tem o menor custo, ou seja, custo de 1. À época da escrita da RFC do OSPF, 
interfaces FastEthernet eram as mais populares e com maior largura de banda disponível. 
Porém, hoje, onde interfaces GigabitEthernet, 10GigabitEthernet e mesmo 100GigabitEthernet 
estão disponíveis, utilizar esse custo padrão sugerido pelas implementações OSPF se mostra 
sub-otimizado, uma vez que apenas valores inteiros são possíveis, ou seja: interfaces 
FastEthernet, GigabitEthernet e 10GigabitEthernet todas possuiriam custo de 1.
Foram apresentados exemplos nas sessões anteriores, mostrando que é possível manipular 
o custo de cada interface com o comando:
interface ethX
 ip ospf cost VALOR
Para evitar que o Engenheiro de Rede tenha de mudar interface por interface para ajustar a 
métrica com suporte a interfaces com maior capacidade, o Quagga provê o comando a seguir:
router ospf
 auto-cost reference-bandwidth <1-4294967>
81
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Por exemplo, caso deseje trabalhar com interfaces 10GigabitEthernet, aplique o seguintecomando:
router ospf
 auto-cost reference-bandwidth 10000
Com esse comando aplicado, as interfaces 10GigabitEthernet terão métrica de 1, as interfaces 
2,5GigabitEthernet terão métrica 4, e as interfaces 1GigabitEthernet terão métrica 10. Para 
que a topologia seja coerente, o comando deve ser aplicado em todos os roteadores OSPF.
O comando de interface ip ospf cost VALOR é útil para configurações customizadas ou casos 
de enlaces virtuais, por exemplo:
 1 Circuitos Frame-Relay que usam subinterfaces: nesse caso, como muitos circuitos 
podem ser configurados em uma mesma interface, cada um com largura de banda dife-
rente, o comando ip ospf cost é utilizado para refletir manualmente o custo desejado em 
cada subinterface; 
 1 Circuitos Metro-Ethernet ou VLANs configuradas uma interface Ethernet: assim 
como no Frame-Relay, cada circuito pode ter largura de banda diferente dos demais, e 
inferior à capacidade da interface física. 
Equal Cost Multi-Path
A especificação do OSPF permite que, caso existam múltiplos caminhos do mesmo tipo 
(tipos de rota OSPF serão explicadas na próxima sessão) e com o mesmo custo, o roteador 
OSPF deve instalar todas as rotas de custo igual. A limitação da quantidade é definida pelo 
fabricante ou pela implementação, e depende de recursos do Sistema Operacional. 
No final do tópico a seguir, “Escolha de Caminhos pelo OSPF”, um exemplo prático será 
apresentado sobre ECMP.
Escolha de caminhos pelo OSPF
q 1 Com o particionamento, várias Áreas OSPF são possíveis. 
 1 Protocolo OSPF faz diferenciação de rotas a partir das origens: 
 2 Rotas Intra-Área: geradas na própria área. 
 2 Rotas Inter-Área: gerada em outra área OSPF. 
 2 Rotas Externas: rotas redistribuídas pelo ASBR. Podem ser Externas ou NSSA, 
Tipo 1 ou 2. 
Foi apresentado até agora que o OSPF permite fazer o particionamento da rede em 
diversas redes menores, chamadas de áreas, e que diversos tipos de área são possíveis: 
Área Backbone, Área Normal, Área Stub e Área Not-So-Stub – ou NSSA. Para diferenciar os 
tipos de rotas, o OSPF cria os seguintes tipos de rotas:
 1 Rotas Intra-Área: são aquelas geradas dentro da área da qual o roteador OSPF faz parte; 
 1 Rotas Inter-Área: aquelas geradas dentro de outra área OSPF e foi recebida do roteador ABR; 
 1 Rotas Externas: são redistribuídas no processo OSPF por algum roteador ASBR. Áreas 
Externas podem ser do Tipo 1 ou do Tipo 2, Externas ou NSSA. 
Lembre-se: rotas Externas do Tipo 1 possuem a métrica da rota externa mais a 
métrica interna do OSPF. Rotas Externas do Tipo 2 só possuem a métrica da rota 
externa, e essa é preservada ao longo da rede. 
82
 
O
SP
F 
Av
an
ça
do
Os tipos de rota são levados em consideração pelo processo OSPF para decidir por qual 
instalar. Observe a figura 3.4 (arquivo adr9-cap3-escolha_de_caminhos.imn).
Área Backbone
R3
R2R1
3.3.3.3/24
2
1
Área 1
100
Na topologia da figura 3.4, cada roteador possui uma interface loopback que faz parte do 
processo OSPF. Nos roteadores R1 e R2, a interface loopback faz parte da Área Backbone, e no 
roteador R3 faz parte da Área 1. Cada enlace possui um custo OSPF: R1-R2 tem custo 1; R1-R3 
tem custo 100 e R2-R3 tem custo 2. Lembre-se de que quanto menor o custo, melhor é a rota.
Observe a configuração e as rotas OSPF instaladas no roteador R1. O endereçamento segue 
o mesmo padrão anteriormente definido.
router ospf
 ospf router-id 1.1.1.1
 network 1.1.1.1/24 area 0.0.0.0
 network 10.1.2.0/24 area 0.0.0.0
 network 10.1.3.0/24 area 0.0.0.1
R1# show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
O 1.1.1.0/24 [110/10] is directly connected, lo, 00:02:10
O>* 2.2.2.0/24 [110/11] via 10.1.2.2, eth1, 00:01:20
O>* 3.3.3.0/24 [110/110] via 10.1.3.3, eth0, 00:01:20
O 10.1.2.0/24 [110/1] is directly connected, eth1, 00:02:10
O 10.1.3.0/24 [110/100] is directly connected, eth0, 00:02:10
O>* 10.2.3.0/24 [110/102] via 10.1.3.3, eth0, 00:01:20
Observe na saída que, para alcançar o endereço da loopback de R3 (cujo endereço IP é 
3.3.3.3/24), o custo é 110. Ao observar mais uma vez a figura 3.4, é possível encontrar um 
caminho com custo menor, via R2, ou seja, R1-R2 e R2-R3, que seria 13. Então, por que R1 
escolheu ir via R1-R3?  
 
Mesmo interfaces virtuais, como as Loopbacks, possuem um custo associado. 
Observe na saída de R1, por exemplo, que a loopback de R1 (1.1.1.0/24) tem custo 10. 
Por padrão, o Quagga coloca custo 10 em interfaces virtuais. 
Figura 3.4 
Escolha de 
Caminhos.
83
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Observe o LSDB de R1 a seguir.
R1# show ip ospf database
 OSPF Router with ID (1.1.1.1)
 Router Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Link count
1.1.1.1 1.1.1.1 905 0x80000006 0x6aa0 2
2.2.2.2 2.2.2.2 906 0x80000005 0x7c82 2
 Net Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum
10.1.2.2 2.2.2.2 906 0x80000001 0x1324
 Summary Link States (Area 0.0.0.0)
Link ID ADV Router Age Seq# CkSum Route
3.3.3.0 1.1.1.1 894 0x80000001 0x31b0 3.3.3.0/24
3.3.3.0 2.2.2.2 895 0x80000001 0x3110 3.3.3.0/24
10.1.3.0 1.1.1.1 944 0x80000001 0x895d 10.1.3.0/24
10.1.3.0 2.2.2.2 895 0x80000001 0x756c 10.1.3.0/24
10.2.3.0 1.1.1.1 894 0x80000001 0x9152 10.2.3.0/24
10.2.3.0 2.2.2.2 945 0x80000001 0x7dc7 10.2.3.0/24
 Router Link States (Area 0.0.0.1)
Link ID ADV Router Age Seq# CkSum Link count
1.1.1.1 1.1.1.1 905 0x80000005 0xb012 1
2.2.2.2 2.2.2.2 906 0x80000005 0x8991 1
3.3.3.3 3.3.3.3 905 0x80000007 0x3126 3
 Net Link States (Area 0.0.0.1)
Link ID ADV Router Age Seq# CkSum
10.1.3.3 3.3.3.3 906 0x80000001 0x121b
10.2.3.3 3.3.3.3 906 0x80000001 0x28ff
 Summary Link States (Area 0.0.0.1)
Link ID ADV Router Age Seq# CkSum Route
1.1.1.0 1.1.1.1 944 0x80000001 0x8dbe 1.1.1.0/24
1.1.1.0 2.2.2.2 896 0x80000001 0x83c2 1.1.1.0/24
2.2.2.0 1.1.1.1 894 0x80000001 0x73d4 2.2.2.0/24
2.2.2.0 2.2.2.2 946 0x80000001 0x4bf9 2.2.2.0/24
10.1.2.0 1.1.1.1 944 0x80000001 0xb298 10.1.2.0/24
10.1.2.0 2.2.2.2 946 0x80000001 0x9ea7 10.1.2.0/24
Observe que realçados em vermelho existem dois LSAs do Tipo Summary com a rota para 
3.3.3.0/24: um que é gerado pelo roteador R1 (ADV Router 1.1.1.1) e enviado para a Área 
Backbone, e um que é gerado pelo roteador R2 (ADV Router 2.2.2.2) e também enviado para 
a Área Backbone. Mas, para gerar um LSA Summary, conforme apresentado anteriormente, 
é necessário que um LSA Router tenha sido recebido pelo roteador ABR com o mesmo 
prefixo. Observe a seguir a confirmação:
84
 
O
SP
F 
Av
an
ça
do
R1# show ip ospf database route adv-router 3.3.3.3
 OSPF Router with ID (1.1.1.1)
 Router Link States (Area 0.0.0.1)
 LS age: 1023
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x0
 LS Type: router-LSA
 Link State ID: 3.3.3.3
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000007
 Checksum: 0x3126
 Length: 60
 Number of Links: 3
 Link connected to:a Transit Network
 (Link ID) Designated Router address: 10.1.3.3
 (Link Data) Router Interface address: 10.1.3.3
 Number of TOS metrics: 0
 TOS 0 Metric: 100
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.2.3.3
 (Link Data) Router Interface address: 10.2.3.3
 Number of TOS metrics: 0
 TOS 0 Metric: 2
 Link connected to: Stub Network
 (Link ID) Net: 3.3.3.0
 (Link Data) Network Mask: 255.255.255.0
 Number of TOS metrics: 0
 TOS 0 Metric: 10
Este comando exibe o LSDB da Área 1 (Area 0.0.0.1) com o LSA Router gerado pelo roteador 
R3 (Advertising Router 3.3.3.3). Observe que existe um enlace do tipo Stub Network, com o 
prefixo 3.3.3.0/24, além de custo 10.
Apesar de o Quagga não deixar explícito o motivo de ter escolhido a rota com custo maior 
(110 contra 13), a razão está na RFC 2328 do OSPF: no processo de escolha de qual rota deve 
ser instalada, rotas Intra-Área sempre terão preferência sob as rotas Inter-Áreas. No caso da 
figura 3.4, mesmo que o enlace R1-R3 fosse apenas um enlace de backup, com baixa capaci-
dade, ainda assim ele seria preterido quando comparado com o LSA Summary recebido de R2.
Ou seja, o processo de escolha de rota do OSPF sempre terá a seguinte lista de prioridades:
1. Intra-Área. 
2. Inter-Área. 
3. Externa do Tipo 1: AS-External-NSSA. 
4. Externa do Tipo 1: AS-External. 
5. Externa do Tipo 2: AS-External-NSSA. 
6. Externa do Tipo 2: AS-External. 
85
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
q 1 Prioridades para o processo de escolha de rota
 2 Intra-Área
 2 Inter-Área
 2 Externa do Tipo 1 - AS-External-NSSA
 2 Externa do Tipo 1 - AS-External 
 2 Externa do Tipo 2 - AS-External-NSSA
 2 Externa do Tipo 2 - AS-External
É fácil entender que quanto mais informações se tem de uma rota, maior a chance de ela ser 
escolhida pelo processo OSPF.
Caso exista mais de um caminho com a mesma prioridade; por exemplo, duas rotas Intra-Área 
recebidas, a escolha se dará pelo custo total. Em caso de custo total ser semelhante, ambas as 
rotas devem ser instaladas, usando a abordagem de Equal Cost Multi-Path (ECMP) apresentada 
anteriormente. Observe a figura 3.5, disponível no arquivo adr9-cap-escolha-de-caminhos2.imn.
Área Backbone
R3
R2R1
3.3.3.3/24
2
2
4
Como todos os enlaces fazem parte da mesma área, para R1 chegar à Loopback de R3, 
existem duas opções com a mesma métrica. A saída a seguir do roteador R1 confirma o 
ECMP instalado, onde é possível ver a mesma rota com dois roteadores como próximo salto.
R1# show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
O 1.1.1.0/24 [110/10] is directly connected, lo, 00:02:28
O>* 2.2.2.0/24 [110/12] via 10.1.2.2, eth1, 00:01:42
O>* 3.3.3.0/24 [110/14] via 10.1.3.3, eth0, 00:01:32
 * via 10.1.2.2, eth1, 00:01:32
O 10.1.2.0/24 [110/2] is directly connected, eth1, 00:02:28
O 10.1.3.0/24 [110/4] is directly connected, eth0, 00:02:28
O>* 10.2.3.0/24 [110/4] via 10.1.2.2, eth1, 00:01:42
A funcionalidade ECMP é muito útil para fazer balanceamento de carga e otimização do rote-
amento. Observe que o protocolo OSPF só suporta múltiplas rotas para o mesmo destino 
caso as métricas sejam idênticas.
Figura 3.5 
ECMP.
86
 
O
SP
F 
Av
an
ça
do
Controlando atualizações de roteamento
q 1 Sistemas Autônomos tendem a possuir diversas configurações e complexidades, 
envolvendo diversos tipos de enlaces e protocolos, múltiplos IGPs que requerem 
configurações extras para garantir a otimização. 
 1 Funcionalidades extras, como Interfaces Passivas, Rotas Padrão e Filtragem tendem 
a ser fundamentais em grandes Sistemas Autônomos, especialmente em caso de 
múltiplos IGP. 
Conforme a configuração da rede fica mais complexa, com mais roteadores, outros IGPs, 
diferentes tipos de enlaces e protocolos, mais ajustes finos são necessários para garantir 
que os protocolos de roteamento funcionem da maneira mais otimizada possível. Esses 
ajustes também se aplicam ao protocolo OSPF, e nesta sessão alguns ajustes serão apre-
sentados em detalhes. No início desta sessão, técnicas de sumarização e agregação foram 
apresentas. Nesta sessão, as seguintes técnicas serão apresentadas:
 1 Passive Interfaces (Interfaces Passivas); 
 1 Rotas Padrão; 
 1 Filtrando Prefixos. 
 2 Distributed Lists (Listas de Distribuição); 
 2 Route-Maps (Mapas de Rotas). 
Essas técnicas também serão utilizadas na próxima sessão, quando a interação com outros 
protocolos de roteamento será detalhada.
Interfaces Passivas (Passive Interfaces)
q 1 Interfaces Passivas ou Passive Interfaces podem ser utilizadas para dar mais flexibili-
dade nas configurações OSPF. 
 1 Com Interfaces Passivas, as rotas geradas são tratadas como Intra-Área. 
 1 Com o comando redistribute, as rotas geradas são tratadas como rotas Externas. 
 1 Interfaces configuradas como passivas não enviam mensagens Hello nem formam 
adjacências OSPF. 
Até esse momento, foram apresentadas duas maneiras de adicionar o prefixo IP de um 
enlace no processo OSPF: ativando OSPF no enlace ou redistribuindo o endereço IP das 
interfaces conectadas.
Ao ativarmos OSPF no enlace, via comando network do processo OSPF, o prefixo IP da inter-
face é inserido no OSPF como Intra-Área e pode ser sumarizado para outras áreas, sendo 
tratado como Inter-Área. Se for utilizada redistribuição via comando redistribute connected 
do processo OSPF, o prefixo IP é inserido como um prefixo externo, tendo menos prioridade 
no processo de escolha de caminhos, conforme apresentado anteriormente.
Caso o Engenheiro de Rede queira usar o comando network em vez de redistribute, esse 
pode fazê-lo, mas essa abordagem pode trazer desvantagens. Observe a figura 3.6 
(arquivo adr9-cap3-interfaces_passivas.imn).
87
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
10.0.0.0/24Internet
R4 R1
Área 1
R3
Área 2
R2
Área Backbone
eth0
eth1
Na topologia da figura 3.6, o roteador OSPF R1 está conectado à Área Backbone, e uma das 
suas interfaces conecta usuários da empresa. Essa interface com usuários não possui 
roteadores, somente dispositivos dos usuários, como computadores, tablets, smartphones, 
impressoras, dispositivos Wi-Fi, entre outros. Esse segmento de rede precisa ser anunciado 
por R1 para os demais roteadores OSPF; caso contrário, eles não serão alcançados. Até 
então, a opção mais comum era redistribuir o endereço daquele segmento no processo 
OSPF. Ao ser redistribuído, o prefixo seria tratado como um prefixo externo.
Caso o Engenheiro de Redes decida não redistribuir e habilite a interface no OSPF com o 
comando network, esse segmento de rede passaria a receber mensagens Hello a cada 
10 segundos de R1. Além disso, caso algum dos usuários deseje agir maliciosamente, ele 
pode instalar um roteador OSPF no segmento, que poderia estabelecer adjacência com R1 
e maliciosamente controlar e injetar prefixos que podem comprometer a instabilidade da 
rede. Mesmo que o Engenheiro de redes habilite MD5, o usuário malicioso pode ficar ten-
tando quebrar a senha por tentativa e erro.
É para essas situações que o recurso de Interfaces Passivas, ou Passive Interfaces, existe. 
Ao criar Interfaces Passivas, o roteador OSPF considera a interface como parte do OSPF, mas 
não tenta criar adjacências. Dessa maneira, o Engenheiro de Rede passa a ter mais controle 
e flexibilidade na administraçãoda rede. Para fazer uso de Interfaces Passivas, os passos a 
seguir são utilizados:
router ospf
 ! Habilite a interface da maneira tradicional com comando network
 network IP area Área
 ! Transforme em interface passiva
 passive-interface Nome_Interface
Figura 3.6 
Interfaces Passivas.
88
 
O
SP
F 
Av
an
ça
do
qPara transformar uma interface em passiva, basta utilizar o comando a seguir:
router ospf
 ! Habilite a interface da maneira tradicional com comando network
 network IP area Área
 ! Transforme em interface passiva
 passive-interface Nome_Interface
Por exemplo, considerando o roteador R1 da figura 3.6:
router ospf
 ! Interface eth1 tem IP 11.0.0.1/24
 network 11.0.0.0/24 area 0
 ! Transforma em interface passiva
 passive-interface eth1
A partir desse comando, o prefixo IP da interface eth1 fará parte do LSDB e será visto 
como Intra-Área pelos demais roteadores OSPF da Área Backbone. Porém, pacotes Hello 
não serão enviados. Observe na saída a seguir do roteador R1, em vermelho, a informação 
de interface passiva.
R1# show ip ospf interface eth1
eth1 is up
 ifindex 1424, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
 Internet Address 11.0.0.1/24, Area 0.0.0.0
 MTU mismatch detection:enabled
 Router ID 10.0.0.4, Network Type BROADCAST, Cost: 10
 Transmit Delay is 1 sec, State DR, Priority 1
 Designated Router (ID) 10.0.0.4, Interface Address 11.0.0.1
 No backup designated router on this network
 Multicast group memberships: <None>
 Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
 No Hellos (Passive interface)
 Neighbor Count is 0, Adjacent neighbor count is 0
Atualmente existem roteadores com dezenas ou mesmo centenas de interfaces. 
Caso deseje, o Engenheiro de Rede pode fazer uso dos comandos a seguir, usando R1 da 
figura 3.6 como exemplo.
router ospf
 ! Transforma todas as interfaces em passivas
 passive-interface default
 ! Transforma interface eth0 em ativa
 no passive-interface eth0
 network 0.0.0.0/0 area 0.0.0.0
Com o comando passive-interface default, todas as interfaces do roteador R1 que estão inclu-
ídas pelo comando network passam a fazer parte do processo OSPF; porém, apenas eth0 
poderá formar adjacências com outros roteadores.
89
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
qÉ possível transformar todas as interfaces do roteador em passivas com um único comando.
router ospf
 ! Transforma todas as interfaces em passivas
 passive-interface default
 ! Transforma interface eth0 em ativa
 no passive-interface eth0
 network 0.0.0.0/0 area 0.0.0.0
Rotas padrão
q 1 Rota padrão ou default route é um recurso útil para economia de recursos 
dos roteadores. 
 1 Gerado pelos ABRs em áreas Stub quando o comando no-summary é inserido. 
 1 Útil quando existe apenas um roteador de saída do Sistema Autônomo. 
 1 Pode ser gerada pelo processo OSPF. 
 2 LSA AS-External. 
A rota padrão, ou default route, é um recurso extremamente útíl nas redes de computadores. 
Através dessa rota, todos os destinos podem ser alcançados, economizando recursos dos 
roteadores, mesmo que não seja a solução mais otimizada. Foram apresentadas situações 
na sessão 2, onde roteadores ABR geravam rotas padrão dentro de Áreas Stub e NSSA, 
quando o comando a seguir era inserido:
route ospf
 area AREA stub no-summary
O comando no-summary, no ABR, serve para forçar o roteador ABR a filtrar mais LSAs do 
tipo Summary, além dos LSAs externos já bloqueados por padrão na área Stub. Como os 
roteadores internos não têm informação dos prefixos externos, o roteador ABR então gera 
uma rota padrão e envia via LSA Summary para os roteadores internos. Alguns fabricantes 
chamam esse tipo de área de Totally Stub ou Totally NSSA.
Porém, há casos onde a rota padrão deve ser gerada para as outras áreas, informando alter-
nativas de saída. Observe a figura 3.7 (arquivo adr9-cap3-rota_padrao.imn).
90
 
O
SP
F 
Av
an
ça
do
10.0.0.0/24Internet
R4 R1
Área 1 Stub
R3
R2
Área Backbone
R5R6
No Sistema Autônomo da figura 3.7, o roteador R4 faz parte da Área Backbone e possui 
BGP para acesso à internet. Nenhum outro roteador tem BGP configurado, apenas OSPF. 
Observe a configuração do roteador R4:
! Processo BGP. Anuncia prefixo 10.0.0.0/8 para o Sistema Autônomo remoto
router bgp 4
 bgp router-id 11.0.0.4
 network 10.0.0.0/8
 neighbor 11.0.0.1 remote-as 555
!
router ospf
 ospf router-id 4.4.4.4
 network 4.4.4.4/32 area 0.0.0.0
 network 10.2.4.0/24 area 0.0.0.0
 network 10.3.4.0/24 area 0.0.0.0
 ! Origina LSA AS-External com a Rota padrão
 default-information originate
!
Figura 3.7 
Rota Padrão.
91
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
q 1 Na topologia da figura 3.7, há apenas um roteador BGP e uma saída; 
 1 Roteadores OSPF precisam de informações para enviar pacotes para fora do Sistema 
Autônomo; 
 1 O roteador R4 pode redistribuir prefixos BGP ou originar uma rota padrão para os 
demais roteadores OSPF. 
Através da figura 3.7 e das configurações do roteador R4, é possível confirmar que há apenas 
um roteador BGP. Para que os usuários conectados aos roteadores R1, R2, R5 e R6 tenham 
acesso à internet, o roteador R4 teria duas possibilidades:
 1 Redistribuir os prefixos BGP dentro do processo OSPF; 
 1 Gerar uma rota padrão para os demais roteadores OSPF. 
Não é recomendado redistribuir prefixos BGP dentro do OSPF, pois, na maioria das vezes, a 
quantidade de prefixos BGP é muito grande a ponto de comprometer o processo OSPF.
Atualmente, a tabela BGP global possui mais de 500 mil prefixos, e não é interessante que 
estes sejam redistribuídos no processo OSPF. Então, a solução com rota padrão se mostra 
mais interessante. O roteador pode originar uma rota padrão no processo OSPF com o 
seguinte comando:
router ospf
 default-information originate [always] [metric METRICA] [metric-type 1|2]
qComando a seguir pode ser utilizado para gerar a rota padrão:
router ospf
 default-information originate [always] [metric METRICA] [metric-type 1|2]
LSA AS-External é gerado: 
filtrado no ABR da Área 1.
Com esse comando, o processo OSPF pode gerar um LSA AS-External com a rota padrão, 
desde que esteja na sua tabela de rotas. No caso da topologia da figura 3.7, a rota padrão 
em R4 foi recebida via BGP do Sistema Autônomo remoto. Observe a saída a seguir:
R4# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
B>* 0.0.0.0/0 [20/0] via 11.0.0.1, eth0, 00:11:20
qRota BGP em R4:
R4# show ip route bgp
B>* 0.0.0.0/0 [20/0] via 11.0.0.1, eth0, 00:11:20
Rota OSPF em R1:
R1# show ip route
O>* 0.0.0.0/0 [110/10] via 10.1.3.3, eth0, 00:28:30
 * via 10.1.2.2, eth1, 00:28:30
92
 
O
SP
F 
Av
an
ça
do
qParâmetros opcionais:
 1 always: origina a rota padrão, mesmo que não exista uma no roteador;   
 1 metric-type: define o tipo de métrica para o LSA AS-External: tipo 1 ou 2. O tipo padrão 
é 2; 
 1 metrica: define o custo da rota. O custo padrão é 10. 
De posse da rota padrão recebida do AS remoto, mais o comando default-information 
originate, o roteador R4 gera o LSA AS-External, conforme pode ser visto em R1:
R1# show ip ospf database external
 OSPF Router with ID (1.1.1.1)
 AS External Link States
 LS age: 799
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LSType: AS-external-LSA
 Link State ID: 0.0.0.0 (External Network Number)
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000003
 Checksum: 0xcaeb
 Length: 36
 Network Mask: /0
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 10
 Forward Address: 0.0.0.0
 External Route Tag: 0
Após receber esse LSA, o roteador R1 instala uma rota padrão e, partir desse momento, 
todos os usuários conectados ao roteador R1 passam a ter acesso ao Sistema Autônomo 
remoto, e mesmo à internet.
O comando default-information originate possui alguns parâmetros opcionais:
 1 always: origina a rota padrão, mesmo que não exista uma no roteador;  
 1 metric-type: define o tipo de métrica para o LSA AS-External: tipo 1 ou 2. O tipo padrão é 2; 
 1 metrica: define o custo da rota. O custo padrão é 10. 
Filtrando prefixos
q 1 Filtragem de prefixos são necessárias para customizar a manipulação de prefixos na 
rede OSPF; 
 1 Engenheiro de redes pode decidir por não enviar prefixos entre áreas – ou mesmo 
não instalar rotas de acordo com as necessidades locais; 
 1 Diversas ferramentas estão à disposição no Quagga: 
 2 Lista de Controle de Acesso ou ACL; 
 2 Lista de Prefixos; 
 2 Lista de Distribuição; 
 2 Mapas de Rotas. 
93
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Filtragem de prefixos faz parte de qualquer protocolo de roteamento. Seja por questões de 
segurança, isolamento ou escalabilidade, todos os protocolos de roteamento implementam 
opções que permitem ao engenheiro de rede fazer ajustes finos. No curso Protocolos de 
Roteamento IP, o conceito e exemplos de mapas de rotas foram apresentados com focos em 
BGP. Nesta sessão, diversas abordagens de filtros, intra e inter-domínio serão apresentadas, 
inclusive mapas de rotas. Porém, antes, uma introdução será feita sobre as ferramentas 
disponíveis no Quagga.
Lista de Controle de Acesso (Access Control List: ACL)
q 1 Listas de Controle de Acesso (ou ACL) são utilizadas normalmente para filtragem de 
pacotes de usuários; 
 1 Também servem para marcar prefixos antes da tomada de ação pelo roteador; 
 1 Não permite remoção de apenas uma entrada ou reordenamento; 
 1 Podem ser configuradas de três maneiras diferentes: 
 2 ACL Padrão: numeradas com valores 1-99 e 1300-1999: access-list NÚMERO 
(deny|permit) (A.B.C.D|Any) [Wildcard]
 2 ACL Extendida: números possíveis: 100-199 e 2000-2699: access-list NÚMERO 
(deny|permit) ip A.B.C.D Wildcard (Any|A.B.C.D Wildcard)
 2 ACL baseada em Nomes: access-list NOME (deny|permit) A.B.C.D/M [exact-match]
Listas de Controle de Acesso, ou ACLs, são utilizadas com grande frequência para filtragem 
de pacotes de usuários nas interfaces. No âmbito do OSPF, ACL são utilizadas para especi-
ficar prefixos a serem selecionados. Possibilidades de configuração no Quagga:
 ! ACL Padrão: Números 1-99 e 1300-1999
 access-list NÚMERO (deny|permit) (A.B.C.D|Any) [Wildcard]
 ! ACL Extendida: Números possíveis 100-199 e 2000-2699
 access-list NÚMERO (deny|permit) ip A.B.C.D Wildcard (Any|A.B.C.D Wildcard)
 ! ACL baseada em Nomes
 access-list NOME (deny|permit) A.B.C.D/M [exact-match]
Existem outras combinações possíveis; porém, para o OSPF, essas são as mais utilizadas. 
ACLs não possuem a possibilidade de remover apenas uma entrada; logo, se uma entrada for 
removida, toda a ACL será removida. A mesma limitação se aplica a ordenamento ou sequen-
ciamento: uma vez criada, a única possibilidade para mudar a sequência é recriando a ACL.
Lista de Prefixos (Prefix-List)
q 1 Lista de Prefixos é uma evolução das ACL, possuindo número de sequência e opções 
de range, como le (menor-igual) e ge (maior-igual). 
 1 Permite que apenas uma entrada seja removida. 
 1 Permite reorganização ou resequenciamento. 
 1 Pode ser configurada da seguinte maneira: 
 2 ip prefix-list NOME seq <NÚMERO> (deny|permit) A.B.C.D/M [ge <0-32>] [le <0-32>] 
94
 
O
SP
F 
Av
an
ça
do
Lista de prefixos foi criada para facilitar a seleção de prefixos, uma vez que cada entrada 
possui um número de sequência, além das extensões le (menor-igual) e ge (maior-igual), 
muito úteis para seleções mais específicas.
ip prefix-list NOME seq <NÚMERO> (deny|permit) A.B.C.D/M [ge <0-32>] [le <0-32>]
Existem outras combinações possíveis; porém, no âmbito desse material, esses parâmetros 
são suficientes.
Listas de Distribuição (Distributed Lists)
q 1 Listas de Distribuição permitem que filtragens de entrada e saída sejam aplicadas por 
interface e por protocolo de roteamento. 
 1 Mesmo pacotes gerados pelo roteador podem ser filtrados. 
 1 Utiliza ACL para selecionar os prefixos a serem filtrados ou liberados. 
 1 Podem ser configuradas da seguinte maneira: 
 2 distribute-list (Número ACL | Nome ACL) (in|out) 
Listas de Distribuição é outra possibilidade para implementar controles de prefixos, e foi 
criada para superar algumas limitações existentes nas ACLs. ACLs não filtram pacotes origi-
nados pelo próprio roteador, além de ser aplicadas por interface. Listas de Distribuição não 
possuem essas limitações, sendo utilizados para fazer seleções e restrições nas distribui-
ções de prefixos por interface e por processo de roteamento.
Listas de Distribuição usam ACLs para filtrar os prefixos desejados. Os usos mais comuns são:
distribute-list (Número ACL | Nome ACL) (in|out)
Mapas de Rotas (Route-Maps)
q 1 Mapa de Rotas é um ferramenta extremamente poderosa para não só selecionar 
prefixos, mas também executar edições ou ações. 
 1 Possui diversos tipos de filtragem, através do comando match. 
 1 Possui diversos tipos de edições, através do comando set. 
 1 Possui número de sequência para fácil ordenamento e remoção. 
 1 Pode ser configurado da seguinte maneira: 
 2 Para criar um mapa de rotas com nome NOME e número de sequência: 
 3 route-map NOME (deny|permit) <número sequência 1-65535>
 2 Para buscar por prefixos especificados pela ACL (nome ou número): 
 3 match ip address
 2 Para buscar pelo tag do LSA AS-External ou NSSA: 
 3 match tag
 2 Para configurar o custo com VALOR específico: 
 3 set metric
 2 Para configurar o LSA AS-External ou NSSA com tipo específico: 
 3 set metric-type <tipo 1 | tipo 2| internal | external>
 2 Para colocar uma tag no LSA AS-External ou NSSA: 
 3 set tag
95
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Mapa de Rota foi criado para utilizar ACL e Listas de Prefixos para não apenas filtrar prefixos, 
mas também executar mudanças nos prefixos selecionados. A utilização foi apresentada 
no curso Protocolos de Roteamento IP, porém os comandos mais comuns para se usar com 
OSPF estão relacionados a seguir:
! Cria um mapa de rotas com nome NOME e número de sequência
route-map NOME (deny|permit) <número sequência 1-65535>
! Procura por prefixos específicados pela ACL (nome ou número)
 match ip address 
! Procura pelo tag do LSA AS-External ou NSSA
 match tag <VALOR TAG>
! Configura métrica com VALOR específico
 set metric <VALOR>
! Configura LSA AS-External ou NSSA com tipo específico
 set metric-type <tipo 1 | tipo 2| internal | external>
! Coloca uma tag no LSA AS-External ou NSSA
 set tag <VALOR>
De posse das ferramentas de filtragem, algumas aplicações serão apresentadas para 
facilitar o entendimento de possíveis aplicações. A topologia da figura 3.8 será utilizada para 
exemplificar essas possibilidades (arquivo adr9-cap3-filtragem.imn).
10.0.0.0/24
Área Backbone Internet
R8
R9
R1
R3R7
R6
R5
Área 1
R2
R4
Figura 3.8 
Filtragens de 
Prefixos.
96O
SP
F 
Av
an
ça
do
A topologia da figura 3.8 é composta por duas Áreas OSPF: Área Backbone e Área 1. A Área 1 
foi criada para isolar a topologia do Datacenter, com diversos racks de servidores e um rote-
ador OSPF por rack. Os roteadores OSPF internos da Área 1 possuem várias conexões para 
aumentar a performance. Dentro da Área 1 existem dois prefixos:
 1 11.0.0.0/16: IPs dos servidores que são acessados pela internet; 
 1 11.1.0.0/16: IPs dos servidors internos sem acesso fora da Área 1. 
Como os roteadores OSPF internos (R3, R4, R5, R6 e R7) são responsáveis pelo roteamento 
de ambos os prefixos, por padrão, todos os prefixos estão sendo divulgados pelos ABRs R1 e 
R2 para a Área Backbone. Observe a tabela de rotas do roteador R8:
R8# show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
O 0.0.0.0/0 [110/10] via 10.8.9.9, eth1, 00:06:09
O>* 9.9.9.9/32 [110/20] via 10.8.9.9, eth1, 00:08:12
O>* 10.1.2.0/24 [110/20] via 10.1.8.1, eth0, 00:08:07
O>* 10.1.3.0/24 [110/20] via 10.1.8.1, eth0, 00:08:07
O 10.1.8.0/24 [110/10] is directly connected, eth0, 00:08:56
O>* 10.2.4.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
O>* 10.2.9.0/24 [110/20] via 10.8.9.9, eth1, 00:08:12
O>* 10.3.4.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.3.5.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.3.6.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.3.7.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.4.5.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
O>* 10.4.6.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
O>* 10.4.7.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
O 10.8.9.0/24 [110/10] is directly connected, eth1, 00:08:56
O>* 11.0.21.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.23.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.25.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.27.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.29.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
O>* 11.1.22.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.24.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.26.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.28.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.30.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
 
97
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
qMesmo com a instrução de que os prefixos da rede 11.1.0.0/16 não deveriam ser 
acessados fora da Área 1, roteador R8 possui rotas para tais prefixos.
O>* 11.0.21.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.23.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.25.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.27.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.29.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
O>* 11.1.22.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.24.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.26.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.28.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.30.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
 * via 10.8.9.9, eth1, 00:08:06
Isso acontece porque a configuração padrão do OSPF é distribuir os prefixos entre 
áreas OSPF. 
Observe que, pela multiplicidade de conexões, vários prefixos podem ser acessados por 
mais de um caminho usando ECMP.
Filtragem de prefixos Inter-Áreas OSPF
Pela saída da tabela de rotas de R8, é possível ver que os sub-prefixos do prefixo 11.1.0.0/16 
estão acessíveis, mas, segundo a definição anterior, esses prefixos não deveriam ser vistos 
fora da Área 1. Nesse caso, como o padrão do OSPF é redistribuir os prefixos entre áreas, o 
engenheiro de redes precisa agir para não permitir essa distribuição, mas ainda assim tendo 
esse prefixo sendo roteado na Área 1.
No tópico Sumarização de Rotas, foi apresentado o comando range, que permite a criação 
de agregação entre áreas. Além de agregar e anunciar, o mesmo comando permite que, em 
vez de gerar o LSA do tipo Summary para fazer o anúncio, permite bloquear todos os pre-
fixos do range. Observe o comando a seguir:
router ospf
 area 1 range 11.1.0.0/16 not-advertise
Com esse comando, os roteadores ABR R1 e R2 não vão criar os LSAs do tipo Summary para 
nenhum prefixo incluso no range 11.1.0.0/16. Observe que na tabela de rotas do roteador R8 
não há mais rotas para os prefixos 11.1.0.0/16.
R8# sh ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
O>* 9.9.9.9/32 [110/20] via 10.8.9.9, eth1, 00:03:56
O>* 10.1.2.0/24 [110/20] via 10.1.8.1, eth0, 00:03:45
O>* 10.1.3.0/24 [110/20] via 10.1.8.1, eth0, 00:03:45
O 10.1.8.0/24 [110/10] is directly connected, eth0, 00:04:40
O>* 10.2.4.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45
 * via 10.8.9.9, eth1, 00:03:45
98
 
O
SP
F 
Av
an
ça
do
O>* 10.2.9.0/24 [110/20] via 10.8.9.9, eth1, 00:03:56
O>* 10.3.4.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45
O>* 10.3.5.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45
O>* 10.3.6.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45
O>* 10.3.7.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45
O>* 10.4.5.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45
 * via 10.8.9.9, eth1, 00:03:45
O>* 10.4.6.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45
 * via 10.8.9.9, eth1, 00:03:45
O>* 10.4.7.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45
 * via 10.8.9.9, eth1, 00:03:45
O 10.8.9.0/24 [110/10] is directly connected, eth1, 00:04:40
O>* 11.0.21.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45
O>* 11.0.23.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45
O>* 11.0.25.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45
O>* 11.0.27.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45
O>* 11.0.29.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45
 * via 10.8.9.9, eth1, 00:03:45
qO comando range apresentado anteriormente possui uma opção que faz o inverso: em 
vez de criar um LSA Summary para o prefixo explicitado, passa a não gerar LSAs do tipo 
Summary para os LSA Routers inclusos no prefixo explicitado.
router ospf
 area 1 range 11.1.0.0/16 not-advertise
Com esse comando, roteadores R8 e R9 não terão conhecimento do prefixo 11.1.0.0/16
Outra possibilidade de fazer o mesmo bloqueio é possível com Listas de Prefixos. Vamos 
remover o comando range de ambos R1 e R2.
router ospf
 no area 0.0.0.1 range 11.1.0.0/16 not-advertise
 
qÉ possível fazer o mesmo filtro com Lista de Prefixos.
ip prefix-list Datacenter-11.1 deny 11.1.0.0/16 le 32
ip prefix-list Datacenter-11.1 permit any
router ospf
 area 1 filter-list prefix Datacenter-11.1 out
Lista de Prefixos permite que apenas uma lista tenha diversos prefixos IP distintos, 
evitando ter de aplicar múltiplos comandos range.
Agora, em ambos R1 e R2 vamos criar uma Lista de Prefixos que inclua todos os prefixos do 
range 11.1.0.0/16:
ip prefix-list Datacenter-11.1 deny 11.1.0.0/16 le 32
ip prefix-list Datacenter-11.1 permit any
Essa Lista de Prefixos, chamada Datacenter-11.1, possui duas regras: a primeira rejeita o 
prefixo 11.1.0.0/16, incluindo prefixos menores até /32; a segunda regrapermite todos os 
outros prefixos.
99
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Agora, aplique a Lista de Prefixos no processo OSPF:
router ospf
 area 1 filter-list prefix Datacenter-11.1 out
Ao observar o LSDB de R8, é possível observar o mesmo comportamento do comando range:
R8# show ip ospf database 
 OSPF Router with ID (8.8.8.8)
Link ID ADV Router Age Seq# CkSum Route
11.1.22.0 10.2.4.2 3600 0x80000001 0x7793 11.1.22.0/24
11.1.24.0 10.2.4.2 3600 0x80000001 0x61a7 11.1.24.0/24
11.1.26.0 10.2.4.2 3600 0x80000001 0x4bbb 11.1.26.0/24
11.1.28.0 10.2.4.2 3600 0x80000001 0x35cf 11.1.28.0/24
11.1.30.0 10.2.4.2 3600 0x80000001 0xba52 11.1.30.0/24
qO comando range e a Lista de Prefixos, após serem aplicados, criam LSAs do Tipo 
Summary solicitando a remoção do prefixo. Observe o LSDB de R8:
Link ID ADV Router Age Seq# CkSum Route
11.1.22.0 10.2.4.2 3600 0x80000001 0x7793 11.1.22.0/24
11.1.24.0 10.2.4.2 3600 0x80000001 0x61a7 11.1.24.0/24
11.1.26.0 10.2.4.2 3600 0x80000001 0x4bbb 11.1.26.0/24
11.1.28.0 10.2.4.2 3600 0x80000001 0x35cf 11.1.28.0/24
11.1.30.0 10.2.4.2 3600 0x80000001 0xba52 11.1.30.0/24
Todos os LSAs possuem Age 3600, que significa que devem ser removidos.
Observe que o campo “Age” foi configurado com MaxAge nos LSAs do tipo Summary, 
forçando os demais roteadores OSPF a removerem os prefixos inclusos na Lista de 
Prefixos dos seus LSDBs. Com a configuração atual, a Área Backbone não possui mais 
rotas para a rede 11.1.0.0/16, conforme especificado no início do texto.
Filtragem de prefixos Intra-Área OSPF
Após a aplicação dos comandos range ou/e filter-list em R1 e R2, foi possível confirmar que 
nenhum roteador fora da Área 1 tinha informações que o prefixo 11.1.0.0/16 estava na 
Área 1. Porém, e se forem conectados aos roteadores R1 ou R2 novas redes, com usuários, 
por exemplo?  Apesar de não anunciar para a Área Backbone, como R1 e R2 ainda fazem 
parte da Área 1, estes possuem rotas para o prefixo 11.1.0.0/16:
R1# sh ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
 > - selected route, * - FIB route
O>* 8.8.8.8/32 [110/20] via 10.1.8.8, eth2, 23:33:22
O>* 9.9.9.9/32 [110/30] via 10.1.2.2, eth1, 23:33:22
 * via 10.1.8.8, eth2, 23:33:22
O 10.1.2.0/24 [110/10] is directly connected, eth1, 23:34:13
O 10.1.3.0/24 [110/10] is directly connected, eth0, 23:34:13
O 10.1.8.0/24 [110/10] is directly connected, eth2, 23:34:13
O>* 10.2.4.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 10.2.9.0/24 [110/20] via 10.1.2.2, eth1, 23:33:22
100
 
O
SP
F 
Av
an
ça
do
O>* 10.3.4.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27
O>* 10.3.5.0/24 [110/20] via 10.1.3.3, eth0, 23:33:22
O>* 10.3.6.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27
O>* 10.3.7.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27
O>* 10.4.5.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 10.4.6.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 10.4.7.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 10.8.9.0/24 [110/20] via 10.1.8.8, eth2, 23:33:22
O>* 11.0.21.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27
O>* 11.0.23.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 11.0.25.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 11.0.27.0/24 [110/30] via 10.1.3.3, eth0, 23:33:22
O>* 11.0.29.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 11.1.22.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27
O>* 11.1.24.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 11.1.26.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
O>* 11.1.28.0/24 [110/30] via 10.1.3.3, eth0, 23:33:22
O>* 11.1.30.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27
R1 e R2 nessa topologia não precisam saber desse prefixo, pois em caso de conexão nova 
com R1 ou R2, os servidores da rede 11.1.0.0/16 seriam acessíveis. Para evitar esse tipo de 
situação, bloqueios Intra-Área devem ser utilizados.
Uma maneira de impedir que R1 e R2 tenham rotas para os prefixos da rede 11.1.0.0/16 é 
impedir que o processo OSPF instale rotas para o prefixo 11.1.0.0/16 na tabela de rotas. 
No Quagga, a maneira mais simples de se implementar essa restrição é usando o comando 
ip protocol a seguir, juntamente com Mapas de Rotas.
Primeiramente, verifique a Lista de Prefixos criada anteriormente:
ip prefix-list Datacenter-11.1 seq 5 deny 11.1.0.0/16 le 32
ip prefix-list Datacenter-11.1 seq 10 permit any
Essa Lista de Prefixos rejeita todos os prefixos da rede 11.1.0.0 dos prefixos /16 até prefixos /32.
Segundo, crie um Mapa de Rotas que inclua essa Lista de Prefixos:
route-map Rejeita_Datacenter permit 5
 match ip address prefix-list Datacenter-11.1
Terceiro, aplique o Mapa de Rotas no protocolo OSPF:
ip protocol ospf route-map Rejeita_Datacenter
Observe o que foi feito: o roteador OSPF vai criar adjacências com outros roteadores OSPF, 
no caso, R1 e R2 criarão adjacências com R3 e R4, respectivamente. Ao receberem os 
prefixos, estes serão instalados no LSDB, após todo o processo de sincronização apresen-
tado na sessão 1. Após a sincronização, o roteador vai verificar quais rotas OSPF devem ser 
instaladas na tabela de rotas. Como há um Mapa de Rotas configurado, apenas os prefixos 
permitidos pela Lista de Prefixos serão aceitos. Observe a tabela de rotas do roteador R2:
R2# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
 O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,
101
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
 > - selected route, * - FIB route
O>* 8.8.8.8/32 [110/30] via 10.1.2.1, eth1, 1d00h15m
 * via 10.2.9.9, eth2, 1d00h15m
O>* 9.9.9.9/32 [110/20] via 10.2.9.9, eth2, 1d00h15m
O 10.1.2.0/24 [110/10] is directly connected, eth1, 1d00h16m
C>* 10.1.2.0/24 is directly connected, eth1
O>* 10.1.3.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 10.1.8.0/24 [110/20] via 10.1.2.1, eth1, 1d00h15m
O 10.2.4.0/24 [110/10] is directly connected, eth0, 00:09:12
C>* 10.2.4.0/24 is directly connected, eth0
O 10.2.9.0/24 [110/10] is directly connected, eth2, 1d00h16m
C>* 10.2.9.0/24 is directly connected, eth2
O>* 10.3.4.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03
O>* 10.3.5.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 10.3.6.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 10.3.7.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 10.4.5.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03
O>* 10.4.6.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03
O>* 10.4.7.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03
O>* 10.8.9.0/24 [110/20] via 10.2.9.9, eth2, 1d00h15m
O>* 11.0.21.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 11.0.23.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 11.0.25.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 11.0.27.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 11.0.29.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03
O 11.1.22.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03
O 11.1.24.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03
O 11.1.26.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03
O 11.1.28.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03
O 11.1.30.0/24 [110/20] via 10.2.4.4, eth0 inactive, 00:09:03
Se o comando for aplicado após o prefixo já estar inserido na tabela de rotas, o 
engenheiro de rede necessitará reestabelecer as adjacências OSPF, reiniciando o 
processo OSPF. 
Observe que os prefixos da rede 11.1.0.0/16 estão inativos; logo, não são alcançáveis.Observe no LSDB de R2 o LSA Router gerado por R4, por exemplo:
R2# show ip ospf database router adv-router 10.3.4.4
 OSPF Router with ID (10.2.4.2)
 Router Link States (Area 0.0.0.1)
 LS age: 754
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 Flags: 0x0
 LS Type: router-LSA
 Link State ID: 10.3.4.4
 Advertising Router: 10.3.4.4
 LS Seq Number: 80000018
102
 
O
SP
F 
Av
an
ça
do
 Checksum: 0xe84c
 Length: 108
 Number of Links: 7
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.3.4.4
 (Link Data) Router Interface address: 10.3.4.4
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.4.5.5
 (Link Data) Router Interface address: 10.4.5.4
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.4.6.6
 (Link Data) Router Interface address: 10.4.6.4
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.4.7.7
 (Link Data) Router Interface address: 10.4.7.4
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.2.4.4
 (Link Data) Router Interface address: 10.2.4.4
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: Stub Network
 (Link ID) Net: 11.0.29.0
 (Link Data) Network Mask: 255.255.255.0
 Number of TOS metrics: 0
 TOS 0 Metric: 10
 Link connected to: Stub Network
 (Link ID) Net: 11.1.30.0
 (Link Data) Network Mask: 255.255.255.0
 Number of TOS metrics: 0
 TOS 0 Metric: 10
Observe que no último registro consta a rede 11.1.30.0/24. Lembre-se: o LSDB tem de ser o 
mesmo em todos os roteadores OSPF da Área. Nesse caso, filtramos apenas a instalação da 
rota na tabela de rotas, mas não a inserção do LSA no LSDB.
Em alguns outros fabricantes, o comando OSPF distributed-list está disponível:
router ospf
 distributed-list prefix NOME_LISTA_PREFIXO in
A lógica é a mesma: apenas prefixos listados e permitidos na Lista de Prefixo NOME_LISTA_
PREFIXO serão instalados na tabela de roteamento.
103
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
qExecutando Filtragem de Prefixos Intra-Área:
1. Crie a Lista de Prefixo com o prefixo que não deve ser instalado:
ip prefix-list Datacenter-11.1 seq 5 deny 11.1.0.0/16 le 32
ip prefix-list Datacenter-11.1 seq 10 permit any
2. Crie um Mapa de Rotas que inclua a Lista de Prefixo criada:
route-map Rejeita_Datacenter permit 5
 match ip address prefix-list Datacenter-11.1
3. Aplique o Mapa de Rotas no protocolo OSPF:
ip protocol ospf route-map Rejeita_Datacenter
Agregação de LSAs AS-External
Na sessão “Agregação de Rotas”, foi apresentado o comando OSPF summary-address para 
fazer agregação de LSAs do tipo AS-External. Porém, conforme apresentado, esse comando 
não é suportado pelo Quagga; então, a possibilidade usando Mapas de Rotas vai ser apre-
sentada a seguir.
Observe a figura 3.3, reproduzida novamente a seguir.
Área Backbone
192.168.1.0/24
R5
192.168.0.0/24
R4
192.168.2.0/24
R6
192.168.3.0/24
R7
192.168.6.0/24
R10
192.168.7.4/31
192.168.7.2/31
19
2.1
68
.7.
12
/3
119
2.16
8.7.
6/31
192.168.7.0/31
ASBR
R2
R3
(. . .)
External
104
 
O
SP
F 
Av
an
ça
do
Na topologia da figura 3.1, o ASBR possui interfaces conectadas aos roteadores remotos R4 
até R10 e uma rota estática para cada rede interna, conforme abaixo:
router ospf
 ospf router-id 10.1.2.1
 redistribute connected
 redistribute static
 network 10.1.2.0/24 area 0.0.0.0
 network 10.1.3.0/24 area 0.0.0.0
!
ip route 192.168.0.0/24 192.168.7.1
ip route 192.168.1.0/24 192.168.7.3
ip route 192.168.2.0/24 192.168.7.5
ip route 192.168.3.0/24 192.168.7.7
ip route 192.168.4.0/24 192.168.7.9
ip route 192.168.5.0/24 192.168.7.11
ip route 192.168.6.0/24 192.168.7.13
Observe que as interfaces com R4 até R10 e as rotas estáticas estão sendo redistribuídas 
no OSPF. Para evitar que R2 e R3 criem 14 rotas apontando para o ASBR, podemos utilizar 
Mapas de Rotas para fazer a agregação. Os seguintes passos devem ser executados:
Passo 1: crie a Lista de Prefixos:
ip prefix-list FILTRA_192.168-20 seq 5 deny 192.168.0.0/16 ge 24
ip prefix-list FILTRA_192.168-20 seq 10 permit any
Essa Lista de Prefixos diz para verificar os primeiros 16 bits do prefixo (192.168) e rejeitar 
(deny) todos os prefixos com comprimento do prefixo maior ou igual a 24 (/24, /25, /26 etc.)
Passo 2: crie um Mapa de Rotas com a Lista de Prefixo criada:
route-map AGREGACAO permit 5
 match ip address prefix-list FILTRA_192.168-20
Esse Mapa de Rotas vai permitir tudo que está na Lista de Prefixo FILTRA_192.168-20, ou 
seja, rejeitar prefixos com comprimento do prefixo maior que 24 e permitir o resto (any).
Passo 3: crie uma rota estática para o endereço agregável:
ip route 192.168.0.0/20 null0
Passo 4: aplicar o Mapa de Rotas no processo OSPF, fazendo a redistribuição de rotas estáticas:
router ospf
 redistribute static route-map AGREGACAO
105
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
Passo 5: confirme o resultado nos demais roteadores da Área Backbone:
R2# sh ip ospf database external
 OSPF Router with ID (10.1.2.2)
 AS External Link States
 LS age: 339
 Options: 0x2 : *|-|-|-|-|-|E|*
 LS Flags: 0x6 
 LS Type: AS-external-LSA
 Link State ID: 192.168.0.0 (External Network Number)
 Advertising Router: 10.1.2.1
 LS Seq Number: 80000003
 Checksum: 0x3420
 Length: 36
 Network Mask: /20
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 0.0.0.0
 External Route Tag: 0
Apesar de requerer mais passos que o comando OSPF summary-address, o mesmo o 
bjetivo foi alcançado com rota estática, Lista de Prefixo e Mapa de Rotas.
qUsando Mapas de Rotas para fazer agregação de LSAs do tipo AS-External:
1. Crie a Lista de Prefixos: 
ip prefix-list FILTRA_192.168-20 seq 5 deny 192.168.0.0/16 ge 24
ip prefix-list FILTRA_192.168-20 seq 10 permit any
2. Crie um Mapa de Rotas com a Lista de Prefixos criada: 
route-map AGREGACAO permit 5
 match ip address prefix-list FILTRA_192.168-20
3. Crie uma rota estática para o endereço agregável: 
ip route 192.168.0.0/20 null0
4. Aplique o Mapa de Rotas no processo OSPF, fazendo a redistribuição de rotas estáticas: 
router ospf
 redistribute static route-map AGREGACAO
5. Confirme o resultado nos demais roteadores da Área Backbone:
R2# sh ip ospf database external
Nesta sessão, o aluno teve contato com algumas técnicas de engenharia de tráfego que per-
mitem a otimização do LSDB, aumenta a eficiência do processo de convergência e também 
agrega segurança e isolamento nas implementações OSPF. Na sessão de aprendizagem 4, 
o aluno terá a oportunidade de conhecer algumas técnicas e funcionalidades mais novas 
desenvolvidas pelo IETF para o protocolo OSPF, que agregam mais valor e escalabilidade a 
esse popular protocolo de roteamento dinâmico.
106
 
O
SP
F 
Av
an
ça
do
 Comandos OSPF
A seguir, uma lista de comandos de configuração que foram apresentados na sessão de 
aprendizagem 3. Em destaque estão as palavras-chave.
Os comandosa seguir são aplicados na sessão de OSPF do roteador.
 1 Gera LSAs do tipo Summary na Área Backbone. Not-advertise filtra o LSA do tipo 
Summary:
area NÚMERO_ÁREA range IP_A_SER_SUMARIZADO [cost métrica] [not-advertise]
 1 Gera uma agregação de LSAs do tipo AS-External na rede OSPF:
summary-address PREFIXO MÁSCARA [tag TAG]
 1 Muda o custo de referência das interfaces OSPF:
auto-cost reference-bandwidth <1-4294967>
 1 Coloca uma interface no modo passivo do OSPF:
passive-interface Nome_Interface
 1 Coloca todas as interfaces do roteador no modo passivo do OSPF:
passive-interface default
 1 Origina uma rota padrão em uma área Stub e filtra todos os LSAs do tipo Summary:
area AREA stub no-summary
 1 Origina uma rota padrão na rede OSPF:
default-information originate [always] [metric METRICA] [metric-type 1|2]
 1 Filtra LSAs do tipo Summary entre áreas:
area NUMERO filter-list prefix NOME_LISTA_PREFIXO [in|out]
 1 Filtra prefixos de anúncios recebidos:
distribute-list prefix NOME_LISTA_PREFIXO in
Os comandos a seguir são aplicados na configuração das interfaces.
 1 Altera o custo da interface no processo OSPF:
ip ospf cost VALOR
Os comandos a seguir são aplicados no modo de configuração global do roteador.
 1 Ativa um mapa de rotas no processo OSPF:
ip protocol ospf route-map NOME_DO_MAPA
 1 Cria uma ACL padrão:
access-list NÚMERO (deny|permit) (A.B.C.D|Any) [Wildcard]
107
 
C
ap
ítu
lo
 3
 - 
En
ge
nh
ar
ia
 d
e 
tr
áf
eg
o 
co
m
 O
SP
F
 1 Cria uma ACL Extendida:
access-list NÚMERO (deny|permit) ip A.B.C.D Wildcard (Any|A.B.C.D Wildcard)
access-list NOME (deny|permit) A.B.C.D/M [exact-match]
 1 Cria um Mapa de Rotas:
route-map NOME [permit|deny] NUMERO_SEQUÊNCIA
 1 Cria uma Lista de Prefixos:
Ip prefix-list NOME seq NÚMERO [permit|deny] A.B.C.D/M [ge <0-32>] [le <0-32>]
 1 Procura por prefixos específicados pela ACL (nome ou número) em uma Mapa de Rotas:
match ip address
 1 Procura pelo tag do LSA AS-External ou NSSA no Mapa de Rotas:
match tag <VALOR TAG>
 1 Configura métrica com VALOR específico no Mapa de Rotas:
set metric <VALOR>
 1 Configura LSA AS-External ou NSSA com tipo específico no Mapa de Rotas:
set metric-type <tipo 1 | tipo 2| internal | external>
 1 Coloca uma tag no LSA AS-External ou NSSA no Mapa de Rotas:
set tag <VALOR TAG>
108
 
O
SP
F 
Av
an
ça
do
109
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
 
 
ob
je
tiv
os
conceitos
4
Otimização e tópicos avançados
Conhecer novas tecnologias relacionadas ao OSPF; Apresentar exemplos práticos para 
consolidação dos novos tópicos; Entender a importância dessas tecnologias novas 
para os ambientes que usam OSPF.
 
Escalabilidade e Estabilidade: Incremental OSPF, Supressão de Prefixos, Graceful Restart; 
Convergência: Bidirectional Forwarding Detection (BFD); Monitoramento: MIB 4750.
 
 
 
Introdução
Nas sessões anteriores, as RFCs 2328 e 3101 foram apresentadas e as configurações mais 
comuns disponíveis do protocolo OSPF nos roteadores atuais foram detalhadas. Diversos exem-
plos e topologias foram apresentados, com informação suficiente para o aluno ter a capacidade 
de configurar redes complexas e de grande escala. Porém, ao longo dos anos e com o advento 
de novos protocolos e tecnologias, novas funcionalidades foram propostas e algumas viraram 
padrões de fato via RFCs no IETF (Internet Engineering Task Force). Serviços como o transporte 
de voz e vídeo utilizando redes IP se consolidaram e passaram a exigir tempos de convergência 
menores, o que força uma detecção mais rápida de possíveis problemas de conectividade. Além 
disso, com redes cada vez maiores e mais roteadores OSPFs, os LSDBs ficaram cada vez maiores, 
consumindo mais recursos dos roteadores e comprometendo o tempo de convergência da rede.
Esta sessão apresenta as tecnologias e propostas mais novas relacionadas ao protocolo OSPF 
e, sempre que possível, exemplos práticos serão apresentados para ajudar o aluno a conso-
lidar os novos tópicos. Algumas das funcionalidades a serem apresentadas são tão recentes 
que muitos dos fornecedores ainda não as suportam, mas é importante os alunos saberem 
que existem opções para resolver problemas específicos relacionados a grandes ambientes 
de roteamento OSPF. Além disso, algumas tecnologias apresentadas são importantes para 
ambientes que usam o OSPF, como por exemplo, redes MPLS e Engenharia de Tráfego.
Os principais assuntos a serem abordados nesta sessão estão relacionados às seguintes áreas:
 1 Escalabilidade e Estabilidade: serão discutidos tópicos como Incremental OSPF, 
Supressão de Prefixos e Graceful Restart;  
 1 Convergência: será apresentado o protocolo Bidirectional Forwarding Detection (BFD);  
 1 Monitoramento: a MIB 4750 será detalhada. 
 
 
110
 
O
SP
F 
Av
an
ça
do
Escalabilidade e Estabilidade do OSPF
q 1 Roteadores modernos possuem mais CPU e memória, porém as redes estão ficando 
cada vez maiores. 
 1 Provedores atuais possuem mais roteadores e mais enlaces entre eles, aumentando o 
tamanho do LSDB. 
 1 É importante melhorar a escabilidade do OSPF para garantir uma rede estável. 
 1 Novas funcionalidades foram propostas ou melhoradas para extender a RFC 2328.  
A capacidade de suportar cada vez mais roteadores e prefixos de maneira estável determina 
a escalabilidade de um protocolo de roteamento. O protocolo OSPF foi planejado para 
suportar muitos roteadores e enlaces, porém, com a popularização das redes de computa-
dores e o crescimento destas, os LSBDs acabaram ficando muito grandes. Mesmo com os 
roteadores mais novos possuindo mais capacidade de processamento e memória, algumas 
funcionalidades foram propostas para otimizar e acelerar o processo de convergência, além 
de aumentar a estabilidade da rede. As seguintes funcionalidades foram padronizadas para 
extender as capacidades da RFC 2328 (OSPF v2) e serão detalhadas ao longo da sessão de 
aprendizagem 4:
q 1 Incremental OSPF: permite que o OSPF reprocesse apenas parte do LSDB em casos 
específicos de alteração na topologia da área OSPF; 
 1 Graceful Restart: permite que os pacotes continuem sendo encaminhados ao longo 
da reinicialização do processo OSPF; 
 1 BFD para OSPF: permite que o processo OSPF detecte mais rapidamente a queda dos 
roteadores vizinhos; 
 1 Supressão de Prefixos: permite a remoção dos prefixos das redes de trânsito do 
LSDB, diminuindo assim o seu tamanho; 
 1 MIB para OSPF: permite o monitoramento dos objetos OSPF, facilitando a operação 
da rede OSPF. 
Incremental OSPF
q 1 Roteadores OSPF usam o algoritmo SPF para escolher o melhor caminho para cada 
destino. 
 1 Após a escolha de todos os caminhos, a Shortest Path Tree (SPT) é calculada. 
 1 Uma vez calculada a SPT, só há o reprocessamento quando há alterações topológicas. 
 1 O SPF reprocessa TODO o LSDB em caso de alterações topológicas na Área OSPF, 
consumindo CPU e memória do roteador. 
 1 A figura 4.1 será utilizada para ilustrar a criação da SPT. 
No curso "Protocolos de Roteamento IP", o funcionamento do Algoritmo de Djisktra foi 
apresentado, mostrando como o protocolo OSPF faz a escolha dos caminhos. Inicialmente, 
após a sincronização do LSDB (apresentada na sessão 1), cada roteador precisa definir sua 
Shortest Path Tree (SPT) com todos os destinos, avaliando os custos e caminhos disponibili-
zados pelos demais roteadores OSPF. Através da SPT, o roteador OSPF saberá como chegar 
em cada uma das redes disponíveis. A fim de ilustrar esse procedimento, observe a topo-
logia da figura 4.1.
111
 
C
ap
ítu
lo
 4
 - 
O
timiz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Rede 10
Rede 7
Rede 3
Rede 1
R1
R3
Rede 6
R2 R5
R10
R6
R7
Rede 2
Rede 8 Rede 4
R8 R9
Rede 11
R11
5
10
10
10
10
10
10
10
10
10
15
15
5
5
R4
É possível observar que essa rede possui diversos enlaces e roteadores. Assumindo os 
custos informados nos enlaces, o roteador R6 iria executar o processo SPF (Shortest Path 
First) no seu LSDB para criar sua SPT (Shortest Path Tree) para alcançar todos os destinos. 
A figura 4.2. apresenta a SPT do ponto de vista de R6.
q 1 A topologia da figura 4.1. apresenta 11 roteadores, com diversos enlaces e custos; 
 1 Cada roteador cria sua própria SPT para chegar a todos os destinos; 
 1 A figura 4.2 mostra a SPT do ponto de vista de R6, utilizando as métricas (ou custos) 
informadas; Observe que não há loops na SPT. 
Figura 4.1 
Incremental OSPF.
112
 
O
SP
F 
Av
an
ça
do
Rede 8
R8
Rede 9
R9
Rede 10
R10
Rede 11
R11
Rede 1
R1
Rede 2
R2
R4
R6
R5 R7R3
Como era de se esperar, o roteador R6 calculou sua SPT sem loops, utilizando as métricas dos 
enlaces anunciados pelos demais roteadores. Suponha que as rotas sejam instaladas no rote-
ador R6, e o enlace que liga o roteador R8 à Rede 8 mude de estado, de UP para DOWN. O rote-
ador R8 vai então gerar um LSA Network para informar que a Rede 8 está indisponível (com LSA 
Age 3600 ou Métrica Infinita). Os demais roteadores OSPF vão repassar o LSA (via flooding) até 
que todos os roteadores OSPF estejam com o mesmo LSDB. Após terem o LSDB sincronizado, 
todos os roteadores vão executar o processo do SPF para recalcularem suas respectivas SPTs.
Como o SPF processa todos os registros do LSDB, a árvore SPT teve de ser inteiramente 
recriada por causa de um prefixo IP que é uma folha da árvore SPT. Esse cálculo consome 
recursos de processamento e memória do roteador, e se depender da quantidade de prefixos 
e frequência com que esses prefixos oscilam, a CPU do roteador pode ficar bastante ocupada. 
Vimos na sessão 2 que esse problema poderia ser evitado com áreas OSPF, mas considere que 
a figura 4.2 já é uma Área OSPF de uma rede maior, pois muitas redes podem ter dezenas ou 
centenas de roteadores, milhares de prefixos sendo roteados pelo OSPF por área.
q 1 Supondo um problema entre R8 e Rede 8, R8 vai gerar um LSA Router informando a 
mudança de estado; 
 1 Todos os roteadores OSPF reprocessam o LSDB para criar novas SPTs;  
 1 Ao longo da recriação da SPT, recursos de CPU e memória serão utilizados;  
 1 Como a Rede 8 só tem ligação com R8, as SPTs vão permanecer as mesmas. 
Figura 4.2 
Roteader R6 e 
sua SPT.
113
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Diante desse cenário, alguns fabricantes implementaram uma versão otimizada do algoritmo 
SPF sugerida na época da ARPANET.  À época, foi sugerida uma modificação no algoritmo do 
SFP, chamado Incremental SFP (ISPF), propondo mudanças que afetem apenas as folhas ou 
pequenas sub-árvores da SPT, e não forçam o cálculo completo da SPT. Assim, economizam 
recursos computacionais dos roteadores.  
q 1 Para evitar esse tipo de situação, uma mudança foi implementada no SPF: 
o Incremental SPF (ISPF); 
 1 O ISPF propõe que mudanças que afetem apenas as folhas ou pequenas sub-árvores 
da SPT e não forcem o cálculo completo da SPT; 
 1 Recursos computacionais seriam economizados e o tempo de convergência pode 
ser otimizado; 
 1 Três propriedades se aplicam ao funcionamento do ISPF.
O Incremental SFP consiste em três propriedades principais: 
Propriedade 1
Se um roteador OSPF for adicionado ou removido da SPT e se caracterizar como um roteador 
"folha" da árvore, a SPT só precisa ser alterada para adicionar ou remover tal roteador 
"folha". O mesmo conceito se aplica às redes Não Trânsito, redes "terminais", ou Stub (como 
apresentado na sessão de aprendizagem 1), como por exemplo a Rede 8 utilizada como 
exemplo.  A figura 4.3 possui um roteador (R12) e duas redes Stub adicionados.
q 1 Propriedade 1: 
 1 Se um roteador OSPF for adicionado ou removido da SPT e este se caracterizar 
como um roteador "folha" da árvore, a SPT só precisa ser alterada para adicionar ou 
remover tal roteador "folha"
 1 Mesma regra para redes terminais, stub ou não-trânsito, como a "Rede 8" da figura 4.2
 1 O processo SPF apenas adicionaria o novo roteador (ou nova rede Stub) sem recriar a SPT
 1 Figura 4.3 ilustra a Propriedade 1
Leia o artigo “ARPANET 
Routing Algorithm 
Improvements”, em 
http://www.dtic.mil/
dtic/tr/fulltext/u2/
a086340.pdf 
w
114
 
O
SP
F 
Av
an
ça
do
Rede 11B
Rede 8
R8
Rede 9
R9
Rede 10
R10
Rede 1
R1
Rede 2
R2
R4
R6
R5 R7R3
Rede 12
R12
Rede 11
R11
Nesses casos, com o ISPF, o cálculo SPF seria feito apenas para adicionar o novo roteador 
e as novas redes adicionadas, não recalculando toda a SPT. Como não há necessidade de 
recalcular toda a SPT, o tempo de cálculo tende a ser menor. Para demonstrar os resultados, 
o cenário da figura 4.1 foi criado no arquivo (adr9-cap4-ispf.zip). Primeiramente, a interface 
Loopback do roteador 12 será desativada e o tempo de execução do recálculo da SPT em R6 
será apresentado:
R12#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R12(config)#interface lo0
R12(config-if)#shutdown
R12(config-if)#
*Mar 1 00:34:46.835: %LINK-5-CHANGED: Interface Loopback0, changed state to 
administratively down
*Mar 1 00:34:47.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, 
changed state to down
Como a Interface Loopback0 foi desativada, o roteador R12 gerou um LSA Network que foi 
propagado pela rede OSPF. Observe a saída a seguir. Nessa saída, o comando show ip ospf 
statistics detail foi utilizado. A linha em negrito e em vermelho mostra o tempo total, em milise-
gundos, necessário para computar a mudança recebida do roteador R12 (em negrito e azul).
Figura 4.3 
ISPF e a 
Propriedade 1.
115
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
q 1 A saída a seguir mostra o tempo de execução do SPF caso a interface Loopback de 
R12 seja desativada
 1 Observe o tempo total de 12 ms, pois todos os LSAs foram reprocessados
 1 Observe que o tipo de SPF é Full, ou seja, completo
R6#sh ip ospf statistics detail 
(...)
SPF 19 executed 00:00:20 ago, SPF type Full
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 8 12 0 0 0 0 0 12
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 10 0 
 LSIDs processed R:12 N:15 Stub:11 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 12.12.12.12(R)
R6#sh ip ospf statistics detail 
(...)
SPF 19 executed 00:00:20 ago, SPF type Full
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 8 12 0 0 0 0 0 12
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 10 0 
 LSIDs processed R:12 N:15 Stub:11 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 12.12.12.12(R)
É possível observar que o roteador R6 levou 12 milisegundos para recriar a árvore SPT. 
Vamos agora habilitar o ISPF em R6:
R6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R6(config)#router ospf 10
R6(config-router)#ispf
Vamos confirmarse o comando foi aplicado:
R6#sh ip ospf 
 Routing Process "ospf 10" with ID 6.6.6.6
 Start time: 00:04:02.648, Time elapsed: 00:34:07.856
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
116
 
O
SP
F 
Av
an
ça
do
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF enabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
Como o Incremental SPF está habilitado (enabled), vamos habilitar a interface Loopback0 do 
roteador 12 novamente e verificar o tempo necessário em R6:
R6#sh ip ospf statistics detail
SPF 21 executed 00:01:02 ago, SPF type Incremental
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 0 0 4 0 0 0 0 4
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 0 0 
 LSIDs processed R:0 N:0 Stub:1 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 12.12.12.12(R)
qAo habilitarmos o ISPF com o comando a seguir, a mesma alteração do estado da 
Loopback de R12 consome 4 ms e apenas um LSA foi processado.
R6#configure terminal
R6(config)#router ospf 10
R6(config-router)#ispf
Observe que o tipo de SPF foi Incremental.
R6#sh ip ospf statistics detail
SPF 21 executed 00:01:02 ago, SPF type Incremental
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 0 0 4 0 0 0 0 4
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 0 0 
 LSIDs processed R:0 N:0 Stub:1 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 12.12.12.12(R)
117
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Apenas a última execução do SPF executado foi mostrado (SPF 21). Nessa saída, é possível 
ver algumas informações interessantes:
 1 SPF type Incremental: o tipo de cálculo SPF foi o incremental, e não o completo (Full); 
 1 Total 4: o tempo total utilizado pelo SPF foi de 4 milisegundos, três vezes mais rápido que 
o modo Full; 
 1 12.12.12.12(R): a mudança que forçou o SPF foi gerada pelo roteador R12 (Lo0: 12.12.12.12) 
e foi um LSA do tipo Router (R).
Além disso, a saída mostra (Stub: 1). Como vimos na sessão 1, interfaces Loopback são 
chamadas de redes Stub (não confunda com Área Stub!). É possível ver que o ISPF diminuiu 
consideravelmente o tempo de processamento do SPF, de 12 para 4 milisegundos. Como é 
uma funcionalidade local, o ISPF não precisa ser habilitado em todos os roteadores OSPF, 
ou seja, é possível ter na mesma rede OSPF roteadores que suportam ISPF e roteadores que 
não suportam ISPF.
Propriedade 2
A propriedade 2 é relacionada com a alteração do estado do enlace que não é parte da SPT. 
Observe na figura 4.1 que há um enlace entre R2 e R4. Esse enlace não faz parte da SPT de 
R6, logo, se esse enlace tiver seu estado alterado, com ISPF habilitado o roteador R6 não vai 
precisar recalcular a SPT.
q 1 Propriedade 2
 1 Relacionada com a alteração do estado do enlace que não é parte da SPT: se o enlace 
que tem o estado alterado para DOWN não faz parte da SPT, não há necessidade de 
recalculá-la
 1 Observe o enlace entre R2 e R4 na figura 4.2. Como não faz parte da SPT de R6, R6 
não precisa recalcular sua SPT
Desativação da interface FastEthernet 0/1, que liga R2 com R4:
R2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int f0/1
R2(config-if)# #Interface com R4
R2(config-if)# shutdown
*Mar 1 00:48:59.291: %OSPF-5-ADJCHG: Process 10, Nbr 4.4.4.4 on FastEthernet0/1 
from FULL to DOWN, Neighbor Down: Interface down or detached
R2(config-if)#
*Mar 1 00:49:01.283: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to 
administratively down
*Mar 1 00:49:02.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
FastEthernet0/1, changed state to down
  qR2-R4 alterado para DOWN. Tempo total do SPF com ISPF habilitado:
R6#sh ip ospf statistics detail
SPF 23 executed 00:00:16 ago, SPF type Incremental
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 0 0 0 0 0 0 0 0
118
 
O
SP
F 
Av
an
ça
do
qTempo total com ISPF desabilitado:
R6#sh ip ospf statistics detail
SPF 27 executed 00:00:36 ago, SPF type Full
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 8 8 0 0 0 0 0 8
 1 Enquanto que sem ISPF todos os LSAs foram reprocessados e levou 8 ms, com ISPF 
apenas o LSA informado foi reprocessado, e como não faz parte da SPT, nem foi pro-
cessado (tempo 0ms). 
 1 Lembre-se de que a SPT é por roteador. O enlace R2-R4 pode fazer parte da SPT de 
outro roteador e esse teve de calcular a SPT novamente.”.
Observe que, com o ISPF habilitado, não há nenhum processamento da SPT (tempo total é 0):
R6#sh ip ospf statistics detail
SPF 23 executed 00:00:16 ago, SPF type Incremental
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 0 0 0 0 0 0 0 0
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 0 0 
 LSIDs processed R:0 N:0 Stub:1 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 2.2.2.2(R)
Com o ISPF desabilitado, observe o que aconteceria:
R6#sh ip ospf statistics detail
SPF 27 executed 00:00:36 ago, SPF type Full
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 8 8 0 0 0 0 0 8
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 7 0 
 LSIDs processed R:12 N:15 Stub:11 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 2.2.2.2(R)
Fica evidente o benefício de usar ISPF nesse caso também, pois não há a necessidade de 
recalcular a SPT de R6.
Lembre-se de que a SPT é por roteador, ou seja, cada roteador tem sua própria SPT para 
chegar aos demais destinos da rede. Logo, outros roteadores podem ter suas SPTs afe-
tadas por causa da alteração do estado do enlace entre R2 e R4. Nesses casos, a SPT teria 
de ser recalculada.
119
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Propriedade 3
Caso haja uma alteração em um enlace de trânsito que afete parte da SPT, apenas os 
caminhos para chegar aos roteadores pós-enlace afetado precisam ser recalculados. Por 
exemplo, considere que o enlace entre os roteadores R4 e R5 teve seu estado alterado para 
DOWN, conforme a figura 4.4.
q 1 Propriedade 3:
 1 Caso haja uma alteração em um enlace de trânsito que afete parte da SPT, apenas os 
caminhos para chegar nos roteadores pós-enlace afetado precisam ser recalculados
 1 Observe figura 4.4, onde o enlace R4-R5 ficou indisponível, afetando uma sub-árvore 
da SPT
Rede 11B
Rede 8
R8
Rede 9
R9
Rede 10
R10Rede 1
R1
Rede 2
R2
R4
R6
R5 R7R3
Rede 12
R12
Rede 11
R11
“Os roteadores R4, R8, R9 e R12, os enlaces R4-R5, R4-R8, R4-R9, R9-R12 e as redes "Rede 
8", "Rede 9"e "Rede 12" foram os únicos afetados pela alteração do estado do enlace R4-R5. 
Nesse caso, com ISPF, apenas esta sub-árvore precisaria ser reconstruída, e não toda a SPT.
Observe o cálculo do SPF sem ISPF habilitado em R6:”
Figura 4.4 
ISPF Propriedade 3.
120
 
O
SP
F 
Av
an
ça
do
qR6#sh ip ospf statistics detail
SPF 31 executed 00:00:11 ago, SPF type Full
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 12 16 0 0 0 0 0 16
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 4 0 
 LSIDs processed R:12 N:15 Stub:12 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 4.4.4.4(R)
Observe o cálculo do SPF com o ISPF habilitado em R6:
R6#sh ip ospf statistics detail
SPF 36 executed 00:00:13 ago, SPF type Incremental
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 4 8 0 0 0 0 0 8
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 0 0 
 LSIDs processed R:4 N:4 Stub:4 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 4.4.4.4(R)
O tempo de processamento caiu pela metade (16 sem ISPF, 8 com ISPF) e a quantidade 
de enlaces afetados saiu de 12 para 4, o que justifica o uso do ISPF.
 1 Nesta situação, os roteadores R4, R8, R9 e R12, os enlaces R4-R5, R4-R8, R4-R9, 
R9-R12 e as redes "Rede 8", "Rede 9"e "Rede 12" foram os únicos afetados pela alte-
ração do estado do enlace R4-R5
 1 Apenas esta sub-árvore precisaria ser reconstruída, e não toda a SPT
 1 Observe o cálculo do SPF sem ISPF habilitado em R6:
Observe o cálculo do SPF sem ISPF habilitado em R6:
R6#sh ip ospf statistics detail
SPF 31 executed 00:00:11 ago, SPF type Full
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 12 16 0 0 0 0 0 16
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 4 0 
 LSIDs processed R:12 N:15 Stub:12 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 4.4.4.4(R)
121
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
qObserve o cálculo do SPF com o ISPF habilitado em R6:
R6#sh ip ospf statistics detail
SPF 36 executed 00:00:13 ago, SPF type Incremental
 SPF calculation time (in msec):
 SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total
 4 8 0 0 0 0 0 8
 RIB manipulation time (in msec):
 RIB Update RIB Delete
 0 0 
 LSIDs processed R:4 N:4 Stub:4 SN:0 SA:0 X7:0
 Change record
 LSIDs changed 1
 Changed LSAs. Recorded is LS ID and LS type:
 4.4.4.4(R)
Outras situações que não cobertas pelas três propriedades anteriores exigem o cálculo FULL 
do SPF, por exemplo:
 1 Troca de métricas e adição de novos enlaces, que melhoram a conectividade da rede; 
 1 Alteração de qualquer enlace do próprio roteador (por exemplo, qualquer alteração em 
R6 força o processamento FULL do SPF); 
 1 Alteração de enlace em redes Full Mesh (todos os roteadores ligados a todos os outros 
roteadores). 
q 1 É fácil ver os benefícios de usar o ISPF, já que o tempo de execução pode ser conside-
ravelmente menor.
 1 Situações que diferem das três propriedades apresentadas exigem cálculo Full do SPF, 
por exemplo:
 2 Troca de métricas e adição de novos enlaces; 
 2 Alterações em qualquer enlace do próprio roteador. 
 1 Em ambientes de conectividade Full-Mesh, ou seja, todos roteadores têm enlaces 
para todos os demais roteadores, também requerem execução Full do SPF.
Graceful Restart
q 1 No funcionamento padrão do OSPF, em caso de reiniciação do processo ou problemas 
no módulo de controle, as vizinhanças são desfeitas; 
 1 Roteadores vizinhos precisam fazer a convergência do tráfego buscando caminhos 
alternativos, caso existam; 
 1 Em certos equipamentos, mesmo com a reinicialização do Plano de Controle, o Plano 
de Encaminhamento pode continuar funcionando; 
 1 Para evitar indisponibilidades quando esses equipamentos estão presentes, o IETF 
padronizou o Graceful Restart, RFC 3623. 
Os roteadores atuais são compostos por três planos de operação:
 1 Plano de Controle; 
 1 Plano de Encaminhamento; 
 1 Plano de Gerência. 
122
 
O
SP
F 
Av
an
ça
do
O Plano de Controle é o conjunto de processos responsáveis por negociar informações de 
rotas entre roteadores, configuração de rotas estáticas, criação da árvore do protocolo 
Spanning Tree etc. Todos esses processos são executados na CPU principal do roteador.
O Plano de Encaminhamento é o conjunto de processos responsáveis pelo encaminhamento 
dos quadros e pacotes entre interfaces físicas do equipamento de rede. O modo como o encami-
nhamento deve ser feito é de responsabilidade do Plano de Controle, que instala as rotas nos 
processadores dedicados a encaminhamento, conhecidos como ASICs (Application Specific 
Integrated Circuits) ou FPGAs (Field-programmable Gate Array). Esses processadores específicos 
são capazes de encaminhar e rotear milhões de pacotes por segundo, sem necessidade de usar 
a CPU principal do equipamento de rede. Nos equipamentos que possuem módulos específicos 
de portas e módulos de gerência (supervisores ou Route-Engines), os papéis são bem mais 
claros, uma vez que o Plano de Controle tende a ficar no módulo de gerência.
O Plano de Gerência é o conjunto de processos responsáveis por monitorar e notificar o 
administrador de rede sobre o funcionamento do equipamento, por exemplo, contadores de 
interfaces, uso de CPU e memória, processo SNMP, NetFlow/sFlow, Syslog etc.
Os roteadores modernos são compostos por três planos de operação:
q 1 Plano de Controle: responsável por definir como o tráfego deve ser encaminhado; 
utiliza a CPU principal do equipamento; 
 1 Plano de Encaminhamento: responsável pelo encaminhamento do tráfego entre as 
interfaces; utiliza processadores dedicados (ASICs ou FPGAs); 
 1 Plano de Gerência: responsável por monitorar a operação do equipamento; utiliza a 
CPU principal do equipamento; 
 1 O OSPF e outros protocolos de roteamento funcionam no Plano de Controle. 
Na operação de uma rede com muitos roteadores, inevitavelmente um ou mais equipamentos 
de rede precisarão ter seus Sistemas Operacionais atualizados, seja por correções de segu-
rança, seja por novas funcionalidades. Equipamentos de rede mais modernos permitem que 
o Sistema Operacional seja atualizado, mas sem remover as informações de encaminhamento 
e/ou roteamento dos módulos de interfaces, ou seja, sem alterar o Plano de Encaminhamento. 
Dessa maneira, o Sistema Operacional é atualizado, o Plano de Controle reiniciado (incluindo 
o processo OSPF) e somente após o carregamento total e sincronismos entre os módulos de 
gerência é que as tabelas de encaminhamento são atualizadas ou alteradas.
No funcionamento padrão do OSPF, se o processo OSPF é reiniciado, cada vizinho OSPF vai 
perceber a queda da adjacência após o Dead Interval e vai executar o processo SPF para 
calcular novas rotas que não incluam o roteador que está indisponível. Após esse cálculo, 
o tráfego pode ser roteado por outro caminho. Porém, como mencionado anteriormente, 
alguns roteadores modernos permitem que o tráfego continue a ser encaminhado mesmo 
em caso de reinicializaçãodo módulo de gerência ou de um processo específico. Para que 
esse encaminhamento continue a ocorrer, o IETF padronizou uma funcionalidade chamada 
OSPF Graceful Restart. Essa funcionalidade está padronizada na RFC 3623.
A funcionalidade Graceful Restart permite que o roteador OSPF notifique seus vizinhos de que 
o processo OSPF será reiniciado e que eles devem agir como se o roteador OSPF estivesse fun-
cionando normalmente. Essa notificação é feita através de um LSA específico, chamado Grace 
LSA, que contém na mensagem o motivo da reinicialização e o tempo de indisponibilidade 
estimado (Grace Period). No processo do Graceful Restart, existem duas entidades:
123
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
 1 Restarting Router: roteador que vai reiniciar o processo OSPF; 
 1 Helping Router: roteador vizinho do roteador que vai reiniciar (Restarting Router); 
q 1 O Graceful Restart permite que o processo OSPF notifique seus vizinhos que o 
processo será reinicializado, mas que o encaminhamento do tráfego não será inter-
rompido enquanto isso acontece
 1 Duas entidades foram definidas:
 2 Restarting Router: roteador que irá reiniciar o processo OSPF
 2 Helping Router: roteador vizinho do roteador que irá reiniciar (Restarting Router)
 1 Antes de reiniciar, o Restarting Router envia um Grace LSA informando o motivo e o 
tempo previsto de indisponibilidade
 1 Se o Helping Router suportar o Graceful Restart, o mesmo continua enviando tráfego 
normalmente
 1 Se não suportar, nenhuma resposta é enviada e após o Restarting Router reiniciar, 
as vizinhanças ou adjacências serão finalizadas
Quando o Restarting Router deseja executar um Graceful Restart, ele envia um Grace LSA 
para seus vizinhos. Após esse envio, existem duas possibilidades:
 1 O roteador vizinho que suporta o Grace LSA (Helper Router) vai enviar um LSA ACK para 
o Restarting Router. A partir desse momento, o Helper Router vai continuar anunciando 
os LSAs do tipo Router recebidos anteriormente do Restarting Router para os demais 
roteadores OSPF da área; 
 1 O roteador vizinho não suporta o Grace LSA. Nesse caso, o roteador OSPF ignora os Grace 
LSAs. O Restarting Router, após algumas tentativas, mesmo que não tenha recebido o LSA 
ACK, procede com a reinicialização. Para o vizinho que não suporta o Graceful Restart, o 
processo de funcionamento continua o mesmo: após o Dead Interval, ele vai gerar LSAs 
do tipo Router para os vizinhos OSPF informando que os enlaces com o Restarting Router 
não estão mais disponíveis. 
Após a reinicialização, o Restarting Router precisa seguir alguns passos para sair do estado 
do Graceful Restart:
1. O Restarting Router estabelece as adjacências normalmente com os vizinhos OSPF; 
2. Durante o sincronismo do LSDB, o Restarting Router não gera nenhum LSA, apenas recebe 
os LSAs dos vizinhos; 
3. Após montar o LSDB com os LSAs recebidos, o Restarting Router executa o procedimento 
SPF para calcular as rotas. Porém, as rotas não são instaladas; o Restarting Router as 
utiliza para criar os Virtual Links pré-existentes; 
4. Se nos pacotes Hello recebidos dos vizinhos constar que o Restarting Router é o DR do 
segmento, o Restarting Router se promove a DR; 
5. Se o Restarting Router não perceber inconsistências, como por exemplo, um pacote Hello 
que não o tenha no campo de “Vizinhos Ativos”, ele sai do estado de Graceful Restart 
enviando um novo Grace LSA com o tempo expirado (3.600 segundos). 
124
 
O
SP
F 
Av
an
ça
do
q 1 Antes de voltar a operar novamente, o Restarting Router precisa:
 2 Reestabelecer as vizinhanças OSPF
 2 Durante o sincronismo do LSDB, não pode gerar nenhum LSA
 2 Após receber os LSAs, executa o SPF mas não instala as rotas (usa para 
os Virtual Links)
 2 Verifica as mensagens Hello para ver se deve virar DR
 2 Se não houver inconsistências nos LSAs, envia um novo Grace LSA com o tempo 
expirado (3600s)
Após sair do estado de Graceful Restart, o Restarting Router executa alguns procedimentos:
 1 Todos os LSAs do tipo Router são reoriginados para garantir consistência; 
 1 Já todos os LSAs do tipo Network são reoriginados nos segmentos onde o Restarting 
Router é o DR; 
 1 O processo SPF é reexecutado e as rotas desta vez são instaladas; 
 1 LSAs do tipo 3, 4, 5 e 7 são reoriginados, caso o Restarting Router seja ABR ou ASBR; 
 1 Todas as entradas na tabela de rotas que não são mais válidas são removidas; 
 1 Todos os Grace LSAs são removidos do LSDB. 
q 1 Após sair do estado de Graceful Restart, o Restarting Router executa alguns 
procedimentos:
 2 Todos os LSAs do tipo Router são reoriginados para garantir consistencia;
 2 Todos os LSAs do tipo Network são reoriginados nos segmentos onde o Restarting 
Router é o DR;
 2 O processo SPF é reexecutado e as rotas dessa vez são instaladas. 
 2 LSAs do tipo 3, 4, 5 e 7 são reoriginados, caso o Restarting Router seja ABR ou ASBR;
 2 Todas as entradas na tabela de rotas que não são mais válidas são removidas;
 2 Todos os Grace LSAs são removidos do LSDB.
Os roteadores que suportam o Graceful Restart e viraram Helping Routers podem deixar de 
ser Helping Routers diante dos seguintes eventos:
 1 Um Grace LSA com tempo expirado é recebido do Restarting Router. Nesse caso, o Helping 
Router assume que não é mais necessário ficar nesse estado; 
 1 O Grace Period informado no Grace LSA expirou. Nesse caso, o Restarting Router não 
retornou às atividades dentro da janela de tempo previsto. Logo, o Helping Router age 
como se estivesse indisponível. A partir desse momento, o processo normal do OSPF de 
indisponibilidade de vizinho é executado; 
 1 Uma mudança do LSDB indicando que a topologia da rede mudou. Nesse caso, o Helping 
Router encerra seu papel no processo do Graceful Restart. 
125
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
q 1 Os roteadores Helping Routers podem deixar de ser Helping Router diante dos 
seguintes eventos:
 2 Um Grace LSA com tempo expirado é recebido do Restarting Router.
 2 O Grace Period informado no Grace LSA expirou
 2 Uma mudança do LSDB indicando que a topologia da rede mudou
 1 O modo Helping Router já é habilitado por padrão em alguns fabricantes. Muitas vezes 
com o nome IETF NSF helper (Non-Stop Forwarding).
Alguns fabricantes já ativam o modo Helping Router por padrão, facilitando a operação da 
rede. Por exemplo, observe a saída a seguir:
R1#sh ip ospf
 Routing Process "ospf 10" with ID 1.1.1.1
 Start time: 00:01:08.196, Time elapsed: 00:09:44.664
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
É possível ver a linha IETF NSF, ou NonStop Forward, habilitada. Nesse caso, basta que o 
vizinho OSPF envie um Grace LSApara que esse roteador passe para o modo Helping Router. 
Para ativar o modo Restarting Router, basta inserir os seguintes comandos antes de reiniciar 
o processo OSPF:
R1# (config)# router ospf 10
R1# (config-router)#nsf ietf restart-interval <0-1800>
126
 
O
SP
F 
Av
an
ça
do
q 1 Para iniciar o Graceful Restart no Restarting Router basta configurar o processo OSPF:
R1# (config)# router ospf 10
R1# (config-router)#nsf ietf restart-interval <0-1800>
 1 E na sequência, reiniciar o processo OSPF
 1 Ao solicitar a reinicialização, um Grace LSA será enviado com o tempo informado no 
comando restart-interval.
Após aplicar esse comando, quando o operador reiniciar o processo OSPF, um Grace LSA 
será enviado com o tempo informado no comando restart-interval.
BFD para OSPF
Na sessão 1, o processo de estabelecimento de uma vizinhança OSPF foi apresentado, bem 
como o processo para detectar a queda dos vizinhos. Em particular, o Dead Interval, inter-
valo de tempo em que o OSPF espera por pacotes Hello de um vizinho antes de declará-lo 
"morto" foi apresentado, com alguns exemplos. De acordo com a RFC 2328, o Dead Interval 
padrão é especificado em 40 segundos. Esse tempo de 40 segundos é extremamente 
elevado para as aplicações modernas e, principalmente, as aplicações interativas. Para 
situações onde os roteadores estão diretamente conectados, a queda de interface OSPF 
ativa imediatamente o processo de convergência OSPF. Porém, alguns cenários apresentam 
desafios extras. Observe a topologia da figura 4.5.
q 1 Sessão 1 apresentou o processo de estabelecimento e identificação da queda da adja-
cência OSPF, usando ambos Hello (10 segundos) e Dead Interval (40 segundos)
 1 Quando uma enlace OSPF muda de estado, o roteador diretamente conectado 
detecta a mudança e notifica os demais roteadores OSPF
 1 Se o enlace não estiver diretamente conectado, o Dead Interval é utilizado
 1 Observe a figura 4.5
Internet
R1
SW2 SW1
R3
R2
s1/0
f0/0
s1/0
f0/0
f0/0Rede de Transporte A
1
2 2
3
1
A rede da figura 4.5 possui três roteadores, R1, R2 e R3, e dois switches, SW1 e SW2. 
Os dois switches fazem parte da "Rede de Transporte A", contratada para interconectar os 
roteadores OSPF R1, R2 e R3. Além disso, há um enlace serial entre os roteadores R1 e R3. 
Observe as configurações a seguir.
O modo Restarting 
Router, da funcionali-
dade Graceful Restart, 
só é suportado por 
equipamentos com 
suporte ao encaminha-
mento de pacotes, 
mesmo sem o módulo 
de gerência estar em 
operação. Esse 
comportamento é 
comum em equipa-
mentos de chassis, que 
são modulares. 
Equipamentos menores 
normalmente 
suportam apenas o 
modo Helper Router.  
l
Figura 4.5 
 Bidirectional 
Forwarding 
Detection.
127
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
R1:
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Serial1/0
 ip address 10.1.3.1 255.255.255.0
!
router ospf 10
 network 0.0.0.0 255.255.255.255 area 0
R2:
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
!
router ospf 10
 network 0.0.0.0 255.255.255.255 area 0
R3:
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.3 255.255.255.0
!
interface Serial1/0
 ip address 10.1.3.3 255.255.255.0
! 
router ospf 10
 network 0.0.0.0 255.255.255.255 area 0
É possível observar que todas as interfaces fazem parte da Área Backbone. A rede 
10.0.0.0/24 conecta todos os roteadores via a "Rede de Transporte A", e a rede 10.1.3.0/24 
conecta R1 e R3. Como a interface FastEthernet0/0 dos roteadores R1 e R3 tem melhor custo 
que a interface Serial1/0, a interface Serial1/0 será utilizada apenas como uma interface de 
proteção em caso de queda na infraestrutura da "Rede de Transporte A".
q 1 A "Rede de Transporte A" conecta os três roteadores, criando uma rede Broadcast
 1 Uma rede ponto-a-ponto em um enlace serial conecta R1 e R3
 1 O enlace serial deve ser usado para backup
 1 Todos os roteadores estão na Área Backbone
 1 Todas as adjacências estão estabelecidas:
R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 0 FULL/ - 00:00:36 10.1.3.3 Serial1/0
2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0
128
 
O
SP
F 
Av
an
ça
do
q3.3.3.3 1 FULL/DR 00:00:33 10.0.0.3 FastEthernet0/0
R2#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DROTHER 00:00:37 10.0.0.1 FastEthernet0/0
3.3.3.3 1 FULL/DR 00:00:35 10.0.0.3 FastEthernet0/0
R3#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 0 FULL/ - 00:00:39 10.1.3.1 Serial1/0
1.1.1.1 1 FULL/DROTHER 00:00:36 10.0.0.1 FastEthernet0/0
2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0
Observe que entre R1 e R3 existem duas adjacências estabelecidas, uma via rede 
Broadcast, outra via rede Ponto-a-Ponto.
A seguir, algumas saídas mostrando o funcionamento da Rede OSPF:
R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 0 FULL/ - 00:00:36 10.1.3.3 Serial1/0
2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0
3.3.3.3 1 FULL/DR 00:00:33 10.0.0.3 FastEthernet0/0
R2#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DROTHER 00:00:37 10.0.0.1 FastEthernet0/0
3.3.3.3 1 FULL/DR 00:00:35 10.0.0.3 FastEthernet0/0
R3#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 0 FULL/ - 00:00:39 10.1.3.1 Serial1/0
1.1.1.1 1 FULL/DROTHER 00:00:36 10.0.0.1 FastEthernet0/0
2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0
R1 e R3 possuem 3 vizinhanças, sendo duas entre eles. Uma via interface Serial1/0, uma via 
interface FastEthernet0/0. É possível ver que uma vizinhança é Ponto-a-Ponto (State: Full/-) e 
outra é Broadcast (Full/DROTHER, BDR ou DR).
Vamos analisar algumas possibilidades de alteração de estado de alguns enlaces para 
entender como a rede OSPF se comportaria:
 1 Interface 2 do SW1 e Interface FastEthernet0/0 do R3 tem seus estados alterados para 
DOWN (problema no enlace): ao perceber que a interface FastEthernet0/0 está DOWN, R3 
cria um LSA Router notificando seus vizinhos OSPF. Nesse caso, como a interface FastE-
thernet0/0 está DOWN, apenas R1 seria notificado. Através da interface FastEthernet0/0, R1 
notifica R2; R2 atualiza suas rotas para chegar em R3 via R1. A convergência foi concluída; 
 1 Interface 3 do SW1 e Interface FastEthernet0/0 do R2 tem seus estados alterados 
para DOWN (problema no enlace): como R2 não tem redundância de acesso, R2 não 
tem o que fazer. R1 e R3 vão esperar pelo Dead Interval (40s) para removerem R2 do 
LSDB da Área Backbone; 
 1 Interface 2 do SW2 e Interface FastEthernet0/0 do R1 tem seus estados alterados 
para DOWN (problema no enlace): ao perceber que a FastEthernet0/0 está DOWN, R1 cria 
um LSA Router notificando seus vizinhos OSPF. Nesse caso, como a interface FastEthernet0/0 
está DOWN, apenas R3 seria notificado. Através da interface FastEthernet0/0, R3 notifica R2; 
R2 atualiza suas rotas para chegar em R1 via R3. A convergência foi concluída;129
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Algumas possibilidades de indisponibilidades e impacto na rede:
q 1 Enlace SW1-R3 indisponível: R3 cria um LSA Router para os vizinhos, nesse caso R1; 
R1 atualiza R2 para enviar os pacotes para R3 via R1. Convergência concluída; 
 1 Enlace SW1-R2 indisponível: R2 não tem redundância, fica indisponível; 
 1 Enlace SW2-R1 indisponível: R1 cria um LSA Router para os vizinhos; nesse caso, R3; 
R3 atualiza R2 para enviar os pacotes para R1 via R3. Convergência concluída; 
Em nenhum desses casos, o Dead Interval causou indisponibilidade extra. Outra possibi-
lidade seria:
 1 Enlace SW1-SW2 indisponível: nenhum roteador OSPF diretamente afetado, Dead 
Interval será utilizado. Enquanto isso, o enlace R1-R3 de backup fica sem utilização. 
40 segundos de indisponibilidade pode ser observado. 
É possível observar que nesses três casos listados, apesar do fato de o Dead Interval ser 
relativamente alto, esse valor não trouxe impacto, pois a queda da interface é tratada ime-
diatamente pelos roteadores OSPF. Vamos ver o caso a seguir:
 1 Interface 1 do SW1 e Interface 1 do SW2 tem seus estados alterados para DOWN 
(problema no enlace): nesse caso, apesar de haver um problema na "Rede de Transporte A", 
esse problema não afeta nenhuma interface dos roteadores OSPF. Então, os roteadores R1, 
R2 e R3 vão esperar pelo Dead Interval para fazer a convergência da rede, ou seja, apesar de 
o enlace entre R1 e R3 estar disponível, esse só será utilizado após o Dead Interval.  
 2 Enlace entre SW1 e SW2 desativado. As adjacências OSPF são removidas após 
40 segundos. Observe o Dead Interval decrementando. 
qR1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 0 FULL/ - 00:00:30 10.1.3.3 Serial2/0
2.2.2.2 1 FULL/BDR 00:00:17 10.0.0.2 FastEthernet0/0
3.3.3.3 1 FULL/DR 00:00:15 10.0.0.3 FastEthernet0/0
R1#
*Jun 21 14:50:12.483: %OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on FastEthernet0/0 
from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
*Jun 21 14:50:14.343: %OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on FastEthernet0/0 
from FULL to DOWN, Neighbor Down: Dead timer expired
R3#
*Jun 21 14:50:03.607: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on FastEthernet0/0 
from FULL to DOWN, Neighbor Down: Dead timer expired
Após os alertas de Neighbor Down, R1 e R3 executam o SPF em seus LSDBs. Com isso, o 
enlace serial entre R1 e R2 passa a ser utilizado, permitindo que todos os roteadores sejam 
alcançáveis novamente.
R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 0 FULL/ - 00:00:30 10.1.3.3 Serial2/0
2.2.2.2 1 FULL/BDR 00:00:17 10.0.0.2 FastEthernet0/0
3.3.3.3 1 FULL/DR 00:00:15 10.0.0.3 FastEthernet0/0
R1#
*Jun 21 14:50:12.483: %OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on FastEthernet0/0 
130
 
O
SP
F 
Av
an
ça
do
from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
*Jun 21 14:50:14.343: %OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on FastEthernet0/0 
from FULL to DOWN, Neighbor Down: Dead timer expired
R3#
*Jun 21 14:50:03.607: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on FastEthernet0/0 
from FULL to DOWN, Neighbor Down: Dead timer expired
Na sessão de aprendizagem 1, a funcionalidade de Fast Hello do OSPF foi apresentada jus-
tamente para resolver esse tipo de problema, uma vez que a detecção de desconexão dos 
vizinhos ocorre em menos de 1 segundo. Porém, o Fast Hello é processado pelo Módulo de 
Gerência, no Plano de Controle, consumindo recursos extras de CPU e Memória.
Para permitir uma solução mais escalável e independente do tipo de protocolo de rotea-
mento, o IETF padronizou um protocolo chamado Bidirectional Forwarding Detection, ou 
BFD, na RFC 5880. O BFD é um protocolo de teste de conectividade entre Planos de Enca-
minhamento. Por ser mais leve, o BFD permite que mais sessões sejam monitoradas, com 
intervalos de monitoramento de 50 milisegundos. Além disso, o BFD é agnóstico ao pro-
tocolo de roteamento, podendo ser utilizado para rotas estáticas, OSPF, ISIS, entre outros. 
Alguns equipamentos suportam centenas de sessões BFD ao mesmo tempo.
q 1 Funcionalidade Fast Hello permite convergência em menos de 1 segundo, porém 
consume CPU do roteador
 1 Protocolo Bidirectional Forwarding Detection, ou BFD, foi padronizado na RFC 5880
 1 Protocolo de testes em Planos de Encaminhamento
 1 Permite convergência em intervalos de testes de 50 milissegundos
 1 Independente de protocolo: funciona com OSPF, rota estática, ISIS, BGP, etc.
O BFD funciona como o protocolo Hello: uma mensagem é enviada por cada roteador a 
cada intervalo definido pelo Engenheiro de Redes, e após uma quantidade de mensagens 
perdidas (também definidas pelo Engenheiro de Redes), a sessão BFD é declarada DOWN. 
Quando utilizado com o OSPF, o BFD também notifica o processo OSPF da queda da sessão, 
logo o roteador OSPF atualiza seu LSDB removendo o vizinho indisponível. Nesse caso, o 
Engenheiro de Redes pode inclusive aumentar o intervalo das mensagens Hello, desone-
rando o processo OSPF. Assim como o protocolo Hello, o BFD também suporta autenticação 
das suas mensagens, inclusive com MD5.
Nas redes atuais, o protocolo BFD tem sido muito utilizado em casos onde a conexão entre 
roteadores é feita através de redes Ethernet ou MPLS, que não geram circuitos fim-a-fim.
q 1 BFD utiliza sistema de mensagem de teste similar ao Hello do OSPF
 1 Engenheiro de Redes pode definir o intervalo de testes e quantidade de mensagens 
permitidas antes de declarar vizinho como morto
 1 BFD suporta MD5 por sessão
 1 Muito utilizado para testar enlaces providos via Ethernet ou MPLS 
131
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
A configuração BFD é extremamente simples de ser feita:
1. Habilita-se o BFD nas interfaces dedicadas, definindo o intervalo entre mensagens 
(interval), o tempo mínimo entre mensagens (min_rx) e a quantidade de mensagens que 
devem ser perdidas para considerar o vizinho OSPF como indisponível (multiplier): 
configure terminal
 interface fastEthernet0/0
 bfd interval 50 min_rx 50 multiplier 3
Esse comando habilita o BFD na interface fastEthernet0/0, com intervalo entre mensagens 
de 50 milisegundos,  tempo mínimo para receber as mensagens de 50 milisegundos e a 
quantidade de mensagens perdidas de 3. Ou seja, em caso de indisponibilidades, após 
150 milisegundos (3x50), a sessão OSPF com o roteador inativo seria terminada e o processo 
de convergência executado.
 q 1 A configuração BFD é tão simples quanto o protocolo:
 2 1. Configura-se a(s) interface(s) que terão o BFD habilitado:
configure terminal
interface fastEthernet0/0
bfd interval 50 min_rx 50 multiplier 3
q 2 O intervalo de testes foi configurado para 50 milisegundos
 2 O tempo mínimo para receber as mensagens foi configurado para 50 milisegundos
 2 Mensagens que devem ser perdidas antes de considerar a sessão BFD indisponível: 3
 2 Neste caso, o tempo de detecção da queda da adjacência ocorre em 150 milisegundos.
2. Ativa-se o BFD no processo OSPF (todas as interfaces) ou em interfaces específicas. 
Para ativar por interface:
configure terminal
 interface fastEthernet 0/0
 ip ospf bfd
Para ativar para todas as interfaces OSPF:
configure terminal
 router ospf 10
 bfd all-interfaces
q2. Configura-se o processo OSPF para usar as informações do processo BFD
Pode ser feito por interface:
configure terminal
interface fastEthernet 0/0
ip ospfbfd
*ou para todas as interfaces:
configure terminal
router ospf 10
bfd all-interfaces
Em alguns fabricantes, o 
BFD só é ativado quando 
a adjacência OSPF é 
recriada; logo pode ser 
necessário reiniciar o 
processo OSPF. 
l
132
 
O
SP
F 
Av
an
ça
do
Para confirmar a ativação, execute o comando a seguir e observe a linha "BFD is enabled". 
R1#show ip ospf
 Routing Process "ospf 10" with ID 1.1.1.1
 Start time: 00:00:35.700, Time elapsed: 00:06:41.904
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 (...)
 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 BFD is enabled
 (...)
qVerifique se o BFD está habilitado via comando:
R1#show ip ospf
(...)
 BFD is enabled
Para verificar se as sessões estão criadas:
R1#sh bfd neighbors
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.0.0.3 8003/3 Up Up f0/0
10.0.0.2 8004/4 Up Up f0/0
Para confirmar se as sessões BFD estão criadas, utilize o comando a seguir:
R1#sh bfd neighbors
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.0.0.3 8003/3 Up Up f0/0
10.0.0.2 8004/4 Up Up f0/0
Uma vez que a sessão BFD foi ativada, no próximo incidente que mude o estado do enlace, 
o processo BFD vai detectar a queda e notificar o processo OSPF. Assim, o processo OSPF vai 
executar o SPF novamente para computar a SPT.
q 1 A partir do momento que a sessão BFD foi estabelecida, o processo BFD fará os testes 
no intervalo determinado, e ao detectar a queda, notificará o processo OSPF.
 1 Ao ser notificado pelo BFD, o processo OSPF imediatamente desfaz a adjacência com 
o vizinho indisponível e recria a SPT.
 1 O Engenheiro de Redes deve ser cauteloso ao definir o tempo mínimo de intervalo 
do BFD e a quantidade de sessões a serem estabelecidas. Mais sessões e tempos 
menores consomem mais recursos do roteador.
Assim como no Fast 
Hello, o Engenheiro de 
Redes deve ser 
cauteloso na escolha 
de quando ativar o BFD 
e também na escolha 
do intervalo entre 
testes. Intervalos muito 
curtos tendem a 
consumir mais recursos 
e todos os roteadores 
possuem um número 
máximo de sessões 
BFD suportadas, a 
depender da plata-
forma. 
l
133
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Supressão de Prefixos
Redes de provedores de serviços de internet (internet Service Providers: ISPs) contêm 
milhares de rotas, principalmente se contarmos com a tabela BGP global (mais de 500 mil 
prefixos IPv4 atualmente). E muitas dessas redes possuem diversos enlaces conectando 
diversos roteadores, aumentando a capacidade de tráfego e a resiliência da rede. Em muitos 
casos, as conexões são feitas entre pares de roteadores, seja através de circuitos seriais, 
ópticos ou via VLANs específicas.
No tópico do Incremental SFP, foi apresentada uma abordagem para evitar a execução com-
pleta do SPF em casos de alteração de estados mais simples, como em roteadores folhas 
ou enlaces que não fazem parte da SPT (Shortest Path Tree). Em redes que possuem muitos 
enlaces que concentram apenas roteadores – enlaces chamados de Redes de Trânsito –, 
além do ISPF, outro recurso está à disposição do Engenheiro de Redes para aumentar a 
escalabilidade do processo OSPF: a Supressão de Prefixos. Esse recurso foi padronizado 
na RFC 6860 com o objetivo de remover os prefixos desses enlaces de trânsito da tabela de 
rotas. Essa funcionalidade se aplica tanto em enlaces ponto-a-ponto como enlaces do tipo 
Broadcast. Observe o cenário da figura 4.6 (arquivo adr9-cap4-supressao.zip).
q 1 Redes de ISPs já possuem milhares de rotas, recebidas via BGP e IGP
 1 Quanto mais enlaces entre roteadores, mais Redes de Trânsito são criadas
 1 Redes altamente conectadas possuem em seus LSDBs muitos prefixos apenas para 
trânsito, ou seja, desnecessários do ponto de vista dos usuários
 1 RFC 6860 padronizou uma funcionalidade para melhorar a escalabilidade do OSPF: 
a Supressão de Prefixos
 1 Redes de Trânsito são removidas do LSDB quando a Supressão de Prefixos é habilitada
 1 Melhora o tempo de convergência através da diminuição do LSDB
192.168.3.0/24
192.168.1.0/24 192.168.2.0/24
R1 R2 R3
R4 R5
10.1.2.0/24 10.2.3.0/24
10.2.4.0/24
10.4.5.0/24
10.3.5.0/24
Nesta topologia, existem três redes de usuários (192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) e 
cinco roteadores (R1, R2, R3, R4 e R5). O prefixo 10.0.0.0/24 foi utilizado para endereçar as 
interfaces Loopbacks (10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4 e 10.0.0.5), e o prefixo 10.X.Y.N/24 
para endereçar as conexões entre roteadores, seguindo o modelo em uso ao longo deste livro.
Figura 4.6 
Topologia para 
Supressão de 
Prefixos.
134
 
O
SP
F 
Av
an
ça
do
Para ilustrar algumas diferenças de funcionamento, o enlace R1-R2 ficou configurado no 
modo Broadcast, enquanto os demais enlaces estão configurados como ponto-a-ponto. 
A seguir está a configuração das interfaces do roteador R5:
interface FastEthernet0/0
 ip address 10.4.5.5 255.255.255.0
 ip ospf network point-to-point
!
interface GigabitEthernet1/0
 ip address 10.3.5.5 255.255.255.0
 ip ospf network point-to-point
q 1 A rede da figura 4.6 possui:
 2 Três redes de usuários (192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24);
 2 Cinco roteadores (R1, R2, R3, R4 e R5);
 2 Cinco interfaces Loopbacks (10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4 e 10.0.0.5);
 2 Cinco redes de trânsito (10.1.2.0/24, 10.2.3.0/24, 10.2.4.0/24, 10.3.5.0/24, 10.4.5.0/24);
 2 Enlace R1-R2 está configurado como Broadcast;
 2 Demais enlaces estão configurados como Ponto-a-Ponto.
qObserve a seguir a saída da tabela de rotas de R5:
R5#show ip route ospf
 10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
O 10.0.0.2/32 [110/21] via 10.4.5.4, 00:03:12, FastEthernet0/1
 [110/21] via 10.3.5.3, 00:03:12, FastEthernet0/0
O 10.1.2.0/24 [110/30] via 10.4.5.4, 00:03:12, FastEthernet0/1
 [110/30] via 10.3.5.3, 00:03:12, FastEthernet0/0
O 10.0.0.3/32 [110/11] via 10.3.5.3, 00:03:12, FastEthernet0/0
O 10.2.3.0/24 [110/20] via 10.3.5.3, 00:03:12, FastEthernet0/0
O 10.0.0.1/32 [110/31] via 10.4.5.4, 00:03:12, FastEthernet0/1
 [110/31] via 10.3.5.3, 00:03:12, FastEthernet0/0
O 10.2.4.0/24 [110/20] via 10.4.5.4, 00:03:12, FastEthernet0/1
O 10.0.0.4/32 [110/11] via 10.4.5.4, 00:03:12, FastEthernet0/1
 192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/31] via 10.4.5.4, 00:03:12, FastEthernet0/1
 [110/31] via 10.3.5.3, 00:03:12, FastEthernet0/0
O E2 192.168.2.0/24 [110/20] via 10.3.5.3, 00:03:12, FastEthernet0/0
 192.168.3.0/32 is subnetted, 1 subnets
O 192.168.3.1 [110/11] via 10.4.5.4, 00:03:13, FastEthernet0/1
Nessa tabela de rotas, é possível observar diversas rotas, incluindo as rotas que endereçam 
conexões entre roteadores (redes de trânsito), como por exemplo os prefixos 10.1.2.0/24, 
10.2.3.0/24 e 10.2.4.0/24. A rede de usuário 192.168.2.0/24 foi redistribuída no processo 
OSPF pelo roteador R3 (por isso O E2 à frente da rota). Observe também que o ECMP está 
em uso, com alguns prefixos possuindo mais de um caminho – por exemplo, 10.0.0.2/32 
pode ser alcançado via R4 (10.4.5.4) e R3 (10.3.5.3).
É muito comum em ISPs de médio e grande porte que as conexões entre roteadores sejam 
criadas via enlacesponto-a-ponto e utilizando prefixos /30 e/ou /31. Nesse caso, quanto maior 
135
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
a quantidade de roteadores e enlaces entre estes, maior a quantidade de rotas associadas a 
Redes de Trânsito. Porém, essas rotas têm pouco ou nenhuma importância na maioria dos 
casos, e acabam consumindo recursos do LSDB e dos roteadores OSPF. A RFC 6860 propôs 
justamente remover esses prefixos das tabelas de roteamento OSPF, diminuindo o LSBD, o 
tempo de convergência, aumentando a escalabilidade e a segurança da rede.
Antes de apresentar o funcionamento da RFC 6860, uma revisão sobre os LSA Router e 
Network será feita a seguir, utilizando a topologia da figura 4.6 como exemplo. A saída a 
seguir mostra o LSDB da Área 0 coletado a partir de R5:
R5#sh ip ospf database 
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.0.1 10.0.0.1 183 0x80000002 0x005215 3
10.0.0.2 10.0.0.2 34 0x80000004 0x00B788 6
10.0.0.3 10.0.0.3 28 0x80000003 0x00273C 5
10.0.0.4 10.0.0.4 40 0x80000004 0x00E7F4 6
10.0.0.5 10.0.0.5 28 0x80000004 0x0081D0 5
 Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.2.1 10.0.0.1 183 0x80000001 0x006B9E
 Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
192.168.2.0 10.0.0.3 39 0x80000001 0x00B374 0
É possível ver que R1 está anunciando três enlaces no LSA Router (Link count). Observe-os 
a seguir.
R5#sh ip ospf database router adv-router 10.0.0.1
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Router Link States (Area 0)
 LS Type: Router Links
 Link State ID: 10.0.0.1
 Advertising Router: 10.0.0.1
 Number of Links: 3
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 192.168.1.1
 (Link Data) Network Mask: 255.255.255.255
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.0.0.1
 (Link Data) Network Mask: 255.255.255.255
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.1.2.1
 (Link Data) Router Interface address: 10.1.2.1
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
136
 
O
SP
F 
Av
an
ça
do
Nesta saída existem os seguintes tipos de enlace: dois do Tipo 3 (Stub Network) e um do Tipo 2 
(Transit Network).  O Tipo 2 é utilizado para informar em qual rede existe um Designated 
Router. O Tipo 3 informa a rota que será instalada na tabela de rotas. Observe agora o LSA 
Router originado por R2:
R5#sh ip ospf database router adv-router 10.0.0.2
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Router Link States (Area 0)
 LS Type: Router Links
 Link State ID: 10.0.0.2
 Advertising Router: 10.0.0.2
 Number of Links: 6
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.0.0.2
 (Link Data) Network Mask: 255.255.255.255
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 10.0.0.3
 (Link Data) Router Interface address: 10.2.3.2
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.2.3.0
 (Link Data) Network Mask: 255.255.255.0
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 10.0.0.4
 (Link Data) Router Interface address: 10.2.4.2
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.2.4.0
 (Link Data) Network Mask: 255.255.255.0
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.1.2.1
 (Link Data) Router Interface address: 10.1.2.2
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
Observe que R2 anunciou 3 enlaces do Tipo 3 (Stub Network), 1 enlace do Tipo 2 (Transit 
Network) e 2 enlaces do Tipo 1 (point-to-point). O Tipo 1 é utilizado para o cálculo do SPF e 
está relacionado a enlaces ponto-a-ponto. Quando o Tipo 1 é utilizado, o campo “Link Data” 
informa o endereço IP da interface a ser utilizada para alcançar o vizinho OSPF. Quando o 
Tipo 3 é utilizado, o campo “Link Data” informa a máscara de subrede da rede Stub. No caso 
do Tipo 2, o campo “Link Data” informa o endereço IP da interface do originador do LSA. No 
Tipo 2, o campo “Link ID” informa o endereço IP da interface do roteador DR. Em caso de 
dúvidas, consulte a tabela 1.2, da sessão 1.
137
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
É possível notar que existem dois registros associados com o mesmo enlace entre o rote-
ador R2 e o roteador R3:
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 10.0.0.3
 (Link Data) Router Interface address: 10.2.3.2
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.2.3.0
 (Link Data) Network Mask: 255.255.255.0
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
qObserve os LSAs do tipo Router na Área Backbone:
R5#sh ip ospf database 
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.0.1 10.0.0.1 183 0x80000002 0x005215 3
10.0.0.2 10.0.0.2 34 0x80000004 0x00B788 6
10.0.0.3 10.0.0.3 28 0x80000003 0x00273C 5
10.0.0.4 10.0.0.4 40 0x80000004 0x00E7F4 6
10.0.0.5 10.0.0.5 28 0x80000004 0x0081D0 5
Nesses LSAs, existem LSAs do Tipo 1(Ponto-a-Ponto), do Tipo 2(Transit) e do Tipo 3(Stub.
Observe os LSAs gerados pelo R2 (valores de métrica removidos para simplificar):
R5#sh ip ospf database router adv-router 10.0.0.2
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Router Link States (Area 0)
 LS Type: Router Links
 Link State ID: 10.0.0.2
 Advertising Router: 10.0.0.2
 Number of Links: 6
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.0.0.2
 (Link Data) Network Mask: 255.255.255.255
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 10.0.0.3
 (Link Data) Router Interface address: 10.2.3.2
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.2.3.0
 (Link Data) Network Mask: 255.255.255.0
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 10.0.0.4
 (Link Data) Router Interface address: 10.2.4.2
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.2.4.0
 (Link Data) Network Mask: 255.255.255.0
138
 
O
SP
F 
Av
an
ça
do
q Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.1.2.1(Link Data) Router Interface address: 10.1.2.2
O prefixo IP desse enlace não precisa ser acessado por usuários e seria mais seguro que 
eles realmente não fossem alcançáveis de fora da rede. Então, bastaria ativar a supressão 
de prefixos para remover esse e outros prefixos de trânsito do LSDB. A configuração para 
remoção pode ser feita de duas maneiras:
Por interface OSPF:
configure terminal
 interface fastEthernet 0/1
 ip ospf prefix-suppression
Por roteador:
configure terminal
 router ospf 10
 prefix-suppression
  q 1 A Supressão de Prefixos pode ser feita por interface:
configure terminal
interface fastEthernet 0/1
ip ospf prefix-suppression
 1 Por roteador:
configure terminal
router ospf 10
prefix-suppresion
 1 Uma vez inseridos os comandos, nenhuma rota associada a registros do Tipo 3 para 
redes de trânsito é gerada.
Quando esses comandos são inseridos em interfaces do tipo ponto-a-ponto, nenhuma 
rota associada a registros do Tipo 3 é gerada. Observe o LSDB após a inserção do comando 
prefix-suppresion:
R5#sh ip ospf database 
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.0.1 10.0.0.1 1579 0x80000004 0x004E17 3
10.0.0.2 10.0.0.2 73 0x80000007 0x00E09D 4
10.0.0.3 10.0.0.3 25 0x80000006 0x004261 3
10.0.0.4 10.0.0.4 32 0x80000007 0x008B93 4
10.0.0.5 10.0.0.5 12 0x80000007 0x00593D 3
 Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.2.1 10.0.0.1 22 0x80000004 0x0065A1
 Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
192.168.2.0 10.0.0.3 1391 0x80000003 0x00AF76 0
139
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
q 1 Observe o LSBD com a Supressão de Prefixos habilitada:
R5#sh ip ospf database 
OSPF Router with ID (10.0.0.5) (Process ID 10)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.0.1 10.0.0.1 1579 0x80000004 0x004E17 3
10.0.0.2 10.0.0.2 73 0x80000007 0x00E09D 4
10.0.0.3 10.0.0.3 25 0x80000006 0x004261 3
10.0.0.4 10.0.0.4 32 0x80000007 0x008B93 4
10.0.0.5 10.0.0.5 12 0x80000007 0x00593D 3
 1 Observe que a quantidade de enlaces na coluna Link Count diminui se comparado 
com o LSBD sem supressão.
 1 Lembre-se que redes de usuários, interfaces passivas e loopbacks não são redes de 
trânsito, logo continuam a ser anunciados via OSPF
Note pela coluna "Link count" que a quantidade de enlaces anunciados por R2, R3, R4 
e R5 diminuiu dois valores comparando com a saída antes de aplicarmos o comando 
prefix-suppresion. A seguir é possível ver o LSA Router gerado por R2:
R5#sh ip ospf database router adv-router 10.0.0.2
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Router Link States (Area 0)
 LS Type: Router Links
 Link State ID: 10.0.0.2
 Advertising Router: 10.0.0.2
 Number of Links: 4
 Link connected to: a Stub Network
 (Link ID) Network/subnet number: 10.0.0.2
 (Link Data) Network Mask: 255.255.255.255
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 10.0.0.3
 (Link Data) Router Interface address: 10.2.3.2
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: another Router (point-to-point)
 (Link ID) Neighboring Router ID: 10.0.0.4
 (Link Data) Router Interface address: 10.2.4.2
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
 Link connected to: a Transit Network
 (Link ID) Designated Router address: 10.1.2.1
 (Link Data) Router Interface address: 10.1.2.2
 Number of MTID metrics: 0
 TOS 0 Metrics: 1
140
 
O
SP
F 
Av
an
ça
do
É possível verificar que não existem mais enlaces do Tipo 3 (Stub) associados os enlaces 
ponto-a-ponto. Enlaces associados a interfaces loopbacks ou interfaces passívas não são 
suprimidos, pois não são considerados redes de trânsito. 
Confirmando a tabela de rotas em R5:
R5#sh ip route ospf
 10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
O 10.0.0.1/32 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0
 [110/4] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O 10.0.0.2/32 [110/3] via 10.4.5.4, 01:35:16, FastEthernet0/0
 [110/3] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O 10.0.0.3/32 [110/2] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O 10.0.0.4/32 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0
 192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0
 [110/4] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O E2 192.168.2.0/24 [110/20] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
 192.168.3.0/32 is subnetted, 1 subnets
O 192.168.3.1 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0
  q 1 Verificando a tabela de rotas em R5:
R5#sh ip route ospf
 10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
O 10.0.0.1/32 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0
 [110/4] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O 10.0.0.2/32 [110/3] via 10.4.5.4, 01:35:16, FastEthernet0/0
 [110/3] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O 10.0.0.3/32 [110/2] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O 10.0.0.4/32 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0
 192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0
 [110/4] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
O E2 192.168.2.0/24 [110/20] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
 192.168.3.0/32 is subnetted, 1 subnets
O 192.168.3.1 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0
 1 É possível observar que não existem prefixos da rede 10.X.Y.N/24, somente prefixos 
de usuários e interfaces Loopback.
Por essa saída é possível confirmar que as redes de trânsito não fazem mais parte da tabela 
de rotas.
Nesse ponto, o aluno pode estar se perguntando: por que o prefixo 10.1.2.0/24 sumiu da 
tabela de rotas se ele não era um registro do Tipo 3, e sim do Tipo 2?
q 1 É possível observar que o enlace 10.1.2.0/24 também não está na tabela de rotas de 
R5, apesar de não ser Tipo 3.
 1 Enlaces tipo 2(Transit) também são considerados redes de trânsito, por isso também 
são suprimidos
 1 RFC6860 define que a máscara de subrede do LSA Network seja alterada para /32.
Só há supressão para 
LSAs Router e Network. 
l
141
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Os enlaces do Tipo 2, apesar de não serem redes ponto-a-ponto, também são considerados 
redes de trânsito, logo também não há necessidade de estarem na tabela de rotas. A RFC 
6860 muda isso forçando que os roteadores que suportem supressão de prefixos anunciem 
a máscara do segmento de rede como /32 (nesse caso, sem a supressão seria /24):
R5#sh ip ospf database network
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Net Link States (Area 0)
 LS age: 158
 LS Type: Network Links
 Link State ID: 10.1.2.1 (addressof Designated Router)
 Advertising Router: 10.0.0.1
 Network Mask: /32
 Attached Router: 10.0.0.1
 Attached Router: 10.0.0.2
qObserve o LSA Network:
R5#sh ip ospf database network
 OSPF Router with ID (10.0.0.5) (Process ID 10)
 Net Link States (Area 0)
 LS age: 158
 LS Type: Network Links
 Link State ID: 10.1.2.1 (address of Designated Router)
 Advertising Router: 10.0.0.1
 Network Mask: /32
 Attached Router: 10.0.0.1
 Attached Router: 10.0.0.2
Verifique a Network Mask não está como /24, e sim como /32.
Com essa alteração, o roteador OSPF não cria uma rota para a rede de trânsito do Tipo 2. 
Uma vez que não são mais divulgadas as redes de trânsito, qualquer teste com PING ou 
TRACEROUTE gerado localmente no roteador não vai funcionar se a opção SOURCE não 
for definida:
R1#ping 10.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 10.0.0.5 source 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/42/52 ms
Esse problema acontece porque o roteador usa o endereço da interface mais próxima do 
destino, e como endereços de interfaces não são mais anunciados, os pacotes não têm 
como voltar!
142
 
O
SP
F 
Av
an
ça
do
q 1 A princípal diferença, do ponto de vista da operação da rede, e o PING ou TRACEROUTE 
de dentro dos roteadores. Observe:
R1#ping 10.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
 1 R1 tem rota para 10.0.0.5, mas não pinga. Ao fazer o PING ou TRACEROUTE de dentro do 
roteador, o mesmo escolhe como IP de origem, o IP da interface mais próxima do destino.
 1 Como o IP da interface mais próxima faz parte da rede de trânsito, R5 não tem rota para 
enviar o pacote de volta.
 1 Nesse caso, a origem do teste deve ser definida:
R1#ping 10.0.0.5 source 10.0.0.1
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/42/52 ms
Nesse ponto, o aluno pode estar novamente se questionando: qual o impacto para o iBGP 
e para o monitoramento da rede se não consigo mais “pingar” o IP das interfaces? Dada as 
múltiplas redundâncias disponíveis na rede, as melhores práticas do iBGP é que as sessões 
iBGP sejam feitas entre interfaces loopbacks, haja vista que essas não ficam indisponíveis 
com quedas de enlaces.
Quanto ao monitoramento via ping, esse realmente não é possível, mas via SNMP é possível 
monitorá-las, além do Syslog. O IETF também criou a RFC 5837 para expandir o ICMP a fim 
de ajudar nesse tipo de situação.  Em breve as ferramentas de traceroute estarão disponí-
veis com suporte a RFC 5837, que permitirão o traceroute fornecer informações sobre as 
interfaces envolvidas no caminho IP.
As alterações propostas na RFC 6860 permitem que em uma rede OSPF dispositivos que 
suportem supressão de prefixo funcionem com dispositivos que não suportam tal funcionali-
dade. Nesse caso, o roteador que não suportar supressão de prefixos vai funcionar do modo 
normal e, no caso de enlaces do Tipo 2, vai criar uma rota /32 apontando para o DR da rede.
Apesar de não ser parte do contexto desse material, supressão de prefixos tem sido muito 
utilizado em redes MPLS. Nessas redes, quando se utiliza o protocolo LDP (Label Distribution 
Protocol), um label MPLS é associado a cada prefixo do IGP. Quanto mais prefixos, mais labels 
são utilizados, o que também consome recursos extras do roteador OSPF/MPLS.
Monitorando o OSPF com a RFC 4750: OSPF Version 2 MIB
q 1 Redes de computadores devem ter seus ativos de rede e protocolos monitorados 
constantemente. 
 1 O protocolo SNMP (Simple Network Management Protocol) provê diversas informações 
para operação da rede. 
143
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
q 1 Itens como utilização e erros das interfaces, CPU e memória, fontes, ventiladores e 
laser recebido nas interfaces são itens mínimos a serem monitorados. 
 1 Monitoramento OSPF via SNMP está definido na RFC 4750, que especifica a Management 
Information Base (MIB) do OSPF. 
 1 Diversos objetos estão contemplados e disponíveis para os operadores de rede. 
 1 Esses objetos podem ser monitorados por qualquer NMS (Network Management 
System) disponível que use SNMP, como Nagios, Cacti e Zabbix etc. 
Até esse ponto, diversas funcionalidades, técnicas e abordagens para configurar o protocolo 
OSPF foram apresentadas para fazer a rede OSPF robusta, escalável e funcional. Porém, o 
Engenheiro de Redes não pode apenas configurar os roteadores e esquecê-los. Todos os 
ativos da rede precisam ser monitorados constantemente, para que quando houver algum 
incidente, o Engenheiro de Redes tenha informação suficiente para identificar, isolar e res-
taurar a rede.
Normalmente, apenas os monitoramentos padrão são feitos utilizando SNMP (Simple 
Network Management Protocol): utilização e erros nas interfaces, quantidade de pacotes 
unicast, broadcast e multicast, uso de CPU e memória, e poucos outros. Porém, via SNMP, é 
possível monitorar muitos outros objetos, entre eles objetos relacionados ao protocolo OSPF. 
A RFC 4750 especifica a Management Information Base (MIB), que descreve quais objetos são 
monitorados e quais são os identificadores desses objetos (OID: Object Identifier).
O SNMP é suportado em praticamente todos os Sistemas Operacionais de uso geral: Microsoft 
Windows, GNU/Linux, Unix e MAC OS X, e por todos os fabricantes de equipamentos de rede 
corporativas. Atualmente, existem diversas MIBs que podem ser utilizadas para monitorar 
desde interface de rede até objetos do próprio Sistema Operacional, como transações de 
bancos de dados. Aplicações como MRTG e Cacti se consolidaram como interfaces web para 
o SNMP; aplicações mais modernas, como Zabbix, e algumas proprietárias, como o Tivoli ou 
CA, também fazem uso do SNMP nativamente.
Como não é um monitoramento comumente implantado, muitos desses softwares 
mencionados não possuem templates já prontos para usar com OSPF, mas há vasta 
documentação na internet – não é dificil criá-los. Porém, mais importante que apresentar 
as ferramentas, é apresentar a MIB especificada na RFC 4750 e descrever os principais 
objetos que podem ser monitorados.
q 1 A MIB do OSPF consiste das seguintes tabelas:
 2 Variáveis Gerais 
 2 Estrutura de Dados de Áreas 
 2 Tabela de Métricas de Áreas Sub
 2 Link State Database
 2 Tabelas de range de endereços e Hosts
Para ajudar no entendimento, as seções que compõem a MIB do OSPF serão apresentadas, 
bem como o OID da tabela e os principais objetos a serem explorados adiante.
144
 
O
SP
F 
Av
an
ça
do
Tabela OID Principais Objetos
Variáveis Gerais (General Variables): descreve variáveis 
globais do processo OSPF
ospfGeneralGroup 
1.3.6.1.2.1.14.1
ospfRouterId 
ospfAdminStat
Estrututas de Dados de Áreas (Area Data Structure): 
descreve todas as áreas da qual o roteador faz parte
ospfAreaTable 
1.3.6.1.2.1.14.2
ospfAreaId ospfAuthType
Tabela de Métricas de Áreas Stub (Area Stub Metric 
Table): descreve as métricas enviadas para a(s) área(s) 
Stub
ospfStubAreaTable
1.3.6.1.2.1.14.3
ospfStubAreaId
Link State Database (LSDB): provê informações do 
LSDB para tratamento de erros
ospfLsdbTable1.3.6.1.2.1.14.4
ospfLsdbAreaId
Tabela de Range de Endereços (Address Range Table): 
provê informações sobre sumários e rotas de hosts
ospfAreaRangeTable
1.3.6.1.2.1.14.5
ospfAreaRangeNet
Tabela de Hosts (Host Table): provê informações sobre 
sumários e rotas de hosts
ospfHostTable
1.3.6.1.2.1.14.6
ospfHostMetric 
ospfHostAreaID
Tabela de Interfaces (Interface Table): provê informa-
ções sobre as interfaces OSPF
ospfIfTable 
1.3.6.1.2.1.14.7
ospfIfType 
ospfIfHelloInterval
ospfIfDesignatedRouter
Tabela de Métrica de Interface (Interface Metric Table): 
provê informações de métrica das interfaces OSPF
ospfIfMetricTable
1.3.6.1.2.1.14.8
ospfIfMetricValue
Tabela de Interface Virtual (Virtual Interface Table): 
provê informações sobre os Virtual Links
ospfVirtIfTable 
1.3.6.1.2.1.14.9
ospfVirtIfNeighbor
Tabela de Vizinho (Neighbor Table): descreve os vizi-
nhos OSPF
ospfNbrTable 
1.3.6.1.2.1.14.10
ospfNbrIpAddr 
ospfNbrRtrId
ospfNbrState
Tabela de Vizinho Virtual (Virtual Neighbor Table): des-
creve os vizinhos OSPF usando Virtual Links
ospfVirtNbrTable
1.3.6.1.2.1.14.11
ospfVirtNbrArea 
ospfVirtNbrRtrId
LSDB Externo (External Link State Database): provê 
informações do LSDB para tratamento de erros
ospfExtLsdbTable
1.3.6.1.2.1.14.12
ospfExtLsdbType
Tabela de Range Agregado (Aggregate Range Table): 
informa os prefixos sumarizados
ospfAreaAggregateTable
1.3.6.1.2.1.14.14
ospfAreaAggregateAreaID
LSDB Local (Local Link State Database): idêntico ao 
LSDB mas contém apenas LSAs Opacos (Tipo 9)
ospfLocalLsdbTable
1.3.6.1.2.1.14.17
ospfLocalLsdbEntry
LSDB escopo AS (AS-scope Link State Database): idên-
tico ao LSDB mas contém apenas LSAs Externos
ospfAsLsdbTable
1.3.6.1.2.1.14.19
ospfAsLsdbEntry
qContinuação das tabelas disponíveis na MIB do OSPF:
 1 Tabelas de Interface, Métrica de Interface e Interface Virtual; 
 1 Tabelas de Vizinho e Vizinho Virtual; 
 1 LSDB Externo, LSDB Local, LSBD escopo AS; 
 1 Tabela de Range Agregado. 
Tabela 4.1 
Seções que 
compõem a MIB 
do OSPF.
145
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Conforme mencionado anteriormente, a MIB do OSPF foi criada para permitir o monitora-
mento remoto dos objetos, tabelas e parâmetros que compõem a operação do OSPF em 
um determinado roteador. Os resultados obtidos via SNMP também podem ser obtidos 
pela linha de comando do equipamento; porém, em ambientes com muitos equipamentos, 
o ideal é automatizar a operação e monitoramento. Para ilustrar as saídas possíveis, vamos 
utilizar a topologia da figura 4.7.
q 1 A MIB OSPF possui o OID 1.3.6.1.2.1.14
 1 Cada tabela tem um OID - Object Identifier que a representa, através de um índice 
especifico.
 1 Exemplos:
 2 Variáveis gerais - Índice 1 - 1.3.6.1.2.1.14.1
 2 Tabela de Interfaces - Índice 7 - 1.3.6.1.2.1.14.7
 1 Para demonstrar a utilização da MIB do OSPF, a figura 4.7 será utilizada.
A topologia da figura possui diversas configurações, como tipos de área, de autenticação, 
de rede e métricas diferentes. Todas as configurações já são de conhecimento dos alunos.
192.168.2.0/24
192.168.1.0/24 192.168.3.0/24
R1 R2 R3
R4 R5
10.1.2.0/24 10.2.3.0/24
10.2.4.0/24
Senha Simples
Custo 15
10.4.5.0/24
10.2.5.0/24 - M
D5
Area 1 Stub
Area 2
Gerência
17
2.
16
.1
.0
/2
4
Essa rede possui as seguintes características:
 1 Cinco roteadores OSPF, atuando como roteadores internos (R3), ABR (R2, R4 e R5) 
e ASBR (R1); 
 1 Os enlaces R1-R2 e R4-R5 não possuem autenticação; 
 1 O enlace R2-R5 possui autenticação MD5; 
 1 O enlace R2-R4 possui autenticação simples; 
 1 Além da Área Backbone, há uma área Stub (Area 1) e uma Área Normal (Área 2); 
 1 R1 faz a redistribuição do prefixo 192.168.1.0/24 na Área Backbone; 
 1 O enlace R2-R4 possui custo alterado para 15; 
 1 O enlace R2-R5 está configurado como ponto-a-ponto; 
 1 R4 gera um LSA-Summary para o prefixo 192.168.2.0/24; 
 1 Um Virtual Link será criado entre R4 e R5; 
 1 Um servidor de gerência, com pacote SNMP instalado, foi instalado com o IP 172.16.1.2.
 
Cada seção possui 
diversos objetos, que 
podem ser do tipo 
"somente leitura" 
(read-only) 
ou "leitura e escrita" 
(read-write). É 
importante o aluno ter 
em mente que um 
roteador mal-configu-
rado pode criar riscos 
de segurança. 
l
Figura 4.7 
SNMP.
146
 
O
SP
F 
Av
an
ça
do
q 1 Todas as consultas SNMP serão feitas a partir de um servidor Linux com o pacote 
SNMP instalado. 
 1 As consultas foram feitas com o comando snmpwalk, SNMP versão 2 e a community 
(senha) public. 
 1 Nos roteadores, a configuração a seguir foi feita para habilitar o SNMP:
configure terminal
 snmp-server community public
 1 Não habilite essa configuração em ambientes de produção, a menos que troque 
a community.. 
O servidor Gerência possui o pacote SNMP instalado, o que lhe dá acesso às ferramentas 
de consulta e modificação via SNMP. Nos exemplos a seguir, o comando snmpwalk será 
utilizado, sempre com a community SNMP "public" e a versão 2 do SNMP (2c). A community 
é equivalente a uma senha de acesso e deve ser configurada no roteador. Em ambientes 
de produção, considere utilizar communities mais complexas e a versão 3 do SNMP, que 
suporta autenticação.
Antes de iniciar as consultas SNMP, o seguinte comando deve ser aplicado em cada roteador:
configure terminal
 snmp-server community public
 
Atenção: esse comando habilita o processo SNMP no roteador, e permite consultas 
que usarem a community "public". Não aplique esse comando dessa maneira em 
equipamentos de produção, a menos que saiba exatamente o que está fazendo!
No servidor de gerência, a MIB OSPF deve estar instalada. A configuração do SNMP e a ins-
talação da MIB OSPF serão apresentados como parte das atividades práticas da sessão de 
aprendizagem 4.
A seguir, as principais tabelas serão apresentadas, usando como referência o nome do 
OID apresentado na tabela de OIDs, com os principais objetos exemplificados. Caso queira 
conhecer todos os objetos disponíveis, consulte a RFC 4750.
Explorando a tabela ospfGeneralGroup (Variáveis Globais)
q 1 A tabela Variáveis Globais é representada pelo objeto ospfGeneralGroup, com 
ID 1.3.6.1.2.1.14.1. 
 1 Observe os objetos disponíveis no roteador R2:
snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfGeneralGroup
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2
OSPF-MIB::ospfAdminStat.0 = INTEGER: enabled(1)
OSPF-MIB::ospfVersionNumber.0 = INTEGER: version2(2)
OSPF-MIB::ospfAreaBdrRtrStatus.0 = INTEGER: true(1)
OSPF-MIB::ospfASBdrRtrStatus.0 = INTEGER: false(2)
OSPF-MIB::ospfExternLsaCount.0 = Gauge32: 1
OSPF-MIB::ospfExternLsaCksumSum.0 = INTEGER: 51808
OSPF-MIB::ospfTOSSupport.0 = INTEGER: false(2)
OSPF-MIB::ospfOriginateNewLsas.0 = Counter32: 60
147
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
qOSPF-MIB::ospfRxNewLsas.0 = Counter32: 42
OSPF-MIB::ospfExtLsdbLimit.0 = INTEGER: -1
OSPF-MIB::ospfMulticastExtensions.0 = INTEGER: 0
OSPF-MIB::ospfExitOverflowInterval.0 = INTEGER: 0
OSPF-MIB::ospfDemandExtensions.0 = INTEGER: true(1)
 1 É possível ver na saída o router-id configurado em R2, a versão do OSPF, o tipo de 
roteador (ABR). 
Vamos iniciar com a OID ospfGeneralGroup (1.3.6.1.2.1.14.1), consultando o roteador R2. 
Os objetos mais importantes estão em negrito:
snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfGeneralGroup
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2 
OSPF-MIB::ospfAdminStat.0 = INTEGER: enabled(1)
OSPF-MIB::ospfVersionNumber.0 = INTEGER: version2(2)
OSPF-MIB::ospfAreaBdrRtrStatus.0= INTEGER: true(1)
OSPF-MIB::ospfASBdrRtrStatus.0 = INTEGER: false(2)
OSPF-MIB::ospfExternLsaCount.0 = Gauge32: 1 
OSPF-MIB::ospfExternLsaCksumSum.0 = INTEGER: 51808
OSPF-MIB::ospfTOSSupport.0 = INTEGER: false(2)
OSPF-MIB::ospfOriginateNewLsas.0 = Counter32: 60
OSPF-MIB::ospfRxNewLsas.0 = Counter32: 42 
OSPF-MIB::ospfExtLsdbLimit.0 = INTEGER: -1
OSPF-MIB::ospfMulticastExtensions.0 = INTEGER: 0 
OSPF-MIB::ospfExitOverflowInterval.0 = INTEGER: 0
OSPF-MIB::ospfDemandExtensions.0 = INTEGER: true(1)
É possível ver nessa saída acima o router-id do roteador:
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2
Além do router-id, podemos ver que o processo OSPF está habilitado:
OSPF-MIB::ospfAdminStat.0 = INTEGER: enabled(1)
A versão do OSPF, nesse caso, versão 2:
OSPF-MIB::ospfVersionNumber.0 = INTEGER: version2(2)
E que esse roteador é um ABR, já que está na Área 1 também:
OSPF-MIB::ospfAreaBdrRtrStatus.0 = INTEGER: true(1)
Quando se deseja apenas um objeto específico, podemos filtrá-lo no comando snmpwalk:
snmpwalk -v 2c -c public 10.0.0.2 ospfRouterId
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2
Vamos consultar o router-id de cada roteador:
snmpwalk -v 2c -c public 10.0.0.1 ospfRouterId
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.1
snmpwalk -v 2c -c public 10.0.0.2 ospfRouterId
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2
snmpwalk -v 2c -c public 10.0.0.3 ospfRouterId
148
 
O
SP
F 
Av
an
ça
do
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.3
snmpwalk -v 2c -c public 10.0.0.4 ospfRouterId
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.4
snmpwalk -v 2c -c public 10.0.0.5 ospfRouterId
OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.5
Nesse momento, podemos confirmar que todos os roteadores estão com o SNMP configurado 
e todos têm suporte a MIB do OSPF. Vamos dar prosseguimento e explorar outras tabelas.
Explorando a tabela ospfAreaTable
q 1 Usando a OID ospfAreaTable, podemos consultar informações sobre as Áreas OSPF. 
 1 Observe a saída de R2:
snmpwalk -v 2c -c public 10.0.0.2 ospfAreaID
OSPF-MIB::ospfAreaId.0.0.0.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfAreaId.0.0.0.1 = IpAddress: 0.0.0.1
snmpwalk -v 2c -c public 10.0.0.2 ospfAuthType
OSPF-MIB::ospfAuthType.0.0.0.0 = INTEGER: 0
OSPF-MIB::ospfAuthType.0.0.0.1 = INTEGER: 0
 1 É possível ver que R2 é um ABR (possui duas áreas (0.0.0.0 e 0.0.0.1)), sem autenticação 
(valor 0) por área. 
Vamos explorar a ospfAreaTable. Nessa tabela, os objetos mais importantes são:
 1 ospfAreaID: informa as áreas presentes em um roteador; 
 1 ospfAuthType: informa que tipo de autenticação existe para cada área. 
Observe a consulta à ospfAreaTable do roteador R2.
snmpwalk -v 2c -c public 10.0.0.2 ospfAreaID
OSPF-MIB::ospfAreaId.0.0.0.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfAreaId.0.0.0.1 = IpAddress: 0.0.0.1
snmpwalk -v 2c -c public 10.0.0.2 ospfAuthType
OSPF-MIB::ospfAuthType.0.0.0.0 = INTEGER: 0
OSPF-MIB::ospfAuthType.0.0.0.1 = INTEGER: 0
Observe que o R2 possui duas áreas (Área 0 ou Backbone e Área 1) e que não há autenti-
cação para a área (valor 0 representa sem autenticação).
Observe a consulta feita ao roteador R4, que também possui duas áreas (Backbone e Área 2) 
e não possui autenticação por área.
snmpwalk -v 2c -c public 10.0.0.4 ospfAreaID
OSPF-MIB::ospfAreaId.0.0.0.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfAreaId.0.0.0.2 = IpAddress: 0.0.0.2
snmpwalk -v 2c -c public 10.0.0.4 ospfAuthType
OSPF-MIB::ospfAuthType.0.0.0.0 = INTEGER: 0
OSPF-MIB::ospfAuthType.0.0.0.2 = INTEGER: 0
149
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
qAlém disso, a ospfAreaTable possui os seguintes objetos que podem ser muito úteis:
 1 ospfSpfRuns: informa a quantidade de vezes que o SPF foi executado para uma área 
específica. Quando há muitas modificações em um curto espaço de tempo, significa 
que algum enlace ou roteador está oscilando; 
 1 ospfAreaBdrRtrCount: informa quantos ABRs existem na área; 
 1 ospfAsBdrRtrCount: informa quantos ASBRs existem na área. 
 1 Como esses objetos estão associados às áreas, a sintaxe de saída será sempre:
OSPF-MIB::OBJETO.ÁREA = Valor
 1 Por exemplo:
snmpwalk -v 2c -c public 10.0.0.4 ospfSpfRuns
OSPF-MIB::ospfSpfRuns.0.0.0.0 = Counter32: 17
OSPF-MIB::ospfSpfRuns.0.0.0.1 = Counter32: 6
Como esses objetos estão associados às áreas, a sintaxe de saída será sempre:
OSPF-MIB::OBJETO.ÁREA = Valor
Observe a saída de R2 com esses objetos, com as áreas adicionadas à OID:
snmpwalk -v 2c -c public 10.0.0.4 ospfSpfRuns
OSPF-MIB::ospfSpfRuns.0.0.0.0 = Counter32: 17
OSPF-MIB::ospfSpfRuns.0.0.0.1 = Counter32: 6
snmpwalk -v 2c -c public 10.0.0.4 ospfAreaBdrRtrCount
OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.0 = Gauge32: 3
OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.1 = Gauge32: 1
snmpwalk -v 2c -c public 10.0.0.4 ospfAsBdrRtrCount
OSPF-MIB::ospfAsBdrRtrCount.0.0.0.0 = Gauge32: 1
OSPF-MIB::ospfAsBdrRtrCount.0.0.0.1 = Gauge32: 0
Na topologia da figura 4.7, existem três ABRs na Área Backbone e um ABBR. Na Área 1, só 
há um ABR e nenhum ASBR. Lembre-se de que essa consulta é feita por roteador. Logo, se 
consultarmos R4, veremos informações também da Área 2:
snmpwalk -v 2c -c public 10.0.0.4 ospfSpfRuns
OSPF-MIB::ospfSpfRuns.0.0.0.0 = Counter32: 8
OSPF-MIB::ospfSpfRuns.0.0.0.2 = Counter32: 4
snmpwalk -v 2c -c public 10.0.0.4 ospfAreaBdrRtrCount
OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.0 = Gauge32: 3
OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.2 = Gauge32: 2
snmpwalk -v 2c -c public 10.0.0.4 ospfAsBdrRtrCount
OSPF-MIB::ospfAsBdrRtrCount.0.0.0.0 = Gauge32: 1
OSPF-MIB::ospfAsBdrRtrCount.0.0.0.2 = Gauge32: 0
150
 
O
SP
F 
Av
an
ça
do
Explorando a tabela ospfStubAreaTable
q 1 A tabela ospfStubAreaTable só existe nos roteadores que possuem um Área Stub.
 1 Caso o roteador consultado não possua um Área Stub, esse erro será visto:
snmpwalk -v 2c -c public 10.0.0.4 ospfStubAreaId
OSPF-MIB::ospfStubAreaId = No Such Instance currently exists at this OID
 1 A Área 1 é Stub, logo:
snmpwalk -v 2c -c public 10.0.0.2 ospfStubAreaId
OSPF-MIB::ospfStubAreaId.0.0.0.1.0 = IpAddress: 0.0.0.1
 1 Além disso, é possível ver a métrica associada à rota padrão gerada pelo ABR:
snmpwalk -v 2c -c public 10.0.0.2 ospfStubMetric
OSPF-MIB::ospfStubMetric.0.0.0.1.0 = INTEGER: 1
 1 Que pela linha de comando pode ser vista com :
R3#show ip route ospf 
O*IA 0.0.0.0/0 [110/2] via 10.2.3.2, 00:00:14, FastEthernet2/0
 1 Nesse caso, em R3 a rota tem métrica 2, 1 da própria interface FastEthernet e 1 da 
rota enviada por R2
A tabela ospfStubAreaTable só existe nos roteadores que possuem um Área Stub. Caso o 
roteador consultado não possua um Área Stub, esse erro será visto:
snmpwalk -v 2c -c public 10.0.0.4 ospfStubAreaId
OSPF-MIB::ospfStubAreaId = No Such Instance currently exists at this OID
Esse erro significa que a tabela não existe nesse roteador. Como o roteador R2 está conec-
tado à Área 1 que é Stub, essa tabela estará presente:
snmpwalk -v 2c -c public 10.0.0.2 ospfStubAreaId
OSPF-MIB::ospfStubAreaId.0.0.0.1.0 = IpAddress: 0.0.0.1
Outros objetos podem ser consultados, como o ospfStubMetric, que informa o custo asso-
ciado à rota padrão gerada pelo ABR:
snmpwalk -v 2c -c public 10.0.0.2 ospfStubMetric
OSPF-MIB::ospfStubMetric.0.0.0.1.0 = INTEGER: 1
Nesse caso, o custo foi de 1, como pode ser visto pela linha de comando em R3:
R3#sh ip route ospf
O*IA 0.0.0.0/0 [110/2] via 10.2.3.2, 00:00:14, FastEthernet2/0
O valor da métrica total é de 2: 1 da interface FastEthernet + 1 anunciado por R2 para essa 
rota. Observe a troca do custo em R2:
configure terminal
 router ospf 10
 area 1 default-cost 5
151
 
C
ap
ítu
lo
 4- 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
Confirmando via linha de comando e via SNMP:
R3#sh ip route ospf 
O*IA 0.0.0.0/0 [110/6] via 10.2.3.2, 00:00:37, FastEthernet2/0
snmpwalk -v 2c -c public 10.0.0.2 ospfStubMetric
OSPF-MIB::ospfStubMetric.0.0.0.1.0 = INTEGER: 5
É possível observar que tanto via SNMP quanto via CLI é possível monitorar o custo da rota 
padrão na Área Stub.
Explorando a tabela ospfLsdbTable
q 1 A tabela ospfLsdbTable apresenta o LSDB inteiro, de cada área
 1 Contém os LSA existentes, número de sequência, Age, tipos, etc.
 1 Observe a saída abaixo, apresentando os LSAs por tipo, usando o formato:
 2 OSPF-MIB::ospfLsdbAreaId.AREA.TIPO.LINK_ID.ADV_ROUTER IpAddress: AREA 
$ snmpwalk -v 2c -c public 10.0.0.2 ospfLsdbAreaId (Saída simplificada)
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.1.10.0.0.1 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.2.10.0.0.2 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.networkLink.10.2.4.2.10.0.0.2 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.2.1.10.0.0.5 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.3.1.10.0.0.2 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.2.10.0.0.2 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.3.10.0.0.3 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.networkLink.10.2.3.2.10.0.0.2 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.summaryLink.0.0.0.0.10.0.0.2 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 0.0.0.1
A tabela ospfLsdbTable apresenta o LSDB inteiro, de cada área. Nessa tabela podemos 
observar quais são os LSAs existentes, número de sequência, Age, tipos etc. É possível 
inclusive ver o LSA anunciado, em formato hexadecimal. Dessa tabela, o objeto mais impor-
tante é o ospfLsdbAreaId. Observe a saída a seguir de R2: a saída do comando snmpwalk foi 
quebrada em blocos por tipo de LSA. A sintaxe tem a seguinte forma:
OSPF-MIB::ospfLsdbAreaId.AREA.TIPO.LINK_ID.ADV_ROUTER IpAddress: aREA
 1 AREA: número da área em 32 bits; 
 1 TIPO: router, Network, Summary, asSummary, asExternal, nssaExternal; 
 1 LINK_ID: depende do TIPO. Mais detalhes na sessão de aprendizagem 1, tabela 1.2; 
 1 ADV_ROUTER: roteador que está originando o LINK_ID. 
$ snmpwalk -v 2c -c public 10.0.0.2 ospfLsdbAreaId
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.1.10.0.0.1 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.2.10.0.0.2 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.4.10.0.0.4 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.5.10.0.0.5 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.networkLink.10.1.2.2.10.0.0.2 = IpAddress: 0.0.0.0
152
 
O
SP
F 
Av
an
ça
do
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.networkLink.10.2.4.2.10.0.0.2 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.3.10.0.0.2 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.4.10.0.0.4 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.4.10.0.0.5 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.5.10.0.0.4 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.5.10.0.0.5 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.2.3.0.10.0.0.2 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.4.5.0.10.0.0.4 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.4.5.0.10.0.0.5 = IpAddress: 0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.2.0.10.0.0.4 = IpAddress: 
0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.2.1.10.0.0.5 = IpAddress: 
0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.3.1.10.0.0.2 = IpAddress: 
0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 
0.0.0.0
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.2.10.0.0.2 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.3.10.0.0.3 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.networkLink.10.2.3.2.10.0.0.2 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.summaryLink.0.0.0.0.10.0.0.2 = IpAddress: 0.0.0.1
OSPF-MIB::ospfLsdbAreaId.0.0.0.1.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 
0.0.0.1
O primeiro bloco está associado aos LSAs do tipo Router na Área Backbone (0.0.0.0). 
É possível ver os roteadores R1, R2, R4 e R5.
O segundo bloco está associado aos LSAs do tipo Network na Área Backbone (0.0.0.0). 
É possível ver os segmentos R1-R2 (10.1.2.0) e R2-R4 (10.2.4.0). Lembre-se de que o enlace 
com R5 foi configurado como Ponto-a-Ponto, por isso não existe um LSA Network.
O terceiro bloco está associado aos LSAs do tipo Summary na Área Backbone (0.0.0.0).
O quarto bloco lista os LSAs do tipo AS-External. Na sequência, os mesmos tipos de LSA 
para a Área 1 (0.0.0.1).
Explorando a tabela ospfHostTable
q 1 A tabela ospfHostTable mostra informações sobre as interfaces de usuário, ou 
hosts(interfaces passivas).
 1 Essas interfaces não tem roteadores OSPF como vizinhos
 1 Objetos mais importantes: ospfHostMetric e ospfHostAreaID
 1 Exemplo:
$ snmpwalk -v 2c -c public 10.0.0.3 OSPF-MIB::ospfHostTable
OSPF-MIB::ospfHostMetric.10.0.0.3.0 = INTEGER: 1
OSPF-MIB::ospfHostMetric.192.168.3.1.0 = INTEGER: 1
OSPF-MIB::ospfHostAreaID.10.0.0.3.0 = IpAddress: 0.0.0.1
OSPF-MIB::ospfHostAreaID.192.168.3.1.0 = IpAddress: 0.0.0.1
$ snmpwalk -v 2c -c public 10.0.0.4 .1.3.6.1.2.1.14.6
OSPF-MIB::ospfHostMetric.10.0.0.4.0 = INTEGER: 1
153
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
qOSPF-MIB::ospfHostMetric.192.168.2.1.0 = INTEGER: 1
OSPF-MIB::ospfHostAreaID.10.0.0.4.0 = IpAddress: 0.0.0.2
OSPF-MIB::ospfHostAreaID.192.168.2.1.0 = IpAddress: 0.0.0.2
A tabela ospfHostTable mostra informações sobre as interfaces de usuário ou hosts. 
Essas interfaces não têm roteadores OSPF como vizinhos. Dessa tabela, os objetos mais 
importantes são:
 1 ospfHostMetric: métrica associada à interface; 
 1 ospfHostAreaID: área da qual a interface faz parte. 
Observe a seguir o snmpwalk. Os demais objetos foram omitidos para simplificar a visualização.
$ snmpwalk -v 2c -c public 10.0.0.3 OSPF-MIB::ospfHostTable
OSPF-MIB::ospfHostMetric.10.0.0.3.0 = INTEGER: 1
OSPF-MIB::ospfHostMetric.192.168.3.1.0 = INTEGER: 1
OSPF-MIB::ospfHostAreaID.10.0.0.3.0 = IpAddress: 0.0.0.1
OSPF-MIB::ospfHostAreaID.192.168.3.1.0 = IpAddress: 0.0.0.1
snmpwalk -v 2c -c public 10.0.0.4 .1.3.6.1.2.1.14.6
OSPF-MIB::ospfHostMetric.10.0.0.4.0 = INTEGER: 1
OSPF-MIB::ospfHostMetric.192.168.2.1.0 = INTEGER: 1
OSPF-MIB::ospfHostAreaID.10.0.0.4.0 = IpAddress: 0.0.0.2
OSPF-MIB::ospfHostAreaID.192.168.2.1.0 = IpAddress: 0.0.0.2
É possível ver o custo ou métrica da interface com valor 1 e a área à qual as interfaces 
pertencem (0.0.0.1 – Área 1 e 0.0.0.2 – Área 2).
Explorando a tabela ospfIfTable
q 1 A tabela ospfIfTable mostra diversas informações sobre as interfaces OSPF
 1 Principais objetos:
 2 ospfIfAreaId: informa a área da qual a interface faz parte. A interface é represen-
tada pelo IP que possui. Formato:
 3 OSPF-MIB::ospfIfAreaId.IP.0 = IpAddress: AREA
 2 ospfIfType: informa o tipo de rede da interface (broadcast(1), pointToPoint(3), 
nbma(2) e pointToMultipoint(4))
q 2 ospfIfRtrPriority: informa a prioridade da interface para escolha do DR
 2 ospfIfHelloInterval, ospfIfRtrDeadInterval: informam o Hello e o Dead Interval2 ospfIfState: O estado da interface. Pode ser down, loopback, waiting, pointToPoint, 
designatedRouter, backupDesignatedRouter ou otherDesignatedRouter.
 2 ospfIfAuthType: Informa o tipo de autenticação configurada na interface. 0 significa 
sem autenticação, 1 significa autenticação simples, 2 significa autenticação com MD5.
A tabela ospfIfTable mostra diversas informações sobre as interfaces OSPF, e os principais 
objetos são:
 1 ospfIfAreaId: informa a área da qual a interface faz parte. Observe que a interface é 
representada pelo IP que possui, e não pelo nome da interface. O formato está apresen-
tado a seguir: 
OSPF-MIB::ospfIfAreaId.IP.0 = IpAddress: AREA
154
 
O
SP
F 
Av
an
ça
do
 1 ospfIfType: informa o tipo de rede da interface. Os tipos podem ser broadcast(1), 
pointToPoint(3), nbma(2) e pointToMultipoint(4). Novamente, o endereço IP da interface é 
utilizado ao invés do nome da interface; 
 1 ospfIfRtrPriority: informa a prioridade da interface para escolha do DR. Prioridade 0 é 
não elegível, muito comum em redes ponto-a-ponto; 
 1 ospfIfHelloInterval: indica o intervalo Hello da interface. O padrão é 10 segundos; 
 1 ospfIfRtrDeadInterval: informa o intervalo Dead Interval da interface, indicando 
quando o roteador vizinho será considerado desconectado. O padrão é 40 segundos; 
 1 ospfIfState: o estado da interface. Pode ser down, loopback, waiting, pointToPoint, 
designatedRouter, backupDesignatedRouter ou otherDesignatedRouter; 
 1 ospfIfAuthType: indica o tipo de autenticação configurada na interface. 0 significa sem 
autenticação, 1 significa autenticação simples, 2 significa autenticação com MD5. 
Observe a seguir o snmpwalk do roteador R2 e do roteador R5. Os demais objetos foram 
omitidos para simplificar a visualização.  Analise a saída e veja se corresponde com a des-
crição da topologia da figura 4.7.
$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfIfTable
OSPF-MIB::ospfIfAreaId.10.0.0.2.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfAreaId.10.1.2.2.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfAreaId.10.2.3.2.0 = IpAddress: 0.0.0.1
OSPF-MIB::ospfIfAreaId.10.2.4.2.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfAreaId.10.2.5.2.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfType.10.0.0.2.0 = INTEGER: pointToPoint(3)
OSPF-MIB::ospfIfType.10.1.2.2.0 = INTEGER: broadcast(1)
OSPF-MIB::ospfIfType.10.2.3.2.0 = INTEGER: broadcast(1)
OSPF-MIB::ospfIfType.10.2.4.2.0 = INTEGER: broadcast(1)
OSPF-MIB::ospfIfType.10.2.5.2.0 = INTEGER: pointToPoint(3)
OSPF-MIB::ospfIfRtrPriority.10.0.0.2.0 = INTEGER: 0
OSPF-MIB::ospfIfRtrPriority.10.1.2.2.0 = INTEGER: 1
OSPF-MIB::ospfIfRtrPriority.10.2.3.2.0 = INTEGER: 1
OSPF-MIB::ospfIfRtrPriority.10.2.4.2.0 = INTEGER: 1
OSPF-MIB::ospfIfRtrPriority.10.2.5.2.0 = INTEGER: 0
OSPF-MIB::ospfIfHelloInterval.10.0.0.2.0 = INTEGER: 10
OSPF-MIB::ospfIfHelloInterval.10.1.2.2.0 = INTEGER: 10
OSPF-MIB::ospfIfHelloInterval.10.2.3.2.0 = INTEGER: 10
OSPF-MIB::ospfIfHelloInterval.10.2.4.2.0 = INTEGER: 10
OSPF-MIB::ospfIfHelloInterval.10.2.5.2.0 = INTEGER: 10
OSPF-MIB::ospfIfRtrDeadInterval.10.0.0.2.0 = INTEGER: 40
OSPF-MIB::ospfIfRtrDeadInterval.10.1.2.2.0 = INTEGER: 40
OSPF-MIB::ospfIfRtrDeadInterval.10.2.3.2.0 = INTEGER: 40
OSPF-MIB::ospfIfRtrDeadInterval.10.2.4.2.0 = INTEGER: 40
OSPF-MIB::ospfIfRtrDeadInterval.10.2.5.2.0 = INTEGER: 40
OSPF-MIB::ospfIfState.10.0.0.2.0 = INTEGER: loopback(2)
OSPF-MIB::ospfIfState.10.1.2.2.0 = INTEGER: designatedRouter(5)
OSPF-MIB::ospfIfState.10.2.3.2.0 = INTEGER: designatedRouter(5)
OSPF-MIB::ospfIfState.10.2.4.2.0 = INTEGER: designatedRouter(5)
OSPF-MIB::ospfIfState.10.2.5.2.0 = INTEGER: pointToPoint(4)
OSPF-MIB::ospfIfAuthType.10.0.0.2.0 = INTEGER: 0
155
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
OSPF-MIB::ospfIfAuthType.10.1.2.2.0 = INTEGER: 0
OSPF-MIB::ospfIfAuthType.10.2.3.2.0 = INTEGER: 0
OSPF-MIB::ospfIfAuthType.10.2.4.2.0 = INTEGER: 1
OSPF-MIB::ospfIfAuthType.10.2.5.2.0 = INTEGER: 2
snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfIfTable
OSPF-MIB::ospfIfAreaId.10.0.0.5.0 = IpAddress: 0.0.0.2
OSPF-MIB::ospfIfAreaId.10.2.5.5.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfAreaId.10.4.5.5.0 = IpAddress: 0.0.0.2
OSPF-MIB::ospfIfType.10.0.0.5.0 = INTEGER: pointToPoint(3)
OSPF-MIB::ospfIfType.10.2.5.5.0 = INTEGER: pointToPoint(3)
OSPF-MIB::ospfIfType.10.4.5.5.0 = INTEGER: broadcast(1)
OSPF-MIB::ospfIfRtrPriority.10.0.0.5.0 = INTEGER: 0
OSPF-MIB::ospfIfRtrPriority.10.2.5.5.0 = INTEGER: 0
OSPF-MIB::ospfIfRtrPriority.10.4.5.5.0 = INTEGER: 1
OSPF-MIB::ospfIfHelloInterval.10.0.0.5.0 = INTEGER: 10
OSPF-MIB::ospfIfHelloInterval.10.2.5.5.0 = INTEGER: 10
OSPF-MIB::ospfIfHelloInterval.10.4.5.5.0 = INTEGER: 10
OSPF-MIB::ospfIfRtrDeadInterval.10.0.0.5.0 = INTEGER: 40
OSPF-MIB::ospfIfRtrDeadInterval.10.2.5.5.0 = INTEGER: 40
OSPF-MIB::ospfIfRtrDeadInterval.10.4.5.5.0 = INTEGER: 40
OSPF-MIB::ospfIfState.10.0.0.5.0 = INTEGER: loopback(2)
OSPF-MIB::ospfIfState.10.2.5.5.0 = INTEGER: pointToPoint(4)
OSPF-MIB::ospfIfState.10.4.5.5.0 = INTEGER: designatedRouter(5)
OSPF-MIB::ospfIfDesignatedRouter.10.0.0.5.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfDesignatedRouter.10.2.5.5.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfDesignatedRouter.10.4.5.5.0 = IpAddress: 10.4.5.5
OSPF-MIB::ospfIfBackupDesignatedRouter.10.0.0.5.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfBackupDesignatedRouter.10.2.5.5.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfBackupDesignatedRouter.10.4.5.5.0 = IpAddress: 10.4.5.4
OSPF-MIB::ospfIfAuthType.10.0.0.5.0 = INTEGER: 0
OSPF-MIB::ospfIfAuthType.10.2.5.5.0 = INTEGER: 2
OSPF-MIB::ospfIfAuthType.10.4.5.5.0 = INTEGER: 0
 qObserve a tabela ospfIfTable de R2 (simplificada): 
$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfIfTable
OSPF-MIB::ospfIfAreaId.10.0.0.2.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfAreaId.10.2.3.2.0 = IpAddress: 0.0.0.1
OSPF-MIB::ospfIfType.10.2.4.2.0 = INTEGER: broadcast(1)
OSPF-MIB::ospfIfType.10.2.5.2.0 = INTEGER: pointToPoint(3)
OSPF-MIB::ospfIfRtrPriority.10.0.0.2.0 = INTEGER: 0
OSPF-MIB::ospfIfRtrPriority.10.1.2.2.0 = INTEGER: 1
OSPF-MIB::ospfIfHelloInterval.10.2.5.2.0 = INTEGER: 10
OSPF-MIB::ospfIfRtrDeadInterval.10.2.5.2.0 = INTEGER: 40
OSPF-MIB::ospfIfState.10.0.0.2.0 = INTEGER: loopback(2)
OSPF-MIB::ospfIfState.10.1.2.2.0 = INTEGER: designatedRouter(5)
OSPF-MIB::ospfIfAuthType.10.0.0.2.0 = INTEGER: 0
OSPF-MIB::ospfIfAuthType.10.2.5.2.0 = INTEGER: 2
Observe que a interface com IP 10.0.0.2, não possui autenticação (ofpfIfAuthType = 0) 
156
 
O
SP
F 
Av
an
ça
do
Pelas saídas citadas, é possível identificar quais são as interfaces Loopback, Ponto a Ponto 
e Broadcast, além de saber quais possuem autenticação. Apenas usando o SNMP, o Enge-
nheiro da Rede pode consultar todos os roteadores OSPF e validar se as configurações estão 
corretas e de acordo com a Política de Segurança. Por exemplo, com um script de poucas 
linhas de código é possível ver que existem interfaces que não têm autenticação, oferecendo 
riscos à infraestrutura de rede.
Explorando a tabela ospfVirtIfTable
q 1 A tabela ospfVirtIfTable descreve as configurações relacionadas aos Virtual Links.
 1 A mesma só existe em roteadores que tem Virtual-Link ativado
 1 Exemplo da tabela a partir do roteador R5:
$ snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfVirtIfTable
OSPF-MIB::ospfVirtIfAreaId.0.0.0.2.10.0.0.4 = IpAddress: 0.0.0.2
OSPF-MIB::ospfVirtIfNeighbor.0.0.0.2.10.0.0.4 = IpAddress: 10.0.0.4
OSPF-MIB::ospfVirtIfHelloInterval.0.0.0.2.10.0.0.4 = INTEGER: 10
OSPF-MIB::ospfVirtIfRtrDeadInterval.0.0.0.2.10.0.0.4 = INTEGER: 40
OSPF-MIB::ospfVirtIfAuthType.0.0.0.2.10.0.0.4 = INTEGER: 0
 1 É possível ver a área de trânsito (0.0.0.2), o IP do neighbor (10.0.0.4- R4), valores de 
Hello e Dead Interval e se existe autenticação (0 significa sem autenticação).
A tabela ospfVirtIfTable descreve as configurações relacionadas aos Virtual Links e só existe 
em roteadores que têm Virtual-Link ativado. Na topologia da figura 4.7, existe um Virtual-Link 
entre R4 e R5. Observe o snmpwalk a seguir, onde a tabela ospfVirtIfTable foi consultada:
$ snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfVirtIfTable
OSPF-MIB::ospfVirtIfAreaId.0.0.0.2.10.0.0.4 = IpAddress: 0.0.0.2
OSPF-MIB::ospfVirtIfNeighbor.0.0.0.2.10.0.0.4 = IpAddress: 10.0.0.4
OSPF-MIB::ospfVirtIfHelloInterval.0.0.0.2.10.0.0.4 = INTEGER: 10
OSPF-MIB::ospfVirtIfRtrDeadInterval.0.0.0.2.10.0.0.4 = INTEGER: 40
OSPF-MIB::ospfVirtIfAuthType.0.0.0.2.10.0.0.4 = INTEGER: 0
É possível ver qual é a área de trânsito (ospfVirtIfAreaId) (Área 2 – 0.0.0.2), quem é o vizinho do 
Virtual-Link (ospfVirtIfNeighbor) (R4 – 10.0.0.4), se há autenticação (ospfVirtIfAuthType) 
(0 – não há) e valores de Hello (ospfVirtIfHelloInterval) e Dead Interval (ospfVirtIfRtrDeadInterval).
Explorando a tabela ospfNbrTable
q 1 A tabela ospfNbrTable descreve as vizinhanças estabelecidas pelo roteador OSPF
 1 Essa é uma das tabelas mais importantes
 1 Objetos mais importantes:
 2 ospfNbrIpAddr: informa o endereço IP da interface do vizinho OSPF
 2 ospfNbrRtrId: informa o Router-ID do vizinho OSPF
 2 ospfNbrPriority: informa a prioridade para escolha do DR. 
 2 spfNbrState: informa o estado de sincronismo do LSDB. Os estados possíveis são: 
down (1), attempt (2), init (3), twoWay (4), exchangeStart (5), exchange (6), 
loading (7) ou full (8). 
 1 O Engenheiro de Redes deve consultar frequentemente o objeto ospfNbrState e 
manter histórico de todas os valores passados para fins de resolução de problema.
157
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
A tabela ospfNbrTable descreve as vizinhanças estabelecidas pelo roteador OSPF. Essa é uma 
das tabelas mais importantes e que, se possível, deve ter seu monitoramento automatizado. 
Os objetos a seguir são extremamente úteis:
 1 ospfNbrIpAddr: informa o endereço IP da interface do vizinho OSPF; 
 1 ospfNbrRtrId: indica o Router-ID do vizinho OSPF; 
 1 ospfNbrPriority: informa a prioridade para escolha do DR. Se o valor é 0, não é elegível 
ou é Ponto-a-Ponto; 
 1 ospfNbrState: indica o estado de sincronismo do LSDB. Os estados possíveis são: down (1), 
attempt (2), init (3), twoWay (4), exchangeStart (5), exchange (6), loading (7) ou full (8). 
Caso a vizinhança não esteja em "full", a menos que seja uma adjacência entre roteadores 
DROthers, há um problema entre os dois roteadores.  
Observe a seguir o snmpwalk de R5 e R2. Os demais objetos foram omitidos para simplificar 
a visualização.
$ snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfNbrTable
OSPF-MIB::ospfNbrIpAddr.10.2.5.2.0 = IpAddress: 10.2.5.2
OSPF-MIB::ospfNbrIpAddr.10.4.5.4.0 = IpAddress: 10.4.5.4
OSPF-MIB::ospfNbrRtrId.10.2.5.2.0 = IpAddress: 10.0.0.2
OSPF-MIB::ospfNbrRtrId.10.4.5.4.0 = IpAddress: 10.0.0.4
OSPF-MIB::ospfNbrPriority.10.2.5.2.0 = INTEGER: 0
OSPF-MIB::ospfNbrPriority.10.4.5.4.0 = INTEGER: 1
OSPF-MIB::ospfNbrState.10.2.5.2.0 = INTEGER: full(8)
OSPF-MIB::ospfNbrState.10.4.5.4.0 = INTEGER: full(8)
$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfNbrTable
OSPF-MIB::ospfNbrIpAddr.10.1.2.1.0 = IpAddress: 10.1.2.1
OSPF-MIB::ospfNbrIpAddr.10.2.3.3.0 = IpAddress: 10.2.3.3
OSPF-MIB::ospfNbrIpAddr.10.2.4.4.0 = IpAddress: 10.2.4.4
OSPF-MIB::ospfNbrIpAddr.10.2.5.5.0 = IpAddress: 10.2.5.5
OSPF-MIB::ospfNbrRtrId.10.1.2.1.0 = IpAddress: 10.0.0.1
OSPF-MIB::ospfNbrRtrId.10.2.3.3.0 = IpAddress: 10.0.0.3
OSPF-MIB::ospfNbrRtrId.10.2.4.4.0 = IpAddress: 10.0.0.4
OSPF-MIB::ospfNbrRtrId.10.2.5.5.0 = IpAddress: 10.0.0.5
OSPF-MIB::ospfNbrPriority.10.1.2.1.0 = INTEGER: 1
OSPF-MIB::ospfNbrPriority.10.2.3.3.0 = INTEGER: 1
OSPF-MIB::ospfNbrPriority.10.2.4.4.0 = INTEGER: 1
OSPF-MIB::ospfNbrPriority.10.2.5.5.0 = INTEGER: 0
OSPF-MIB::ospfNbrState.10.1.2.1.0 = INTEGER: full(8)
OSPF-MIB::ospfNbrState.10.2.3.3.0 = INTEGER: full(8)
OSPF-MIB::ospfNbrState.10.2.4.4.0 = INTEGER: full(8)
OSPF-MIB::ospfNbrState.10.2.5.5.0 = INTEGER: full(8)
 qExemplo da tabela ofpfNbrTable a partir de R2:
OSPF-MIB::ospfNbrIpAddr.10.1.2.1.0 = IpAddress: 10.1.2.1
OSPF-MIB::ospfNbrIpAddr.10.2.3.3.0 = IpAddress: 10.2.3.3
OSPF-MIB::ospfNbrIpAddr.10.2.4.4.0 = IpAddress: 10.2.4.4
OSPF-MIB::ospfNbrIpAddr.10.2.5.5.0 = IpAddress: 10.2.5.5
OSPF-MIB::ospfNbrRtrId.10.1.2.1.0 = IpAddress: 10.0.0.1
158
 
O
SP
F 
Av
an
ça
do
qOSPF-MIB::ospfNbrRtrId.10.2.3.3.0 = IpAddress: 10.0.0.3
OSPF-MIB::ospfNbrRtrId.10.2.4.4.0 = IpAddress: 10.0.0.4
OSPF-MIB::ospfNbrRtrId.10.2.5.5.0 = IpAddress: 10.0.0.5
OSPF-MIB::ospfNbrPriority.10.1.2.1.0 = INTEGER: 1
OSPF-MIB::ospfNbrPriority.10.2.3.3.0 = INTEGER: 1
OSPF-MIB::ospfNbrPriority.10.2.4.4.0 = INTEGER: 1
OSPF-MIB::ospfNbrPriority.10.2.5.5.0 = INTEGER: 0
OSPF-MIB::ospfNbrState.10.1.2.1.0 = INTEGER: full(8)
OSPF-MIB::ospfNbrState.10.2.3.3.0 = INTEGER: full(8)
OSPF-MIB::ospfNbrState.10.2.4.4.0 = INTEGER: full(8)
OSPF-MIB::ospfNbrState.10.2.5.5.0 = INTEGER: full(8)
Observe que todas as vizinhanças estão no estado "full".
O Engenheiro de Redes deve consultar frequentemente o objeto ospfNbrState e manter 
histórico de todas os valores passados para fins de resolução de problema.
Explorando a tabela ospfAreaAggregateTable
q 1 A tabela ospfAreaAggregateTable descreve as rotas sumarizadas pelo roteador OSPF
 1 Caso não exista rota sumarizada, a tabela não será criada.
 1 Principais objetos:
 2 ospfAreaAggregateAreaID: informa a área associada à sumarização. 
 2 ospfAreaAggregateLsdbType: informa o tipo de sumarização sendo executado. 
Pode ser summaryLink (3) ou nssaExternalLink (7). 
 2 ospfAreaAggregateNet: informa o prefixo sumarizado;
 2 ospfAreaAggregateMask: informa a máscara de sub-rede do prefixo sumarizado.
A tabela ospfAreaAggregateTable descreve as rotas sumarizadas pelo roteador OSPF. Como 
é uma funcionalidade opcional, caso o roteador não esteja fazendo sumarização, a tabela 
não será criada e, quando consultada, apresentará o seguinte erro:
$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfAreaAggregateTable
OSPF-MIB::ospfAreaAggregateTable = No Such Object available on this agent at this OID
Na topologia da figura 4.7, R4 está fazendo sumarização via comando area range:
router ospf
 area 2 range 192.168.2.0 255.255.255.0
Nesse caso, a tabela ospfAreaAggregateTable está sendo criada e tem como principais objetos:
 1 ospfAreaAggregateAreaID: informa a área associada à sumarização. No caso de R4, é a 
Área 2 (0.0.0.2); 
 1 ospfAreaAggregateLsdbType: informa o tipo de sumarização sendo executado. Pode 
ser summaryLink (3) ou nssaExternalLink (7). Como em R4 foi feito com o comando area 
range, é do tipo LSA Summary; 
 1 ospfAreaAggregateNet: informa o prefixo sumarizado; 
 1 ospfAreaAggregateMask: informa a máscara de subrede do prefixo sumarizado. 
159
 
C
ap
ítu
lo
 4
 - 
O
tim
iz
aç
ão
 e
 tó
pi
co
s 
av
an
ça
do
s 
A seguir, observe a saída do snmpwalk de R4. É possível ver o prefixo 
192.168.2.0/255.255.255.0 sendo sumarizado.
$ snmpwalk -v 2c -c public 10.0.0.4 OSPF-MIB::ospfAreaAggregateTable
OSPF-MIB::ospfAreaAggregateAreaID.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = 
IpAddress: 0.0.0.2
OSPF-MIB::ospfAreaAggregateLsdbType.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = 
INTEGER: summaryLink(3)
OSPF-MIB::ospfAreaAggregateNet.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = 
IpAddress: 192.168.2.0
OSPF-MIB::ospfAreaAggregateMask.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0= 
IpAddress: 255.255.255.0
 qEm R4 foi aplicado o seguinte comando:
router ospf
 area 2 range 192.168.2.0 255.255.255.0
Observe a saída do snmpwalk em R4:
$ snmpwalk -v 2c -c public 10.0.0.4 OSPF-MIB::ospfAreaAggregateTable
OSPF-MIB::ospfAreaAggregateAreaID.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = 
IpAddress: 0.0.0.2
OSPF-MIB::ospfAreaAggregateLsdbType.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 
= INTEGER: summaryLink(3)
OSPF-MIB::ospfAreaAggregateNet.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = 
IpAddress: 192.168.2.0
OSPF-MIB::ospfAreaAggregateMask.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = 
IpAddress: 255.255.255.0
Nesta última parte foram apresentados os objetos e as tabelas mais comumente utilizadas, 
porém outros objetos estão documentados na RFC 4750. Além disso, a RFC 4750 especifica 
como fazer configurações OSPF via SNMP, por isso a importância de configurações seguras.
q 1 Neste material, foram apresentados apenas os objetos principais. Mais objetos estão 
disponíveis na RFC 4750
 1 Além disso, a RFC 4750 especifica como fazer configurações usando SNMP. É possível 
adicionar uma interface ou criar uma área OSPF via SNMP.
 1 Por isso, garanta que está usando uma community complexa, se possível usando 
SNMPv3 e com Listas de Controle de Acesso filtrando os prefixos de origem.
 1 É importante ter essas medições integradas com algum software de gerência de rede, 
até para registrar o histórico das saídas. 
Mas não basta apenas monitorar pontualmente: é importante que essas consultas sejam 
integradas com algum sistema de gerência de rede, como Nagios, Cacti ou Zabbix, para que 
sejam criados históricos. A configuração dessa integração está fora do escopo desse material, 
uma vez que existe vasta documentação desses softwares.
Na sessão de Atividades Práticas, o aluno será instruído como preparar um ambiente e fazer 
testes na linha de comando para obter as informações desejadas.
160
 
O
SP
F 
Av
an
ça
do
Conclusão
Nesta sessão, foram apresentados alguns tópicos que podem auxiliar o Engenheiro de Redes 
na implantação de redes OSPF de larga escala. Tópicos de escalabilidade e convergência foram 
apresentados; porém, alguns deles são relativamente novos e não são suportados por todos 
os fabricantes. Mas, conforme foi apresentado, muitos deles são compatíveis com a versão 
padrão do OSPF definida na RFC 2328, o que permite uma implementação gradual.
 
Comandos OSPF
A seguir, uma lista de comandos de configuração que têm relação com o tema da sessão 4. 
Os comandos a seguir são aplicados na sessão de OSPF do roteador.
 1 Habilita o ISPF no processo OSPF:
ispf
 1 Habilita e define o tempo de expiração do Grace LSA:
nsf ietf restart-interval <0-1800>
 1 Habilita BFD em todas as interfaces OSPF:
bfd all-interfaces
 1 Habilita supressão dos prefixos de todas as redes de trânsito do roteador OSPF:
prefix-suppresion
Os comandos a seguir são aplicados na configuração das interfaces do roteador.
 1 Configura os temporizadores do processo BFD na interface:
bfd interval VALOR min_rx VALOR multiplier NUMERO
 1 Habilita BFD no processo OSPF da interface:
ip ospf bfd
 1 Habilita supressão de prefixos na interface OSPF:
ip ospf prefix-suppression
Os comandos a seguir são aplicados no modo de configuração global do roteador.
 1 Habilita o processo SNMP server no roteador com a comunidade estabelecida:
snmp-server community <NOME_DA_COMMUNITY>
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 ope-
racionais, 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êmi-
cas 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.
 
avançada do protocolo OSPF em Redes TCP/IP de grande 
porte. São estudados os pacotes OSPF e a sua utilização. 
São descritas as áreas OSPF e as suas características. 
São apresentadas as técnicas de Engenharia de Tráfego 
processo de escolha de rotas do OSPF. São descritos 
os métodos de otimização do OSPF. O curso garante ao 
-
ção avançada do protocolo OSPF na rede de sua institui-
ção. Este livro inclui os roteiros das atividades práticas 
e o conteúdo dos slides apresentados em sala de aula, 
-
mento em suas organizações ou localidades de origem.
LI
VR
O 
DE
 A
PO
IO
 A
O 
CU
RS
O
02 5
630025
	OSPFAvançado
	Sumário
	Escola Superior de Redes
	A metodologia da ESR
	Sobre o curso 
	A quem se destina 
	Convenções utilizadas neste livro
	Permissões de uso
	Sobre os autores
	1. Funcionamento do banco de nulldados do OSPF
	Entendendo o funcionamento do banco de dados do OSPF
	Tipos de pacotes OSPF
	Pacotes Hello
	Formato do pacote Hello
	Responsabilidades do protocolo Hello
	Processo de eleição dos roteadores Designated Router e Backup 
Designated Router
	Database Description – DD
	Link State Request ou LSR
	Link State Update ou LSU
	Link State Acknowledgement ou LSAck
	Transição de Estados no Sincronismo do OSPF
	Link State Advertisement ou LSA
	Router LSA
	Network Summary LSA e ASBR Summary LSA
	AS External LSA
	NSSA External LSA
	Remoção de LSAs
	Conclusão
	Comandos OSPF
	2. Entendendo as áreas do OSPF
	Por que o OSPF faz uso do conceito de áreas?
	Quais são os tipos de áreas e como elas se comportam em 
um ambiente OSPF
	Área Backbone
	Área Normal
	Área Stub
	Área Not-So-Stubby ou NSSA
	Interconectando áreas com Virtual Links
	Entendendo o LSDB
	A: Observando o funcionamento do LSDB na Área Backbone
	A1: Router-LSA e Network-LSA
	A.2: Summary-LSA
	A.3: AS External LSA
	A.4: ASBR Summary LSA
	A.5: NSSA-LSA
	A.6: Virtual Links
	Conclusão
	Comandos OSPF
	3. Engenharia de tráfego com OSPF
	Introdução
	Sumarização de rotas
	Agregação de rotas
	Métricas
	Escolha de caminhos pelo OSPF
	Observe o LSDB de R1 a seguir.
	Controlando atualizações de roteamento
	Interfaces Passivas (Passive Interfaces)
	Rotas padrão
	Filtrando prefixos
	Lista de Controle de Acesso (Access Control List: ACL)
	Lista de Prefixos (Prefix-List)
	Listas de Distribuição (Distributed Lists)
	Mapas de Rotas (Route-Maps)
	Filtragem de prefixos Intra-Área OSPF
	Agregação de LSAs AS-External
	 Comandos OSPF
	4. Otimização e tópicos avançados
	Introdução
	Escalabilidade e Estabilidade do OSPF
	Incremental OSPF
	Propriedade 1
	Propriedade 2
	Propriedade 3
	Graceful Restart
	BFD para OSPF
	Supressão de Prefixos
	Monitorando o OSPF com a RFC 4750: OSPF Version 2 MIB
	Explorando a tabela ospfGeneralGroup (Variáveis Globais)
	Explorando a tabela ospfAreaTable
	Explorando a tabela ospfStubAreaTable
	Explorando a tabela ospfLsdbTable
	Explorando a tabela ospfHostTable
	Explorando a tabela ospfIfTable
	Explorando a tabela ospfVirtIfTable
	Explorando a tabela ospfNbrTable
	Explorando a tabela ospfAreaAggregateTable
	Conclusão
	Comandos OSPF