OSPF Avançado

OSPF
Avanado
Jernimo Aguiar Bezerra
A RNP Rede Nacional de Ensino

e Pesquisa qualificada como
uma Organizao Social (OS),
sendo ligada ao Ministrio da
Cincia, Tecnologia e Inovao
(MCTI)
responsvel
pelo
Programa Interministerial RNP,

que conta com a participao dos
ministrios da Educao (MEC), da
Sade (MS) e da Cultura (MinC).
Pioneira no acesso Internet no
Brasil, a RNP planeja e mantm a
rede Ip, a rede ptica nacional
acadmica de alto desempenho.
Com Pontos de Presena nas
27 unidades da federao, a rede
tem mais de 800 instituies
conectadas. So aproximadamente
3,5 milhes de usurios usufruindo
de uma infraestrutura de redes
avanadas para comunicao,
computao e experimentao,
que contribui para a integrao
entre o sistema de Cincia e
Tecnologia, Educao Superior,
Sade e Cultura.
OSPF
Avanado
OSPF
Avanado
Rio de Janeiro
Escola Superior de Redes
2016
Copyright 2016 Rede Nacional de Ensino e Pesquisa RNP

Rua Lauro Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho

Coordenador Nacional
Leandro Marcos Oliveira Guimares

Edio
Lincoln da Mata
Coordenador Acadmico da rea e Administrao de Projetos de Redes
Luiz Carlos Lobo Lobato
Equipe ESR (em ordem alfabtica)
Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlina Miranda, Elimria Barbosa,
Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato ,
Renato Duarte e Yve Marcial.
Capa, projeto visual e diagramao
Tecnodesign
Verso
1.0.0
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de
contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores no 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.
Distribuio
Rua Lauro Mller, 116 sala 1103

22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br
Dados Internacionais de Catalogao na Publicao (CIP)

B574o
Bezerra, Jernimo Aguiar

OSPF Avanado / Jernimo 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. Telecomunicaes Trafico Gesto. I. Ttulo.

CDD 004.62
Sumrio
A metodologia da ESRvii
Sobre o curso viii
A quem se destina ix
Convenes utilizadas neste livroix
Permisses de usox
Sobre os autoresx
1. Funcionamento do banco de
dados do OSPF
Entendendo o funcionamento do banco de dados do OSPF1
Tipos de pacotes OSPF2
Pacotes Hello4
Formato do pacote Hello5
Responsabilidades do protocolo Hello7
Processo de eleio dos roteadores Designated Router e Backup Designated Router10
Database Description DD13
Link State Request ou LSR16
Link State Update ou LSU18
Link State Acknowledgement ou LSAck19
Transio de Estados no Sincronismo do OSPF20
Link State Advertisement ou LSA22
Router LSA24
iii
Network Summary LSA e ASBR Summary LSA26

AS External LSA27
NSSA External LSA28
Remoo de LSAs29
Concluso31
Comandos OSPF32
2. Entendendo as reas do OSPF

Por que o OSPF faz uso do conceito de reas?33
Quais so os tipos de reas e como elas se comportam em um ambiente OSPF35
rea Backbone36
rea Normal37
rea Stub37
rea Not-So-Stubby ou NSSA38
Interconectando reas com Virtual Links38
Entendendo o LSDB40
A: Observando o funcionamento do LSDB na rea Backbone41
A1: Router-LSA e Network-LSA41
A.2: Summary-LSA48
A.3: AS External LSA53
A.4: ASBR Summary LSA57
A.5: NSSA-LSA59
A.6: Virtual Links61
Concluso66
Comandos OSPF66
3. Engenharia de trfego com OSPF

Introduo69
Sumarizao de rotas69
Agregao de rotas76
Mtricas80
Escolha de caminhos pelo OSPF81
Observe o LSDB de R1 a seguir.83
Controlando atualizaes de roteamento86
iv
Interfaces Passivas (Passive Interfaces)86

Rotas padro89
Filtrando prefixos92
Lista de Controle de Acesso (Access Control List: ACL)93
Lista de Prefixos (Prefix-List)93
Listas de Distribuio (Distributed Lists)94
Mapas de Rotas (Route-Maps)94
Filtragem de prefixos Intra-rea OSPF99
Agregao de LSAs AS-External103
Comandos OSPF106
4. Otimizao e tpicos avanados

Introduo109
Escalabilidade e Estabilidade do OSPF110
Incremental OSPF110
Propriedade 1113
Propriedade 2117
Propriedade 3119
Graceful Restart121
BFD para OSPF126
Supresso de Prefixos133
Monitorando o OSPF com a RFC 4750: OSPF Version 2 MIB142
Explorando a tabela ospfGeneralGroup (Variveis Globais)146
Explorando a tabela ospfAreaTable148
Explorando a tabela ospfStubAreaTable150
Explorando a tabela ospfLsdbTable151
Explorando a tabela ospfHostTable152
Explorando a tabela ospfIfTable153
Explorando a tabela ospfVirtIfTable156
Explorando a tabela ospfNbrTable156
Explorando a tabela ospfAreaAggregateTable158
Concluso160
Comandos OSPF160
vi

A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa (RNP)
responsvel pela disseminao do conhecimento em Tecnologias da Informao e Comunicao (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competncias
em TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e
unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica do
corpo funcional das organizaes usurias da RNP, para o exerccio de competncias aplicveis ao uso eficaz e eficiente das TIC.
A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Projeto
de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao Digital e
Governana de TI.
A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao e
execuo de planos de capacitao para formao de multiplicadores para projetos educacionais como: formao no uso da conferncia web para a Universidade Aberta do Brasil
(UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um conjunto de
cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedaggica e a metodologia que orientam os cursos da ESR so baseadas na
aprendizagem como construo do conhecimento por meio da resoluo de problemas tpicos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza
terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no
apenas como expositor de conceitos e informaes, mas principalmente como orientador do
aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional.
A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema
semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise,
sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do problema, em abordagem orientada ao desenvolvimento de competncias.
Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as
atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de aprendizagem no considerada uma simples exposio de conceitos e informaes. O instrutor
busca incentivar a participao dos alunos continuamente.
vii
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas de
estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de atuao do futuro especialista que se pretende formar.
As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de tempo
para as atividades prticas, conforme descrio a seguir:
Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos).
O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema
da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor
levanta questes sobre o contedo dos slides em vez de apenas apresent-los, convidando
a turma reflexo e participao. Isso evita que as apresentaes sejam montonas e que o
aluno se coloque em posio de passividade, o que reduziria a aprendizagem.
Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos).
Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona 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 dvidas e
oferecer explicaes complementares.
Terceira etapa: discusso das atividades realizadas (30 minutos).
O instrutor comenta cada atividade, apresentando uma das solues possveis para resolv-la,
devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so convidados a
comentar as solues encontradas e o instrutor retoma tpicos que tenham gerado dvidas,
estimulando a participao dos alunos. O instrutor sempre estimula os alunos a encontrarem
solues 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 so utilizados. Alm disso, sero apresentadas alternativas para trabalhar com
engenharia de trfego, sero apresentados modos de como mudar as mtricas e forar
o roteamento de trfego por caminhos mais otimizados. Tambm sero apresentadas
tcnicas para controlar a redistribuio de prefixos utilizando os mapas de rotas (ou
route-maps). O curso termina com uma sesso de sugestes de otimizaes para a convergncia do OSPF alm 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 so e como so utilizados os LSA (Link State Advertisements)
66 Descrever quais so os estados possveis 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 tcnicas de Engenharia de Trfego com OSPF
66 Entender e configurar ajustes finos avanados 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 Supresso 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 bsico do protocolo OSPF. Estudantes de Cincia da Computao
interessados em aprofundar os conhecimentos em protocolo de roteamento OSPF.
Convenes utilizadas neste livro

As seguintes convenes tipogrficas so usadas neste livro:
Itlico
Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.
Largura constante
Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da sada
de comandos. Comandos que sero digitados pelo usurio so grifados em negrito e possuem
o prefixo do ambiente em uso (no Linux normalmente # ou $, enquanto no Windows C:\).
Contedo de slide q
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.
Smbolo w
Indica referncia complementar disponvel em site ou pgina na internet.
Smbolo d
Indica um documento como referncia complementar.
Smbolo v
Indica um vdeo como referncia complementar.
Smbolo s
Indica um arquivo de adio como referncia complementar.
Smbolo
Indica um aviso ou precauo a ser considerada.
Smbolo p
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao
entendimento do tema em questo.
Smbolo l
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou
mesmo uma observao.
ix
Permisses de uso
Todos os direitos reservados RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citao: TORRES, Pedro et al. Administrao de Sistemas Linux: Redes e Segurana.
Rio de Janeiro: Escola Superior de Redes, RNP, 2013.
Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao:
Escola Superior de Redes RNP
Endereo: Av. Lauro Mller 116 sala 1103 Botafogo
Rio de Janeiro RJ 22290-906
E-mail: info@esr.rnp.br
Sobre os autores
Jernimo Aguiar Bezerra mestre em Mecatrnica e Bacharel em Cincia da Computao
pela Universidade Federal da Bahia, Jeronimo Aguiar Bezerra tem vasta experincia com
redes de computadores, sistemas operacionais, VoIP e GNU/Linux. Possuindo algumas certificaes 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 diversos projetos de larga escala, como a implementao da Rede REMESSA e do Ponto de Troca
de Trfego da Bahia. Jab esteve envolvido com redes acadmicas e comerciais pelos ltimos
13 anos, com passagem pela Rede Nacional de Ensino e Pesquisa (RNP) e tendo feito parte
de Grupos de Trabalho do IETF.
1
objetivos
Funcionamento do banco de
dados do OSPF
Descrever o funcionamento do OSPF; Descrever os tipos de pacotes OSPF;
Descrever quais so e como so utilizados os Link State Advertisements; Descrever
quais so os estados possveis de um roteador OSPF.
conceitos
Funcionamento do protocolo OSPF; Tipos de pacotes OSPF; Transio de Estados

no Sincronismo do OSPF; Link State Advertisement ou LSA; Router LSA; Network LSA;
Network Summary LSA; ASBR Summary LSA; AS External LSA; NSSA External LSA;
Remoo de LSAs.
Entendendo o funcionamento do banco de dados do OSPF

11 OSPF est definido na RFC 2328 (atualmente usa-se a verso 2 para IPv4
e verso 3 para IPv6).

11 Funcionamento se baseia em um banco de dados topolgico.
11 Existe apenas um banco de dados topolgico por rea (chamado de Link-State
11 Todos os roteadores da rea tm de ter o mesmo LSDB.
11 Banco de dados criados a partir da troca de mensagens Link State Advertisements (LSAs).
11 Roteadores enviam LSAs com informaes 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 topolgico (ou Link-State

SPF Short Path First
Ou algoritmo de
Dijkstra. Criado por
Edsger Dijkstra
em 1956.
Database LSDB), criado com informaes dos enlaces de todos os roteadores que fazem
parte da mesma rea hierrquica, ou seja, todos os roteadores de cada rea precisam
manter um banco de dados sncrono para garantir o roteamento adequado dos pacotes IP.
atravs desse banco de dados topolgico que o processo do OSPF calcula o menor
caminho para cada destino, utilizando o algoritmo SPF Short Path First. O modo de funcionamento desse algoritmo foi detalhado e exemplificado na sesso de aprendizagem 3 do
curso "Protocolos de Roteamento IP".
Captulo 1 - Funcionamento do banco de

dados do OSPF
Database ou LSDB).
O banco de dados topolgico do OSPF criado a partir dos LSAs, ou Link State Advertisements,
que so as estruturas de dados responsveis pelas informaes topolgicas dos roteadores
OSPF, ou seja, contm informaes sobre o estado de cada enlace pelo qual um determinado
roteador responsvel. Nas mensagens LSA esto indicados o prefixo IP e a mscara de
subrede do enlace, qual o roteador responsvel pelo prefixo, qual a mtrica (ou custo) para
alcanar aquele destino, um tempo de expirao e outras informaes.
atravs dessas informaes que o algoritmo SPF define qual o melhor caminho para
alcanar um destino IP. Aps essa definio, uma rota IP criada e enviada para o software
gerenciador da tabela de rotas (Plano de Controle do roteador) decidir se vai ou no instalar
na tabela de rotas.
Para entender como o banco de dados topolgico montado e sincronizado, importante conhecer os tipos de pacotes OSPF existentes, como os pacotes funcionam e em que
momento eles so utilizados.
Tipos de pacotes OSPF

Sincronizao do banco de dados OSPF ocorre a partir de cinco pacotes OSPF:
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 nmero de protocolo 89), ou seja, no utiliza o protocolo TCP para garantir a
consistncia dos dados trocados. Ento, cabe ao prprio protocolo OSPF definir os mecanismos de controle e garantia na troca de informaes entre os roteadores OSPF. Entre
outros mtodos, o OSPF utiliza confirmao de recebimento, controle de verso por registro
e nmeros de sequncia.
De acordo com a RFC 2328, existem cinco pacotes OSPF que rodam sobre o protocolo IP e
so responsveis pelas operaes do OSPF, cada mtodo com sua abordagem de controle
e garantia. Esses cinco pacotes OSPF sero detalhados a seguir e seus cabealhos sero
apresentados. Porm, todos compartilham de um cabealho comum, ento importante
detalh-lo antecipadamente. Observe na figura 1.1 o formato desse cabealho, que possui
nove campos e 24 bytes de tamanho total sem autenticao (se utilizar autenticao MD5,
so 40 bytes).
Todos os cinco pacotes OSPF contm um cabealho comum de 24 bytes (sem autenti-
OSPF Avanado
cao com MD5) ou 40 bytes (com autenticao com MD5):
8 bits
8 bits
Verso=2
Tipo
32 bits
8 bits
8 bits
Tamanho do Pacote
Router ID
Area ID
Checksum
Tipo de Autenticao
Autenticao
Figura 1.1
Cabealho OSPF
compartilhado.
Autenticao
Os campos esto detalhados a seguir:
11 Verso: para o protocolo IPv4, a verso atual do protocolo OSPF a verso 2; para IPv6
a verso 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 cabealho e o contedo, sem contar com a mensagem de autenticao MD5;
11 Router ID: endereo IP selecionado pelo processo OSPF para identificar o roteador.
Geralmente est associado ao endereo 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 no na sua recepo. Usa o mesmo algoritmo do checksum do pacote IP;
11 Tipo de Autenticao: informa qual esquema de autenticao est sendo utilizado. Pode
assumir os seguintes valores:
22 0: Sem autenticao;
22 1: Autenticao simples, utilizando texto sem criptografia. Pode utilizar senhas de at
oito caracteres. Nesse tipo de autenticao, os dois campos Autenticao acima arma22 2: Autenticao criptogrfica. Nesse caso, os dois campos Autenticao assumem o
seguinte formato:
0x0000
Key ID
Tamanho
Nmero de Sequncia Criptogrco

33 Key ID: identifica a chave a ser utilizada (vrias chaves so possveis na configurao OSPF);
33 Tamanho: tamanho da mensagem criptogrfica (digest). Esse tamanho no est
incluso no tamanho informado anteriormente no campo Tamanho do Pacote;
33 Nmero de Sequncia Criptogrfico: utilizado para evitar ataques do tipo Replay,
por isso fica sempre incrementando.
22 Alm dessas modificaes no formato dos campos Autenticao do cabealho, o cabealho aumentado com mais um campo, de 16 bytes, onde a mensagem digest do MD5
inserida. Caso a autenticao com MD5 seja utilizada, o cabealho OSPF passa de 24

dados do OSPF
Figura 1.2
Informaes de
Criptografia do
cabealho OSPF
para MD5. Os
dois campos
Autenticao viram
novos campos.
zenam o valor da senha, como se fossem um nico campo;
bytes para 40 bytes. No final, o cabealho OSPF completo com autenticao MD5 teria a
estrutura apresentada na figura 1.3.
3
8 bits
8 bits
Verso=2
Tipo
32 bits
8 bits
8 bits
Tamanho do Pacote
Router ID
Area ID
Checksum
Tipo de Autenticao
0x0000
Key ID
Tamanho
Nmero de Sequncia Criptogrco
Digest MD5
11 Pacotes OSPF usam o protocolo IP com TTL de 1;
Figura 1.3
Cabealho OSPF
completo com
Autenticao MD5.
11 IP de origem do pacote OSPF sempre o IP da interface conectada rea, no o

Router-ID;
11 IP de destino pode ser o endereo IP do roteador adjacente ou um dos grupos multicast definidos: allSPFRouters (224.0.0.5) ou AllDRouters (224.0.0.6).
importante ressaltar que, por tratar apenas de adjacncias, todos os pacotes IP utilizados
pelo OSPF so criados para serem enviados apenas para os roteadores adjacentes e, por
isso, so criados com o campo Time to Live (TTL) do pacote IP configurado como "1". Isso
garante que os pacotes no sero roteados para outras redes da qual o roteador OSPF no
faz parte.
O endereo IP de origem dos pacotes OSPF sempre o endereo IP da interface de rede
onde existe a adjacncia, e o endereo IP de destino pode ser o endereo IP do roteador
OSPF adjacente ou um endereo IP multicast: AllSPFRouters (224.0.0.5) ou AllDRouters
(224.0.0.6).
A seguir, os pacotes OSPF e o uso sero detalhados.
Pacotes Hello
Pacotes Hello possuem diversas funes:
11 Descobrir roteadores OSPF adjacentes.
11 Estabelecer adjacncias com esses roteadores.
11 Manter as adjacncias.
OSPF Avanado
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.
11 Utiliza o grupo Multicast AllSPFRouters (224.0.0.5) em redes Broadcast e NBMA.
Relembrando: O OSPF pode funcionar em trs tipos diferentes de rede:

11 Redes Ponto-a-Ponto: conecta um par de roteadores;
11 Redes Broadcast: suportam mltiplos roteadores e endereo IP que
representam todos os roteadores da rede (endereo Broadcast);
11 Redes Non-Broadcast: suportam mltiplos roteadores, mas no suportam
broadcast. No contexto do OSPF, podem ser operadas de duas maneiras:
22 Simulao de uma rede Broadcast na rede Non-Broadcast, denominada
non-broadcast multi-access ou NBMA;
22 Tratando a rede como uma coleo de enlaces ponto-a-ponto, denominada
redes Ponto-a-Multiponto.
Apesar de ser um tipo de pacote do OSPF, o Hello tambm considerado um protocolo por
si s. Esse protocolo possui as seguintes responsabilidades:
11 Descobrir roteadores OSPF adjacentes;
11 Estabelecer adjacncias com esses roteadores;
11 Manter as adjacncias;
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
adjacncias so criadas, alm de ser o responsvel por detectar falhas de enlaces e roteadores. Por ser o primeiro pacote OSPF a ser utilizado, funciona enviando pacotes Hello
para o endereo IP multicast AllSPFRouters (224.0.0.5). Os roteadores OSPF que recebem o
pacote Hello enviam outro pacote Hello de volta para iniciar as adjacncias.
Formato do pacote Hello

A figura 1.4 apresenta o pacote Hello. Observe que o cabealho OSPF apresentado anteriormente simplificado, mostrando apenas o nmero que representa o tipo do pacote Hello,
dados do OSPF
que o tipo 1.
8 bits
8 bits
32 bits
8 bits
8 bits
Tipo=1
Cabealho OSPF
Mscara de sub-rede
Intervalo Hello
Opes
Prioridade
Intervalo de Roteador Morto

Designated Router
Backup Designated Router
Vizinhos Ativos
...
Vizinhos Ativos
Os campos esto detalhados a seguir:
11 Mscara de sub-rede: mscara de sub-rede da interface que est enviando o pacote
Hello. Essa mscara 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 discrepncias, a
adjacncia no ser estabelecida;
11 Opes: existem cinco tipos de opes definidas na RFC 2328. Essas opes so utilizadas para estender as capacidades do roteador OSPF, alm de informar outros roteadores dessas capacidades. As possibilidades so apresentadas a seguir:
22 E-bit: descreve como os LSA AS-External so anunciados na rede;
22 MC-bit : descreve se os datagramas IP multicast so 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 eleio do DR (Designated Router) e BDR (Backup Designated
OSPF Avanado
Router) em redes Broadcast e NBMA. Prioridade 0 significa que o roteador no ele-
gvel para virar DR ou BDR. O roteador com a maior prioridade eleito o DR;
11 Intervalo de Roteador Morto (Dead Interval): intervalo em segundos para definir que
o roteador adjacente est desconectado da rede e assim encerrar a adjacncia. Assim
como o Intervalo Hello, o valor tem de ser o mesmo nos roteadores conectados no
mesmo segmento. Em caso de discrepncias, a adjacncia no ser estabelecida;
Figura 1.4
Pacote Hello com
o cabealho OSPF
simplificado.
11 Designated Router: endereo IP da interface do DR no segmento de rede (no o Router-ID).

Caso no seja uma rede tipo Broadcast ou NBMA, esse campo preenchido com 0.0.0.0;
11 Backup Designated Router: endereo IP da interface do BDR no segmento de rede (no
o Router-ID). Caso no 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 vlidos. Em redes do tipo Broadcast e NBMA, so listados
todos os roteadores OSPF que fazem parte do segmento. Em redes ponto-a-ponto, o endereo IP do roteador remoto informado nesse campo.
Responsabilidades do protocolo Hello

O protocolo Hello responsvel por um conjunto grande de tarefas em uma rede OSPF, conforme citado anteriormente. Ento, de posse das informaes sobre os campos do pacote
Hello, as principais atividades tero seu funcionamento detalhado a seguir.
Descobrir roteadores OSPF adjacentes e estabelecer adjacncias

11 Protocolo Hello utilizado para descobrir e estabelecer as adjacncias.
11 As adjacncias OSPF so iniciadas logo aps um roteador OSPF detectar outro na rede.
11 A figura 1.5 ser usada para exemplificar o estabelecimento das adjacncias.
No momento em que o roteador OSPF finaliza sua inicializao e habilita suas interfaces,
o processo OSPF comea a enviar pacotes Hello por todas as interfaces que esto configuradas para fazerem parte do OSPF. Considere a topologia na figura a seguir.
R3
R4
10.1.1.0/24
s1/0
s0/0
11 Nesse exemplo, ambos os roteadores esto configurados na rea Backbone ou
rea 0.0.0.0;
11 Pacotes Hello so enviados;
11 Primeiro pacote no possui o campo Vizinho Ativo (Active Neighbor);
11 DR e BDR no so utilizados em enlaces seriais.
Ambos os roteadores R3 e R4 esto conectados por um enlace serial, utilizando o endereamento 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 roteador R4 acabou de ser ligado e configurado, e suponha tambm que ambos os roteadores
foram configurados com OSPF nas interfaces mostradas, todas na rea Backbone (tambm
conhecida como rea 0.0.0.0). No momento em que R4 inicia seu processo OSPF, suas estruturas de dados so criadas, porm o banco de dados topolgico 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:

dados do OSPF
Figura 1.5
Topologia de
Exemplo para
exemplificar a
funcionamento do
protocolo Hello.
Cabealho comum:
11 OSPF Version: 2;
11 Type: 1 (Pacote Hello);
11 Packet Length: 44 (24 bytes do cabealho 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 autenticao.
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 no tem DR);
11 Backup Designated Router: 0.0.0.0 (enlace serial no tem BDR).
Podemos observar que o campo de Vizinhos Ativos no est presente, pois o roteador
R4 ainda no conhece o roteador remoto.
R4 envia o primeiro pacote Hello:
Open Shortest Path First

OSPF Header
OSPF Version: 2
Message Type: Hello Packet (1)
Packet Length: 44
Source 0SPF Router: 10.1.1.2 (10.1.1.2)
Area ID: 0.0.0.0 (Backbone)
Packet Checksum: 0xe19b [correct]
Auth Type: Null
Auth Data (none)
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x12 (L, E)
Router Priority: 1
Figura 1.6
Captura do
primeiro pacote
Hello enviado
por R4.
Router Dead Interval: 40 seconds

