OSPF Avançado PDF

OSPF
Avançado
Jerônimo Aguiar Bezerra

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
(MCTI) e responsável pelo
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.
OSPF
Avançado

OSPF
Avançado
Rio de Janeiro
Escola Superior de Redes
2016
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

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
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
Sumário
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
iii
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
iv
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
v
vi
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 para as
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.
vii
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:
66 Descrever o funcionamento do OSPF

66 Descrever os tipos de pacotes OSPF
66 Descrever quais são e como são utilizados os LSA (Link State Advertisements)
66 Descrever quais são os estados possíveis de um roteador OSPF
66 Distinguir os tipos de áreas existentes
66 Projetar e justificar quais tipos de área deseja utilizar
66 Entender o porquê de cada estado de cada banco de dados por área
66 Entender as técnicas de Engenharia de Tráfego com OSPF
66 Entender e configurar ajustes finos avançados no OSPF
viii
66 Entender o processo de escolha de rotas do OSPF
66 Entender Incremental OSPF
66 Entender Graceful Restart
66 Configurar BFD para OSPF
66 Configurar Supressão de Prefixos
66 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.
ix
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.
x
1
Funcionamento do banco de
dados do OSPF
objetivos
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
conceitos
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

11 OSPF está definido na RFC 2328 (atualmente usa-se a versão 2 para IPv4 q
e versão 3 para IPv6).
11 Funcionamento se baseia em um banco de dados topológico.
11 Existe apenas um banco de dados topológico por área (chamado de Link-State

Database ou LSDB).
11 Todos os roteadores da área têm de ter o mesmo LSDB.
Capítulo 1 - Funcionamento do banco de

dados do OSPF
11 Banco de dados criados a partir da troca de mensagens Link State Advertisements (LSAs).
11 Roteadores enviam LSAs com informações de enlaces conectados e seus custos.
11 Algoritmo SPF utilizado para calcular as rotas.
11 Cinco tipos de pacotes OSPF existem para fazer a troca das mensagens LSA.
O funcionamento do protocolo OSPF se baseia no banco de dados topológico (ou Link-State

Database – LSDB), criado com informações dos enlaces de todos os roteadores que fazem
SPF – Short Path First
parte da mesma área hierárquica, ou seja, todos os roteadores de cada área precisam
Ou algoritmo de
manter um banco de dados síncrono para garantir o roteamento adequado dos pacotes IP.
Dijkstra. Criado por
Edsger Dijkstra É através desse banco de dados topológico que o processo do OSPF calcula o menor
em 1956. 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".
1
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

Sincronização do banco de dados OSPF ocorre a partir de cinco pacotes OSPF: q
11 Hello.
11 DD: database Description.
11 LSR: link State Request.
11 LSU: link State Update.
11 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).
Todos os cinco pacotes OSPF contêm um cabeçalho comum de 24 bytes (sem autenti- q
cação com MD5) ou 40 bytes (com autenticação com MD5):
OSPF Avançado
2
32 bits
8 bits 8 bits 8 bits 8 bits
Versão=2 Tipo Tamanho do Pacote
Router ID
Area ID
Checksum Tipo de Autenticação
Autenticação
Figura 1.1
Cabeçalho OSPF Autenticação
compartilhado.
Os campos estão detalhados a seguir:
11 Versão: para o protocolo IPv4, a versão atual do protocolo OSPF é a versão 2; para IPv6 é
a versão 3;
11 Tipo: identifica um dos cinco pacotes OSPF (Hello (1), DD(2), LSR(3), LSU(4), LSAck(5));
11 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;
11 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;
11 Area ID: identifica a área OSPF;
11 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;
11 Tipo de Autenticação: informa qual esquema de autenticação está sendo utilizado. Pode
assumir os seguintes valores:
22 0: Sem autenticação;
22 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;
Figura 1.2
Informações de 22 2: Autenticação criptográfica. Nesse caso, os dois campos Autenticação assumem o
Criptografia do seguinte formato:

dados do OSPF
cabeçalho OSPF
para MD5. Os
dois campos 0x0000 Key ID Tamanho
Autenticação viram
Número de Sequência Criptográﬁco
novos campos.
33 Key ID: identifica a chave a ser utilizada (várias chaves são possíveis na configu-
ração OSPF);
33 Tamanho: tamanho da mensagem criptográfica (digest). Esse tamanho não está

incluso no tamanho informado anteriormente no campo Tamanho do Pacote;
33 Número de Sequência Criptográfico: utilizado para evitar ataques do tipo Replay,

por isso fica sempre incrementando.
22 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.
3
32 bits
Versão=2 Tipo Tamanho do Pacote
Router ID
Area ID
Checksum Tipo de Autenticação
0x0000 Key ID Tamanho
Número de Sequência Criptográﬁco
Digest MD5 Figura 1.3

Cabeçalho OSPF
completo com
Autenticação MD5.
11 Pacotes OSPF usam o protocolo IP com TTL de “1”; q

11 IP de origem do pacote OSPF é sempre o IP da interface conectada à área, não o
Router-ID;
11 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
Pacotes Hello possuem diversas funções: q
11 Descobrir roteadores OSPF adjacentes.
11 Estabelecer adjacências com esses roteadores.
11 Manter as adjacências.
11 Detectar falhas de enlaces e roteadores.
11 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em

OSPF Avançado
redes tipo Broadcast e NBMA.
11 Utiliza o grupo Multicast AllSPFRouters (224.0.0.5) em redes Broadcast e NBMA.
4
Relembrando: O OSPF pode funcionar em três tipos diferentes de rede:
11 Redes Ponto-a-Ponto: conecta um par de roteadores;
11 Redes Broadcast: suportam múltiplos roteadores e endereço IP que

representam todos os roteadores da rede (endereço Broadcast);
11 Redes Non-Broadcast: suportam múltiplos roteadores, mas não suportam

broadcast. No contexto do OSPF, podem ser operadas de duas maneiras:
22 Simulação de uma rede Broadcast na rede Non-Broadcast, denominada

non-broadcast multi-access ou NBMA;
22 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:
11 Descobrir roteadores OSPF adjacentes;
11 Estabelecer adjacências com esses roteadores;
11 Manter as adjacências;
11 Detectar falhas de enlaces e roteadores;
11 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”.

dados do OSPF
5
32 bits
Tipo=1
Cabeçalho OSPF
Máscara de sub-rede
Intervalo Hello Opções Prioridade
Intervalo de Roteador Morto
Designated Router
Backup Designated Router
Vizinhos Ativos
Figura 1.4
... Pacote Hello com
o cabeçalho OSPF
Vizinhos Ativos simplificado.
Os campos estão detalhados a seguir:
11 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;
11 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;
11 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:
22 E-bit: descreve como os LSA AS-External são anunciados na rede;
22 MC-bit : descreve se os datagramas IP multicast são enviados de acordo com a RFC

1584 (Multicast OSPF);
22 N/P bit: esse bit descreve como manipular os LSAs do Tipo 7;
22 EA bit: descreve o interesse do roteador para receber e encaminhar LSA

External-Attributes;
22 DC bit: descreve se o roteador manipula circuitos sob demanda.
11 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;
OSPF Avançado
11 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;
6
11 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;
11 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;
11 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

11 Protocolo Hello é utilizado para descobrir e estabelecer as adjacências. q
11 As adjacências OSPF são iniciadas logo após um roteador OSPF detectar outro na rede.
11 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.
Figura 1.5 R3 R4
Topologia de 10.1.1.0/24
Exemplo para
exemplificar a
funcionamento do s1/0 s0/0
protocolo Hello.
11 Nesse exemplo, ambos os roteadores estão configurados na Área Backbone ou q

Área 0.0.0.0;
11 Pacotes Hello são enviados;

dados do OSPF
11 Primeiro pacote não possui o campo “Vizinho Ativo” (Active Neighbor);
11 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:
7
Cabeçalho comum:
11 OSPF Version: 2;
11 Type: 1 (Pacote Hello);
11 Packet Length: 44 (24 bytes do cabeçalho OSPF mais 20 bytes do pacote Hello);
11 Source OSPF Router ou Router ID: 10.1.1.2 (IP da interface);
11 Area ID: 0.0.0.0, conhecida como Área Backbone;
11 Auth Type: null, ou seja, sem autenticação.
Pacote Hello:
11 Network Mask: 255.255.255.0 (pois a rede é 10.1.1.0/24);
11 Hello Interval: (intervalo entre os Hellos): 10 segundos;
11 Router Priority: 1;
11 Router Dead Interval: 40 segundos;
11 Designated Router: 0.0.0.0 (enlace serial não tem DR);
11 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.
R4 envia o primeiro pacote Hello: q

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
Figura 1.6
Router Dead Interval: 40 seconds Captura do
Designated Router: 0.0.0.0 primeiro pacote
Hello enviado
Backup Designated Router: 0.0.0.0
por R4.
Após receber o pacote Hello vindo de R4 (10.1.1.2), o R3 envia um pacote Hello, conforme
OSPF Avançado
figura 1.7.
11 R3 envia seu primeiro pacote Hello, porém após receber o Hello do R4 (nesse exemplo); q
11 Campo Vizinho Ativo ou Active Neighbor é preenchido a partir do Hello do roteador R4;
8
OSPF Header
OSPF Version: 2
Packet Length: 48
Source OSPF Router: 10.1.1.1 (10.1.1.1)
Packet Checksum: 0xd695 [correct]
Auth Type: Null
Auth Data (none)
OSPF Hello Packet
Router Priority: 1
Router Dead Interval: 40 seconds
Figura 1.7
Captura do pacote Designated Router: 0.0.0.0
Hello de R3 (Source Backup Designated Router: 0.0.0.0
OSPF Router:
Active Neighbor: 10.1.1.2
10.1.1.1

OSPF Header
OSPF Version: 2
Packet Length: 48
Packet Checksum: 0xd695 [correct]
Auth Type: Null
Auth Data (none)
OSPF Hello Packet

dados do OSPF
Router Priority: 1
Figura 1.8
Captura do pacote Designated Router: 0.0.0.0
Hello de R4 agora Backup Designated Router: 0.0.0.0
informando ter Active Neighbor: 10.1.1.1
visto R3.
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:
9
11 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);
11 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).
11 Observe os campos Packet Length: por que mudou? q

11 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
11 Redes Broadcast e NBMA precisam ter um DR e um BDR por questões q
de escalabilidade.
11 Roteadores da área somente vão sincronizar com o DR.
11 Três tipos de roteadores OSPF na área:
22 Designated Router (DR).
22 Backup Designated Router (BDR).
22 DR Others (DROther).
11 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:
11 Designated Router (DR);
11 Backup Designated Router (BDR);
11 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-
OSPF Avançado
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.
10
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 R2
f0/0
f0/0
SW1
1 2
3 10.1.0.0/24
f0/0
Figura 1.9
Rede tipo
Broadcast. 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

dados do OSPF
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;
11
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.
11 Roteadores, ao entrarem na rede, verificam se já há um DR e/ou um BDR: q

22 Checam os campos Designated Router e Backup Designated Router do pacote Hello;
11 Caso positivo, aceitam a escolha;
11 No exemplo, não existem outros roteadores, então iniciam da forma normal;
11 Enviam pacotes Hello sem o campo Active Neighbors;
11 Campos Designated Router e Backup Designated Router preenchidos com 0.0.0.0;
11 Ao receber um pacote Hello, campo Active Neighbors passa a conter o IP do roteador

remoto;
11 Processo de escolha do BDR é iniciado. Depende de quem tiver maior Router Priority.
Desempate com o maior endereço IP;
22 Roteadores com Router Priority 0 não são elegíveis;
11 Após escolha do BDR, processo de escolha do DR é iniciado;
22 Mesmos critérios de desempate do processo do BDR;
11 DR e BDR não mudam mesmo que outro roteador tenha prioridade maior;
22 Evita instabilidade na rede;
11 BDR só assume no momento em que o DR fica inativo;
11 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.
OSPF Avançado
12
OSPF Header
OSPF Version: 2
Packet Length: 48
Packet Checksum: 0xc490 [correct]
Auth Type: Null
Auth Data (none)
OSPF He11o Packet
Router Priority: 1
Designated Router: 10.1.0.2
Figura 1.10
Backup Designated Router: 10.1.0.1
R2 escolhido como
DR, R1 como BDR. 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
11 Após os roteadores OSPF tornarem-se adjacentes, os bancos de dados topológicos q
precisam ser sincronizados;
11 Pacotes Database Description são utilizados para esta atividade;

dados do OSPF
11 Pacotes DD são os pacotes OSPF do Tipo “2”
11 Database Exchange Process é iniciado:
22 Eleição Master/Slave;
22 Envio dos cabeçalhos LSA;
22 Verificação do aging para descobrir se o LSA é mais novo ou não;
22 Caso verifique que não está atualizado, uma lista de cabeçalhos LSA é criada para
solicitar o LSA completo no próximo passo;
22 Utiliza endereçamento Unicast em redes Broadcast e NBMA e endereçamento

Multicast em redes ponto a ponto.
13
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).
32 bits
Tipo=2
Cabeçalho OSPF
MTU Opções 00000 I M Ms

