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