Designated Router: 0.0.0.0
OSPF Avanado
Backup Designated Router: 0.0.0.0
Aps receber o pacote Hello vindo de R4 (10.1.1.2), o R3 envia um pacote Hello, conforme
figura 1.7.
11 R3 envia seu primeiro pacote Hello, porm aps receber o Hello do R4 (nesse exemplo);
11 Campo Vizinho Ativo ou Active Neighbor preenchido a partir do Hello do roteador R4;

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
Figura 1.7
Captura do pacote
Hello de R3 (Source
OSPF Router:
10.1.1.1

Active Neighbor: 10.1.1.2

OSPF Header
OSPF Version: 2
Packet Length: 48
Packet Checksum: 0xd695 [correct]
Auth Type: Null
Auth Data (none)
OSPF Hello Packet
Router Priority: 1
Figura 1.8
Captura do pacote
Hello de R4 agora
informando ter
visto R3.

Observe que o R3 envia um pacote Hello similar, porm com campo Source OSPF Router
indicando seu endereo 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 prxima 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 estabelecer a adjacncia. Outros pontos que requerem ateno:

dados do OSPF
11 Na figura 1.6, o Packet Length tinha 44 bytes, porm 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 endereo IP do vizinho nas figura 1.7 e figura 1.8 (lembre-se de que o endereo IPv4 possui
4 bytes de tamanho, ou 32 bits);
11 A adjacncia s foi estabelecida devido aos roteadores possurem as mesmas configuraes
de temporizadores (Hello Interval e Router Dead Interval) e rea (0.0.0.0).
11 Observe os campos Packet Length: por que mudou?
11 Para evitar problemas ao criar adjacncias no OSPF, garanta que os temporizadores,

rea ID e mscara de subrede estejam sempre de acordo em todos os roteadores OSPF.
Processo de eleio dos roteadores Designated Router e Backup

Designated Router
11 Redes Broadcast e NBMA precisam ter um DR e um BDR por questes
de escalabilidade.
11 Roteadores da rea somente vo sincronizar com o DR.
11 Trs 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 comunicao com o DR e o BDR.
No cenrio do exemplo anterior, por ser uma rede ponto-a-ponto, o processo de estabelecimento de adjacncia foi bastante simplificado, uma vez que em circuitos ponto-a-ponto s
temos dois roteadores envolvidos. Porm, em redes tipo Broadcast ou NBMA, por questes
de escalabilidade, o processo requer etapas extras, para que sejam escolhidos os roteadores Designated Router e Backup Designated Router.
Esses papis existem nas redes Broadcast e NBMA para servirem de centralizadores de
atualizao das informaes topolgicas, 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, alm de reduzir a quantidade de mensagens trocadas. Nesses casos, teremos trs papis:
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 topolgico com os demais. Agora,
em caso de alteraes na rede, os roteadores DROthers tero de notificar o DR e o BDR
dessas alteraes, e o DR atualizar o banco de dados dos demais roteadores da rede. Para
OSPF Avanado
que o DROthers possam notificar apenas o DR e o BDR, um novo grupo multicast foi criado,
10
chamado de AllDRouters (224.0.0.6). Apesar de apenas o DR ser responsvel por encaminhar as atualizaes recebidas para os demais roteadores OSPF da rede, importante que
o BDR tambm seja notificado, uma vez que este ser o responsvel por substituir o DR em
caso de falha.
Para exemplificar o processo de escolha do DR e do BDR em uma rede Broadcast, vamos

utilizar a topologia proposta na figura 1.9.
R2
R1
f0/0
f0/0
SW1
1
10.1.0.0/24
f0/0
Figura 1.9
Rede tipo
Broadcast.
R3
Nessa topologia, o roteador R1 possui endereo IP 10.1.0.1, o roteador R2 possui endereo
10.1.0.2 e o roteador R3 possui endereo 10.1.0.3. O switch (sw1) na figura 1.9 atua sem configurao especial. O processo OSPF em cada roteador est configurado para operar apenas
na interface fastEthernet 0/0. Supondo que os roteadores R1 e R2 so inicializados e o R3
permanece desligado, o processo ocorrer da seguinte maneira:
a. Ambos os roteadores, ao terminarem de inicializar o processo OSPF, vo 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 verificao feita atravs 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 recm-inicializados e no existem outros roteadores,
ambos os roteadores enviaro pacotes Hello sem o campo Active Neighbors. Nesse momento,
c. Ao receberem o pacote Hello, cada roteador passar a enviar os prximos pacotes Hello
com o campo Active Neighbors indicando o IP do roteador remoto; por exemplo, R2 vai
enviar o pacote com Router-ID 10.1.0.2 e Active Neighbor 10.1.0.1;
d. Nesse momento, o processo de escolha do BDR iniciado. Caso algum roteador tenha
preenchido o prprio IP no campo Backup Designated Router, aquele com a maior Router
Priority ser escolhido. Em caso de empate, aquele com o endereo 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 endereo IP mais
alto ser escolhido. Aps esse processo, nesse exemplo, o R2 ser escolhido temporariamente como BDR, pois ambos esto com a Router Priority configurada com o valor
padro (1) e o Router-ID de R2 maior que o Router-ID de R1;

dados do OSPF
os campos Designated Router e Backup Designated Router esto preenchidos com 0.0.0.0;
11
e. Aps a escolha do R2 como BDR, o processo de escolha do DR iniciado. Caso mais de

um roteador tenha preenchido o prprio IP no campo Designated Router, aquele com a
maior Router Priority ser escolhido. Caso ambos tenham o mesmo valor de prioridade,
aquele com o endereo 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 tambm ser
considerado o Designated Router desse segmento;
f. Como o DR e o BDR no podem estar associados ao mesmo roteador, uma nova eleio
para o BDR estabelecida, seguindo os passos detalhados no passo D. Com isso, R1 ser
escolhido BDR do segmento;
g. Aps a escolha do novo BDR, o DR e o BDR ficaro com seus papis at que o processo
OSPF seja forado 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 eleio para o BDR
acontecer. Caso o BDR caia, apenas uma eleio 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 esto definidos, logo ele se caracterizar como DROther, estabelecendo adjacncias com o DR e o BDR.
11 Roteadores, ao entrarem na rede, verificam se j h um DR e/ou um BDR:
22 Checam os campos Designated Router e Backup Designated Router do pacote Hello;

11 Caso positivo, aceitam a escolha;
11 No exemplo, no existem outros roteadores, ento 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 endereo IP;
22 Roteadores com Router Priority 0 no so elegveis;
11 Aps escolha do BDR, processo de escolha do DR iniciado;
22 Mesmos critrios de desempate do processo do BDR;
11 DR e BDR no 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 sero os DROthers.
O fato de que, aps escolhidos, o DR e o BDR no mudam, mesmo com a entrada de outros
roteadores com prioridade mais alta, serve para garantir a estabilidade da rede, uma vez que a
OSPF Avanado
cada eleio todo o processo de adjacncia tem de ocorrer novamente, gerando instabilidade
12
no roteamento da rede. Observe na figura 1.10 o pacote Hello com o DR e o BDR definidos.

OSPF Header
OSPF Version: 2
Packet Length: 48
Packet Checksum: 0xc490 [correct]
Auth Type: Null
Auth Data (none)
OSPF He11o Packet
Router Priority: 1
Como ambos os roteadores esto 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 no poder ser candidato DR ou BDR.
Aps o estabelecimento das adjacncias, os roteadores OSPF precisam trocar informaes
de estado de enlace para, assim, sincronizar seus bancos de dados topolgicos e calcular a
melhor rota para cada destino. Essa troca de informao 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 Aps os roteadores OSPF tornarem-se adjacentes, os bancos de dados topolgicos
precisam ser sincronizados;

11 Pacotes Database Description so utilizados para esta atividade;
11 Pacotes DD so os pacotes OSPF do Tipo 2
11 Database Exchange Process iniciado:
22 Eleio Master/Slave;
22 Envio dos cabealhos LSA;
22 Verificao do aging para descobrir se o LSA mais novo ou no;
22 Caso verifique que no est atualizado, uma lista de cabealhos LSA criada para
solicitar o LSA completo no prximo passo;
22 Utiliza endereamento Unicast em redes Broadcast e NBMA e endereamento
Multicast em redes ponto a ponto.

dados do OSPF
Figura 1.10
R2 escolhido como
DR, R1 como BDR.
13
Aps os roteadores OSPF estabelecerem adjacncias, estes precisam verificar se seus

bancos de dados topolgicos esto sincronizados. Para essa tarefa, o pacote OSPF Database
Description DD (pacote OSPF tipo 2) utilizado. Durante o perodo chamado Database
Exchange Process, um processo de eleio de Master/Slave acontecer e, aps eleito, o
Master comear a enviar os cabealhos dos LSAs existentes no seu banco de dados topolgico. Como cada cabealho LSA contm um aging (tempo de existncia), o roteador Slave
conseguir verificar se seu banco de dados est mais atualizado ou no. Caso perceba que
no est, este registra essa informao para solicitar o LSA completo na prxima etapa.
O mesmo acontece com o Master, que ao receber o pacote DD do Slave verifica se seu banco
est atualizado a partir dos cabealhos LSAs recebidos e os respectivos tempos de aging.
Assim como o pacote Hello, o pacote DD tambm usa o cabealho OSPF apresentado anteriormente, adicionando apenas os campos listados a seguir. A troca dos pacotes de DD
ocorre utilizando endereamento Unicast (em redes Broadcast e NBMA) e Multicast
(em redes ponto a ponto).
8 bits
32 bits
8 bits
8 bits
8 bits
Tipo=2
Cabealho OSPF
MTU
Opes
00000 I M Ms
Nmero de Sequncia
Cabealhos LSA
11 MTU: tamanho do Maximum Transmission Unit da interface OSPF a ser utilizada para sincronismo dos bancos de dados topolgicos. Caso sejam diferentes entre os roteadores, o
processo de sincronismo no vai ocorrer;
11 Options: mesmas opes definidas no pacote Hello;
11 Bit I (Initial): caso esteja marcado com 1, indica que esse o primeiro pacote DD da
sequncia de sincronismo;
11 Bit M (More): caso esteja marcado com 1, indica que o pacote atual no o ltimo da
sequncia. 0 indica que o ltimo;
11 Bit MS (Master/Slave): se esse bit estiver marcado como 1, significa que roteador originador o Master na relao de sincronismo entre os dois roteadores. Se estiver marcado
como 0, esse roteador o Slave do processo;
11 Nmero de Sequncia: utilizado pelo Master para definir o sequenciamento dos pacotes DD;
OSPF Avanado
11 Cabealhos LSA: lista dos cabealhos de parte ou todos os LSAs contidos no banco de dados
do originador do pacote. A partir desse campo, o recebedor do pacote poder confirmar se
possui todos os LSAs e, caso no tenha, solicitar tais LSAs faltantes no prximo processo.
Para ilustrar, vamos utilizar a topologia apresentada na figura 1.9. Como as adjacncias 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
Figura 1.11
Pacote Database
Description.
Tambm usa o
cabealho OSPF.
OSPF Header
OSPF Header
OSPF version: 2
OSPF version: 2
Message Type: DB Description (2)
Packet Length: 32
Packet Length: 32
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)
DB Description: 0x07 (I, M, MS)
.... 0... = R: OOBResync bit is NOT set
.... .1.. = I: Init bit is SET
.... ..1. = M: More bit is SET
.... ...1 = MS: Master/Slave bit is SET
DD Sequence: 6258
DD Sequence: 7376
Figura 1.12
Database Exchange
Process: eleio
do Master.
Na figura 1.12 possvel observar que ambos os roteadores R1 (10.1.0.1) e R2 (10.1.0.2)
Figura 1.13
Database Exchange
Process: incio
da troca de
pacotes DD.
Na figura 1.13., o roteador R1 envia o pacote com o bit M/S configurado para 0, indicando
enviam o pacote DD informando serem Masters do processo. Cada um envia seu prprio
nmero de sequncia (R1 envia 6258 e R2 envia 7376).
ser o Slave da relao. No mesmo pacote R1 j envia o nmero de sequncia recebido do R2