Figura 1.11
Pacote Database
Número de Sequência
Description.
Cabeçalhos LSA Também usa o
cabeçalho OSPF.
11 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;
11 Options: mesmas opções definidas no pacote Hello;
11 Bit I (Initial): caso esteja marcado com “1”, indica que esse é o primeiro pacote DD da
sequência de sincronismo;
11 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;
11 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;
11 Número de Sequência: utilizado pelo Master para definir o sequenciamento dos pacotes DD;
11 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
OSPF Avançado
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.
14
OSPF Header OSPF Header
OSPF version: 2 OSPF version: 2
Message Type: DB Description (2) Message Type: DB Description (2)
Packet Length: 32 Packet Length: 32
Source OSPF Router: 10.1.0.1 (10.1.0.1) Source OSPF Router: 10.1.0.2 (10.1.0.2)
Area ID: 0.0.0.0 (Backbone) Area ID: 0.0.0.0 (backbone)
Packet checksum: 0x8386 [correct] Packet checksum: 0x7f27 [correct]
Auth Type: Null Auth Type: Null
Auth Data (none) Auth Data (none)
OSPF DB Description OSPF DB Description
Interface MTU: 1500 Interface MTU: 1500
Options: 0x52 (O, L, E) Options: 0x52 (O, L, E)
DB Description: 0x07 (I, M, MS) DB Description: 0x07 (I, M, MS)
.... 0... = R: OOBResync bit is NOT set .... 0... = R: OOBResync bit is NOT set
.... .1.. = I: Init bit is SET .... .1.. = I: Init bit is SET
.... ..1. = M: More bit is SET .... ..1. = M: More bit is SET
.... ...1 = MS: Master/Slave bit is SET .... ...1 = MS: Master/Slave bit is SET
DD Sequence: 6258 DD Sequence: 7376
Figura 1.12 Na figura 1.12 é possível observar que ambos os roteadores R1 (10.1.0.1) e R2 (10.1.0.2)
Database Exchange enviam o pacote DD informando serem Masters do processo. Cada um envia seu próprio
Process: eleição
do Master. número de sequência (R1 envia 6258 e R2 envia 7376).
Figura 1.13 Na figura 1.13., o roteador R1 envia o pacote com o bit M/S configurado para “0”, indicando
Database Exchange ser o Slave da relação. No mesmo pacote R1 já envia o número de sequência recebido do R2
Process: início
da troca de (7376) e os cabeçalhos dos LSAs que estão no seu banco de dados (a explicação sobre LSA
pacotes DD. se dará mais à frente).

OSPF version: 2 OSPF version: 2
Area ID: 0.0.0.0 (Backbone) Area ID: 0.0.0.0 (backbone)

dados do OSPF
Packet checksum: 0x7ffe [correct] Packet checksum: 0x7f27 [correct]
DB Description: 0x02 (M) DB Description: 0x07 (I, M, MS)
.... .0.. = I: Init bit is NOT SET .... .1.. = I: Init bit is SET
.... ..1. = M: More bit is SET .... ..1. = M: More bit is SET
.... ...0 = MS: Master/Slave bit is NOT SET .... ...1 = MS: Master/Slave bit is SET
LSA Header
15
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: version: 2 OSPF: version: 2
Area ID: 0.0.0.0 (Backbone) Area ID: 0.0.0.0 (Backbone)
Packet checksum: 0x7f2e [correct] Packet checksum: 0x8fe9 [correct]
DB Description: 0x00 DB Description: 0x03 (M, MS)
.... .0.. = I: Init bit is NOT set .... .0.. = I: Init bit is NOT set
.... ..0. = More bit is NOT set .... ..1. = M: More bit is SET
.... ...0 = MS: Master/Slave bit is NOT set .... ...1 = MS: Master/Slave bit is SET
LSA Header
Após isso, R2 envia mais um pacote DD com o bit M configurado como “0” e um novo Figura 1.14
número de sequência (7378), indicando o fim do processo, e R1 confirma com um pacote DD Database Exchange
Process – R2
com o mesmo número. Agora, de posse dos cabeçalhos LSAs existentes no roteador remoto, enviando
ambos os roteadores enviarão pacotes OSPF chamados Link State Request, solicitando os seus LSAs.
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

11 Após o Database Exchange Process, os roteadores OSPF têm uma lista com LSAs que q
precisam ser solicitados.
11 A solicitação dos LSAs acontece via pacote OSPF Link State Request ou LSR.
11 Pacote OSPF do Tipo 3.
11 Também faz uso do cabeçalho OSPF, assim como o Hello e o DD.
11 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
OSPF Avançado
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.
16
32 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
Figura 1.15
Pacote Link Advertising Router n
State Request.
11 Tipo do LSA: identifica o tipo do LSA (os tipos estão listados na tabela 1.1);
11 ID do LSA: varia de acordo com o tipo do LSA;
11 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

dados do OSPF
Packet Checksum: 0xdfd0 [correct]
Auth Type: Null
Figura 1.16
Pacote LSR saindo Auth Data (none)
de R2 para R1. Link State Request
Nesse caso, R2 está Link-State Advertisement Type: Router-LSA (1)
solicitando o LSA
que tem os campos Link State ID: 10.1.0.1
circulados na figura. 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.
17
Link State Update ou LSU
11 Recebido o Link State Request, o roteador OSPF receptor verifica no seu banco de q
dados e responde com um pacote Link State Update.
11 O Link State Update é o pacote OSPF Tipo “4”.
11 O pacote pode ser enviado por Unicast ou Multicast.
11 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:
11 Um pacote LSU via Unicast para o solicitante;
11 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
Tipo=4
Cabeçalho OSPF
Número de LSAs
Figura 1.17
Pacote Link State
LSAs Update. Apenas
dois campos
adicionados.
11 Número de LSAs: informa a quantidade de LSAs que estão sendo enviados nesse pacote;
11 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.
OSPF Avançado
18
OSPF Header
OSPF Version: 2
Message Type: LS Update (4)
Packet Length: 64
Source OSPF Router : 10.1. 0.1 (10.1. 0.1)
Packet Checksum: 0xe898 [correct]
Auth Type: Null
Auth Data (none)
LS Update Packet
Figura 1.18 Number of LSAs: 1
Resposta do R1 ao LS Type: Router-LSA
LSR de R2.
Os tipos e o conteúdo dos LSAs serão apresentados no item "Link State Advertisement ou LSA".
Link State Acknowledgement ou LSAck

11 Depois de enviado o LSU, o roteador OSPF precisa da confirmação do roteador q
remoto que esse recebeu o pacote enviado.
11 A confirmação pode se dar de duas maneiras:
22 O receptor envia um pacote LSU com o mesmo conteúdo de volta para o originador.
22 O receptor gera um pacote Link State Acknowlegdement e envia para o originador.
11 Pacote Link State Acknowledgement ou LSAck possui o Tipo “5”.
11 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.
32 bits

dados do OSPF
Tipo=5
Cabeçalho OSPF
Figura 1.19 Cabeçalhos LSAs

Pacote Link State
Acknowledgement.
19
É 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
Packet Checksum: 0x6b41 [correct]
Auth Type: Null
Figura 1.20
Auth Data (none) LSAck do R2
LSA Header para R1.
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.
11 Após todos os LSA serem trocados e confirmados, os roteadores entram no q

estado FULL;
11 Nesse estado, o algoritmo SFP faz o cálculo das rotas para serem inseridas no roteador;
11 Só haverá novos LSU/LSAck em caso de alterações no estado de algum enlace:
22 Enlace inativo, queda de circuito, queda de roteador etc.;
11 Caso o LSA não seja atualizado por 30 minutos, o roteador deve anunciá-lo nova-
mente para os roteadores da área:
22 Garantir que os bancos de dados estão sincronizados;
22 Esse tempo é chamado de LSRefreshTime e é fixo;
22 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

OSPF Avançado
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.
20
R1 R2
DOWN DOWN
HELLO (DR=0, Vizinhos=0)
HELLO (DR=R2, Vizinhos=R1) INIT
ExStart D-D (Seq =X, I, M, Master)
D-D (Seq =Y, l, M, Master) ExStart
Exchange D-D (Seq =Y, M, Slave)
D-D (Seq =Y+1, l, M, Master) Exchange
D-D (Seq =Y+1, M, Slave)
(...)
D-D (Seq =Y+n, Master)
D-D (Seq =Y+n, Slave)
Loading
LS Request Full
LS Update
LS Request
Figura 1.21 LS Update
Transição de
estados OSPF. Full
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 Capítulo 1 - Funcionamento do banco de
dados do OSPF
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;
21
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 alguns fabricantes) 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.
11 Em redes Broadcast e NBMA, esse processo ocorre entre o roteador OSPF q

(DROther)e o DR;
22 Entre os DROthers, o maior estado é o ExStart;
11 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

11 Link State Advertisement é a estrutura de dados responsável por armazenar as infor- q
mações sobre os estados de enlaces;
22 Endereço IP, máscara de sub-rede, métrica etc.;
11 Pacotes OSPF DD e LSR usam apenas o cabeçalho; pacote LSU usa o LSA completo;
11 Através das informações no LSA é que o roteador faz os cálculos para definir as rotas;
11 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.
OSPF Avançado
22
Código Nome Quem faz uso? Descrição Definição
1 Router LSA Todos Descreve o ambiente RFC2328

do roteador, inter-
faces, métricas
2 Network LSA DR Informa todos os RFC2328

roteadores na rede
Broadcast/NBMA
3 Network Summary ABRs Anuncia rotas de RFC2328

LSA outra área do OSPF
4 ASBR Summary LSA ABRs Anuncia a rota para RFC2328

chegar no roteador
ASBR
5 AS external LSA ASBRs Anuncia rota de fora RFC2328

do AS
6 Group Membership - Usado para Multicast RFC1584

LSA OSPF
7 NSSA External LSA ASBRs em NSSA Anuncia rota de fora RFC3101

do AS
8 External Attributes - Possível substituto Pendente

LSA do iBGP
9 Opaque LSA - Usado em MPLS RFC5250
10 Opaque LSA - Usado em MPLS RFC5250

Tabela 1.1
Lista dos tipos 11 Opaque LSA - Usado em MPLS RFC5250
de LSA.
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.
32 bits
Age Opções Tipo
Link-State ID

dados do OSPF
Advertising Router
Figura 1.22
Cabeçalho LSA Sequence Number
utilizado por todos
os tipos de LSA. Checksum Tamanho
11 Age (Tempo de vida): tempo em segundos desde que o LSA foi gerado;
11 Opções: mesmas definições do campo de Opções do protocolo Hello;
11 Tipo: identifica o Tipo do LSA;
11 Link-State ID: conteúdo dependente do Tipo do LSA. Será detalhado à frente;
11 Advertising Router: router-ID do roteador que originou o LSA;
11 Sequence Number: utilizado como controle de versão do LSA;
23
11 Checksum: utilizado para garantir integridade. Não inclui o campo Age;
11 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
11 Router LSA é utilizado para informar os roteadores adjacentes com informações q
como Router-ID, enlaces locais e métricas de saída.
11 Esse é o primeiro LSA enviado pelo roteador OSPF;
11 Contém todas as informações de todos os enlaces que o roteador possui;
11 Todas as informações de estado de enlace enviadas em apenas um LSA;
11 É o LSA Tipo “1”;
11 Todos os roteadores OSPF enviam LSAs do tipo Router LSA;
11 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.
32 bits
Age Opções Tipo = 1
Link-State ID
Advertising Router
Sequence Number
Checksum Tamanho
00000 V E B 0x00 Número de Links
Link ID
Link Data
Tipo de Link Número TOS Métrica

Figura 1.23
TOS 0x00 Métrica TOS
Router LSA.
A seguir, os campos do Router LSA são apresentados:
11 Bit V (Virtual): informa se o roteador é a ponta de um Virtual Link;
11 Bit E (External): indica que o roteador originador é um ASBR;

OSPF Avançado
11 Bit B (Border): indica que o roteador originador é um ABR;
11 Número de Links: número de enlaces incluídos no LSA.
24
Os campos a seguir são utilizados para descrever cada enlace do roteador. Cada enlace
possui um tipo.
11 Link ID: identifica o objeto ao qual o enlace se conecta. Valor depende do campo Tipo de Link;
11 Link Data: conteúdo depende do Tipo de Link;
11 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;
11 Número TOS: não utilizado;
11 Métrica: custo do enlace;

Tabela 1.2
Router LSA: 11 TOS: não utilizado, mantido por compatibilidade com o OSPFv1;
tipos de Link.
11 Métrica TOS: não utilizado, mantido por compatibilidade com o OSPFv1.
Tipo de Tipo de Conexão Descrição Valor do Link Valor do Link Data

Link ID
1 Ponto a Ponto Uma conexão para outro roteador Router-ID do IP da interface do

Vizinho roteador originador
2 Rede de Trânsito Carrega tráfego de trânsito IP da interface IP da interface do

do DR roteador originador
3 Rede Stub Deve carregar pacotes tendo o Prefixo da IP da Rede Stub ou

Router-ID como origem ou destino Rede IP Máscara de Rede
4 Virtual Link Usado por virtual links Router-ID do Valor of Ifindex do

Vizinho Virtual
11 A partir do Tipos de Link, o valor dos campos Link ID e Link Data podem mudar q
A utilização dos campos da tabela 1.2 será apresentada na sessão de aprendizagem 2,
“Áreas OSPF”, bem como exemplos.
Network LSA
11 LSA tipo “2”; q
11 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;
11 Essa informação é utilizada para saber quais roteadores estão na mesma sub-rede e

dados do OSPF
calcular as rotas entre eles;
11 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 na figura 1.24. É possível verificar que este é
mais simples que o Router LSA.
25
32 bits
Link-State ID
Advertising Router
Sequence Number
Checksum Tamanho
Máscara de Sub-rede
Roteador Ativo
Figura 1.24
Roteador Ativo Network LSA.
Os campos são preenchidos da seguinte maneira:
11 Link-State ID: endereço IP da interface do DR na área;
11 Máscara de Sub-rede: máscara de sub-rede da interface do DR conectada à área;
11 Roteador Ativo: router-ID dos roteadores com os quais o DR possui adjacência.
Network Summary LSA e ASBR Summary LSA

