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