(7376) e os cabealhos dos LSAs que esto no seu banco de dados (a explicao sobre LSA
se dar mais frente).
OSPF Header
OSPF version: 2
OSPF version: 2
Packet Length: 52
Packet Length: 32
Area ID: 0.0.0.0 (backbone)
Packet checksum: 0x7ffe [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
DB Description: 0x02 (M)
.... .0.. = I: Init bit is NOT SET
.... ...0 = MS: Master/Slave bit is NOT SET

DD Sequence: 7376
LSA Header

DD Sequence: 7376

dados do OSPF
OSPF Header
15
Na figura 1.14, podemos observar que o R2 envia agora os cabealhos dos seus LSAs com
um novo nmero de sequncia (7377) e o R1 confirma recebimento enviando um pacote DD
com o mesmo nmero de sequncia.
OSPF Header
OSPF Header
OSPF: version: 2
OSPF: version: 2
Packet Length: 32
Packet Length: 52
Packet checksum: 0x7f2e [correct]
Packet checksum: 0x8fe9 [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
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
.... ...0 = MS: Master/Slave bit is NOT set

DD Sequence: 7377

DD Sequence: 7377
LSA Header
Aps isso, R2 envia mais um pacote DD com o bit M configurado como 0 e um novo
nmero de sequncia (7378), indicando o fim do processo, e R1 confirma com um pacote DD
com o mesmo nmero. Agora, de posse dos cabealhos LSAs existentes no roteador remoto,
ambos os roteadores enviaro pacotes OSPF chamados Link State Request, solicitando os
LSAs completos para serem inseridos no banco de dados topolgico. O processo de requisio ser apresentado a seguir.
Link State Request ou LSR

11 Aps o Database Exchange Process, os roteadores OSPF tm uma lista com LSAs que
precisam ser solicitados.

11 A solicitao dos LSAs acontece via pacote OSPF Link State Request ou LSR.
11 Pacote OSPF do Tipo 3.
11 Tambm faz uso do cabealho OSPF, assim como o Hello e o DD.
11 Adiciona apenas trs campos novos, que podem ocorrer diversas vezes.
Concludo o Database Exchange Process, o prximo passo para o sincronismo dos bancos de
OSPF Avanado
dados solicitar os LSAs completos que cada roteador recebeu do roteador remoto, seja por
no possuir tal LSA, seja devido ao aging recebido ser mais novo que o existente no banco
de dados atual.
Para fazer tal requisio ao roteador remoto, o pacote OSPF Link State Request (pacote
OSPF tipo 3) utilizado. Tambm fazendo uso do mesmo cabealho do Hello e do DD,
esse pacote apenas adiciona trs campos, conforme pode ser visto na figura 1.15. Esses
campos podem se repetir.
16
Figura 1.14
Database Exchange
Process R2
enviando
seus LSAs.
8 bits
32 bits
8 bits
8 bits
8 bits
Tipo=3
Cabealho 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
State Request.
Advertising Router n
11 Tipo do LSA: identifica o tipo do LSA (os tipos esto 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 mltiplos LSAs no mesmo
pacote. Assim como a comunicao no Database Exchange Process, a comunicao entre
os roteadores OSPF ocorre utilizando endereamento Unicast (redes Broadcast e NBMA) e
Multicast (redes Ponto-a-Ponto). Na figura 1.16 possvel ver um pacote LSR sendo enviado
do R2 para R1:
OSPF Version: 2
Message Type: LS Request (3)
Packet Checksum: 0xdfd0 [correct]
Figura 1.16
Pacote LSR saindo
de R2 para R1.
Nesse caso, R2 est
solicitando o LSA
que tem os campos
circulados na figura.
Auth Type: Null

Auth Data (none)
Link State Request
Link-State Advertisement Type: Router-LSA (1)
Link State ID: 10.1.0.1
Advertising Router: 10.1.0.1 (10.1.0.1)
Uma vez enviado o LSR solicitando os LSAs que precisam ser atualizados, o roteador remoto
envia pacotes OSPF de Link State Update, que contm o LSA completo. A seguir ser explicado o formato desse pacote.

dados do OSPF
Packet Length: 36
17
Link State Update ou LSU

11 Recebido o Link State Request, o roteador OSPF receptor verifica no seu banco de
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 Tambm faz uso do cabealho OSPF.
Recebida a solicitao do LSA via pacote LSR, o roteador OSPF enviar um pacote OSPF Link
State Update, cujo tipo o 4. Esse pacote utiliza o mesmo cabealho 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.
8 bits
8 bits
32 bits
8 bits
8 bits
Tipo=4
Cabealho OSPF
Nmero de LSAs
LSAs
11 Nmero de LSAs: informa a quantidade de LSAs que esto sendo enviados nesse pacote;
11 LSAs: nesse campo so enviados os LSAs requisitados pelo LSR.
Na figura 1.18 possvel verificar um pacote LSU respondendo com um LSA completo.
Porm, para garantir que o roteador remoto realmente recebeu o LSU, o roteador remoto
precisa informar ao originador a confirmao de recebimento. Essa confirmao ocorre
OSPF Avanado
atravs do pacote OSPF Link State Acknowledgement ou LSAck.
18
Figura 1.17
Pacote Link State
Update. Apenas
dois campos
adicionados.
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
Resposta do R1 ao
LSR de R2.
Number of LSAs: 1
LS Type: Router-LSA
Os tipos e o contedo dos LSAs sero apresentados no item "Link State Advertisement ou LSA".
Link State Acknowledgement ou LSAck
11 Depois de enviado o LSU, o roteador OSPF precisa da confirmao do roteador

remoto que esse recebeu o pacote enviado.
11 A confirmao pode se dar de duas maneiras:
22 O receptor envia um pacote LSU com o mesmo contedo 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 Tambm utiliza o cabealho OSPF.
Como o LSU tambm ocorre em modo flooding: enviando as informaes 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 atravs do pacote LSAck. Essa confirmao ocorre quando o recebedor envia
os cabealhos do LSA no pacote LSAck, podendo confirmar um ou diversos LSAs em uma
8 bits
8 bits
32 bits
Tipo=5
Cabealho OSPF
Figura 1.19
Pacote Link State
Acknowledgement.
Cabealhos LSAs
8 bits
8 bits

dados do OSPF
nica mensagem. O LSAck o pacote de tipo nmero 5 do OSPF.
19
importante salientar que a especificao do OSPF tambm permite que a confirmao

se d atravs do prprio LSU, onde o recebedor enviaria um LSU de volta com os mesmos
dados. Em redes Broadcast ou NBMA, a confirmao pode ocorrer tambm via Unicast
(diretamente para o originador) ou via Multicast. Na figura 1.20, podemos observar a confirmao 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
LSAck do R2
para R1.
Auth Data (none)

LSA Header
Aps a confirmao de todos os LSAs recebidos por todos os roteadores OSPF, estes entram no
estado chamado FULL, uma vez que seus bancos de dados esto sincronizados. A partir desse
momento, apenas alteraes de estado dos enlaces geraro novas atualizaes na rede.
11 Aps todos os LSA serem trocados e confirmados, os roteadores entram no
estado FULL;
11 Nesse estado, o algoritmo SFP faz o clculo das rotas para serem inseridas no roteador;
11 S haver novos LSU/LSAck em caso de alteraes no estado de algum enlace:
22 Enlace inativo, queda de circuito, queda de roteador etc.;
11 Caso o LSA no seja atualizado por 30 minutos, o roteador deve anunci-lo novamente para os roteadores da rea:
22 Garantir que os bancos de dados esto sincronizados;
22 Esse tempo chamado de LSRefreshTime e fixo;
22 Nota: o anncio feito por LSA, e no de todo o banco de dados.
Apesar do protocolo OSPF s enviar notificaes de atualizaes quando estas ocorrem (por
exemplo, um enlace fica inativo), para garantir que todos os bancos de dados esto atualizados,
toda vez que um LSA atingir o tempo aging de 30 minutos, uma atualizao ser enviada para
o grupo Multicast AllSPFRouters, mesmo que no final o mesmo LSA permanea no banco de
dados OSPF. Esse tempo fixo e chamado de LSRefreshTime na especificao do OSPF.
importante salientar que o anncio feito por LSA, e no para todo o banco de dados.
OSPF Avanado
O OSPF no faz flooding da tabela de roteamento ou do banco de dados topolgico.
20
Transio de Estados no Sincronismo do OSPF

Cada etapa do processo de sincronizao do banco de dados topolgico do OSPF tem um
nome de estado associado. Esses nomes so importantes para entender o funcionamento
do OSPF e para a resoluo de problemas. A figura 1.21 ilustra essa transio de estados.
R1
R2
DOWN
DOWN
HELLO (DR=0, Vizinhos=0)
HELLO (DR=R2, Vizinhos=R1)
ExStart
D-D (Seq =X, I, M, Master)

D-D (Seq =Y, l, M, Master)
Exchange
INIT
ExStart
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)
Loading
D-D (Seq =Y+n, Slave)

LS Request
Full
LS Update
LS Request
LS Update
Full
De maneira resumida, o processo de sincronizao 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
indicao de vizinhos ativos;
b. R2 recebe o pacote Hello, e sai do estado DOWN para o estado INIT. R2 ento 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 endereo IP no campo de vizinhos ativos,
R1 sai do estado DOWN e passa para o estado ExStart. Nesse estado, R1 e R2 faro a
verificao do banco de dados topolgicos 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 adjacncia, e sai do
estado INIT para o estado ExStart, e envia um pacote DD para R1 tambm 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
nmero de sequncia informado por R2;
f. R2 recebe o pacote DD com seu nmero de sequncia e passa para o estado Exchange. A
partir desse momento, comea a troca de mensagens DD com os cabealhos dos LSAs de
cada banco de dados;
g. Aps todos os cabealhos serem trocados, R1 entra no estado de Loading, pois agora vai
solicitar os LSAs completos de R2. Mensagens de LSR so enviadas com os cabealhos
dos LSA desejados;

dados do OSPF
Figura 1.21
Transio de
estados OSPF.
21
h. Ao receber o LSR vindo de R1, se o R2 no 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 no precisar de informaes 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 confirmao de recebimento com os
LSAck e entrar no estado FULL tambm. A partir desse momento, o banco de dados OSPF
estar completo e as rotas sero 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 adjacncias sero criadas, porm os roteadores
DROthers ficaro parados no estado ExStart (ou 2-Way para alguns fabricantes) entre eles,
pois no h necessidade do sincronismo. Em redes no Broadcast e NBMA, onde no 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
(DROther)e o DR;
22 Entre os DROthers, o maior estado o ExStart;
11 Em redes Ponto-a-Ponto, ambos os roteadores tm de chegar ao estado FULL.
Agora que o processo de sincronizao do banco de dados topolgico j est claro, ser
apresentada a estrutura de dados chamada Link State Advertisement, ou LSA, que so as
estruturas que contm as informaes topolgicas que populam o banco de dados do OSPF.
Link State Advertisement ou LSA

11 Link State Advertisement a estrutura de dados responsvel por armazenar as infor-
maes sobre os estados de enlaces;

22 Endereo IP, mscara de sub-rede, mtrica etc.;
11 Pacotes OSPF DD e LSR usam apenas o cabealho; pacote LSU usa o LSA completo;
11 Atravs das informaes no LSA que o roteador faz os clculos para definir as rotas;
11 Existem onze tipos, porm 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 responsvel por armazenar as diversas
informaes usadas pelo processo OSPF sobre os estados de enlaces, como tipo de enlace,
IP, mscara de subrede, mtrica, origem etc. Foi apresentado anteriormente que, nos
pacotes OSPF DD e LSR, apenas o cabealho do LSA trocado, enquanto que no LSU o LSA
completo enviado.
Como os LSAs so os responsveis por todas as informaes e mtricas da rede OSPF,
diversos tipos foram criados, com propsitos especficos. Na tabela 1.1, os onze tipos existentes atualmente para IPv4 so apresentados. Porm, nas redes OSPF atuais, apenas seis
tipos so realmente utilizados e sero detalhados nas sesses a seguir: router LSA, Network
OSPF Avanado
LSA, Network Summary LSA, ASBR Summary LSA, AS External LSA e NSSA External LSA.
22
Tabela 1.1
Lista dos tipos
de LSA.
Cdigo
Nome
Quem faz uso?
Descrio
Definio
Router LSA
Todos
Descreve o ambiente
do roteador, interfaces, mtricas
RFC2328
Network LSA
DR
Informa todos os
roteadores na rede
Broadcast/NBMA
RFC2328
Network Summary
LSA
ABRs
Anuncia rotas de
outra rea do OSPF
RFC2328
ASBR Summary LSA
ABRs
Anuncia a rota para

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

do AS
RFC2328
Group Membership
LSA
Usado para Multicast

OSPF
RFC1584
NSSA External LSA
ASBRs em NSSA
Anuncia rota de fora

do AS
RFC3101
External Attributes
LSA
Possvel substituto
do iBGP
Pendente
Opaque LSA
Usado em MPLS
RFC5250
10
Opaque LSA
Usado em MPLS
RFC5250
11
Opaque LSA
Usado em MPLS
RFC5250
Assim como os pacotes OSPF, o LSA tambm tem um cabealho que compartilhado por
todos os tipos de LSA. Esse cabealho possui 20 Bytes e est apresentado na figura 1.22,
sendo detalhado a seguir.
8 bits
8 bits
32 bits
Age
8 bits
8 bits
Opes
Tipo
Advertising Router
Figura 1.22
Cabealho LSA
utilizado por todos
os tipos de LSA.
Sequence Number
Checksum
Tamanho
11 Age (Tempo de vida): tempo em segundos desde que o LSA foi gerado;
11 Opes: mesmas definies do campo de Opes do protocolo Hello;
11 Tipo: identifica o Tipo do LSA;
11 Link-State ID: contedo 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 verso do LSA;

dados do OSPF
Link-State ID
23
11 Checksum: utilizado para garantir integridade. No inclui o campo Age;

11 Tamanho: tamanho do LSA em Bytes, incluindo o cabealho.
A seguir, os principais tipos de LSA sero apresentados, e seus cabealhos sero detalhados,
bem como seu modo de uso.
Router LSA
11 Router LSA utilizado para informar os roteadores adjacentes com informaes
como Router-ID, enlaces locais e mtricas de sada.

11 Esse o primeiro LSA enviado pelo roteador OSPF;
11 Contm todas as informaes de todos os enlaces que o roteador possui;
11 Todas as informaes 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 informaes como Router-ID, enlaces locais e mtricas de sada. Esse o primeiro LSA
enviado pelo roteador e nele devem conter todas as informaes 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 cabealho LSA, detalhado na figura 1.22.
8 bits
32 bits
8 bits
Age
8 bits
8 bits
Opes
Tipo = 1
Link-State ID
Advertising Router
Sequence Number
Checksum
00000 V E B
Tamanho
0x00
Nmero de Links
Link ID
Link Data
Tipo de Link
Nmero TOS
Mtrica
TOS
0x00
Mtrica TOS
A seguir, os campos do Router LSA so apresentados:
OSPF Avanado
11 Bit V (Virtual): informa se o roteador a ponta de um Virtual Link;
24
11 Bit E (External): indica que o roteador originador um ASBR;

11 Bit B (Border): indica que o roteador originador um ABR;
11 Nmero de Links: nmero de enlaces includos no LSA.
Figura 1.23
Router LSA.
Os campos a seguir so 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: contedo depende do Tipo de Link;
11 Tipo de Link: informa o tipo de enlace e define o contedo dos campos Link ID e Link
Data. Os tipos esto informados na tabela 1.2;
11 Nmero TOS: no utilizado;
11 Mtrica: custo do enlace;
11 TOS: no utilizado, mantido por compatibilidade com o OSPFv1;
11 Mtrica TOS: no utilizado, mantido por compatibilidade com o OSPFv1.
Tipo de
Link
Tipo de Conexo
Descrio
Valor do Link
ID
Valor do Link Data
Ponto a Ponto
Uma conexo para outro roteador
Router-ID do
Vizinho
IP da interface do
roteador originador
Rede de Trnsito
Carrega trfego de trnsito
IP da interface
do DR
IP da interface do
roteador originador
Rede Stub
Deve carregar pacotes tendo o

Router-ID como origem ou destino
Prefixo da
Rede IP
IP da Rede Stub ou
Mscara de Rede
Virtual Link
Usado por virtual links
Router-ID do
Vizinho
Valor of Ifindex do
Virtual
11 A partir do Tipos de Link, o valor dos campos Link ID e Link Data podem mudar
A utilizao dos campos da tabela 1.2 ser apresentada na sesso de aprendizagem 2,

reas OSPF, bem como exemplos.
Network LSA
11 LSA tipo 2;
11 Network LSA utilizado pelo Designated Router para informar aos demais roteadores
OSPF da rea sobre os roteadores com os quais o DR possui adjacncias;
11 Essa informao utilizada para saber quais roteadores esto na mesma sub-rede e
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 adjacncias.
A estrutura da Network LSA est apresentada na figura 1.24. possvel verificar que este
mais simples que o Router LSA.

dados do OSPF
Tabela 1.2
Router LSA:
tipos de Link.
25
8 bits
8 bits
32 bits
Age
8 bits
8 bits
Opes
Tipo = 2
Link-State ID
Advertising Router
Sequence Number
Checksum
Tamanho
Mscara de Sub-rede
Roteador Ativo
Figura 1.24
Network LSA.
Roteador Ativo
Os campos so preenchidos da seguinte maneira:
11 Link-State ID: endereo IP da interface do DR na rea;
11 Mscara de Sub-rede: mscara de sub-rede da interface do DR conectada rea;
11 Roteador Ativo: router-ID dos roteadores com os quais o DR possui adjacncia.
Network Summary LSA e ASBR Summary LSA

11 Network Summary LSA o Tipo 3.
11 ASBR Summary LSA o Tipo 4.

11 Ambos so 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 endereo IP dos roteadores ASBR:
Autonomous System Boundary Routers.
11 O formato dos campos o mesmo, porm o preenchimento varia nos seguintes campos:
22 Tipo.
22 Link-State ID.
22 Mscara de Sub-rede.
11 Tambm 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 so
idnticos. As nicas diferenas ento no preenchimento dos campos Tipo, Link-State ID e
Mscara 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 Mscara de sub-rede preen OSPF Avanado
chido com a mscara do prefixo informado. Caso o ABR queira, possvel fazer agregao dos
26
prefixos, alm de ser possvel o envio da rota padro (ou rota default). No caso da rota padro,
ambos os campos Link-State ID e Mscara de Sub-rede so preenchidos com o valor 0.0.0.0.
O ASBR Summary LSA utilizado pelo ABR para informar sobre os roteadores ASBR existentes 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 endereo de loopback). Nesse caso, o campo
Mscara de Sub-rede no tem serventia e preenchido com o valor 0.0.0.0.
8 bits
8 bits
32 bits
Age
8 bits
8 bits
Opes
Tipo = 3 ou 4
Link-State ID
Advertising Router
Sequence Number
Checksum
Tamanho
Mscara de Sub-rede
Network ou ASBR
Summary LSA.
0x00
Mtrica
TOS
Mtrica TOS
O campo Mtrica preenchido com o custo associado para se chegar ao endereo IP informado no campo Link-State ID. Os campos TOS e Mtrica TOS no so utilizados.
AS External LSA
11 LSA Tipo 5.
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 no possuem relao com nenhuma rea e por isso so transportados 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: alm do custo externo, adiciona o custo interno da rede para alcanar o
ASBR.
22 Tipo 2: somente tem o custo externo.
Quando um ASBR precisa enviar rotas que so externas ao AS ou externas ao processo OSPF
(redistribuio, por exemplo), o ASBR o faz enviando LSAs do tipo 5, ou AS External LSA.
Esse LSA enviado para todas as reas OSPF, com exceo 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 Mscara de Sub-rede: mscara de sub-rede do prefixo IP a ser anunciado;

dados do OSPF
Figura 1.25
27
11 Bit E (External): utilizado para marcar a rota com duas opes: e1 ou E2. Quando o bit
E est configurado com 0, a rota dita E1 e possui como mtrica 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 mtrica apenas o custo externo.
No caso da rota E2, o custo maior que qualquer outro enlace interno. A configurao
padro configurar a rota como E2.
11 Mtrica: custo da rota;
11 Endereo de Encaminhamento: endereo IP do roteador responsvel pelo prefixo. Se
estiver configurado como 0.0.0.0, significa que para enviar para o prprio ASBR;
11 Tag da Rota Externa: campo extra, que pode ser utilizado pelas polticas de roteamento
do AS. No utilizado pelo OSPF em si.
Os campos TOS, Mtrica TOS, Endereo de Encaminhamento TOS e Tag da Rota Externa TOS so
campos de compatibilidade, e no so utilizados.
8 bits
8 bits
32 bits
Age
8 bits
8 bits
Opes
Tipo = 5
Link-State ID
Advertising Router
Sequence Number
Checksum
Tamanho
Mscara de Sub-rede
E 0000000
Mtrica
Endereo
Endereode
deEncaminhamento
Encaminhamento
Tag da Rota Externa
E TOS
Mtrica TOS
Endereo de Encaminhamento TOS
Figura 1.26
AS External LSA.
Tag da Rota Externa TOS
NSSA External LSA

11 LSA Tipo 7.
11 Tambm criado pelo ASBR, quando este est em uma rea Not-so-Stub-Area.
11 Mesmo cabealho do AS External LSA, porm preenchimento diferente no campo
Endereo de Encaminhamento.
OSPF Avanado
11 Por padro, o NSSA External LSA traduzido para AS External LSA nos ABRs.
28
O LSA tipo 7 o NSSA External LSA. Esse LSA tambm criado pelo ASBR, porm, apenas
quando o ASBR est dentro de uma rea NSSA (Not-so-Stub-Area). Todos os campos so
utilizados da mesma maneira que no AS External LSA, com exceo do campo Endereo de
Encaminhamento. O NSSA External LSA est detalhado na figura 1.27.
8 bits
32 bits
8 bits
Age
8 bits
8 bits
Opes
Tipo = 7
Link-State ID
Advertising Router
Sequence Number
Checksum
Tamanho
Mscara de Sub-rede
E 0000000
Mtrica
Endereo
Endereode
deEncaminhamento
Encaminhamento
Tag da Rota Externa
E TOS
Mtrica TOS
Endereo de Encaminhamento TOS
Figura 1.27
NSSA External LSA.
Tag da Rota Externa TOS

O campo Endereo de Encaminhamento pode assumir um dos seguintes valores:
11 Endereo IP do roteador na rede responsvel pelo prefixo se a rede j for redistribuda
como interna; por exemplo, redistribuio do protocolo RIP;
11 Router-ID do roteador ASBR caso seja uma rota externa ao AS.
Remoo de LSAs
11 A remoo de um LSA do LSDB pode ocorrer devido a dois fatores:
22 LSA aging atinge o MaxAge.
22 Acontece alguma alterao topolgica na rede.
11 Alteraes topolgicas 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 mudana de estado, duas aes podem fazer a remoo de um LSA do LSDB.
22 Expirao da adjacncia detectada pelo protocolo Hello.
22 Envio de LSU com o LSA atualizado.
11 A Figura 1.28 mostra uma topologia onde a expirao via protocolo Hello aconteceria.
11 A figura 1.29 mostra uma topologia onde o envio de um LSU acontece.

dados do OSPF
A utilizao dos seis LSAs apresentados at aqui ser demonstrada na sesso 2.
29
Conforme mencionado anteriormente, uma vez no estado FULL, os roteadores OSPF no

enviam novas atualizaes de estado de enlace a menos que:
11 O aging do LSA atinje o LSRefreshTime (30 minutos);
11 Haja alguma alterao topolgica na rede.
Alteraes topolgicas 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 adio de enlace ou roteador foram explicados anteriormente,
porm, importante detalhar como os prefixos so removidos do LSDB. A remoo de um
LSA do LSDB acontece, na maioria dos casos, diante de dois cenrios:
11 Expirao da adjacncia detectada via protocolo Hello;
11 Envio de LSU com LSA atualizado informando a alterao.
Vamos utilizar como exemplo a topologia da figura 1.28. Nessa rede Broadcast, todos os
roteadores esto conectados a um switch Ethernet. Todos os trs roteadores enviam, a cada
intervalo definido no protocolo Hello (Interval), um pacote Hello para garantir que a adjacncia
est formada. Suponha agora que todas as adjacncias esto formadas, porm, em algum
momento futuro, o roteador R1 muda de estado para DOWN (por falta de energia, interveno
do administrador, problemas no equipamento etc.). Como eles esto interconectados via um
switch Ethernet, as interfaces f0/0 dos roteadores R2 e R3 vo continuar UP, e aps o Dead
Interval do protocolo Hello, R2 e R3 vo ter as entradas LSA referentes ao roteador R1 removidas do LSDB. Essa remoo acontecer devido expirao da adjacncia OSPF.
R2
R1
f0/0
f0/0
SW1
1
10.1.0.0/24
f0/0
R3
Observe agora topologia da figura 1.29. Nessa figura, temos dois momentos: momento
OSPF Avanado
A, onde a rede est funcional entre os roteadores R1, R2 e R3, com todos os roteadores
30
no estado FULL. Nesse estado, o roteamento acontece normalmente e os trs roteadores

possuem o mesmo LSDB.
Assuma agora que algum tempo depois o enlace entre R1 e R2 mudou de estado, de UP para
DOWN. Esse novo estado est representado pelo Momento B da figura 1.29.
Figura 1.28
Rede Broadcast.
F0/0
a.
.1
10.1.2.0/24 F0/0
.2
R1
.1
.2
R2
F0/0
b.
10.2.3.0/24 F0/0
.1
10.1.2.0/24 F0/0
F0/1
.2
R1
R3
10.2.3.0/24 F0/0
.1
R2
.2
LSU + LSA
R3
Aps a queda do enlace entre R1 e R2, houve uma mudana no estado do enlace da
interface f0/0 do roteador R2, e essa mudana precisa ser informada ao roteador R3.
Essa mudana ser informada atravs 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 perodo no LSDB deve ser
removido, pois subentende-se que no foi atualizado no tempo LSRefreshTime. Ento,
possvel um roteador OSPF informar outro roteador da remoo de um LSA simplesmente preenchendo o campo Age do cabealho do LSA com o valor MaxAge. Essa abordagem utilizada principalmente pelo Network-LSA;
11 Mtrica: uma outra constante que pode ser utilizada para informar que o LSA deve ser
removido a LSInfinity. Essa constante, utilizada como mtrica mxima (infinita) do
OSPF, definida com os 24 bits todos configurados como 1 (0xffffff). Ou seja, caso o LSA
tenha seu campo Mtrica 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.
Concluso
Nesta sesso, 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 so utilizados pelos roteadores OSPF para sincronizar os bancos de dados.
Alm disso, o LSA, seus seis principais tipos e seus papis tambm foram apresentados.
De posse dessas informaes, ser possvel entender como o OSPF cria o conceito de hierarquia em reas, e como e quais LSAs so filtrados e/ou encaminhados pelos ABRs para
que a hierarquia e a escalabilidade da rede OSPF possa ser alcanada. Na prxima sesso,
essa interao entre LSA, pacotes OSPF e as reas ser apresentada, permitindo ao aluno
planejar, projetar e operar as mais diversas configuraes de redes OSPF existentes.

dados do OSPF
Figura 1.29
Rede Broadcast
com momentos
A e B.
F0/1
31
Comandos OSPF
A seguir, uma lista de comandos de configurao que tm relao com os temas abordados
na sesso de aprendizagem 1, para serem utilizados no Quagga. Os comandos a seguir so
aplicados por interface.
11 Altera o tempo em segundos entre pacotes Hello (padro de 10 segundos):
ip ospf hello-interval <1-65535>
11 Altera o tempo em segundos para considerar um vizinho como inativo (padro de

40 segundos):
ip ospf dead-interval <1-65535>: tempo para considerar o vizinho como inativo
11 Fast Hello: nmero 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 no elegvel:

ip ospf priority <0-255>
11 Configura autenticao simples:

ip ospf authentication-key SENHA
11 Configura autenticao MD5:

ip ospf authentication message-digest
ip ospf message-digest-key <1-255> md5 SENHA
A seguir, uma lista dos comandos de observao que tm relao com os assuntos abordados na sesso de aprendizagem 1:
11 Exibe informaes sobre o processo OSPF:
show ip ospf
11 Exibe informaes resumidas sobre o banco de dados OSPF:

show ip ospf database
11 Exibe informaes resumidas sobre o banco de dados OSPF por tipo de LSA:
show ip ospf database <router|network|summary|asbr-summary|external|nssaexternal>
11 Exibe informaes sobre o processo OSPF em uma determinada interface:

show ip ospf interfaces
OSPF Avanado
11 Exibe as adjacncias OSPF estabelecidas:
32
show ip ospf neighbor
2
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 so 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 idntico em todos os roteadores da rede.
11 Redes muito grandes possuem LSDB muito grandes.

22 Aumenta o consumo de memria e CPU.
22 Diminui o tempo de convergncia 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 criao e manuteno
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 mtricas. A partir desse banco de dados, as rotas para todos os destinos so
calculadas, otimizadas para usar o melhor caminho possvel e garantir que no haver loops
de roteamento.
Para que isso acontea, imprescindvel que todos os roteadores da rede tenham exatamente
o mesmo LSDB. Em redes pequenas e mdias, com poucos roteadores, a complexidade para
manter esse LSDB sincronizado e a rede estvel bem pequena. Porm, em redes grandes,
com mais de vinte roteadores, maior a quantidade de enlaces e maior a quantidade de
possveis caminhos para chegar at um determinado endereo 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 situaes adversas que fazem
com que oscilem. Com essas oscilaes, toda vez que um enlace enfrenta uma indisponibilidade, ou seja, ocorre uma mudana do estado do enlace, o roteador responsvel por tal
Captulo 2 - Entendendo as reas do OSPF
objetivos
Entendendo as reas do OSPF
33
enlace deve informar todos os outros roteadores que compartilham do mesmo LSDB. Cada
roteador dever fazer a confirmao (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 Especificao do OSPF permite o particionamento da rede: reas;
11 reas so utilizadas para criar redes OSPF menores;

11 Topologia da rea transparente para as demais reas;
11 Com LSDB menor, menos recursos computacionais so necessrios;
11 Cada rea no ABR possui um LSDB separado;
11 Roteamento Intra-Area no necessita de informaes externas.
Diante dessa situao, a especificao 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 pedaos da rede sejam criados, gerando LSDBs menores que
podem ser processados de maneira mais rpida, economizando recursos computacionais dos
roteadores e diminuindo o tempo de convergncia da rede. Essas reas podem ser criadas
para agrupar roteadores com papis similares, por exemplo, roteadores de datacenter;
roteadores conectados a servios menos confiveis, como enlaces seriais; ou mesmo para
permitir que roteadores com menos recursos de CPU e memria possam fazer parte do
roteamento dinmico da rede.
Para permitir que as reas sejam alcanveis dentro da rede, roteadores chamados de Area
Border Routers (ABR) so conectados a duas ou mais reas ao mesmo tempo, efetuando o
roteamento entre estas. No roteador ABR, a quantidade de LSDBs vai depender da quantidade 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 trs reas OSPF, o ABR ter trs LSDB separados, e assim sucessivamente.
Por causa disso, os roteadores ABR so 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 informaes da sua rea, a topologia externa completamente transparente. O trfego que roteado dentro de uma rea
(intra-area) endereo de origem e de destino esto inclusos no mesmo LSDB: no necessita
de informao alguma externa quela rea. No trfego em que o endereo de destino ou o de
origem so de reas diferentes, informaes de roteamento vindas do ABR so necessrias.
11 Para fazer a interconexo entre reas, o roteador ABR utilizado:
22 LSAs Router e Network ficam confinados por rea;

22 LSA Summary gerado para permitir a alcanabilidade da rede.
11 LSA Externos continuam sendo encaminhados entre reas (menos reas Stub e NSSA).
OSPF Avanado
A transparncia criada pelo ABR feita atravs da filtragem dos Link State Advertisements:
34
em vez de encaminhar os LSAs Router e Network entre reas, o ABR gera um sumrio e
envia um LSA Summary para a rea remota, que assim passa a saber quais prefixos so
alcanveis dentro de cada rea. Como no LSA Summary no h indicaes de como os
enlaces esto conectados, os roteadores externos no precisam gerar toda a rvore SFP por
enlace. Logo, o processo SFP simplificado.
Para fazer o particionamento de uma rede OSPF em reas, importante conhecer quais so
as reas suportadas, como elas funcionam e como se relacionam. Alm disso, fundamental
saber quais so os LSAs utilizados por cada roteador de cada rea e como eles so filtrados
ou gerados nos ABRs.
Quais so os tipos de reas e como elas se comportam em

um ambiente OSPF
11 As RFCs 2328 e 3101 definem a criao das seguintes reas OSPF:
22 rea Backbone.
22 rea No Backbone.
33 rea "Normal".
33 rea Stub.
33 rea Not-So-Stubby.
22 Virtual-Links.
A RFC 2328 possui as definies das principais reas atualmente suportadas pelo OSPF.
So elas:
11 rea 0 ou Backbone: rea principal do OSPF, conecta todos os ABRs;
11 rea No Backbone: rea OSPF, que est conectada rea Backbone.
Para aumentar o controle, a flexibilidade e a escalabilidade do LSDB, as reas no 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, porm no suporta LSAs Tipo 5
e Tipo 7.
Alm destas, a RFC 3101 adicionou uma nova rea No 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 no pode ser particionada, ou seja, deve ser contgua ao longo de toda a
rede do Sistema Autnomo. Em casos onde ocorre esse particionamento, seja por roteador ou enlace indisponvel, necessrio que essas duas partes da rea Backbone sejam
reconectadas atravs de Virtual Links, que um recurso criado justamente para reconectar
reas, sejam parties da mesma rea Backbone ou reas No Backbone rea Backbone.
uso das reas OSPF.
A seguir cada rea OSPF ser detalhada. A figura 2.1, a seguir, ser utilizada como caso de
35
R1
R3
rea Backbone
R6
Rede 1
R2
R5
Rede 3
Rede 2
R4
R7
rea 2
R8
rea 3
rea 4
Internet
BGP
R9
R10
Rede 4
Rede 5
rea Backbone
11 Conhecida como rea 0 ou rea 0.0.0.0. o ncleo da rede.
R11
Rede 6
11 Responsvel por interconectar todas as demais reas.

11 No pode ser particionada.
11 Deve possuir roteadores com memria e CPU suficientes para manipular vrios LSDBs.
A rea Backbone, tambm conhecida como rea 0 ou rea 0.0.0.0, considerada a principal
rea OSPF, pois a responsvel por interconectar todas as demais reas OSPF. Nessa rea
esto todos os roteadores ABR, ou seja, todas as reas devem estar diretamente conectadas
rea Backbone. Por ser a rea principal, essa rea no pode ser particionada. Por isso,
o engenheiro de redes responsvel pela configurao da rede OSPF deve ter cuidado na
definio da rede.
Alm disso, devido ao fato de ter todos os ABRs e todos os tipos de LSA, incluindo Summary
e AS-Externo, a rea Backbone tambm deve possuir roteadores com memria e processamento suficiente para manipular o LSDB. Na figura 2.1, os roteadores R3, R4, R5, R6 e
OSPF Avanado
R7 fazem parte da rea Backbone. Desses, R3, R4 e R7 so roteadores ABR e R5 e R6 so
36
Roteadores Internos (Internal Routers). Observe na figura que no OSPF o roteador pode ter
interfaces em diversas reas.
Figura 2.1
Rede OSPF com
Diversas reas.
rea Normal
11 Aceita LSAs Externos.
11 No faz trnsito.
11 Roteadores com perfis similares.
11 Geralmente possui mltiplos roteadores ABRs.
Apesar de suportar os principais LSAs (Router, Network, Summary, ASBR-Summary e
AS-External), as reas Normais so diferentes da rea Backbone, pois no fazem trnsito
ao longo da sua extenso (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 mltiplos roteadores
ABR conectados rea Backbone. Na figura 2.1, a rea 2 pode ser caracterizada como uma
rea Normal, pois no prov trnsito para outras reas OSPF, alm de possuir dois ABRs.
As reas 3 e 4 podem ser consideradas reas Normais mesmo tendo apenas um
ABR. A especificao do OSPF apenas sugere mais de um ABR. Em casos com apenas
um ABR, a sugesto configurar rea Stub.
rea Stub
11 rea Stub
11 Usada quando
22 Roteadores com recursos computacionais limitados
22 Apenas um ABR por rea
11 Opo de LSA-Summary gerado pelo ABR com a rota padro
11 LSA Externos so descartados (AS External LSA e NSSA-LSA)
As reas Stubs so muito utilizadas em cenrios onde os roteadores que fazem parte da
rea no 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. possvel observar que a rea 3 e a rea 4 possuem mais de um roteador OSPF
por rea, porm apenas um roteador ABR.
Nesse caso, no faria sentido que os roteadores R8, R9, R10 e R11 tivessem informaes
sobre a topologia da rea 2 ou da rea Backbone, por exemplo, pois todo acesso s outras
gurar os roteadores como fazendo parte de uma rea Stub, e o ABR de cada rea gerar uma
rota padro (default route) que seria enviada para os demais roteadores da rea. Nesse caso,
R8 e R9 receberiam uma rota padro vinda do roteador R4 e os roteadores R10 e R11 receberiam uma rota padro vinda do roteador R7. Nos LSDB de R8, R9, R10 e R11 constaria apenas
as rotas da prpria rea (Router-LSA e Network-LSA) mais a rota padro 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.
redes se d via o nico ABR da rea. Neste caso, o procedimento recomendado seria confi-
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 redistribuio nos roteadores, seja
redistribuio das rotas estticas, das rotas de outro IGP (RIP, IS-IS, etc.) ou mesmo de interfaces diretamente conectadas no processo OSPF. Ento, pode acontecer de um roteador que
est em uma rea Stub precisar redistribuir informaes de estado de enlace que devem ser
propagadas para todos os roteadores da rede. Conforme explicado anteriormente, os roteadores 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 redistribuio refere-se insero de estado de
enlaces que esto fora do processo OSPF no processo OSPF. Por exemplo: redistribuir um prefixo IP do processo de roteamento do RIP no processo de roteamento do
OSPF. Ou, redistribuir uma rota esttica no processo OSPF. Sempre que h redistribuio 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 redistribuio, 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
22 Criada na RFC 3101

22 Comportamente similar a rea Stub porm permite redistribuio
22 Prefixos externos so redistribudos 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.
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 temporrio.
11 No suportado via reas Stub.
Virtual Link um recurso criado na RFC 2328 para garantir que a mudana de estado de
OSPF Avanado
enlaces no segregue alguma rea, principalmente a rea Backbone, e gere problemas de
38
roteamento, ou seja, o objetivo do Virtual Link conectar dois ABRs via uma rea que no
seja a rea Backbone. Com o Virtual Link, o OSPF trata os dois roteadores como se estivessem conectados a uma rede ponto-a-ponto unnumbered (ou seja, sem endereamento
IP nas pontas).
Como exemplo, observe novamente a figura 2.1. Nela, o roteador R4 faz parte da rea Backbone atravs 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 no pode acontecer.
Mesmo R4 tendo conexo via Rede 3 com R3, os LSAs com os prefixos da rea 3 no seriam
encaminhados para a rea Backbone ou para a rea 2 por R3, pois no foram recebidos pela
l
NVirtual Links no
podem ser criados via
rea Stub.
interface que faz parte da rea Backbone.

Ou seja, a rea 3 ficaria desconectada da rede mesmo que R4 tivesse um enlace de backup via
Rede 3. Nesse caso, a soluo criar um Virtual Link entre R3 e R4 via rea 2. Esse Virtual Link
seria tratado como uma extenso da rea Backbone, desfazendo o particionamento criado
pela mudana de estado do enlace entre R4 e R5. A nova topologia ficaria igual figura 2.2.
R3
Rede 3
rea Bac
VL
R4
rea 2
R8
rea 3
importante ressaltar que o Virtual Link uma funcionalidade que deve ser utilizada para
remediar um problema temporrio, e no ser uma soluo definitiva.
A principal funo das reas no OSPF permitir que a topologia interna das reas seja transparente para as demais reas. Isso resolvido pelo roteador ABR, que filtra os LSAs Router e
Network, gerando LSAs do tipo Summary. Ento, mesmo que o LSA Router no seja recebido
por roteadores OSPF de outras reas, estes ainda recebero o LSA Summary para cada prefixo
existente na rea. Isso garante que a rede seja alcanvel. Porm, se o Administrador da Rede
quiser reduzir a quantidade de prefixos IP na tabela de rotas, recomendvel que os prefixos
IP utilizados em uma rea sejam agregveis, ou seja, parte de um mesmo prefixo maior.
Figura 2.2
Virtual Link entre
R4 e R3.
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 memria e aumenta
a estabilidade da rede, pois caso um enlace oscile, os roteadores externos rea no precisam processar o LSDB novamente.
Entendendo o LSDB
De posse das informaes sobre o tipos de Link State Advertisements vistos na sesso de
aprendizagem 1 com as informaes sobre as reas OSPF da sesso 2, nesta sesso vamos
estudar como funciona o banco de dados do OSPF, o Link State Data Base, quando mltiplas
reas so utilizadas. Conhecer o LSDB extremamente importante para entender se as configuraes esto corretas e para resoluo 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
Backbone
rea 2 Normal
R1
rea 3
NSSA
5.5.5.5/32
R4
10.2.4.0/24
10.1.2.0/24
1.1.1.1/32
10.1.3.0/24
R3
10.3.4.0/24
10.4.5.0/24
10.5.7.0/24
R6
10.4.6.0/24
rea 4
Stub
6.6.6.6/32
A seguir, detalhes da topologia:

11 Existem seis roteadores OSPF (R1 at R6) e um roteador no OSPF (R7);
11 As conexes entre roteadores so feitas por enlaces Ethernet;
11 O prefixo IP entre dois roteadores seguir a lgica 10.X.Y.0/24, onde X representa o
nmero do menor roteador e Y o nmero do maior roteador. Por exemplo, entre R2 e R4,
a rede ser 10.2.4.0/24;
11 O ltimo octeto ser sempre o nmero do roteador. Por exemplo, em R2, no enlace que
conecta com R4, o endereo da interface ser 10.2.4.2/24. Em R4 ser 10.2.4.4/24;
11 Todos os roteadores tero a interface loopback (lo) configurada com o prefixo IP, onde todos
os octetos representam o nmero do roteador. Por exemplo, roteador R6 ser 6.6.6.6/32;
11 Quando a interface Loopack estiver representada em uma nuvem dentro do retngulo
que representa a rea, a interface Loopback far parte do processo OSPF;
OSPF Avanado
11 Quando a interface Loopback estiver representada em uma nuvem fora do retngulo que
40
representa a rea, a interface Loopback ser redistribuda no processo OSPF;

11 As Loopbacks dos roteadores R2, R3, R4 e R7 no esto representadas, mas sero
configuradas seguindo a mesma ideia do item E. R2, R3 e R4 tero suas Loopbacks na
rea Backbone;
11 Em R5 h uma rota esttica apontando para a Loopback de R7;
R7
Figura 2.3
Rede OSPF
Multi-rea.
11 Em R7 h uma rota padro apontando para a interface de R5;

11 As conexes entre R1 e R3 e R3 e R4 tero custo alterado para 64;
11 As interfaces entre R1 e R3, alm de R3 e R4, sero 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 compem a rea Backbone.
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 possvel observar a quantidade de enlaces (links) por roteador, alm de um

LSA Network.
A composio mais simples do LSDB ocorre quando existe apenas uma rea, a rea
Backbone (tambm 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:
Router Link States (Area 0.0.0.0)
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)

10.2.4.4 4.4.4.4 412 0x80000001 0x27f6
possvel observar que o LSDB possui trs LSAs do Tipo 1 (Router LSA) e um LSA do Tipo
2 (Network-LSA). Conforme apresentado na sesso de aprendizagem 1, o Router-LSA
utilizado por todos os roteadores OSPF para informar os estados dos seus enlaces, ou seja,
prefixo IP, mscara, mtrica, 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. possvel ver o tempo de vida (Age), nmero de sequncia (Seq),
checksum e quantidade de enlaces por Router LSA. Como o LSDB o mesmo em todos os
roteadores da rea, essa sada a mesma nos roteadores R2 e R3.
41
Observe agora o Router-LSA gerado pelo roteador R2, primeiro Router-LSA da sada 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
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:

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 Avanado

TOS 0 Metric: 10
TOS 0 Metric: 10
42
Alguns campos foram destacados em negrito e itlico, pois so as informaes mais importantes. Primeiro campo que requer ateno 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, possvel ver que o roteador R2 se apresenta como um roteador ABR, pois este
est conectado rea Backbone e rea 2. As informaes de estado de enlace esto apresentadas logo aps o campo Length, e possvel ver duas entradas:
11 Transit Network: indica que essa enlace de uma rede de trnsito, ou seja, enlace
que possui um Designated Router. Nesse caso, o campo Link ID preenchido com o
endereo IP do DR e o campo Link Data preenchido com o IP do roteador que originou
o LSA. Observe que os endereos IP utilizados so os endereos das interfaces, no o
Router-ID (a tabela 1.1 da sesso de aprendizagem 1 explica como funciona o preenchimento dos campos Link ID e Link Data);
11 Stub Network: uma vez que o endereo IP configurado na interface Loopback utilizado
como destino ou origem do trfego (e no trnsito), o enlace da Loopback anunciado
como uma rede Stub (no confunda com rea Stub).
A ltima informao de cada enlace a mtrica para chegar neste, que no caso est apresentado 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
Continuao:
TOS 0 Metric: 64
(Link ID) Net: 10.3.4.0
TOS 0 Metric: 64
OSPF Avanado
TOS 0 Metric: 10
44
possvel observar que R4, alm de ser um roteador ABR, tambm um roteador ASBR,
devido ao fato de estar conectado rea NSSA (todo roteador de borda de uma rea NSSA
considerado um ASBR). Alm 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
trnsito, um que faz parte de uma rede ponto-a-ponto e dois registros de redes Stub:
11 Transit Network: essa rede de trnsito 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 endereo IP do roteador DR (o prprio R4), e no campo Link Data o endereo
IP do roteador que originou o LSA (nesse caso, prprio R4). Observe pelo endereamento
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 endereamento para confirmar: 10.3.4.4). Como a especificao da topologia dizia
que o tipo de rede OSPF entre R3 e R4 seria Ponto-a-Ponto e redes ponto-a-ponto no
fazem eleio de DR, no 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 endereo IP no enlace
do roteador originador, e o campo Link ID preenchido com o Router ID do roteador
vizinho. Como na especificao tambm dizia que o custo OSPF da interface seria alterado para 64 (especificao K), possvel ver que o LSA possui mtrica 64;
11 Stub Network com Link ID 10.3.4.0: toda vez que uma rede ponto-a-ponto for anunciada pelo processo OSPF, alm da entrada Tipo do Link 1 acima, outra entrada de Tipo do
Link 3 deve ser criada. Nesse caso, a rede ponto-a-ponto tambm 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 mscara de sub-rede. Observe que a
mtrica a mesma: 64, que foi configurada manualmente na interface;
11 Stub Network com Link ID 4.4.4.4: essa entrada apresenta informaes sobre a interface
Loopback do roteador R4. Uma vez que o endereo IP configurado na interface Loopback
utilizado como destino ou origem do trfego (e no trnsito), 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|*
Flags: 0x1 : ABR
LS Type: router-LSA
Checksum: 0xfd3c
Length: 60
Number of Links: 3
LS Flags: 0x6
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 Avanado
46

TOS 0 Metric: 64
possvel verificar que o roteador R3 possui trs registros com informaes 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 consequncia, o prefixo IP
usado nesse enlace ponto-a-ponto anunciado como uma rede Stub (10.3.4.0/255.255.255.0).
Observe as mtricas 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 sada 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 adjacncias com R2 e R3, possvel ver que h apenas um
Network LSA na rea Backbone, que se refere ao enlace entre R2 e R4 (observe o endereamento 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:
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
possvel 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 possvel ver qual a mscara da rede (/24) e quais so os
roteadores que fazem parte dessa rede (R2 e R4).
Neste momento voc pode estar se perguntando: "Se R3 no 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, no h eleio de DR nesse tipo de rede.
11 Observe que o LSDB da rea Backbone no possui nenhum Network-LSA que inclua o
roteador R3, e R3 no est na lista de Attached Router;

11 Isso acontece porque R3 tem seus enlaces configurados como Ponto-a-Ponto, logo
no h DR ou BDR;
11 Lembre-se: apenas o DR gera LSAs do tipo Network.
Nesse ponto, j temos melhor compreenso dos LSAs do Tipo 1 e do Tipo 2. Como ambos os
tipos so restritos por rea, possvel 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 tambm
so criados, porm ambos do tipo LSA Router (Point-to-Point e Stub).
Uma vez que j foram apresentados ambos LSAs na sesso 1 e nas descries anteriores, fica
como atividade para o aluno detalhar os Router-LSAs ou os Network-LSAs das reas 2, 3 e 4.
OSPF Avanado
A.2: Summary-LSA
48
Como cada rea possui um LSDB prprio, fundamental que os ABRs informem os demais
roteadores OSPF sobre os prefixos ali contidos. Nesse caso, os ABRs vo 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 sero gerados para as outras reas OSPF. Observe os LSDBs existentes no roteador R3 (LSAs Tipo 4 e 5 foram removidos):

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
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
4.4.4.4 3.3.3.3 1400 0x80000001 0x210c 4.4.4.4/32
49
Observe que o ABR R3 possui um LSDB por rea e cada rea possui seus LSAs do tipo
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
possvel observar que os prefixos IP que fazem parte do processo OSPF de cada rea so
inseridos como Summary-LSAs no LSDB das outras reas. Por exemplo:
11 Na rea Backbone (Area 0.0.0.0), possvel 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 prefixos foram inseridos na rea Backbone pelos roteadores listados na coluna ADV Router;
11 Na rea 0.0.0.2, possvel 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 endereos
OSPF Avanado
Loopback de R2 e R3 tambm foram inseridos como Summary-LSAs na rea 2, devido ao

fato de que eles esto configurados para operar na rea Backbone (conforme apresentado nas descries sobre Router-LSA).
Os Summary-LSAs criados pelos roteadores R2 e R3 a partir dos Router-LSAs da rea 2 so
enviados para os demais roteadores da rea Backbone. Ao receber esses Summary-LSAs,
o roteador ABR R4 dever executar uma das duas aes:
11 Enviar para os roteadores de outras reas (R5 e R6);
50
11 No enviar para os roteadores de outras reas.

A opo por enviar ou no depende das configuraes de cada rea. Se o administrador da
rede optar por no enviar os Summary-LSAs para os roteadores internos de cada rea (seja
por questo de engenharia de trfego, economia de recursos dos roteadores ou devido ao
fato de que h apenas um roteador ABR na rea), essa configurao dever ser feita no ABR,
e nesse caso, uma rota padro dever ser gerada por esse ABR.
11 Em casos onde uma rea OSPF possui apenas um roteador ABR, por exemplo, as
reas 3 e 6, o Engenheiro de Redes pode optar por enviar ou no 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 no.
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

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
q
Roteador R4 configurado para criar a rea 4 como Stub:
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 parmetro no-summary:
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 parmetro no-summary, o ABR gera uma rota padro para a rea 4;
11 Como h apenas um ABR na rea 4, no haver chance de os roteadores internos
terem roteamento sub-otimizado.
O Quagga 0.99 utilizado durante a escrita deste material mantm os registros do

LSDB por algum tempo aps o fim das adjacncias e trocas de configurao, como
essa informada. necessrio aguardar que os registros do LSBD expirem para serem
removidos. As rotas so removidas normalmente.
Enquanto que no primeiro exemplo R6 possui informaes sobre todos os prefixos da rede,
no segundo havia apenas um Summary-LSA gerado por R4, contendo a rota padro. A seguir
est o Summary-LSA com a rota padro:
LS age: 831
Options: 0x0 : *|-|-|-|-|-|-|*
OSPF Avanado
LS Flags: 0x6
52
LS Type: summary-LSA
Link State ID: 0.0.0.0 (summary Network Number)
Checksum: 0x1934
Length: 28
Network Mask: /0
TOS: 0 Metric: 1
A seguir o LSA Summary com a rota padro:

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
possvel 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 padro a ser utilizada.
Observe que em ambos os casos as redes externas rea sero alcanveis. Porm,
ao usarmos a opo de envio de rota padro, 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 redistribuio de dois prefixos
na rea 3: a sua loopback (5.5.5.5) e a rota esttica que aponta para a loopback do roteador
R7 (7.7.7.7). Essas interfaces esto sendo redistribudas no processo OSPF para demonstrar
uma rota externa ao processo OSPF. Dentro da rea 3, que uma rea NSSA, utilizado o
LSA Tipo 7. Porm, uma vez que esse LSA chega ao ABR da rede, esse convertido para o LSA
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)
do Tipo 5, AS-External-LSA, e enviado para todos os roteadores OSPF da rea Backbone e
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 redistribuio de uma rota esttica (7.7.7.7/32) e da sua interface
Loopack (5.5.5.5/32);
11 Rotas redistribudas so anunciadas com LSAs do tipo AS-External ou NSSA, dependendo da rea;
11 rea 3 uma rea NSSA, logo os prefixos 7.7.7.7/32 e 5.5.5.5/32 so 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 mantm inalterados pela Rede OSPF, R1 os enxerga
da maneira que criado pelo R4/ABR da rea 3.
possvel constatar que ambos os prefixos redistribudos constam no LSDB do roteador
R1, e ambos como LSAs do Tipo 5 (AS-External-LSA). possvel ver que o roteador que
originou o LSA foi o roteador R4 (4.4.4.4) e ambos possuem o endereo IP 10.4.5.5 como
endereo de encaminhamento (Forward Address). Alm disso, observe que ambos os prefixos foram redistribudos como mtrica do tipo E2 (Metric Type: 2) e possuem custo de 20.
OSPF Avanado
importante observar que R4 consta no campo Advertising Router por ter sido o res-
54
ponsvel pela traduo do LSA do Tipo 7 para o LSA do Tipo 5. O verdadeiro originador do
prefixo o roteador R5, porm, esse est em uma rea NSSA.
11 LSA AS-External em R1;
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
Observe que o roteador que criou o LSA foi o R4 (Advertising Router: 4.4.4.4).
Apenas como exemplo, vamos alterar a configurao 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
Metric: 20
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 no NSSA:

LS age: 18
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
Checksum: 0x5f57
Length: 36
Network Mask: /32
TOS: 0
Metric: 20
Observe o comportamento padro 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 possvel verificar, tanto o prefixo (Link State ID) quanto o originador (Advertising
Router) esto preenchidos com o endereo do Router-ID de R1 (1.1.1.1). Como os roteadores
ABR no fazem alterao 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.
OSPF Avanado
Observe que o AS-External-LSA no associado a rea alguma; logo, no tem
56
nenhuma informao de rea, tipo (Area 0.0.0.0). Por isso, no deve ser manipulado
pelos ABRs.
A.4: ASBR Summary LSA

J que os roteadores OSPF devem preservar os AS-External-LSAs intactos e estes so gerados
por roteadores ASBR, necessrio ter um mecanismo que permita que os demais roteadores
OSPF saibam como chegar no ASBR. Com esse propsito, foi criado o ASBR-Summary-LSA,
conforme apresentado na sesso 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 endereo de R4. Observe a sada 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

LS age: 770
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
criado. Observe como R1 aprende o caminho para 4.4.4.4 via R2 (2.2.2.2).
57
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 so gerados pelos roteadores ABR, atravs do campo Advertising
Router, R1 consegue ver quais so 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|*
OSPF Avanado
LS Flags: 0x6
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
so 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 sada 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 redistribuio na rea 3, que uma rea NSSA, os prefixos redistribudos
so 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|*
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 padro 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 idntico 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, aps a traduo de Tipo 7 para LSA do Tipo 5, para que a rota seja instalada, o
OSPF Avanado
roteador remoto precisa fazer uso do ASBR-Summary-LSA, que gerado pelo ABR.
60
Apesar de permitir a redistribuio de prefixos externos ao processo OSPF, as reas NSSA

tm as caractersticas das reas Stub; logo, no h encaminhamento de AS-External-LSAs.
Alm disso, caso o Engenheiro de Rede responsvel deseje, podemos controlar o envio de
Summary LSAs, injetando apenas a rota padro na rea.
A.6: Virtual Links

Como apresentado anteriormente, Virtual Links devem ser utilizados para conectar partes
desconexas da mesma rea. Vamos ilustrar tambm utilizando a figura 2.3. Como estudo de
caso, vamos utilizar o endereo 2.2.2.2/32, que a Loopback do roteador R2. A Loopback
faz parte da rea Backbone, conforme a descrio apresentada anteriormente e as sadas
apresentadas a seguir.
11 Vamos utilizar o endereo 2.2.2.2/32 como estudo de caso para Virtual Link;
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 (sada 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
tambm 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 adjacncia OSPF; logo, utilizando o Router LSA
anterior e a informao de adjacncia. O roteador R4 cria uma rota para 2.2.2.2/32, com
mtrica 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
possvel ver que R4 possui adjacncia com R2:

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 adjacncia 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 partio separada da rea Backbone;
11 Aps a remoo 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 segregao da rea Backbone, onde a Loopback de R2 ficou
isolada. Observe a seguir as sadas para confirmar que no 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 no
OSPF Avanado
remove o registro imediatamente; porm, como no h mais adjacncia, a rota no criada.
62
Vamos agora configurar um Virtual Link entre R2 e R3, via R1. A rea 2 ser utilizada para
criar esse Virtual Link. A configurao de Virtual Link feita nos dois roteadores, cada um
utilizando o Router-ID do roteador remoto.
Criao do Virtual Link entre R2 e R3:
11 Configurao aplicada em R2:

router ospf
area 2 virtual-link 3.3.3.3
11 Configurao aplicada em R3:

router ospf
A seguinte configurao ser aplicada em R2 para criar o Virtual Link:

router ospf
A seguinte configurao ser aplicada em R3 para criar o Virtual Link:

router ospf
Observe a adjacncia criada entre R2 e R3:

3.3.3.3 1 Full/DROther 39.483s 10.1.3.3 VLINK0
A rota ento 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 tambm
que a mtrica no 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 adjacncia 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.

(...)
OSPF Avanado
TOS 0 Metric: 20
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
(...)
TOS 0 Metric: 20
Observe que o Quagga no coloca no campo Link Data o endereo da interface conforme
sugere a RFC2328. Em vez de adicionar o ifIndex da interface do Virtual Link, o endereo IP
do roteador utilizado.
LS Type: router-LSA
65
Concluso
Nesta sesso, foram apresentados os tipos de rea existentes, como cada rea funciona e
quais LSAs so utilizados. Na prxima sesso, sero apresentadas tcnicas que podem ser
utilizadas para melhorar ou ajustar o roteamento dos pacotes em uma rede OSPF e como
otimizar a convergncia.
Comandos OSPF
A seguir, uma lista de comandos de configurao que tm relao com o tema da sesso de
aprendizagem 2, para serem utilizados no Quagga.
Todos os comandos so aplicados na sesso de OSPF do roteador. Em destaque, as
palavras-chave.
11 Adiciona as interfaces que so parte do prefixo informado na rea Backbone:
network prefixo mscara rea 0
11 Adiciona as interfaces que so parte do prefixo informado em uma rea Stub:

network prefixo mscara rea X.X.X.X
area X.X.X.X stub
11 Gera uma rota padro em uma rea Stub (utilizado no ABR):

area X.X.X.X stub no-summary
11 Origina uma rota padro na rede OSPF:

Default-information originate [always] [metric METRICA] [metric-type 1|2]
11 Criar uma rea NSSA em um roteador interno:

network prefixo mscara rea Z.Z.Z.Z
area Z.Z.Z.Z nssa
11 Criar uma rea NSSA e gera uma rota padro na rea (utilizado no ABR):
network prefixo mscara rea Z.Z.Z.Z
area Z.Z.Z.Z nssa no-summary
11 Redistribui rotas estticas no OSPF:

redistribute static
11 Redistribui interfaces conectadas no OSPF:

redistribute connected
11 Redistribui rotas do protocolo RIP no OSPF:

redistribute rip metric 2
OSPF Avanado
66
11 Cria um Virtual Link:

area Area_Transito virtual-link Router_ID_ABR
A seguir, uma lista dos comandos de observao que tm relao com o tema da sesso de
aprendizagem 2.
11 Exibe informaes sobre o processo OSPF:
show ip ospf
11 Exibe informaes resumidas sobre o banco de dados OSPF:

show ip ospf database
11 Exibe informaes detalhadas por LSA:

show ip ospf database <router|network|summary|asbr-summary|external|nssaexternal>
11 Exibe informaes por tipo de LSA originado pelo roteador:

show ip ospf database self-originated
11 Exibe informaes sobre o processo OSPF em uma determinada interface:
show ip ospf interfaces
11 Exibe as adjacncias OSPF estabelecidas:
show ip ospf neighbor
67
68
OSPF Avanado
3
Aprender sobre sumarizao; Conhecer agregao de rotas; Entender como funciona
a manipulao de rotas; Conhecer sobre filtragem de prefixos.
conceitos
Sumarizao de rotas; Agregao de Rotas; Mtricas; Escolha de Caminhos pelo OSPF;

Controlando Atualizaes de Roteamento.
Introduo
As sesses de aprendizagem 1 e 2 apresentaram detalhes avanados sobre o funcionamento do OSPF, permitindo ao aluno entender como o OSPF contri o LSDB e como as
mensagens so negociadas, alm de detalhar o funcionamento das reas OSPF. At esse
momento, as configuraes OSPF utilizadas ficaram muito prximas das configuraes
padro do OSPF.
Mesmo essas configuraes mais simples permitiram que as diversas topologias ilustradas
tivessem um roteamento dinmico eficaz e livre de loops. Porm, o OSPF permite ajustes
mais finos para refletir necessidades de redes mais complexas, o que inclui escolha de caminhos alternativos, economia de recursos dos roteadores e filtros de prefixos. Esta sesso vai
detalhar alguns desses ajustes finos possveis, entre eles sumarizao e agregao de rotas;
manipulao de rotas e filtragem de prefixos.
Sumarizao de rotas
11 Sumarizao de rotas;
11 reas OSPF permitem que a topologia de uma rea seja abstrada 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 informando da remoo;
22 Demais roteadores OSPF precisam recalcular as rotas;
22 Recursos computacionais so consumidos a cada incidente.
11 Existem otimizaes possveis.
Captulo 3 - Engenharia de trfego com OSPF
objetivos
Engenharia de trfego com OSPF
69
Foi mostrado nas sesses anteriores que uma das principais vantagens de usar particionamento da rede criando reas OSPF a conteno de detalhes da topologia inerentes de cada
rea. Como os LSAs Router e Network ficam contidos no LSDB da rea, a topologia abstrada
das demais reas e apenas LSAs do tipo Summary so enviados com os prefixos internos.
Na configurao padro do OSPF, cada LSA Router recebido pelo roteador ABR dispara a criao
de um LSA Summary que, apesar de no 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 situaes, 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
2.1
19
LSA Summary
68
192.168.1.0/24
LSA Summary
2.
LSA Summary
31
192.168.2.0/24
0/
.7.
R6
19
16
8.
7.
2/
31
LSA Summary
ABR
192.168
.7.4/31
R7
(.
19
2.
16
8.
7.
12
/3
192
192.168.3.0/24
31
.6/
.7
168
. .)
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
LSA Summary
R10
R3
192.168.6.0/24
A rede OSPF da figura 3.1 tem as seguintes caractersticas:

11 Duas reas OSPF: rea Backbone e rea 1;
11 Um roteador ABR (Router-ID 10.1.2.1);
OSPF Avanado
11 Sete roteadores OSPF internos na rea 1 (R4 at R10);
70
11 Sete enlaces saindo do ABR para os roteadores OSPF internos (com prefixos
192.168.7.x/31);
11 Sete redes internas com prefixo 192.168.[0-6].0/24;
11 Alm do roteador ABR, a rea Backbone possui outros dois roteadores OSPF (R2 e R3).
Figura 3.1
rea 1 com
configurao
padro OSPF.
ABR vai criar um LSA Summary para cada LSA Router recebido:
11 Quatorze LSAs do tipo Summary vo 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 sero criados pelo ABR.
11 R2 e R3 vo recalcular as rotas;
11 Como no h outro caminho para tais prefixos, R2 e R3 vo remover os prefixos informados pelos LSAs do tipo Summary recebidos do ABR;
11 Quando o enlace for restaurado, R2 e R3 vo 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 roteadores R2 e R3 vo 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 indisponvel, e outro para informar que a rede atrs do roteador OSPF interno est inacessvel.
Cada roteador da rea Backbone vai ento recalcular o LSDB, removendo as rotas para
os destinos recm-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.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.0.0 10.1.2.1 234 0x80000001 0x0cc5 192.168.0.0/24
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 clculo, o ABR vai remover a rede 192.168.0.0/24 que era alcanada via o enlace
192.168.7.0/31. Aps o clculo, 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 no 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 sero 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 oscilao, 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 especfico, como a rede 192.168.0.0/24 s alcanada via ABR, no faz sentido os
roteadores R2 e R3 ficarem recalculando as rotas a cada oscilao, uma vez que ou o prefixo
vai estar fora (j que no h redundncia de acesso) ou vai estar ativo via ABR. Ento, 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 no precisa ficar enviando
LSAs do tipo Summary a cada oscilao. Ou seja, o Engenheiro de Redes pode configurar o
ABR para enviar o LSA Summary apenas para informar que a rede est acessvel (no incio
do funcionamento da rede OSPF e a cada refresh). No Quagga, essa configurao feita pelo
comando a seguir:
router ospf
area NMERO_REA range IP_A_SER_SUMARIZADO [cost mtrica]
Para evitar consumo de recursos de R2 e R3 a cada oscilao na rea 1, o comando range
pode ser utilizado:

area NMERO_REA range IP_A_SER_SUMARIZADO [cost mtrica]
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 agregveis.
Para que esse comando seja aplicado de maneira satisfatria, 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 configurao a seguir. Nela, cada LSA Router
da rea 1 estaria associado a um comando range, porm essa configurao no seria til
para manter as rotas em R2 e R3, ou seja, no evitaria que R2 e R3 recalculassem seus
LSDBs a cada oscilao na rea 1.
OSPF Avanado
! Configurao INCORRETA
72
router ospf
area 0.0.0.1 range 192.168.0.0/24
area 0.0.0.1 range 192.168.1.0/24
area 0.0.0.1 range 192.168.2.0/24
area 0.0.0.1 range 192.168.3.0/24
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 satisfatria, necessrio mais de um prefixo IP contemplado pelo comando range. Como na topologia da figura 3.1 os prefixos IP fazem parte de
um prefixo IP maior, a seguinte configurao deveria ser inserida no roteador ABR:
! Configurao CORRETA
router ospf
area 0.0.0.1 range 192.168.0.0/20
Uma vez que as rotas so criadas em R2 e R3 a partir do LSA Summary, ambos vo 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.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
192.168.7.6 10.1.2.1 3600 0x80000001 0x18b7 192.168.7.6/31
73
11 Aps a insero do comando range, LSAs do tipo Summary so enviados com campo
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 existente na rea 1; porm, agora com o campo Age configurado como MaxAge. Conforme
apresentado na sesso 1, enviar um LSA com o campo Age configurado com MaxAge fora
os demais roteadores OSPF a removerem tal registro do LSDB. Observe o LSDB do roteador
R2 alguns segundos aps a sada anterior, j sem os registros LSA mais especficos:
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 configurao, 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
OSPF Avanado
de 14. A figura 3.2 ilustra essa modificao.
74
R4
rea 1
rea Backbone
192.168.0.0/24
R2
R5
.7.
68
2.1
19
192.168.1.0/24
192.168.2.0/24
19
2.
31
0/
R6
16
8.
7.
2/
31
ABR
192.168
.7.4/31
R7
LSA Summary 192.168.0.0/20
/31
.7.6
68
2.1
(.
19
2.
16
8.
7.
12
/3
19
192.168.3.0/24
. .)
R10
R3
192.168.6.0/24
importante salientar que a sumarizao s acontece com duas condies:

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 no ser gerado;
11 A sumarizao s acontece para LSA Router, no para LSA AS-External.
Importante salientar:
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 no ser gerado;
11 A sumarizao s acontece para LSA Router, no para LSA AS-External.
q
Figura 3.2
Rede OSPF com
Sumarizao.
75
Normalmente, trs questes so 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 indisponvel, isso
no vai sobrecarregar o ABR desnecessariamente?
Quando R2 e R3 enviarem os pacotes para ABR, os enlaces entre eles vo ser utilizados,
porm essa carga ser mnima, j que no haver comunicao no sentido contrrio.
Mesmo com essa utilizao de recursos da rede, os benefcios tendem a superar esse
custo, uma vez que o consumo de CPU e memria em R2 e R3 ser menor, alm de que
com o LSDB sendo menor, a convergncia da rede mais rpida.
2. Quando os pacotes destinados rede 192.168.0.0/24 chegarem ao ABR e o enlace
com R4 estiver fora, no h risco de criar-se um loop de roteamento, caso o ABR
tenha uma rota padro apontando para R2 ou R3?
Para evitar que haja loops de roteamento nessas situaes, os roteadores OSPF criam
uma rota esttica 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 esttica 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 no enviando via rota padro.
3. Qual a mtrica que ficar associada ao LSA Summary configurado?
O comando range apresentado anteriormente permite que o engenheiro de redes
estabelea a mtrica para aquele LSA Summary configurado. Como aquele parmetro
opcional, caso no estabelecido, a mtrica a ser utilizada ser a menor mtrica dos LSAs
do tipo Router associados ao LSA Summary.
Trs questes podem ser levantadas por quem est vendo essa abordagem pela
primeira vez:
11 Se R2 e R3 enviarem os pacotes para ABR mesmo que a rede esteja indisponvel, isso
no 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, no h risco de criar-se um loop de roteamento, caso o ABR
tenha uma rota padro apontando para R2 ou R3?
11 Qual a mtrica que ficar associada ao LSA Summary configurado?
Agregao de rotas
11 Tambm possvel otimizar e agregar prefixos oriundos de LSAs do Tipo AS-External.
11 O seguinte comando pode ser utilizado:

router ospf
summary-address prefixo mscara [tag TAG]
Conforme apresentado na sesso anterior, o comando range apenas utilizado para criar
OSPF Avanado
LSAs do tipo Summary a partir de LSAs do tipo Router. Quando o objetivo agregar LSAs do
76
tipo AS-External, utiliza-se o comando a seguir.

router ospf
summary-address prefixo mscara [tag TAG]
Diferentemente do comando range, o comando summary-address no associado a

nenhuma rea, uma vez que os LSAs do tipo AS-External tambm no so associados com
rea alguma. Alm disso, o comando summary-address deve ser inserido no roteador ASBR,
e no 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
R6
192.168.2.0/24
19
2.
31
0/
.7.
68
2.1
19
192.168.1.0/24
16
8.
7.
2/
31
ASBR
192.168
.7.4/31
R7
/31
7.6
8.
.16
(.
19
2.
16
8.
7.
12
/3
192
192.168.3.0/24
. .)
R10
R3
192.168.6.0/24
Apesar de ser semelhante topologia da figura 3.1, o roteador ABR foi substitudo pelo
roteador ASBR, e no h adjacncias OSPF entre ASBR e os roteadores R4 at R10. ASBR tem
uma rota esttica para cada rede interna e redistribui essas rotas mais as interfaces
conectadas no processo OSPF. Observe a configurao 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
Figura 3.3
Redistribuio e
Agregao.
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 no possui adjacncias OSPF com os roteadores R4 a R10;
11 Uma rota esttica criada para cada rede interna;

11 Rotas Estticas so redistribudas no processo OSPF;
11 Roteadores R2 e R3 recebem quatorze LSAs do tipo AS-External:
22 Todos apontam para o ASBR;
22 No existe alternativa de caminho.
As configuraes dessa topologia podem ser vistas no arquivo adr9-cap3-agregacao.imn.
Como o ASBR est redistribuindo as rotas estticas no processo OSPF, LSAs do tipo
AS-External esto 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]
OSPF Avanado
192.168.7.6 10.1.2.1 92 0x80000003 0xef49 E2 192.168.7.6/31 [0x0]
78
192.168.7.8 10.1.2.1 92 0x80000003 0xdb5b E2 192.168.7.8/31 [0x0]

192.168.7.10 10.1.2.1 92 0x80000003 0xc76d E2 192.168.7.10/31 [0x0]
192.168.7.12 10.1.2.1 92 0x80000003 0xb37f E2 192.168.7.12/31 [0x0]
Essa sada mostra a configurao padro do OSPF sem agregao ou sumarizao. 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 sero 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 Aps receber os 14 LSAs do tipo AS-External, 14 rotas so criadas por R2 e R3;

11 Com o comando summary-address 192.168.0.0/20, novos LSAs do tipo AS-External
so gerados com o campo Age com valor MaxAge, forando sua remoo;
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, no foi

implementado no Quagga, apesar de ser bastante comum em outras plataformas. Porm,
existe outra abordagem que permite o mesmo resultado, e ser explicado na sesso de
route-maps (ou mapas de rotas). Essa outra abordagem foi utilizada para gerar a sada acima.
Mtricas
11 Clculo das Rotas utiliza as mtricas ou custos das interfaces.
11 Rotas com menores custos so escolhidas.

11 Custo padro de cada interface no Quagga definida a partir da equao:
22 Custo padro = 100Mbps/(Largura de Banda da Interface).
11 Como interfaces com mais capacidade que 100Mbps esto disponveis, 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 configuraes customizadas ou enlaces
virtuais com capacidade menor que a capacidade da interface fsica.
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 clculos 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 informao do campo
Mtrica do LSA. Para evitar que o Engenheiro de Rede tenha de definir manualmente o
custo de cada interface, as implementaes de OSPF utilizam a largura de banda disponvel
de cada interface para definir a mtrica a ser utilizada. O Quagga e alguns outros fabricantes
definem essa mtrica por interface dividindo o custo de referncia, 100Mbps, pela largura
de banda da interface fsica. Ou seja, o custo padro :
Custo padro = 100Mbps/(Largura de Banda da Interface)
Como no OSPF, quanto menor for o valor da mtrica, maior a preferncia, 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 disponvel.
Porm, hoje, onde interfaces GigabitEthernet, 10GigabitEthernet e mesmo 100GigabitEthernet
esto disponveis, utilizar esse custo padro sugerido pelas implementaes OSPF se mostra
sub-otimizado, uma vez que apenas valores inteiros so possveis, ou seja: interfaces
FastEthernet, GigabitEthernet e 10GigabitEthernet todas possuiriam custo de 1.
Foram apresentados exemplos nas sesses anteriores, mostrando que possvel manipular
o custo de cada interface com o comando:
interface ethX
OSPF Avanado
ip ospf cost VALOR
80
Para evitar que o Engenheiro de Rede tenha de mudar interface por interface para ajustar a
mtrica com suporte a interfaces com maior capacidade, o Quagga prov o comando a seguir:
router ospf
auto-cost reference-bandwidth <1-4294967>
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 tero mtrica de 1, as interfaces

2,5GigabitEthernet tero mtrica 4, e as interfaces 1GigabitEthernet tero mtrica 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 configuraes 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 diferente, 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 fsica.
Equal Cost Multi-Path

A especificao do OSPF permite que, caso existam mltiplos caminhos do mesmo tipo
(tipos de rota OSPF sero explicadas na prxima sesso) e com o mesmo custo, o roteador
OSPF deve instalar todas as rotas de custo igual. A limitao da quantidade definida pelo
fabricante ou pela implementao, e depende de recursos do Sistema Operacional.
No final do tpico a seguir, Escolha de Caminhos pelo OSPF, um exemplo prtico ser
apresentado sobre ECMP.
Escolha de caminhos pelo OSPF

11 Com o particionamento, vrias reas OSPF so possveis.
11 Protocolo OSPF faz diferenciao de rotas a partir das origens:

22 Rotas Intra-rea: geradas na prpria rea.
22 Rotas Inter-rea: gerada em outra rea OSPF.
22 Rotas Externas: rotas redistribudas pelo ASBR. Podem ser Externas ou NSSA,
Tipo 1 ou 2.
diversas redes menores, chamadas de reas, e que diversos tipos de rea so possveis:
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: so 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: so redistribudas 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 mtrica da rota externa mais a
mtrica interna do OSPF. Rotas Externas do Tipo 2 s possuem a mtrica da rota
externa, e essa preservada ao longo da rede.
Foi apresentado at agora que o OSPF permite fazer o particionamento da rede em
81
Os tipos de rota so levados em considerao pelo processo OSPF para decidir por qual
instalar. Observe a figura 3.4 (arquivo adr9-cap3-escolha_de_caminhos.imn).
R1
rea Backbone
R2
1
rea 1
100
2
R3
3.3.3.3/24
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 configurao e as rotas OSPF instaladas no roteador R1. O endereamento segue
o mesmo padro 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 sada que, para alcanar o endereo da loopback de R3 (cujo endereo IP

3.3.3.3/24), o custo 110. Ao observar mais uma vez a figura 3.4, possvel encontrar um
caminho com custo menor, via R2, ou seja, R1-R2 e R2-R3, que seria 13. Ento, por que R1
OSPF Avanado
escolheu ir via R1-R3?
82
Mesmo interfaces virtuais, como as Loopbacks, possuem um custo associado.

Observe na sada de R1, por exemplo, que a loopback de R1 (1.1.1.0/24) tem custo 10.
Por padro, o Quagga coloca custo 10 em interfaces virtuais.
Figura 3.4
Escolha de
Caminhos.
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
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 tambm enviado para
a rea Backbone. Mas, para gerar um LSA Summary, conforme apresentado anteriormente,
necessrio que um LSA Router tenha sido recebido pelo roteador ABR com o mesmo
prefixo. Observe a seguir a confirmao:
Observe que realados em vermelho existem dois LSAs do Tipo Summary com a rota para
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, alm de custo 10.
Apesar de o Quagga no deixar explcito o motivo de ter escolhido a rota com custo maior
(110 contra 13), a razo est na RFC 2328 do OSPF: no processo de escolha de qual rota deve
ser instalada, rotas Intra-rea sempre tero preferncia 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 capacidade, 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.
OSPF Avanado
2. Inter-rea.
84
3. Externa do Tipo 1: AS-External-NSSA.

4. Externa do Tipo 1: AS-External.
5. Externa do Tipo 2: AS-External-NSSA.
6. Externa do Tipo 2: AS-External.
11 Prioridades para o processo de escolha de rota

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
fcil entender que quanto mais informaes 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, disponvel no arquivo adr9-cap-escolha-de-caminhos2.imn.
R1
R2
rea Backbone
2
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 opes com a mesma mtrica. A sada a seguir do roteador R1 confirma o
ECMP instalado, onde possvel ver a mesma rota com dois roteadores como prximo 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 otimizao do roteamento. Observe que o protocolo OSPF s suporta mltiplas rotas para o mesmo destino
caso as mtricas sejam idnticas.
85
Controlando atualizaes de roteamento

11 Sistemas Autnomos tendem a possuir diversas configuraes e complexidades,
envolvendo diversos tipos de enlaces e protocolos, mltiplos IGPs que requerem

configuraes extras para garantir a otimizao.
11 Funcionalidades extras, como Interfaces Passivas, Rotas Padro e Filtragem tendem
a ser fundamentais em grandes Sistemas Autnomos, especialmente em caso de
mltiplos IGP.
Conforme a configurao da rede fica mais complexa, com mais roteadores, outros IGPs,
diferentes tipos de enlaces e protocolos, mais ajustes finos so necessrios para garantir
que os protocolos de roteamento funcionem da maneira mais otimizada possvel. Esses
ajustes tambm se aplicam ao protocolo OSPF, e nesta sesso alguns ajustes sero apresentados em detalhes. No incio desta sesso, tcnicas de sumarizao e agregao foram
apresentas. Nesta sesso, as seguintes tcnicas sero apresentadas:
11 Passive Interfaces (Interfaces Passivas);
11 Rotas Padro;
11 Filtrando Prefixos.
22 Distributed Lists (Listas de Distribuio);
22 Route-Maps (Mapas de Rotas).
Essas tcnicas tambm sero utilizadas na prxima sesso, quando a interao com outros
protocolos de roteamento ser detalhada.
Interfaces Passivas (Passive Interfaces)

11 Interfaces Passivas ou Passive Interfaces podem ser utilizadas para dar mais flexibili-
dade nas configuraes OSPF.

11 Com Interfaces Passivas, as rotas geradas so tratadas como Intra-rea.
11 Com o comando redistribute, as rotas geradas so tratadas como rotas Externas.
11 Interfaces configuradas como passivas no enviam mensagens Hello nem formam
adjacncias 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 endereo IP das
interfaces conectadas.
Ao ativarmos OSPF no enlace, via comando network do processo OSPF, o prefixo IP da interface inserido no OSPF como Intra-rea e pode ser sumarizado para outras reas, sendo
tratado como Inter-rea. Se for utilizada redistribuio 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
OSPF Avanado
pode faz-lo, mas essa abordagem pode trazer desvantagens. Observe a figura 3.6
86
(arquivo adr9-cap3-interfaces_passivas.imn).
rea 2
R2
R4
R1
rea Backbone
eth1
10.0.0.0/24
Internet
eth0
R3
rea 1
Na topologia da figura 3.6, o roteador OSPF R1 est conectado rea Backbone, e uma das
suas interfaces conecta usurios da empresa. Essa interface com usurios no possui
roteadores, somente dispositivos dos usurios, 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 contrrio, eles no sero alcanados. At
ento, a opo mais comum era redistribuir o endereo daquele segmento no processo
OSPF. Ao ser redistribudo, o prefixo seria tratado como um prefixo externo.
Caso o Engenheiro de Redes decida no 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. Alm disso, caso algum dos usurios deseje agir maliciosamente, ele
pode instalar um roteador OSPF no segmento, que poderia estabelecer adjacncia com R1
e maliciosamente controlar e injetar prefixos que podem comprometer a instabilidade da
rede. Mesmo que o Engenheiro de redes habilite MD5, o usurio malicioso pode ficar tentando quebrar a senha por tentativa e erro.
para essas situaes 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
no tenta criar adjacncias. Dessa maneira, o Engenheiro de Rede passa a ter mais controle
e flexibilidade na administrao da rede. Para fazer uso de Interfaces Passivas, os passos a
seguir so utilizados:
router ospf
! Habilite a interface da maneira tradicional com comando network
network IP area rea
! Transforme em interface passiva
passive-interface Nome_Interface
Figura 3.6
Interfaces Passivas.
87
Para transformar uma interface em passiva, basta utilizar o comando a seguir:
router ospf
! Habilite a interface da maneira tradicional com comando network
network IP area rea
! Transforme em interface passiva
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. Porm, pacotes Hello
no sero enviados. Observe na sada a seguir do roteador R1, em vermelho, a informao
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 esto inclu OSPF Avanado
das pelo comando network passam a fazer parte do processo OSPF; porm, apenas eth0
88
poder formar adjacncias com outros roteadores.
possvel transformar todas as interfaces do roteador em passivas com um nico comando.
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 padro
11 Rota padro ou default route um recurso til para economia de recursos
dos roteadores.
11 Gerado pelos ABRs em reas Stub quando o comando no-summary inserido.
11 til quando existe apenas um roteador de sada do Sistema Autnomo.
11 Pode ser gerada pelo processo OSPF.
22 LSA AS-External.
A rota padro, ou default route, um recurso extremamente tl nas redes de computadores.
Atravs dessa rota, todos os destinos podem ser alcanados, economizando recursos dos
roteadores, mesmo que no seja a soluo mais otimizada. Foram apresentadas situaes
na sesso 2, onde roteadores ABR geravam rotas padro 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 forar o roteador ABR a filtrar mais LSAs do
tipo Summary, alm dos LSAs externos j bloqueados por padro na rea Stub. Como os
roteadores internos no tm informao dos prefixos externos, o roteador ABR ento gera
uma rota padro e envia via LSA Summary para os roteadores internos. Alguns fabricantes
chamam esse tipo de rea de Totally Stub ou Totally NSSA.
Porm, h casos onde a rota padro deve ser gerada para as outras reas, informando alter-
nativas de sada. Observe a figura 3.7 (arquivo adr9-cap3-rota_padrao.imn).
89
R2
R4
R1
rea Backbone
10.0.0.0/24
Internet
R3
R6
R5
rea 1 Stub
Figura 3.7
Rota Padro.
No Sistema Autnomo 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 configurao do roteador R4:
! Processo BGP. Anuncia prefixo 10.0.0.0/8 para o Sistema Autnomo 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
!
OSPF Avanado
router ospf
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 padro
default-information originate
!
90
11 Na topologia da figura 3.7, h apenas um roteador BGP e uma sada;
11 Roteadores OSPF precisam de informaes para enviar pacotes para fora do Sistema
Autnomo;
11 O roteador R4 pode redistribuir prefixos BGP ou originar uma rota padro para os
demais roteadores OSPF.
Atravs da figura 3.7 e das configuraes do roteador R4, possvel confirmar que h apenas
um roteador BGP. Para que os usurios 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 padro para os demais roteadores OSPF.
No 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 no interessante que
estes sejam redistribudos no processo OSPF. Ento, a soluo com rota padro se mostra
mais interessante. O roteador pode originar uma rota padro 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 padro:
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 padro,
desde que esteja na sua tabela de rotas. No caso da topologia da figura 3.7, a rota padro
em R4 foi recebida via BGP do Sistema Autnomo remoto. Observe a sada a seguir:
R4# show ip route bgp
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
B>* 0.0.0.0/0 [20/0] via 11.0.0.1, eth0, 00:11:20
91
Parmetros opcionais:
11 always: origina a rota padro, mesmo que no exista uma no roteador;

11 metric-type: define o tipo de mtrica para o LSA AS-External: tipo 1 ou 2. O tipo padro
2;
11 metrica: define o custo da rota. O custo padro 10.
De posse da rota padro 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
Aps receber esse LSA, o roteador R1 instala uma rota padro e, partir desse momento,
todos os usurios conectados ao roteador R1 passam a ter acesso ao Sistema Autnomo
remoto, e mesmo internet.
O comando default-information originate possui alguns parmetros opcionais:
11 always: origina a rota padro, mesmo que no exista uma no roteador;
11 metric-type: define o tipo de mtrica para o LSA AS-External: tipo 1 ou 2. O tipo padro 2;
11 metrica: define o custo da rota. O custo padro 10.
Filtrando prefixos
11 Filtragem de prefixos so necessrias para customizar a manipulao de prefixos na
rede OSPF;
11 Engenheiro de redes pode decidir por no enviar prefixos entre reas ou mesmo
no instalar rotas de acordo com as necessidades locais;
OSPF Avanado
11 Diversas ferramentas esto disposio no Quagga:
92
22 Lista de Controle de Acesso ou ACL;

22 Lista de Prefixos;
22 Lista de Distribuio;
22 Mapas de Rotas.
Filtragem de prefixos faz parte de qualquer protocolo de roteamento. Seja por questes de
segurana, isolamento ou escalabilidade, todos os protocolos de roteamento implementam
opes 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 sesso, diversas abordagens de filtros, intra e inter-domnio sero apresentadas,
inclusive mapas de rotas. Porm, antes, uma introduo ser feita sobre as ferramentas
disponveis no Quagga.
Lista de Controle de Acesso (Access Control List: ACL)

11 Listas de Controle de Acesso (ou ACL) so utilizadas normalmente para filtragem de
pacotes de usurios;
11 Tambm servem para marcar prefixos antes da tomada de ao pelo roteador;
11 No permite remoo de apenas uma entrada ou reordenamento;
11 Podem ser configuradas de trs maneiras diferentes:
22 ACL Padro: numeradas com valores 1-99 e 1300-1999: access-list NMERO
(deny|permit) (A.B.C.D|Any) [Wildcard]
22 ACL Extendida: nmeros possveis: 100-199 e 2000-2699: access-list NMERO
(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, so utilizadas com grande frequncia para filtragem
de pacotes de usurios nas interfaces. No mbito do OSPF, ACL so utilizadas para especificar prefixos a serem selecionados. Possibilidades de configurao no Quagga:
! ACL Padro: Nmeros 1-99 e 1300-1999
access-list NMERO (deny|permit) (A.B.C.D|Any) [Wildcard]
! ACL Extendida: Nmeros possveis 100-199 e 2000-2699
access-list NMERO (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 combinaes possveis; porm, para o OSPF, essas so as mais utilizadas.
ACLs no possuem a possibilidade de remover apenas uma entrada; logo, se uma entrada for
removida, toda a ACL ser removida. A mesma limitao se aplica a ordenamento ou sequen-
Lista de Prefixos (Prefix-List)

11 Lista de Prefixos uma evoluo das ACL, possuindo nmero de sequncia e opes
de range, como le (menor-igual) e ge (maior-igual).
11 Permite que apenas uma entrada seja removida.
11 Permite reorganizao ou resequenciamento.
11 Pode ser configurada da seguinte maneira:
22 ip prefix-list NOME seq <NMERO> (deny|permit) A.B.C.D/M [ge <0-32>] [le <0-32>]
ciamento: uma vez criada, a nica possibilidade para mudar a sequncia recriando a ACL.
93
Lista de prefixos foi criada para facilitar a seleo de prefixos, uma vez que cada entrada
possui um nmero de sequncia, alm das extenses le (menor-igual) e ge (maior-igual),
muito teis para selees mais especficas.
ip prefix-list NOME seq <NMERO> (deny|permit) A.B.C.D/M [ge <0-32>] [le <0-32>]
Existem outras combinaes possveis; porm, no mbito desse material, esses parmetros
so suficientes.
Listas de Distribuio (Distributed Lists)

11 Listas de Distribuio permitem que filtragens de entrada e sada sejam aplicadas por
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 (Nmero ACL | Nome ACL) (in|out)
Listas de Distribuio outra possibilidade para implementar controles de prefixos, e foi
criada para superar algumas limitaes existentes nas ACLs. ACLs no filtram pacotes originados pelo prprio roteador, alm de ser aplicadas por interface. Listas de Distribuio no
possuem essas limitaes, sendo utilizados para fazer selees e restries nas distribuies de prefixos por interface e por processo de roteamento.
Listas de Distribuio usam ACLs para filtrar os prefixos desejados. Os usos mais comuns so:
distribute-list (Nmero ACL | Nome ACL) (in|out)
Mapas de Rotas (Route-Maps)

11 Mapa de Rotas um ferramenta extremamente poderosa para no s selecionar
prefixos, mas tambm executar edies ou aes.
11 Possui diversos tipos de filtragem, atravs do comando match.
11 Possui diversos tipos de edies, atravs do comando set.
11 Possui nmero de sequncia para fcil ordenamento e remoo.
11 Pode ser configurado da seguinte maneira:
22 Para criar um mapa de rotas com nome NOME e nmero de sequncia:
33 route-map NOME (deny|permit) <nmero sequncia 1-65535>
22 Para buscar por prefixos especificados pela ACL (nome ou nmero):
33 match ip address
22 Para buscar pelo tag do LSA AS-External ou NSSA:
33 match tag
OSPF Avanado
22 Para configurar o custo com VALOR especfico:
94
33 set metric
22 Para configurar o LSA AS-External ou NSSA com tipo especfico:
33 set metric-type <tipo 1 | tipo 2| internal | external>
22 Para colocar uma tag no LSA AS-External ou NSSA:
33 set tag
Mapa de Rota foi criado para utilizar ACL e Listas de Prefixos para no apenas filtrar prefixos,
mas tambm executar mudanas nos prefixos selecionados. A utilizao foi apresentada
no curso Protocolos de Roteamento IP, porm os comandos mais comuns para se usar com
OSPF esto relacionados a seguir:
! Cria um mapa de rotas com nome NOME e nmero de sequncia
route-map NOME (deny|permit) <nmero sequncia 1-65535>
! Procura por prefixos especficados pela ACL (nome ou nmero)
match ip address
! Procura pelo tag do LSA AS-External ou NSSA
match tag <VALOR TAG>
! Configura mtrica com VALOR especfico
set metric <VALOR>
! Configura LSA AS-External ou NSSA com tipo especfico
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 aplicaes sero apresentadas para

facilitar o entendimento de possveis aplicaes. 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
R2
R5
R4
R9
Internet
10.0.0.0/24
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 roteador OSPF por rack. Os roteadores OSPF internos da rea 1 possuem vrias conexes para
aumentar a performance. Dentro da rea 1 existem dois prefixos:
11 11.0.0.0/16: IPs dos servidores que so 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) so responsveis pelo roteamento
de ambos os prefixos, por padro, todos os prefixos esto 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.1.8.0/24 [110/10] is directly connected, eth0, 00:08:56
O>* 10.2.4.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06

*
via 10.8.9.9, eth1, 00:08:06
O>* 10.2.9.0/24 [110/20] via 10.8.9.9, eth1, 00:08:12

O>* 10.3.4.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.3.5.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.3.6.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.3.7.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 10.4.5.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
*
via 10.8.9.9, eth1, 00:08:06
O>* 10.4.6.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06

*
via 10.8.9.9, eth1, 00:08:06
O>* 10.4.7.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06

*
O
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
OSPF Avanado
O>* 11.1.28.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
96
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
Mesmo com a instruo de que os prefixos da rede 11.1.0.0/16 no deveriam ser
acessados fora da rea 1, roteador R8 possui rotas para tais prefixos.

O>* 11.0.21.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.23.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.25.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.27.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.0.29.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
*
via 10.8.9.9, eth1, 00:08:06
O>* 11.1.22.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06

O>* 11.1.24.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.26.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.28.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
O>* 11.1.30.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06
*
via 10.8.9.9, eth1, 00:08:06
Isso acontece porque a configurao padro do OSPF distribuir os prefixos entre

reas OSPF.
Observe que, pela multiplicidade de conexes, vrios prefixos podem ser acessados por
mais de um caminho usando ECMP.
Filtragem de prefixos Inter-reas OSPF

Pela sada da tabela de rotas de R8, possvel ver que os sub-prefixos do prefixo 11.1.0.0/16
esto acessveis, mas, segundo a definio anterior, esses prefixos no deveriam ser vistos
fora da rea 1. Nesse caso, como o padro do OSPF redistribuir os prefixos entre reas, o
engenheiro de redes precisa agir para no permitir essa distribuio, mas ainda assim tendo
esse prefixo sendo roteado na rea 1.
No tpico Sumarizao de Rotas, foi apresentado o comando range, que permite a criao
de agregao entre reas. Alm de agregar e anunciar, o mesmo comando permite que, em
vez de gerar o LSA do tipo Summary para fazer o anncio, permite bloquear todos os prefixos 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 no vo 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
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
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
no h mais rotas para os prefixos 11.1.0.0/16.
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

*
O
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 opo que faz o inverso: em
vez de criar um LSA Summary para o prefixo explicitado, passa a no 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 no tero conhecimento do prefixo 11.1.0.0/16

Outra possibilidade de fazer o mesmo bloqueio possvel 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
possvel fazer o mesmo filtro com Lista de Prefixos.
ip prefix-list Datacenter-11.1 deny 11.1.0.0/16 le 32

ip prefix-list Datacenter-11.1 permit any
router ospf
area 1 filter-list prefix Datacenter-11.1 out
Lista de Prefixos permite que apenas uma lista tenha diversos prefixos IP distintos,
evitando ter de aplicar mltiplos comandos range.
Agora, em ambos R1 e R2 vamos criar uma Lista de Prefixos que inclua todos os prefixos do
OSPF Avanado
range 11.1.0.0/16:
ip prefix-list Datacenter-11.1 deny 11.1.0.0/16 le 32
ip prefix-list Datacenter-11.1 permit any
Essa Lista de Prefixos, chamada Datacenter-11.1, possui duas regras: a primeira rejeita o
prefixo 11.1.0.0/16, incluindo prefixos menores at /32; a segunda 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, possvel observar o mesmo comportamento do comando range:

Link ID
ADV Router
Age
11.1.22.0
10.2.4.2
3600 0x80000001 0x7793 11.1.22.0/24
Seq#
CkSum
Route
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, aps serem aplicados, criam LSAs do Tipo
Summary solicitando a remoo do prefixo. Observe o LSDB de R8:

Link ID
ADV Router
Age
11.1.22.0
10.2.4.2
3600 0x80000001 0x7793 11.1.22.0/24
Seq#
CkSum
Route
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,
forando os demais roteadores OSPF a removerem os prefixos inclusos na Lista de
Prefixos dos seus LSDBs. Com a configurao atual, a rea Backbone no possui mais
rotas para a rede 11.1.0.0/16, conforme especificado no incio do texto.
Filtragem de prefixos Intra-rea OSPF

Aps a aplicao dos comandos range ou/e filter-list em R1 e R2, foi possvel confirmar que
nenhum roteador fora da rea 1 tinha informaes que o prefixo 11.1.0.0/16 estava na
rea 1. Porm, e se forem conectados aos roteadores R1 ou R2 novas redes, com usurios,
por exemplo? Apesar de no anunciar para a rea Backbone, como R1 e R2 ainda fazem
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
parte da rea 1, estes possuem rotas para o prefixo 11.1.0.0/16:
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 no precisam saber desse prefixo, pois em caso de conexo nova
com R1 ou R2, os servidores da rede 11.1.0.0/16 seriam acessveis. Para evitar esse tipo de
situao, 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 restrio 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 adjacncias com outros roteadores OSPF,
no caso, R1 e R2 criaro adjacncias com R3 e R4, respectivamente. Ao receberem os
prefixos, estes sero instalados no LSDB, aps todo o processo de sincronizao apresen-
OSPF Avanado
tado na sesso 1. Aps a sincronizao, o roteador vai verificar quais rotas OSPF devem ser
100
instaladas na tabela de rotas. Como h um Mapa de Rotas configurado, apenas os prefixos

permitidos pela Lista de Prefixos sero aceitos. Observe a tabela de rotas do roteador R2:
R2# sh ip route

O>* 8.8.8.8/32 [110/30] via 10.1.2.1, eth1, 1d00h15m
* via 10.2.9.9, eth2, 1d00h15m
O>* 9.9.9.9/32 [110/20] via 10.2.9.9, eth2, 1d00h15m
O 10.1.2.0/24 [110/10] is directly connected, eth1, 1d00h16m
C>* 10.1.2.0/24 is directly connected, eth1
O>* 10.1.3.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03
O>* 10.1.8.0/24 [110/20] via 10.1.2.1, eth1, 1d00h15m
O 10.2.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 aps o prefixo j estar inserido na tabela de rotas, o

engenheiro de rede necessitar reestabelecer as adjacncias OSPF, reiniciando o
processo OSPF.
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
Observe que os prefixos da rede 11.1.0.0/16 esto inativos; logo, no so alcanveis.
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 instalao da
rota na tabela de rotas, mas no a insero do LSA no LSDB.
OSPF Avanado
Em alguns outros fabricantes, o comando OSPF distributed-list est disponvel:
102
router ospf
distributed-list prefix NOME_LISTA_PREFIXO in
A lgica a mesma: apenas prefixos listados e permitidos na Lista de Prefixo NOME_LISTA_

PREFIXO sero instalados na tabela de roteamento.
Executando Filtragem de Prefixos Intra-rea:

1. Crie a Lista de Prefixo com o prefixo que no 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
Agregao de LSAs AS-External

Na sesso Agregao de Rotas, foi apresentado o comando OSPF summary-address para
fazer agregao de LSAs do tipo AS-External. Porm, conforme apresentado, esse comando
no suportado pelo Quagga; ento, a possibilidade usando Mapas de Rotas vai ser apresentada a seguir.
Observe a figura 3.3, reproduzida novamente a seguir.
R4
External
rea Backbone
192.168.0.0/24
R2
R5
2.1
19
192.168.2.0/24
19
2.
31
R6
0/
.7.
68
192.168.1.0/24
16
8.
7.
2/
.7.4/31
19
2.
16
8.
7.
12
/3
. .)
R10
R3
31
.6/
.7
168
192
192.168.3.0/24
192.168.6.0/24
ASBR
192.168
R7
(.
31
103
Na topologia da figura 3.1, o ASBR possui interfaces conectadas aos roteadores remotos R4
at R10 e uma rota esttica 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 estticas esto sendo redistribudas
no OSPF. Para evitar que R2 e R3 criem 14 rotas apontando para o ASBR, podemos utilizar
Mapas de Rotas para fazer a agregao. 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 esttica para o endereo agregvel:
ip route 192.168.0.0/20 null0
Passo 4: aplicar o Mapa de Rotas no processo OSPF, fazendo a redistribuio de rotas estticas:
router ospf
OSPF Avanado
redistribute static route-map AGREGACAO
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 alcanado com rota esttica, Lista de Prefixo e Mapa de Rotas.
Usando Mapas de Rotas para fazer agregao de LSAs do tipo AS-External:
1. Crie a Lista de Prefixos:

ip prefix-list FILTRA_192.168-20 seq 5 deny 192.168.0.0/16 ge 24
ip prefix-list FILTRA_192.168-20 seq 10 permit any
2. Crie um Mapa de Rotas com a Lista de Prefixos criada:

route-map AGREGACAO permit 5
match ip address prefix-list FILTRA_192.168-20
3. Crie uma rota esttica para o endereo agregvel:

ip route 192.168.0.0/20 null0
4. Aplique o Mapa de Rotas no processo OSPF, fazendo a redistribuio de rotas estticas:
redistribute static route-map AGREGACAO
5. Confirme o resultado nos demais roteadores da rea Backbone:

Nesta sesso, o aluno teve contato com algumas tcnicas de engenharia de trfego que permitem a otimizao do LSDB, aumenta a eficincia do processo de convergncia e tambm
agrega segurana e isolamento nas implementaes OSPF. Na sesso de aprendizagem 4,
o aluno ter a oportunidade de conhecer algumas tcnicas e funcionalidades mais novas
desenvolvidas pelo IETF para o protocolo OSPF, que agregam mais valor e escalabilidade a
esse popular protocolo de roteamento dinmico.
router ospf
105
Comandos OSPF
A seguir, uma lista de comandos de configurao que foram apresentados na sesso de
aprendizagem 3. Em destaque esto as palavras-chave.
Os comandos a seguir so aplicados na sesso de OSPF do roteador.
11 Gera LSAs do tipo Summary na rea Backbone. Not-advertise filtra o LSA do tipo
Summary:
area NMERO_REA range IP_A_SER_SUMARIZADO [cost mtrica] [not-advertise]
11 Gera uma agregao de LSAs do tipo AS-External na rede OSPF:

summary-address PREFIXO MSCARA [tag TAG]
11 Muda o custo de referncia 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 padro em uma rea Stub e filtra todos os LSAs do tipo Summary:
area AREA stub no-summary
11 Origina uma rota padro 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 anncios recebidos:

distribute-list prefix NOME_LISTA_PREFIXO in
Os comandos a seguir so aplicados na configurao das interfaces.

11 Altera o custo da interface no processo OSPF:
ip ospf cost VALOR
Os comandos a seguir so aplicados no modo de configurao global do roteador.

11 Ativa um mapa de rotas no processo OSPF:
ip protocol ospf route-map NOME_DO_MAPA
OSPF Avanado
11 Cria uma ACL padro:
106
access-list NMERO (deny|permit) (A.B.C.D|Any) [Wildcard]
11 Cria uma ACL Extendida:

access-list NMERO (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_SEQUNCIA
11 Cria uma Lista de Prefixos:

Ip prefix-list NOME seq NMERO [permit|deny] A.B.C.D/M [ge <0-32>] [le <0-32>]
11 Procura por prefixos especficados pela ACL (nome ou nmero) 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 mtrica com VALOR especfico no Mapa de Rotas:

set metric <VALOR>
11 Configura LSA AS-External ou NSSA com tipo especfico 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
108
OSPF Avanado
4
Conhecer novas tecnologias relacionadas ao OSPF; Apresentar exemplos prticos para
consolidao dos novos tpicos; Entender a importncia dessas tecnologias novas
para os ambientes que usam OSPF.
Convergncia: Bidirectional Forwarding Detection (BFD); Monitoramento: MIB 4750.
conceitos
Escalabilidade e Estabilidade: Incremental OSPF, Supresso de Prefixos, Graceful Restart;
Introduo
Nas sesses anteriores, as RFCs 2328 e 3101 foram apresentadas e as configuraes mais
comuns disponveis do protocolo OSPF nos roteadores atuais foram detalhadas. Diversos exemplos e topologias foram apresentados, com informao suficiente para o aluno ter a capacidade
de configurar redes complexas e de grande escala. Porm, ao longo dos anos e com o advento
de novos protocolos e tecnologias, novas funcionalidades foram propostas e algumas viraram
padres de fato via RFCs no IETF (Internet Engineering Task Force). Servios como o transporte
de voz e vdeo utilizando redes IP se consolidaram e passaram a exigir tempos de convergncia
menores, o que fora uma deteco mais rpida de possveis problemas de conectividade. Alm
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 convergncia da rede.
Esta sesso apresenta as tecnologias e propostas mais novas relacionadas ao protocolo OSPF
e, sempre que possvel, exemplos prticos sero apresentados para ajudar o aluno a consolidar os novos tpicos. Algumas das funcionalidades a serem apresentadas so to recentes
que muitos dos fornecedores ainda no as suportam, mas importante os alunos saberem
que existem opes para resolver problemas especficos relacionados a grandes ambientes
de roteamento OSPF. Alm disso, algumas tecnologias apresentadas so importantes para
ambientes que usam o OSPF, como por exemplo, redes MPLS e Engenharia de Trfego.
Os principais assuntos a serem abordados nesta sesso esto relacionados s seguintes reas:
11 Escalabilidade e Estabilidade: sero discutidos tpicos como Incremental OSPF,
Supresso de Prefixos e Graceful Restart;
11 Convergncia: ser apresentado o protocolo Bidirectional Forwarding Detection (BFD);
11 Monitoramento: a MIB 4750 ser detalhada.
Captulo 4 - Otimizao e tpicos avanados
objetivos
Otimizao e tpicos avanados
109
Escalabilidade e Estabilidade do OSPF

11 Roteadores modernos possuem mais CPU e memria, porm as redes esto ficando
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 estvel.
11 Novas funcionalidades foram propostas ou melhoradas para extender a RFC 2328.
A capacidade de suportar cada vez mais roteadores e prefixos de maneira estvel determina
a escalabilidade de um protocolo de roteamento. O protocolo OSPF foi planejado para
suportar muitos roteadores e enlaces, porm, com a popularizao das redes de computadores e o crescimento destas, os LSBDs acabaram ficando muito grandes. Mesmo com os
roteadores mais novos possuindo mais capacidade de processamento e memria, algumas
funcionalidades foram propostas para otimizar e acelerar o processo de convergncia, alm
de aumentar a estabilidade da rede. As seguintes funcionalidades foram padronizadas para
extender as capacidades da RFC 2328 (OSPF v2) e sero detalhadas ao longo da sesso de
aprendizagem 4:
11 Incremental OSPF: permite que o OSPF reprocesse apenas parte do LSDB em casos
especficos de alterao na topologia da rea OSPF;

11 Graceful Restart: permite que os pacotes continuem sendo encaminhados ao longo
da reinicializao do processo OSPF;
11 BFD para OSPF: permite que o processo OSPF detecte mais rapidamente a queda dos
roteadores vizinhos;
11 Supresso de Prefixos: permite a remoo dos prefixos das redes de trnsito do
LSDB, diminuindo assim o seu tamanho;
11 MIB para OSPF: permite o monitoramento dos objetos OSPF, facilitando a operao
da rede OSPF.
Incremental OSPF
11 Roteadores OSPF usam o algoritmo SPF para escolher o melhor caminho para cada
destino.
11 Aps a escolha de todos os caminhos, a Shortest Path Tree (SPT) calculada.
11 Uma vez calculada a SPT, s h o reprocessamento quando h alteraes topolgicas.
11 O SPF reprocessa TODO o LSDB em caso de alteraes topolgicas na rea OSPF,
consumindo CPU e memria do roteador.
11 A figura 4.1 ser utilizada para ilustrar a criao da SPT.
No curso "Protocolos de Roteamento IP", o funcionamento do Algoritmo de Djisktra foi
OSPF Avanado
apresentado, mostrando como o protocolo OSPF faz a escolha dos caminhos. Inicialmente,
110
aps a sincronizao do LSDB (apresentada na sesso 1), cada roteador precisa definir sua
Shortest Path Tree (SPT) com todos os destinos, avaliando os custos e caminhos disponibilizados pelos demais roteadores OSPF. Atravs da SPT, o roteador OSPF saber como chegar
em cada uma das redes disponveis. A fim de ilustrar esse procedimento, observe a topologia da figura 4.1.
Rede 3
R1
Rede 1
R6
Rede 6
10
R3
10
Rede 2
10
15
15
R2
10
10
Rede 7
R5
R7
10
R8
10
Rede 8
10
R9
Rede 4
R10
Rede 10
R11
Rede 11
possvel observar que essa rede possui diversos enlaces e roteadores. Assumindo os
custos informados nos enlaces, o roteador R6 iria executar o processo SPF (Shortest Path
First) no seu LSDB para criar sua SPT (Shortest Path Tree) para alcanar 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;
11 Cada roteador cria sua prpria SPT para chegar a todos os destinos;
11 A figura 4.2 mostra a SPT do ponto de vista de R6, utilizando as mtricas (ou custos)
informadas;Observe que no h loops na SPT.
Figura 4.1
Incremental OSPF.
R4
10
111
R6
R3
R1
Rede 1
R5
R7
R2
R11
R10
R4
Rede 2
R8
Rede 8
Rede 11
Rede 10
R9
Rede 9
Como era de se esperar, o roteador R6 calculou sua SPT sem loops, utilizando as mtricas dos
enlaces anunciados pelos demais roteadores. Suponha que as rotas sejam instaladas no roteador R6, e o enlace que liga o roteador R8 Rede 8 mude de estado, de UP para DOWN. O roteador R8 vai ento gerar um LSA Network para informar que a Rede 8 est indisponvel (com LSA
Age 3600 ou Mtrica Infinita). Os demais roteadores OSPF vo repassar o LSA (via flooding) at
que todos os roteadores OSPF estejam com o mesmo LSDB. Aps terem o LSDB sincronizado,
todos os roteadores vo 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 clculo consome
recursos de processamento e memria do roteador, e se depender da quantidade de prefixos
e frequncia com que esses prefixos oscilam, a CPU do roteador pode ficar bastante ocupada.
Vimos na sesso 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
mudana de estado;
OSPF Avanado
11 Todos os roteadores OSPF reprocessam o LSDB para criar novas SPTs;
112
11 Ao longo da recriao da SPT, recursos de CPU e memria sero utilizados;

11 Como a Rede 8 s tem ligao com R8, as SPTs vo permanecer as mesmas.
Figura 4.2
Roteader R6 e
sua SPT.
Diante desse cenrio, alguns fabricantes implementaram uma verso otimizada do algoritmo
SPF sugerida na poca da ARPANET. poca, foi sugerida uma modificao no algoritmo do
SFP, chamado Incremental SFP (ISPF), propondo mudanas que afetem apenas as folhas ou
pequenas sub-rvores da SPT, e no foram o clculo completo da SPT. Assim, economizam
recursos computacionais dos roteadores.
11 Para evitar esse tipo de situao, uma mudana foi implementada no SPF:
o Incremental SPF (ISPF);

11 O ISPF prope que mudanas que afetem apenas as folhas ou pequenas sub-rvores
da SPT e no forcem o clculo completo da SPT;
11 Recursos computacionais seriam economizados e o tempo de convergncia pode
ser otimizado;
11 Trs propriedades se aplicam ao funcionamento do ISPF.
O Incremental SFP consiste em trs 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 No Trnsito, redes "terminais", ou Stub (como
apresentado na sesso 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:
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 no-trnsito, 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
Leia o artigo ARPANET

Routing Algorithm
Improvements, em
http://www.dtic.mil/
dtic/tr/fulltext/u2/
a086340.pdf
113
R6
R3
R5
R7
R2
R1
R11
R10
Rede 11B
Rede 1
R4
Rede 2
R9
R8
Rede 8
Rede 11
Rede 10
Rede 9
R12
Rede 12
Nesses casos, com o ISPF, o clculo SPF seria feito apenas para adicionar o novo roteador
e as novas redes adicionadas, no recalculando toda a SPT. Como no h necessidade de
recalcular toda a SPT, o tempo de clculo tende a ser menor. Para demonstrar os resultados,
o cenrio 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 execuo do reclculo 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
OSPF Avanado
Como a Interface Loopback0 foi desativada, o roteador R12 gerou um LSA Network que foi
114
propagado pela rede OSPF. Observe a sada a seguir. Nessa sada, o comando show ip ospf
statistics detail foi utilizado. A linha em negrito e em vermelho mostra o tempo total, em milisegundos, necessrio para computar a mudana recebida do roteador R12 (em negrito e azul).
Figura 4.3
ISPF e a
Propriedade 1.
11 A sada a seguir mostra o tempo de execuo do SPF caso a interface Loopback de
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)
possvel observar que o roteador R6 levou 12 milisegundos para recriar a rvore SPT.
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)
Vamos agora habilitar o ISPF em R6:
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 necessrio 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 alterao do estado da

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 Avanado

0 0
Change record
LSIDs changed 1
12.12.12.12(R)
116
Apenas a ltima execuo do SPF executado foi mostrado (SPF 21). Nessa sada, possvel
ver algumas informaes interessantes:
11 SPF type Incremental: o tipo de clculo SPF foi o incremental, e no o completo (Full);
11 Total 4: o tempo total utilizado pelo SPF foi de 4 milisegundos, trs vezes mais rpido que
o modo Full;
11 12.12.12.12(R): a mudana que forou o SPF foi gerada pelo roteador R12 (Lo0: 12.12.12.12)
e foi um LSA do tipo Router (R).
Alm disso, a sada mostra (Stub: 1). Como vimos na sesso 1, interfaces Loopback so
chamadas de redes Stub (no confunda com rea Stub!). possvel ver que o ISPF diminuiu
consideravelmente o tempo de processamento do SPF, de 12 para 4 milisegundos. Como
uma funcionalidade local, o ISPF no precisa ser habilitado em todos os roteadores OSPF,
ou seja, possvel ter na mesma rede OSPF roteadores que suportam ISPF e roteadores que
no suportam ISPF.
Propriedade 2
A propriedade 2 relacionada com a alterao do estado do enlace que no parte da SPT.
Observe na figura 4.1 que h um enlace entre R2 e R4. Esse enlace no faz parte da SPT de
R6, logo, se esse enlace tiver seu estado alterado, com ISPF habilitado o roteador R6 no vai
precisar recalcular a SPT.
11 Propriedade 2
11 Relacionada com a alterao do estado do enlace que no parte da SPT: se o enlace

que tem o estado alterado para DOWN no faz parte da SPT, no h necessidade de
recalcul-la
11 Observe o enlace entre R2 e R4 na figura 4.2. Como no faz parte da SPT de R6, R6
no precisa recalcular sua SPT
Desativao 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
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
R2-R4 alterado para DOWN. Tempo total do SPF com ISPF habilitado:
from FULL to DOWN, Neighbor Down: Interface down or detached
0 0 0 0 0 0 0 0
117
Tempo total com ISPF desabilitado:

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 no faz parte da SPT, nem foi processado (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, no 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)
OSPF Avanado
Fica evidente o benefcio de usar ISPF nesse caso tambm, pois no h a necessidade de
recalcular a SPT de R6.
Lembre-se de que a SPT por roteador, ou seja, cada roteador tem sua prpria SPT para
chegar aos demais destinos da rede. Logo, outros roteadores podem ter suas SPTs afetadas por causa da alterao do estado do enlace entre R2 e R4. Nesses casos, a SPT teria
de ser recalculada.
118
Propriedade 3
Caso haja uma alterao em um enlace de trnsito que afete parte da SPT, apenas os
caminhos para chegar aos roteadores ps-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:
11 Caso haja uma alterao em um enlace de trnsito que afete parte da SPT, apenas os
caminhos para chegar nos roteadores ps-enlace afetado precisam ser recalculados
11 Observe figura 4.4, onde o enlace R4-R5 ficou indisponvel, afetando uma sub-rvore
da SPT
R6
R3
R1
R5
R7
R2
R11
R10
Rede 11B
Rede 2
R8
Figura 4.4
ISPF Propriedade 3.
Rede 8
Rede 11
Rede 10
R4
R9
Rede 9
R12
Rede 12
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 alterao do estado do enlace R4-R5.
Nesse caso, com ISPF, apenas esta sub-rvore precisaria ser reconstruda, e no toda a SPT.
Observe o clculo do SPF sem ISPF habilitado em R6:
Rede 1
119

12 16 0 0 0 0 0 16
4 0
Change record
LSIDs changed 1
4.4.4.4(R)
Observe o clculo 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 situao, 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 alterao do estado do enlace R4-R5
11 Apenas esta sub-rvore precisaria ser reconstruda, e no toda a SPT
11 Observe o clculo do SPF sem ISPF habilitado em R6:
Observe o clculo do SPF sem ISPF habilitado em R6:
12 16 0 0 0 0 0 16
OSPF Avanado

4 0
Change record
LSIDs changed 1
4.4.4.4(R)
120
Observe o clculo 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)
Outras situaes que no cobertas pelas trs propriedades anteriores exigem o clculo FULL
do SPF, por exemplo:
11 Troca de mtricas e adio de novos enlaces, que melhoram a conectividade da rede;
11 Alterao de qualquer enlace do prprio roteador (por exemplo, qualquer alterao em
R6 fora o processamento FULL do SPF);
11 Alterao de enlace em redes Full Mesh (todos os roteadores ligados a todos os outros
roteadores).
11 fcil ver os benefcios de usar o ISPF, j que o tempo de execuo pode ser conside-
ravelmente menor.
11 Situaes que diferem das trs propriedades apresentadas exigem clculo Full do SPF,
por exemplo:
22 Troca de mtricas e adio de novos enlaces;
22 Alteraes em qualquer enlace do prprio roteador.
11 Em ambientes de conectividade Full-Mesh, ou seja, todos roteadores tm enlaces
para todos os demais roteadores, tambm requerem execuo Full do SPF.
11 No funcionamento padro do OSPF, em caso de reiniciao do processo ou problemas

no mdulo de controle, as vizinhanas so desfeitas;
11 Roteadores vizinhos precisam fazer a convergncia do trfego buscando caminhos
alternativos, caso existam;
11 Em certos equipamentos, mesmo com a reinicializao do Plano de Controle, o Plano
de Encaminhamento pode continuar funcionando;
11 Para evitar indisponibilidades quando esses equipamentos esto presentes, o IETF
padronizou o Graceful Restart, RFC 3623.
Os roteadores atuais so compostos por trs planos de operao:
11 Plano de Controle;
11 Plano de Encaminhamento;
11 Plano de Gerncia.
q
Graceful Restart
121
O Plano de Controle o conjunto de processos responsveis por negociar informaes de

rotas entre roteadores, configurao de rotas estticas, criao da rvore do protocolo
Spanning Tree etc. Todos esses processos so executados na CPU principal do roteador.
O Plano de Encaminhamento o conjunto de processos responsveis pelo encaminhamento
dos quadros e pacotes entre interfaces fsicas do equipamento de rede. O modo como o encaminhamento 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 especficos
so capazes de encaminhar e rotear milhes de pacotes por segundo, sem necessidade de usar
a CPU principal do equipamento de rede. Nos equipamentos que possuem mdulos especficos
de portas e mdulos de gerncia (supervisores ou Route-Engines), os papis so bem mais
claros, uma vez que o Plano de Controle tende a ficar no mdulo de gerncia.
O Plano de Gerncia o conjunto de processos responsveis por monitorar e notificar o
administrador de rede sobre o funcionamento do equipamento, por exemplo, contadores de
interfaces, uso de CPU e memria, processo SNMP, NetFlow/sFlow, Syslog etc.
Os roteadores modernos so compostos por trs planos de operao:
11 Plano de Controle: responsvel por definir como o trfego deve ser encaminhado;
utiliza a CPU principal do equipamento;

11 Plano de Encaminhamento: responsvel pelo encaminhamento do trfego entre as
interfaces; utiliza processadores dedicados (ASICs ou FPGAs);
11 Plano de Gerncia: responsvel por monitorar a operao do equipamento; utiliza a
CPU principal do equipamento;
11 O OSPF e outros protocolos de roteamento funcionam no Plano de Controle.
Na operao de uma rede com muitos roteadores, inevitavelmente um ou mais equipamentos
de rede precisaro ter seus Sistemas Operacionais atualizados, seja por correes de segurana, seja por novas funcionalidades. Equipamentos de rede mais modernos permitem que
o Sistema Operacional seja atualizado, mas sem remover as informaes de encaminhamento
e/ou roteamento dos mdulos 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 aps o carregamento total e sincronismos entre os mdulos de
gerncia que as tabelas de encaminhamento so atualizadas ou alteradas.
No funcionamento padro do OSPF, se o processo OSPF reiniciado, cada vizinho OSPF vai
perceber a queda da adjacncia aps o Dead Interval e vai executar o processo SPF para
calcular novas rotas que no incluam o roteador que est indisponvel. Aps esse clculo,
o trfego pode ser roteado por outro caminho. Porm, como mencionado anteriormente,
alguns roteadores modernos permitem que o trfego continue a ser encaminhado mesmo
em caso de reinicializao do mdulo de gerncia ou de um processo especfico. Para que
esse encaminhamento continue a ocorrer, o IETF padronizou uma funcionalidade chamada
OSPF Graceful Restart. Essa funcionalidade est padronizada na RFC 3623.
OSPF Avanado
A funcionalidade Graceful Restart permite que o roteador OSPF notifique seus vizinhos de que
122
o processo OSPF ser reiniciado e que eles devem agir como se o roteador OSPF estivesse funcionando normalmente. Essa notificao feita atravs de um LSA especfico, chamado Grace
LSA, que contm na mensagem o motivo da reinicializao e o tempo de indisponibilidade
estimado (Grace Period). No processo do Graceful Restart, existem duas entidades:
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
processo ser reinicializado, mas que o encaminhamento do trfego no ser interrompido 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 trfego
normalmente
11 Se no suportar, nenhuma resposta enviada e aps o Restarting Router reiniciar,
as vizinhanas ou adjacncias sero finalizadas
Quando o Restarting Router deseja executar um Graceful Restart, ele envia um Grace LSA
para seus vizinhos. Aps 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 no suporta o Grace LSA. Nesse caso, o roteador OSPF ignora os Grace
LSAs. O Restarting Router, aps algumas tentativas, mesmo que no tenha recebido o LSA
ACK, procede com a reinicializao. Para o vizinho que no suporta o Graceful Restart, o
processo de funcionamento continua o mesmo: aps o Dead Interval, ele vai gerar LSAs
do tipo Router para os vizinhos OSPF informando que os enlaces com o Restarting Router
no esto mais disponveis.
Aps a reinicializao, o Restarting Router precisa seguir alguns passos para sair do estado
do Graceful Restart:
1. O Restarting Router estabelece as adjacncias normalmente com os vizinhos OSPF;
2. Durante o sincronismo do LSDB, o Restarting Router no gera nenhum LSA, apenas recebe
3. Aps montar o LSDB com os LSAs recebidos, o Restarting Router executa o procedimento
SPF para calcular as rotas. Porm, as rotas no so 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 no perceber inconsistncias, como por exemplo, um pacote Hello
que no 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).
os LSAs dos vizinhos;
123
11 Antes de voltar a operar novamente, o Restarting Router precisa:
22 Reestabelecer as vizinhanas OSPF

22 Durante o sincronismo do LSDB, no pode gerar nenhum LSA
22 Aps receber os LSAs, executa o SPF mas no instala as rotas (usa para
os Virtual Links)
22 Verifica as mensagens Hello para ver se deve virar DR
22 Se no houver inconsistncias nos LSAs, envia um novo Grace LSA com o tempo
expirado (3600s)
Aps sair do estado de Graceful Restart, o Restarting Router executa alguns procedimentos:
11 Todos os LSAs do tipo Router so reoriginados para garantir consistncia;
11 J todos os LSAs do tipo Network so reoriginados nos segmentos onde o Restarting
Router o DR;
11 O processo SPF reexecutado e as rotas desta vez so instaladas;
11 LSAs do tipo 3, 4, 5 e 7 so reoriginados, caso o Restarting Router seja ABR ou ASBR;
11 Todas as entradas na tabela de rotas que no so mais vlidas so removidas;
11 Todos os Grace LSAs so removidos do LSDB.
11 Aps sair do estado de Graceful Restart, o Restarting Router executa alguns
procedimentos:
22 Todos os LSAs do tipo Router so reoriginados para garantir consistencia;
22 Todos os LSAs do tipo Network so reoriginados nos segmentos onde o Restarting
Router o DR;
22 O processo SPF reexecutado e as rotas dessa vez so instaladas.
22 LSAs do tipo 3, 4, 5 e 7 so reoriginados, caso o Restarting Router seja ABR ou ASBR;
22 Todas as entradas na tabela de rotas que no so mais vlidas so removidas;
22 Todos os Grace LSAs so 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 no mais necessrio ficar nesse estado;
11 O Grace Period informado no Grace LSA expirou. Nesse caso, o Restarting Router no
retornou s atividades dentro da janela de tempo previsto. Logo, o Helping Router age
como se estivesse indisponvel. A partir desse momento, o processo normal do OSPF de
indisponibilidade de vizinho executado;
11 Uma mudana do LSDB indicando que a topologia da rede mudou. Nesse caso, o Helping
OSPF Avanado
Router encerra seu papel no processo do Graceful Restart.
124
11 Os roteadores Helping Routers podem deixar de ser Helping Router diante dos
seguintes eventos:
22 Um Grace LSA com tempo expirado recebido do Restarting Router.
22 O Grace Period informado no Grace LSA expirou
22 Uma mudana do LSDB indicando que a topologia da rede mudou
11 O modo Helping Router j habilitado por padro em alguns fabricantes. Muitas vezes
com o nome IETF NSF helper (Non-Stop Forwarding).
Alguns fabricantes j ativam o modo Helping Router por padro, facilitando a operao da
rede. Por exemplo, observe a sada 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
IETF NSF helper support enabled
possvel 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>
External flood list length 0
125
11 Para iniciar o Graceful Restart no Restarting Router basta configurar o processo OSPF:
R1# (config)# router ospf 10

R1# (config-router)#nsf ietf restart-interval <0-1800>
11 E na sequncia, reiniciar o processo OSPF

11 Ao solicitar a reinicializao, um Grace LSA ser enviado com o tempo informado no
comando restart-interval.
Aps aplicar esse comando, quando o operador reiniciar o processo OSPF, um Grace LSA
ser enviado com o tempo informado no comando restart-interval.
BFD para OSPF

Na sesso 1, o processo de estabelecimento de uma vizinhana OSPF foi apresentado, bem
como o processo para detectar a queda dos vizinhos. Em particular, o Dead Interval, intervalo de tempo em que o OSPF espera por pacotes Hello de um vizinho antes de declar-lo
"morto" foi apresentado, com alguns exemplos. De acordo com a RFC 2328, o Dead Interval
padro especificado em 40 segundos. Esse tempo de 40 segundos extremamente
elevado para as aplicaes modernas e, principalmente, as aplicaes interativas. Para
situaes onde os roteadores esto diretamente conectados, a queda de interface OSPF
ativa imediatamente o processo de convergncia OSPF. Porm, alguns cenrios apresentam
desafios extras. Observe a topologia da figura 4.5.
11 Sesso 1 apresentou o processo de estabelecimento e identificao da queda da adjacncia OSPF, usando ambos Hello (10 segundos) e Dead Interval (40 segundos)
O modo Restarting
Router, da funcionalidade Graceful Restart,
s suportado por
equipamentos com
suporte ao encaminhamento de pacotes,
mesmo sem o mdulo
de gerncia estar em
operao. Esse
comportamento
comum em equipamentos de chassis, que
so modulares.
Equipamentos menores
normalmente
suportam apenas o
modo Helper Router.
11 Quando uma enlace OSPF muda de estado, o roteador diretamente conectado

detecta a mudana e notifica os demais roteadores OSPF
11 Se o enlace no estiver diretamente conectado, o Dead Interval utilizado
11 Observe a figura 4.5
Internet
R3
s1/0
s1/0
R1
f0/0
2
SW2
SW1
1
OSPF Avanado
f0/0
Rede de Transporte A
f0/0
R2
A rede da figura 4.5 possui trs 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. Alm disso, h um enlace serial entre os roteadores R1 e R3.
Observe as configuraes a seguir.
126
Figura 4.5
Bidirectional
Forwarding
Detection.
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
possvel 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
que a interface Serial1/0, a interface Serial1/0 ser utilizada apenas como uma interface de
proteo em caso de queda na infraestrutura da "Rede de Transporte A".
11 A "Rede de Transporte A" conecta os trs roteadores, criando uma rede Broadcast
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 esto na rea Backbone
11 Todas as adjacncias esto estabelecidas:
R1#sh ip ospf neighbor
3.3.3.3 0 FULL/ - 00:00:36 10.1.3.3 Serial1/0
conecta R1 e R3. Como a interface FastEthernet0/0 dos roteadores R1 e R3 tem melhor custo
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

1.1.1.1 1 FULL/DROTHER 00:00:37 10.0.0.1 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 adjacncias estabelecidas, uma via rede
Broadcast, outra via rede Ponto-a-Ponto.
A seguir, algumas sadas 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 vizinhanas, sendo duas entre eles. Uma via interface Serial1/0, uma via
interface FastEthernet0/0. possvel ver que uma vizinhana Ponto-a-Ponto (State: Full/-) e
outra Broadcast (Full/DROTHER, BDR ou DR).
Vamos analisar algumas possibilidades de alterao 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 FastEthernet0/0 est DOWN, apenas R1 seria notificado. Atravs da interface FastEthernet0/0, R1
notifica R2; R2 atualiza suas rotas para chegar em R3 via R1. A convergncia foi concluda;
11 Interface 3 do SW1 e Interface FastEthernet0/0 do R2 tem seus estados alterados
para DOWN (problema no enlace): como R2 no tem redundncia de acesso, R2 no
tem o que fazer. R1 e R3 vo esperar pelo Dead Interval (40s) para removerem R2 do
OSPF Avanado
LSDB da rea Backbone;

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. Atravs da interface FastEthernet0/0, R3 notifica R2;
R2 atualiza suas rotas para chegar em R1 via R3. A convergncia foi concluda;
128
Algumas possibilidades de indisponibilidades e impacto na rede:

11 Enlace SW1-R3 indisponvel: R3 cria um LSA Router para os vizinhos, nesse caso R1;
R1 atualiza R2 para enviar os pacotes para R3 via R1. Convergncia concluda;

11 Enlace SW1-R2 indisponvel: R2 no tem redundncia, fica indisponvel;
11 Enlace SW2-R1 indisponvel: R1 cria um LSA Router para os vizinhos; nesse caso, R3;
R3 atualiza R2 para enviar os pacotes para R1 via R3. Convergncia concluda;
Em nenhum desses casos, o Dead Interval causou indisponibilidade extra. Outra possibilidade seria:
11 Enlace SW1-SW2 indisponvel: nenhum roteador OSPF diretamente afetado, Dead
Interval ser utilizado. Enquanto isso, o enlace R1-R3 de backup fica sem utilizao.
40 segundos de indisponibilidade pode ser observado.
possvel observar que nesses trs casos listados, apesar do fato de o Dead Interval ser
relativamente alto, esse valor no trouxe impacto, pois a queda da interface tratada imediatamente 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 no afeta nenhuma interface dos roteadores OSPF. Ento, os roteadores R1,
R2 e R3 vo esperar pelo Dead Interval para fazer a convergncia da rede, ou seja, apesar de
o enlace entre R1 e R3 estar disponvel, esse s ser utilizado aps o Dead Interval.
22 Enlace entre SW1 e SW2 desativado. As adjacncias OSPF so removidas aps
40 segundos. Observe o Dead Interval decrementando.
R1#show ip ospf neighbor

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#
Aps 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
alcanveis novamente.
3.3.3.3 0 FULL/ - 00:00:30 10.1.3.3 Serial2/0
R1#
129

R1#
R3#
Na sesso de aprendizagem 1, a funcionalidade de Fast Hello do OSPF foi apresentada justamente para resolver esse tipo de problema, uma vez que a deteco de desconexo dos
vizinhos ocorre em menos de 1 segundo. Porm, o Fast Hello processado pelo Mdulo de
Gerncia, no Plano de Controle, consumindo recursos extras de CPU e Memria.
Para permitir uma soluo mais escalvel e independente do tipo de protocolo de roteamento, 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 Encaminhamento. Por ser mais leve, o BFD permite que mais sesses sejam monitoradas, com
intervalos de monitoramento de 50 milisegundos. Alm disso, o BFD agnstico ao protocolo de roteamento, podendo ser utilizado para rotas estticas, OSPF, ISIS, entre outros.
Alguns equipamentos suportam centenas de sesses BFD ao mesmo tempo.
11 Funcionalidade Fast Hello permite convergncia em menos de 1 segundo, porm
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 convergncia em intervalos de testes de 50 milissegundos
11 Independente de protocolo: funciona com OSPF, rota esttica, 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 aps uma quantidade de mensagens
perdidas (tambm definidas pelo Engenheiro de Redes), a sesso BFD declarada DOWN.
Quando utilizado com o OSPF, o BFD tambm notifica o processo OSPF da queda da sesso,
logo o roteador OSPF atualiza seu LSDB removendo o vizinho indisponvel. Nesse caso, o
Engenheiro de Redes pode inclusive aumentar o intervalo das mensagens Hello, desonerando o processo OSPF. Assim como o protocolo Hello, o BFD tambm suporta autenticao
das suas mensagens, inclusive com MD5.
Nas redes atuais, o protocolo BFD tem sido muito utilizado em casos onde a conexo entre
roteadores feita atravs de redes Ethernet ou MPLS, que no geram circuitos fim-a-fim.
11 BFD utiliza sistema de mensagem de teste similar ao Hello do OSPF
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 sesso
OSPF Avanado
11 Muito utilizado para testar enlaces providos via Ethernet ou MPLS
130
A configurao BFD extremamente simples de ser feita:

1. Habilita-se o BFD nas interfaces dedicadas, definindo o intervalo entre mensagens
(interval), o tempo mnimo entre mensagens (min_rx) e a quantidade de mensagens que
devem ser perdidas para considerar o vizinho OSPF como indisponvel (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 mnimo para receber as mensagens de 50 milisegundos e a
quantidade de mensagens perdidas de 3. Ou seja, em caso de indisponibilidades, aps
150 milisegundos (3x50), a sesso OSPF com o roteador inativo seria terminada e o processo
de convergncia executado.
11 A configurao BFD to simples quanto o protocolo:
22 1. Configura-se a(s) interface(s) que tero 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
22 O tempo mnimo para receber as mensagens foi configurado para 50 milisegundos

22 Mensagens que devem ser perdidas antes de considerar a sesso BFD indisponvel: 3
22 Neste caso, o tempo de deteco da queda da adjacncia ocorre em 150 milisegundos.
2. Ativa-se o BFD no processo OSPF (todas as interfaces) ou em interfaces especficas.
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
2. Configura-se o processo OSPF para usar as informaes do processo BFD

Pode ser feito por interface:
l
Em alguns fabricantes, o
BFD s ativado quando
a adjacncia OSPF
recriada; logo pode ser
necessrio reiniciar o
processo OSPF.
configure terminal
ip ospf bfd
*ou para todas as interfaces:

configure terminal
router ospf 10
bfd all-interfaces
bfd all-interfaces
131
Para confirmar a ativao, 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:
R1#show ip ospf
(...)
BFD is enabled
Para verificar se as sesses esto criadas:

R1#sh bfd neighbors
Assim como no Fast

Hello, o Engenheiro de
Redes deve ser
cauteloso na escolha
de quando ativar o BFD
e tambm na escolha
do intervalo entre
testes. Intervalos muito
curtos tendem a
consumir mais recursos
e todos os roteadores
possuem um nmero
mximo de sesses
BFD suportadas, a
depender da plataforma.
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.0.0.3 8003/3 Up Up f0/0
10.0.0.2 8004/4 Up Up f0/0
Para confirmar se as sesses BFD esto criadas, utilize o comando a seguir:

R1#sh bfd neighbors
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.0.0.3 8003/3 Up Up f0/0
10.0.0.2 8004/4 Up Up f0/0
Uma vez que a sesso BFD foi ativada, no prximo 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 sesso BFD foi estabelecida, o processo BFD far os testes
no intervalo determinado, e ao detectar a queda, notificar o processo OSPF.
11 Ao ser notificado pelo BFD, o processo OSPF imediatamente desfaz a adjacncia com
o vizinho indisponvel e recria a SPT.
11 O Engenheiro de Redes deve ser cauteloso ao definir o tempo mnimo de intervalo
OSPF Avanado
do BFD e a quantidade de sesses a serem estabelecidas. Mais sesses e tempos
132
menores consomem mais recursos do roteador.
Supresso de Prefixos
Redes de provedores de servios de internet (internet Service Providers: ISPs) contm
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 trfego e a resilincia da rede. Em muitos
casos, as conexes so feitas entre pares de roteadores, seja atravs de circuitos seriais,
pticos ou via VLANs especficas.
No tpico do Incremental SFP, foi apresentada uma abordagem para evitar a execuo completa do SPF em casos de alterao de estados mais simples, como em roteadores folhas
ou enlaces que no fazem parte da SPT (Shortest Path Tree). Em redes que possuem muitos
enlaces que concentram apenas roteadores enlaces chamados de Redes de Trnsito ,
alm do ISPF, outro recurso est disposio do Engenheiro de Redes para aumentar a
escalabilidade do processo OSPF: a Supresso de Prefixos. Esse recurso foi padronizado
na RFC 6860 com o objetivo de remover os prefixos desses enlaces de trnsito da tabela de
rotas. Essa funcionalidade se aplica tanto em enlaces ponto-a-ponto como enlaces do tipo
Broadcast. Observe o cenrio da figura 4.6 (arquivo adr9-cap4-supressao.zip).
11 Redes de ISPs j possuem milhares de rotas, recebidas via BGP e IGP
11 Quanto mais enlaces entre roteadores, mais Redes de Trnsito so criadas

11 Redes altamente conectadas possuem em seus LSDBs muitos prefixos apenas para
trnsito, ou seja, desnecessrios do ponto de vista dos usurios
11 RFC 6860 padronizou uma funcionalidade para melhorar a escalabilidade do OSPF:
a Supresso de Prefixos
11 Redes de Trnsito so removidas do LSDB quando a Supresso de Prefixos habilitada
11 Melhora o tempo de convergncia atravs da diminuio do LSDB
192.168.1.0/24
R2
10.1.2.0/24
R3
10.2.3.0/24
10.2.4.0/24
Figura 4.6
Topologia para
Supresso de
Prefixos.
192.168.2.0/24
10.3.5.0/24
10.4.5.0/24
192.168.3.0/24
R4
R5
Nesta topologia, existem trs redes de usurios (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 enderear 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 enderear as conexes entre roteadores, seguindo o modelo em uso ao longo deste livro.
R1
133
Para ilustrar algumas diferenas de funcionamento, o enlace R1-R2 ficou configurado no

modo Broadcast, enquanto os demais enlaces esto configurados como ponto-a-ponto.
A seguir est a configurao 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:
22 Trs redes de usurios (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 trnsito (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 esto configurados como Ponto-a-Ponto.
Observe a seguir a sada da tabela de rotas de R5:
R5#show ip route ospf

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
O 10.0.0.2/32 [110/21] via 10.4.5.4, 00:03:12, FastEthernet0/1
[110/21] via 10.3.5.3, 00:03:12, FastEthernet0/0
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, possvel observar diversas rotas, incluindo as rotas que endeream
conexes entre roteadores (redes de trnsito), como por exemplo os prefixos 10.1.2.0/24,
OSPF Avanado
10.2.3.0/24 e 10.2.4.0/24. A rede de usurio 192.168.2.0/24 foi redistribuda no processo

OSPF pelo roteador R3 (por isso O E2 frente da rota). Observe tambm que o ECMP est
em uso, com alguns prefixos possuindo mais de um caminho por exemplo, 10.0.0.2/32
pode ser alcanado via R4 (10.4.5.4) e R3 (10.3.5.3).
muito comum em ISPs de mdio e grande porte que as conexes 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 Trnsito. Porm, essas rotas tm pouco ou nenhuma importncia na maioria dos
casos, e acabam consumindo recursos do LSDB e dos roteadores OSPF. A RFC 6860 props
justamente remover esses prefixos das tabelas de roteamento OSPF, diminuindo o LSBD, o
tempo de convergncia, aumentando a escalabilidade e a segurana da rede.
Antes de apresentar o funcionamento da RFC 6860, uma reviso sobre os LSA Router e
Network ser feita a seguir, utilizando a topologia da figura 4.6 como exemplo. A sada 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
possvel ver que R1 est anunciando trs 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 sada 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
OSPF Avanado
Network) e 2 enlaces do Tipo 1 (point-to-point). O Tipo 1 utilizado para o clculo do SPF e

est relacionado a enlaces ponto-a-ponto. Quando o Tipo 1 utilizado, o campo Link Data
informa o endereo IP da interface a ser utilizada para alcanar o vizinho OSPF. Quando o
Tipo 3 utilizado, o campo Link Data informa a mscara de subrede da rede Stub. No caso
do Tipo 2, o campo Link Data informa o endereo IP da interface do originador do LSA. No
Tipo 2, o campo Link ID informa o endereo IP da interface do roteador DR. Em caso de
dvidas, consulte a tabela 1.2, da sesso 1.
136
possvel notar que existem dois registros associados com o mesmo enlace entre o roteador R2 e o roteador R3:
TOS 0 Metrics: 1
TOS 0 Metrics: 1
Observe os LSAs do tipo Router na rea Backbone:

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 mtrica removidos para simplificar):
Number of Links: 6
137

O prefixo IP desse enlace no precisa ser acessado por usurios e seria mais seguro que
eles realmente no fossem alcanveis de fora da rede. Ento, bastaria ativar a supresso
de prefixos para remover esse e outros prefixos de trnsito do LSDB. A configurao para
remoo pode ser feita de duas maneiras:
Por interface OSPF:
configure terminal
ip ospf prefix-suppression
Por roteador:
configure terminal
router ospf 10
prefix-suppression
11 A Supresso 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 trnsito gerada.
Quando esses comandos so inseridos em interfaces do tipo ponto-a-ponto, nenhuma
rota associada a registros do Tipo 3 gerada. Observe o LSDB aps a insero 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
OSPF Avanado
10.0.0.5 10.0.0.5 12 0x80000007 0x00593D 3

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 Supresso de Prefixos habilitada:

Link ID
ADV Router
Age
Seq#
10.0.0.1
10.0.0.1
1579
0x80000004 0x004E17 3
Checksum Link count
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 supresso.
11 Lembre-se que redes de usurios, interfaces passivas e loopbacks no so redes de
trnsito, 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 sada antes de aplicarmos o comando
prefix-suppresion. A seguir possvel 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
possvel verificar que no existem mais enlaces do Tipo 3 (Stub) associados os enlaces
S h supresso para
LSAs Router e Network.
ponto-a-ponto. Enlaces associados a interfaces loopbacks ou interfaces passvas no so

suprimidos, pois no so considerados redes de trnsito.
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
11 Verificando a tabela de rotas em R5:
R5#sh ip route ospf

O
10.0.0.1/32 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0

O
10.0.0.3/32 [110/2] via 10.3.5.3, 01:35:06, GigabitEthernet1/0

192.168.1.1 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0

O E2
192.168.2.0/24 [110/20] via 10.3.5.3, 01:35:06, GigabitEthernet1/0

O
192.168.3.1 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0
11 possvel observar que no existem prefixos da rede 10.X.Y.N/24, somente prefixos

de usurios e interfaces Loopback.
Por essa sada possvel confirmar que as redes de trnsito no 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
OSPF Avanado
tabela de rotas se ele no era um registro do Tipo 3, e sim do Tipo 2?
140
11 possvel observar que o enlace 10.1.2.0/24 tambm no est na tabela de rotas de

R5, apesar de no ser Tipo 3.
11 Enlaces tipo 2(Transit) tambm so considerados redes de trnsito, por isso tambm
so suprimidos
11 RFC6860 define que a mscara de subrede do LSA Network seja alterada para /32.
Os enlaces do Tipo 2, apesar de no serem redes ponto-a-ponto, tambm so considerados

redes de trnsito, logo tambm no h necessidade de estarem na tabela de rotas. A RFC
6860 muda isso forando que os roteadores que suportem supresso de prefixos anunciem
a mscara do segmento de rede como /32 (nesse caso, sem a supresso seria /24):
R5#sh ip ospf database network
LS age: 158
LS Type: Network Links
Network Mask: /32
Observe o LSA Network:
R5#sh ip ospf database network

LS age: 158
LS Type: Network Links
Network Mask: /32
Verifique a Network Mask no est como /24, e sim como /32.

Com essa alterao, o roteador OSPF no cria uma rota para a rede de trnsito do Tipo 2.
Uma vez que no so mais divulgadas as redes de trnsito, qualquer teste com PING ou
TRACEROUTE gerado localmente no roteador no vai funcionar se a opo SOURCE no
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 endereo da interface mais prxima do
destino, e como endereos de interfaces no so mais anunciados, os pacotes no tm
como voltar!
.....
141
11 A princpal diferena, do ponto de vista da operao da rede, e o PING ou TRACEROUTE
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 no pinga. Ao fazer o PING ou TRACEROUTE de dentro do
roteador, o mesmo escolhe como IP de origem, o IP da interface mais prxima do destino.
11 Como o IP da interface mais prxima faz parte da rede de trnsito, R5 no 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 no consigo mais pingar o IP das interfaces? Dada as
mltiplas redundncias disponveis na rede, as melhores prticas do iBGP que as sesses
iBGP sejam feitas entre interfaces loopbacks, haja vista que essas no ficam indisponveis
com quedas de enlaces.
Quanto ao monitoramento via ping, esse realmente no possvel, mas via SNMP possvel
monitor-las, alm do Syslog. O IETF tambm criou a RFC 5837 para expandir o ICMP a fim
de ajudar nesse tipo de situao. Em breve as ferramentas de traceroute estaro disponveis com suporte a RFC 5837, que permitiro o traceroute fornecer informaes sobre as
interfaces envolvidas no caminho IP.
As alteraes propostas na RFC 6860 permitem que em uma rede OSPF dispositivos que
suportem supresso de prefixo funcionem com dispositivos que no suportam tal funcionalidade. Nesse caso, o roteador que no suportar supresso 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 no ser parte do contexto desse material, supresso 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
so utilizados, o que tambm consome recursos extras do roteador OSPF/MPLS.
OSPF Avanado
Monitorando o OSPF com a RFC 4750: OSPF Version 2 MIB
142
11 Redes de computadores devem ter seus ativos de rede e protocolos monitorados

constantemente.
11 O protocolo SNMP (Simple Network Management Protocol) prov diversas informaes
para operao da rede.
11 Itens como utilizao e erros das interfaces, CPU e memria, fontes, ventiladores e
laser recebido nas interfaces so itens mnimos 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 esto contemplados e disponveis para os operadores de rede.
11 Esses objetos podem ser monitorados por qualquer NMS (Network Management
System) disponvel que use SNMP, como Nagios, Cacti e Zabbix etc.
At esse ponto, diversas funcionalidades, tcnicas e abordagens para configurar o protocolo
OSPF foram apresentadas para fazer a rede OSPF robusta, escalvel e funcional. Porm, o
Engenheiro de Redes no 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 informao suficiente para identificar, isolar e restaurar a rede.
Normalmente, apenas os monitoramentos padro so feitos utilizando SNMP (Simple
Network Management Protocol): utilizao e erros nas interfaces, quantidade de pacotes
unicast, broadcast e multicast, uso de CPU e memria, e poucos outros. Porm, via SNMP,
possvel monitorar muitos outros objetos, entre eles objetos relacionados ao protocolo OSPF.
A RFC 4750 especifica a Management Information Base (MIB), que descreve quais objetos so
monitorados e quais so 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 prprio Sistema Operacional, como transaes de
bancos de dados. Aplicaes como MRTG e Cacti se consolidaram como interfaces web para
o SNMP; aplicaes mais modernas, como Zabbix, e algumas proprietrias, como o Tivoli ou
CA, tambm fazem uso do SNMP nativamente.
Como no um monitoramento comumente implantado, muitos desses softwares
mencionados no possuem templates j prontos para usar com OSPF, mas h vasta
documentao na internet no dificil cri-los. Porm, 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:
22 Estrutura de Dados de reas

22 Tabela de Mtricas de reas Sub
22 Link State Database
22 Tabelas de range de endereos e Hosts
Para ajudar no entendimento, as sees que compem a MIB do OSPF sero apresentadas,
bem como o OID da tabela e os principais objetos a serem explorados adiante.
22 Variveis Gerais
143
Tabela
OID
Principais Objetos
Variveis Gerais (General Variables): descreve variveis

globais do processo OSPF
ospfGeneralGroup
1.3.6.1.2.1.14.1
ospfRouterId
Estrututas de Dados de reas (Area Data Structure):

descreve todas as reas da qual o roteador faz parte
ospfAreaTable
1.3.6.1.2.1.14.2
ospfAreaId ospfAuthType
Tabela de Mtricas de reas Stub (Area Stub Metric

Table): descreve as mtricas enviadas para a(s) rea(s)
Stub
ospfStubAreaTable
ospfStubAreaId
Link State Database (LSDB): prov informaes do

LSDB para tratamento de erros
ospfLsdbTable
Tabela de Range de Endereos (Address Range Table):

prov informaes sobre sumrios e rotas de hosts
ospfAreaRangeTable
Tabela de Hosts (Host Table): prov informaes sobre

sumrios e rotas de hosts
ospfHostTable
ospfHostMetric
1.3.6.1.2.1.14.6
ospfHostAreaID
Tabela de Interfaces (Interface Table): prov informaes sobre as interfaces OSPF
ospfIfTable
1.3.6.1.2.1.14.7
ospfIfType
ospfAdminStat
1.3.6.1.2.1.14.3
ospfLsdbAreaId
1.3.6.1.2.1.14.4
ospfAreaRangeNet
1.3.6.1.2.1.14.5
ospfIfHelloInterval
ospfIfDesignatedRouter
Tabela de Mtrica de Interface (Interface Metric Table):

prov informaes de mtrica das interfaces OSPF
ospfIfMetricTable
ospfIfMetricValue
Tabela de Interface Virtual (Virtual Interface Table):

prov informaes sobre os Virtual Links
ospfVirtIfTable
1.3.6.1.2.1.14.9
ospfVirtIfNeighbor
Tabela de Vizinho (Neighbor Table): descreve os vizinhos OSPF
ospfNbrTable
1.3.6.1.2.1.14.10
ospfNbrIpAddr
1.3.6.1.2.1.14.8
ospfNbrRtrId
ospfNbrState
Tabela de Vizinho Virtual (Virtual Neighbor Table): descreve os vizinhos OSPF usando Virtual Links
ospfVirtNbrTable
ospfVirtNbrArea
1.3.6.1.2.1.14.11
ospfVirtNbrRtrId
LSDB Externo (External Link State Database): prov

informaes do LSDB para tratamento de erros
ospfExtLsdbTable
ospfExtLsdbType
Tabela de Range Agregado (Aggregate Range Table):

informa os prefixos sumarizados
ospfAreaAggregateTable
LSDB Local (Local Link State Database): idntico ao

LSDB mas contm apenas LSAs Opacos (Tipo 9)
ospfLocalLsdbTable
LSDB escopo AS (AS-scope Link State Database): idntico ao LSDB mas contm apenas LSAs Externos
ospfAsLsdbTable
1.3.6.1.2.1.14.12
1.3.6.1.2.1.14.19
11 Tabelas de Interface, Mtrica de Interface e Interface Virtual;
OSPF Avanado
11 LSDB Externo, LSDB Local, LSBD escopo AS;
144
11 Tabela de Range Agregado.
ospfLocalLsdbEntry
1.3.6.1.2.1.14.17
Continuao das tabelas disponveis na MIB do OSPF:
11 Tabelas de Vizinho e Vizinho Virtual;
ospfAreaAggregateAreaID
1.3.6.1.2.1.14.14
ospfAsLsdbEntry
Tabela 4.1
Sees que
compem a MIB
do OSPF.
l
Cada seo possui
diversos objetos, que
podem ser do tipo
"somente leitura"
(read-only)
ou "leitura e escrita"
(read-write).
importante o aluno ter
em mente que um
roteador mal-configurado pode criar riscos
de segurana.
Conforme mencionado anteriormente, a MIB do OSPF foi criada para permitir o monitoramento remoto dos objetos, tabelas e parmetros que compem a operao do OSPF em
um determinado roteador. Os resultados obtidos via SNMP tambm podem ser obtidos
pela linha de comando do equipamento; porm, em ambientes com muitos equipamentos,
o ideal automatizar a operao e monitoramento. Para ilustrar as sadas possveis, vamos
utilizar a topologia da figura 4.7.
11 A MIB OSPF possui o OID 1.3.6.1.2.1.14

11 Cada tabela tem um OID - Object Identifier que a representa, atravs de um ndice
especifico.
11 Exemplos:
22 Variveis 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 utilizao da MIB do OSPF, a figura 4.7 ser utilizada.
A topologia da figura possui diversas configuraes, como tipos de rea, de autenticao,
de rede e mtricas diferentes. Todas as configuraes j so de conhecimento dos alunos.
R1
Area 1 Stub
R2
10.1.2.0/24
10.2.3.0/24
192.168.3.0/24
.0/
6.1
2.1
17
4-
/2
5.0
D5
10.2.4.0/24
Senha Simples
Custo 15
.2.
10
24
192.168.1.0/24
R3
10.4.5.0/24
192.168.2.0/24
R4
Figura 4.7
SNMP.
Area 2
R5
Essa rede possui as seguintes caractersticas:

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 no possuem autenticao;
11 O enlace R2-R5 possui autenticao MD5;
11 O enlace R2-R4 possui autenticao simples;
11 Alm da rea Backbone, h uma rea Stub (Area 1) e uma rea Normal (rea 2);
11 R1 faz a redistribuio 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 gerncia, com pacote SNMP instalado, foi instalado com o IP 172.16.1.2.
Gerncia
145
11 Todas as consultas SNMP sero feitas a partir de um servidor Linux com o pacote
SNMP instalado.
11 As consultas foram feitas com o comando snmpwalk, SNMP verso 2 e a community
(senha) public.
11 Nos roteadores, a configurao a seguir foi feita para habilitar o SNMP:
configure terminal
snmp-server community public
11 No habilite essa configurao em ambientes de produo, a menos que troque

a community..
O servidor Gerncia possui o pacote SNMP instalado, o que lhe d acesso s ferramentas
de consulta e modificao via SNMP. Nos exemplos a seguir, o comando snmpwalk ser
utilizado, sempre com a community SNMP "public" e a verso 2 do SNMP (2c). A community
equivalente a uma senha de acesso e deve ser configurada no roteador. Em ambientes
de produo, considere utilizar communities mais complexas e a verso 3 do SNMP, que
suporta autenticao.
Antes de iniciar as consultas SNMP, o seguinte comando deve ser aplicado em cada roteador:
configure terminal
snmp-server community public
Ateno: esse comando habilita o processo SNMP no roteador, e permite consultas

que usarem a community "public". No aplique esse comando dessa maneira em
equipamentos de produo, a menos que saiba exatamente o que est fazendo!
No servidor de gerncia, a MIB OSPF deve estar instalada. A configurao do SNMP e a instalao da MIB OSPF sero apresentados como parte das atividades prticas da sesso de
aprendizagem 4.
A seguir, as principais tabelas sero apresentadas, usando como referncia o nome do
OID apresentado na tabela de OIDs, com os principais objetos exemplificados. Caso queira
conhecer todos os objetos disponveis, consulte a RFC 4750.
Explorando a tabela ospfGeneralGroup (Variveis Globais)

11 A tabela Variveis Globais representada pelo objeto ospfGeneralGroup, com
ID 1.3.6.1.2.1.14.1.
11 Observe os objetos disponveis 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 Avanado
OSPF-MIB::ospfVersionNumber.0 = INTEGER: version2(2)

OSPF-MIB::ospfAreaBdrRtrStatus.0 = INTEGER: true(1)
OSPF-MIB::ospfASBdrRtrStatus.0 = INTEGER: false(2)
OSPF-MIB::ospfExternLsaCount.0 = Gauge32: 1
OSPF-MIB::ospfExternLsaCksumSum.0 = INTEGER: 51808
OSPF-MIB::ospfTOSSupport.0 = INTEGER: false(2)
OSPF-MIB::ospfOriginateNewLsas.0 = Counter32: 60
146
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)
11 possvel ver na sada o router-id configurado em R2, a verso 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 esto 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)
possvel ver nessa sada acima o router-id do roteador:

Alm do router-id, podemos ver que o processo OSPF est habilitado:

A verso do OSPF, nesse caso, verso 2:

Quando se deseja apenas um objeto especfico, podemos filtr-lo no comando snmpwalk:

snmpwalk -v 2c -c public 10.0.0.2 ospfRouterId
Vamos consultar o router-id de cada roteador:

E que esse roteador um ABR, j que est na rea 1 tambm:
147

Nesse momento, podemos confirmar que todos os roteadores esto com o SNMP configurado
e todos tm suporte a MIB do OSPF. Vamos dar prosseguimento e explorar outras tabelas.
Explorando a tabela ospfAreaTable

11 Usando a OID ospfAreaTable, podemos consultar informaes sobre as reas OSPF.
11 Observe a sada 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 possvel ver que R2 um ABR (possui duas reas (0.0.0.0 e 0.0.0.1)), sem autenticao
(valor 0) por rea.
Vamos explorar a ospfAreaTable. Nessa tabela, os objetos mais importantes so:
11 ospfAreaID: informa as reas presentes em um roteador;
11 ospfAuthType: informa que tipo de autenticao 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 no h autenticao para a rea (valor 0 representa sem autenticao).
Observe a consulta feita ao roteador R4, que tambm possui duas reas (Backbone e rea 2)
e no possui autenticao por rea.
OSPF Avanado
148
Alm disso, a ospfAreaTable possui os seguintes objetos que podem ser muito teis:
11 ospfSpfRuns: informa a quantidade de vezes que o SPF foi executado para uma rea
especfica. Quando h muitas modificaes em um curto espao 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 esto associados s reas, a sintaxe de sada 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 esto associados s reas, a sintaxe de sada ser sempre:
OSPF-MIB::OBJETO.REA = Valor
Observe a sada 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 trs 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 informaes tambm da rea 2:
snmpwalk -v 2c -c public 10.0.0.4 ospfAsBdrRtrCount
snmpwalk -v 2c -c public 10.0.0.4 ospfAreaBdrRtrCount
149
Explorando a tabela ospfStubAreaTable

11 A tabela ospfStubAreaTable s existe nos roteadores que possuem um rea Stub.
11 Caso o roteador consultado no 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 Alm disso, possvel ver a mtrica associada rota padro 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 mtrica 2, 1 da prpria 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 no 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 no existe nesse roteador. Como o roteador R2 est conectado 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 associado rota padro 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 mtrica total de 2: 1 da interface FastEthernet + 1 anunciado por R2 para essa

rota. Observe a troca do custo em R2:
OSPF Avanado
configure terminal
150
router ospf 10
area 1 default-cost 5
Confirmando via linha de comando e via SNMP:

R3#sh ip route ospf
possvel observar que tanto via SNMP quanto via CLI possvel monitorar o custo da rota
padro na rea Stub.
Explorando a tabela ospfLsdbTable

11 A tabela ospfLsdbTable apresenta o LSDB inteiro, de cada rea
11 Contm os LSA existentes, nmero de sequncia, Age, tipos, etc.

11 Observe a sada 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 (Sada 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 so os LSAs existentes, nmero de sequncia, Age, tipos etc. possvel
inclusive ver o LSA anunciado, em formato hexadecimal. Dessa tabela, o objeto mais importante o ospfLsdbAreaId. Observe a sada a seguir de R2: a sada do comando snmpwalk foi
quebrada em blocos por tipo de LSA. A sintaxe tem a seguinte forma:
11 AREA: nmero da rea em 32 bits;

11 TIPO: router, Network, Summary, asSummary, asExternal, nssaExternal;
11 LINK_ID: depende do TIPO. Mais detalhes na sesso 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
OSPF-MIB::ospfLsdbAreaId.AREA.TIPO.LINK_ID.ADV_ROUTER IpAddress: aREA
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).
possvel 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).
possvel 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 no 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 sequncia, os mesmos tipos de LSA
para a rea 1 (0.0.0.1).
Explorando a tabela ospfHostTable