11 Network Summary LSA é o Tipo “3”. q
11 ASBR Summary LSA é o Tipo “4”.
11 Ambos são utilizados apenas pelos ABR: Area Border Router:
22 Network Summary LSA é utilizado para enviar as rotas entre áreas.
22 ASBR Summary LSA é utilizado para informar o endereço IP dos roteadores ASBR:
Autonomous System Boundary Routers.
11 O formato dos campos é o mesmo, porém o preenchimento varia nos seguintes campos:
22 Tipo.
22 Link-State ID.
22 Máscara de Sub-rede.
11 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,
OSPF Avançado
ambos os campos Link-State ID e Máscara de Sub-rede são preenchidos com o valor 0.0.0.0.
26
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.
32 bits
Age Opções Tipo = 3 ou 4
Link-State ID
Advertising Router
Sequence Number
Checksum Tamanho
0x00 Métrica
Figura 1.25
Network ou ASBR TOS Métrica TOS
Summary LSA.
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
11 LSA Tipo “5”. q
11 Utilizado para enviar rotas externas ao AS ou externas ao processo OSPF.
11 É enviado para todas as áreas, menos para as áreas Stub e NSSA.
11 AS External LSA não possuem relação com nenhuma área e por isso são transpor-
tados intactos entre áreas.
22 Daí a necessidade do ASBR Summary LSA (Tipo “4”) para ajudar os roteadores a
localizarem o ASBR.
11 Possui dois tipos de rotas externas:
22 Tipo “1”: além do custo externo, adiciona o custo interno da rede para alcançar o

dados do OSPF
ASBR.
22 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:
11 Link-State ID: prefixo IP da rota a ser anunciada;
11 Máscara de Sub-rede: máscara de sub-rede do prefixo IP a ser anunciado;
27
11 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.
11 Métrica: custo da rota;
11 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;
11 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.
32 bits
Link-State ID
Advertising Router
Sequence Number
Checksum Tamanho
E 0000000 Métrica
Endereço
Endereçode
deEncaminhamento
Encaminhamento
Tag da Rota Externa
E TOS Métrica TOS
Endereço de Encaminhamento TOS

Figura 1.26
Tag da Rota Externa TOS AS External LSA.
NSSA External LSA

11 LSA Tipo “7”. q
11 Também é criado pelo ASBR, quando este está em uma área Not-so-Stub-Area.
11 Mesmo cabeçalho do AS External LSA, porém preenchimento diferente no campo

Endereço de Encaminhamento.
11 Por padrão, o NSSA External LSA é traduzido para AS External LSA nos ABRs.
OSPF Avançado
28
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.
32 bits
Link-State ID
Advertising Router
Sequence Number
Checksum Tamanho
E 0000000 Métrica
Endereço
Endereçode
deEncaminhamento
Encaminhamento
Tag da Rota Externa
E TOS Métrica TOS
Endereço de Encaminhamento TOS

Figura 1.27
NSSA External LSA. Tag da Rota Externa TOS
O campo Endereço de Encaminhamento pode assumir um dos seguintes valores:
11 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;
11 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
11 A remoção de um LSA do LSDB pode ocorrer devido a dois fatores: q
dados do OSPF
22 LSA aging atinge o MaxAge.
22 Acontece alguma alteração topológica na rede.
11 Alterações topológicas na rede incluem:
22 Enlace que muda de estado (de UP para DOWN ou DOWN para UP).
22 Roteador adicionado ou removido da rede.
11 Em caso de mudança de estado, duas ações podem fazer a remoção de um LSA do LSDB.
22 Expiração da adjacência detectada pelo protocolo Hello.
22 Envio de LSU com o LSA atualizado.
11 A Figura 1.28 mostra uma topologia onde a expiração via protocolo Hello aconteceria.
11 A figura 1.29 mostra uma topologia onde o envio de um LSU acontece.
29
Conforme mencionado anteriormente, uma vez no estado FULL, os roteadores OSPF não
enviam novas atualizações de estado de enlace a menos que:
11 O aging do LSA atinje o LSRefreshTime (30 minutos);
11 Haja alguma alteração topológica na rede.
Alterações topológicas na rede incluem:
11 Enlace que muda de estado (de UP para DOWN ou DOWN para UP);
11 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:
11 Expiração da adjacência detectada via protocolo Hello;
11 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 R2
f0/0
f0/0
SW1
1 2
3 10.1.0.0/24
f0/0
Figura 1.28
R3 Rede Broadcast.
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
OSPF Avançado
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.
30
a. F0/0 10.1.2.0/24 F0/0 F0/1 10.2.3.0/24 F0/0
.1 .2 .1 .2
R1 R2 R3
b. F0/0 10.1.2.0/24 F0/0 F0/1 10.2.3.0/24 F0/0

Figura 1.29
Rede Broadcast .1 .2 .1 .2
com momentos LSU + LSA
A e B. R1 R2 R3
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:
11 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;
11 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.

dados do OSPF
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.
31
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.
11 Altera o tempo em segundos entre pacotes Hello (padrão de 10 segundos):
ip ospf hello-interval <1-65535>

11 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
11 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>

11 Configura o tipo de rede OSPF:
ip ospf network <broadcast|non-broadcast|point-to-multipoint|point-to-point>

11 Define a prioridade no processo de escolha do DR/BDR. 0 significa não elegível:
ip ospf priority <0-255>

11 Configura autenticação simples:
ip ospf authentication-key SENHA

11 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:
11 Exibe informações sobre o processo OSPF:
show ip ospf

11 Exibe informações resumidas sobre o banco de dados OSPF:
show ip ospf database

11 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>

11 Exibe informações sobre o processo OSPF em uma determinada interface:
show ip ospf interfaces

11 Exibe as adjacências OSPF estabelecidas:

OSPF Avançado
show ip ospf neighbor
32
2
Entendendo as áreas do OSPF
objetivos
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.
conceitos
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?

11 LSDB precisa ser idêntico em todos os roteadores da rede. q
11 Redes muito grandes possuem LSDB muito grandes.
22 Aumenta o consumo de memória e CPU.
22 Diminui o tempo de convergência da rede.
11 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.
Capítulo 2 - Entendendo as áreas do OSPF
Para que 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
33
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.
11 Especificação do OSPF permite o particionamento da rede: Áreas; q

11 Áreas são utilizadas para criar redes OSPF menores;
11 Topologia da área é transparente para as demais áreas;
11 Com LSDB menor, menos recursos computacionais são necessários;
11 Cada área no ABR possui um LSDB separado;
11 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.
11 Para fazer a interconexão entre áreas, o roteador ABR é utilizado: q

22 LSAs Router e Network ficam confinados por área;
22 LSA Summary é gerado para permitir a alcançabilidade da rede.
11 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
OSPF Avançado
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.
34
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
11 As RFCs 2328 e 3101 definem a criação das seguintes áreas OSPF: q
22 Área Backbone.
22 Área Não Backbone.
33 Área "Normal".
33 Área Stub.
33 Área Not-So-Stubby.
22 Virtual-Links.
A RFC 2328 possui as definições das principais áreas atualmente suportadas pelo OSPF.
São elas:
11 Área 0 ou Backbone: área principal do OSPF, conecta todos os ABRs;
11 Á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:
11 Área Normal: área OSPF que se conecta à Área Backbone e suporta todos os tipos de LSAs;
11 Á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.
35
R1
R3 Área Backbone R6
Rede 1
R2 R5
Rede 3
Rede 2
R4
Área 2 R7
Área 3
R8
Área 4
Internet
BGP
R11
R9 R10
Rede 4 Rede 5 Rede 6
Figura 2.1
Área Backbone Rede OSPF com
11 Conhecida como Área 0 ou Área 0.0.0.0. É o núcleo da rede. q Diversas Áreas.
11 Responsável por interconectar todas as demais áreas.
11 Não pode ser particionada.
11 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
OSPF Avançado
interfaces em diversas áreas.
36
Área Normal
11 Aceita LSAs Externos. q
11 Não faz trânsito.
11 Roteadores com perfis similares.
11 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
11 Área Stub q
11 Usada quando
22 Roteadores com recursos computacionais limitados
22 Apenas um ABR por área
11 Opção de LSA-Summary gerado pelo ABR com a rota padrão
11 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.
37
Á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.
11 Área Not-So-Stubby q
22 Criada na RFC 3101
22 Comportamente similar a Área Stub porém permite redistribuição
22 Prefixos externos são redistribuídos com LSA External-NSSA
22 ABR converte de External-NSSA para AS External LSA
Interconectando áreas com Virtual Links

11 Evitar o particionamento da Área Backbone. q
11 Utilizado para reconectar área que desconectou da Área Backbone via outra Área.
11 OSPF trata o Virtual Link como uma rede ponto-a-ponto unnumbered.
11 Funcionalidade de uso temporário.
11 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
OSPF Avançado
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).
38
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.
l Ou seja, a Área 3 ficaria desconectada da rede mesmo que R4 tivesse um enlace de backup via
NVirtual Links não Rede 3. Nesse caso, a solução é criar um Virtual Link entre R3 e R4 via Área 2. Esse Virtual Link
podem ser criados via seria tratado como uma extensão da Área Backbone, desfazendo o particionamento criado
Área Stub.
pela mudança de estado do enlace entre R4 e R5. A nova topologia ficaria igual à figura 2.2.
R3 Área Bac
Rede 3
VL
R4
Área 2
Área 3
R8
Figura 2.2
Virtual Link entre
R4 e R3.
É 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.
39
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ão vamos
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.
R2 R5
Área 2 Normal Área Área 3
Backbone NSSA
5.5.5.5/32
R1 R4
10.1.2.0/24 10.2.4.0/24 10.4.5.0/24
10.5.7.0/24
R7
1.1.1.1/32
R3 R6
10.1.3.0/24 10.3.4.0/24 10.4.6.0/24
Área 4 6.6.6.6/32
Stub
A seguir, detalhes da topologia: Figura 2.3

Rede OSPF
11 Existem seis roteadores OSPF (R1 até R6) e um roteador não OSPF (R7); Multi-Área.
11 As conexões entre roteadores são feitas por enlaces Ethernet;
11 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;
11 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;
11 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;
11 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;
11 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;
OSPF Avançado
11 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;
11 Em R5 há uma rota estática apontando para a Loopback de R7;
40
11 Em R7 há uma rota padrão apontando para a interface de R5;
11 As conexões entre R1 e R3 e R3 e R4 terão custo alterado para 64;
11 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
11 Roteadores R2, R3 e R4 compõem a Área Backbone. q
11 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
11 É 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:

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

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.
41
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

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
TOS 0 Metric: 10
Detalhamento do Router-LSA gerado pelo Roteador R2: q

LS age: 1119
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x1 : ABR
LS Type: router-LSA
Checksum: 0x8b60
Length: 48
Number of Links: 2
OSPF Avançado
TOS 0 Metric: 10
TOS 0 Metric: 10
42
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:
11 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”);
11 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):

LS age: 250
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x3
Flags: 0x3 : ABR ASBR
LS Type: router-LSA
Checksum: 0x6c1e
Length: 60
Number of Links: 4

TOS 0 Metric: 10
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 3.3.3.3
TOS 0 Metric: 64
(Link ID) Net: 10.3.4.0
43
TOS 0 Metric: 64
TOS 0 Metric: 10

LS age: 250
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x3
Flags: 0x3 : ABR ASBR
LS Type: router-LSA
Checksum: 0x6c1e
Length: 60
Number of Links: 4
TOS 0 Metric: 10
Continuação:

TOS 0 Metric: 64
(Link ID) Net: 10.3.4.0
TOS 0 Metric: 64
TOS 0 Metric: 10
OSPF Avançado
44
É 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:
11 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
11 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;
11 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;
11 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:

LS age: 222
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x1 : ABR
LS Type: router-LSA
Checksum: 0xfd3c
Length: 60
Number of Links: 3
45
TOS 0 Metric: 10
TOS 0 Metric: 64
(Link ID) Net: 10.3.4.0
TOS 0 Metric: 64

LS age: 222
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x1 : ABR
LS Type: router-LSA
Checksum: 0xfd3c
Length: 60
Number of Links: 3
TOS 0 Metric: 10
TOS 0 Metric: 64
(Link ID) Net: 10.3.4.0
OSPF Avançado
TOS 0 Metric: 64
46
É 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).
Observe as 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:

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
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

LS age: 79
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x3
LS Type: network-LSA
Link State ID: 10.2.4.4 (address of Designated Router)
Checksum: 0x27f6
Length: 32
Network Mask: /24
Attached Router: 2.2.2.2
47
Detalhamento do Network-LSA gerado pelo Roteador R4: q
R4# show ip ospf database network
LS age: 79
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x3
LS Type: network-LSA
Checksum: 0x27f6
Length: 32
Network Mask: /24
É 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.
11 Observe que o LSDB da Área Backbone não possui nenhum Network-LSA que inclua o q
roteador R3, e R3 não está na lista de Attached Router;
11 Isso acontece porque R3 tem seus enlaces configurados como Ponto-a-Ponto, logo
não há DR ou BDR;
11 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.
11 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
OSPF Avançado
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):
48
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
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
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
10.1.2.2 2.2.2.2 1562 0x80000001 0x1324
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
49
Observe que o ABR R3 possui um LSDB por área e cada área possui seus LSAs do tipo q
Summary:
R3# sh ip ospf database summary

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
LSAs do Tipo Summary da Área 2:
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:
11 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;
11 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-
OSPF Avançado
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:
11 Enviar para os roteadores de outras áreas (R5 e R6);

50
11 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.
11 Em casos onde uma Área OSPF possui apenas um roteador ABR, por exemplo, as q
Áreas 3 e 6, o Engenheiro de Redes pode optar por enviar ou não os LSAs do tipo
Summary recebidos de outros ABRs;
11 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):

Router Link States (Area 0.0.0.4 [Stub])
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])
10.4.6.6 6.6.6.6 6 0x80000004 0x6995
Summary Link States (Area 0.0.0.4 [Stub])
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
Roteador R4 configurado para criar a Área 4 como Stub: q


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
51
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):

Router Link States (Area 0.0.0.4 [Stub])
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])
10.4.6.6 6.6.6.6 242 0x80000002 0x6d93
0.0.0.0 4.4.4.4 253 0x80000002 0x1934 0.0.0.0/0
Roteador R4 configurado para criar a Área 4 como Stub com o parâmetro no-summary: q
router ospf
area 4 stub no-summary
0.0.0.0 4.4.4.4 253 0x80000002 0x1934 0.0.0.0/0
11 Com o parâmetro no-summary, o ABR gera uma rota padrão para a Área 4;
11 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:

LS age: 831
Options: 0x0 : *|-|-|-|-|-|-|*
LS Flags: 0x6
LS Type: summary-LSA
OSPF Avançado
Link State ID: 0.0.0.0 (summary Network Number)

52
Checksum: 0x1934
Length: 28
Network Mask: /0
TOS: 0 Metric: 1
A seguir o LSA Summary com a rota padrão: q

LS age: 831
Options: 0x0 : *|-|-|-|-|-|-|*
LS Flags: 0x6
Link State ID: 0.0.0.0 (summary Network Number)
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

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)
53
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 Seq Number: 8000000a
Checksum: 0x046d
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
11 Roteador R5 faz redistribuição de uma rota estática (7.7.7.7/32) e da sua interface q

Loopack (5.5.5.5/32);
11 Rotas redistribuídas são anunciadas com LSAs do tipo AS-External ou NSSA, depen-
dendo da Área;
11 Á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;
11 ABR da Área 3 converte para LSA AS-External e envia para a Área Backbone;
11 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
OSPF Avançado
prefixo é o roteador R5, porém, esse está em uma área NSSA.
54
11 LSA AS-External em R1; q
11 Prefixo 5.5.5.5/32.

LS age: 324
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0x6417
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
11 LSA AS-External em R1;
11 Prefixo 7.7.7.7/32.
LS age: 330
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0x046d
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
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:

LS age: 18
Options: 0x2 : *|-|-|-|-|-|E|*
55
LS Flags: 0x6
Checksum: 0x5f57
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
Observe como o LSA AS-External é criado em uma Área não NSSA: q

LS age: 18
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0x5f57
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
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
OSPF Avançado
pelos ABRs.
56
A.4: ASBR Summary LSA
Já que os roteadores OSPF devem preservar 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

ASBR-Summary Link States (Area 0.0.0.2)
LS age: 770
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Link State ID: 4.4.4.4 (AS Boundary Router address)
Checksum: 0xbe74
Length: 28
Network Mask: /32
TOS: 0 Metric: 10
LS age: 1130
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0xa28d
Length: 28
Network Mask: /32
TOS: 0 Metric: 10
Como R4 gerou LSAs do tipo AS-External, um LSA do tipo ASBR-Summary precisa ser q
criado. Observe como R1 aprende o caminho para 4.4.4.4 via R2 (2.2.2.2).

LS age: 770
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
57
LS Seq Number: 80000008 q
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
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:

LS age: 749
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0x57ee
Length: 28
Network Mask: /32
TOS: 0 Metric: 10
LS age: 749
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
OSPF Avançado

58
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

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)
Checksum: 0xbfb4
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
NSSA: Forward Address: 10.4.5.5
LS age: 2
Options: 0xa : *|-|-|-|N/P|-|E|*
LS Flags: 0x6
LS Type: NSSA-LSA
Checksum: 0x5f0b
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
59
Como R5 fez redistribuição na Área 3, que é uma Área NSSA, os prefixos redistribuídos q
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

NSSA-external Link States (Area 0.0.0.3 [NSSA])
LS age: 125
Options: 0xa : *|-|-|-|N/P|-|E|*
q
LS Flags: 0x6
LS Type: NSSA-LSA
Checksum: 0xbfb4
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
LS age: 2
Options: 0xa : *|-|-|-|N/P|-|E|*
LS Flags: 0x6
LS Type: NSSA-LSA
Checksum: 0x5f0b
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
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

OSPF Avançado
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.
60
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.
11 Vamos utilizar o endereço 2.2.2.2/32 como estudo de caso para Virtual Link; q
11 Interface Loopback de R2 está configurado como parte da Área Backbone;
11 Observe o LSDB em R4 com o registro do IP 2.2.2.2/32 (saída abreviada):
R4# show ip ospf database router

Flags: 0x1 : ABR
LS Type: router-LSA
(...)
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).

LS age: 103
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x1 : ABR
LS Type: router-LSA

Checksum: 0x8961
Length: 48
Number of Links: 2
TOS 0 Metric: 10
61
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
É possível ver que R4 possui adjacência com R2: q

2.2.2.2 1 Full/Backup 35.275s 10.2.4.2 eth0:10.2.4.4
* 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;
11 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;
11 Após a remoção do LSA, a rota é removida de R4:

% 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:

% 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.
OSPF Avançado
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.
62
Criação do Virtual Link entre R2 e R3: q
11 Configuração aplicada em R2:
router ospf
area 2 virtual-link 3.3.3.3
11 Configuração aplicada em R3:
router ospf
A seguinte configuração será aplicada em R2 para criar o Virtual Link:
router ospf
A seguinte configuração será aplicada em R3 para criar o Virtual Link:
router ospf
Observe a adjacência criada entre R2 e R3: q

3.3.3.3 1 Full/DROther 39.483s 10.1.3.3 VLINK0
A rota é então criada novamente em R4, apontando para R3:

* 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).


* 10.3.4.3, via eth1
Observe em R2 e R3 a adjacência utilizando o Virtual Link (VLINK0)

63
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.

LS age: 690
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x1 : ABR
LS Type: router-LSA
Checksum: 0x1c7e
Length: 60
Number of Links: 3
TOS 0 Metric: 10
TOS 0 Metric: 10
Link connected to: a Virtual Link
TOS 0 Metric: 20
Observe o Router LSA de R3 (10.1.3.3) informando o Virtual Link. q

(...)
TOS 0 Metric: 20
OSPF Avançado
64
A seguir observe como R4 agora possui um Router LSA originado por R2 com o registro Stub
da interface Loopback.

LS age: 895
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x1 : ABR
LS Type: router-LSA
LS Seq Number: 8000000d
Checksum: 0x578c
Length: 48
Number of Links: 2
TOS 0 Metric: 10
TOS 0 Metric: 20
Observe o Router LSA de R2 (2.2.2.2) informando o Virtual Link.

LS age: 895
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x1 : ABR
LS Type: router-LSA

(...)
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.
65
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.
11 Adiciona as interfaces que são parte do prefixo informado na Área Backbone:
network prefixo máscara área 0
11 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
11 Gera uma rota padrão em uma área Stub (utilizado no ABR):
area X.X.X.X stub no-summary

11 Origina uma rota padrão na rede OSPF:
Default-information originate [always] [metric METRICA] [metric-type 1|2]

11 Criar uma Área NSSA em um roteador interno:
network prefixo máscara área Z.Z.Z.Z

area Z.Z.Z.Z nssa
11 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
11 Redistribui rotas estáticas no OSPF:
redistribute static

11 Redistribui interfaces conectadas no OSPF:
redistribute connected

11 Redistribui rotas do protocolo RIP no OSPF:
redistribute rip metric 2

11 Cria um Virtual Link:

OSPF Avançado
area Area_Transito virtual-link Router_ID_ABR
66
A seguir, uma lista dos comandos de observação que têm relação com o tema da sessão de
aprendizagem 2.
11 Exibe informações sobre o processo OSPF:
show ip ospf

11 Exibe informações resumidas sobre o banco de dados OSPF:
show ip ospf database

11 Exibe informações detalhadas por LSA:
show ip ospf database <router|network|summary|asbr-summary|external|nssa-

external>

11 Exibe informações por tipo de LSA originado pelo roteador:
show ip ospf database self-originated

11 Exibe informações sobre o processo OSPF em uma determinada interface:
show ip ospf interfaces

11 Exibe as adjacências OSPF estabelecidas:
show ip ospf neighbor
67
68
OSPF Avançado
3
Engenharia de tráfego com OSPF
objetivos
Aprender sobre sumarização; Conhecer agregação de rotas; Entender como funciona

a manipulação de rotas; Conhecer sobre filtragem de prefixos.
conceitos
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
Capítulo 3 - Engenharia de tráfego com OSPF
11 Sumarização de rotas;
11 Áreas OSPF permitem que a topologia de uma área seja abstraída das demais áreas;
11 Roteadores ABR criam LSAs do tipo Summary para cada LSA do tipo Router e envia
para as demais Áreas OSPF.
22 Caso um LSA Router seja removido do LSDB, um LSA Summary é enviado infor-
mando da remoção;
22 Demais roteadores OSPF precisam recalcular as rotas;
22 Recursos computacionais são consumidos a cada incidente.
11 Existem otimizações possíveis.
69
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.
R4 Área 1 Área Backbone
192.168.0.0/24
R2
R5
LSA Summary
19
LSA Summary
2.1
192.168.1.0/24
68
LSA Summary
.7.
0/
19 LSA Summary
31
2.
16
R6 8.
7. LSA Summary
2/
31
ABR LSA Summary
192.168.2.0/24
192.168 LSA Summary
.7.4/31
LSA Summary
R7 LSA Summary
31
.7 .6/
.168 LSA Summary
192.168.3.0/24 192
1
LSA Summary
/3
12
7.
LSA Summary
8.
16
2.
LSA Summary
19
(. . .)
LSA Summary
R10
R3
192.168.6.0/24
A rede OSPF da figura 3.1 tem as seguintes características: Figura 3.1

Área 1 com
11 Duas áreas OSPF: Área Backbone e Área 1; configuração
padrão OSPF.
11 Um roteador ABR (Router-ID 10.1.2.1);
11 Sete roteadores OSPF internos na Área 1 (R4 até R10);
11 Sete enlaces saindo do ABR para os roteadores OSPF internos (com prefixos
OSPF Avançado
192.168.7.x/31);
11 Sete redes internas com prefixo 192.168.[0-6].0/24;
11 Além do roteador ABR, a Área Backbone possui outros dois roteadores OSPF (R2 e R3).
70
ABR vai criar um LSA Summary para cada LSA Router recebido: q
11 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.
11 R2 e R3 vão recalcular as rotas;
11 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;
11 Quando o enlace for restaurado, R2 e R3 vão recriar as rotas a partir dos LSAs recebidos.
Nessa topologia, para cada LSA 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):

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
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
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
71
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]
q

Para 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
OSPF Avançado
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
72
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):

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.8 10.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
73
11 Após a inserção do comando range, LSAs do tipo Summary são enviados com campo q
Age preenchido com MaxAge;
11 Roteadores OSPF removem os LSAs do tipo Summary;
11 Apenas um LSA Summary é mantido: aquele informado no comando range;
11 Por exemplo, usando a figura 36, em vez de 14 prefixos na tabela de rotas e no LSDB,
apenas um existirá:

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:

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.
OSPF Avançado
74
R4 Área 1 Área Backbone
192.168.0.0/24
R2
R5
19
2.1
192.168.1.0/24
68
.7.
0/
19
31
2.
16
R6 8.
7.
2/
31
ABR
192.168.2.0/24
192.168
.7.4/31
LSA Summary – 192.168.0.0/20
R7
/31
68 .7.6
192.1
192.168.3.0/24
1
/3
12
7.
8.
16
2.
19
(. . .)
R10
R3
192.168.6.0/24
Figura 3.2 É importante salientar que a sumarização só acontece com duas condições:
Rede OSPF com
Sumarização. 11 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;
11 A sumarização só acontece para LSA Router, não para LSA AS-External.
Importante salientar: q
11 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;
11 A sumarização só acontece para LSA Router, não para LSA AS-External.
75
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.
Três questões podem ser levantadas por quem está vendo essa abordagem pela q
primeira vez:
11 Se R2 e R3 enviarem os pacotes para ABR mesmo que a rede esteja indisponível, isso
não vai sobrecarregar o ABR desnecessariamente?
11 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?
11 Qual é a métrica que ficará associada ao LSA Summary configurado?
Agregação de rotas
11 Também é possível otimizar e agregar prefixos oriundos de LSAs do Tipo AS-External. q
11 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.
OSPF Avançado
router ospf
summary-address prefixo máscara [tag TAG]
76
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.
R4 External Área Backbone
192.168.0.0/24
R2
R5 19
2.1
192.168.1.0/24
68
.7.
0/
19
31
2.
16
R6 8.
7.
2/
31
ASBR
192.168.2.0/24
192.168
.7.4/31
R7
/31
8.7.6
.16
192.168.3.0/24 192
1
/3
12
7.
8.
16
2.
19
(. . .)
R10
R3
192.168.6.0/24
Figura 3.3 Apesar de ser semelhante à topologia da figura 3.1, o roteador ABR foi substituído pelo
Redistribuição e roteador ASBR, e não há adjacências OSPF entre ASBR e os roteadores R4 até R10. ASBR tem
Agregação.
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 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
77
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
11 O roteador ASBR não possui adjacências OSPF com os roteadores R4 a R10; q

11 Uma rota estática é criada para cada rede interna;
11 Rotas Estáticas são redistribuídas no processo OSPF;
11 Roteadores R2 e R3 recebem quatorze LSAs do tipo AS-External:
22 Todos apontam para o ASBR;
22 Não existe alternativa de caminho.
As configurações dessa topologia podem 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

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
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
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]
OSPF Avançado
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]
78
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:

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:

192.168.0.0 10.1.2.1 34 0x80000001 0x381e E2 192.168.0.0/20 [0x0]

O>* 192.168.0.0/20 [110/20] via 10.1.2.1, eth0, 00:03:04
11 Após receber os 14 LSAs do tipo AS-External, 14 rotas são criadas por R2 e R3; q
11 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;
11 Um LSA AS-External com o valor agregado será enviado e apenas uma rota será
criada em R2 e R3.
79
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
11 Cálculo das Rotas utiliza as métricas ou custos das interfaces. q
11 Rotas com menores custos são escolhidas.
11 Custo padrão de cada interface no Quagga é definida a partir da equação:
22 Custo padrão = 100Mbps/(Largura de Banda da Interface).
11 Como interfaces com mais capacidade que 100Mbps estão disponíveis, Engenheiro de
Redes pode:
22 Usar o comando de interface ip ospf cost VALOR por interface com o valor desejado.
22 Usar o comando do OSPF auto-cost reference-bandwidth VALOR.
33 O comando auto-cost muda o custo de todas as interfaces do roteador.
11 Comando ip ospf cost VALOR é útil para configurações customizadas ou enlaces

virtuais com capacidade menor que a capacidade da interface física.
11 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
OSPF Avançado
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>
80
Por exemplo, caso deseje trabalhar com interfaces 10GigabitEthernet, aplique o seguinte
comando:
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:
11 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;
11 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

11 Com o particionamento, várias Áreas OSPF são possíveis. q
11 Protocolo OSPF faz diferenciação de rotas a partir das origens:
22 Rotas Intra-Área: geradas na própria área.
22 Rotas Inter-Área: gerada em outra área OSPF.
22 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:
11 Rotas Intra-Área: são aquelas geradas dentro da área da qual o roteador OSPF faz parte;
11 Rotas Inter-Área: aquelas geradas dentro de outra área OSPF e foi recebida do roteador ABR;
11 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.
81
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).
R1 R2
Área Backbone
1
Área 1
100 2
R3
Figura 3.4
Escolha de
3.3.3.3/24 Caminhos.
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
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
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.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?
OSPF Avançado
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.

82
Observe o LSDB de R1 a seguir.

1.1.1.1 1.1.1.1 905 0x80000006 0x6aa0 2
2.2.2.2 2.2.2.2 906 0x80000005 0x7c82 2
10.1.2.2 2.2.2.2 906 0x80000001 0x1324
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
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
10.1.3.3 3.3.3.3 906 0x80000001 0x121b
10.2.3.3 3.3.3.3 906 0x80000001 0x28ff
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:
83
R1# show ip ospf database route adv-router 3.3.3.3
LS age: 1023
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x0
LS Type: router-LSA
Checksum: 0x3126
Length: 60
Number of Links: 3
TOS 0 Metric: 100
TOS 0 Metric: 2
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.

OSPF Avançado
4. Externa do Tipo 1: AS-External.
5. Externa do Tipo 2: AS-External-NSSA.
6. Externa do Tipo 2: AS-External.
84
11 Prioridades para o processo de escolha de rota q
22 Intra-Área
22 Inter-Área
22 Externa do Tipo 1 - AS-External-NSSA
22 Externa do Tipo 1 - AS-External
22 Externa do Tipo 2 - AS-External-NSSA
22 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.
R1 R2
Área Backbone
4 2
R3
Figura 3.5
ECMP. 3.3.3.3/24
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.

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.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.
85
Controlando atualizações de roteamento
11 Sistemas Autônomos tendem a possuir diversas configurações e complexidades, q
envolvendo diversos tipos de enlaces e protocolos, múltiplos IGPs que requerem
configurações extras para garantir a otimização.
11 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:
11 Passive Interfaces (Interfaces Passivas);
11 Rotas Padrão;
11 Filtrando Prefixos.
22 Distributed Lists (Listas de Distribuição);
22 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)

11 Interfaces Passivas ou Passive Interfaces podem ser utilizadas para dar mais flexibili- q
dade nas configurações OSPF.
11 Com Interfaces Passivas, as rotas geradas são tratadas como Intra-Área.
11 Com o comando redistribute, as rotas geradas são tratadas como rotas Externas.
11 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).
OSPF Avançado
86
Área 2
R2
R4 R1
Área Backbone
eth1
Internet 10.0.0.0/24
eth0
R3
Área 1
Figura 3.6 Na topologia da figura 3.6, o roteador OSPF R1 está conectado à Área Backbone, e uma das
Interfaces Passivas. 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ção da 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
87
Para transformar uma interface em passiva, basta utilizar o comando a seguir: q
router ospf
! Habilite a interface da maneira tradicional com comando network
network IP area Área
! Transforme em interface passiva
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.
OSPF Avançado
88
É possível transformar todas as interfaces do roteador em passivas com um único comando. q
router ospf
! Transforma todas as interfaces em passivas
! Transforma interface eth0 em ativa
no passive-interface eth0
network 0.0.0.0/0 area 0.0.0.0
Rotas padrão
11 Rota padrão ou default route é um recurso útil para economia de recursos q
dos roteadores.
11 Gerado pelos ABRs em áreas Stub quando o comando no-summary é inserido.
11 Útil quando existe apenas um roteador de saída do Sistema Autônomo.
11 Pode ser gerada pelo processo OSPF.
22 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).
89
R2
R4 R1
Área Backbone
Internet 10.0.0.0/24
R3
R6 R5
Área 1 Stub
Figura 3.7
Rota Padrão.
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 Avançado
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
!
90
11 Na topologia da figura 3.7, há apenas um roteador BGP e uma saída; q
11 Roteadores OSPF precisam de informações para enviar pacotes para fora do Sistema
Autônomo;
11 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:
11 Redistribuir os prefixos BGP dentro do processo OSPF;
11 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]
Comando a seguir pode ser utilizado para gerar a rota padrão: q

router ospf
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

B>* 0.0.0.0/0 [20/0] via 11.0.0.1, eth0, 00:11:20
q
Rota 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
91
Parâmetros opcionais: q
11 always: origina a rota padrão, mesmo que não exista uma no roteador;
11 metric-type: define o tipo de métrica para o LSA AS-External: tipo 1 ou 2. O tipo padrão
é 2;
11 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

LS age: 799
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0xcaeb
Length: 36
Network Mask: /0
TOS: 0
Metric: 10
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:
11 always: origina a rota padrão, mesmo que não exista uma no roteador;
11 metric-type: define o tipo de métrica para o LSA AS-External: tipo 1 ou 2. O tipo padrão é 2;
11 metrica: define o custo da rota. O custo padrão é 10.
Filtrando prefixos
11 Filtragem de prefixos são necessárias para customizar a manipulação de prefixos na q
rede OSPF;
11 Engenheiro de redes pode decidir por não enviar prefixos entre áreas – ou mesmo
não instalar rotas de acordo com as necessidades locais;
11 Diversas ferramentas estão à disposição no Quagga:
22 Lista de Controle de Acesso ou ACL;

OSPF Avançado
22 Lista de Prefixos;
22 Lista de Distribuição;
22 Mapas de Rotas.
92
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)

11 Listas de Controle de Acesso (ou ACL) são utilizadas normalmente para filtragem de q
pacotes de usuários;
11 Também servem para marcar prefixos antes da tomada de ação pelo roteador;
11 Não permite remoção de apenas uma entrada ou reordenamento;
11 Podem ser configuradas de três maneiras diferentes:
22 ACL Padrão: numeradas com valores 1-99 e 1300-1999: access-list NÚMERO

(deny|permit) (A.B.C.D|Any) [Wildcard]
22 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)
22 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. Capítulo 3 - Engenharia de tráfego com OSPF
Lista de Prefixos (Prefix-List)

11 Lista de Prefixos é uma evolução das ACL, possuindo número de sequência e opções q
de range, como le (menor-igual) e ge (maior-igual).
11 Permite que apenas uma entrada seja removida.
11 Permite reorganização ou resequenciamento.
11 Pode ser configurada da seguinte maneira:
22 ip prefix-list NOME seq <NÚMERO> (deny|permit) A.B.C.D/M [ge <0-32>] [le <0-32>]
93
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)

11 Listas de Distribuição permitem que filtragens de entrada e saída sejam aplicadas por q
interface e por protocolo de roteamento.
11 Mesmo pacotes gerados pelo roteador podem ser filtrados.
11 Utiliza ACL para selecionar os prefixos a serem filtrados ou liberados.
11 Podem ser configuradas da seguinte maneira:
22 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)

11 Mapa de Rotas é um ferramenta extremamente poderosa para não só selecionar q
prefixos, mas também executar edições ou ações.
11 Possui diversos tipos de filtragem, através do comando match.
11 Possui diversos tipos de edições, através do comando set.
11 Possui número de sequência para fácil ordenamento e remoção.
11 Pode ser configurado da seguinte maneira:
22 Para criar um mapa de rotas com nome NOME e número de sequência:
33 route-map NOME (deny|permit) <número sequência 1-65535>
22 Para buscar por prefixos especificados pela ACL (nome ou número):
33 match ip address
22 Para buscar pelo tag do LSA AS-External ou NSSA:
33 match tag
22 Para configurar o custo com VALOR específico:
33 set metric
OSPF Avançado
22 Para configurar o LSA AS-External ou NSSA com tipo específico:
33 set metric-type <tipo 1 | tipo 2| internal | external>
22 Para colocar uma tag no LSA AS-External ou NSSA:
33 set tag
94
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).
Figura 3.8
Filtragens de
Prefixos.
R7 R3
Área 1
R1
R8
R6
Área Backbone
Internet
10.0.0.0/24
R9
R2
R5 R4
95
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:
11 11.0.0.0/16: IPs dos servidores que são acessados pela internet;
11 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:

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.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>* 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
OSPF Avançado
* via 10.8.9.9, eth1, 00:08:06
96
Mesmo com a instrução de que os prefixos da rede 11.1.0.0/16 não deveriam ser q
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

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.2.4.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45
* via 10.8.9.9, eth1, 00:03:45
97
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>* 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
O comando range apresentado anteriormente possui uma opção que faz o inverso: em q
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
É possível fazer o mesmo filtro com Lista de Prefixos. q

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

OSPF Avançado
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 regra permite todos os
outros prefixos.
98
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:

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
O comando range e a Lista de Prefixos, após serem aplicados, criam LSAs do Tipo q
Summary solicitando a remoção do prefixo. Observe o LSDB de R8:

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


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.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
99
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
OSPF Avançado
permitidos pela Lista de Prefixos serão aceitos. Observe a tabela de rotas do roteador R2:
R2# sh ip route
100
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.9.0/24 [110/10] is directly connected, eth2, 1d00h16m
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
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

LS age: 754
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Flags: 0x0
LS Type: router-LSA
101
Checksum: 0xe84c
Length: 108
Number of Links: 7
TOS 0 Metric: 10
TOS 0 Metric: 10
TOS 0 Metric: 10
TOS 0 Metric: 10
TOS 0 Metric: 10
(Link ID) Net: 11.0.29.0
TOS 0 Metric: 10
(Link ID) Net: 11.1.30.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
OSPF Avançado
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.
102
Executando Filtragem de Prefixos Intra-Área: q
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.
R4 External Área Backbone
192.168.0.0/24
R2
R5
19
2.1
192.168.1.0/24
68
.7.
0/
19
31
2.
16
R6 8.
7.
2/
31
ASBR
192.168.2.0/24
192.168
.7.4/31
R7
31
.7 .6/
.168
192.168.3.0/24 192
1
/3
12
7.
8.
16
2.
19
(. . .)
R10
R3
192.168.6.0/24
103
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
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
OSPF Avançado
104
Passo 5: confirme o resultado nos demais roteadores da Área Backbone:

LS age: 339
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0x3420
Length: 36
Network Mask: /20
TOS: 0
Metric: 20
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.
Usando Mapas de Rotas para fazer agregação de LSAs do tipo AS-External: q

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:
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.
105
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 comandos a seguir são aplicados na sessão de OSPF do roteador.
11 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]
11 Gera uma agregação de LSAs do tipo AS-External na rede OSPF:
summary-address PREFIXO MÁSCARA [tag TAG]
11 Muda o custo de referência das interfaces OSPF:
auto-cost reference-bandwidth <1-4294967>
11 Coloca uma interface no modo passivo do OSPF:
11 Coloca todas as interfaces do roteador no modo passivo do OSPF:
11 Origina uma rota padrão em uma área Stub e filtra todos os LSAs do tipo Summary:
area AREA stub no-summary
11 Origina uma rota padrão na rede OSPF:
11 Filtra LSAs do tipo Summary entre áreas:
area NUMERO filter-list prefix NOME_LISTA_PREFIXO [in|out]
11 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.
11 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.
11 Ativa um mapa de rotas no processo OSPF:
ip protocol ospf route-map NOME_DO_MAPA
11 Cria uma ACL padrão:

OSPF Avançado
access-list NÚMERO (deny|permit) (A.B.C.D|Any) [Wildcard]
106
11 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]
11 Cria um Mapa de Rotas:
route-map NOME [permit|deny] NUMERO_SEQUÊNCIA
11 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>]
11 Procura por prefixos específicados pela ACL (nome ou número) em uma Mapa de Rotas:
match ip address
11 Procura pelo tag do LSA AS-External ou NSSA no Mapa de Rotas:
match tag <VALOR TAG>
11 Configura métrica com VALOR específico no Mapa de Rotas:
set metric <VALOR>
11 Configura LSA AS-External ou NSSA com tipo específico no Mapa de Rotas:
set metric-type <tipo 1 | tipo 2| internal | external>
11 Coloca uma tag no LSA AS-External ou NSSA no Mapa de Rotas:
set tag <VALOR TAG>
107
OSPF Avançado
108
4
Otimização e tópicos avançados
objetivos
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.
conceitos
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-
Capítulo 4 - Otimização e tópicos avançados
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:
11 Escalabilidade e Estabilidade: serão discutidos tópicos como Incremental OSPF,

Supressão de Prefixos e Graceful Restart;
11 Convergência: será apresentado o protocolo Bidirectional Forwarding Detection (BFD);
11 Monitoramento: a MIB 4750 será detalhada.
109
Escalabilidade e Estabilidade do OSPF
11 Roteadores modernos possuem mais CPU e memória, porém as redes estão ficando q
cada vez maiores.
11 Provedores atuais possuem mais roteadores e mais enlaces entre eles, aumentando o
tamanho do LSDB.
11 É importante melhorar a escabilidade do OSPF para garantir uma rede estável.
11 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:
11 Incremental OSPF: permite que o OSPF reprocesse apenas parte do LSDB em casos q
específicos de alteração na topologia da área OSPF;
11 Graceful Restart: permite que os pacotes continuem sendo encaminhados ao longo