11 A tabela ospfHostTable mostra informaes sobre as interfaces de usurio, ou
hosts(interfaces passivas).
11 Essas interfaces no tem roteadores OSPF como vizinhos
11 Objetos mais importantes: ospfHostMetric e ospfHostAreaID
11 Exemplo:
OSPF Avanado
$ snmpwalk -v 2c -c public 10.0.0.3 OSPF-MIB::ospfHostTable

OSPF-MIB::ospfHostMetric.10.0.0.3.0 = INTEGER: 1
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

A tabela ospfHostTable mostra informaes sobre as interfaces de usurio ou hosts.

Essas interfaces no tm roteadores OSPF como vizinhos. Dessa tabela, os objetos mais
importantes so:
11 ospfHostMetric: mtrica associada interface;
11 ospfHostAreaID: rea da qual a interface faz parte.
Observe a seguir o snmpwalk. Os demais objetos foram omitidos para simplificar a visualizao.
$ 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
possvel ver o custo ou mtrica 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 informaes sobre as interfaces OSPF
11 Principais objetos:
22 ospfIfAreaId: informa a rea da qual a interface faz parte. A interface representada 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
22 ospfIfState: O estado da interface. Pode ser down, loopback, waiting, pointToPoint,

designatedRouter, backupDesignatedRouter ou otherDesignatedRouter.
22 ospfIfAuthType: Informa o tipo de autenticao configurada na interface. 0 significa
sem autenticao, 1 significa autenticao simples, 2 significa autenticao com MD5.
A tabela ospfIfTable mostra diversas informaes sobre as interfaces OSPF, e os principais
objetos so:
11 ospfIfAreaId: informa a rea da qual a interface faz parte. Observe que a interface
representada pelo IP que possui, e no pelo nome da interface. O formato est apresentado a seguir:
OSPF-MIB::ospfIfAreaId.IP.0 = IpAddress: AREA
22 ospfIfHelloInterval, ospfIfRtrDeadInterval: informam o Hello e o Dead Interval
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 endereo IP da interface
utilizado ao invs do nome da interface;
11 ospfIfRtrPriority: informa a prioridade da interface para escolha do DR. Prioridade 0
no elegvel, muito comum em redes ponto-a-ponto;
11 ospfIfHelloInterval: indica o intervalo Hello da interface. O padro 10 segundos;
11 ospfIfRtrDeadInterval: informa o intervalo Dead Interval da interface, indicando
quando o roteador vizinho ser considerado desconectado. O padro 40 segundos;
11 ospfIfState: o estado da interface. Pode ser down, loopback, waiting, pointToPoint,
designatedRouter, backupDesignatedRouter ou otherDesignatedRouter;
11 ospfIfAuthType: indica o tipo de autenticao configurada na interface. 0 significa sem
autenticao, 1 significa autenticao simples, 2 significa autenticao com MD5.
Observe a seguir o snmpwalk do roteador R2 e do roteador R5. Os demais objetos foram
omitidos para simplificar a visualizao. Analise a sada e veja se corresponde com a descrio 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 Avanado
OSPF-MIB::ospfIfState.10.0.0.2.0 = INTEGER: loopback(2)
154
OSPF-MIB::ospfIfState.10.1.2.2.0 = INTEGER: designatedRouter(5)

OSPF-MIB::ospfIfState.10.2.5.2.0 = INTEGER: pointToPoint(4)
OSPF-MIB::ospfIfAuthType.10.0.0.2.0 = INTEGER: 0
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):
$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfIfTable

Observe que a interface com IP 10.0.0.2, no possui autenticao (ofpfIfAuthType = 0)

155
Pelas sadas citadas, possvel identificar quais so as interfaces Loopback, Ponto a Ponto
e Broadcast, alm de saber quais possuem autenticao. Apenas usando o SNMP, o Engenheiro da Rede pode consultar todos os roteadores OSPF e validar se as configuraes esto
corretas e de acordo com a Poltica de Segurana. Por exemplo, com um script de poucas
linhas de cdigo possvel ver que existem interfaces que no tm autenticao, oferecendo
riscos infraestrutura de rede.
Explorando a tabela ospfVirtIfTable

11 A tabela ospfVirtIfTable descreve as configuraes relacionadas aos Virtual Links.
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 possvel ver a rea de trnsito (0.0.0.2), o IP do neighbor (10.0.0.4 - R4), valores de

Hello e Dead Interval e se existe autenticao (0 significa sem autenticao).
A tabela ospfVirtIfTable descreve as configuraes relacionadas aos Virtual Links e s existe
em roteadores que tm 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
possvel ver qual a rea de trnsito (ospfVirtIfAreaId) (rea 2 0.0.0.2), quem o vizinho do
Virtual-Link (ospfVirtIfNeighbor) (R4 10.0.0.4), se h autenticao (ospfVirtIfAuthType)
(0 no h) e valores de Hello (ospfVirtIfHelloInterval) e Dead Interval (ospfVirtIfRtrDeadInterval).
Explorando a tabela ospfNbrTable

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

22 spfNbrState: informa o estado de sincronismo do LSDB. Os estados possveis so:
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 histrico de todas os valores passados para fins de resoluo de problema.
156
A tabela ospfNbrTable descreve as vizinhanas estabelecidas pelo roteador OSPF. Essa uma
das tabelas mais importantes e que, se possvel, deve ter seu monitoramento automatizado.
Os objetos a seguir so extremamente teis:
11 ospfNbrIpAddr: informa o endereo 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, no elegvel
ou Ponto-a-Ponto;
11 ospfNbrState: indica o estado de sincronismo do LSDB. Os estados possveis so: down (1),
attempt (2), init (3), twoWay (4), exchangeStart (5), exchange (6), loading (7) ou full (8).
Caso a vizinhana no esteja em "full", a menos que seja uma adjacncia 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 visualizao.
$ 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:

157

Observe que todas as vizinhanas esto no estado "full".

O Engenheiro de Redes deve consultar frequentemente o objeto ospfNbrState e manter
histrico de todas os valores passados para fins de resoluo de problema.
Explorando a tabela ospfAreaAggregateTable

11 A tabela ospfAreaAggregateTable descreve as rotas sumarizadas pelo roteador OSPF
11 Caso no exista rota sumarizada, a tabela no ser criada.

11 Principais objetos:
22 ospfAreaAggregateAreaID: informa a rea associada sumarizao.
22 ospfAreaAggregateLsdbType: informa o tipo de sumarizao sendo executado.
Pode ser summaryLink (3) ou nssaExternalLink (7).
22 ospfAreaAggregateNet: informa o prefixo sumarizado;
22 ospfAreaAggregateMask: informa a mscara de sub-rede do prefixo sumarizado.
A tabela ospfAreaAggregateTable descreve as rotas sumarizadas pelo roteador OSPF. Como
uma funcionalidade opcional, caso o roteador no esteja fazendo sumarizao, a tabela
no 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 sumarizao 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 sumarizao. No caso de R4, a
rea 2 (0.0.0.2);
11 ospfAreaAggregateLsdbType: informa o tipo de sumarizao sendo executado. Pode
OSPF Avanado
ser summaryLink (3) ou nssaExternalLink (7). Como em R4 foi feito com o comando area
158
range, do tipo LSA Summary;

11 ospfAreaAggregateNet: informa o prefixo sumarizado;
11 ospfAreaAggregateMask: informa a mscara de subrede do prefixo sumarizado.
A seguir, observe a sada do snmpwalk de R4. possvel 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:
router ospf
area 2 range 192.168.2.0 255.255.255.0
Observe a sada 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,
porm outros objetos esto documentados na RFC 4750. Alm disso, a RFC 4750 especifica
como fazer configuraes OSPF via SNMP, por isso a importncia de configuraes seguras.
11 Neste material, foram apresentados apenas os objetos principais. Mais objetos esto
disponveis na RFC 4750

11 Alm disso, a RFC 4750 especifica como fazer configuraes usando SNMP. possvel
adicionar uma interface ou criar uma rea OSPF via SNMP.
SNMPv3 e com Listas de Controle de Acesso filtrando os prefixos de origem.

11 importante ter essas medies integradas com algum software de gerncia de rede,
at para registrar o histrico das sadas.
Mas no basta apenas monitorar pontualmente: importante que essas consultas sejam
integradas com algum sistema de gerncia de rede, como Nagios, Cacti ou Zabbix, para que
sejam criados histricos. A configurao dessa integrao est fora do escopo desse material,
uma vez que existe vasta documentao desses softwares.
Na sesso de Atividades Prticas, o aluno ser instrudo como preparar um ambiente e fazer
testes na linha de comando para obter as informaes desejadas.
11 Por isso, garanta que est usando uma community complexa, se possvel usando
159
Concluso
Nesta sesso, foram apresentados alguns tpicos que podem auxiliar o Engenheiro de Redes
na implantao de redes OSPF de larga escala. Tpicos de escalabilidade e convergncia foram
apresentados; porm, alguns deles so relativamente novos e no so suportados por todos
os fabricantes. Mas, conforme foi apresentado, muitos deles so compatveis com a verso
padro do OSPF definida na RFC 2328, o que permite uma implementao gradual.
Comandos OSPF
A seguir, uma lista de comandos de configurao que tm relao com o tema da sesso 4.
Os comandos a seguir so aplicados na sesso de OSPF do roteador.
11 Habilita o ISPF no processo OSPF:
ispf
11 Habilita e define o tempo de expirao do Grace LSA:

nsf ietf restart-interval <0-1800>
11 Habilita BFD em todas as interfaces OSPF:

bfd all-interfaces
11 Habilita supresso dos prefixos de todas as redes de trnsito do roteador OSPF:

prefix-suppresion
Os comandos a seguir so aplicados na configurao 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 supresso de prefixos na interface OSPF:

Os comandos a seguir so aplicados no modo de configurao global do roteador.

11 Habilita o processo SNMP server no roteador com a comunidade estabelecida:
OSPF Avanado
snmp-server community <NOME_DA_COMMUNITY>
160
Jernimo Aguiar Bezerra mestre

em Mecatrnica e Bacharel em Cincia
da Computao pela Universidade
Federal da Bahia, Jeronimo Aguiar
Bezerra tem vasta experincia com
redes de computadores, sistemas operacionais, VoIP e GNU/Linux. Possuindo
algumas cer-tificaes 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
implementao da Rede REMESSA e do Ponto de Troca de
Trfego da Bahia. Jab esteve envolvido com redes acadmicas 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
avanada do protocolo OSPF em Redes TCP/IP de grande

porte. So estudados os pacotes OSPF e a sua utilizao.
So descritas as reas OSPF e as suas caractersticas.
So apresentadas as tcnicas de Engenharia de Trfego
processo de escolha de rotas do OSPF. So descritos
os mtodos de otimizao do OSPF. O curso garante ao
o avanada do protocolo OSPF na rede de sua instituio. Este livro inclui os roteiros das atividades prticas
e o contedo dos slides apresentados em sala de aula,
mento em suas organizaes ou localidades de origem.
02 5
630025

Idioma

OSPF Avançado

Enviado por

Dados do documento

Descrição:

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Descrição:

Direitos autorais:

OSPF Avançado

Enviado por

Descrição:

Direitos autorais:

OSPF

A RNP Rede Nacional de Ensino

Programa Interministerial RNP,

Jernimo Aguiar Bezerra

Copyright 2016 Rede Nacional de Ensino e Pesquisa RNP

Jos Luiz Ribeiro Filho

Escola Superior de Redes

Leandro Marcos Oliveira Guimares

Luiz Carlos Lobo Lobato

Equipe ESR (em ordem alfabtica)

Escola Superior de Redes

Rua Lauro Mller, 116 sala 1103

Dados Internacionais de Catalogao na Publicao (CIP)

Network Summary LSA e ASBR Summary LSA26

2. Entendendo as reas do OSPF

3. Engenharia de trfego com OSPF

Interfaces Passivas (Passive Interfaces)86

4. Otimizao e tpicos avanados

Escola Superior de Redes

As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

66 Descrever o funcionamento do OSPF

66 Entender o processo de escolha de rotas do OSPF

Convenes utilizadas neste livro

Funcionamento do protocolo OSPF; Tipos de pacotes OSPF; Transio de Estados

Entendendo o funcionamento do banco de dados do OSPF

e verso 3 para IPv6).

O funcionamento do protocolo OSPF se baseia no banco de dados topolgico (ou Link-State

Captulo 1 - Funcionamento do banco de

Tipos de pacotes OSPF

cao com MD5) ou 40 bytes (com autenticao com MD5):

Nmero de Sequncia Criptogrco

Captulo 1 - Funcionamento do banco de

zenam o valor da senha, como se fossem um nico campo;

Nmero de Sequncia Criptogrco

11 Pacotes OSPF usam o protocolo IP com TTL de 1;

11 IP de origem do pacote OSPF sempre o IP da interface conectada rea, no o

11 Detectar falhas de enlaces e roteadores.

11 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em

Relembrando: O OSPF pode funcionar em trs tipos diferentes de rede:

Formato do pacote Hello

Intervalo de Roteador Morto

Router) em redes Broadcast e NBMA. Prioridade 0 significa que o roteador no ele-

11 Designated Router: endereo IP da interface do DR no segmento de rede (no o Router-ID).

Responsabilidades do protocolo Hello

Descobrir roteadores OSPF adjacentes e estabelecer adjacncias

11 Nesse exemplo, ambos os roteadores esto configurados na rea Backbone ou

Captulo 1 - Funcionamento do banco de

R4 envia o primeiro pacote Hello:

Open Shortest Path First

Router Dead Interval: 40 seconds

Backup Designated Router: 0.0.0.0

Open Shortest Path First

Router Dead Interval: 40 seconds

Open Shortest Path First

Router Dead Interval: 40 seconds

Captulo 1 - Funcionamento do banco de

Network Mask: 255.255.255.0

11 Para evitar problemas ao criar adjacncias no OSPF, garanta que os temporizadores,

Processo de eleio dos roteadores Designated Router e Backup

Para exemplificar o processo de escolha do DR e do BDR em uma rede Broadcast, vamos

Captulo 1 - Funcionamento do banco de

e. Aps a escolha do R2 como BDR, o processo de escolha do DR iniciado. Caso mais de

22 Checam os campos Designated Router e Backup Designated Router do pacote Hello;