da reinicialização do processo OSPF;
11 BFD para OSPF: permite que o processo OSPF detecte mais rapidamente a queda dos
roteadores vizinhos;
11 Supressão de Prefixos: permite a remoção dos prefixos das redes de trânsito do

LSDB, diminuindo assim o seu tamanho;
11 MIB para OSPF: permite o monitoramento dos objetos OSPF, facilitando a operação
da rede OSPF.
Incremental OSPF
11 Roteadores OSPF usam o algoritmo SPF para escolher o melhor caminho para cada q
destino.
11 Após a escolha de todos os caminhos, a Shortest Path Tree (SPT) é calculada.
11 Uma vez calculada a SPT, só há o reprocessamento quando há alterações topológicas.
11 O SPF reprocessa TODO o LSDB em caso de alterações topológicas na Área OSPF,

consumindo CPU e memória do roteador.
11 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
OSPF Avançado
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.
110
R1 Rede 3 R6
Rede 1 5 Rede 6
10
R3
10 5 5
10
Rede 2 15 10 Rede 7
15 10
R2 R5 R7
10 10
R8 R9 R10 R11
10 10
R4
Rede 8 Rede 4 Rede 10 Rede 11
Figura 4.1 É possível observar que essa rede possui diversos enlaces e roteadores. Assumindo os
Incremental OSPF. 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.
11 A topologia da figura 4.1. apresenta 11 roteadores, com diversos enlaces e custos; q

11 Cada roteador cria sua própria SPT para chegar a todos os destinos;
11 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.
111
R6
R3 R5 R7
R1 R2 R10 R11
R4
R8 R9
Rede 8 Rede 9
Como era de se esperar, o roteador R6 calculou sua SPT sem loops, utilizando as métricas dos Figura 4.2
enlaces anunciados pelos demais roteadores. Suponha que as rotas sejam instaladas no rote- Roteader R6 e
sua SPT.
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.
11 Supondo um problema entre R8 e Rede 8, R8 vai gerar um LSA Router informando a q

mudança de estado;
11 Todos os roteadores OSPF reprocessam o LSDB para criar novas SPTs;

OSPF Avançado
11 Ao longo da recriação da SPT, recursos de CPU e memória serão utilizados;
11 Como a Rede 8 só tem ligação com R8, as SPTs vão permanecer as mesmas.
112
w Diante desse cenário, alguns fabricantes implementaram uma versão otimizada do algoritmo
Leia o artigo “ARPANET
Routing Algorithm SPF sugerida na época da ARPANET. À época, foi sugerida uma modificação no algoritmo do
Improvements”, em SFP, chamado Incremental SFP (ISPF), propondo mudanças que afetem apenas as folhas ou
http://www.dtic.mil/
pequenas sub-árvores da SPT, e não forçam o cálculo completo da SPT. Assim, economizam
dtic/tr/fulltext/u2/
a086340.pdf recursos computacionais dos roteadores.
11 Para evitar esse tipo de situação, uma mudança foi implementada no SPF: q
o Incremental SPF (ISPF);
11 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;
11 Recursos computacionais seriam economizados e o tempo de convergência pode

ser otimizado;
11 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.
11 Propriedade 1: q
11 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"
11 Mesma regra para redes terminais, stub ou não-trânsito, como a "Rede 8" da figura 4.2
11 O processo SPF apenas adicionaria o novo roteador (ou nova rede Stub) sem recriar a SPT
11 Figura 4.3 ilustra a Propriedade 1
113
R6
R3 R5 R7
R1 R2 R10 R11
Rede 11B
R4
R8 R9 R12
Figura 4.3
Rede 8 Rede 9 Rede 12 ISPF e a
Propriedade 1.
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
OSPF Avançado
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).
114
11 A saída a seguir mostra o tempo de execução do SPF caso a interface Loopback de q
R12 seja desativada
11 Observe o tempo total de 12 ms, pois todos os LSAs foram reprocessados
11 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)

(...)
8 12 0 0 0 0 0 12
10 0
Change record
LSIDs changed 1
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(config)#router ospf 10
R6(config-router)#ispf
Vamos confirmar se 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
115
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:

SPF 21 executed 00:01:02 ago, SPF type Incremental
0 0 4 0 0 0 0 4
0 0
Change record
LSIDs changed 1
12.12.12.12(R)
Ao habilitarmos o ISPF com o comando a seguir, a mesma alteração do estado da q

Loopback de R12 consome 4 ms e apenas um LSA foi processado.
R6(config)#router ospf 10
R6(config-router)#ispf
Observe que o tipo de SPF foi Incremental.

0 0 4 0 0 0 0 4
OSPF Avançado
0 0
Change record
LSIDs changed 1
12.12.12.12(R)
116
Apenas a última execução do SPF executado foi mostrado (SPF 21). Nessa saída, é possível
ver algumas informações interessantes:
11 SPF type Incremental: o tipo de cálculo SPF foi o incremental, e não o completo (Full);
11 Total 4: o tempo total utilizado pelo SPF foi de 4 milisegundos, três vezes mais rápido que
o modo Full;
11 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.
11 Propriedade 2 q
11 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
11 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(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
q

R2-R4 alterado para DOWN. Tempo total do SPF com ISPF habilitado:
0 0 0 0 0 0 0 0
117
Tempo total com ISPF desabilitado: q
8 8 0 0 0 0 0 8
11 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).
11 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):

0 0 0 0 0 0 0 0
0 0
Change record
LSIDs changed 1
2.2.2.2(R)
Com o ISPF desabilitado, observe o que aconteceria:

8 8 0 0 0 0 0 8
7 0
Change record
LSIDs changed 1
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.
OSPF Avançado
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.
118
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.
11 Propriedade 3: q
11 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
11 Observe figura 4.4, onde o enlace R4-R5 ficou indisponível, afetando uma sub-árvore
da SPT
R6
R3 R5 R7
R1 R2 R10 R11
Rede 11B

R4
R8 R9 R12
Figura 4.4 Rede 8 Rede 9 Rede 12

ISPF Propriedade 3.
“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:”
119
R6#sh ip ospf statistics detail q
12 16 0 0 0 0 0 16
4 0
Change record
LSIDs changed 1
4.4.4.4(R)
Observe o cálculo do SPF com o ISPF habilitado em R6:

4 8 0 0 0 0 0 8
0 0
Change record
LSIDs changed 1
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.
11 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
11 Apenas esta sub-árvore precisaria ser reconstruída, e não toda a SPT
11 Observe o cálculo do SPF sem ISPF habilitado em R6:
Observe o cálculo do SPF sem ISPF habilitado em R6:

12 16 0 0 0 0 0 16
OSPF Avançado
4 0
Change record
LSIDs changed 1
4.4.4.4(R)
120
Observe o cálculo do SPF com o ISPF habilitado em R6: q
4 8 0 0 0 0 0 8
0 0
Change record
LSIDs changed 1
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:
11 Troca de métricas e adição de novos enlaces, que melhoram a conectividade da rede;
11 Alteração de qualquer enlace do próprio roteador (por exemplo, qualquer alteração em

R6 força o processamento FULL do SPF);
11 Alteração de enlace em redes Full Mesh (todos os roteadores ligados a todos os outros
roteadores).
11 É fácil ver os benefícios de usar o ISPF, já que o tempo de execução pode ser conside- q
ravelmente menor.
11 Situações que diferem das três propriedades apresentadas exigem cálculo Full do SPF,
por exemplo:
22 Troca de métricas e adição de novos enlaces;
22 Alterações em qualquer enlace do próprio roteador.
11 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
11 No funcionamento padrão do OSPF, em caso de reiniciação do processo ou problemas q
no módulo de controle, as vizinhanças são desfeitas;
11 Roteadores vizinhos precisam fazer a convergência do tráfego buscando caminhos

alternativos, caso existam;
11 Em certos equipamentos, mesmo com a reinicialização do Plano de Controle, o Plano

de Encaminhamento pode continuar funcionando;
11 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:
11 Plano de Controle;
11 Plano de Encaminhamento;
11 Plano de Gerência.
121
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:
11 Plano de Controle: responsável por definir como o tráfego deve ser encaminhado; q
utiliza a CPU principal do equipamento;
11 Plano de Encaminhamento: responsável pelo encaminhamento do tráfego entre as

interfaces; utiliza processadores dedicados (ASICs ou FPGAs);
11 Plano de Gerência: responsável por monitorar a operação do equipamento; utiliza a

CPU principal do equipamento;
11 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ção do 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-
OSPF Avançado
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:
122
11 Restarting Router: roteador que vai reiniciar o processo OSPF;
11 Helping Router: roteador vizinho do roteador que vai reiniciar (Restarting Router);
11 O Graceful Restart permite que o processo OSPF notifique seus vizinhos que o q
processo será reinicializado, mas que o encaminhamento do tráfego não será inter-
rompido enquanto isso acontece
11 Duas entidades foram definidas:
22 Restarting Router: roteador que irá reiniciar o processo OSPF
22 Helping Router: roteador vizinho do roteador que irá reiniciar (Restarting Router)
11 Antes de reiniciar, o Restarting Router envia um Grace LSA informando o motivo e o

tempo previsto de indisponibilidade
11 Se o Helping Router suportar o Graceful Restart, o mesmo continua enviando tráfego

normalmente
11 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:
11 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;
11 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).
123
11 Antes de voltar a operar novamente, o Restarting Router precisa: q
22 Reestabelecer as vizinhanças OSPF
22 Durante o sincronismo do LSDB, não pode gerar nenhum LSA
22 Após receber os LSAs, executa o SPF mas não instala as rotas (usa para
os Virtual Links)
22 Verifica as mensagens Hello para ver se deve virar DR
22 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:
11 Todos os LSAs do tipo Router são reoriginados para garantir consistência;
11 Já todos os LSAs do tipo Network são reoriginados nos segmentos onde o Restarting
Router é o DR;
11 O processo SPF é reexecutado e as rotas desta vez são instaladas;
11 LSAs do tipo 3, 4, 5 e 7 são reoriginados, caso o Restarting Router seja ABR ou ASBR;
11 Todas as entradas na tabela de rotas que não são mais válidas são removidas;
11 Todos os Grace LSAs são removidos do LSDB.
11 Após sair do estado de Graceful Restart, o Restarting Router executa alguns q

procedimentos:
22 Todos os LSAs do tipo Router são reoriginados para garantir consistencia;
22 Todos os LSAs do tipo Network são reoriginados nos segmentos onde o Restarting
Router é o DR;
22 O processo SPF é reexecutado e as rotas dessa vez são instaladas.
22 LSAs do tipo 3, 4, 5 e 7 são reoriginados, caso o Restarting Router seja ABR ou ASBR;
22 Todas as entradas na tabela de rotas que não são mais válidas são removidas;
22 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:
11 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;
11 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;
11 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.
OSPF Avançado
124
11 Os roteadores Helping Routers podem deixar de ser Helping Router diante dos q
seguintes eventos:
22 Um Grace LSA com tempo expirado é recebido do Restarting Router.
22 O Grace Period informado no Grace LSA expirou
22 Uma mudança do LSDB indicando que a topologia da rede mudou
11 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
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 LSA para 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>
125
11 Para iniciar o Graceful Restart no Restarting Router basta configurar o processo OSPF: q
R1# (config)# router ospf 10
R1# (config-router)#nsf ietf restart-interval <0-1800>
11 E na sequência, reiniciar o processo OSPF
11 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.
l
O modo Restarting
BFD para OSPF Router, da funcionali-
dade Graceful Restart,
Na sessão 1, o processo de estabelecimento de uma vizinhança OSPF foi apresentado, bem só é suportado por
como o processo para detectar a queda dos vizinhos. Em particular, o Dead Interval, inter- equipamentos com
suporte ao encaminha-
valo de tempo em que o OSPF espera por pacotes Hello de um vizinho antes de declará-lo
mento de pacotes,
"morto" foi apresentado, com alguns exemplos. De acordo com a RFC 2328, o Dead Interval mesmo sem o módulo
padrão é especificado em 40 segundos. Esse tempo de 40 segundos é extremamente de gerência estar em
operação. Esse
elevado para as aplicações modernas e, principalmente, as aplicações interativas. Para
comportamento é
situações onde os roteadores estão diretamente conectados, a queda de interface OSPF comum em equipa-
ativa imediatamente o processo de convergência OSPF. Porém, alguns cenários apresentam mentos de chassis, que
são modulares.
desafios extras. Observe a topologia da figura 4.5. Equipamentos menores
11 Sessão 1 apresentou o processo de estabelecimento e identificação da queda da adja- q normalmente

suportam apenas o
cência OSPF, usando ambos Hello (10 segundos) e Dead Interval (40 segundos) modo Helper Router.
11 Quando uma enlace OSPF muda de estado, o roteador diretamente conectado

detecta a mudança e notifica os demais roteadores OSPF
11 Se o enlace não estiver diretamente conectado, o Dead Interval é utilizado
11 Observe a figura 4.5
Internet
s1/0 R3
s1/0
f0/0
R1
f0/0
2 2
SW2 SW1
1 1
3 f0/0
Rede de Transporte A
Figura 4.5
Bidirectional
Forwarding
OSPF Avançado
R2 Detection.
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.
126
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
!
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
!
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".
11 A "Rede de Transporte A" conecta os três roteadores, criando uma rede Broadcast q
11 Uma rede ponto-a-ponto em um enlace serial conecta R1 e R3
11 O enlace serial deve ser usado para backup
11 Todos os roteadores estão na Área Backbone
11 Todas as adjacências estão estabelecidas:
R1#sh ip ospf neighbor

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
127
3.3.3.3 1 FULL/DR 00:00:33 10.0.0.3 FastEthernet0/0 q
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
1.1.1.1 0 FULL/ - 00:00:39 10.1.3.1 Serial1/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:

3.3.3.3 0 FULL/ - 00:00:36 10.1.3.3 Serial1/0
1.1.1.1 0 FULL/ - 00:00:39 10.1.3.1 Serial1/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:
11 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;
11 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;
OSPF Avançado
11 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;
128
Algumas possibilidades de indisponibilidades e impacto na rede:
11 Enlace SW1-R3 indisponível: R3 cria um LSA Router para os vizinhos, nesse caso R1; q
R1 atualiza R2 para enviar os pacotes para R3 via R1. Convergência concluída;
11 Enlace SW1-R2 indisponível: R2 não tem redundância, fica indisponível;
11 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:
11 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:
11 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.
22 Enlace entre SW1 e SW2 desativado. As adjacências OSPF são removidas após
40 segundos. Observe o Dead Interval decrementando.
R1#show ip ospf neighbor q

3.3.3.3 0 FULL/ - 00:00:30 10.1.3.3 Serial2/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#
R3#
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.

3.3.3.3 0 FULL/ - 00:00:30 10.1.3.3 Serial2/0
R1#
129
R1#
R3#
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.
11 Funcionalidade Fast Hello permite convergência em menos de 1 segundo, porém q

consume CPU do roteador
11 Protocolo Bidirectional Forwarding Detection, ou BFD, foi padronizado na RFC 5880
11 Protocolo de testes em Planos de Encaminhamento
11 Permite convergência em intervalos de testes de 50 milissegundos
11 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.
11 BFD utiliza sistema de mensagem de teste similar ao Hello do OSPF q

11 Engenheiro de Redes pode definir o intervalo de testes e quantidade de mensagens
permitidas antes de declarar vizinho como morto
11 BFD suporta MD5 por sessão
11 Muito utilizado para testar enlaces providos via Ethernet ou MPLS

OSPF Avançado
130
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.
11 A configuração BFD é tão simples quanto o protocolo: q

22 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
22 O intervalo de testes foi configurado para 50 milisegundos q

22 O tempo mínimo para receber as mensagens foi configurado para 50 milisegundos
22 Mensagens que devem ser perdidas antes de considerar a sessão BFD indisponível: 3
22 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
q
2. Configura-se o processo OSPF para usar as informações do processo BFD
Pode ser feito por interface:
l
configure terminal
Em alguns fabricantes, o ip ospf bfd
BFD só é ativado quando
a adjacência OSPF é *ou para todas as interfaces:
recriada; logo pode ser
necessário reiniciar o configure terminal
processo OSPF. router ospf 10
bfd all-interfaces
131
Para confirmar a ativação, execute o comando a seguir e observe a linha "BFD is enabled".
R1#show ip ospf
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
(...)
Verifique se o BFD está habilitado via comando: q

R1#show ip ospf
(...)
BFD is enabled
l
Para verificar se as sessões estão criadas:
R1#sh bfd neighbors

Assim como no Fast
IPv4 Sessions
Hello, o Engenheiro de
NeighAddr LD/RD RH/RS State Int Redes deve ser
10.0.0.3 8003/3 Up Up f0/0 cauteloso na escolha
de quando ativar o BFD
10.0.0.2 8004/4 Up Up f0/0
e também na escolha
do intervalo entre
Para confirmar se as sessões BFD estão criadas, utilize o comando a seguir: testes. Intervalos muito
curtos tendem a
R1#sh bfd neighbors consumir mais recursos
IPv4 Sessions e todos os roteadores
possuem um número
NeighAddr LD/RD RH/RS State Int
máximo de sessões
10.0.0.3 8003/3 Up Up f0/0 BFD suportadas, a
10.0.0.2 8004/4 Up Up f0/0 depender da plata-
forma.
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.
11 A partir do momento que a sessão BFD foi estabelecida, o processo BFD fará os testes q
no intervalo determinado, e ao detectar a queda, notificará o processo OSPF.
11 Ao ser notificado pelo BFD, o processo OSPF imediatamente desfaz a adjacência com
o vizinho indisponível e recria a SPT.
11 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.
OSPF Avançado
132
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).
11 Redes de ISPs já possuem milhares de rotas, recebidas via BGP e IGP q

11 Quanto mais enlaces entre roteadores, mais Redes de Trânsito são criadas
11 Redes altamente conectadas possuem em seus LSDBs muitos prefixos apenas para
trânsito, ou seja, desnecessários do ponto de vista dos usuários
11 RFC 6860 padronizou uma funcionalidade para melhorar a escalabilidade do OSPF:

a Supressão de Prefixos
11 Redes de Trânsito são removidas do LSDB quando a Supressão de Prefixos é habilitada
11 Melhora o tempo de convergência através da diminuição do LSDB
R1 R2 R3
192.168.1.0/24 10.1.2.0/24 10.2.3.0/24 192.168.2.0/24
10.2.4.0/24 10.3.5.0/24
Figura 4.6 10.4.5.0/24

192.168.3.0/24
Topologia para
Supressão de
Prefixos. R4 R5
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.
133
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:
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
11 A rede da figura 4.6 possui: q

22 Três redes de usuários (192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24);
22 Cinco roteadores (R1, R2, R3, R4 e R5);
22 Cinco interfaces Loopbacks (10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4 e 10.0.0.5);
22 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);
22 Enlace R1-R2 está configurado como Broadcast;
22 Demais enlaces estão configurados como Ponto-a-Ponto.
Observe a seguir a saída da tabela de rotas de R5: q

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
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
O E2 192.168.2.0/24 [110/20] via 10.3.5.3, 00:03:12, FastEthernet0/0
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á
OSPF Avançado
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 enlaces ponto-a-ponto e utilizando prefixos /30 e/ou /31. Nesse caso, quanto maior
134
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

LS Type: Router Links
Number of Links: 3
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.1.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
TOS 0 Metrics: 1
TOS 0 Metrics: 1
135
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:

Number of Links: 6
TOS 0 Metrics: 1
TOS 0 Metrics: 1
TOS 0 Metrics: 1
TOS 0 Metrics: 1
TOS 0 Metrics: 1
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”
OSPF Avançado
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.
136
É possível notar que existem dois registros associados com o mesmo enlace entre o rote-
ador R2 e o roteador R3:

TOS 0 Metrics: 1
TOS 0 Metrics: 1
Observe os LSAs do tipo Router na Área Backbone: q

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):

Number of Links: 6

137
Link connected to: a Transit Network q
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
ip ospf prefix-suppression
Por roteador:
configure terminal
router ospf 10
prefix-suppression
q

11 A Supressão de Prefixos pode ser feita por interface:
configure terminal
11 Por roteador:
configure terminal
router ospf 10
prefix-suppresion
11 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:

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
OSPF Avançado
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
138
11 Observe o LSBD com a Supressão de Prefixos habilitada: q
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
11 Observe que a quantidade de enlaces na coluna Link Count diminui se comparado

com o LSBD sem supressão.
11 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:

Number of Links: 4
TOS 0 Metrics: 1
TOS 0 Metrics: 1

TOS 0 Metrics: 1
TOS 0 Metrics: 1
139
É possível verificar que não existem mais enlaces do Tipo 3 (Stub) associados os enlaces
l
Só há supressão para
ponto-a-ponto. Enlaces associados a interfaces loopbacks ou interfaces passívas não são LSAs Router e Network.
suprimidos, pois não são considerados redes de trânsito.
Confirmando a tabela de rotas em R5:
R5#sh ip route ospf

[110/4] 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 E2 192.168.2.0/24 [110/20] via 10.3.5.3, 01:35:06, GigabitEthernet1/0
q

11 Verificando a tabela de rotas em R5:
R5#sh ip route ospf

O 10.0.0.3/32 [110/2] 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
11 É 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?
11 É possível observar que o enlace 10.1.2.0/24 também não está na tabela de rotas de q
OSPF Avançado
R5, apesar de não ser Tipo 3.
11 Enlaces tipo 2(Transit) também são considerados redes de trânsito, por isso também
são suprimidos
11 RFC6860 define que a máscara de subrede do LSA Network seja alterada para /32.
140
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

LS age: 158
LS Type: Network Links
Network Mask: /32
Observe o LSA Network: q

R5#sh ip ospf database network
LS age: 158
LS Type: Network Links
Network Mask: /32
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

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!
141
11 A princípal diferença, do ponto de vista da operação da rede, e o PING ou TRACEROUTE q
de dentro dos roteadores. Observe:
R1#ping 10.0.0.5
.....
Success rate is 0 percent (0/5)
11 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.
11 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.
11 Nesse caso, a origem do teste deve ser definida:
R1#ping 10.0.0.5 source 10.0.0.1

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

11 Redes de computadores devem ter seus ativos de rede e protocolos monitorados q
OSPF Avançado
constantemente.
11 O protocolo SNMP (Simple Network Management Protocol) provê diversas informações

para operação da rede.
142
11 Itens como utilização e erros das interfaces, CPU e memória, fontes, ventiladores e q
laser recebido nas interfaces são itens mínimos a serem monitorados.
11 Monitoramento OSPF via SNMP está definido na RFC 4750, que especifica a Management
Information Base (MIB) do OSPF.
11 Diversos objetos estão contemplados e disponíveis para os operadores de rede.
11 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.
11 A MIB do OSPF consiste das seguintes tabelas: q

22 Variáveis Gerais
22 Estrutura de Dados de Áreas

22 Tabela de Métricas de Áreas Sub
22 Link State Database
22 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.
143
Tabela OID Principais Objetos
Variáveis Gerais (General Variables): descreve variáveis ospfGeneralGroup ospfRouterId

globais do processo OSPF 1.3.6.1.2.1.14.1 ospfAdminStat
Estrututas de Dados de Áreas (Area Data Structure): ospfAreaTable ospfAreaId ospfAuthType

descreve todas as áreas da qual o roteador faz parte 1.3.6.1.2.1.14.2
Tabela de Métricas de Áreas Stub (Area Stub Metric ospfStubAreaTable ospfStubAreaId

Table): descreve as métricas enviadas para a(s) área(s) 1.3.6.1.2.1.14.3
Stub
Link State Database (LSDB): provê informações do ospfLsdbTable ospfLsdbAreaId

LSDB para tratamento de erros 1.3.6.1.2.1.14.4
Tabela de Range de Endereços (Address Range Table): ospfAreaRangeTable ospfAreaRangeNet

provê informações sobre sumários e rotas de hosts 1.3.6.1.2.1.14.5
Tabela de Hosts (Host Table): provê informações sobre ospfHostTable ospfHostMetric

sumários e rotas de hosts 1.3.6.1.2.1.14.6 ospfHostAreaID
Tabela de Interfaces (Interface Table): provê informa- ospfIfTable ospfIfType

ções sobre as interfaces OSPF 1.3.6.1.2.1.14.7 ospfIfHelloInterval
ospfIfDesignatedRouter
Tabela de Métrica de Interface (Interface Metric Table): ospfIfMetricTable ospfIfMetricValue

provê informações de métrica das interfaces OSPF 1.3.6.1.2.1.14.8
Tabela de Interface Virtual (Virtual Interface Table): ospfVirtIfTable ospfVirtIfNeighbor

provê informações sobre os Virtual Links 1.3.6.1.2.1.14.9
Tabela de Vizinho (Neighbor Table): descreve os vizi- ospfNbrTable ospfNbrIpAddr

nhos OSPF 1.3.6.1.2.1.14.10 ospfNbrRtrId
ospfNbrState
Tabela de Vizinho Virtual (Virtual Neighbor Table): des- ospfVirtNbrTable ospfVirtNbrArea

creve os vizinhos OSPF usando Virtual Links 1.3.6.1.2.1.14.11 ospfVirtNbrRtrId
LSDB Externo (External Link State Database): provê ospfExtLsdbTable ospfExtLsdbType

informações do LSDB para tratamento de erros 1.3.6.1.2.1.14.12
Tabela de Range Agregado (Aggregate Range Table): ospfAreaAggregateTable ospfAreaAggregateAreaID

informa os prefixos sumarizados 1.3.6.1.2.1.14.14
LSDB Local (Local Link State Database): idêntico ao ospfLocalLsdbTable ospfLocalLsdbEntry

LSDB mas contém apenas LSAs Opacos (Tipo 9) 1.3.6.1.2.1.14.17
LSDB escopo AS (AS-scope Link State Database): idên- ospfAsLsdbTable

tico ao LSDB mas contém apenas LSAs Externos ospfAsLsdbEntry
1.3.6.1.2.1.14.19
Continuação das tabelas disponíveis na MIB do OSPF: q Tabela 4.1

Seções que
11 Tabelas de Interface, Métrica de Interface e Interface Virtual; compõem a MIB
do OSPF.
11 Tabelas de Vizinho e Vizinho Virtual;
11 LSDB Externo, LSDB Local, LSBD escopo AS;

OSPF Avançado
11 Tabela de Range Agregado.
144
l Conforme mencionado anteriormente, a MIB do OSPF foi criada para permitir o monitora-
Cada seção possui mento remoto dos objetos, tabelas e parâmetros que compõem a operação do OSPF em
diversos objetos, que um determinado roteador. Os resultados obtidos via SNMP também podem ser obtidos
podem ser do tipo
"somente leitura" pela linha de comando do equipamento; porém, em ambientes com muitos equipamentos,
(read-only) o ideal é automatizar a operação e monitoramento. Para ilustrar as saídas possíveis, vamos
ou "leitura e escrita"
utilizar a topologia da figura 4.7.
q
(read-write). É
importante o aluno ter
11 A MIB OSPF possui o OID 1.3.6.1.2.1.14
em mente que um
roteador mal-configu- 11 Cada tabela tem um OID - Object Identifier que a representa, através de um índice
rado pode criar riscos
especifico.
de segurança.
11 Exemplos:
22 Variáveis gerais - Índice 1 - 1.3.6.1.2.1.14.1
22 Tabela de Interfaces - Índice 7 - 1.3.6.1.2.1.14.7
11 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.
R1 R2 Area 1 Stub R3
192.168.1.0/24 10.1.2.0/24 10.2.3.0/24 192.168.3.0/24

24
10
.0/
.2.
6.1
10.2.4.0/24
5.0
2.1
Senha Simples
/2
Custo 15
17
4-
M
D5
Gerência 192.168.2.0/24 10.4.5.0/24
R4 Area 2 R5
Figura 4.7 Essa rede possui as seguintes características:

SNMP.
11 Cinco roteadores OSPF, atuando como roteadores internos (R3), ABR (R2, R4 e R5)
e ASBR (R1);
11 Os enlaces R1-R2 e R4-R5 não possuem autenticação;

11 O enlace R2-R5 possui autenticação MD5;
11 O enlace R2-R4 possui autenticação simples;
11 Além da Área Backbone, há uma área Stub (Area 1) e uma Área Normal (Área 2);
11 R1 faz a redistribuição do prefixo 192.168.1.0/24 na Área Backbone;
11 O enlace R2-R4 possui custo alterado para 15;
11 O enlace R2-R5 está configurado como ponto-a-ponto;
11 R4 gera um LSA-Summary para o prefixo 192.168.2.0/24;
11 Um Virtual Link será criado entre R4 e R5;
11 Um servidor de gerência, com pacote SNMP instalado, foi instalado com o IP 172.16.1.2.

145
11 Todas as consultas SNMP serão feitas a partir de um servidor Linux com o pacote q
SNMP instalado.
11 As consultas foram feitas com o comando snmpwalk, SNMP versão 2 e a community

(senha) public.
11 Nos roteadores, a configuração a seguir foi feita para habilitar o SNMP:
configure terminal
snmp-server community public
11 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)

11 A tabela Variáveis Globais é representada pelo objeto ospfGeneralGroup, com q
ID 1.3.6.1.2.1.14.1.
11 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 Avançado
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
146
OSPF-MIB::ospfRxNewLsas.0 = Counter32: 42 q
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)
11 É 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::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:
Além do router-id, podemos ver que o processo OSPF está habilitado:
A versão do OSPF, nesse caso, versão 2:
E que esse roteador é um ABR, já que está na Área 1 também:

Quando se deseja apenas um objeto específico, podemos filtrá-lo no comando snmpwalk:
snmpwalk -v 2c -c public 10.0.0.2 ospfRouterId

Vamos consultar o router-id de cada roteador:

147
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

11 Usando a OID ospfAreaTable, podemos consultar informações sobre as Áreas OSPF. q
11 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
snmpwalk -v 2c -c public 10.0.0.2 ospfAuthType
OSPF-MIB::ospfAuthType.0.0.0.0 = INTEGER: 0
11 É 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:
11 ospfAreaID: informa as áreas presentes em um roteador;
11 ospfAuthType: informa que tipo de autenticação existe para cada área.
Observe a consulta à ospfAreaTable do roteador R2.

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.

OSPF Avançado
148
Além disso, a ospfAreaTable possui os seguintes objetos que podem ser muito úteis: q
11 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;
11 ospfAreaBdrRtrCount: informa quantos ABRs existem na área;
11 ospfAsBdrRtrCount: informa quantos ASBRs existem na área.
11 Como esses objetos estão associados às áreas, a sintaxe de saída será sempre:
OSPF-MIB::OBJETO.ÁREA = Valor
11 Por exemplo:
snmpwalk -v 2c -c public 10.0.0.4 ospfSpfRuns

OSPF-MIB::ospfSpfRuns.0.0.0.0 = Counter32: 17
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 ospfAreaBdrRtrCount
OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.0 = Gauge32: 3
snmpwalk -v 2c -c public 10.0.0.4 ospfAsBdrRtrCount
OSPF-MIB::ospfAsBdrRtrCount.0.0.0.0 = Gauge32: 1
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 ospfAreaBdrRtrCount
snmpwalk -v 2c -c public 10.0.0.4 ospfAsBdrRtrCount
149
Explorando a tabela ospfStubAreaTable
11 A tabela ospfStubAreaTable só existe nos roteadores que possuem um Área Stub. q
11 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
11 A Área 1 é Stub, logo:

OSPF-MIB::ospfStubAreaId.0.0.0.1.0 = IpAddress: 0.0.0.1
11 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
11 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
11 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:

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:

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:

Nesse caso, o custo foi de 1, como pode ser visto pela linha de comando em R3:
R3#sh ip route ospf

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
OSPF Avançado
area 1 default-cost 5
150
Confirmando via linha de comando e via SNMP:
R3#sh ip route ospf

É 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

11 A tabela ospfLsdbTable apresenta o LSDB inteiro, de cada área q
11 Contém os LSA existentes, número de sequência, Age, tipos, etc.
11 Observe a saída abaixo, apresentando os LSAs por tipo, usando o formato:
22 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.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.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 0.0.0.0
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

11 AREA: número da área em 32 bits;
11 TIPO: router, Network, Summary, asSummary, asExternal, nssaExternal;
11 LINK_ID: depende do TIPO. Mais detalhes na sessão de aprendizagem 1, tabela 1.2;
11 ADV_ROUTER: roteador que está originando o LINK_ID.
$ snmpwalk -v 2c -c public 10.0.0.2 ospfLsdbAreaId

151
OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.2.0.10.0.0.4 = IpAddress:
0.0.0.0
0.0.0.0
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.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

11 A tabela ospfHostTable mostra informações sobre as interfaces de usuário, ou q
hosts(interfaces passivas).
11 Essas interfaces não tem roteadores OSPF como vizinhos
11 Objetos mais importantes: ospfHostMetric e ospfHostAreaID
11 Exemplo:
$ snmpwalk -v 2c -c public 10.0.0.3 OSPF-MIB::ospfHostTable

OSPF-MIB::ospfHostMetric.10.0.0.3.0 = INTEGER: 1
OSPF Avançado
OSPF-MIB::ospfHostAreaID.10.0.0.3.0 = IpAddress: 0.0.0.1
$ snmpwalk -v 2c -c public 10.0.0.4 .1.3.6.1.2.1.14.6
152
OSPF-MIB::ospfHostMetric.192.168.2.1.0 = INTEGER: 1 q
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:
11 ospfHostMetric: métrica associada à interface;
11 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

snmpwalk -v 2c -c public 10.0.0.4 .1.3.6.1.2.1.14.6
É 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

11 A tabela ospfIfTable mostra diversas informações sobre as interfaces OSPF q
11 Principais objetos:
22 ospfIfAreaId: informa a área da qual a interface faz parte. A interface é represen-

tada pelo IP que possui. Formato:
33 OSPF-MIB::ospfIfAreaId.IP.0 = IpAddress: AREA
22 ospfIfType: informa o tipo de rede da interface (broadcast(1), pointToPoint(3),

nbma(2) e pointToMultipoint(4))
22 ospfIfRtrPriority: informa a prioridade da interface para escolha do DR q

22 ospfIfHelloInterval, ospfIfRtrDeadInterval: informam o Hello e o Dead Interval
22 ospfIfState: O estado da interface. Pode ser down, loopback, waiting, pointToPoint,

designatedRouter, backupDesignatedRouter ou otherDesignatedRouter.
22 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:
11 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
153
11 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;
11 ospfIfRtrPriority: informa a prioridade da interface para escolha do DR. Prioridade 0 é

não elegível, muito comum em redes ponto-a-ponto;
11 ospfIfHelloInterval: indica o intervalo Hello da interface. O padrão é 10 segundos;
11 ospfIfRtrDeadInterval: informa o intervalo Dead Interval da interface, indicando

quando o roteador vizinho será considerado desconectado. O padrão é 40 segundos;
11 ospfIfState: o estado da interface. Pode ser down, loopback, waiting, pointToPoint,

designatedRouter, backupDesignatedRouter ou otherDesignatedRouter;
11 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::ospfIfType.10.0.0.2.0 = INTEGER: pointToPoint(3)
OSPF-MIB::ospfIfType.10.1.2.2.0 = INTEGER: broadcast(1)
OSPF-MIB::ospfIfRtrPriority.10.0.0.2.0 = INTEGER: 0
OSPF-MIB::ospfIfHelloInterval.10.0.0.2.0 = INTEGER: 10
OSPF-MIB::ospfIfRtrDeadInterval.10.0.0.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 Avançado

OSPF-MIB::ospfIfState.10.2.5.2.0 = INTEGER: pointToPoint(4)
OSPF-MIB::ospfIfAuthType.10.0.0.2.0 = INTEGER: 0
154
snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfIfTable
OSPF-MIB::ospfIfState.10.2.5.5.0 = INTEGER: pointToPoint(4)
OSPF-MIB::ospfIfDesignatedRouter.10.0.0.5.0 = IpAddress: 0.0.0.0
OSPF-MIB::ospfIfBackupDesignatedRouter.10.0.0.5.0 = IpAddress: 0.0.0.0
Observe a tabela ospfIfTable de R2 (simplificada): q

$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfIfTable

Observe que a interface com IP 10.0.0.2, não possui autenticação (ofpfIfAuthType = 0)
155
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

11 A tabela ospfVirtIfTable descreve as configurações relacionadas aos Virtual Links. q
11 A mesma só existe em roteadores que tem Virtual-Link ativado
11 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
11 É 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

11 A tabela ospfNbrTable descreve as vizinhanças estabelecidas pelo roteador OSPF q
11 Essa é uma das tabelas mais importantes
11 Objetos mais importantes:
22 ospfNbrIpAddr: informa o endereço IP da interface do vizinho OSPF
22 ospfNbrRtrId: informa o Router-ID do vizinho OSPF
22 ospfNbrPriority: informa a prioridade para escolha do DR.

OSPF Avançado
22 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).
11 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.
156
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:
11 ospfNbrIpAddr: informa o endereço IP da interface do vizinho OSPF;
11 ospfNbrRtrId: indica o Router-ID do vizinho OSPF;
11 ospfNbrPriority: informa a prioridade para escolha do DR. Se o valor é 0, não é elegível

ou é Ponto-a-Ponto;
11 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::ospfNbrRtrId.10.2.5.2.0 = IpAddress: 10.0.0.2
OSPF-MIB::ospfNbrPriority.10.2.5.2.0 = INTEGER: 0
OSPF-MIB::ospfNbrState.10.2.5.2.0 = INTEGER: full(8)
$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfNbrTable

Exemplo da tabela ofpfNbrTable a partir de R2: q

157
OSPF-MIB::ospfNbrRtrId.10.2.3.3.0 = IpAddress: 10.0.0.3 q
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

11 A tabela ospfAreaAggregateTable descreve as rotas sumarizadas pelo roteador OSPF q
11 Caso não exista rota sumarizada, a tabela não será criada.
11 Principais objetos:
22 ospfAreaAggregateAreaID: informa a área associada à sumarização.
22 ospfAreaAggregateLsdbType: informa o tipo de sumarização sendo executado.

Pode ser summaryLink (3) ou nssaExternalLink (7).
22 ospfAreaAggregateNet: informa o prefixo sumarizado;
22 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:
11 ospfAreaAggregateAreaID: informa a área associada à sumarização. No caso de R4, é a

Área 2 (0.0.0.2);
11 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;
OSPF Avançado
11 ospfAreaAggregateNet: informa o prefixo sumarizado;
11 ospfAreaAggregateMask: informa a máscara de subrede do prefixo sumarizado.
158
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.

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
Em R4 foi aplicado o seguinte comando: q

router ospf
area 2 range 192.168.2.0 255.255.255.0
Observe a saída do snmpwalk em R4:

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.
11 Neste material, foram apresentados apenas os objetos principais. Mais objetos estão q
disponíveis na RFC 4750
11 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.
11 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.
11 É 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.
159
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.
11 Habilita o ISPF no processo OSPF:
ispf
11 Habilita e define o tempo de expiração do Grace LSA:
nsf ietf restart-interval <0-1800>
11 Habilita BFD em todas as interfaces OSPF:
bfd all-interfaces
11 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.
11 Configura os temporizadores do processo BFD na interface:
bfd interval VALOR min_rx VALOR multiplier NUMERO
11 Habilita BFD no processo OSPF da interface:
ip ospf bfd
11 Habilita supressão de prefixos na interface OSPF:
Os comandos a seguir são aplicados no modo de configuração global do roteador.
11 Habilita o processo SNMP server no roteador com a comunidade estabelecida:
snmp-server community <NOME_DA_COMMUNITY>

OSPF Avançado
160
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.
LIVRO DE APOIO AO CURSO
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.
02 5
630025

OSPF Avançado PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OSPF Avançado PDF

Enviado por

Direitos autorais:

Formatos disponíveis

OSPF

Jerônimo Aguiar Bezerra

Jerônimo Aguiar Bezerra

Jerônimo Aguiar Bezerra

Diretor de Serviços e Soluções

Escola Superior de Redes

Coordenador Acadêmico da Área e Administração de Projetos de Redes

Equipe ESR (em ordem alfabética)

Capa, projeto visual e diagramação

Dados Internacionais de Catalogação na Publicação (CIP)

B574o Bezerra, Jerônimo Aguiar

1. OSPF (Open Shortest Path First). 2. Protocolos de rede de computador.

Escola Superior de Redes

Sobre o curso viii

A quem se destina ix

Convenções utilizadas neste livro ix

Entendendo o funcionamento do banco de dados do OSPF 1

Tipos de pacotes OSPF 2

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

NSSA External LSA 28

2. Entendendo as áreas do OSPF

Quais são os tipos de áreas e como elas se comportam em um ambiente OSPF 35

Área Not-So-Stubby ou NSSA 38

Interconectando áreas com Virtual Links 38

A: Observando o funcionamento do LSDB na Área Backbone 41

A1: Router-LSA e Network-LSA 41

A.3: AS External LSA 53

A.4: ASBR Summary LSA 57

A.6: Virtual Links 61

3. Engenharia de tráfego com OSPF

Escolha de caminhos pelo OSPF 81

Observe o LSDB de R1 a seguir. 83

Controlando atualizações de roteamento 86

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

4. Otimização e tópicos avançados

Escalabilidade e Estabilidade do OSPF 110

BFD para OSPF 126

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

A ESR também participa de diversos projetos de interesse público, como a elaboração e

A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema

As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo