OSPF Avançado

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 encontrado 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 [email protected]. 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 [email protected]

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

iii

Network Summary LSA e ASBR Summary LSA 26 AS External LSA 27 NSSA External LSA 28 Remoção de LSAs 29 Conclusão 31 Comandos OSPF 32

2. Entendendo as áreas do OSPF Por que o OSPF faz uso do conceito de áreas? 33 Quais são os tipos de áreas e como elas se comportam em um ambiente OSPF 35 Área Backbone 36 Área Normal 37 Área Stub 37 Área Not-So-Stubby ou NSSA 38 Interconectando áreas com Virtual Links 38 Entendendo o LSDB 40 A: Observando o funcionamento do LSDB na Área Backbone 41 A1: Router-LSA e Network-LSA 41 A.2: Summary-LSA 48 A.3: AS External LSA 53 A.4: ASBR Summary LSA 57 A.5: NSSA-LSA 59 A.6: Virtual Links 61 Conclusão 66 Comandos OSPF 66

3. Engenharia de tráfego com OSPF Introdução 69 Sumarização de rotas 69 Agregação de rotas 76 Métricas 80 Escolha de caminhos pelo OSPF 81 Observe o LSDB de R1 a seguir. 83 Controlando atualizações de roteamento 86

iv

Interfaces Passivas (Passive Interfaces) 86 Rotas padrão 89 Filtrando prefixos 92 Lista de Controle de Acesso (Access Control List: ACL) 93 Lista de Prefixos (Prefix-List) 93 Listas de Distribuição (Distributed Lists) 94 Mapas de Rotas (Route-Maps) 94 Filtragem de prefixos Intra-Área OSPF 99 Agregação de LSAs AS-External 103 Comandos OSPF 106

4. Otimização e tópicos avançados Introdução 109 Escalabilidade e Estabilidade do OSPF 110 Incremental OSPF 110 Propriedade 1 113 Propriedade 2 117 Propriedade 3 119 Graceful Restart 121 BFD para OSPF 126 Supressão de Prefixos 133 Monitorando o OSPF com a RFC 4750: OSPF Version 2 MIB 142 Explorando a tabela ospfGeneralGroup (Variáveis Globais) 146 Explorando a tabela ospfAreaTable 148 Explorando a tabela ospfStubAreaTable 150 Explorando a tabela ospfLsdbTable 151 Explorando a tabela ospfHostTable 152 Explorando a tabela ospfIfTable 153 Explorando a tabela ospfVirtIfTable 156 Explorando a tabela ospfNbrTable 156 Explorando a tabela ospfAreaAggregateTable 158 Conclusão 160 Comandos OSPF 160

v

vi

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 educacionais 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ípicos 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 problema, 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 aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

vii

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso O curso descreve os detalhes do funcionamento do protocolo OSPF, permitindo ao aluno entender como o OSPF monta sua hierarquia em áreas e quais mensagens e tipos de pacotes são utilizados. Além disso, serão apresentadas alternativas para trabalhar com engenharia de tráfego, serão apresentados modos de como mudar as métricas e forçar o roteamento de tráfego por caminhos mais otimizados. Também serão apresentadas técnicas para controlar a redistribuição de prefixos utilizando os mapas de rotas (ou route-maps). O curso termina com uma sessão de sugestões de otimizações para a convergência do OSPF além de apresentar o SNMP como uma ferramenta de monitoramento do ambiente OSPF. Ao final do curso o aluno estará capacitado a:

66 Descrever o funcionamento do OSPF 66 Descrever os tipos de pacotes OSPF 66 Descrever quais são e como são utilizados os LSA (Link State Advertisements) 66 Descrever quais são os estados possíveis de um roteador OSPF 66 Distinguir os tipos de áreas existentes 66 Projetar e justificar quais tipos de área deseja utilizar 66 Entender o porquê de cada estado de cada banco de dados por área 66 Entender as técnicas de Engenharia de Tráfego com OSPF 66 Entender e configurar ajustes finos avançados no OSPF

viii

66 Entender o processo de escolha de rotas do OSPF 66 Entender Incremental OSPF 66 Entender Graceful Restart 66 Configurar BFD para OSPF 66 Configurar Supressão de Prefixos 66 Implementar Monitoramento da MIB para OSPF

A quem se destina Profissionais de TI que administram redes TCP/IP baseadas no protocolo OSPF e que já tenham um conhecimento básico do protocolo OSPF. Estudantes de Ciência da Computação interessados em aprofundar os conhecimentos em protocolo de roteamento OSPF.

Convenções utilizadas neste livro As seguintes convenções tipográficas são usadas neste livro: Itálico Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide q Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo w Indica referência complementar disponível em site ou página na internet.

Símbolo d Indica um documento como referência complementar.

Símbolo v Indica um vídeo como referência complementar.

Símbolo s Indica um arquivo de aúdio como referência complementar.

Símbolo Indica um aviso ou precaução a ser considerada.

Símbolo p Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo l Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação. ix

Permissões de uso Todos os direitos reservados à RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: TORRES, Pedro et al. Administração de Sistemas Linux: Redes e Segurança. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.

Comentários e perguntas Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo Rio de Janeiro – RJ – 22290-906 E-mail: [email protected]

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 certificaçõ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 diversos projetos de larga escala, como a implementação da Rede REMESSA e do Ponto de Troca de Tráfego da Bahia. Jab esteve envolvido com redes acadêmicas e comerciais pelos últimos 13 anos, com passagem pela Rede Nacional de Ensino e Pesquisa (RNP) e tendo feito parte de Grupos de Trabalho do IETF.

x

1 objetivos

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.

conceitos

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 11 OSPF está definido na RFC 2328 (atualmente usa-se a versão 2 para IPv4

q

e versão 3 para IPv6). 11 Funcionamento se baseia em um banco de dados topológico. 11 Existe apenas um banco de dados topológico por área (chamado de Link-State 11 Todos os roteadores da área têm de ter o mesmo LSDB. 11 Banco de dados criados a partir da troca de mensagens Link State Advertisements (LSAs). 11 Roteadores enviam LSAs com informações de enlaces conectados e seus custos. 11 Algoritmo SPF utilizado para calcular as rotas. 11 Cinco tipos de pacotes OSPF existem para fazer a troca das mensagens LSA.

O funcionamento do protocolo OSPF se baseia no banco de dados topológico (ou Link-State 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 funcionamento desse algoritmo foi detalhado e exemplificado na sessão de aprendizagem 3 do curso "Protocolos de Roteamento IP".

Capítulo 1 - Funcionamento do banco de dados do OSPF

Database ou LSDB).

1

O banco de dados topológico do OSPF é criado a partir dos LSAs, ou Link State Advertisements, que são as estruturas de dados responsáveis pelas informações topológicas dos roteadores OSPF, ou seja, contém informações sobre o estado de cada enlace pelo qual um determinado roteador é responsável. Nas mensagens LSA estão indicados o prefixo IP e a máscara de subrede do enlace, qual o roteador responsável pelo prefixo, qual é a métrica (ou custo) para alcançar aquele destino, um tempo de expiração e outras informações. É através dessas informações que o algoritmo SPF define qual é o melhor caminho para alcançar um destino IP. Após essa definição, uma rota IP é criada e enviada para o software gerenciador da tabela de rotas (Plano de Controle do roteador) decidir se vai ou não instalar na tabela de rotas. Para entender como o banco de dados topológico é montado e sincronizado, é importante conhecer os tipos de pacotes OSPF existentes, como os pacotes funcionam e em que momento eles são utilizados.

Tipos de pacotes OSPF Sincronização do banco de dados OSPF ocorre a partir de cinco pacotes OSPF:

q

11 Hello. 11 DD: database Description. 11 LSR: link State Request. 11 LSU: link State Update. 11 LSAck: link State Acknowledgement. O protocolo OSPF, diferentemente do RIP e do BGP, opera diretamente sobre o protocolo IP (usando o número de protocolo 89), ou seja, não utiliza o protocolo TCP para garantir a consistência dos dados trocados. Então, cabe ao próprio protocolo OSPF definir os mecanismos 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-

OSPF Avançado

cação com MD5) ou 40 bytes (com autenticação com MD5):

2

q

8 bits

8 bits

Versão=2

Tipo

32 bits

8 bits

8 bits

Tamanho do Pacote Router ID Area ID

Checksum

Tipo de Autenticação Autenticação

Figura 1.1 Cabeçalho OSPF compartilhado.

Autenticação Os campos estão detalhados a seguir: 11 Versão: para o protocolo IPv4, a versão atual do protocolo OSPF é a versão 2; para IPv6 é a versão 3; 11 Tipo: identifica um dos cinco pacotes OSPF (Hello (1), DD(2), LSR(3), LSU(4), LSAck(5)); 11 Tamanho do Pacote: tamanho do pacote OSPF em Bytes, somando o cabeçalho e o conteúdo, sem contar com a mensagem de autenticação MD5; 11 Router ID: endereço IP selecionado pelo processo OSPF para identificar o roteador. Geralmente está associado ao endereço IP da interface Loopback ou é configurado manualmente; 11 Area ID: identifica a área OSPF; 11 Checksum: valor de checksum do pacote OSPF, utilizado para verificar se o pacote está íntegro ou não na sua recepção. Usa o mesmo algoritmo do checksum do pacote IP; 11 Tipo de Autenticação: informa qual esquema de autenticação está sendo utilizado. Pode assumir os seguintes valores: 22 0: Sem autenticação; 22 1: Autenticação simples, utilizando texto sem criptografia. Pode utilizar senhas de até oito caracteres. Nesse tipo de autenticação, os dois campos Autenticação acima arma22 2: Autenticação criptográfica. Nesse caso, os dois campos Autenticação assumem o seguinte formato: 0x0000

Key ID

Tamanho

Número de Sequência Criptográﬁco 33 Key ID: identifica a chave a ser utilizada (várias chaves são possíveis na configuração OSPF); 33 Tamanho: tamanho da mensagem criptográfica (digest). Esse tamanho não está incluso no tamanho informado anteriormente no campo Tamanho do Pacote; 33 Número de Sequência Criptográfico: utilizado para evitar ataques do tipo Replay, por isso fica sempre incrementando. 22 Além dessas modificações no formato dos campos Autenticação do cabeçalho, o cabeçalho é aumentado com mais um campo, de 16 bytes, onde a mensagem digest do MD5 é inserida. Caso a autenticação com MD5 seja utilizada, o cabeçalho OSPF passa de 24


Figura 1.2 Informações de Criptografia do cabeçalho OSPF para MD5. Os dois campos Autenticação viram novos campos.

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

bytes para 40 bytes. No final, o cabeçalho OSPF completo com autenticação MD5 teria a estrutura apresentada na figura 1.3. 3

8 bits

8 bits

Versão=2

Tipo

32 bits

8 bits

8 bits

Tamanho do Pacote Router ID Area ID

Checksum

Tipo de Autenticação

0x0000

Key ID

Tamanho

Número de Sequência Criptográﬁco

Digest MD5

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

Figura 1.3 Cabeçalho OSPF completo com Autenticação MD5.

q

11 IP de origem do pacote OSPF é sempre o IP da interface conectada à área, não o Router-ID; 11 IP de destino pode ser o endereço IP do roteador adjacente ou um dos grupos multicast 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: 11 Descobrir roteadores OSPF adjacentes. 11 Estabelecer adjacências com esses roteadores. 11 Manter as adjacências.

OSPF Avançado

11 Detectar falhas de enlaces e roteadores.

4

11 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em redes tipo Broadcast e NBMA. 11 Utiliza o grupo Multicast AllSPFRouters (224.0.0.5) em redes Broadcast e NBMA.

q

Relembrando: O OSPF pode funcionar em três tipos diferentes de rede: 11 Redes Ponto-a-Ponto: conecta um par de roteadores; 11 Redes Broadcast: suportam múltiplos roteadores e endereço IP que representam todos os roteadores da rede (endereço Broadcast); 11 Redes Non-Broadcast: suportam múltiplos roteadores, mas não suportam broadcast. No contexto do OSPF, podem ser operadas de duas maneiras: 22 Simulação de uma rede Broadcast na rede Non-Broadcast, denominada non-broadcast multi-access ou NBMA; 22 Tratando a rede como uma coleção de enlaces ponto-a-ponto, denominada redes Ponto-a-Multiponto.

Apesar de ser um tipo de pacote do OSPF, o Hello também é considerado um protocolo por si só. Esse protocolo possui as seguintes responsabilidades: 11 Descobrir roteadores OSPF adjacentes; 11 Estabelecer adjacências com esses roteadores; 11 Manter as adjacências; 11 Detectar falhas de enlaces e roteadores; 11 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em redes tipo Broadcast e NBMA. Esse é considerado o principal pacote OSPF, pois é a partir dele que todas as descobertas e adjacências são criadas, além de ser o responsável por detectar falhas de enlaces e roteadores. 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 anteriormente é simplificado, mostrando apenas o número que representa o tipo do pacote Hello, Capítulo 1 - Funcionamento do banco de dados do OSPF

que é o tipo “1”.

5

8 bits

8 bits

32 bits

8 bits

8 bits

Tipo=1

Cabeçalho OSPF

Máscara de sub-rede Intervalo Hello

Opções

Prioridade

Intervalo de Roteador Morto Designated Router Backup Designated Router Vizinhos Ativos

... Vizinhos Ativos Os campos estão detalhados a seguir: 11 Máscara de sub-rede: máscara de sub-rede da interface que está enviando o pacote Hello. Essa máscara deve ser a mesma em todas as interfaces dos roteadores conectados no mesmo segmento, por exemplo, na mesma VLAN ou no enlace serial; 11 Intervalo Hello: tempo em segundos entre o envio dos pacotes Hello. O valor tem de ser o mesmo nos roteadores conectados no mesmo segmento. Em caso de discrepâncias, a adjacência não será estabelecida; 11 Opções: existem cinco tipos de opções definidas na RFC 2328. Essas opções são utilizadas para estender as capacidades do roteador OSPF, além de informar outros roteadores dessas capacidades. As possibilidades são apresentadas a seguir: 22 E-bit: descreve como os LSA AS-External são anunciados na rede; 22 MC-bit : descreve se os datagramas IP multicast são enviados de acordo com a RFC 1584 (Multicast OSPF); 22 N/P bit: esse bit descreve como manipular os LSAs do Tipo 7; 22 EA bit: descreve o interesse do roteador para receber e encaminhar LSA External-Attributes; 22 DC bit: descreve se o roteador manipula circuitos sob demanda. 11 Prioridade: utilizado para a eleição do DR (Designated Router) e BDR (Backup Designated

OSPF Avançado

Router) em redes Broadcast e NBMA. Prioridade “0” significa que o roteador não é ele-

6

gível para virar DR ou BDR. O roteador com a maior prioridade é eleito o DR; 11 Intervalo de Roteador Morto (Dead Interval): intervalo em segundos para definir que o roteador adjacente está desconectado da rede e assim encerrar a 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.

11 Designated Router: endereço IP da interface do DR no segmento de rede (não o Router-ID). Caso não seja uma rede tipo Broadcast ou NBMA, esse campo é preenchido com 0.0.0.0; 11 Backup Designated Router: endereço IP da interface do BDR no segmento de rede (não o Router-ID). Caso não seja uma rede tipo Broadcast ou NBMA, esse campo é preenchido com 0.0.0.0; 11 Vizinhos Ativos: lista dos roteadores vizinhos do qual o roteador OSPF que está enviando o pacote recebeu pacotes Hello válidos. Em redes do tipo Broadcast e NBMA, são listados todos os roteadores OSPF que fazem parte do segmento. Em redes ponto-a-ponto, o endereç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, conforme citado anteriormente. Então, de posse das informações sobre os campos do pacote Hello, as principais atividades terão seu funcionamento detalhado a seguir.

Descobrir roteadores OSPF adjacentes e estabelecer adjacências 11 Protocolo Hello é utilizado para descobrir e estabelecer as adjacências.

q

11 As adjacências OSPF são iniciadas logo após um roteador OSPF detectar outro na rede. 11 A figura 1.5 será usada para exemplificar o estabelecimento das adjacências. No momento em que o roteador OSPF finaliza sua inicialização e habilita suas interfaces, o processo OSPF começa a enviar pacotes Hello por todas as interfaces que estão configuradas para fazerem parte do OSPF. Considere a topologia na figura a seguir.

R3

R4 10.1.1.0/24 s1/0

s0/0

11 Nesse exemplo, ambos os roteadores estão configurados na Área Backbone ou

q

Área 0.0.0.0; 11 Pacotes Hello são enviados; 11 Primeiro pacote não possui o campo “Vizinho Ativo” (Active Neighbor); 11 DR e BDR não são utilizados em enlaces seriais. Ambos os roteadores R3 e R4 estão conectados por um enlace serial, utilizando o endereçamento IP 10.1.1.0/24, onde R3 possui IP 10.1.1.1 e R4 possui IP 10.1.1.2. Suponha que o roteador R4 acabou de ser ligado e configurado, e suponha 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 estruturas 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.

7

Cabeçalho comum: 11 OSPF Version: 2; 11 Type: 1 (Pacote Hello); 11 Packet Length: 44 (24 bytes do cabeçalho OSPF mais 20 bytes do pacote Hello); 11 Source OSPF Router ou Router ID: 10.1.1.2 (IP da interface); 11 Area ID: 0.0.0.0, conhecida como Área Backbone; 11 Auth Type: null, ou seja, sem autenticação. Pacote Hello: 11 Network Mask: 255.255.255.0 (pois a rede é 10.1.1.0/24); 11 Hello Interval: (intervalo entre os Hellos): 10 segundos; 11 Router Priority: 1; 11 Router Dead Interval: 40 segundos; 11 Designated Router: 0.0.0.0 (enlace serial não tem DR); 11 Backup Designated Router: 0.0.0.0 (enlace serial não tem BDR). Podemos observar que o campo de Vizinhos Ativos não está presente, pois o roteador R4 ainda não conhece o roteador remoto.

R4 envia o primeiro pacote Hello:

q

Open Shortest Path First OSPF Header OSPF Version: 2 Message Type: Hello Packet (1) Packet Length: 44 Source 0SPF Router: 10.1.1.2 (10.1.1.2) Area ID: 0.0.0.0 (Backbone) Packet Checksum: 0xe19b [correct] Auth Type: Null Auth Data (none) OSPF Hello Packet Network Mask: 255.255.255.0 Hello Interval: 10 seconds Options: 0x12 (L, E) Router Priority: 1

Figura 1.6 Captura do primeiro pacote Hello enviado por R4.

Router Dead Interval: 40 seconds Designated Router: 0.0.0.0

OSPF Avançado

Backup Designated Router: 0.0.0.0

8

Após receber o pacote Hello vindo de R4 (10.1.1.2), o R3 envia um pacote Hello, conforme figura 1.7. 11 R3 envia seu primeiro pacote Hello, porém após receber o Hello do R4 (nesse exemplo); 11 Campo Vizinho Ativo ou Active Neighbor é preenchido a partir do Hello do roteador R4;

q

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 Figura 1.7 Captura do pacote Hello de R3 (Source OSPF Router: 10.1.1.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 Hello Interval: 10 seconds Options: 0x12 (L, E) Router Priority: 1 Figura 1.8 Captura do pacote Hello de R4 agora informando ter visto R3.

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 estabelecer a adjacência. Outros pontos que requerem atenção:


Network Mask: 255.255.255.0

9

11 Na figura 1.6, o Packet Length tinha 44 bytes, porém nas figura 1.7 e figura 1.8, tem 48 Bytes. Isso se deve ao fato de que o campo Active Neighbor estava presente com o endereço IP do vizinho nas figura 1.7 e figura 1.8 (lembre-se de que o endereço IPv4 possui 4 bytes de tamanho, ou 32 bits); 11 A adjacência só foi estabelecida devido aos roteadores possuírem as mesmas configurações de temporizadores (Hello Interval e Router Dead Interval) e área (0.0.0.0). 11 Observe os campos Packet Length: por que mudou?

q

11 Para evitar problemas ao criar adjacências no OSPF, garanta que os temporizadores, área ID e máscara de subrede estejam sempre de acordo em todos os roteadores OSPF.

Processo de eleição dos roteadores Designated Router e Backup Designated Router 11 Redes Broadcast e NBMA precisam ter um DR e um BDR por questões

q

de escalabilidade. 11 Roteadores da área somente vão sincronizar com o DR. 11 Três tipos de roteadores OSPF na área: 22 Designated Router (DR). 22 Backup Designated Router (BDR). 22 DR Others (DROther). 11 Grupo Multicast AllDRouters (224.0.0.6) criado para comunicação com o DR e o BDR. No cenário do exemplo anterior, por ser uma rede ponto-a-ponto, o processo de estabelecimento 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 roteadores 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 trocadas. Nesses casos, teremos três papéis: 11 Designated Router (DR); 11 Backup Designated Router (BDR); 11 DR Others (DROther). Apenas o DR tem o papel de sincronizar o banco de dados topológico com os demais. Agora, em caso de alterações na rede, os roteadores DROthers terão de notificar o DR e o BDR dessas alterações, e o DR atualizará o banco de dados dos demais roteadores da rede. Para

OSPF Avançado

que o DROthers possam notificar apenas o DR e o BDR, um novo grupo multicast foi criado,

10

chamado de AllDRouters (224.0.0.6). Apesar de apenas o DR ser responsável por encaminhar 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.

Para exemplificar o processo de escolha do DR e do BDR em uma rede Broadcast, vamos utilizar a topologia proposta na figura 1.9.

R2

R1

f0/0 f0/0

SW1 1

2

3

10.1.0.0/24

f0/0

Figura 1.9 Rede tipo Broadcast.

R3 Nessa topologia, o roteador R1 possui endereço IP 10.1.0.1, o roteador R2 possui endereço 10.1.0.2 e o roteador R3 possui endereço 10.1.0.3. O switch (sw1) na figura 1.9 atua sem configuraçã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,

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


os campos Designated Router e Backup Designated Router estão preenchidos com 0.0.0.0;

11

e. Após a escolha do R2 como BDR, o processo de escolha do DR é iniciado. Caso mais de um roteador tenha preenchido o próprio IP no campo Designated Router, aquele com a maior Router Priority será escolhido. Caso ambos tenham o mesmo valor de prioridade, aquele com o endereço IP mais alto será eleito o DR. Caso apenas um roteador tenha preenchido, esse será considerado o DR. Se nenhum roteador tiver preenchido o campo de Designated Router, o BDR é escolhido para ser o DR. Nesse caso, o R2 também será considerado o Designated Router desse segmento; f. Como o DR e o BDR não podem estar associados ao mesmo roteador, uma nova eleição para o BDR é estabelecida, seguindo os passos detalhados no passo D. Com isso, R1 será escolhido BDR do segmento; g. Após a escolha do novo BDR, o DR e o BDR ficarão com seus papéis até que o processo OSPF seja forçado pelo administrador a acontecer novamente ou em caso de queda de algum dos dois. Se o DR cair, o BDR assumirá o papel de DR e uma eleição para o BDR acontecerá. Caso o BDR caia, apenas uma eleição para BDR acontecerá; h. Caso o administrador da rede inicialize o roteador R3 agora, este vai observar nos pacotes Hello que o DR e o BDR já estão definidos, logo ele se caracterizará como DROther, estabelecendo adjacências com o DR e o BDR. 11 Roteadores, ao entrarem na rede, verificam se já há um DR e/ou um BDR:

q

22 Checam os campos Designated Router e Backup Designated Router do pacote Hello; 11 Caso positivo, aceitam a escolha; 11 No exemplo, não existem outros roteadores, então iniciam da forma normal; 11 Enviam pacotes Hello sem o campo Active Neighbors; 11 Campos Designated Router e Backup Designated Router preenchidos com 0.0.0.0; 11 Ao receber um pacote Hello, campo Active Neighbors passa a conter o IP do roteador remoto; 11 Processo de escolha do BDR é iniciado. Depende de quem tiver maior Router Priority. Desempate com o maior endereço IP; 22 Roteadores com Router Priority 0 não são elegíveis; 11 Após escolha do BDR, processo de escolha do DR é iniciado; 22 Mesmos critérios de desempate do processo do BDR; 11 DR e BDR não mudam mesmo que outro roteador tenha prioridade maior; 22 Evita instabilidade na rede; 11 BDR só assume no momento em que o DR fica inativo; 11 Outros roteadores que entrarem na rede serão os DROthers. O fato de que, após escolhidos, o DR e o BDR não mudam, mesmo com a entrada de outros roteadores com prioridade mais alta, serve para garantir a estabilidade da rede, uma vez que a

OSPF Avançado

cada eleição todo o processo de adjacência tem de ocorrer novamente, gerando instabilidade

12

no roteamento da rede. Observe na figura 1.10 o pacote Hello com o DR e o BDR definidos.

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 11 Após os roteadores OSPF tornarem-se adjacentes, os bancos de dados topológicos

q

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


Figura 1.10 R2 escolhido como DR, R1 como BDR.

13

Após os roteadores OSPF estabelecerem adjacências, estes precisam verificar se seus bancos de dados topológicos estão sincronizados. Para essa tarefa, o pacote OSPF Database Description – DD – (pacote OSPF tipo “2”) é utilizado. Durante o período chamado “Database Exchange Process”, um processo de eleição de Master/Slave acontecerá e, após eleito, o Master começará a enviar os cabeçalhos dos LSAs existentes no seu banco de dados topoló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 anteriormente, 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

32 bits

8 bits

8 bits

8 bits

Tipo=2

Cabeçalho OSPF

MTU

Opções

00000 I M Ms

Número de Sequência Cabeçalhos LSA 11 MTU: tamanho do Maximum Transmission Unit da interface OSPF a ser utilizada para sincronismo dos bancos de dados topológicos. Caso sejam diferentes entre os roteadores, o processo de sincronismo não vai ocorrer; 11 Options: mesmas opções definidas no pacote Hello; 11 Bit I (Initial): caso esteja marcado com “1”, indica que esse é o primeiro pacote DD da sequência de sincronismo; 11 Bit M (More): caso esteja marcado com “1”, indica que o pacote atual não é o último da sequência. “0” indica que é o último; 11 Bit MS (Master/Slave): se esse bit estiver marcado como “1”, significa que roteador originador é o Master na relação de sincronismo entre os dois roteadores. Se estiver marcado como “0”, esse roteador é o Slave do processo; 11 Número de Sequência: utilizado pelo Master para definir o sequenciamento dos pacotes DD;

OSPF Avançado

11 Cabeçalhos LSA: lista dos cabeçalhos de parte ou todos os LSAs contidos no banco de dados do originador do pacote. A partir desse campo, o recebedor do pacote poderá confirmar se possui todos os LSAs e, caso não tenha, solicitará tais LSAs faltantes no próximo processo. Para ilustrar, vamos utilizar a topologia apresentada na figura 1.9. Como as adjacências já foram criadas, o passo seguinte é o Database Exchange Process. Observe a figura 1.12, a figura 1.13 e a figura 1.14. 14

Figura 1.11 Pacote Database Description. Também usa o cabeçalho OSPF.

OSPF Header

OSPF Header OSPF version: 2

OSPF version: 2

Message Type: DB Description (2)


Packet Length: 32

Packet Length: 32

Source OSPF Router: 10.1.0.1 (10.1.0.1)


Area ID: 0.0.0.0 (Backbone)

Area ID: 0.0.0.0 (backbone)

Packet checksum: 0x8386 [correct]

Packet checksum: 0x7f27 [correct]

Auth Type: Null

Auth Type: Null

Auth Data (none)

Auth Data (none)

OSPF DB Description

OSPF DB Description

Interface MTU: 1500

Interface MTU: 1500

Options: 0x52 (O, L, E)


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

.... ...1 = MS: Master/Slave bit is SET

DD Sequence: 6258

DD Sequence: 7376

Figura 1.12 Database Exchange Process: eleição do Master.

Na figura 1.12 é possível observar que ambos os roteadores R1 (10.1.0.1) e R2 (10.1.0.2)

Figura 1.13 Database Exchange Process: início da troca de pacotes DD.

Na figura 1.13., o roteador R1 envia o pacote com o bit M/S configurado para “0”, indicando

enviam o pacote DD informando serem Masters do processo. Cada um envia seu próprio número de sequência (R1 envia 6258 e R2 envia 7376).

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

OSPF version: 2



Packet Length: 52

Packet Length: 32




Area ID: 0.0.0.0 (backbone)

Packet checksum: 0x7ffe [correct]

Packet checksum: 0x7f27 [correct]

Auth Type: Null

Auth Type: Null

Auth Data (none)

Auth Data (none)

OSPF DB Description

OSPF DB Description

Interface MTU: 1500

Interface MTU: 1500



DB Description: 0x02 (M)




.... .0.. = I: Init bit is NOT SET




.... ...0 = MS: Master/Slave bit is NOT SET DD Sequence: 7376 LSA Header

.... ...1 = MS: Master/Slave bit is SET DD Sequence: 7376


OSPF Header

15

Na figura 1.14, podemos observar que o R2 envia agora os cabeçalhos dos seus LSAs com um novo número de sequência (7377) e o R1 confirma recebimento enviando um pacote DD com o mesmo número de sequência. OSPF Header

OSPF Header

OSPF: version: 2

OSPF: version: 2



Packet Length: 32

Packet Length: 52





Packet checksum: 0x7f2e [correct]

Packet checksum: 0x8fe9 [correct]

Auth Type: Null

Auth Type: Null

Auth Data (none)

Auth Data (none)

OSPF DB Description

OSPF DB Description

Interface MTU: 1500

Interface MTU: 1500



DB Description: 0x00

DB Description: 0x03 (M, MS)



.... .0.. = I: Init bit is NOT set

.... .0.. = I: Init bit is NOT set

.... ..0. = More bit is NOT set


.... ...0 = MS: Master/Slave bit is NOT set DD Sequence: 7377

.... ...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 requisição será apresentado a seguir.

Link State Request ou LSR 11 Após o Database Exchange Process, os roteadores OSPF têm uma lista com LSAs que

q

precisam ser solicitados. 11 A solicitação dos LSAs acontece via pacote OSPF Link State Request ou LSR. 11 Pacote OSPF do Tipo 3. 11 Também faz uso do cabeçalho OSPF, assim como o Hello e o DD. 11 Adiciona apenas três campos novos, que podem ocorrer diversas vezes. Concluído o Database Exchange Process, o próximo passo para o sincronismo dos bancos de

OSPF Avançado

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

Figura 1.14 Database Exchange Process – R2 enviando seus LSAs.

8 bits

32 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

Figura 1.15 Pacote Link State Request.

Advertising Router n 11 Tipo do LSA: identifica o tipo do LSA (os tipos estão listados na tabela 1.1); 11 ID do LSA: varia de acordo com o tipo do LSA; 11 Advertising Router: o Router-ID do roteador que originou o LSA. Esses campos podem se repetir diversas vezes, para solicitar múltiplos LSAs no mesmo pacote. Assim como a comunicação no Database Exchange Process, a comunicação entre os roteadores OSPF ocorre utilizando endereçamento Unicast (redes Broadcast e NBMA) e Multicast (redes Ponto-a-Ponto). Na figura 1.16 é possível ver um pacote LSR sendo enviado do R2 para R1: OSPF Version: 2 Message Type: LS Request (3) Source OSPF Router: 10.1.0.2 (10.1.0.2) Area ID: 0.0.0.0 (Backbone) Packet Checksum: 0xdfd0 [correct]

Figura 1.16 Pacote LSR saindo de R2 para R1. Nesse caso, R2 está solicitando o LSA que tem os campos circulados na figura.

Auth Type: Null Auth Data (none) Link State Request Link-State Advertisement Type: Router-LSA (1) Link State ID: 10.1.0.1 Advertising Router: 10.1.0.1 (10.1.0.1)

Uma vez enviado o LSR solicitando os LSAs que precisam ser atualizados, o roteador remoto envia pacotes OSPF de Link State Update, que contém o LSA completo. A seguir será explicado o formato desse pacote.


Packet Length: 36

17

Link State Update ou LSU 11 Recebido o Link State Request, o roteador OSPF receptor verifica no seu banco de

q

dados e responde com um pacote Link State Update. 11 O Link State Update é o pacote OSPF Tipo “4”. 11 O pacote pode ser enviado por Unicast ou Multicast. 11 Também faz uso do cabeçalho OSPF. Recebida a solicitação do LSA via pacote LSR, o roteador OSPF enviará um pacote OSPF Link State Update, cujo tipo é o 4. Esse pacote utiliza o mesmo cabeçalho OSPF, e a resposta é feita via uma das possibilidades a seguir: 11 Um pacote LSU via Unicast para o solicitante; 11 Um pacote LSU via Multicast para o grupo AllSPFRouters. Apenas dois campos existem nesse pacote, conforme pode ser observado na figura 1.17.

8 bits

8 bits

32 bits

8 bits

8 bits

Tipo=4

Cabeçalho OSPF

Número de LSAs LSAs

11 Número de LSAs: informa a quantidade de LSAs que estão sendo enviados nesse pacote; 11 LSAs: nesse campo são enviados os LSAs requisitados pelo LSR. Na figura 1.18 é possível verificar um pacote LSU respondendo com um LSA completo. Porém, para garantir que o roteador remoto realmente recebeu o LSU, o roteador remoto precisa informar ao originador a confirmação de recebimento. Essa confirmação ocorre

OSPF Avançado

através do pacote OSPF Link State Acknowledgement ou LSAck.

18

Figura 1.17 Pacote Link State Update. Apenas dois campos adicionados.

OSPF Header OSPF Version: 2 Message Type: LS Update (4) Packet Length: 64 Source OSPF Router : 10.1. 0.1 (10.1. 0.1) Area ID: 0.0.0.0 (Backbone) Packet Checksum: 0xe898 [correct] Auth Type: Null Auth Data (none) LS Update Packet Figura 1.18 Resposta do R1 ao LSR de R2.

Number of LSAs: 1 LS Type: Router-LSA

Os tipos e o conteúdo dos LSAs serão apresentados no item "Link State Advertisement ou LSA".

Link State Acknowledgement ou LSAck

q

11 Depois de enviado o LSU, o roteador OSPF precisa da confirmação do roteador remoto que esse recebeu o pacote enviado. 11 A confirmação pode se dar de duas maneiras: 22 O receptor envia um pacote LSU com o mesmo conteúdo de volta para o originador. 22 O receptor gera um pacote Link State Acknowlegdement e envia para o originador. 11 Pacote Link State Acknowledgement ou LSAck possui o Tipo “5”. 11 Também utiliza o cabeçalho OSPF.

Como o LSU também ocorre em modo flooding: enviando as informações para todos os

roteadores OSPF do segmento de rede do qual faz parte: o LSAck é importante para garantir confiabilidade ao protocolo OSPF. Cada LSA recebido deve ser explicitamente confirmado pelo recebedor através do pacote LSAck. Essa confirmação ocorre quando o recebedor envia os cabeçalhos do LSA no pacote LSAck, podendo confirmar um ou diversos LSAs em uma

8 bits

8 bits

32 bits

Tipo=5

Cabeçalho OSPF

Figura 1.19 Pacote Link State Acknowledgement.

Cabeçalhos LSAs

8 bits

8 bits


única mensagem. O LSAck é o pacote de tipo número “5” do OSPF.

19

É importante salientar que a especificação do OSPF também permite que a confirmação se dê através do próprio LSU, onde o recebedor enviaria um LSU de volta com os mesmos dados. Em redes Broadcast ou NBMA, a confirmação pode ocorrer também via Unicast (diretamente para o originador) ou via Multicast. Na figura 1.20, podemos observar a confirmaçã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

Figura 1.20 LSAck do R2 para R1.

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. 11 Após todos os LSA serem trocados e confirmados, os roteadores entram no

q

estado FULL; 11 Nesse estado, o algoritmo SFP faz o cálculo das rotas para serem inseridas no roteador; 11 Só haverá novos LSU/LSAck em caso de alterações no estado de algum enlace: 22 Enlace inativo, queda de circuito, queda de roteador etc.; 11 Caso o LSA não seja atualizado por 30 minutos, o roteador deve anunciá-lo novamente para os roteadores da área: 22 Garantir que os bancos de dados estão sincronizados; 22 Esse tempo é chamado de LSRefreshTime e é fixo; 22 Nota: o anúncio é feito por LSA, e não de todo o banco de dados. Apesar do protocolo OSPF só enviar notificações de atualizações quando estas ocorrem (por exemplo, um enlace fica inativo), para garantir que todos os bancos de dados estão atualizados, toda vez que um LSA atingir o tempo aging de 30 minutos, uma atualização será enviada para o grupo Multicast AllSPFRouters, mesmo que no final o mesmo LSA permaneça no banco de dados OSPF. Esse tempo é fixo e chamado de LSRefreshTime na especificação do OSPF.

É importante salientar que o anúncio é feito por LSA, e não para todo o banco de dados.

OSPF Avançado

O OSPF não faz flooding da tabela de roteamento ou do banco de dados topológico.

20

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.

R1

R2 DOWN

DOWN HELLO (DR=0, Vizinhos=0) HELLO (DR=R2, Vizinhos=R1) ExStart

D-D (Seq =X, I, M, Master) D-D (Seq =Y, l, M, Master)

Exchange

INIT

ExStart

D-D (Seq =Y, M, Slave) D-D (Seq =Y+1, l, M, Master)

Exchange

D-D (Seq =Y+1, M, Slave) (...) D-D (Seq =Y+n, Master) Loading

D-D (Seq =Y+n, Slave) LS Request

Full

LS Update LS Request LS Update Full De maneira resumida, o processo de 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.

21

h. Ao receber o LSR vindo de R1, se o R2 não precisar de nenhum LSA do R1, o este entra no estado FULL direto. Se R2 precisar, um pacote LSR será enviado para R1 e entrará no estado LOADING. No exemplo, como o R2 não precisará de informações do R1, R2 já foi para o estado FULL, e enviará os pacotes LSU com os LSAs requisitados; i. Quando o R1 receber todos os LSU requisitados, fará a confirmação de recebimento com os LSAck e entrará no estado FULL também. A partir desse momento, o banco de dados OSPF estará completo e as rotas serão calculadas e inseridas na tabela de rotas do roteador. Caso um novo roteador entre na rede OSPF, este fará o processo acima com o DR apenas. Com os outros DROthers da rede, as adjacências serão criadas, porém os roteadores DROthers ficarão parados no estado ExStart (ou 2-Way para alguns fabricantes) entre eles, pois não há necessidade do sincronismo. Em redes não Broadcast e NBMA, onde não há DR e BDR, ambos os roteadores devem chegar até o estado FULL. 11 Em redes Broadcast e NBMA, esse processo ocorre entre o roteador OSPF

q

(DROther)e o DR; 22 Entre os DROthers, o maior estado é o ExStart; 11 Em redes Ponto-a-Ponto, ambos os roteadores têm de chegar ao estado FULL. Agora que o processo de sincronização do banco de dados topológico já está claro, será apresentada a estrutura de dados chamada Link State Advertisement, ou LSA, que são as estruturas que contêm as informações topológicas que populam o banco de dados do OSPF.

Link State Advertisement ou LSA 11 Link State Advertisement é a estrutura de dados responsável por armazenar as infor-

q

mações sobre os estados de enlaces; 22 Endereço IP, máscara de sub-rede, métrica etc.; 11 Pacotes OSPF DD e LSR usam apenas o cabeçalho; pacote LSU usa o LSA completo; 11 Através das informações no LSA é que o roteador faz os cálculos para definir as rotas; 11 Existem onze tipos, porém seis utilizados rotineiramente: router LSA, Network LSA, Network Summary LSA, ASBR Summary LSA, AS External LSA e NSSA External LSA. Link State Advertisement é a estrutura de dados responsável por armazenar as diversas informações usadas pelo processo OSPF sobre os estados de enlaces, como tipo de enlace, IP, máscara de subrede, métrica, origem etc. Foi apresentado anteriormente que, nos pacotes OSPF DD e LSR, apenas o cabeçalho do LSA é trocado, enquanto que no LSU o LSA completo é enviado. Como os LSAs são os responsáveis por todas as informações e métricas da rede OSPF, diversos tipos foram criados, com propósitos específicos. Na tabela 1.1, os onze tipos existentes 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

OSPF Avançado

LSA, Network Summary LSA, ASBR Summary LSA, AS External LSA e NSSA External LSA.

22

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, interfaces, 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.

8 bits

8 bits

32 bits

Age

8 bits

8 bits

Opções

Tipo

Advertising Router Figura 1.22 Cabeçalho LSA utilizado por todos os tipos de LSA.

Sequence Number Checksum

Tamanho

11 Age (Tempo de vida): tempo em segundos desde que o LSA foi gerado; 11 Opções: mesmas definições do campo de Opções do protocolo Hello; 11 Tipo: identifica o Tipo do LSA; 11 Link-State ID: conteúdo dependente do Tipo do LSA. Será detalhado à frente; 11 Advertising Router: router-ID do roteador que originou o LSA; 11 Sequence Number: utilizado como controle de versão do LSA;


Link-State ID

23

11 Checksum: utilizado para garantir integridade. Não inclui o campo Age; 11 Tamanho: tamanho do LSA em Bytes, incluindo o cabeçalho. A seguir, os principais tipos de LSA serão apresentados, e seus cabeçalhos serão detalhados, bem como seu modo de uso.

Router LSA 11 Router LSA é utilizado para informar os roteadores adjacentes com informações

q

como Router-ID, enlaces locais e métricas de saída. 11 Esse é o primeiro LSA enviado pelo roteador OSPF; 11 Contém todas as informações de todos os enlaces que o roteador possui; 11 Todas as informações de estado de enlace enviadas em apenas um LSA; 11 É o LSA Tipo “1”; 11 Todos os roteadores OSPF enviam LSAs do tipo Router LSA; 11 O Router LSA é mantido apenas dentro da área que faz parte. LSA tipo “1”, o Router LSA é utilizado para informar os roteadores adjacentes da área OSPF de informações como Router-ID, enlaces locais e métricas de saída. Esse é o primeiro LSA enviado pelo roteador e nele devem conter todas as informações de todos os enlaces que o roteador possui, em apenas uma mensagem. O formato do Router LSA é apresentado na figura 1.23. Os campos em azul pertencem ao cabeçalho LSA, detalhado na figura 1.22.

8 bits

32 bits

8 bits Age

8 bits

8 bits

Opções

Tipo = 1

Link-State ID Advertising Router Sequence Number Checksum 00000 V E B

Tamanho 0x00

Número de Links Link ID Link Data

Tipo de Link

Número TOS

Métrica

TOS

0x00

Métrica TOS

A seguir, os campos do Router LSA são apresentados:

OSPF Avançado

11 Bit V (Virtual): informa se o roteador é a ponta de um Virtual Link;

24

11 Bit E (External): indica que o roteador originador é um ASBR; 11 Bit B (Border): indica que o roteador originador é um ABR; 11 Número de Links: número de enlaces incluídos no LSA.

Figura 1.23 Router LSA.

Os campos a seguir são utilizados para descrever cada enlace do roteador. Cada enlace possui um tipo. 11 Link ID: identifica o objeto ao qual o enlace se conecta. Valor depende do campo Tipo de Link; 11 Link Data: conteúdo depende do Tipo de Link; 11 Tipo de Link: informa o tipo de enlace e define o conteúdo dos campos Link ID e Link Data. Os tipos estão informados na tabela 1.2; 11 Número TOS: não utilizado; 11 Métrica: custo do enlace; 11 TOS: não utilizado, mantido por compatibilidade com o OSPFv1; 11 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

11 A partir do Tipos de Link, o valor dos campos Link ID e Link Data podem mudar

q

A utilização dos campos da tabela 1.2 será apresentada na sessão de aprendizagem 2, “Áreas OSPF”, bem como exemplos.

Network LSA 11 LSA tipo “2”;

q

11 Network LSA é utilizado pelo Designated Router para informar aos demais roteadores OSPF da área sobre os roteadores com os quais o DR possui adjacências; 11 Essa informação é utilizada para saber quais roteadores estão na mesma sub-rede e calcular as rotas entre eles; 11 Apenas o DR de cada segmento faz uso desse tipo de LSA. LSA tipo “2”, o Network LSA é utilizado pelo Designated Router para informar aos demais roteadores OSPF da área sobre os roteadores com os quais o DR possui adjacências. A estrutura da Network LSA está apresentada na figura 1.24. É possível verificar que este é mais simples que o Router LSA.


Tabela 1.2 Router LSA: tipos de Link.

25

8 bits

8 bits

32 bits

Age

8 bits

8 bits

Opções

Tipo = 2

Link-State ID Advertising Router Sequence Number Checksum

Tamanho Máscara de Sub-rede Roteador Ativo Figura 1.24 Network LSA.

Roteador Ativo Os campos são preenchidos da seguinte maneira: 11 Link-State ID: endereço IP da interface do DR na área; 11 Máscara de Sub-rede: máscara de sub-rede da interface do DR conectada à área; 11 Roteador Ativo: router-ID dos roteadores com os quais o DR possui adjacência.

Network Summary LSA e ASBR Summary LSA 11 Network Summary LSA é o Tipo “3”.

q

11 ASBR Summary LSA é o Tipo “4”. 11 Ambos são utilizados apenas pelos ABR: Area Border Router: 22 Network Summary LSA é utilizado para enviar as rotas entre áreas. 22 ASBR Summary LSA é utilizado para informar o endereço IP dos roteadores ASBR: Autonomous System Boundary Routers. 11 O formato dos campos é o mesmo, porém o preenchimento varia nos seguintes campos: 22 Tipo. 22 Link-State ID. 22 Máscara de Sub-rede. 11 Também é utilizado para gerar a rota default dentro de uma área Stub. O formato do Network Summary LSA (ou Summary LSA) e do ASBR Summary LSA são idênticos. As únicas diferenças então no preenchimento dos campos Tipo, Link-State ID e Máscara de Sub-rede. O Network Summary LSA é utilizado para informar os roteadores de uma das áreas do ABR sobre as rotas das outras áreas do ABR. Por isso, quanto o roteador ABR quer enviar um Network Summary LSA, o campo Tipo é preenchido com valor “3”. O campo Link-State ID é preenchido com o prefixo IP da rede a ser anunciada, e o campo Máscara de sub-rede é preen OSPF Avançado

chido com a máscara do prefixo informado. Caso o ABR queira, é possível fazer agregação dos

26

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.

O ASBR Summary LSA é utilizado pelo ABR para informar sobre os roteadores ASBR existentes em outra área da qual o ABR faz parte. Quanto for enviar um ASBR Summary LSA, o ABR precisa preencher o campo Tipo com valor “4”, e, no campo Link-State ID, é preciso informar o Router-ID do ASBR (geralmente o 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.

8 bits

8 bits

32 bits

Age

8 bits

8 bits

Opções

Tipo = 3 ou 4


Tamanho Máscara de Sub-rede

Network ou ASBR Summary LSA.

0x00

Métrica

TOS

Métrica TOS

O campo Métrica é preenchido com o custo associado para se chegar ao endereço IP informado no campo Link-State ID. Os campos TOS e Métrica TOS não são utilizados.

AS External LSA 11 LSA Tipo “5”.

q

11 Utilizado para enviar rotas externas ao AS ou externas ao processo OSPF. 11 É enviado para todas as áreas, menos para as áreas Stub e NSSA. 11 AS External LSA não possuem relação com nenhuma área e por isso são transportados intactos entre áreas. 22 Daí a necessidade do ASBR Summary LSA (Tipo “4”) para ajudar os roteadores a localizarem o ASBR. 11 Possui dois tipos de rotas externas: 22 Tipo “1”: além do custo externo, adiciona o custo interno da rede para alcançar o ASBR. 22 Tipo “2”: somente tem o custo externo. Quando um ASBR precisa enviar rotas que são externas ao AS ou externas ao processo OSPF (redistribuição, por exemplo), o ASBR o faz enviando LSAs do tipo “5”, ou AS External LSA. Esse LSA é enviado para todas as áreas OSPF, com exceção das áreas Stub e NSSA. O formato do AS External LSA está apresentado na figura 1.26. O preenchimento dos campos é feito da seguinte maneira: 11 Link-State ID: prefixo IP da rota a ser anunciada; 11 Máscara de Sub-rede: máscara de sub-rede do prefixo IP a ser anunciado;


Figura 1.25

27

11 Bit E (External): é utilizado para marcar a rota com duas opções: e1 ou E2. Quando o bit E está configurado com “0”, a rota é dita E1 e possui como métrica o custo da rota externa recebida pelo ASBR, mais o custo interno para se chegar até o ASBR. Quando o bit E está configurado com “1”, a rota é dita E2 e possui como métrica apenas o custo externo. No caso da rota E2, o custo é maior que qualquer outro enlace interno. A configuração padrão é configurar a rota como E2. 11 Métrica: custo da rota; 11 Endereço de Encaminhamento: endereço IP do roteador responsável pelo prefixo. Se estiver configurado como “0.0.0.0”, significa que é para enviar para o próprio ASBR; 11 Tag da Rota Externa: campo extra, que pode ser utilizado pelas políticas de roteamento do AS. Não é utilizado pelo OSPF em si. Os campos TOS, Métrica TOS, Endereço de Encaminhamento TOS e Tag da Rota Externa TOS são campos de compatibilidade, e não são utilizados.

8 bits

8 bits

32 bits

Age

8 bits

8 bits

Opções

Tipo = 5



E 0000000

Métrica Endereço Endereçode deEncaminhamento Encaminhamento Tag da Rota Externa

E TOS

Métrica TOS Endereço de Encaminhamento TOS Figura 1.26 AS External LSA.

Tag da Rota Externa TOS

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

OSPF Avançado

11 Por padrão, o NSSA External LSA é traduzido para AS External LSA nos ABRs.

28

q

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.

8 bits

32 bits

8 bits Age

8 bits

8 bits

Opções

Tipo = 7



E 0000000

Métrica Endereço Endereçode deEncaminhamento Encaminhamento Tag da Rota Externa

E TOS

Métrica TOS Endereço de Encaminhamento TOS

Figura 1.27 NSSA External LSA.

Tag da Rota Externa TOS O campo Endereço de Encaminhamento pode assumir um dos seguintes valores: 11 Endereço IP do roteador na rede responsável pelo prefixo se a rede já for redistribuída como interna; por exemplo, redistribuição do protocolo RIP; 11 Router-ID do roteador ASBR caso seja uma rota externa ao AS.

Remoção de LSAs 11 A remoção de um LSA do LSDB pode ocorrer devido a dois fatores: 22 LSA aging atinge o MaxAge. 22 Acontece alguma alteração topológica na rede. 11 Alterações topológicas na rede incluem: 22 Enlace que muda de estado (de UP para DOWN ou DOWN para UP). 22 Roteador adicionado ou removido da rede. 11 Em caso de mudança de estado, duas ações podem fazer a remoção de um LSA do LSDB. 22 Expiração da adjacência detectada pelo protocolo Hello. 22 Envio de LSU com o LSA atualizado. 11 A Figura 1.28 mostra uma topologia onde a expiração via protocolo Hello aconteceria. 11 A figura 1.29 mostra uma topologia onde o envio de um LSU acontece.

q


A utilização dos seis LSAs apresentados até aqui será demonstrada na sessão 2.

29

Conforme mencionado anteriormente, uma vez no estado FULL, os roteadores OSPF não enviam novas atualizações de estado de enlace a menos que: 11 O aging do LSA atinje o LSRefreshTime (30 minutos); 11 Haja alguma alteração topológica na rede. Alterações topológicas na rede incluem: 11 Enlace que muda de estado (de UP para DOWN ou DOWN para UP); 11 Roteador adicionado ou removido da rede (seja por problemas no roteador ou intencional). Os casos que refletem adição de enlace ou roteador foram explicados anteriormente, porém, é importante detalhar como os prefixos são removidos do LSDB. A remoção de um LSA do LSDB acontece, na maioria dos casos, diante de dois cenários: 11 Expiração da adjacência detectada via protocolo Hello; 11 Envio de LSU com LSA atualizado informando a alteração. Vamos utilizar como exemplo a topologia da figura 1.28. Nessa rede Broadcast, todos os roteadores estão conectados a um switch Ethernet. Todos os três roteadores enviam, a cada intervalo definido no protocolo Hello (Interval), um pacote Hello para garantir que a adjacência está formada. Suponha agora que todas as adjacências estão formadas, porém, em algum momento futuro, o roteador R1 muda de estado para DOWN (por falta de energia, intervenção do administrador, problemas no equipamento etc.). Como eles estão interconectados via um switch Ethernet, as interfaces f0/0 dos roteadores R2 e R3 vão continuar UP, e após o Dead Interval do protocolo Hello, R2 e R3 vão ter as entradas LSA referentes ao roteador R1 removidas do LSDB. Essa remoção acontecerá devido à expiração da adjacência OSPF.

R2

R1

f0/0 f0/0

SW1 1

2

3

10.1.0.0/24

f0/0

R3 Observe agora topologia da figura 1.29. Nessa figura, temos dois momentos: momento

OSPF Avançado

A, onde a rede está funcional entre os roteadores R1, R2 e R3, com todos os roteadores

30

no estado FULL. Nesse estado, o roteamento acontece normalmente e os três roteadores possuem o mesmo LSDB. Assuma agora que algum tempo depois o enlace entre R1 e R2 mudou de estado, de UP para DOWN. Esse novo estado está representado pelo Momento B da figura 1.29.

Figura 1.28 Rede Broadcast.

F0/0

a.

.1

10.1.2.0/24 F0/0 .2

R1

.1

.2

R2

F0/0

b.

10.2.3.0/24 F0/0

.1

10.1.2.0/24 F0/0

F0/1

.2

R1

R3

10.2.3.0/24 F0/0

.1

R2

.2 LSU + LSA

R3

Após a queda do enlace entre R1 e R2, houve uma mudança no estado do enlace da interface f0/0 do roteador R2, e essa mudança precisa ser informada ao roteador R3. Essa mudança será informada através do pacote OSPF LSU (Link State Update), e um dos seguintes campos do LSA pode ser utilizado: 11 Age (ou Tempo de Vida): uma das constantes do OSPF é o MaxAge, que representa o valor de 1 hora (3.600 segundos). Qualquer LSA que atinja esse período no LSDB deve ser removido, pois subentende-se que não foi atualizado no tempo LSRefreshTime. Então, é possível um roteador OSPF informar outro roteador da remoção de um LSA simplesmente preenchendo o campo Age do cabeçalho do LSA com o valor MaxAge. Essa abordagem é utilizada principalmente pelo Network-LSA; 11 Métrica: uma outra constante que pode ser utilizada para informar que o LSA deve ser removido é a LSInfinity. Essa constante, utilizada como métrica máxima (infinita) do OSPF, é definida com os 24 bits todos configurados como 1 (0xffffff). Ou seja, caso o LSA tenha seu campo Métrica preenchido com o valor LSInfinity, o roteador OSPF recebedor de tal LSA deve removê-lo do LSDB. Essa abordagem é utilizada principalmente pelo Summary-LSA e pelo AS-External LSA.

Conclusão Nesta sessão, foram apresentados os cinco diferentes tipos de pacotes OSPF: Hello, Database Description, Link State Request, Link State Update e Link State Acknowledgement, e como eles são utilizados pelos roteadores OSPF para sincronizar os bancos de dados. Além disso, o LSA, seus seis principais tipos e seus papéis também foram apresentados. De posse dessas informações, será possível entender como o OSPF cria o conceito de hierarquia em áreas, e como e quais LSAs são filtrados e/ou encaminhados pelos ABRs para que a hierarquia e a escalabilidade da rede OSPF possa ser alcançada. Na próxima sessão, essa interação entre LSA, pacotes OSPF e as áreas será apresentada, permitindo ao aluno planejar, projetar e operar as mais diversas configurações de redes OSPF existentes.


Figura 1.29 Rede Broadcast com momentos A e B.

F0/1

31

Comandos OSPF A seguir, uma lista de comandos de configuração que têm relação com os temas abordados na sessão de aprendizagem 1, para serem utilizados no Quagga. Os comandos a seguir são aplicados por interface. 11 Altera o tempo em segundos entre pacotes Hello (padrão de 10 segundos): ip ospf hello-interval <1-65535>

11 Altera o tempo em segundos para considerar um vizinho como inativo (padrão de 40 segundos): ip ospf dead-interval <1-65535>: tempo para considerar o vizinho como inativo

11 Fast Hello: número de Hellos para enviar em um intervalo dead-interval de 1 segundo: ip ospf dead-interval minimal hello-multiplier <1-10>

11 Configura o tipo de rede OSPF: ip ospf network

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

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

11 Configura autenticação MD5: ip ospf authentication message-digest ip ospf message-digest-key <1-255> md5 SENHA

A seguir, uma lista dos comandos de observação que têm relação com os assuntos abordados na sessão de aprendizagem 1: 11 Exibe informações sobre o processo OSPF: show ip ospf

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

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

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

OSPF Avançado

11 Exibe as adjacências OSPF estabelecidas:

32

show ip ospf neighbor

2 Distinguir os tipos de áreas utilizadas pelo OSPF; Projetar e justificar quais tipos de área deseja utilizar; Entender o porquê de cada estado de cada banco de dados por área.

conceitos

Por que o OSPF faz uso do conceito de áreas?; Quais são os tipos de áreas e como elas se comportam em um ambiente OSPF; Área Backbone; Área Normal; Área Stub; Área Not-So-Stubby ou NSSA; Interconectando áreas com Virtual Links; Entendendo o LSDB; Observando o funcionamento do LSDB na Área Backbone.

Por que o OSPF faz uso do conceito de áreas? 11 LSDB precisa ser idêntico em todos os roteadores da rede.

q

11 Redes muito grandes possuem LSDB muito grandes. 22 Aumenta o consumo de memória e CPU. 22 Diminui o tempo de convergência da rede. 11 Redes com muitos enlaces que oscilam tendem a sofrer mais com LSDB muito grandes. O protocolo OSPF, por ser um protocolo de estado de enlace, requer a criação e manutenção de um banco de dados com a topologia completa da rede. Esse banco de dados, chamado de Link-State Data Base (LSDB) deve conter todos os enlaces de uma determinada rede, seus estados e suas métricas. A partir desse banco de dados, as rotas para todos os destinos são calculadas, otimizadas para usar o melhor caminho possível e garantir que não haverá loops de roteamento. 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 indisponibilidade, ou seja, ocorre uma mudança do estado do enlace, o roteador responsável por tal

Capítulo 2 - Entendendo as áreas do OSPF

objetivos

Entendendo as áreas do OSPF

33

enlace deve informar todos os outros roteadores que compartilham do mesmo LSDB. Cada roteador deverá fazer a confirmação (LSAck), executar o algoritmo SPF e calcular e instalar novas rotas. Ou seja, quanto maior a quantidade de roteadores e enlaces, maior o custo computacional para manter a rede operando adequadamente. 11 Especificação do OSPF permite o particionamento da rede: Áreas;

q

11 Áreas são utilizadas para criar redes OSPF menores; 11 Topologia da área é transparente para as demais áreas; 11 Com LSDB menor, menos recursos computacionais são necessários; 11 Cada área no ABR possui um LSDB separado; 11 Roteamento Intra-Area não necessita de informações externas. Diante dessa situação, a especificação do OSPF foi criada para permitir o particionamento da rede, criando zonas de roteamento menores. Essas zonas de roteamento – chamadas de áreas – permitem com que pedaços da rede sejam criados, gerando LSDBs menores que podem ser processados de maneira mais rápida, economizando recursos computacionais dos roteadores e diminuindo o tempo de convergência da rede. Essas áreas podem ser criadas para agrupar roteadores com papéis similares, por exemplo, roteadores de datacenter; roteadores conectados a serviços menos confiáveis, como enlaces seriais; ou mesmo para permitir que roteadores com menos recursos de CPU e memória possam fazer parte do roteamento dinâmico da rede. Para permitir que as áreas sejam alcançáveis dentro da rede, roteadores chamados de Area Border Routers (ABR) são conectados a duas ou mais áreas ao mesmo tempo, efetuando o roteamento entre estas. No roteador ABR, a quantidade de LSDBs vai depender da quantidade de áreas às quais o ABR se conecta: se estiver conectado a duas áreas OSPF, o ABR terá dois LSDB separados. Se estiver conectado a três áreas OSPF, o ABR terá três LSDB separados, 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 topologia externa é completamente transparente. O tráfego que é roteado dentro de uma área (intra-area) – endereço de origem e de destino estão inclusos no mesmo LSDB: não necessita de informação alguma externa àquela área. No tráfego em que o endereço de destino ou o de origem são de áreas diferentes, informações de roteamento vindas do ABR são necessárias. 11 Para fazer a interconexão entre áreas, o roteador ABR é utilizado:

q

22 LSAs Router e Network ficam confinados por área; 22 LSA Summary é gerado para permitir a alcançabilidade da rede. 11 LSA Externos continuam sendo encaminhados entre áreas (menos áreas Stub e NSSA).

OSPF Avançado

A transparência criada pelo ABR é feita através da filtragem dos Link State Advertisements:

34

em vez de encaminhar os LSAs Router e Network entre áreas, o ABR gera um sumário e envia um LSA Summary para a área remota, que assim passa a saber quais prefixos são alcançáveis dentro de cada área. Como no LSA Summary não há indicações de como os enlaces estão conectados, os roteadores externos não precisam gerar toda a árvore SFP por enlace. Logo, o processo SFP é simplificado.

Para fazer o particionamento de uma rede OSPF em áreas, é importante conhecer quais são as áreas suportadas, como elas funcionam e como se relacionam. Além disso, é fundamental saber quais são os LSAs utilizados por cada roteador de cada área e como eles são filtrados ou gerados nos ABRs.

Quais são os tipos de áreas e como elas se comportam em um ambiente OSPF 11 As RFCs 2328 e 3101 definem a criação das seguintes áreas OSPF:

q

22 Área Backbone. 22 Área Não Backbone. 33 Área "Normal". 33 Área Stub. 33 Área Not-So-Stubby. 22 Virtual-Links. A RFC 2328 possui as definições das principais áreas atualmente suportadas pelo OSPF. São elas: 11 Área 0 ou Backbone: área principal do OSPF, conecta todos os ABRs; 11 Área Não Backbone: área OSPF, que está conectada à Área Backbone. Para aumentar o controle, a flexibilidade e a escalabilidade do LSDB, as áreas não backbone podem ser divididas em: 11 Área Normal: área OSPF que se conecta à Área Backbone e suporta todos os tipos de LSAs; 11 Área Stub: área OSPF que se conecta à Área Backbone, porém não suporta LSAs Tipo 5 e Tipo 7. Além destas, a RFC 3101 adicionou uma nova Área Não Backbone às redes OSPF: a Not-So-Stubby-Area – ou NSSA. A NSSA funciona basicamente como uma área Stub que permite ASBR dentro da área. A Área Backbone não pode ser particionada, ou seja, deve ser contígua ao longo de toda a rede do Sistema Autônomo. Em casos onde ocorre esse particionamento, seja por roteador ou enlace indisponível, é necessário que essas duas partes da Área Backbone sejam reconectadas através de Virtual Links, que é um recurso criado justamente para reconectar áreas, sejam partições da mesma Área Backbone ou Áreas Não Backbone à Área Backbone.

uso das áreas OSPF.


A seguir cada área OSPF será detalhada. A figura 2.1, a seguir, será utilizada como caso de

35

R1 R3

Área Backbone

R6

Rede 1

R2

R5 Rede 3

Rede 2

R4

R7

Área 2

R8

Área 3

Área 4

Internet BGP R9

R10

Rede 4

Rede 5

Área Backbone 11 Conhecida como Área 0 ou Área 0.0.0.0. É o núcleo da rede.

R11

Rede 6

q

11 Responsável por interconectar todas as demais áreas. 11 Não pode ser particionada. 11 Deve possuir roteadores com memória e CPU suficientes para manipular vários LSDBs. A Área Backbone, também conhecida como Área 0 ou Área 0.0.0.0, é considerada a principal área OSPF, pois é a responsável por interconectar todas as demais áreas OSPF. Nessa área estão todos os roteadores ABR, ou seja, todas as áreas devem estar diretamente conectadas à Área Backbone. Por ser a área principal, essa área não pode ser particionada. Por isso, o engenheiro de redes responsável pela configuração da rede OSPF deve ter cuidado na definição da rede. Além disso, devido ao fato de ter todos os ABRs e todos os tipos de LSA, incluindo Summary e AS-Externo, a Área Backbone também deve possuir roteadores com memória e processamento suficiente para manipular o LSDB. Na figura 2.1, os roteadores R3, R4, R5, R6 e

OSPF Avançado

R7 fazem parte da Área Backbone. Desses, R3, R4 e R7 são roteadores ABR e R5 e R6 são

36

Roteadores Internos (Internal Routers). Observe na figura que no OSPF o roteador pode ter interfaces em diversas áreas.

Figura 2.1 Rede OSPF com Diversas Áreas.

Área Normal 11 Aceita LSAs Externos.

q

11 Não faz trânsito. 11 Roteadores com perfis similares. 11 Geralmente possui múltiplos roteadores ABRs. Apesar de suportar os principais LSAs (Router, Network, Summary, ASBR-Summary e AS-External), as Áreas Normais são diferentes da Área Backbone, pois não fazem trânsito ao longo da sua extensão (a menos que Virtual Links sejam utilizados). Normalmente, essas áreas possuem um conjunto de roteadores com perfis similares (por exemplo, roteadores de data center ou roteadores em uma mesma localidade) e podem possuir múltiplos roteadores ABR conectados à Área Backbone. Na figura 2.1, a Área 2 pode ser caracterizada como uma Área Normal, pois não provê trânsito para outras áreas OSPF, além de possuir dois ABRs. As Áreas 3 e 4 podem ser consideradas Áreas Normais mesmo tendo apenas um ABR. A especificação do OSPF apenas sugere mais de um ABR. Em casos com apenas um ABR, a sugestão é configurar Área Stub.

Área Stub 11 Área Stub

q

11 Usada quando 22 Roteadores com recursos computacionais limitados 22 Apenas um ABR por área 11 Opção de LSA-Summary gerado pelo ABR com a rota padrão 11 LSA Externos são descartados (AS External LSA e NSSA-LSA) As Áreas Stubs são muito utilizadas em cenários onde os roteadores que fazem parte da área não possuem recursos computacionais suficientes para manter toda a topologia, ou em casos onde existe um único ABR conectando a Área Backbone. Por exemplo, observe a figura 2.1. É possível observar que a Área 3 e a Área 4 possuem mais de um roteador OSPF por área, porém apenas um roteador ABR. Nesse caso, não faria sentido que os roteadores R8, R9, R10 e R11 tivessem informações sobre a topologia da Área 2 ou da Área Backbone, por exemplo, pois todo acesso às outras gurar os roteadores como fazendo parte de uma área Stub, e o ABR de cada área gerar uma rota padrão (default route) que seria enviada para os demais roteadores da área. Nesse caso, R8 e R9 receberiam uma rota padrão vinda do roteador R4 e os roteadores R10 e R11 receberiam uma rota padrão vinda do roteador R7. Nos LSDB de R8, R9, R10 e R11 constaria apenas as rotas da própria área (Router-LSA e Network-LSA) mais a rota padrão gerada (Summary-LSA). Uma vez configurado o processo OSPF como parte de uma Área Stub, os LSAs Tipo 5 (AS External LSA) passam a ser descartados pelos roteadores ABR.


redes se dá via o único ABR da área. Neste caso, o procedimento recomendado seria confi-

37

Área Not-So-Stubby ou NSSA Nas redes OSPF em geral, o LSDB possui mais LSAs do Tipo 5 (AS External LSA) do que os demais tipos. Isso se deve, principalmente, ao uso de redistribuição nos roteadores, seja redistribuição das rotas estáticas, das rotas de outro IGP (RIP, IS-IS, etc.) ou mesmo de interfaces diretamente conectadas no processo OSPF. Então, pode acontecer de um roteador que está em uma área Stub precisar redistribuir informações de estado de enlace que devem ser propagadas para todos os roteadores da rede. Conforme explicado anteriormente, os roteadores configurados em uma área Stub descartam os LSAs AS-External-LSA. Logo, utilizando como exemplo a rede da figura 2.1 e assumindo-se que a Área 3 está configurada como um Área Stub, se o roteador R8 necessitar redistribuir algum prefixo recebido do processo BGP, esse prefixo seria filtrado no roteador R4 por ser um prefixo externo ao processo OSPF. No âmbito do OSPF, a palavra redistribuição refere-se à inserção de estado de enlaces que estão fora do processo OSPF no processo OSPF. Por exemplo: redistribuir um prefixo IP do processo de roteamento do RIP no processo de roteamento do OSPF. Ou, redistribuir uma rota estática no processo OSPF. Sempre que há redistribuição é utilizado o LSA AS-External-LSA, que é filtrado nas áreas Stub. Para evitar ter que migrar a Área 3 de Stub para Normal apenas porque um roteador precisa fazer redistribuição, a RFC 3101 criou um novo tipo de área, chamada Not-So-Stubby-Area ou NSSA. Basicamente, a NSSA é uma área Stub que permite que prefixos externos sejam inseridos na área e encaminhados pelo ABR para a Área Backbone. Dentro da Área NSSA, o prefixo é divulgado para os outros roteadores utilizando o LSA External-NSSA. Ao chegar no ABR, este converte de External-NSSA (Tipo 7) para um AS-External LSA (Tipo 5) e encaminha para os demais roteadores da Área Backbone. 11 Área Not-So-Stubby

q

22 Criada na RFC 3101 22 Comportamente similar a Área Stub porém permite redistribuição 22 Prefixos externos são redistribuídos com LSA External-NSSA 22 ABR converte de External-NSSA para AS External LSA

Interconectando áreas com Virtual Links 11 Evitar o particionamento da Área Backbone.

q

11 Utilizado para reconectar área que desconectou da Área Backbone via outra Área. 11 OSPF trata o Virtual Link como uma rede ponto-a-ponto unnumbered. 11 Funcionalidade de uso temporário. 11 Não suportado via Áreas Stub. Virtual Link é um recurso criado na RFC 2328 para garantir que a mudança de estado de OSPF Avançado

enlaces não segregue alguma área, principalmente a Área Backbone, e gere problemas de

38

roteamento, ou seja, o objetivo do Virtual Link é conectar dois ABRs via uma área que não seja a Área Backbone. Com o Virtual Link, o OSPF trata os dois roteadores como se estivessem conectados a uma rede ponto-a-ponto unnumbered (ou seja, sem endereçamento IP nas pontas).

Como exemplo, observe novamente a figura 2.1. Nela, o roteador R4 faz parte da Área Backbone através do enlace entre R4 e R5. Caso esse enlace mude de estado (de UP para DOWN), R4 ficaria desconectado e a Área Backbone seria particionada, o que não pode acontecer. Mesmo R4 tendo conexão via Rede 3 com R3, os LSAs com os prefixos da Área 3 não seriam encaminhados para a Área Backbone ou para a Área 2 por R3, pois não foram recebidos pela

l NVirtual Links não podem ser criados via Área Stub.

interface que faz parte da Área Backbone. Ou seja, a Área 3 ficaria desconectada da rede mesmo que R4 tivesse um enlace de backup via Rede 3. Nesse caso, a solução é criar um Virtual Link entre R3 e R4 via Área 2. Esse Virtual Link seria tratado como uma extensão da Área Backbone, desfazendo o particionamento criado pela mudança de estado do enlace entre R4 e R5. A nova topologia ficaria igual à figura 2.2.

R3

Rede 3

Área Bac

VL R4

Área 2

R8

Área 3

É importante ressaltar que o Virtual Link é uma funcionalidade que deve ser utilizada para remediar um problema temporário, e não ser uma solução definitiva. A principal função das áreas no OSPF é permitir que a topologia interna das áreas seja transparente para as demais áreas. Isso é resolvido pelo roteador ABR, que filtra os LSAs Router e Network, gerando LSAs do tipo Summary. Então, mesmo que o LSA Router não seja recebido por roteadores OSPF de outras áreas, estes ainda receberão o LSA Summary para cada prefixo existente na área. Isso garante que a rede seja alcançável. Porém, se o Administrador da Rede quiser reduzir a quantidade de prefixos IP na tabela de rotas, é recomendável que os prefixos IP utilizados em uma área sejam agregáveis, ou seja, parte de um mesmo prefixo maior.


Figura 2.2 Virtual Link entre R4 e R3.

39

Dessa maneira, o ABR poderia sumarizar as rotas internas de uma Área e enviar apenas um LSA Summary com um prefixo agregado. Isso economizaria recursos de memória e aumenta a estabilidade da rede, pois caso um enlace oscile, os roteadores externos à área não precisam processar o LSDB novamente.

Entendendo o LSDB De posse das informações sobre o tipos de Link State Advertisements vistos na sessão de aprendizagem 1 com as informações sobre as áreas OSPF da sessão 2, nesta sessão vamos estudar como funciona o banco de dados do OSPF, o Link State Data Base, quando múltiplas áreas são utilizadas. Conhecer o LSDB é extremamente importante para entender se as configurações estão corretas e para resolução de problemas. Para guiar nosso estudo, a figura 2.3 será utilizada. Essa topologia está configurada no arquivo adr9-cap2-entendendo-lsdb.imn.

R2

R5

Área Backbone

Área 2 Normal R1

Área 3 NSSA

5.5.5.5/32

R4 10.2.4.0/24

10.1.2.0/24

1.1.1.1/32 10.1.3.0/24

R3

10.3.4.0/24

10.4.5.0/24

10.5.7.0/24

R6

10.4.6.0/24

Área 4 Stub

6.6.6.6/32

A seguir, detalhes da topologia: 11 Existem seis roteadores OSPF (R1 até R6) e um roteador não OSPF (R7); 11 As conexões entre roteadores são feitas por enlaces Ethernet; 11 O prefixo IP entre dois roteadores seguirá a lógica 10.X.Y.0/24, onde X representa o número do menor roteador e Y o número do maior roteador. Por exemplo, entre R2 e R4, a rede será 10.2.4.0/24; 11 O último octeto será sempre o número do roteador. Por exemplo, em R2, no enlace que conecta com R4, o endereço da interface será 10.2.4.2/24. Em R4 será 10.2.4.4/24; 11 Todos os roteadores terão a interface loopback (lo) configurada com o prefixo IP, onde todos os octetos representam o número do roteador. Por exemplo, roteador R6 será 6.6.6.6/32; 11 Quando a interface Loopack estiver representada em uma nuvem dentro do retângulo que representa a área, a interface Loopback fará parte do processo OSPF;

OSPF Avançado

11 Quando a interface Loopback estiver representada em uma nuvem fora do retângulo que

40

representa a área, a interface Loopback será redistribuída no processo OSPF; 11 As Loopbacks dos roteadores R2, R3, R4 e R7 não estão representadas, mas serão configuradas seguindo a mesma ideia do item E. R2, R3 e R4 terão suas Loopbacks na Área Backbone; 11 Em R5 há uma rota estática apontando para a Loopback de R7;

R7

Figura 2.3 Rede OSPF Multi-Área.

11 Em R7 há uma rota padrão apontando para a interface de R5; 11 As conexões entre R1 e R3 e R3 e R4 terão custo alterado para 64; 11 As interfaces entre R1 e R3, além de R3 e R4, serão configuradas para funcionar no modo OSPF Ponto-a-Ponto.

A: Observando o funcionamento do LSDB na Área Backbone A1: Router-LSA e Network-LSA 11 Roteadores R2, R3 e R4 compõem a Área Backbone.

q

11 LSDB visto a partir de R4: R4# show ip ospf database OSPF Router with ID (4.4.4.4) Router Link States (Area

0.0.0.0)

Link ID ADV Router Age Seq# CkSum Link count 2.2.2.2 2.2.2.2 412

0x80000006 0x8b60 2

3.3.3.3 3.3.3.3 13

0x80000010 0xd118 3

4.4.4.4 4.4.4.4 7

0x80000010 0x6e1d 4

Net Link States (Area

0.0.0.0)

Link ID ADV Router Age Seq# CkSum 10.2.4.4 4.4.4.4 412

0x80000001 0x27f6

11 É possível observar a quantidade de enlaces (links) por roteador, além de um LSA Network. A composição mais simples do LSDB ocorre quando existe apenas uma área, a Área Backbone (também conhecida como Area 0.0.0.0). Na figura 2.3, a Área Backbone é composta pelos roteadores R2, R3 e R4. Entre R3 e R4 o enlace está configurado como Ponto-a-Ponto. Observe a estrutura do LSDB a partir do R4 (Router-ID 4.4.4.4) listando apenas os registros da Área 0 e LSAs Router e Network: R4# show ip ospf database OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) 2.2.2.2 2.2.2.2 412

0x80000006 0x8b60 2

3.3.3.3 3.3.3.3 13

0x80000010 0xd118 3

4.4.4.4 4.4.4.4 7

0x80000010 0x6e1d 4

Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 10.2.4.4 4.4.4.4 412 0x80000001 0x27f6

É possível observar que o LSDB possui três LSAs do Tipo 1 (Router LSA) e um LSA do Tipo 2 (Network-LSA). Conforme apresentado na sessão de aprendizagem 1, o Router-LSA é utilizado por todos os roteadores OSPF para informar os estados dos seus enlaces, ou seja, prefixo IP, máscara, métrica, tempo de vida, status etc. A coluna ADV Router informa qual foi o roteador que gerou aquele LSA. No Router-LSA, a coluna Link ID sempre informa o Router ID do roteador OSPF. É possível ver o tempo de vida (Age), número de sequência (Seq), checksum e quantidade de enlaces por Router LSA. Como o LSDB é o mesmo em todos os roteadores da área, essa saída é a mesma nos roteadores R2 e R3.


Link ID ADV Router Age Seq# CkSum Link count

41

Observe agora o Router-LSA gerado pelo roteador R2, primeiro Router-LSA da saída anterior (Advertising Router: 2.2.2.2) na Área Backbone: R4# show ip ospf database router 2.2.2.2 Router Link States (Area 0.0.0.0) LS age: 1119 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x1 : ABR LS Type: router-LSA Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000006 Checksum: 0x8b60 Length: 48 Number of Links: 2 Link connected to: a Transit Network (Link ID) Designated Router address: 10.2.4.4 (Link Data) Router Interface address: 10.2.4.2 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: 2.2.2.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10

Detalhamento do Router-LSA gerado pelo Roteador R2: R4# show ip ospf database router 2.2.2.2 Router Link States (Area 0.0.0.0) LS age: 1119 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x1 : ABR LS Type: router-LSA Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000006 Checksum: 0x8b60 Length: 48 Number of Links: 2 Link connected to: a Transit Network (Link ID) Designated Router address: 10.2.4.4

OSPF Avançado

(Link Data) Router Interface address: 10.2.4.2 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: 2.2.2.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10

42

q

Alguns campos foram destacados em negrito e itálico, pois são as informações mais importantes. Primeiro campo que requer atenção é o campo “Flags”. Nele o bit E está configurado como 1, o que significa que esse LSA foi gerado por um roteador OSPF em uma área que suporta AS External LSA. Em uma área Stub, esse bit estaria configurado como 0. No campo das Flags, é possível ver que o roteador R2 se apresenta como um roteador ABR, pois este está conectado à Área Backbone e à Área 2. As informações de estado de enlace estão apresentadas logo após o campo “Length”, e é possível ver duas entradas: 11 Transit Network: indica que essa enlace é de uma rede de trânsito, ou seja, enlace que possui um Designated Router. Nesse caso, o campo “Link ID” é preenchido com o endereço IP do DR e o campo “Link Data” é preenchido com o IP do roteador que originou o LSA. Observe que os endereços IP utilizados são os endereços das interfaces, não o Router-ID (a tabela 1.1 da sessão de aprendizagem 1 explica como funciona o preenchimento dos campos “Link ID” e “Link Data”); 11 Stub Network: uma vez que o endereço IP configurado na interface Loopback é utilizado como destino ou origem do tráfego (e não trânsito), o enlace da Loopback é anunciado como uma rede Stub (não confunda com Área Stub). A última informação de cada enlace é a métrica para chegar neste, que no caso está apresentado como 10 (enlace FastEthernet é utilizado entre R2 e R4). Observe agora o Router LSA gerado pelo roteador R4 (Advertising Router: 4.4.4.4): R4# show ip ospf database router 4.4.4.4 Router Link States (Area 0.0.0.0) LS age: 250 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x3 Flags: 0x3 : ABR ASBR LS Type: router-LSA Link State ID: 4.4.4.4 Advertising Router: 4.4.4.4 LS Seq Number: 80000011 Checksum: 0x6c1e Length: 60 Number of Links: 4 Link connected to: a Transit Network (Link Data) Router Interface address: 10.2.4.4 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 3.3.3.3 (Link Data) Router Interface address: 10.3.4.4 Number of TOS metrics: 0 TOS 0 Metric: 64 Link connected to: Stub Network (Link ID) Net: 10.3.4.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0


(Link ID) Designated Router address: 10.2.4.4

43

TOS 0 Metric: 64 Link connected to: Stub Network (Link ID) Net: 4.4.4.4 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10

Detalhamento do Router-LSA gerado pelo Roteador R4: R4# show ip ospf database router 4.4.4.4 Router Link States (Area 0.0.0.0) LS age: 250 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x3 Flags: 0x3 : ABR ASBR LS Type: router-LSA Link State ID: 4.4.4.4 Advertising Router: 4.4.4.4 LS Seq Number: 80000011 Checksum: 0x6c1e Length: 60 Number of Links: 4 Link connected to: a Transit Network (Link ID) Designated Router address: 10.2.4.4 (Link Data) Router Interface address: 10.2.4.4 Number of TOS metrics: 0 TOS 0 Metric: 10

Continuação: Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 3.3.3.3 (Link Data) Router Interface address: 10.3.4.4 Number of TOS metrics: 0 TOS 0 Metric: 64 Link connected to: Stub Network (Link ID) Net: 10.3.4.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metric: 64 Link connected to: Stub Network (Link ID) Net: 4.4.4.4 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 OSPF Avançado

TOS 0 Metric: 10

44

q

É possível observar que R4, além de ser um roteador ABR, é também um roteador ASBR, devido ao fato de estar conectado à área NSSA (todo roteador de borda de uma área NSSA é considerado um ASBR). Além disso, o Router-LSA mostra que R4 possui quatro registros de estado de enlace configurados na rede OSPF: um registro que faz parte de uma rede de trânsito, um que faz parte de uma rede ponto-a-ponto e dois registros de redes Stub: 11 Transit Network: essa rede de trânsito é a mesma descrita no Router-LSA anterior, só que agora vista a partir do roteador R4 e preenchida da mesma maneira: no campo “Link ID” está o endereço IP do roteador DR (o próprio R4), e no campo “Link Data” o endereço IP do roteador que originou o LSA (nesse caso, próprio R4). Observe pelo endereçamento IP (10.2.4.4) que esse LSA se refere ao enlace entre os roteadores R2 e R4 11 another Router (point-to-point): esse LSA se refere ao enlace entre R3 e R4 (observe o endereçamento para confirmar: 10.3.4.4). Como a especificação da topologia dizia que o tipo de rede OSPF entre R3 e R4 seria Ponto-a-Ponto e redes ponto-a-ponto não fazem eleição de DR, não temos um LSA de Transit Network entre R3 e R4, e sim um LSA de Ponto-a-Ponto. Nesse caso, o Link Data é preenchido com o endereço IP no enlace do roteador originador, e o campo “Link ID” é preenchido com o Router ID do roteador vizinho. Como na especificação também dizia que o custo OSPF da interface seria alterado para 64 (especificação K), é possível ver que o LSA possui métrica 64; 11 Stub Network com Link ID 10.3.4.0: toda vez que uma rede ponto-a-ponto for anunciada pelo processo OSPF, além da entrada Tipo do Link 1 acima, outra entrada de Tipo do Link 3 deve ser criada. Nesse caso, a rede ponto-a-ponto também é considerada do tipo Stub e deve ser preenchida da seguinte maneira: o campo “Link ID” deve possuir o prefixo IP do enlace e o campo “Link Data” deve possuir a máscara de sub-rede. Observe que a métrica é a mesma: 64, que foi configurada manualmente na interface; 11 Stub Network com Link ID 4.4.4.4: essa entrada apresenta informações sobre a interface Loopback do roteador R4. Uma vez que o endereço IP configurado na interface Loopback é utilizado como destino ou origem do tráfego (e não trânsito), o enlace da Loopback é anunciado como uma rede Stub. A seguir, para finalizar o detalhamento dos Router-LSAs da Área Backbone (Area 0.0.0.0), observe o Router-LSA gerado pelo roteador R3: R4# show ip ospf database router 3.3.3.3 Router Link States (Area 0.0.0.0) LS age: 222 Options: 0x2 : *|-|-|-|-|-|E|* Flags: 0x1 : ABR LS Type: router-LSA Link State ID: 3.3.3.3 Advertising Router: 3.3.3.3 LS Seq Number: 80000017 Checksum: 0xfd3c Length: 60 Number of Links: 3


LS Flags: 0x6

45

Link connected to: Stub Network (Link ID) Net: 3.3.3.3 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 4.4.4.4 (Link Data) Router Interface address: 10.3.4.3 Number of TOS metrics: 0 TOS 0 Metric: 64 Link connected to: Stub Network (Link ID) Net: 10.3.4.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metric: 64

Detalhamento do Router-LSA gerado pelo Roteador R3: R4# show ip ospf database router 3.3.3.3 Router Link States (Area 0.0.0.0) LS age: 222 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x1 : ABR LS Type: router-LSA Link State ID: 3.3.3.3 Advertising Router: 3.3.3.3 LS Seq Number: 80000017 Checksum: 0xfd3c Length: 60 Number of Links: 3 Link connected to: Stub Network (Link ID) Net: 3.3.3.3 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 4.4.4.4 (Link Data) Router Interface address: 10.3.4.3 Number of TOS metrics: 0 TOS 0 Metric: 64 Link connected to: Stub Network (Link ID) Net: 10.3.4.0

OSPF Avançado

(Link Data) Network Mask: 255.255.255.0

46

Number of TOS metrics: 0 TOS 0 Metric: 64

q

É possível verificar que o roteador R3 possui três registros com informações de estado de enlace: dois registros para redes Stub e um registro para uma rede ponto-a-ponto. Assim como nos detalhamentos anteriores, a interface Loopback (3.3.3.3/255.255.255.255) está anunciada como uma rede Stub. O enlace entre os roteadores R3 e R4 foi manualmente configurado com o tipo de rede Ponto-a-Ponto. Logo se apresenta como tal (point-to-point), informando o Router-ID do roteador vizinho no campo “Link ID”. Por consequência, o prefixo IP usado nesse enlace ponto-a-ponto é anunciado como uma rede Stub (10.3.4.0/255.255.255.0). Observe as métricas de 64 nas duas últimas entradas: lembre-se de que o custo da interface foi manualmente configurado como 64. Apresentados os LSAs do Tipo 1 da Área Backbone, vamos apresentar o LSA do Tipo 2, ou Network LSA. Observe novamente a saída do Roteador R4 com LSAs do Tipo 1 e 2 da Área Backbone: R4# show ip ospf database OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 2.2.2.2 2.2.2.2 412 0x80000006 0x8b60 2 3.3.3.3 3.3.3.3 13 0x80000010 0xd118 3 4.4.4.4 4.4.4.4 7 0x80000010 0x6e1d 4 Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 10.2.4.4 4.4.4.4 412 0x80000001 0x27f6

Apesar de o roteador R4 ter adjacências com R2 e R3, é possível ver que há apenas um Network LSA na Área Backbone, que se refere ao enlace entre R2 e R4 (observe o endereçamento IP no campo “Link ID”). Vamos analisar esse LSA: R4# show ip ospf database network OSPF Router with ID (4.4.4.4) Net Link States (Area 0.0.0.0) LS age: 79 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x3 LS Type: network-LSA Link State ID: 10.2.4.4 (address of Designated Router) LS Seq Number: 80000001 Checksum: 0x27f6 Length: 32 Network Mask: /24 Attached Router: 2.2.2.2 Attached Router: 4.4.4.4


Advertising Router: 4.4.4.4

47

Detalhamento do Network-LSA gerado pelo Roteador R4:

q

R4# show ip ospf database network OSPF Router with ID (4.4.4.4) Net Link States (Area 0.0.0.0) LS age: 79 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x3 LS Type: network-LSA Link State ID: 10.2.4.4 (address of Designated Router) Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0x27f6 Length: 32 Network Mask: /24 Attached Router: 2.2.2.2 Attached Router: 4.4.4.4

É possível observar que esse LSA foi gerado pelo roteador R4 (o campo “Advertising Router” informa que originou o LSA), uma vez que ele é o Designated Router desse enlace. Apenas o DR gera LSAs do Tipo 2. Nele é possível ver qual é a máscara da rede (/24) e quais são os roteadores que fazem parte dessa rede (R2 e R4). Neste momento você pode estar se perguntando: "Se R3 não está na lista de Attached Router nem tem um LSA do Tipo 2 que o inclua, o que aconteceu com R3"? Lembre-se de que o enlace entre R3 e R4 foi manualmente definido como um enlace ponto-a-ponto (ip ospf network point-to-point), logo, não há eleição de DR nesse tipo de rede. 11 Observe que o LSDB da Área Backbone não possui nenhum Network-LSA que inclua o

q

roteador R3, e R3 não está na lista de Attached Router; 11 Isso acontece porque R3 tem seus enlaces configurados como Ponto-a-Ponto, logo não há DR ou BDR; 11 Lembre-se: apenas o DR gera LSAs do tipo Network. Nesse ponto, já temos melhor compreensão dos LSAs do Tipo 1 e do Tipo 2. Como ambos os tipos são restritos por área, é possível compreender que cada área possuirá um LSDB que inclua esses LSAs. 11 Pudemos observar que o tipo de rede OSPF Broadcast gera dois registros: um LSA Router (Transit) e um LSA Network. No tipo de rede OSPF Ponto-a-Ponto, dois registros também são criados, porém ambos do tipo LSA Router (Point-to-Point e Stub). Uma vez que já foram apresentados ambos LSAs na sessão 1 e nas descrições anteriores, fica como atividade para o aluno detalhar os Router-LSAs ou os Network-LSAs das Áreas 2, 3 e 4.

OSPF Avançado

A.2: Summary-LSA

48

Como cada área possui um LSDB próprio, é fundamental que os ABRs informem os demais roteadores OSPF sobre os prefixos ali contidos. Nesse caso, os ABRs vão gerar LSAs do Tipo 3, ou Summary-LSAs que incluem os prefixos internos da área, ou seja, a partir dos LSA do Tipo 1, LSAs do Tipo 3 serão gerados para as outras áreas OSPF. Observe os LSDBs existentes no roteador R3 (LSAs Tipo 4 e 5 foram removidos):

R3# show ip ospf database OSPF Router with ID (3.3.3.3) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 2.2.2.2 2.2.2.2 1561 0x80000006 0x8b60 2 3.3.3.3 3.3.3.3 1560 0x80000006 0xb329 3 4.4.4.4 4.4.4.4 1401 0x80000009 0x3653 3 Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 10.2.4.4 4.4.4.4 1561 0x80000001 0x27f6 Summary Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Route 1.1.1.1 2.2.2.2 282 0x80000002 0xc774 1.1.1.1/32 1.1.1.1 3.3.3.3 620 0x80000002 0xc73a 1.1.1.1/32 6.6.6.6 4.4.4.4 1014 0x80000001 0xa67a 6.6.6.6/32 10.1.2.0 2.2.2.2 1601 0x80000001 0xee4f 10.1.2.0/24 10.1.2.0 3.3.3.3 1580 0x80000001 0x53a6 10.1.2.0/24 10.1.3.0 2.2.2.2 1557 0x80000001 0x6696 10.1.3.0/24 10.1.3.0 3.3.3.3 1600 0x80000001 0xe31f 10.1.3.0/24 10.4.5.0 4.4.4.4 329 0x80000001 0x6dc2 10.4.5.0/24 10.4.6.0 4.4.4.4 641 0x80000002 0x60cd 10.4.6.0/24 Router Link States (Area 0.0.0.2) Link ID ADV Router Age Seq# CkSum Link count 1.1.1.1 1.1.1.1 1561 0x80000007 0xac8c 4 2.2.2.2 2.2.2.2 1562 0x80000004 0xf91e 1 3.3.3.3 3.3.3.3 1590 0x80000003 0x4244 2 Net Link States (Area 0.0.0.2) Link ID ADV Router Age Seq# CkSum 10.1.2.2 2.2.2.2 1562 0x80000001 0x1324 Summary Link States (Area 0.0.0.2) Link ID ADV Router Age Seq# CkSum Route 2.2.2.2 2.2.2.2 1601 0x80000001 0x370c 2.2.2.2/32 2.2.2.2 3.3.3.3 270 0x80000002 0xdf4a 2.2.2.2/32 3.3.3.3 2.2.2.2 1552 0x80000001 0xd159 3.3.3.3/32 3.3.3.3 3.3.3.3 1600 0x80000001 0xea50 3.3.3.3/32 4.4.4.4 2.2.2.2 1402 0x80000001 0x3ff1 4.4.4.4/32 6.6.6.6 2.2.2.2 1015 0x80000001 0x47d7 6.6.6.6/32 6.6.6.6 3.3.3.3 1013 0x80000001 0x29f1 6.6.6.6/32 10.2.4.0 2.2.2.2 1601 0x80000001 0xcc6e 10.2.4.0/24 10.2.4.0 3.3.3.3 1550 0x80000001 0x131a 10.2.4.0/24 10.3.4.0 2.2.2.2 1552 0x80000001 0x250b 10.3.4.0/24 10.3.4.0 3.3.3.3 1600 0x80000001 0xa293 10.3.4.0/24 10.4.5.0 2.2.2.2 329 0x80000001 0x0e20 10.4.5.0/24 10.4.5.0 3.3.3.3 327 0x80000001 0xef3a 10.4.5.0/24 10.4.6.0 2.2.2.2 1552 0x80000001 0x032a 10.4.6.0/24 10.4.6.0 3.3.3.3 1550 0x80000001 0xe444 10.4.6.0/24


4.4.4.4 3.3.3.3 1400 0x80000001 0x210c 4.4.4.4/32

49

Observe que o ABR R3 possui um LSDB por área e cada área possui seus LSAs do tipo

q

Summary: R3# sh ip ospf database summary Summary Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Route 1.1.1.1 2.2.2.2 282 0x80000002 0xc774 1.1.1.1/32 1.1.1.1 3.3.3.3 620 0x80000002 0xc73a 1.1.1.1/32 6.6.6.6 4.4.4.4 1014 0x80000001 0xa67a 6.6.6.6/32 10.1.2.0 2.2.2.2 1601 0x80000001 0xee4f 10.1.2.0/24 10.1.2.0 3.3.3.3 1580 0x80000001 0x53a6 10.1.2.0/24 10.1.3.0 2.2.2.2 1557 0x80000001 0x6696 10.1.3.0/24 10.1.3.0 3.3.3.3 1600 0x80000001 0xe31f 10.1.3.0/24 10.4.5.0 4.4.4.4 329 0x80000001 0x6dc2 10.4.5.0/24 10.4.6.0 4.4.4.4 641 0x80000002 0x60cd 10.4.6.0/24 LSAs do Tipo Summary da Área 2: R3# sh ip ospf database summary Summary Link States (Area 0.0.0.2) Link ID ADV Router Age Seq# CkSum Route 2.2.2.2 2.2.2.2 1601 0x80000001 0x370c 2.2.2.2/32 2.2.2.2 3.3.3.3 270 0x80000002 0xdf4a 2.2.2.2/32 3.3.3.3 2.2.2.2 1552 0x80000001 0xd159 3.3.3.3/32 3.3.3.3 3.3.3.3 1600 0x80000001 0xea50 3.3.3.3/32 4.4.4.4 2.2.2.2 1402 0x80000001 0x3ff1 4.4.4.4/32 4.4.4.4 3.3.3.3 1400 0x80000001 0x210c 4.4.4.4/32 6.6.6.6 2.2.2.2 1015 0x80000001 0x47d7 6.6.6.6/32 6.6.6.6 3.3.3.3 1013 0x80000001 0x29f1 6.6.6.6/32 10.2.4.0 2.2.2.2 1601 0x80000001 0xcc6e 10.2.4.0/24 10.2.4.0 3.3.3.3 1550 0x80000001 0x131a 10.2.4.0/24 10.3.4.0 2.2.2.2 1552 0x80000001 0x250b 10.3.4.0/24 10.3.4.0 3.3.3.3 1600 0x80000001 0xa293 10.3.4.0/24 10.4.5.0 2.2.2.2 329 0x80000001 0x0e20 10.4.5.0/24 10.4.5.0 3.3.3.3 327 0x80000001 0xef3a 10.4.5.0/24 10.4.6.0 2.2.2.2 1552 0x80000001 0x032a 10.4.6.0/24 10.4.6.0 3.3.3.3 1550 0x80000001 0xe444 10.4.6.0/24

É possível observar que os prefixos IP que fazem parte do processo OSPF de cada área são inseridos como Summary-LSAs no LSDB das outras áreas. Por exemplo: 11 Na Área Backbone (Area 0.0.0.0), é possível observar os prefixos 1.1.1.1 (Loopback de R1, que faz parte da Área 2) e 6.6.6.6 (Loopback de R6, que faz parte da Área 4). Esses prefixos foram inseridos na Área Backbone pelos roteadores listados na coluna ADV Router; 11 Na Área 0.0.0.2, é possível observar o prefixo 6.6.6.6 como sendo anunciado pelos roteadores ABR da área. Nesse caso, os roteadores R2 e R3. Observe que os endereços

OSPF Avançado

Loopback de R2 e R3 também foram inseridos como Summary-LSAs na Área 2, devido ao fato de que eles estão configurados para operar na Área Backbone (conforme apresentado nas descrições sobre Router-LSA). Os Summary-LSAs criados pelos roteadores R2 e R3 a partir dos Router-LSAs da Área 2 são enviados para os demais roteadores da Área Backbone. Ao receber esses Summary-LSAs, o roteador ABR R4 deverá executar uma das duas ações: 11 Enviar para os roteadores de outras áreas (R5 e R6); 50

11 Não enviar para os roteadores de outras áreas. A opção por enviar ou não depende das configurações de cada área. Se o administrador da rede optar por não enviar os Summary-LSAs para os roteadores internos de cada área (seja por questão de engenharia de tráfego, economia de recursos dos roteadores ou devido ao fato de que há apenas um roteador ABR na área), essa configuração deverá ser feita no ABR, e nesse caso, uma rota padrão deverá ser gerada por esse ABR. 11 Em casos onde uma Área OSPF possui apenas um roteador ABR, por exemplo, as

q

Áreas 3 e 6, o Engenheiro de Redes pode optar por enviar ou não os LSAs do tipo Summary recebidos de outros ABRs; 11 Como exemplo, observe o LSDB de R6 para cada caso: em um caso R4 envia os LSAs do tipo Summary, em outro não. Observe em R6 o LSDB nos dois casos. Primeiramente, sem filtragem alguma dos Summary-LSAs em R4 (comando OSPF area 4 stub em R4): R6# show ip ospf database OSPF Router with ID (6.6.6.6) Router Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum Link count 4.4.4.4 4.4.4.4 7 0x80000013 0x3aac 1 6.6.6.6 6.6.6.6 6 0x8000000a 0x5755 2 Net Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum 10.4.6.6 6.6.6.6 6 0x80000004 0x6995 Summary Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum Route 1.1.1.1 4.4.4.4 3600 0x80000001 0x101d 1.1.1.1/32 2.2.2.2 4.4.4.4 3600 0x80000001 0x7db5 2.2.2.2/32 3.3.3.3 4.4.4.4 3600 0x80000001 0x4fdf 3.3.3.3/32 4.4.4.4 4.4.4.4 3600 0x80000001 0xbc78 4.4.4.4/32 10.1.2.0 4.4.4.4 3600 0x80000001 0x35f8 10.1.2.0/24 10.1.3.0 4.4.4.4 3600 0x80000001 0x48ae 10.1.3.0/24 10.2.4.0 4.4.4.4 3600 0x80000001 0xae86 10.2.4.0/24 10.3.4.0 4.4.4.4 3600 0x80000001 0xa291 10.3.4.0/24 10.4.5.0 4.4.4.4 3600 0x80000001 0x8ba6 10.4.5.0/24

R6# show ip ospf database OSPF Router with ID (6.6.6.6) Summary Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum Route 1.1.1.1 4.4.4.4 3600 0x80000001 0x101d 1.1.1.1/32 2.2.2.2 4.4.4.4 3600 0x80000001 0x7db5 2.2.2.2/32 3.3.3.3 4.4.4.4 3600 0x80000001 0x4fdf 3.3.3.3/32 4.4.4.4 4.4.4.4 3600 0x80000001 0xbc78 4.4.4.4/32 10.1.2.0 4.4.4.4 3600 0x80000001 0x35f8 10.1.2.0/24 10.1.3.0 4.4.4.4 3600 0x80000001 0x48ae 10.1.3.0/24 10.2.4.0 4.4.4.4 3600 0x80000001 0xae86 10.2.4.0/24 10.3.4.0 4.4.4.4 3600 0x80000001 0xa291 10.3.4.0/24

q Capítulo 2 - Entendendo as áreas do OSPF

Roteador R4 configurado para criar a Área 4 como Stub:

10.4.5.0 4.4.4.4 3600 0x80000001 0x8ba6 10.4.5.0/24

51

Agora, observe o LSDB de R6 com a filtragem de LSAs do Tipo 3 aplicada em R4 (comando OSPF area 4 stub no-summary em R4): R6# show ip ospf database OSPF Router with ID (6.6.6.6) Router Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum Link count 4.4.4.4 4.4.4.4 1063 0x80000007 0x52a0 1 6.6.6.6 6.6.6.6 532 0x80000006 0x5f51 2 Net Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum 10.4.6.6 6.6.6.6 242 0x80000002 0x6d93 Summary Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum Route 0.0.0.0 4.4.4.4 253 0x80000002 0x1934 0.0.0.0/0

Roteador R4 configurado para criar a Área 4 como Stub com o parâmetro no-summary:

q

router ospf area 4 stub no-summary R6# show ip ospf database OSPF Router with ID (6.6.6.6) Summary Link States (Area 0.0.0.4 [Stub]) Link ID ADV Router Age Seq# CkSum Route 0.0.0.0 4.4.4.4 253 0x80000002 0x1934 0.0.0.0/0

11 Com o parâmetro no-summary, o ABR gera uma rota padrão para a Área 4; 11 Como há apenas um ABR na Área 4, não haverá chance de os roteadores internos terem roteamento sub-otimizado.

O Quagga 0.99 utilizado durante a escrita deste material mantém os registros do LSDB por algum tempo após o fim das adjacências e trocas de configuração, como essa informada. É necessário aguardar que os registros do LSBD expirem para serem removidos. As rotas são removidas normalmente.

Enquanto que no primeiro exemplo R6 possui informações sobre todos os prefixos da rede, no segundo havia apenas um Summary-LSA gerado por R4, contendo a rota padrão. A seguir está o Summary-LSA com a rota padrão: R6# sh ip ospf database summary OSPF Router with ID (6.6.6.6) Summary Link States (Area 0.0.0.4 [Stub]) LS age: 831 Options: 0x0 : *|-|-|-|-|-|-|* OSPF Avançado

LS Flags: 0x6

52

LS Type: summary-LSA Link State ID: 0.0.0.0 (summary Network Number) Advertising Router: 4.4.4.4 LS Seq Number: 80000002

Checksum: 0x1934 Length: 28 Network Mask: /0 TOS: 0 Metric: 1

A seguir o LSA Summary com a rota padrão:

q

R6# sh ip ospf database summary OSPF Router with ID (6.6.6.6) Summary Link States (Area 0.0.0.4 [Stub]) LS age: 831 Options: 0x0 : *|-|-|-|-|-|-|* LS Flags: 0x6 LS Type: summary-LSA Link State ID: 0.0.0.0 (summary Network Number) Advertising Router: 4.4.4.4 LS Seq Number: 80000002 Checksum: 0x1934 Length: 28 Network Mask: /0 TOS: 0 Metric: 1

É possível observar que esse LSA é do Tipo 3, Summary-LSA, que o Link State ID é preenchido com o valor 0.0.0.0 e o campo “Network Mask” está preenchido com /0 (0.0.0.0). Nesse caso, 0.0.0.0/0 indica a rota padrão a ser utilizada. Observe que em ambos os casos as redes externas à área serão alcançáveis. Porém, ao usarmos a opção de envio de rota padrão, o LSDB do R6 possui menos registros para serem gerenciados.

A.3: AS External LSA Na topologia da figura 2.3, foi definido que o roteador R5 faria redistribuição de dois prefixos na Área 3: a sua loopback (5.5.5.5) e a rota estática que aponta para a loopback do roteador R7 (7.7.7.7). Essas interfaces estão sendo redistribuídas no processo OSPF para demonstrar uma rota externa ao processo OSPF. Dentro da Área 3, que é uma área NSSA, é utilizado o LSA Tipo 7. Porém, uma vez que esse LSA chega ao ABR da rede, esse é convertido para o LSA pelos ABRs para as outras áreas (menos Stub e NSSA). Observe o LSDB do roteador R1: R1# sh ip ospf database external OSPF Router with ID (1.1.1.1) AS External Link States LS age: 324 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 5.5.5.5 (External Network Number)


do Tipo 5, AS-External-LSA, e enviado para todos os roteadores OSPF da Área Backbone e

53

Advertising Router: 4.4.4.4 LS Seq Number: 80000008 Checksum: 0x6417 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 10.4.5.5 External Route Tag: 0 LS age: 330 mnbv Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 7.7.7.7 (External Network Number) Advertising Router: 4.4.4.4 LS Seq Number: 8000000a Checksum: 0x046d Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 10.4.5.5 External Route Tag: 0

11 Roteador R5 faz redistribuição de uma rota estática (7.7.7.7/32) e da sua interface

q

Loopack (5.5.5.5/32); 11 Rotas redistribuídas são anunciadas com LSAs do tipo AS-External ou NSSA, dependendo da Área; 11 Área 3 é uma Área NSSA, logo os prefixos 7.7.7.7/32 e 5.5.5.5/32 são anunciados com LSA NSSA External; 11 ABR da Área 3 converte para LSA AS-External e envia para a Área Backbone; 11 Como LSAs do tipo AS-External se mantêm inalterados pela Rede OSPF, R1 os enxerga da maneira que é criado pelo R4/ABR da Área 3. É possível constatar que ambos os prefixos redistribuídos constam no LSDB do roteador R1, e ambos como LSAs do Tipo 5 (AS-External-LSA). É possível ver que o roteador que originou o LSA foi o roteador R4 (4.4.4.4) e ambos possuem o endereço IP 10.4.5.5 como endereço de encaminhamento (Forward Address). Além disso, observe que ambos os prefixos foram redistribuídos como métrica do tipo E2 (Metric Type: 2) e possuem custo de 20. OSPF Avançado

É importante observar que R4 consta no campo “Advertising Router” por ter sido o res-

54

ponsável pela tradução do LSA do Tipo 7 para o LSA do Tipo 5. O verdadeiro originador do prefixo é o roteador R5, porém, esse está em uma área NSSA.

11 LSA AS-External em R1;

q

11 Prefixo 5.5.5.5/32. R1# sh ip ospf database external OSPF Router with ID (1.1.1.1) AS External Link States LS age: 324 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 5.5.5.5 (External Network Number) Advertising Router: 4.4.4.4 LS Seq Number: 80000008 Checksum: 0x6417 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 10.4.5.5 External Route Tag: 0

11 LSA AS-External em R1; 11 Prefixo 7.7.7.7/32. LS age: 330 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 7.7.7.7 (External Network Number) Advertising Router: 4.4.4.4 LS Seq Number: 8000000a Checksum: 0x046d Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Forward Address: 10.4.5.5 External Route Tag: 0

Observe que o roteador que criou o LSA foi o R4 (Advertising Router: 4.4.4.4). Apenas como exemplo, vamos alterar a configuração do roteador R1 e remover sua Loopback do processo OSPF (comando: no network 1.1.1.1/32 area 2) e redistribuí-la no OSPF (comando: redistribute connected). Observe como ficaria o LSA do ponto de vista do roteador R4: R4# sh ip ospf database external OSPF Router with ID (4.4.4.4) AS External Link States LS age: 18


Metric: 20

Options: 0x2 : *|-|-|-|-|-|E|*

55

LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 1.1.1.1 (External Network Number) Advertising Router: 1.1.1.1 LS Seq Number: 80000001 Checksum: 0x5f57 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0

Observe como o LSA AS-External é criado em uma Área não NSSA:

q

R4# sh ip ospf database external OSPF Router with ID (4.4.4.4) AS External Link States LS age: 18 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 1.1.1.1 (External Network Number) Advertising Router: 1.1.1.1 LS Seq Number: 80000001 Checksum: 0x5f57 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0

Observe o comportamento padrão do ASBR ao criar LSAs do tipo AS-External: o campo ”Forward Address” foi preenchido com IP 0.0.0.0, diferente dos LSA do tipo NSSA-External. Como é possível verificar, tanto o prefixo (Link State ID) quanto o originador (Advertising Router) estão preenchidos com o endereço do Router-ID de R1 (1.1.1.1). Como os roteadores ABR não fazem alteração em LSA do Tipo 5, o LSA é mantido intacto ao longo da rede OSPF. Lembre-se de que quando o Forward Address estiver preenchido com 0.0.0.0, os pacotes devem ser enviados ao IP do Advertising Router.

OSPF Avançado

Observe que o AS-External-LSA não é associado a área alguma; logo, não tem

56

nenhuma informação de área, tipo (Area 0.0.0.0). Por isso, não deve ser manipulado pelos ABRs.

A.4: ASBR Summary LSA Já que os roteadores OSPF devem preservar os AS-External-LSAs intactos e estes são gerados por roteadores ASBR, é necessário ter um mecanismo que permita que os demais roteadores OSPF saibam como chegar no ASBR. Com esse propósito, foi criado o ASBR-Summary-LSA, conforme apresentado na sessão de aprendizagem 1, que indica como chegar ao ASBR. Como no AS-External-LSA visto por R1 consta R4 como Advertising Router, R1 precisa saber como chegar em R4. Para isso, R1 deve verificar se possui algum ASBR-Summary-LSA com o endereço de R4. Observe a saída a seguir: R1# sh ip ospf database asbr-summary OSPF Router with ID (1.1.1.1) ASBR-Summary Link States (Area 0.0.0.2) LS age: 770 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: summary-LSA Link State ID: 4.4.4.4 (AS Boundary Router address) Advertising Router: 2.2.2.2 LS Seq Number: 80000008 Checksum: 0xbe74 Length: 28 Network Mask: /32 TOS: 0 Metric: 10 LS age: 1130 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: summary-LSA Link State ID: 4.4.4.4 (AS Boundary Router address) Advertising Router: 3.3.3.3 LS Seq Number: 80000007 Checksum: 0xa28d Length: 28 Network Mask: /32 TOS: 0 Metric: 10

Como R4 gerou LSAs do tipo AS-External, um LSA do tipo ASBR-Summary precisa ser

q

R1# sh ip ospf database asbr-summary OSPF Router with ID (1.1.1.1) ASBR-Summary Link States (Area 0.0.0.2) LS age: 770 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: summary-LSA Link State ID: 4.4.4.4 (AS Boundary Router address) Advertising Router: 2.2.2.2


criado. Observe como R1 aprende o caminho para 4.4.4.4 via R2 (2.2.2.2).

57

LS Seq Number: 80000008

q

Checksum: 0xbe74 Length: 28 Network Mask: /32 TOS: 0 Metric: 10

Observe como R1 aprende o caminho para 4.4.4.4 via R3 (3.3.3.3): LS age: 1130 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: summary-LSA Link State ID: 4.4.4.4 (AS Boundary Router address) Advertising Router: 3.3.3.3 LS Seq Number: 80000007 Checksum: 0xa28d Length: 28 Network Mask: /32 TOS: 0 Metric: 10

Como os ASBR Summary LSAs são gerados pelos roteadores ABR, através do campo Advertising Router, R1 consegue ver quais são os roteadores ABR da Área da qual faz parte (Área 0.0.0.2) que devem ser utilizados para encaminhar os pacotes. Nesse caso, como a Área 0.0.0.2 possui dois ABRs (R2 e R3), cada um gera um ASBR Summary LSA. No caso do nosso exemplo que altera a Loopback de R1, observe como R4 se informa sobre como chegar a R1: R4# sh ip ospf database asbr-summary OSPF Router with ID (4.4.4.4) ASBR-Summary Link States (Area 0.0.0.0) LS age: 749 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: summary-LSA Link State ID: 1.1.1.1 (AS Boundary Router address) Advertising Router: 2.2.2.2 LS Seq Number: 80000001 Checksum: 0x57ee Length: 28 Network Mask: /32 TOS: 0 Metric: 10 LS age: 749 Options: 0x2 : *|-|-|-|-|-|E|*

OSPF Avançado

LS Flags: 0x6

58

LS Type: summary-LSA Link State ID: 1.1.1.1 (AS Boundary Router address) Advertising Router: 3.3.3.3 LS Seq Number: 80000001

Checksum: 0x57b4 Length: 28 Network Mask: /32 TOS: 0 Metric: 64

Novamente, como R1 está em uma área com dois roteadores ABR na Área 2, duas entradas são observadas no LSDB de R4: uma via R2, outra via R3.

A.5: NSSA-LSA O último LSA existente na rede OSPF da figura 2.3 é o NSSA-External-LSA. Como existem apenas dois roteadores OSPF na Área NSSA, utilize a saída a seguir para verificar os LSAs do Tipo 7 existentes no LSDB do roteador R4: R4# sh ip ospf database nssa-external OSPF Router with ID (4.4.4.4) NSSA-external Link States (Area 0.0.0.3 [NSSA]) LS age: 125 Options: 0xa : *|-|-|-|N/P|-|E|* LS Flags: 0x6 LS Type: NSSA-LSA Link State ID: 5.5.5.5 (External Network Number for NSSA) Advertising Router: 5.5.5.5 LS Seq Number: 80000001 Checksum: 0xbfb4 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 NSSA: Forward Address: 10.4.5.5 External Route Tag: 0 LS age: 2 Options: 0xa : *|-|-|-|N/P|-|E|* LS Flags: 0x6 LS Type: NSSA-LSA Link State ID: 7.7.7.7 (External Network Number for NSSA) Advertising Router: 5.5.5.5 Checksum: 0x5f0b Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 NSSA: Forward Address: 10.4.5.5 External Route Tag: 0


LS Seq Number: 80000003

59

Como R5 fez redistribuição na Área 3, que é uma Área NSSA, os prefixos redistribuídos

q

são com LSAs do tipo NSSA-External. Observe o LSDB do ABR da Área 3, com LSAs do tipo NSSA-External: R4# sh ip ospf database nssa-external OSPF Router with ID (4.4.4.4) NSSA-external Link States (Area 0.0.0.3 [NSSA]) LS age: 125 Options: 0xa : *|-|-|-|N/P|-|E|* LS Flags: 0x6 LS Type: NSSA-LSA

q

Link State ID: 5.5.5.5 (External Network Number for NSSA) Advertising Router: 5.5.5.5 LS Seq Number: 80000001 Checksum: 0xbfb4 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 NSSA: Forward Address: 10.4.5.5 External Route Tag: 0 LS age: 2 Options: 0xa : *|-|-|-|N/P|-|E|* LS Flags: 0x6 LS Type: NSSA-LSA Link State ID: 7.7.7.7 (External Network Number for NSSA) Advertising Router: 5.5.5.5 LS Seq Number: 80000003 Checksum: 0x5f0b Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 NSSA: Forward Address: 10.4.5.5 External Route Tag: 0

Observe o comportamento padrão do ASBR em Áreas NSSA: o campo “Forward Address” foi preenchido com o IP da interface OSPF, diferente dos LSA do tipo AS-External. O formato do pacote é idêntico ao AS-External-LSA, mudando apenas o preenchimento dos campos “LS Type”, de Tipo 5 para Tipo 7, e o Forward Address. Nos roteadores externos à área NSSA, após a tradução de Tipo 7 para LSA do Tipo 5, para que a rota seja instalada, o

OSPF Avançado

roteador remoto precisa fazer uso do ASBR-Summary-LSA, que é gerado pelo ABR.

60

Apesar de permitir a redistribuição de prefixos externos ao processo OSPF, as áreas NSSA têm as características das áreas Stub; logo, não há encaminhamento de AS-External-LSAs. Além disso, caso o Engenheiro de Rede responsável deseje, podemos controlar o envio de Summary LSAs, injetando apenas a rota padrão na área.

A.6: Virtual Links Como apresentado anteriormente, Virtual Links devem ser utilizados para conectar partes desconexas da mesma área. Vamos ilustrar também utilizando a figura 2.3. Como estudo de caso, vamos utilizar o endereço 2.2.2.2/32, que é a Loopback do roteador R2. A Loopback faz parte da Área Backbone, conforme a descrição apresentada anteriormente e as saídas apresentadas a seguir. 11 Vamos utilizar o endereço 2.2.2.2/32 como estudo de caso para Virtual Link;

q

11 Interface Loopback de R2 está configurado como parte da Área Backbone; 11 Observe o LSDB em R4 com o registro do IP 2.2.2.2/32 (saída abreviada): R4# show ip ospf database router OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) Flags: 0x1 : ABR LS Type: router-LSA Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 (...) Link connected to: Stub Network (Link ID) Net: 2.2.2.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10

Observe que o roteador R4 possui em seu LSDB um Router LSA recebido de R2 (Advertising Router: 2.2.2.2), e que há um registro Stub para a rede 2.2.2.2/255.255.255.255. Observe também que há um registro de Transit Network com DR sendo roteador R4 (10.2.4.4). R4# show ip ospf database router OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) LS age: 103 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x1 : ABR LS Type: router-LSA Advertising Router: 2.2.2.2 LS Seq Number: 80000007 Checksum: 0x8961 Length: 48 Number of Links: 2 Link connected to: a Transit Network (Link ID) Designated Router address: 10.2.4.4 (Link Data) Router Interface address: 10.2.4.2 Number of TOS metrics: 0 TOS 0 Metric: 10


Link State ID: 2.2.2.2

61

Link connected to: Stub Network (Link ID) Net: 2.2.2.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10

Observe a seguir que R2 e R4 possuem uma adjacência OSPF; logo, utilizando o Router LSA anterior e a informação de adjacência. O roteador R4 cria uma rota para 2.2.2.2/32, com métrica 20 (10 do registro Transit Network mais 10 do registro Stub Network). R4# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 Full/Backup 35.275s 10.2.4.2 eth0:10.2.4.4 R4# show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "ospf", distance 110, metric 20, best Last update 00:00:51 ago * 10.2.4.2, via eth0

É possível ver que R4 possui adjacência com R2:

q

R4# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 Full/Backup 35.275s 10.2.4.2 eth0:10.2.4.4 R4# show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "ospf", distance 110, metric 20, best Last update 00:00:51 ago * 10.2.4.2, via eth0

Com o registro LSA e a adjacência com R2, R4 cria a rota para 2.2.2.2/32 diretamente; 11 Para testar o Virtual Link, o enlace entre R2 e R4 será removido; logo a Loopback de R2 ficará em uma partição separada da Área Backbone; 11 Após a remoção do LSA, a rota é removida de R4: R4# show ip route 2.2.2.2 % Network not in table

Vamos desativar o enlace entre R2 e R4. Como esse enlace é o único utilizado por R2 para se conectar à Área Backbone, há uma segregação da Área Backbone, onde a Loopback de R2 ficou isolada. Observe a seguir as saídas para confirmar que não há mais uma rota para 2.2.2.2/24: R4# show ip route 2.2.2.2 % Network not in table

Observe que ainda assim há um Router LSA do roteador R2 no LSDB de R4. O Quagga não OSPF Avançado

remove o registro imediatamente; porém, como não há mais adjacência, a rota não é criada.

62

Vamos agora configurar um Virtual Link entre R2 e R3, via R1. A Área 2 será utilizada para criar esse Virtual Link. A configuração de Virtual Link é feita nos dois roteadores, cada um utilizando o Router-ID do roteador remoto.

Criação do Virtual Link entre R2 e R3:

q

11 Configuração aplicada em R2: router ospf area 2 virtual-link 3.3.3.3

11 Configuração aplicada em R3: router ospf area 2 virtual-link 2.2.2.2

A seguinte configuração será aplicada em R2 para criar o Virtual Link: router ospf area 2 virtual-link 3.3.3.3

A seguinte configuração será aplicada em R3 para criar o Virtual Link: router ospf area 2 virtual-link 2.2.2.2

Observe a adjacência criada entre R2 e R3:

q

R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 1 Full/DROther 39.483s 10.1.3.3 VLINK0 R3# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 Full/DROther 39.656s 10.1.2.2 VLINK0

A rota é então criada novamente em R4, apontando para R3: R4# show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "ospf", distance 110, metric 40, best Last update 00:00:07 ago * 10.3.4.3, via eth1

Observe que agora há uma rota para 2.2.2.2/24 em R4, via R3 (10.3.4.3). Observe também que a métrica não é mais 20, e sim 40 (10 para R4 chegar em R3, 20 do Virtual Link e 10 para a Loopback).

Routing entry for 2.2.2.2/32 Known via "ospf", distance 110, metric 40, best Last update 00:00:07 ago * 10.3.4.3, via eth1

Observe em R2 e R3 a adjacência utilizando o Virtual Link (VLINK0) R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 1 Full/DROther 39.483s 10.1.3.3 VLINK0 R3# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface


R4# show ip route 2.2.2.2

2.2.2.2 1 Full/DROther 39.656s 10.1.2.2 VLINK0

63

Observe a seguir como R4 recebe o registro para o prefixo 2.2.2.2/32. Primeiro, observe o Router LSA de R3 informando o Virtual Link. R4# show ip ospf database router OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) LS age: 690 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x1 : ABR LS Type: router-LSA Link State ID: 3.3.3.3 Advertising Router: 3.3.3.3 LS Seq Number: 8000000a Checksum: 0x1c7e Length: 60 Number of Links: 3 Link connected to: a Transit Network (Link ID) Designated Router address: 10.3.4.4 (Link Data) Router Interface address: 10.3.4.3 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: 3.3.3.3 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: a Virtual Link (Link ID) Neighboring Router ID: 2.2.2.2 (Link Data) Router Interface address: 10.1.3.3 Number of TOS metrics: 0 TOS 0 Metric: 20

Observe o Router LSA de R3 (10.1.3.3) informando o Virtual Link. R4# show ip ospf database router OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) (...) Link connected to: a Virtual Link (Link ID) Neighboring Router ID: 2.2.2.2 (Link Data) Router Interface address: 10.1.3.3 Number of TOS metrics: 0

OSPF Avançado

TOS 0 Metric: 20

64

q

A seguir observe como R4 agora possui um Router LSA originado por R2 com o registro Stub da interface Loopback. R4# show ip ospf database router OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) LS age: 895 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x1 : ABR LS Type: router-LSA Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 8000000d Checksum: 0x578c Length: 48 Number of Links: 2 Link connected to: Stub Network (Link ID) Net: 2.2.2.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: a Virtual Link (Link ID) Neighboring Router ID: 3.3.3.3 (Link Data) Router Interface address: 10.1.2.2 Number of TOS metrics: 0 TOS 0 Metric: 20

Observe o Router LSA de R2 (2.2.2.2) informando o Virtual Link. R4# show ip ospf database router OSPF Router with ID (4.4.4.4) Router Link States (Area 0.0.0.0) LS age: 895 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x1 : ABR Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 (...) Link connected to: a Virtual Link (Link ID) Neighboring Router ID: 3.3.3.3 (Link Data) Router Interface address: 10.1.2.2 Number of TOS metrics: 0 TOS 0 Metric: 20

Observe que o Quagga não coloca no campo “Link Data” o endereço da interface conforme sugere a RFC2328. Em vez de adicionar o ifIndex da interface do Virtual Link, o endereço IP do roteador é utilizado.


LS Type: router-LSA

65

Conclusão Nesta sessão, foram apresentados os tipos de área existentes, como cada área funciona e quais LSAs são utilizados. Na próxima sessão, serão apresentadas técnicas que podem ser utilizadas para melhorar ou ajustar o roteamento dos pacotes em uma rede OSPF e como otimizar a convergência.

Comandos OSPF A seguir, uma lista de comandos de configuração que têm relação com o tema da sessão de aprendizagem 2, para serem utilizados no Quagga. Todos os comandos são aplicados na sessão de OSPF do roteador. Em destaque, as palavras-chave. 11 Adiciona as interfaces que são parte do prefixo informado na Área Backbone: network prefixo máscara área 0

11 Adiciona as interfaces que são parte do prefixo informado em uma área Stub: network prefixo máscara área X.X.X.X area X.X.X.X stub

11 Gera uma rota padrão em uma área Stub (utilizado no ABR): area X.X.X.X stub no-summary

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

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

11 Criar uma Área NSSA e gera uma rota padrão na área (utilizado no ABR): network prefixo máscara área Z.Z.Z.Z area Z.Z.Z.Z nssa no-summary

11 Redistribui rotas estáticas no OSPF: redistribute static

11 Redistribui interfaces conectadas no OSPF: redistribute connected

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

OSPF Avançado

66

11 Cria um Virtual Link: area Area_Transito virtual-link Router_ID_ABR

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

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

11 Exibe informações detalhadas por LSA: show ip ospf database

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

11 Exibe informações sobre o processo OSPF em uma determinada interface:

show ip ospf interfaces

11 Exibe as adjacências OSPF estabelecidas:


show ip ospf neighbor

67

68

OSPF Avançado

3 Aprender sobre sumarização; Conhecer agregação de rotas; Entender como funciona a manipulação de rotas; Conhecer sobre filtragem de prefixos.

conceitos

Sumarização de rotas; Agregação de Rotas; Métricas; Escolha de Caminhos pelo OSPF; Controlando Atualizações de Roteamento.

Introdução As sessões de aprendizagem 1 e 2 apresentaram detalhes avançados sobre o funcionamento do OSPF, permitindo ao aluno entender como o OSPF contrói o LSDB e como as mensagens são negociadas, além de detalhar o funcionamento das áreas OSPF. Até esse momento, as configurações OSPF utilizadas ficaram muito próximas das configurações padrão do OSPF. Mesmo essas configurações mais simples permitiram que as diversas topologias ilustradas tivessem um roteamento dinâmico eficaz e livre de loops. Porém, o OSPF permite ajustes mais finos para refletir necessidades de redes mais complexas, o que inclui escolha de caminhos alternativos, economia de recursos dos roteadores e filtros de prefixos. Esta sessão vai detalhar alguns desses ajustes finos possíveis, entre eles sumarização e agregação de rotas; manipulação de rotas e filtragem de prefixos.

Sumarização de rotas 11 Sumarização de rotas; 11 Áreas OSPF permitem que a topologia de uma área seja abstraída das demais áreas; 11 Roteadores ABR criam LSAs do tipo Summary para cada LSA do tipo Router e envia para as demais Áreas OSPF. 22 Caso um LSA Router seja removido do LSDB, um LSA Summary é enviado informando da remoção; 22 Demais roteadores OSPF precisam recalcular as rotas; 22 Recursos computacionais são consumidos a cada incidente. 11 Existem otimizações possíveis.

q

Capítulo 3 - Engenharia de tráfego com OSPF

objetivos

Engenharia de tráfego com OSPF

69

Foi mostrado nas sessões anteriores que uma das principais vantagens de usar particionamento da rede criando áreas OSPF é a contenção de detalhes da topologia inerentes de cada área. Como os LSAs Router e Network ficam contidos no LSDB da área, a topologia é abstraída das demais áreas e apenas LSAs do tipo Summary são enviados com os prefixos internos. Na configuração padrão do OSPF, cada LSA Router recebido pelo roteador ABR dispara a criação de um LSA Summary que, apesar de não prover detalhes da topologia interna, ainda assim é processado pelos demais roteadores OSPF da Área Backbone como parte da topologia da rede. Apesar de esse procedimento estar correto, em determinadas situações, esse modo de funcionamento pode ser otimizado. Observe a figura 3.1.

R4

Área 1

Área Backbone

192.168.0.0/24

R2 R5

LSA Summary 2.1 19

LSA Summary

68

192.168.1.0/24

LSA Summary

2.

LSA Summary

31

192.168.2.0/24

0/

.7.

R6

19

16

8.

7.

2/

31

LSA Summary

ABR

192.168

.7.4/31

R7

(.

19

2.

16

8.

7.

12

/3

1

.

192

192.168.3.0/24

31

.6/

.7 168

. .)

LSA Summary LSA Summary LSA Summary LSA Summary LSA Summary LSA Summary LSA Summary LSA Summary LSA Summary

R10

R3

192.168.6.0/24

A rede OSPF da figura 3.1 tem as seguintes características: 11 Duas áreas OSPF: Área Backbone e Área 1; 11 Um roteador ABR (Router-ID 10.1.2.1);

OSPF Avançado

11 Sete roteadores OSPF internos na Área 1 (R4 até R10);

70

11 Sete enlaces saindo do ABR para os roteadores OSPF internos (com prefixos 192.168.7.x/31); 11 Sete redes internas com prefixo 192.168.[0-6].0/24; 11 Além do roteador ABR, a Área Backbone possui outros dois roteadores OSPF (R2 e R3).

Figura 3.1 Área 1 com configuração padrão OSPF.

ABR vai criar um LSA Summary para cada LSA Router recebido:

q

11 Quatorze LSAs do tipo Summary vão virar 14 rotas em R2 e R3; Cada vez que um enlace entre ABR e um roteador da Área 1 mudar de estado, dois LSAs do tipo Summary serão criados pelo ABR. 11 R2 e R3 vão recalcular as rotas; 11 Como não há outro caminho para tais prefixos, R2 e R3 vão remover os prefixos informados pelos LSAs do tipo Summary recebidos do ABR; 11 Quando o enlace for restaurado, R2 e R3 vão recriar as rotas a partir dos LSAs recebidos. Nessa topologia, para cada LSA Router da Área 1, o roteador ABR vai gerar um LSA Summary para os demais roteadores da Área Backbone. Assim que a rede é estabelecida, os roteadores R2 e R3 vão criar 14 rotas, uma por LSA Summary recebido do roteador ABR. Apesar de a topologia da Área 1 ser desconhecida para os roteadores R2 e R3, toda vez que um dos enlaces entre o ABR e um roteador OSPF interno cair, o ABR vai gerar e enviar dois LSAs do tipo Summary: um para informar que o enlace com o roteador OSPF interno está indisponível, e outro para informar que a rede atrás do roteador OSPF interno está inacessível. Cada roteador da Área Backbone vai então recalcular o LSDB, removendo as rotas para os destinos recém-informados. Observe a seguir o LSDB do roteador R2 com os 14 LSAs do tipo Summary recebidos do roteador ABR (teste você mesmo com o arquivo adr9-cap3-sumarizacao.imn): R2# show ip ospf database OSPF Router with ID (10.1.2.2) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 10.1.2.1 10.1.2.1 41 0x80000008 0x913e 2 10.1.2.2 10.1.2.2 45 0x80000007 0xd4f6 2 10.1.3.3 10.1.3.3 41 0x80000006 0xfcc6 2 Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 10.1.2.2 10.1.2.2 45 0x80000001 0x67b7 10.1.3.3 10.1.3.3 41 0x80000001 0x60b8 10.2.3.3 10.1.3.3 51 0x80000001 0x5eb8 Summary Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Route 192.168.1.0 10.1.2.1 234 0x80000001 0x01cf 192.168.1.0/24 192.168.2.0 10.1.2.1 234 0x80000001 0xf5d9 192.168.2.0/24 192.168.3.0 10.1.2.1 234 0x80000001 0xeae3 192.168.3.0/24 192.168.4.0 10.1.2.1 233 0x80000001 0xdfed 192.168.4.0/24 192.168.5.0 10.1.2.1 233 0x80000001 0xd4f7 192.168.5.0/24 192.168.6.0 10.1.2.1 233 0x80000001 0xc902 192.168.6.0/24 192.168.7.0 10.1.2.1 284 0x80000001 0x5481 192.168.7.0/31 192.168.7.2 10.1.2.1 284 0x80000001 0x4093 192.168.7.2/31 192.168.7.4 10.1.2.1 284 0x80000001 0x2ca5 192.168.7.4/31 192.168.7.6 10.1.2.1 284 0x80000001 0x18b7 192.168.7.6/31 192.168.7.8 10.1.2.1 284 0x80000001 0x04c9 192.168.7.8/31 192.168.7.10 10.1.2.1 284 0x80000001 0xefdb 192.168.7.10/31


192.168.0.0 10.1.2.1 234 0x80000001 0x0cc5 192.168.0.0/24

192.168.7.12 10.1.2.1 284 0x80000001 0xdbed 192.168.7.12/31

71

Vamos utilizar como exemplo a topologia da figura 3.1: imagine que o enlace entre ABR e o roteador R4 teve seu estado alterado para DOWN (por problemas na operadora, por exemplo). ABR, vendo que o enlace com R4 mudou de estado, vai recalcular seu LSDB. Devido ao cálculo, o ABR vai remover a rede 192.168.0.0/24 que era alcançada via o enlace 192.168.7.0/31. Após o cálculo, ABR vai gerar dois LSAs do tipo Summary e enviar para R2 e R3: um sobre o enlace 192.168.0.0/24 e outro sobre o enlace 192.168.7.0/24, ambos com o campo “Age” do LSA preenchido com MaxAge (3600). Ao receber os LSAs, R2 e R3 recalculam seus respectivos LSDBs e removem ambas as rotas. Observe que não há alternativa para chegar ao prefixo 192.168.0.0/24. Assim que o enlace com R4 ficar operante novamente, ABR vai anunciar os prefixos antes removidos para R2 e R3 via LSA Summary e as rotas serão recriadas, apontando para ABR. Suponha agora que a operadora ainda está recuperando o circuito entre o ABR e o R4, e esse enlace ainda oscile algumas vezes. A cada oscilação, o processo vai ser re-executado por ABR, R2 e R3, consumindo recursos de R2 e R3 que nem conhecem a topologia interna da Área 1. Nesse caso específico, como a rede 192.168.0.0/24 só é alcançada via ABR, não faz sentido os roteadores R2 e R3 ficarem recalculando as rotas a cada oscilação, uma vez que ou o prefixo vai estar fora (já que não há redundância de acesso) ou vai estar ativo via ABR. Então, para evitar que R2 e R3 sejam afetados pela instabilidade do circuito, o que o Engenheiro de Rede pode fazer é: como nessa rede o acesso é via ABR, o roteador ABR não precisa ficar enviando LSAs do tipo Summary a cada oscilação. Ou seja, o Engenheiro de Redes pode configurar o ABR para enviar o LSA Summary apenas para informar que a rede está acessível (no início do funcionamento da rede OSPF e a cada refresh). No Quagga, essa configuração é feita pelo comando a seguir: router ospf area NÚMERO_ÁREA range IP_A_SER_SUMARIZADO [cost métrica]

Para evitar consumo de recursos de R2 e R3 a cada oscilação na Área 1, o comando range

q

pode ser utilizado: area NÚMERO_ÁREA range IP_A_SER_SUMARIZADO [cost métrica]

IP_A_SER_SUMARIZADO deve incluir mais do que apenas um prefixo IP ou LSA Router Para que inclua mais do que apenas um prefixo IP, prefixos IP utilizados na área devem fazer parte de um prefixo IP maior, ou seja, devem ser agregáveis. Para que esse comando seja aplicado de maneira satisfatória, o prefixo IP em IP_A_SER_ SUMARIZADO deve incluir mais de um LSA Router, ou seja, deve contemplar mais do que apenas um prefixo IP. Por exemplo, observe a configuração a seguir. Nela, cada LSA Router da Área 1 estaria associado a um comando range, porém essa configuração não seria útil para manter as rotas em R2 e R3, ou seja, não evitaria que R2 e R3 recalculassem seus LSDBs a cada oscilação na Área 1.

OSPF Avançado

! Configuração INCORRETA

72

router ospf area 0.0.0.1 range 192.168.0.0/24 area 0.0.0.1 range 192.168.1.0/24 area 0.0.0.1 range 192.168.2.0/24 area 0.0.0.1 range 192.168.3.0/24

area 0.0.0.1 range 192.168.4.0/24 area 0.0.0.1 range 192.168.5.0/24 area 0.0.0.1 range 192.168.6.0/24 area 0.0.0.1 range 192.168.7.0/31 area 0.0.0.1 range 192.168.7.4/31 area 0.0.0.1 range 192.168.7.6/31 area 0.0.0.1 range 192.168.7.8/31 area 0.0.0.1 range 192.168.7.10/31 area 0.0.0.1 range 192.168.7.12/31

Para usar o comando range de maneira satisfatória, é necessário mais de um prefixo IP contemplado pelo comando range. Como na topologia da figura 3.1 os prefixos IP fazem parte de um prefixo IP maior, a seguinte configuração deveria ser inserida no roteador ABR: ! Configuração CORRETA router ospf area 0.0.0.1 range 192.168.0.0/20

Uma vez que as rotas são criadas em R2 e R3 a partir do LSA Summary, ambos vão sempre enviar os pacotes para ABR, mesmo que o circuito oscile. Ao aplicar esse comando para o prefixo 192.168.0.0/20, observe o que acontece com o LSDB de R2 (LSAs Router e Network removidos): R2# show ip ospf database OSPF Router with ID (10.1.2.2) Summary Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Route 192.168.0.0 10.1.2.1 3600 0x80000001 0x0cc5 192.168.0.0/24 192.168.1.0 10.1.2.1 3600 0x80000001 0x01cf 192.168.1.0/24 192.168.2.0 10.1.2.1 3600 0x80000001 0xf5d9 192.168.2.0/24 192.168.3.0 10.1.2.1 3600 0x80000001 0xeae3 192.168.3.0/24 192.168.4.0 10.1.2.1 3600 0x80000001 0xdfed 192.168.4.0/24 192.168.5.0 10.1.2.1 3600 0x80000001 0xd4f7 192.168.5.0/24 192.168.6.0 10.1.2.1 3600 0x80000001 0xc902 192.168.6.0/24 192.168.7.0 10.1.2.1 3600 0x80000001 0x5481 192.168.7.0/31 192.168.7.2 10.1.2.1 3600 0x80000001 0x4093 192.168.7.2/31 192.168.7.4 10.1.2.1 3600 0x80000001 0x2ca5 192.168.7.4/31 192.168.7.8 10.1.2.1 3600 0x80000001 0x04c9 192.168.7.8/31 192.168.7.10 10.1.2.1 3600 0x80000001 0xefdb 192.168.7.10/31 192.168.7.12 10.1.2.1 3600 0x80000001 0xdbed 192.168.7.12/31 192.168.15.255 10.1.2.1 4 0x80000001 0x1bb6 192.168.0.0/20


192.168.7.6 10.1.2.1 3600 0x80000001 0x18b7 192.168.7.6/31

73

11 Após a inserção do comando range, LSAs do tipo Summary são enviados com campo

q

Age preenchido com MaxAge; 11 Roteadores OSPF removem os LSAs do tipo Summary; 11 Apenas um LSA Summary é mantido: aquele informado no comando range; 11 Por exemplo, usando a figura 36, em vez de 14 prefixos na tabela de rotas e no LSDB, apenas um existirá: R2# show ip ospf database Summary Link States (Area 0.0.0.0) 192.168.15.255 10.1.2.1 4 0x80000001 0x1bb6 192.168.0.0/20

Ao inserir esse comando, o ABR enviou um novo LSA Summary para cada LSA Router existente na Área 1; porém, agora com o campo “Age” configurado como MaxAge. Conforme apresentado na sessão 1, enviar um LSA com o campo “Age” configurado com MaxAge força os demais roteadores OSPF a removerem tal registro do LSDB. Observe o LSDB do roteador R2 alguns segundos após a saída anterior, já sem os registros LSA mais específicos: R2# show ip ospf database OSPF Router with ID (10.1.2.2) Summary Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Route 192.168.15.255 10.1.2.1 84 0x80000001 0x1bb6 192.168.0.0/20

Observe que há apenas uma rota em R2 para a rede 192.168.0.0/20: R2# show ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route > O>* 192.168.0.0/20 [110/30] via 10.1.2.1, eth0, 00:01:06

Com essa configuração, apenas um LSA Summary foi gerado por ABR e enviado para R2 e R3. O LSDB da Área Backbone ficaria mais otimizado com apenas um LSA Summary em vez

OSPF Avançado

de 14. A figura 3.2 ilustra essa modificação.

74

R4

Área 1

Área Backbone

192.168.0.0/24

R2 R5 .7. 68 2.1 19

192.168.1.0/24

192.168.2.0/24

19

2.

31 0/

R6

16

8.

7.

2/

31

ABR

192.168

.7.4/31

R7

LSA Summary – 192.168.0.0/20

/31

.7.6

68 2.1

(.

19

2.

16

8.

7.

12

/3

1

19

192.168.3.0/24

. .) R10

R3

192.168.6.0/24

É importante salientar que a sumarização só acontece com duas condições: 11 Pelo menos um LSA Network para a rede a ser sumarizada tem de estar no LSDB. Ou seja, se todos os enlaces entre ABR e os roteadores OSPF internos estiverem fora, o LSA Summary não será gerado; 11 A sumarização só acontece para LSA Router, não para LSA AS-External. Importante salientar: 11 Pelo menos um LSA Network para a rede a ser sumarizada tem de estar no LSDB. Ou seja, se todos os enlaces entre ABR e os roteadores OSPF internos estiverem fora, o LSA Summary não será gerado; 11 A sumarização só acontece para LSA Router, não para LSA AS-External.

q Capítulo 3 - Engenharia de tráfego com OSPF

Figura 3.2 Rede OSPF com Sumarização.

75

Normalmente, três questões são levantadas por quem está vendo essa abordagem pela primeira vez: 1. Se R2 e R3 enviarem os pacotes para ABR mesmo que a rede esteja indisponível, isso não vai sobrecarregar o ABR desnecessariamente? Quando R2 e R3 enviarem os pacotes para ABR, os enlaces entre eles vão ser utilizados, porém essa carga será mínima, já que não haverá comunicação no sentido contrário. Mesmo com essa utilização de recursos da rede, os benefícios tendem a superar esse custo, uma vez que o consumo de CPU e memória em R2 e R3 será menor, além de que com o LSDB sendo menor, a convergência da rede é mais rápida. 2. Quando os pacotes destinados à rede 192.168.0.0/24 chegarem ao ABR e o enlace com R4 estiver fora, não há risco de criar-se um loop de roteamento, caso o ABR tenha uma rota padrão apontando para R2 ou R3? Para evitar que haja loops de roteamento nessas situações, os roteadores OSPF criam uma rota estática com baixa prioridade apontando para Null, ou seja, caso a rota OSPF para 192.168.0.0/24 seja removida por queda no enlace, a rota estática para o prefixo sumarizado 192.168.0.0/20 apontando para Null será utilizada, descartando os pacotes para a rede 192.168.0.0/24, e não enviando via rota padrão. 3. Qual é a métrica que ficará associada ao LSA Summary configurado? O comando range apresentado anteriormente permite que o engenheiro de redes estabeleça a métrica para aquele LSA Summary configurado. Como aquele parâmetro é opcional, caso não estabelecido, a métrica a ser utilizada será a menor métrica dos LSAs do tipo Router associados ao LSA Summary. Três questões podem ser levantadas por quem está vendo essa abordagem pela

q

primeira vez: 11 Se R2 e R3 enviarem os pacotes para ABR mesmo que a rede esteja indisponível, isso não vai sobrecarregar o ABR desnecessariamente? 11 Quando os pacotes destinados à rede 192.168.0.0/24 chegarem ao ABR e o enlace com R4 estiver fora, não há risco de criar-se um loop de roteamento, caso o ABR tenha uma rota padrão apontando para R2 ou R3? 11 Qual é a métrica que ficará associada ao LSA Summary configurado?

Agregação de rotas 11 Também é possível otimizar e agregar prefixos oriundos de LSAs do Tipo AS-External.

q

11 O seguinte comando pode ser utilizado: router ospf summary-address prefixo máscara [tag TAG]

Conforme apresentado na sessão anterior, o comando range apenas é utilizado para criar

OSPF Avançado

LSAs do tipo Summary a partir de LSAs do tipo Router. Quando o objetivo é agregar LSAs do

76

tipo AS-External, utiliza-se o comando a seguir. router ospf summary-address prefixo máscara [tag TAG]

Diferentemente do comando range, o comando summary-address não é associado a nenhuma área, uma vez que os LSAs do tipo AS-External também não são associados com área alguma. Além disso, o comando summary-address deve ser inserido no roteador ASBR, e não no ABR. Para ilustrar o LSDB, vamos utilizar a topologia da figura 3.3.

R4

External

Área Backbone

192.168.0.0/24

R2 R5

R6 192.168.2.0/24

19

2.

31 0/

.7. 68 2.1 19

192.168.1.0/24

16

8.

7.

2/

31

ASBR

192.168

.7.4/31

R7

/31

7.6

8. .16

(.

19

2.

16

8.

7.

12

/3

1

192

192.168.3.0/24

. .) R10

R3

192.168.6.0/24

Apesar de ser semelhante à topologia da figura 3.1, o roteador ABR foi substituído pelo roteador ASBR, e não há adjacências OSPF entre ASBR e os roteadores R4 até R10. ASBR tem uma rota estática para cada rede interna e redistribui essas rotas mais as interfaces conectadas no processo OSPF. Observe a configuração a seguir do ASBR: router ospf ospf router-id 10.1.2.1 redistribute connected redistribute static network 10.1.2.0/24 area 0.0.0.0 network 10.1.3.0/24 area 0.0.0.0 ! ip route 192.168.0.0/24 192.168.7.1 ip route 192.168.1.0/24 192.168.7.3


Figura 3.3 Redistribuição e Agregação.

77

ip route 192.168.2.0/24 192.168.7.5 ip route 192.168.3.0/24 192.168.7.7 ip route 192.168.4.0/24 192.168.7.9 ip route 192.168.5.0/24 192.168.7.11 ip route 192.168.6.0/24 192.168.7.13

11 O roteador ASBR não possui adjacências OSPF com os roteadores R4 a R10;

q

11 Uma rota estática é criada para cada rede interna; 11 Rotas Estáticas são redistribuídas no processo OSPF; 11 Roteadores R2 e R3 recebem quatorze LSAs do tipo AS-External: 22 Todos apontam para o ASBR; 22 Não existe alternativa de caminho. As configurações dessa topologia podem ser vistas no arquivo adr9-cap3-agregacao.imn. Como o ASBR está redistribuindo as rotas estáticas no processo OSPF, LSAs do tipo AS-External estão sendo gerados e enviados para R2 e R3. Observe o LSDB do roteador R2: R2# show ip ospf data OSPF Router with ID (10.1.2.2) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 10.1.2.1 10.1.2.1 87 0x80000009 0x923b 2 10.1.2.2 10.1.2.2 86 0x80000007 0xd4f6 2 10.1.3.3 10.1.3.3 92 0x80000006 0xfcc6 2 Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 10.1.2.2 10.1.2.2 91 0x80000001 0x67b7 10.1.3.3 10.1.3.3 92 0x80000001 0x60b8 10.2.3.3 10.1.3.3 92 0x80000001 0x5eb8 AS External Link States Link ID ADV Router Age Seq# CkSum Route 192.168.0.0 10.1.2.1 5 0x80000001 0x83c3 E2 192.168.0.0/24 [0x0] 192.168.1.0 10.1.2.1 5 0x80000001 0x78cd E2 192.168.1.0/24 [0x0] 192.168.2.0 10.1.2.1 5 0x80000001 0x6dd7 E2 192.168.2.0/24 [0x0] 192.168.3.0 10.1.2.1 5 0x80000001 0x62e1 E2 192.168.3.0/24 [0x0] 192.168.4.0 10.1.2.1 5 0x80000001 0x57eb E2 192.168.4.0/24 [0x0] 192.168.5.0 10.1.2.1 5 0x80000001 0x4cf5 E2 192.168.5.0/24 [0x0] 192.168.6.0 10.1.2.1 5 0x80000001 0x41ff E2 192.168.6.0/24 [0x0] 192.168.7.0 10.1.2.1 92 0x80000003 0x2c13 E2 192.168.7.0/31 [0x0] 192.168.7.2 10.1.2.1 92 0x80000003 0x1825 E2 192.168.7.2/31 [0x0] 192.168.7.4 10.1.2.1 92 0x80000003 0x0437 E2 192.168.7.4/31 [0x0]

OSPF Avançado

192.168.7.6 10.1.2.1 92 0x80000003 0xef49 E2 192.168.7.6/31 [0x0]

78

192.168.7.8 10.1.2.1 92 0x80000003 0xdb5b E2 192.168.7.8/31 [0x0] 192.168.7.10 10.1.2.1 92 0x80000003 0xc76d E2 192.168.7.10/31 [0x0] 192.168.7.12 10.1.2.1 92 0x80000003 0xb37f E2 192.168.7.12/31 [0x0]

Essa saída mostra a configuração padrão do OSPF sem agregação ou sumarização. Observe os LSAs do Tipo AS-External para as redes internas. Cada LSA do tipo AS-External vai gerar uma rota a ser instalada no roteador R2: R2# show ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route O>* 192.168.0.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00 O>* 192.168.1.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00 O>* 192.168.2.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00 O>* 192.168.3.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00 O>* 192.168.4.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00 O>* 192.168.5.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00 O>* 192.168.6.0/24 [110/20] via 10.1.2.1, eth0, 00:33:00 O>* 192.168.7.0/31 [110/20] via 10.1.2.1, eth0, 00:34:21 O>* 192.168.7.2/31 [110/20] via 10.1.2.1, eth0, 00:34:21 O>* 192.168.7.4/31 [110/20] via 10.1.2.1, eth0, 00:34:21 O>* 192.168.7.6/31 [110/20] via 10.1.2.1, eth0, 00:34:21 O>* 192.168.7.8/31 [110/20] via 10.1.2.1, eth0, 00:34:21 O>* 192.168.7.10/31 [110/20] via 10.1.2.1, eth0, 00:34:21 O>* 192.168.7.12/31 [110/20] via 10.1.2.1, eth0, 00:34:21

Vamos aplicar o comando summary-address a seguir no ASBR para agregarmos os prefixos. O comando a seguir será aplicado: router ospf summary-address 192.168.0.0/20

Ao aplicarmos esse comando, novos LSAs do tipo AS-External serão enviados informando aos roteadores remotos para removê-los (campo “Age” com valor MaxAge) e um novo LSA AS-External será criado. Observe novamente o LSDB do roteador R2: R2# show ip ospf database OSPF Router with ID (10.1.2.2) AS External Link States Link ID ADV Router Age Seq# CkSum Route 192.168.0.0 10.1.2.1 34 0x80000001 0x381e E2 192.168.0.0/20 [0x0] Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route O>* 192.168.0.0/20 [110/20] via 10.1.2.1, eth0, 00:03:04

11 Após receber os 14 LSAs do tipo AS-External, 14 rotas são criadas por R2 e R3; 11 Com o comando summary-address 192.168.0.0/20, novos LSAs do tipo AS-External são gerados com o campo “Age” com valor MaxAge, forçando sua remoção; 11 Um LSA AS-External com o valor agregado será enviado e apenas uma rota será criada em R2 e R3.

q


R2# show ip route ospf

79

Até o presente momento, o comando summary-address, apesar de comum e útil, não foi implementado no Quagga, apesar de ser bastante comum em outras plataformas. Porém, existe outra abordagem que permite o mesmo resultado, e será explicado na sessão de route-maps (ou mapas de rotas). Essa outra abordagem foi utilizada para gerar a saída acima.

Métricas 11 Cálculo das Rotas utiliza as métricas ou custos das interfaces.

q

11 Rotas com menores custos são escolhidas. 11 Custo padrão de cada interface no Quagga é definida a partir da equação: 22 Custo padrão = 100Mbps/(Largura de Banda da Interface). 11 Como interfaces com mais capacidade que 100Mbps estão disponíveis, Engenheiro de Redes pode: 22 Usar o comando de interface ip ospf cost VALOR por interface com o valor desejado. 22 Usar o comando do OSPF auto-cost reference-bandwidth VALOR. 33 O comando auto-cost muda o custo de todas as interfaces do roteador. 11 Comando ip ospf cost VALOR é útil para configurações customizadas ou enlaces virtuais com capacidade menor que a capacidade da interface física. 11 OSPF suporta Equal Cost Multi-Path (ECMP) ou seja, todas rotas de mesmo custo devem ser instaladas. No curso Protocolos de Roteamento IP, o aluno aprendeu que o OSPF define as rotas a partir de cálculos de menor caminho usando algoritmo de Dijkstra ou Short Path First. Para calcular o menor custo para cada destino, já foi visto que é utilizada a informação do campo “Métrica do LSA”. Para evitar que o Engenheiro de Rede tenha de definir manualmente o custo de cada interface, as implementações de OSPF utilizam a largura de banda disponível de cada interface para definir a métrica a ser utilizada. O Quagga e alguns outros fabricantes definem essa métrica por interface dividindo o custo de referência, 100Mbps, pela largura de banda da interface física. Ou seja, o custo padrão é: Custo padrão = 100Mbps/(Largura de Banda da Interface) Como no OSPF, quanto menor for o valor da métrica, maior a preferência, uma interface FastEthernet tem o menor custo, ou seja, custo de 1. À época da escrita da RFC do OSPF, interfaces FastEthernet eram as mais populares e com maior largura de banda disponível. Porém, hoje, onde interfaces GigabitEthernet, 10GigabitEthernet e mesmo 100GigabitEthernet estão disponíveis, utilizar esse custo padrão sugerido pelas implementações OSPF se mostra sub-otimizado, uma vez que apenas valores inteiros são possíveis, ou seja: interfaces FastEthernet, GigabitEthernet e 10GigabitEthernet todas possuiriam custo de 1. Foram apresentados exemplos nas sessões anteriores, mostrando que é possível manipular o custo de cada interface com o comando: interface ethX OSPF Avançado

ip ospf cost VALOR

80

Para evitar que o Engenheiro de Rede tenha de mudar interface por interface para ajustar a métrica com suporte a interfaces com maior capacidade, o Quagga provê o comando a seguir: router ospf auto-cost reference-bandwidth <1-4294967>

Por exemplo, caso deseje trabalhar com interfaces 10GigabitEthernet, aplique o seguinte comando: router ospf auto-cost reference-bandwidth 10000

Com esse comando aplicado, as interfaces 10GigabitEthernet terão métrica de 1, as interfaces 2,5GigabitEthernet terão métrica 4, e as interfaces 1GigabitEthernet terão métrica 10. Para que a topologia seja coerente, o comando deve ser aplicado em todos os roteadores OSPF. O comando de interface ip ospf cost VALOR é útil para configurações customizadas ou casos de enlaces virtuais, por exemplo: 11 Circuitos Frame-Relay que usam subinterfaces: nesse caso, como muitos circuitos podem ser configurados em uma mesma interface, cada um com largura de banda diferente, o comando ip ospf cost é utilizado para refletir manualmente o custo desejado em cada subinterface; 11 Circuitos Metro-Ethernet ou VLANs configuradas uma interface Ethernet: assim como no Frame-Relay, cada circuito pode ter largura de banda diferente dos demais, e inferior à capacidade da interface física.

Equal Cost Multi-Path A especificação do OSPF permite que, caso existam múltiplos caminhos do mesmo tipo (tipos de rota OSPF serão explicadas na próxima sessão) e com o mesmo custo, o roteador OSPF deve instalar todas as rotas de custo igual. A limitação da quantidade é definida pelo fabricante ou pela implementação, e depende de recursos do Sistema Operacional. No final do tópico a seguir, “Escolha de Caminhos pelo OSPF”, um exemplo prático será apresentado sobre ECMP.

Escolha de caminhos pelo OSPF 11 Com o particionamento, várias Áreas OSPF são possíveis.

q

11 Protocolo OSPF faz diferenciação de rotas a partir das origens: 22 Rotas Intra-Área: geradas na própria área. 22 Rotas Inter-Área: gerada em outra área OSPF. 22 Rotas Externas: rotas redistribuídas pelo ASBR. Podem ser Externas ou NSSA, Tipo 1 ou 2.

diversas redes menores, chamadas de áreas, e que diversos tipos de área são possíveis: Área Backbone, Área Normal, Área Stub e Área Not-So-Stub – ou NSSA. Para diferenciar os tipos de rotas, o OSPF cria os seguintes tipos de rotas: 11 Rotas Intra-Área: são aquelas geradas dentro da área da qual o roteador OSPF faz parte; 11 Rotas Inter-Área: aquelas geradas dentro de outra área OSPF e foi recebida do roteador ABR; 11 Rotas Externas: são redistribuídas no processo OSPF por algum roteador ASBR. Áreas Externas podem ser do Tipo 1 ou do Tipo 2, Externas ou NSSA. Lembre-se: rotas Externas do Tipo 1 possuem a métrica da rota externa mais a métrica interna do OSPF. Rotas Externas do Tipo 2 só possuem a métrica da rota externa, e essa é preservada ao longo da rede.


Foi apresentado até agora que o OSPF permite fazer o particionamento da rede em

81

Os tipos de rota são levados em consideração pelo processo OSPF para decidir por qual instalar. Observe a figura 3.4 (arquivo adr9-cap3-escolha_de_caminhos.imn).

R1

Área Backbone

R2 1

Área 1 100

2 R3

3.3.3.3/24 Na topologia da figura 3.4, cada roteador possui uma interface loopback que faz parte do processo OSPF. Nos roteadores R1 e R2, a interface loopback faz parte da Área Backbone, e no roteador R3 faz parte da Área 1. Cada enlace possui um custo OSPF: R1-R2 tem custo 1; R1-R3 tem custo 100 e R2-R3 tem custo 2. Lembre-se de que quanto menor o custo, melhor é a rota. Observe a configuração e as rotas OSPF instaladas no roteador R1. O endereçamento segue o mesmo padrão anteriormente definido. router ospf ospf router-id 1.1.1.1 network 1.1.1.1/24 area 0.0.0.0 network 10.1.2.0/24 area 0.0.0.0 network 10.1.3.0/24 area 0.0.0.1 R1# show ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route O 1.1.1.0/24 [110/10] is directly connected, lo, 00:02:10 O>* 2.2.2.0/24 [110/11] via 10.1.2.2, eth1, 00:01:20 O>* 3.3.3.0/24 [110/110] via 10.1.3.3, eth0, 00:01:20 O 10.1.2.0/24 [110/1] is directly connected, eth1, 00:02:10 O 10.1.3.0/24 [110/100] is directly connected, eth0, 00:02:10 O>* 10.2.3.0/24 [110/102] via 10.1.3.3, eth0, 00:01:20

Observe na saída que, para alcançar o endereço da loopback de R3 (cujo endereço IP é 3.3.3.3/24), o custo é 110. Ao observar mais uma vez a figura 3.4, é possível encontrar um caminho com custo menor, via R2, ou seja, R1-R2 e R2-R3, que seria 13. Então, por que R1

OSPF Avançado

escolheu ir via R1-R3?

82

Mesmo interfaces virtuais, como as Loopbacks, possuem um custo associado. Observe na saída de R1, por exemplo, que a loopback de R1 (1.1.1.0/24) tem custo 10. Por padrão, o Quagga coloca custo 10 em interfaces virtuais.

Figura 3.4 Escolha de Caminhos.

Observe o LSDB de R1 a seguir. R1# show ip ospf database OSPF Router with ID (1.1.1.1) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 1.1.1.1 1.1.1.1 905 0x80000006 0x6aa0 2 2.2.2.2 2.2.2.2 906 0x80000005 0x7c82 2 Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 10.1.2.2 2.2.2.2 906 0x80000001 0x1324 Summary Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Route 3.3.3.0 1.1.1.1 894 0x80000001 0x31b0 3.3.3.0/24 3.3.3.0 2.2.2.2 895 0x80000001 0x3110 3.3.3.0/24 10.1.3.0 1.1.1.1 944 0x80000001 0x895d 10.1.3.0/24 10.1.3.0 2.2.2.2 895 0x80000001 0x756c 10.1.3.0/24 10.2.3.0 1.1.1.1 894 0x80000001 0x9152 10.2.3.0/24 10.2.3.0 2.2.2.2 945 0x80000001 0x7dc7 10.2.3.0/24 Router Link States (Area 0.0.0.1) Link ID ADV Router Age Seq# CkSum Link count 1.1.1.1 1.1.1.1 905 0x80000005 0xb012 1 2.2.2.2 2.2.2.2 906 0x80000005 0x8991 1 3.3.3.3 3.3.3.3 905 0x80000007 0x3126 3 Net Link States (Area 0.0.0.1) Link ID ADV Router Age Seq# CkSum 10.1.3.3 3.3.3.3 906 0x80000001 0x121b 10.2.3.3 3.3.3.3 906 0x80000001 0x28ff Summary Link States (Area 0.0.0.1) Link ID ADV Router Age Seq# CkSum Route 1.1.1.0 1.1.1.1 944 0x80000001 0x8dbe 1.1.1.0/24 1.1.1.0 2.2.2.2 896 0x80000001 0x83c2 1.1.1.0/24 2.2.2.0 1.1.1.1 894 0x80000001 0x73d4 2.2.2.0/24 2.2.2.0 2.2.2.2 946 0x80000001 0x4bf9 2.2.2.0/24 10.1.2.0 1.1.1.1 944 0x80000001 0xb298 10.1.2.0/24 10.1.2.0 2.2.2.2 946 0x80000001 0x9ea7 10.1.2.0/24

3.3.3.0/24: um que é gerado pelo roteador R1 (ADV Router 1.1.1.1) e enviado para a Área Backbone, e um que é gerado pelo roteador R2 (ADV Router 2.2.2.2) e também enviado para a Área Backbone. Mas, para gerar um LSA Summary, conforme apresentado anteriormente, é necessário que um LSA Router tenha sido recebido pelo roteador ABR com o mesmo prefixo. Observe a seguir a confirmação:


Observe que realçados em vermelho existem dois LSAs do Tipo Summary com a rota para

83

R1# show ip ospf database route adv-router 3.3.3.3 OSPF Router with ID (1.1.1.1) Router Link States (Area 0.0.0.1) LS age: 1023 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x0 LS Type: router-LSA Link State ID: 3.3.3.3 Advertising Router: 3.3.3.3 LS Seq Number: 80000007 Checksum: 0x3126 Length: 60 Number of Links: 3 Link connected to: a Transit Network (Link ID) Designated Router address: 10.1.3.3 (Link Data) Router Interface address: 10.1.3.3 Number of TOS metrics: 0 TOS 0 Metric: 100 Link connected to: a Transit Network (Link ID) Designated Router address: 10.2.3.3 (Link Data) Router Interface address: 10.2.3.3 Number of TOS metrics: 0 TOS 0 Metric: 2 Link connected to: Stub Network (Link ID) Net: 3.3.3.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metric: 10

Este comando exibe o LSDB da Área 1 (Area 0.0.0.1) com o LSA Router gerado pelo roteador R3 (Advertising Router 3.3.3.3). Observe que existe um enlace do tipo Stub Network, com o prefixo 3.3.3.0/24, além de custo 10. Apesar de o Quagga não deixar explícito o motivo de ter escolhido a rota com custo maior (110 contra 13), a razão está na RFC 2328 do OSPF: no processo de escolha de qual rota deve ser instalada, rotas Intra-Área sempre terão preferência sob as rotas Inter-Áreas. No caso da figura 3.4, mesmo que o enlace R1-R3 fosse apenas um enlace de backup, com baixa capacidade, ainda assim ele seria preterido quando comparado com o LSA Summary recebido de R2. Ou seja, o processo de escolha de rota do OSPF sempre terá a seguinte lista de prioridades: 1. Intra-Área.

OSPF Avançado

2. Inter-Área.

84

3. Externa do Tipo 1: AS-External-NSSA. 4. Externa do Tipo 1: AS-External. 5. Externa do Tipo 2: AS-External-NSSA. 6. Externa do Tipo 2: AS-External.

q

11 Prioridades para o processo de escolha de rota 22 Intra-Área 22 Inter-Área 22 Externa do Tipo 1 - AS-External-NSSA 22 Externa do Tipo 1 - AS-External 22 Externa do Tipo 2 - AS-External-NSSA 22 Externa do Tipo 2 - AS-External

É fácil entender que quanto mais informações se tem de uma rota, maior a chance de ela ser escolhida pelo processo OSPF. Caso exista mais de um caminho com a mesma prioridade; por exemplo, duas rotas Intra-Área recebidas, a escolha se dará pelo custo total. Em caso de custo total ser semelhante, ambas as rotas devem ser instaladas, usando a abordagem de Equal Cost Multi-Path (ECMP) apresentada anteriormente. Observe a figura 3.5, disponível no arquivo adr9-cap-escolha-de-caminhos2.imn.

R1

R2

Área Backbone 2

4

2 R3

Figura 3.5

ECMP.

3.3.3.3/24 Como todos os enlaces fazem parte da mesma área, para R1 chegar à Loopback de R3, existem duas opções com a mesma métrica. A saída a seguir do roteador R1 confirma o ECMP instalado, onde é possível ver a mesma rota com dois roteadores como próximo salto. R1# show ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, > - selected route, * - FIB route O 1.1.1.0/24 [110/10] is directly connected, lo, 00:02:28 O>* 2.2.2.0/24 [110/12] via 10.1.2.2, eth1, 00:01:42 O>* 3.3.3.0/24 [110/14] via 10.1.3.3, eth0, 00:01:32 * via 10.1.2.2, eth1, 00:01:32 O 10.1.2.0/24 [110/2] is directly connected, eth1, 00:02:28 O 10.1.3.0/24 [110/4] is directly connected, eth0, 00:02:28 O>* 10.2.3.0/24 [110/4] via 10.1.2.2, eth1, 00:01:42

A funcionalidade ECMP é muito útil para fazer balanceamento de carga e otimização do roteamento. Observe que o protocolo OSPF só suporta múltiplas rotas para o mesmo destino caso as métricas sejam idênticas.


O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,

85

Controlando atualizações de roteamento 11 Sistemas Autônomos tendem a possuir diversas configurações e complexidades,

q

envolvendo diversos tipos de enlaces e protocolos, múltiplos IGPs que requerem configurações extras para garantir a otimização. 11 Funcionalidades extras, como Interfaces Passivas, Rotas Padrão e Filtragem tendem a ser fundamentais em grandes Sistemas Autônomos, especialmente em caso de múltiplos IGP. Conforme a configuração da rede fica mais complexa, com mais roteadores, outros IGPs, diferentes tipos de enlaces e protocolos, mais ajustes finos são necessários para garantir que os protocolos de roteamento funcionem da maneira mais otimizada possível. Esses ajustes também se aplicam ao protocolo OSPF, e nesta sessão alguns ajustes serão apresentados em detalhes. No início desta sessão, técnicas de sumarização e agregação foram apresentas. Nesta sessão, as seguintes técnicas serão apresentadas: 11 Passive Interfaces (Interfaces Passivas); 11 Rotas Padrão; 11 Filtrando Prefixos. 22 Distributed Lists (Listas de Distribuição); 22 Route-Maps (Mapas de Rotas). Essas técnicas também serão utilizadas na próxima sessão, quando a interação com outros protocolos de roteamento será detalhada.

Interfaces Passivas (Passive Interfaces) 11 Interfaces Passivas ou Passive Interfaces podem ser utilizadas para dar mais flexibili-

q

dade nas configurações OSPF. 11 Com Interfaces Passivas, as rotas geradas são tratadas como Intra-Área. 11 Com o comando redistribute, as rotas geradas são tratadas como rotas Externas. 11 Interfaces configuradas como passivas não enviam mensagens Hello nem formam adjacências OSPF. Até esse momento, foram apresentadas duas maneiras de adicionar o prefixo IP de um enlace no processo OSPF: ativando OSPF no enlace ou redistribuindo o endereço IP das interfaces conectadas. Ao ativarmos OSPF no enlace, via comando network do processo OSPF, o prefixo IP da interface é inserido no OSPF como Intra-Área e pode ser sumarizado para outras áreas, sendo tratado como Inter-Área. Se for utilizada redistribuição via comando redistribute connected do processo OSPF, o prefixo IP é inserido como um prefixo externo, tendo menos prioridade no processo de escolha de caminhos, conforme apresentado anteriormente. Caso o Engenheiro de Rede queira usar o comando network em vez de redistribute, esse OSPF Avançado

pode fazê-lo, mas essa abordagem pode trazer desvantagens. Observe a figura 3.6

86

(arquivo adr9-cap3-interfaces_passivas.imn).

Área 2 R2

R4

R1

Área Backbone

eth1

10.0.0.0/24

Internet

eth0

R3

Área 1

Na topologia da figura 3.6, o roteador OSPF R1 está conectado à Área Backbone, e uma das suas interfaces conecta usuários da empresa. Essa interface com usuários não possui roteadores, somente dispositivos dos usuários, como computadores, tablets, smartphones, impressoras, dispositivos Wi-Fi, entre outros. Esse segmento de rede precisa ser anunciado por R1 para os demais roteadores OSPF; caso contrário, eles não serão alcançados. Até então, a opção mais comum era redistribuir o endereço daquele segmento no processo OSPF. Ao ser redistribuído, o prefixo seria tratado como um prefixo externo. Caso o Engenheiro de Redes decida não redistribuir e habilite a interface no OSPF com o comando network, esse segmento de rede passaria a receber mensagens Hello a cada 10 segundos de R1. Além disso, caso algum dos usuários deseje agir maliciosamente, ele pode instalar um roteador OSPF no segmento, que poderia estabelecer adjacência com R1 e maliciosamente controlar e injetar prefixos que podem comprometer a instabilidade da rede. Mesmo que o Engenheiro de redes habilite MD5, o usuário malicioso pode ficar tentando quebrar a senha por tentativa e erro. É para essas situações que o recurso de Interfaces Passivas, ou Passive Interfaces, existe. Ao criar Interfaces Passivas, o roteador OSPF considera a interface como parte do OSPF, mas não tenta criar adjacências. Dessa maneira, o Engenheiro de Rede passa a ter mais controle e flexibilidade na administração da rede. Para fazer uso de Interfaces Passivas, os passos a seguir são utilizados: router ospf ! Habilite a interface da maneira tradicional com comando network network IP area Área ! Transforme em interface passiva passive-interface Nome_Interface


Figura 3.6 Interfaces Passivas.

87

Para transformar uma interface em passiva, basta utilizar o comando a seguir:

q

router ospf ! Habilite a interface da maneira tradicional com comando network network IP area Área ! Transforme em interface passiva passive-interface Nome_Interface

Por exemplo, considerando o roteador R1 da figura 3.6: router ospf ! Interface eth1 tem IP 11.0.0.1/24 network 11.0.0.0/24 area 0 ! Transforma em interface passiva passive-interface eth1

A partir desse comando, o prefixo IP da interface eth1 fará parte do LSDB e será visto como Intra-Área pelos demais roteadores OSPF da Área Backbone. Porém, pacotes Hello não serão enviados. Observe na saída a seguir do roteador R1, em vermelho, a informação de interface passiva. R1# show ip ospf interface eth1 eth1 is up ifindex 1424, MTU 1500 bytes, BW 0 Kbit Internet Address 11.0.0.1/24, Area 0.0.0.0 MTU mismatch detection:enabled Router ID 10.0.0.4, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 10.0.0.4, Interface Address 11.0.0.1 No backup designated router on this network Multicast group memberships: Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5 No Hellos (Passive interface) Neighbor Count is 0, Adjacent neighbor count is 0

Atualmente existem roteadores com dezenas ou mesmo centenas de interfaces. Caso deseje, o Engenheiro de Rede pode fazer uso dos comandos a seguir, usando R1 da figura 3.6 como exemplo. router ospf ! Transforma todas as interfaces em passivas passive-interface default ! Transforma interface eth0 em ativa no passive-interface eth0 network 0.0.0.0/0 area 0.0.0.0

Com o comando passive-interface default, todas as interfaces do roteador R1 que estão inclu OSPF Avançado

ídas pelo comando network passam a fazer parte do processo OSPF; porém, apenas eth0

88

poderá formar adjacências com outros roteadores.

É possível transformar todas as interfaces do roteador em passivas com um único comando.

q

router ospf ! Transforma todas as interfaces em passivas passive-interface default ! Transforma interface eth0 em ativa no passive-interface eth0 network 0.0.0.0/0 area 0.0.0.0

Rotas padrão 11 Rota padrão ou default route é um recurso útil para economia de recursos

q

dos roteadores. 11 Gerado pelos ABRs em áreas Stub quando o comando no-summary é inserido. 11 Útil quando existe apenas um roteador de saída do Sistema Autônomo. 11 Pode ser gerada pelo processo OSPF. 22 LSA AS-External. A rota padrão, ou default route, é um recurso extremamente útíl nas redes de computadores. Através dessa rota, todos os destinos podem ser alcançados, economizando recursos dos roteadores, mesmo que não seja a solução mais otimizada. Foram apresentadas situações na sessão 2, onde roteadores ABR geravam rotas padrão dentro de Áreas Stub e NSSA, quando o comando a seguir era inserido: route ospf area AREA stub no-summary

O comando no-summary, no ABR, serve para forçar o roteador ABR a filtrar mais LSAs do tipo Summary, além dos LSAs externos já bloqueados por padrão na área Stub. Como os roteadores internos não têm informação dos prefixos externos, o roteador ABR então gera uma rota padrão e envia via LSA Summary para os roteadores internos. Alguns fabricantes chamam esse tipo de área de Totally Stub ou Totally NSSA. Porém, há casos onde a rota padrão deve ser gerada para as outras áreas, informando alter-


nativas de saída. Observe a figura 3.7 (arquivo adr9-cap3-rota_padrao.imn).

89

R2

R4

R1

Área Backbone 10.0.0.0/24

Internet

R3 R6

R5 Área 1 Stub

Figura 3.7 Rota Padrão.

No Sistema Autônomo da figura 3.7, o roteador R4 faz parte da Área Backbone e possui BGP para acesso à internet. Nenhum outro roteador tem BGP configurado, apenas OSPF. Observe a configuração do roteador R4: ! Processo BGP. Anuncia prefixo 10.0.0.0/8 para o Sistema Autônomo remoto router bgp 4 bgp router-id 11.0.0.4 network 10.0.0.0/8 neighbor 11.0.0.1 remote-as 555 !

OSPF Avançado

router ospf ospf router-id 4.4.4.4 network 4.4.4.4/32 area 0.0.0.0 network 10.2.4.0/24 area 0.0.0.0 network 10.3.4.0/24 area 0.0.0.0 ! Origina LSA AS-External com a Rota padrão default-information originate !

90

11 Na topologia da figura 3.7, há apenas um roteador BGP e uma saída;

q

11 Roteadores OSPF precisam de informações para enviar pacotes para fora do Sistema Autônomo; 11 O roteador R4 pode redistribuir prefixos BGP ou originar uma rota padrão para os demais roteadores OSPF. Através da figura 3.7 e das configurações do roteador R4, é possível confirmar que há apenas um roteador BGP. Para que os usuários conectados aos roteadores R1, R2, R5 e R6 tenham acesso à internet, o roteador R4 teria duas possibilidades: 11 Redistribuir os prefixos BGP dentro do processo OSPF; 11 Gerar uma rota padrão para os demais roteadores OSPF. Não é recomendado redistribuir prefixos BGP dentro do OSPF, pois, na maioria das vezes, a quantidade de prefixos BGP é muito grande a ponto de comprometer o processo OSPF. Atualmente, a tabela BGP global possui mais de 500 mil prefixos, e não é interessante que estes sejam redistribuídos no processo OSPF. Então, a solução com rota padrão se mostra mais interessante. O roteador pode originar uma rota padrão no processo OSPF com o seguinte comando: router ospf default-information originate [always] [metric METRICA] [metric-type 1|2]

Comando a seguir pode ser utilizado para gerar a rota padrão:

q

router ospf default-information originate [always] [metric METRICA] [metric-type 1|2]

LSA AS-External é gerado: filtrado no ABR da Área 1. Com esse comando, o processo OSPF pode gerar um LSA AS-External com a rota padrão, desde que esteja na sua tabela de rotas. No caso da topologia da figura 3.7, a rota padrão em R4 foi recebida via BGP do Sistema Autônomo remoto. Observe a saída a seguir: R4# show ip route bgp Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route

Rota BGP em R4: R4# show ip route bgp B>* 0.0.0.0/0 [20/0] via 11.0.0.1, eth0, 00:11:20

Rota OSPF em R1: R1# show ip route O>* 0.0.0.0/0 [110/10] via 10.1.3.3, eth0, 00:28:30 * via 10.1.2.2, eth1, 00:28:30

q


B>* 0.0.0.0/0 [20/0] via 11.0.0.1, eth0, 00:11:20

91

Parâmetros opcionais:

q

11 always: origina a rota padrão, mesmo que não exista uma no roteador; 11 metric-type: define o tipo de métrica para o LSA AS-External: tipo 1 ou 2. O tipo padrão é 2; 11 metrica: define o custo da rota. O custo padrão é 10. De posse da rota padrão recebida do AS remoto, mais o comando default-information originate, o roteador R4 gera o LSA AS-External, conforme pode ser visto em R1: R1# show ip ospf database external OSPF Router with ID (1.1.1.1) AS External Link States LS age: 799 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 0.0.0.0 (External Network Number) Advertising Router: 4.4.4.4 LS Seq Number: 80000003 Checksum: 0xcaeb Length: 36 Network Mask: /0 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 10 Forward Address: 0.0.0.0 External Route Tag: 0

Após receber esse LSA, o roteador R1 instala uma rota padrão e, partir desse momento, todos os usuários conectados ao roteador R1 passam a ter acesso ao Sistema Autônomo remoto, e mesmo à internet. O comando default-information originate possui alguns parâmetros opcionais: 11 always: origina a rota padrão, mesmo que não exista uma no roteador; 11 metric-type: define o tipo de métrica para o LSA AS-External: tipo 1 ou 2. O tipo padrão é 2; 11 metrica: define o custo da rota. O custo padrão é 10.

Filtrando prefixos 11 Filtragem de prefixos são necessárias para customizar a manipulação de prefixos na rede OSPF; 11 Engenheiro de redes pode decidir por não enviar prefixos entre áreas – ou mesmo não instalar rotas de acordo com as necessidades locais;

OSPF Avançado

11 Diversas ferramentas estão à disposição no Quagga:

92

22 Lista de Controle de Acesso ou ACL; 22 Lista de Prefixos; 22 Lista de Distribuição; 22 Mapas de Rotas.

q

Filtragem de prefixos faz parte de qualquer protocolo de roteamento. Seja por questões de segurança, isolamento ou escalabilidade, todos os protocolos de roteamento implementam opções que permitem ao engenheiro de rede fazer ajustes finos. No curso Protocolos de Roteamento IP, o conceito e exemplos de mapas de rotas foram apresentados com focos em BGP. Nesta sessão, diversas abordagens de filtros, intra e inter-domínio serão apresentadas, inclusive mapas de rotas. Porém, antes, uma introdução será feita sobre as ferramentas disponíveis no Quagga.

Lista de Controle de Acesso (Access Control List: ACL) 11 Listas de Controle de Acesso (ou ACL) são utilizadas normalmente para filtragem de

q

pacotes de usuários; 11 Também servem para marcar prefixos antes da tomada de ação pelo roteador; 11 Não permite remoção de apenas uma entrada ou reordenamento; 11 Podem ser configuradas de três maneiras diferentes: 22 ACL Padrão: numeradas com valores 1-99 e 1300-1999: access-list NÚMERO (deny|permit) (A.B.C.D|Any) [Wildcard] 22 ACL Extendida: números possíveis: 100-199 e 2000-2699: access-list NÚMERO (deny|permit) ip A.B.C.D Wildcard (Any|A.B.C.D Wildcard) 22 ACL baseada em Nomes: access-list NOME (deny|permit) A.B.C.D/M [exact-match] Listas de Controle de Acesso, ou ACLs, são utilizadas com grande frequência para filtragem de pacotes de usuários nas interfaces. No âmbito do OSPF, ACL são utilizadas para especificar prefixos a serem selecionados. Possibilidades de configuração no Quagga: ! ACL Padrão: Números 1-99 e 1300-1999 access-list NÚMERO (deny|permit) (A.B.C.D|Any) [Wildcard] ! ACL Extendida: Números possíveis 100-199 e 2000-2699 access-list NÚMERO (deny|permit) ip A.B.C.D Wildcard (Any|A.B.C.D Wildcard) ! ACL baseada em Nomes access-list NOME (deny|permit) A.B.C.D/M [exact-match]

Existem outras combinações possíveis; porém, para o OSPF, essas são as mais utilizadas. ACLs não possuem a possibilidade de remover apenas uma entrada; logo, se uma entrada for removida, toda a ACL será removida. A mesma limitação se aplica a ordenamento ou sequen-

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

q


ciamento: uma vez criada, a única possibilidade para mudar a sequência é recriando a ACL.

93

Lista de prefixos foi criada para facilitar a seleção de prefixos, uma vez que cada entrada possui um número de sequência, além das extensões le (menor-igual) e ge (maior-igual), muito úteis para seleções mais específicas. ip prefix-list NOME seq (deny|permit) A.B.C.D/M [ge <0-32>] [le <0-32>]

Existem outras combinações possíveis; porém, no âmbito desse material, esses parâmetros são suficientes.

Listas de Distribuição (Distributed Lists) 11 Listas de Distribuição permitem que filtragens de entrada e saída sejam aplicadas por

q

interface e por protocolo de roteamento. 11 Mesmo pacotes gerados pelo roteador podem ser filtrados. 11 Utiliza ACL para selecionar os prefixos a serem filtrados ou liberados. 11 Podem ser configuradas da seguinte maneira: 22 distribute-list (Número ACL | Nome ACL) (in|out) Listas de Distribuição é outra possibilidade para implementar controles de prefixos, e foi criada para superar algumas limitações existentes nas ACLs. ACLs não filtram pacotes originados pelo próprio roteador, além de ser aplicadas por interface. Listas de Distribuição não possuem essas limitações, sendo utilizados para fazer seleções e restrições nas distribuições de prefixos por interface e por processo de roteamento. Listas de Distribuição usam ACLs para filtrar os prefixos desejados. Os usos mais comuns são: distribute-list (Número ACL | Nome ACL) (in|out)

Mapas de Rotas (Route-Maps) 11 Mapa de Rotas é um ferramenta extremamente poderosa para não só selecionar prefixos, mas também executar edições ou ações. 11 Possui diversos tipos de filtragem, através do comando match. 11 Possui diversos tipos de edições, através do comando set. 11 Possui número de sequência para fácil ordenamento e remoção. 11 Pode ser configurado da seguinte maneira: 22 Para criar um mapa de rotas com nome NOME e número de sequência: 33 route-map NOME (deny|permit) 22 Para buscar por prefixos especificados pela ACL (nome ou número): 33 match ip address 22 Para buscar pelo tag do LSA AS-External ou NSSA: 33 match tag

OSPF Avançado

22 Para configurar o custo com VALOR específico:

94

33 set metric 22 Para configurar o LSA AS-External ou NSSA com tipo específico: 33 set metric-type 22 Para colocar uma tag no LSA AS-External ou NSSA: 33 set tag

q

Mapa de Rota foi criado para utilizar ACL e Listas de Prefixos para não apenas filtrar prefixos, mas também executar mudanças nos prefixos selecionados. A utilização foi apresentada no curso Protocolos de Roteamento IP, porém os comandos mais comuns para se usar com OSPF estão relacionados a seguir: ! Cria um mapa de rotas com nome NOME e número de sequência route-map NOME (deny|permit) ! Procura por prefixos específicados pela ACL (nome ou número) match ip address ! Procura pelo tag do LSA AS-External ou NSSA match tag ! Configura métrica com VALOR específico set metric ! Configura LSA AS-External ou NSSA com tipo específico set metric-type ! Coloca uma tag no LSA AS-External ou NSSA set tag

De posse das ferramentas de filtragem, algumas aplicações serão apresentadas para facilitar o entendimento de possíveis aplicações. A topologia da figura 3.8 será utilizada para exemplificar essas possibilidades (arquivo adr9-cap3-filtragem.imn).

Figura 3.8 Filtragens de Prefixos.

R7

R3

Área 1 R1

R8

R6 Área Backbone

R2

R5

R4

R9


Internet

10.0.0.0/24

95

A topologia da figura 3.8 é composta por duas Áreas OSPF: Área Backbone e Área 1. A Área 1 foi criada para isolar a topologia do Datacenter, com diversos racks de servidores e um roteador OSPF por rack. Os roteadores OSPF internos da Área 1 possuem várias conexões para aumentar a performance. Dentro da Área 1 existem dois prefixos: 11 11.0.0.0/16: IPs dos servidores que são acessados pela internet; 11 11.1.0.0/16: IPs dos servidors internos sem acesso fora da Área 1. Como os roteadores OSPF internos (R3, R4, R5, R6 e R7) são responsáveis pelo roteamento de ambos os prefixos, por padrão, todos os prefixos estão sendo divulgados pelos ABRs R1 e R2 para a Área Backbone. Observe a tabela de rotas do roteador R8: R8# show ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route O

0.0.0.0/0 [110/10] via 10.8.9.9, eth1, 00:06:09

O>* 9.9.9.9/32 [110/20] via 10.8.9.9, eth1, 00:08:12 O>* 10.1.2.0/24 [110/20] via 10.1.8.1, eth0, 00:08:07 O>* 10.1.3.0/24 [110/20] via 10.1.8.1, eth0, 00:08:07 O

10.1.8.0/24 [110/10] is directly connected, eth0, 00:08:56

O>* 10.2.4.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06 *

via 10.8.9.9, eth1, 00:08:06

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

via 10.8.9.9, eth1, 00:08:06

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

via 10.8.9.9, eth1, 00:08:06

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

via 10.8.9.9, eth1, 00:08:06 10.8.9.0/24 [110/10] is directly connected, eth1, 00:08:56

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

via 10.8.9.9, eth1, 00:08:06

O>* 11.1.22.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06 O>* 11.1.24.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06 O>* 11.1.26.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06

OSPF Avançado

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

96

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

via 10.8.9.9, eth1, 00:08:06

Mesmo com a instrução de que os prefixos da rede 11.1.0.0/16 não deveriam ser

q

acessados fora da Área 1, roteador R8 possui rotas para tais prefixos. O>* 11.0.21.0/24 [110/30] via 10.1.8.1, eth0, 00:08:06 O>* 11.0.23.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06 O>* 11.0.25.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06 O>* 11.0.27.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06 O>* 11.0.29.0/24 [110/40] via 10.1.8.1, eth0, 00:08:06 *

via 10.8.9.9, eth1, 00:08:06


via 10.8.9.9, eth1, 00:08:06

Isso acontece porque a configuração padrão do OSPF é distribuir os prefixos entre áreas OSPF. Observe que, pela multiplicidade de conexões, vários prefixos podem ser acessados por mais de um caminho usando ECMP.

Filtragem de prefixos Inter-Áreas OSPF Pela saída da tabela de rotas de R8, é possível ver que os sub-prefixos do prefixo 11.1.0.0/16 estão acessíveis, mas, segundo a definição anterior, esses prefixos não deveriam ser vistos fora da Área 1. Nesse caso, como o padrão do OSPF é redistribuir os prefixos entre áreas, o engenheiro de redes precisa agir para não permitir essa distribuição, mas ainda assim tendo esse prefixo sendo roteado na Área 1. No tópico Sumarização de Rotas, foi apresentado o comando range, que permite a criação de agregação entre áreas. Além de agregar e anunciar, o mesmo comando permite que, em vez de gerar o LSA do tipo Summary para fazer o anúncio, permite bloquear todos os prefixos do range. Observe o comando a seguir: router ospf area 1 range 11.1.0.0/16 not-advertise

Com esse comando, os roteadores ABR R1 e R2 não vão criar os LSAs do tipo Summary para nenhum prefixo incluso no range 11.1.0.0/16. Observe que na tabela de rotas do roteador R8

R8# sh ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route O>* 9.9.9.9/32 [110/20] via 10.8.9.9, eth1, 00:03:56 O>* 10.1.2.0/24 [110/20] via 10.1.8.1, eth0, 00:03:45 O>* 10.1.3.0/24 [110/20] via 10.1.8.1, eth0, 00:03:45 O

10.1.8.0/24 [110/10] is directly connected, eth0, 00:04:40

O>* 10.2.4.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45 *

via 10.8.9.9, eth1, 00:03:45


não há mais rotas para os prefixos 11.1.0.0/16.

97

O>* 10.2.9.0/24 [110/20] via 10.8.9.9, eth1, 00:03:56 O>* 10.3.4.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45 O>* 10.3.5.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45 O>* 10.3.6.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45 O>* 10.3.7.0/24 [110/30] via 10.1.8.1, eth0, 00:03:45 O>* 10.4.5.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45 *

via 10.8.9.9, eth1, 00:03:45

O>* 10.4.6.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45 *

via 10.8.9.9, eth1, 00:03:45

O>* 10.4.7.0/24 [110/40] via 10.1.8.1, eth0, 00:03:45 * O

via 10.8.9.9, eth1, 00:03:45 10.8.9.0/24 [110/10] is directly connected, eth1, 00:04:40


via 10.8.9.9, eth1, 00:03:45

O comando range apresentado anteriormente possui uma opção que faz o inverso: em

q

vez de criar um LSA Summary para o prefixo explicitado, passa a não gerar LSAs do tipo Summary para os LSA Routers inclusos no prefixo explicitado. router ospf area 1 range 11.1.0.0/16 not-advertise

Com esse comando, roteadores R8 e R9 não terão conhecimento do prefixo 11.1.0.0/16 Outra possibilidade de fazer o mesmo bloqueio é possível com Listas de Prefixos. Vamos remover o comando range de ambos R1 e R2. router ospf no area 0.0.0.1 range 11.1.0.0/16 not-advertise

É possível fazer o mesmo filtro com Lista de Prefixos.

q

ip prefix-list Datacenter-11.1 deny 11.1.0.0/16 le 32 ip prefix-list Datacenter-11.1 permit any router ospf area 1 filter-list prefix Datacenter-11.1 out

Lista de Prefixos permite que apenas uma lista tenha diversos prefixos IP distintos, evitando ter de aplicar múltiplos comandos range. Agora, em ambos R1 e R2 vamos criar uma Lista de Prefixos que inclua todos os prefixos do

OSPF Avançado

range 11.1.0.0/16: ip prefix-list Datacenter-11.1 deny 11.1.0.0/16 le 32 ip prefix-list Datacenter-11.1 permit any

Essa Lista de Prefixos, chamada Datacenter-11.1, possui duas regras: a primeira rejeita o prefixo 11.1.0.0/16, incluindo prefixos menores até /32; a segunda regra permite todos os outros prefixos.

98

Agora, aplique a Lista de Prefixos no processo OSPF: router ospf area 1 filter-list prefix Datacenter-11.1 out

Ao observar o LSDB de R8, é possível observar o mesmo comportamento do comando range: R8# show ip ospf database OSPF Router with ID (8.8.8.8) Link ID

ADV Router

Age

11.1.22.0

10.2.4.2

3600 0x80000001 0x7793 11.1.22.0/24

Seq#

CkSum

Route

11.1.24.0

10.2.4.2

3600 0x80000001 0x61a7 11.1.24.0/24

11.1.26.0

10.2.4.2

3600 0x80000001 0x4bbb 11.1.26.0/24

11.1.28.0

10.2.4.2

3600 0x80000001 0x35cf 11.1.28.0/24

11.1.30.0

10.2.4.2

3600 0x80000001 0xba52 11.1.30.0/24

O comando range e a Lista de Prefixos, após serem aplicados, criam LSAs do Tipo

q

Summary solicitando a remoção do prefixo. Observe o LSDB de R8: Link ID

ADV Router

Age

11.1.22.0

10.2.4.2

3600 0x80000001 0x7793 11.1.22.0/24

Seq#

CkSum

Route

11.1.24.0

10.2.4.2

3600 0x80000001 0x61a7 11.1.24.0/24

11.1.26.0

10.2.4.2

3600 0x80000001 0x4bbb 11.1.26.0/24

11.1.28.0

10.2.4.2

3600 0x80000001 0x35cf 11.1.28.0/24

11.1.30.0

10.2.4.2

3600 0x80000001 0xba52 11.1.30.0/24

Todos os LSAs possuem Age 3600, que significa que devem ser removidos. Observe que o campo “Age” foi configurado com MaxAge nos LSAs do tipo Summary, forçando os demais roteadores OSPF a removerem os prefixos inclusos na Lista de Prefixos dos seus LSDBs. Com a configuração atual, a Área Backbone não possui mais rotas para a rede 11.1.0.0/16, conforme especificado no início do texto.

Filtragem de prefixos Intra-Área OSPF Após a aplicação dos comandos range ou/e filter-list em R1 e R2, foi possível confirmar que nenhum roteador fora da Área 1 tinha informações que o prefixo 11.1.0.0/16 estava na Área 1. Porém, e se forem conectados aos roteadores R1 ou R2 novas redes, com usuários, por exemplo? Apesar de não anunciar para a Área Backbone, como R1 e R2 ainda fazem

R1# sh ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route O>* 8.8.8.8/32 [110/20] via 10.1.8.8, eth2, 23:33:22 O>* 9.9.9.9/32 [110/30] via 10.1.2.2, eth1, 23:33:22 * via 10.1.8.8, eth2, 23:33:22 O 10.1.2.0/24 [110/10] is directly connected, eth1, 23:34:13 O 10.1.3.0/24 [110/10] is directly connected, eth0, 23:34:13 O 10.1.8.0/24 [110/10] is directly connected, eth2, 23:34:13 O>* 10.2.4.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 10.2.9.0/24 [110/20] via 10.1.2.2, eth1, 23:33:22


parte da Área 1, estes possuem rotas para o prefixo 11.1.0.0/16:

99

O>* 10.3.4.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27 O>* 10.3.5.0/24 [110/20] via 10.1.3.3, eth0, 23:33:22 O>* 10.3.6.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27 O>* 10.3.7.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27 O>* 10.4.5.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 10.4.6.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 10.4.7.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 10.8.9.0/24 [110/20] via 10.1.8.8, eth2, 23:33:22 O>* 11.0.21.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27 O>* 11.0.23.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 11.0.25.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 11.0.27.0/24 [110/30] via 10.1.3.3, eth0, 23:33:22 O>* 11.0.29.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 11.1.22.0/24 [110/20] via 10.1.3.3, eth0, 23:33:27 O>* 11.1.24.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 11.1.26.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27 O>* 11.1.28.0/24 [110/30] via 10.1.3.3, eth0, 23:33:22 O>* 11.1.30.0/24 [110/30] via 10.1.3.3, eth0, 23:33:27

R1 e R2 nessa topologia não precisam saber desse prefixo, pois em caso de conexão nova com R1 ou R2, os servidores da rede 11.1.0.0/16 seriam acessíveis. Para evitar esse tipo de situação, bloqueios Intra-Área devem ser utilizados. Uma maneira de impedir que R1 e R2 tenham rotas para os prefixos da rede 11.1.0.0/16 é impedir que o processo OSPF instale rotas para o prefixo 11.1.0.0/16 na tabela de rotas. No Quagga, a maneira mais simples de se implementar essa restrição é usando o comando ip protocol a seguir, juntamente com Mapas de Rotas. Primeiramente, verifique a Lista de Prefixos criada anteriormente: ip prefix-list Datacenter-11.1 seq 5 deny 11.1.0.0/16 le 32 ip prefix-list Datacenter-11.1 seq 10 permit any

Essa Lista de Prefixos rejeita todos os prefixos da rede 11.1.0.0 dos prefixos /16 até prefixos /32. Segundo, crie um Mapa de Rotas que inclua essa Lista de Prefixos: route-map Rejeita_Datacenter permit 5 match ip address prefix-list Datacenter-11.1

Terceiro, aplique o Mapa de Rotas no protocolo OSPF: ip protocol ospf route-map Rejeita_Datacenter

Observe o que foi feito: o roteador OSPF vai criar adjacências com outros roteadores OSPF, no caso, R1 e R2 criarão adjacências com R3 e R4, respectivamente. Ao receberem os prefixos, estes serão instalados no LSDB, após todo o processo de sincronização apresen-

OSPF Avançado

tado na sessão 1. Após a sincronização, o roteador vai verificar quais rotas OSPF devem ser

100

instaladas na tabela de rotas. Como há um Mapa de Rotas configurado, apenas os prefixos permitidos pela Lista de Prefixos serão aceitos. Observe a tabela de rotas do roteador R2: R2# sh ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, o - OSPF6, I - IS-IS, B - BGP, A - Babel,

> - selected route, * - FIB route O>* 8.8.8.8/32 [110/30] via 10.1.2.1, eth1, 1d00h15m * via 10.2.9.9, eth2, 1d00h15m O>* 9.9.9.9/32 [110/20] via 10.2.9.9, eth2, 1d00h15m O 10.1.2.0/24 [110/10] is directly connected, eth1, 1d00h16m C>* 10.1.2.0/24 is directly connected, eth1 O>* 10.1.3.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 10.1.8.0/24 [110/20] via 10.1.2.1, eth1, 1d00h15m O 10.2.4.0/24 [110/10] is directly connected, eth0, 00:09:12 C>* 10.2.4.0/24 is directly connected, eth0 O 10.2.9.0/24 [110/10] is directly connected, eth2, 1d00h16m C>* 10.2.9.0/24 is directly connected, eth2 O>* 10.3.4.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03 O>* 10.3.5.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 10.3.6.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 10.3.7.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 10.4.5.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03 O>* 10.4.6.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03 O>* 10.4.7.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03 O>* 10.8.9.0/24 [110/20] via 10.2.9.9, eth2, 1d00h15m O>* 11.0.21.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 11.0.23.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 11.0.25.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 11.0.27.0/24 [110/30] via 10.2.4.4, eth0, 00:09:03 O>* 11.0.29.0/24 [110/20] via 10.2.4.4, eth0, 00:09:03 O 11.1.22.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03 O 11.1.24.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03 O 11.1.26.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03 O 11.1.28.0/24 [110/30] via 10.2.4.4, eth0 inactive, 00:09:03 O 11.1.30.0/24 [110/20] via 10.2.4.4, eth0 inactive, 00:09:03

Se o comando for aplicado após o prefixo já estar inserido na tabela de rotas, o engenheiro de rede necessitará reestabelecer as adjacências OSPF, reiniciando o processo OSPF.

Observe no LSDB de R2 o LSA Router gerado por R4, por exemplo: R2# show ip ospf database router adv-router 10.3.4.4 OSPF Router with ID (10.2.4.2) Router Link States (Area 0.0.0.1) LS age: 754 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x0 LS Type: router-LSA Link State ID: 10.3.4.4 Advertising Router: 10.3.4.4 LS Seq Number: 80000018


Observe que os prefixos da rede 11.1.0.0/16 estão inativos; logo, não são alcançáveis.

101

Checksum: 0xe84c Length: 108 Number of Links: 7 Link connected to: a Transit Network (Link ID) Designated Router address: 10.3.4.4 (Link Data) Router Interface address: 10.3.4.4 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: a Transit Network (Link ID) Designated Router address: 10.4.5.5 (Link Data) Router Interface address: 10.4.5.4 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: a Transit Network (Link ID) Designated Router address: 10.4.6.6 (Link Data) Router Interface address: 10.4.6.4 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: a Transit Network (Link ID) Designated Router address: 10.4.7.7 (Link Data) Router Interface address: 10.4.7.4 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: a Transit Network (Link ID) Designated Router address: 10.2.4.4 (Link Data) Router Interface address: 10.2.4.4 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: 11.0.29.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: 11.1.30.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metric: 10

Observe que no último registro consta a rede 11.1.30.0/24. Lembre-se: o LSDB tem de ser o mesmo em todos os roteadores OSPF da Área. Nesse caso, filtramos apenas a instalação da rota na tabela de rotas, mas não a inserção do LSA no LSDB.

OSPF Avançado

Em alguns outros fabricantes, o comando OSPF distributed-list está disponível:

102

router ospf distributed-list prefix NOME_LISTA_PREFIXO in

A lógica é a mesma: apenas prefixos listados e permitidos na Lista de Prefixo NOME_LISTA_ PREFIXO serão instalados na tabela de roteamento.

q

Executando Filtragem de Prefixos Intra-Área: 1. Crie a Lista de Prefixo com o prefixo que não deve ser instalado: ip prefix-list Datacenter-11.1 seq 5 deny 11.1.0.0/16 le 32 ip prefix-list Datacenter-11.1 seq 10 permit any

2. Crie um Mapa de Rotas que inclua a Lista de Prefixo criada: route-map Rejeita_Datacenter permit 5 match ip address prefix-list Datacenter-11.1

3. Aplique o Mapa de Rotas no protocolo OSPF: ip protocol ospf route-map Rejeita_Datacenter

Agregação de LSAs AS-External Na sessão “Agregação de Rotas”, foi apresentado o comando OSPF summary-address para fazer agregação de LSAs do tipo AS-External. Porém, conforme apresentado, esse comando não é suportado pelo Quagga; então, a possibilidade usando Mapas de Rotas vai ser apresentada a seguir. Observe a figura 3.3, reproduzida novamente a seguir.

R4

External

Área Backbone

192.168.0.0/24

R2 R5 2.1

19

192.168.2.0/24

19

2.

31

R6

0/

.7.

68

192.168.1.0/24

16

8.

7.

2/

.7.4/31

1

19 2. 16 8. 7. 12 /3

. .) R10

R3


31

.6/

.7 168

.

192

192.168.3.0/24

192.168.6.0/24

ASBR

192.168

R7

(.

31

103

Na topologia da figura 3.1, o ASBR possui interfaces conectadas aos roteadores remotos R4 até R10 e uma rota estática para cada rede interna, conforme abaixo: router ospf ospf router-id 10.1.2.1 redistribute connected redistribute static network 10.1.2.0/24 area 0.0.0.0 network 10.1.3.0/24 area 0.0.0.0 ! ip route 192.168.0.0/24 192.168.7.1 ip route 192.168.1.0/24 192.168.7.3 ip route 192.168.2.0/24 192.168.7.5 ip route 192.168.3.0/24 192.168.7.7 ip route 192.168.4.0/24 192.168.7.9 ip route 192.168.5.0/24 192.168.7.11 ip route 192.168.6.0/24 192.168.7.13

Observe que as interfaces com R4 até R10 e as rotas estáticas estão sendo redistribuídas no OSPF. Para evitar que R2 e R3 criem 14 rotas apontando para o ASBR, podemos utilizar Mapas de Rotas para fazer a agregação. Os seguintes passos devem ser executados: Passo 1: crie a Lista de Prefixos: ip prefix-list FILTRA_192.168-20 seq 5 deny 192.168.0.0/16 ge 24 ip prefix-list FILTRA_192.168-20 seq 10 permit any

Essa Lista de Prefixos diz para verificar os primeiros 16 bits do prefixo (192.168) e rejeitar (deny) todos os prefixos com comprimento do prefixo maior ou igual a 24 (/24, /25, /26 etc.) Passo 2: crie um Mapa de Rotas com a Lista de Prefixo criada: route-map AGREGACAO permit 5 match ip address prefix-list FILTRA_192.168-20

Esse Mapa de Rotas vai permitir tudo que está na Lista de Prefixo FILTRA_192.168-20, ou seja, rejeitar prefixos com comprimento do prefixo maior que 24 e permitir o resto (any). Passo 3: crie uma rota estática para o endereço agregável: ip route 192.168.0.0/20 null0

Passo 4: aplicar o Mapa de Rotas no processo OSPF, fazendo a redistribuição de rotas estáticas: router ospf

OSPF Avançado

redistribute static route-map AGREGACAO

104

Passo 5: confirme o resultado nos demais roteadores da Área Backbone: R2# sh ip ospf database external OSPF Router with ID (10.1.2.2) AS External Link States LS age: 339 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: AS-external-LSA Link State ID: 192.168.0.0 (External Network Number) Advertising Router: 10.1.2.1 LS Seq Number: 80000003 Checksum: 0x3420 Length: 36 Network Mask: /20 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0

Apesar de requerer mais passos que o comando OSPF summary-address, o mesmo o bjetivo foi alcançado com rota estática, Lista de Prefixo e Mapa de Rotas. Usando Mapas de Rotas para fazer agregação de LSAs do tipo AS-External:

q

1. Crie a Lista de Prefixos: ip prefix-list FILTRA_192.168-20 seq 5 deny 192.168.0.0/16 ge 24 ip prefix-list FILTRA_192.168-20 seq 10 permit any

2. Crie um Mapa de Rotas com a Lista de Prefixos criada: route-map AGREGACAO permit 5 match ip address prefix-list FILTRA_192.168-20

3. Crie uma rota estática para o endereço agregável: ip route 192.168.0.0/20 null0

4. Aplique o Mapa de Rotas no processo OSPF, fazendo a redistribuição de rotas estáticas:

redistribute static route-map AGREGACAO

5. Confirme o resultado nos demais roteadores da Área Backbone: R2# sh ip ospf database external

Nesta sessão, o aluno teve contato com algumas técnicas de engenharia de tráfego que permitem a otimização do LSDB, aumenta a eficiência do processo de convergência e também agrega segurança e isolamento nas implementações OSPF. Na sessão de aprendizagem 4, o aluno terá a oportunidade de conhecer algumas técnicas e funcionalidades mais novas desenvolvidas pelo IETF para o protocolo OSPF, que agregam mais valor e escalabilidade a esse popular protocolo de roteamento dinâmico.


router ospf

105

Comandos OSPF A seguir, uma lista de comandos de configuração que foram apresentados na sessão de aprendizagem 3. Em destaque estão as palavras-chave. Os comandos a seguir são aplicados na sessão de OSPF do roteador. 11 Gera LSAs do tipo Summary na Área Backbone. Not-advertise filtra o LSA do tipo Summary: area NÚMERO_ÁREA range IP_A_SER_SUMARIZADO [cost métrica] [not-advertise]

11 Gera uma agregação de LSAs do tipo AS-External na rede OSPF: summary-address PREFIXO MÁSCARA [tag TAG]

11 Muda o custo de referência das interfaces OSPF: auto-cost reference-bandwidth <1-4294967>

11 Coloca uma interface no modo passivo do OSPF: passive-interface Nome_Interface

11 Coloca todas as interfaces do roteador no modo passivo do OSPF: passive-interface default

11 Origina uma rota padrão em uma área Stub e filtra todos os LSAs do tipo Summary: area AREA stub no-summary

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

11 Filtra LSAs do tipo Summary entre áreas: area NUMERO filter-list prefix NOME_LISTA_PREFIXO [in|out]

11 Filtra prefixos de anúncios recebidos: distribute-list prefix NOME_LISTA_PREFIXO in

Os comandos a seguir são aplicados na configuração das interfaces. 11 Altera o custo da interface no processo OSPF: ip ospf cost VALOR

Os comandos a seguir são aplicados no modo de configuração global do roteador. 11 Ativa um mapa de rotas no processo OSPF: ip protocol ospf route-map NOME_DO_MAPA

OSPF Avançado

11 Cria uma ACL padrão:

106

access-list NÚMERO (deny|permit) (A.B.C.D|Any) [Wildcard]

11 Cria uma ACL Extendida: access-list NÚMERO (deny|permit) ip A.B.C.D Wildcard (Any|A.B.C.D Wildcard) access-list NOME (deny|permit) A.B.C.D/M [exact-match]

11 Cria um Mapa de Rotas:

route-map NOME [permit|deny] NUMERO_SEQUÊNCIA

11 Cria uma Lista de Prefixos: Ip prefix-list NOME seq NÚMERO [permit|deny] A.B.C.D/M [ge <0-32>] [le <0-32>]

11 Procura por prefixos específicados pela ACL (nome ou número) em uma Mapa de Rotas: match ip address

11 Procura pelo tag do LSA AS-External ou NSSA no Mapa de Rotas: match tag

11 Configura métrica com VALOR específico no Mapa de Rotas: set metric

11 Configura LSA AS-External ou NSSA com tipo específico no Mapa de Rotas: set metric-type

11 Coloca uma tag no LSA AS-External ou NSSA no Mapa de Rotas:


set tag

107

108

OSPF Avançado

4 Conhecer novas tecnologias relacionadas ao OSPF; Apresentar exemplos práticos para consolidação dos novos tópicos; Entender a importância dessas tecnologias novas para os ambientes que usam OSPF.

Convergência: Bidirectional Forwarding Detection (BFD); Monitoramento: MIB 4750.

conceitos

Escalabilidade e Estabilidade: Incremental OSPF, Supressão de Prefixos, Graceful Restart;

Introdução Nas sessões anteriores, as RFCs 2328 e 3101 foram apresentadas e as configurações mais comuns disponíveis do protocolo OSPF nos roteadores atuais foram detalhadas. Diversos exemplos e topologias foram apresentados, com informação suficiente para o aluno ter a capacidade de configurar redes complexas e de grande escala. Porém, ao longo dos anos e com o advento de novos protocolos e tecnologias, novas funcionalidades foram propostas e algumas viraram padrões de fato via RFCs no IETF (Internet Engineering Task Force). Serviços como o transporte de voz e vídeo utilizando redes IP se consolidaram e passaram a exigir tempos de convergência menores, o que força uma detecção mais rápida de possíveis problemas de conectividade. Além disso, com redes cada vez maiores e mais roteadores OSPFs, os LSDBs ficaram cada vez maiores, consumindo mais recursos dos roteadores e comprometendo o tempo de convergência da rede. Esta sessão apresenta as tecnologias e propostas mais novas relacionadas ao protocolo OSPF e, sempre que possível, exemplos práticos serão apresentados para ajudar o aluno a consolidar os novos tópicos. Algumas das funcionalidades a serem apresentadas são tão recentes que muitos dos fornecedores ainda não as suportam, mas é importante os alunos saberem que existem opções para resolver problemas específicos relacionados a grandes ambientes de roteamento OSPF. Além disso, algumas tecnologias apresentadas são importantes para ambientes que usam o OSPF, como por exemplo, redes MPLS e Engenharia de Tráfego. Os principais assuntos a serem abordados nesta sessão estão relacionados às seguintes áreas: 11 Escalabilidade e Estabilidade: serão discutidos tópicos como Incremental OSPF, Supressão de Prefixos e Graceful Restart; 11 Convergência: será apresentado o protocolo Bidirectional Forwarding Detection (BFD); 11 Monitoramento: a MIB 4750 será detalhada.

Capítulo 4 - Otimização e tópicos avançados

objetivos

Otimização e tópicos avançados

109

Escalabilidade e Estabilidade do OSPF 11 Roteadores modernos possuem mais CPU e memória, porém as redes estão ficando

q

cada vez maiores. 11 Provedores atuais possuem mais roteadores e mais enlaces entre eles, aumentando o tamanho do LSDB. 11 É importante melhorar a escabilidade do OSPF para garantir uma rede estável. 11 Novas funcionalidades foram propostas ou melhoradas para extender a RFC 2328. A capacidade de suportar cada vez mais roteadores e prefixos de maneira estável determina a escalabilidade de um protocolo de roteamento. O protocolo OSPF foi planejado para suportar muitos roteadores e enlaces, porém, com a popularização das redes de computadores e o crescimento destas, os LSBDs acabaram ficando muito grandes. Mesmo com os roteadores mais novos possuindo mais capacidade de processamento e memória, algumas funcionalidades foram propostas para otimizar e acelerar o processo de convergência, além de aumentar a estabilidade da rede. As seguintes funcionalidades foram padronizadas para extender as capacidades da RFC 2328 (OSPF v2) e serão detalhadas ao longo da sessão de aprendizagem 4: 11 Incremental OSPF: permite que o OSPF reprocesse apenas parte do LSDB em casos

q

específicos de alteração na topologia da área OSPF; 11 Graceful Restart: permite que os pacotes continuem sendo encaminhados ao longo da reinicialização do processo OSPF; 11 BFD para OSPF: permite que o processo OSPF detecte mais rapidamente a queda dos roteadores vizinhos; 11 Supressão de Prefixos: permite a remoção dos prefixos das redes de trânsito do LSDB, diminuindo assim o seu tamanho; 11 MIB para OSPF: permite o monitoramento dos objetos OSPF, facilitando a operação da rede OSPF.

Incremental OSPF 11 Roteadores OSPF usam o algoritmo SPF para escolher o melhor caminho para cada

q

destino. 11 Após a escolha de todos os caminhos, a Shortest Path Tree (SPT) é calculada. 11 Uma vez calculada a SPT, só há o reprocessamento quando há alterações topológicas. 11 O SPF reprocessa TODO o LSDB em caso de alterações topológicas na Área OSPF, consumindo CPU e memória do roteador. 11 A figura 4.1 será utilizada para ilustrar a criação da SPT. No curso "Protocolos de Roteamento IP", o funcionamento do Algoritmo de Djisktra foi

OSPF Avançado

apresentado, mostrando como o protocolo OSPF faz a escolha dos caminhos. Inicialmente,

110

após a sincronização do LSDB (apresentada na sessão 1), cada roteador precisa definir sua Shortest Path Tree (SPT) com todos os destinos, avaliando os custos e caminhos disponibilizados pelos demais roteadores OSPF. Através da SPT, o roteador OSPF saberá como chegar em cada uma das redes disponíveis. A fim de ilustrar esse procedimento, observe a topologia da figura 4.1.

Rede 3

R1 Rede 1

R6 Rede 6

5

10

R3 10

Rede 2

10

15 15

R2

5

5

10 10

Rede 7

R5

R7 10

R8

10

Rede 8

10

R9

Rede 4

R10

Rede 10

R11

Rede 11

É possível observar que essa rede possui diversos enlaces e roteadores. Assumindo os custos informados nos enlaces, o roteador R6 iria executar o processo SPF (Shortest Path First) no seu LSDB para criar sua SPT (Shortest Path Tree) para alcançar todos os destinos. A figura 4.2. apresenta a SPT do ponto de vista de R6. 11 A topologia da figura 4.1. apresenta 11 roteadores, com diversos enlaces e custos;

q

11 Cada roteador cria sua própria SPT para chegar a todos os destinos; 11 A figura 4.2 mostra a SPT do ponto de vista de R6, utilizando as métricas (ou custos) informadas; Observe que não há loops na SPT.


Figura 4.1 Incremental OSPF.

R4

10

111

R6

R3 R1

Rede 1

R5

R7

R2

R11

R10

R4

Rede 2 R8

Rede 8

Rede 11

Rede 10 R9

Rede 9

Como era de se esperar, o roteador R6 calculou sua SPT sem loops, utilizando as métricas dos enlaces anunciados pelos demais roteadores. Suponha que as rotas sejam instaladas no roteador R6, e o enlace que liga o roteador R8 à Rede 8 mude de estado, de UP para DOWN. O roteador R8 vai então gerar um LSA Network para informar que a Rede 8 está indisponível (com LSA Age 3600 ou Métrica Infinita). Os demais roteadores OSPF vão repassar o LSA (via flooding) até que todos os roteadores OSPF estejam com o mesmo LSDB. Após terem o LSDB sincronizado, todos os roteadores vão executar o processo do SPF para recalcularem suas respectivas SPTs. Como o SPF processa todos os registros do LSDB, a árvore SPT teve de ser inteiramente recriada por causa de um prefixo IP que é uma folha da árvore SPT. Esse cálculo consome recursos de processamento e memória do roteador, e se depender da quantidade de prefixos e frequência com que esses prefixos oscilam, a CPU do roteador pode ficar bastante ocupada. Vimos na sessão 2 que esse problema poderia ser evitado com áreas OSPF, mas considere que a figura 4.2 já é uma Área OSPF de uma rede maior, pois muitas redes podem ter dezenas ou centenas de roteadores, milhares de prefixos sendo roteados pelo OSPF por área. 11 Supondo um problema entre R8 e Rede 8, R8 vai gerar um LSA Router informando a mudança de estado; OSPF Avançado

11 Todos os roteadores OSPF reprocessam o LSDB para criar novas SPTs;

112

11 Ao longo da recriação da SPT, recursos de CPU e memória serão utilizados; 11 Como a Rede 8 só tem ligação com R8, as SPTs vão permanecer as mesmas.

q

Figura 4.2 Roteader R6 e sua SPT.

Diante desse cenário, alguns fabricantes implementaram uma versão otimizada do algoritmo SPF sugerida na época da ARPANET. À época, foi sugerida uma modificação no algoritmo do SFP, chamado Incremental SFP (ISPF), propondo mudanças que afetem apenas as folhas ou pequenas sub-árvores da SPT, e não forçam o cálculo completo da SPT. Assim, economizam recursos computacionais dos roteadores. 11 Para evitar esse tipo de situação, uma mudança foi implementada no SPF:

q

o Incremental SPF (ISPF); 11 O ISPF propõe que mudanças que afetem apenas as folhas ou pequenas sub-árvores da SPT e não forcem o cálculo completo da SPT; 11 Recursos computacionais seriam economizados e o tempo de convergência pode ser otimizado; 11 Três propriedades se aplicam ao funcionamento do ISPF. O Incremental SFP consiste em três propriedades principais:

Propriedade 1 Se um roteador OSPF for adicionado ou removido da SPT e se caracterizar como um roteador "folha" da árvore, a SPT só precisa ser alterada para adicionar ou remover tal roteador "folha". O mesmo conceito se aplica às redes Não Trânsito, redes "terminais", ou Stub (como apresentado na sessão de aprendizagem 1), como por exemplo a Rede 8 utilizada como exemplo. A figura 4.3 possui um roteador (R12) e duas redes Stub adicionados. 11 Propriedade 1:

q

11 Se um roteador OSPF for adicionado ou removido da SPT e este se caracterizar como um roteador "folha" da árvore, a SPT só precisa ser alterada para adicionar ou remover tal roteador "folha" 11 Mesma regra para redes terminais, stub ou não-trânsito, como a "Rede 8" da figura 4.2 11 O processo SPF apenas adicionaria o novo roteador (ou nova rede Stub) sem recriar a SPT 11 Figura 4.3 ilustra a Propriedade 1


w

Leia o artigo “ARPANET Routing Algorithm Improvements”, em http://www.dtic.mil/ dtic/tr/fulltext/u2/ a086340.pdf

113

R6

R3

R5

R7

R2

R1

R11

R10

Rede 11B

Rede 1

R4

Rede 2

R9

R8

Rede 8

Rede 11

Rede 10

Rede 9

R12

Rede 12

Nesses casos, com o ISPF, o cálculo SPF seria feito apenas para adicionar o novo roteador e as novas redes adicionadas, não recalculando toda a SPT. Como não há necessidade de recalcular toda a SPT, o tempo de cálculo tende a ser menor. Para demonstrar os resultados, o cenário da figura 4.1 foi criado no arquivo (adr9-cap4-ispf.zip). Primeiramente, a interface Loopback do roteador 12 será desativada e o tempo de execução do recálculo da SPT em R6 será apresentado: R12#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R12(config)#interface lo0 R12(config-if)#shutdown R12(config-if)# *Mar 1 00:34:46.835: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down *Mar 1 00:34:47.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down

OSPF Avançado

Como a Interface Loopback0 foi desativada, o roteador R12 gerou um LSA Network que foi

114

propagado pela rede OSPF. Observe a saída a seguir. Nessa saída, o comando show ip ospf statistics detail foi utilizado. A linha em negrito e em vermelho mostra o tempo total, em milisegundos, necessário para computar a mudança recebida do roteador R12 (em negrito e azul).

Figura 4.3 ISPF e a Propriedade 1.

11 A saída a seguir mostra o tempo de execução do SPF caso a interface Loopback de

q

R12 seja desativada 11 Observe o tempo total de 12 ms, pois todos os LSAs foram reprocessados 11 Observe que o tipo de SPF é Full, ou seja, completo R6#sh ip ospf statistics detail (...) SPF 19 executed 00:00:20 ago, SPF type Full SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 8 12 0 0 0 0 0 12 RIB manipulation time (in msec): RIB Update RIB Delete 10 0 LSIDs processed R:12 N:15 Stub:11 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 12.12.12.12(R)

R6#sh ip ospf statistics detail (...) SPF 19 executed 00:00:20 ago, SPF type Full SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 8 12 0 0 0 0 0 12 RIB manipulation time (in msec): RIB Update RIB Delete 10 0 LSIDs processed R:12 N:15 Stub:11 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 12.12.12.12(R)

É possível observar que o roteador R6 levou 12 milisegundos para recriar a árvore SPT.

R6#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R6(config)#router ospf 10 R6(config-router)#ispf

Vamos confirmar se o comando foi aplicado: R6#sh ip ospf Routing Process "ospf 10" with ID 6.6.6.6 Start time: 00:04:02.648, Time elapsed: 00:34:07.856 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS)


Vamos agora habilitar o ISPF em R6:

Supports area transit capability

115

Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Incremental-SPF enabled Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0

Como o Incremental SPF está habilitado (enabled), vamos habilitar a interface Loopback0 do roteador 12 novamente e verificar o tempo necessário em R6: R6#sh ip ospf statistics detail SPF 21 executed 00:01:02 ago, SPF type Incremental SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 0 0 4 0 0 0 0 4 RIB manipulation time (in msec): RIB Update RIB Delete 0 0 LSIDs processed R:0 N:0 Stub:1 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 12.12.12.12(R)

Ao habilitarmos o ISPF com o comando a seguir, a mesma alteração do estado da Loopback de R12 consome 4 ms e apenas um LSA foi processado. R6#configure terminal R6(config)#router ospf 10 R6(config-router)#ispf

Observe que o tipo de SPF foi Incremental. R6#sh ip ospf statistics detail SPF 21 executed 00:01:02 ago, SPF type Incremental SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 0 0 4 0 0 0 0 4 RIB manipulation time (in msec): OSPF Avançado

RIB Update RIB Delete 0 0 LSIDs processed R:0 N:0 Stub:1 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 12.12.12.12(R)

116

q

Apenas a última execução do SPF executado foi mostrado (SPF 21). Nessa saída, é possível ver algumas informações interessantes: 11 SPF type Incremental: o tipo de cálculo SPF foi o incremental, e não o completo (Full); 11 Total 4: o tempo total utilizado pelo SPF foi de 4 milisegundos, três vezes mais rápido que o modo Full; 11 12.12.12.12(R): a mudança que forçou o SPF foi gerada pelo roteador R12 (Lo0: 12.12.12.12) e foi um LSA do tipo Router (R). Além disso, a saída mostra (Stub: 1). Como vimos na sessão 1, interfaces Loopback são chamadas de redes Stub (não confunda com Área Stub!). É possível ver que o ISPF diminuiu consideravelmente o tempo de processamento do SPF, de 12 para 4 milisegundos. Como é uma funcionalidade local, o ISPF não precisa ser habilitado em todos os roteadores OSPF, ou seja, é possível ter na mesma rede OSPF roteadores que suportam ISPF e roteadores que não suportam ISPF.

Propriedade 2 A propriedade 2 é relacionada com a alteração do estado do enlace que não é parte da SPT. Observe na figura 4.1 que há um enlace entre R2 e R4. Esse enlace não faz parte da SPT de R6, logo, se esse enlace tiver seu estado alterado, com ISPF habilitado o roteador R6 não vai precisar recalcular a SPT. 11 Propriedade 2

q

11 Relacionada com a alteração do estado do enlace que não é parte da SPT: se o enlace que tem o estado alterado para DOWN não faz parte da SPT, não há necessidade de recalculá-la 11 Observe o enlace entre R2 e R4 na figura 4.2. Como não faz parte da SPT de R6, R6 não precisa recalcular sua SPT Desativação da interface FastEthernet 0/1, que liga R2 com R4: R2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)#int f0/1 R2(config-if)# #Interface com R4 R2(config-if)# shutdown *Mar 1 00:48:59.291: %OSPF-5-ADJCHG: Process 10, Nbr 4.4.4.4 on FastEthernet0/1 R2(config-if)# *Mar 1 00:49:01.283: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down *Mar 1 00:49:02.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

R2-R4 alterado para DOWN. Tempo total do SPF com ISPF habilitado: R6#sh ip ospf statistics detail SPF 23 executed 00:00:16 ago, SPF type Incremental SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total

q


from FULL to DOWN, Neighbor Down: Interface down or detached

0 0 0 0 0 0 0 0

117

Tempo total com ISPF desabilitado:

q

R6#sh ip ospf statistics detail SPF 27 executed 00:00:36 ago, SPF type Full SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 8 8 0 0 0 0 0 8

11 Enquanto que sem ISPF todos os LSAs foram reprocessados e levou 8 ms, com ISPF apenas o LSA informado foi reprocessado, e como não faz parte da SPT, nem foi processado (tempo 0ms). 11 Lembre-se de que a SPT é por roteador. O enlace R2-R4 pode fazer parte da SPT de outro roteador e esse teve de calcular a SPT novamente.”. Observe que, com o ISPF habilitado, não há nenhum processamento da SPT (tempo total é 0): R6#sh ip ospf statistics detail SPF 23 executed 00:00:16 ago, SPF type Incremental SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 0 0 0 0 0 0 0 0 RIB manipulation time (in msec): RIB Update RIB Delete 0 0 LSIDs processed R:0 N:0 Stub:1 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 2.2.2.2(R)

Com o ISPF desabilitado, observe o que aconteceria: R6#sh ip ospf statistics detail SPF 27 executed 00:00:36 ago, SPF type Full SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 8 8 0 0 0 0 0 8 RIB manipulation time (in msec): RIB Update RIB Delete 7 0 LSIDs processed R:12 N:15 Stub:11 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 2.2.2.2(R)

OSPF Avançado

Fica evidente o benefício de usar ISPF nesse caso também, pois não há a necessidade de recalcular a SPT de R6. Lembre-se de que a SPT é por roteador, ou seja, cada roteador tem sua própria SPT para chegar aos demais destinos da rede. Logo, outros roteadores podem ter suas SPTs afetadas por causa da alteração do estado do enlace entre R2 e R4. Nesses casos, a SPT teria de ser recalculada. 118

Propriedade 3 Caso haja uma alteração em um enlace de trânsito que afete parte da SPT, apenas os caminhos para chegar aos roteadores pós-enlace afetado precisam ser recalculados. Por exemplo, considere que o enlace entre os roteadores R4 e R5 teve seu estado alterado para DOWN, conforme a figura 4.4.

q

11 Propriedade 3: 11 Caso haja uma alteração em um enlace de trânsito que afete parte da SPT, apenas os caminhos para chegar nos roteadores pós-enlace afetado precisam ser recalculados 11 Observe figura 4.4, onde o enlace R4-R5 ficou indisponível, afetando uma sub-árvore da SPT

R6

R3 R1

R5

R7

R2

R11

R10

Rede 11B

Rede 2

R8

Figura 4.4 ISPF Propriedade 3.

Rede 8

Rede 11

Rede 10

R4

R9

Rede 9

R12

Rede 12

“Os roteadores R4, R8, R9 e R12, os enlaces R4-R5, R4-R8, R4-R9, R9-R12 e as redes "Rede 8", "Rede 9"e "Rede 12" foram os únicos afetados pela alteração do estado do enlace R4-R5. Nesse caso, com ISPF, apenas esta sub-árvore precisaria ser reconstruída, e não toda a SPT. Observe o cálculo do SPF sem ISPF habilitado em R6:”


Rede 1

119

R6#sh ip ospf statistics detail SPF 31 executed 00:00:11 ago, SPF type Full SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 12 16 0 0 0 0 0 16 RIB manipulation time (in msec): RIB Update RIB Delete 4 0 LSIDs processed R:12 N:15 Stub:12 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 4.4.4.4(R)

Observe o cálculo do SPF com o ISPF habilitado em R6: R6#sh ip ospf statistics detail SPF 36 executed 00:00:13 ago, SPF type Incremental SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 4 8 0 0 0 0 0 8 RIB manipulation time (in msec): RIB Update RIB Delete 0 0 LSIDs processed R:4 N:4 Stub:4 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 4.4.4.4(R)

O tempo de processamento caiu pela metade (16 sem ISPF, 8 com ISPF) e a quantidade de enlaces afetados saiu de 12 para 4, o que justifica o uso do ISPF. 11 Nesta situação, os roteadores R4, R8, R9 e R12, os enlaces R4-R5, R4-R8, R4-R9, R9-R12 e as redes "Rede 8", "Rede 9"e "Rede 12" foram os únicos afetados pela alteração do estado do enlace R4-R5 11 Apenas esta sub-árvore precisaria ser reconstruída, e não toda a SPT 11 Observe o cálculo do SPF sem ISPF habilitado em R6: Observe o cálculo do SPF sem ISPF habilitado em R6: R6#sh ip ospf statistics detail SPF 31 executed 00:00:11 ago, SPF type Full SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 12 16 0 0 0 0 0 16 RIB manipulation time (in msec): OSPF Avançado

RIB Update RIB Delete 4 0 LSIDs processed R:12 N:15 Stub:12 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 4.4.4.4(R)

120

q

Observe o cálculo do SPF com o ISPF habilitado em R6:

q

R6#sh ip ospf statistics detail SPF 36 executed 00:00:13 ago, SPF type Incremental SPF calculation time (in msec): SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 4 8 0 0 0 0 0 8 RIB manipulation time (in msec): RIB Update RIB Delete 0 0 LSIDs processed R:4 N:4 Stub:4 SN:0 SA:0 X7:0 Change record LSIDs changed 1 Changed LSAs. Recorded is LS ID and LS type: 4.4.4.4(R)

Outras situações que não cobertas pelas três propriedades anteriores exigem o cálculo FULL do SPF, por exemplo: 11 Troca de métricas e adição de novos enlaces, que melhoram a conectividade da rede; 11 Alteração de qualquer enlace do próprio roteador (por exemplo, qualquer alteração em R6 força o processamento FULL do SPF); 11 Alteração de enlace em redes Full Mesh (todos os roteadores ligados a todos os outros roteadores). 11 É fácil ver os benefícios de usar o ISPF, já que o tempo de execução pode ser conside-

q

ravelmente menor. 11 Situações que diferem das três propriedades apresentadas exigem cálculo Full do SPF, por exemplo: 22 Troca de métricas e adição de novos enlaces; 22 Alterações em qualquer enlace do próprio roteador. 11 Em ambientes de conectividade Full-Mesh, ou seja, todos roteadores têm enlaces para todos os demais roteadores, também requerem execução Full do SPF.

11 No funcionamento padrão do OSPF, em caso de reiniciação do processo ou problemas no módulo de controle, as vizinhanças são desfeitas; 11 Roteadores vizinhos precisam fazer a convergência do tráfego buscando caminhos alternativos, caso existam; 11 Em certos equipamentos, mesmo com a reinicialização do Plano de Controle, o Plano de Encaminhamento pode continuar funcionando; 11 Para evitar indisponibilidades quando esses equipamentos estão presentes, o IETF padronizou o Graceful Restart, RFC 3623. Os roteadores atuais são compostos por três planos de operação: 11 Plano de Controle; 11 Plano de Encaminhamento; 11 Plano de Gerência.

q Capítulo 4 - Otimização e tópicos avançados

Graceful Restart

121

O Plano de Controle é o conjunto de processos responsáveis por negociar informações de rotas entre roteadores, configuração de rotas estáticas, criação da árvore do protocolo Spanning Tree etc. Todos esses processos são executados na CPU principal do roteador. O Plano de Encaminhamento é o conjunto de processos responsáveis pelo encaminhamento dos quadros e pacotes entre interfaces físicas do equipamento de rede. O modo como o encaminhamento deve ser feito é de responsabilidade do Plano de Controle, que instala as rotas nos processadores dedicados a encaminhamento, conhecidos como ASICs (Application Specific Integrated Circuits) ou FPGAs (Field-programmable Gate Array). Esses processadores específicos são capazes de encaminhar e rotear milhões de pacotes por segundo, sem necessidade de usar a CPU principal do equipamento de rede. Nos equipamentos que possuem módulos específicos de portas e módulos de gerência (supervisores ou Route-Engines), os papéis são bem mais claros, uma vez que o Plano de Controle tende a ficar no módulo de gerência. O Plano de Gerência é o conjunto de processos responsáveis por monitorar e notificar o administrador de rede sobre o funcionamento do equipamento, por exemplo, contadores de interfaces, uso de CPU e memória, processo SNMP, NetFlow/sFlow, Syslog etc. Os roteadores modernos são compostos por três planos de operação: 11 Plano de Controle: responsável por definir como o tráfego deve ser encaminhado;

q

utiliza a CPU principal do equipamento; 11 Plano de Encaminhamento: responsável pelo encaminhamento do tráfego entre as interfaces; utiliza processadores dedicados (ASICs ou FPGAs); 11 Plano de Gerência: responsável por monitorar a operação do equipamento; utiliza a CPU principal do equipamento; 11 O OSPF e outros protocolos de roteamento funcionam no Plano de Controle. Na operação de uma rede com muitos roteadores, inevitavelmente um ou mais equipamentos de rede precisarão ter seus Sistemas Operacionais atualizados, seja por correções de segurança, seja por novas funcionalidades. Equipamentos de rede mais modernos permitem que o Sistema Operacional seja atualizado, mas sem remover as informações de encaminhamento e/ou roteamento dos módulos de interfaces, ou seja, sem alterar o Plano de Encaminhamento. Dessa maneira, o Sistema Operacional é atualizado, o Plano de Controle reiniciado (incluindo o processo OSPF) e somente após o carregamento total e sincronismos entre os módulos de gerência é que as tabelas de encaminhamento são atualizadas ou alteradas. No funcionamento padrão do OSPF, se o processo OSPF é reiniciado, cada vizinho OSPF vai perceber a queda da adjacência após o Dead Interval e vai executar o processo SPF para calcular novas rotas que não incluam o roteador que está indisponível. Após esse cálculo, o tráfego pode ser roteado por outro caminho. Porém, como mencionado anteriormente, alguns roteadores modernos permitem que o tráfego continue a ser encaminhado mesmo em caso de reinicialização do módulo de gerência ou de um processo específico. Para que esse encaminhamento continue a ocorrer, o IETF padronizou uma funcionalidade chamada OSPF Graceful Restart. Essa funcionalidade está padronizada na RFC 3623.

OSPF Avançado

A funcionalidade Graceful Restart permite que o roteador OSPF notifique seus vizinhos de que

122

o processo OSPF será reiniciado e que eles devem agir como se o roteador OSPF estivesse funcionando normalmente. Essa notificação é feita através de um LSA específico, chamado Grace LSA, que contém na mensagem o motivo da reinicialização e o tempo de indisponibilidade estimado (Grace Period). No processo do Graceful Restart, existem duas entidades:

11 Restarting Router: roteador que vai reiniciar o processo OSPF; 11 Helping Router: roteador vizinho do roteador que vai reiniciar (Restarting Router); 11 O Graceful Restart permite que o processo OSPF notifique seus vizinhos que o

q

processo será reinicializado, mas que o encaminhamento do tráfego não será interrompido enquanto isso acontece 11 Duas entidades foram definidas: 22 Restarting Router: roteador que irá reiniciar o processo OSPF 22 Helping Router: roteador vizinho do roteador que irá reiniciar (Restarting Router) 11 Antes de reiniciar, o Restarting Router envia um Grace LSA informando o motivo e o tempo previsto de indisponibilidade 11 Se o Helping Router suportar o Graceful Restart, o mesmo continua enviando tráfego normalmente 11 Se não suportar, nenhuma resposta é enviada e após o Restarting Router reiniciar, as vizinhanças ou adjacências serão finalizadas Quando o Restarting Router deseja executar um Graceful Restart, ele envia um Grace LSA para seus vizinhos. Após esse envio, existem duas possibilidades: 11 O roteador vizinho que suporta o Grace LSA (Helper Router) vai enviar um LSA ACK para o Restarting Router. A partir desse momento, o Helper Router vai continuar anunciando os LSAs do tipo Router recebidos anteriormente do Restarting Router para os demais roteadores OSPF da área; 11 O roteador vizinho não suporta o Grace LSA. Nesse caso, o roteador OSPF ignora os Grace LSAs. O Restarting Router, após algumas tentativas, mesmo que não tenha recebido o LSA ACK, procede com a reinicialização. Para o vizinho que não suporta o Graceful Restart, o processo de funcionamento continua o mesmo: após o Dead Interval, ele vai gerar LSAs do tipo Router para os vizinhos OSPF informando que os enlaces com o Restarting Router não estão mais disponíveis. Após a reinicialização, o Restarting Router precisa seguir alguns passos para sair do estado do Graceful Restart: 1. O Restarting Router estabelece as adjacências normalmente com os vizinhos OSPF; 2. Durante o sincronismo do LSDB, o Restarting Router não gera nenhum LSA, apenas recebe

3. Após montar o LSDB com os LSAs recebidos, o Restarting Router executa o procedimento SPF para calcular as rotas. Porém, as rotas não são instaladas; o Restarting Router as utiliza para criar os Virtual Links pré-existentes; 4. Se nos pacotes Hello recebidos dos vizinhos constar que o Restarting Router é o DR do segmento, o Restarting Router se promove a DR; 5. Se o Restarting Router não perceber inconsistências, como por exemplo, um pacote Hello que não o tenha no campo de “Vizinhos Ativos”, ele sai do estado de Graceful Restart enviando um novo Grace LSA com o tempo expirado (3.600 segundos).


os LSAs dos vizinhos;

123

11 Antes de voltar a operar novamente, o Restarting Router precisa:

q

22 Reestabelecer as vizinhanças OSPF 22 Durante o sincronismo do LSDB, não pode gerar nenhum LSA 22 Após receber os LSAs, executa o SPF mas não instala as rotas (usa para os Virtual Links) 22 Verifica as mensagens Hello para ver se deve virar DR 22 Se não houver inconsistências nos LSAs, envia um novo Grace LSA com o tempo expirado (3600s) Após sair do estado de Graceful Restart, o Restarting Router executa alguns procedimentos: 11 Todos os LSAs do tipo Router são reoriginados para garantir consistência; 11 Já todos os LSAs do tipo Network são reoriginados nos segmentos onde o Restarting Router é o DR; 11 O processo SPF é reexecutado e as rotas desta vez são instaladas; 11 LSAs do tipo 3, 4, 5 e 7 são reoriginados, caso o Restarting Router seja ABR ou ASBR; 11 Todas as entradas na tabela de rotas que não são mais válidas são removidas; 11 Todos os Grace LSAs são removidos do LSDB. 11 Após sair do estado de Graceful Restart, o Restarting Router executa alguns

q

procedimentos: 22 Todos os LSAs do tipo Router são reoriginados para garantir consistencia; 22 Todos os LSAs do tipo Network são reoriginados nos segmentos onde o Restarting Router é o DR; 22 O processo SPF é reexecutado e as rotas dessa vez são instaladas. 22 LSAs do tipo 3, 4, 5 e 7 são reoriginados, caso o Restarting Router seja ABR ou ASBR; 22 Todas as entradas na tabela de rotas que não são mais válidas são removidas; 22 Todos os Grace LSAs são removidos do LSDB. Os roteadores que suportam o Graceful Restart e viraram Helping Routers podem deixar de ser Helping Routers diante dos seguintes eventos: 11 Um Grace LSA com tempo expirado é recebido do Restarting Router. Nesse caso, o Helping Router assume que não é mais necessário ficar nesse estado; 11 O Grace Period informado no Grace LSA expirou. Nesse caso, o Restarting Router não retornou às atividades dentro da janela de tempo previsto. Logo, o Helping Router age como se estivesse indisponível. A partir desse momento, o processo normal do OSPF de indisponibilidade de vizinho é executado; 11 Uma mudança do LSDB indicando que a topologia da rede mudou. Nesse caso, o Helping

OSPF Avançado

Router encerra seu papel no processo do Graceful Restart.

124

11 Os roteadores Helping Routers podem deixar de ser Helping Router diante dos

q

seguintes eventos: 22 Um Grace LSA com tempo expirado é recebido do Restarting Router. 22 O Grace Period informado no Grace LSA expirou 22 Uma mudança do LSDB indicando que a topologia da rede mudou 11 O modo Helping Router já é habilitado por padrão em alguns fabricantes. Muitas vezes com o nome IETF NSF helper (Non-Stop Forwarding). Alguns fabricantes já ativam o modo Helping Router por padrão, facilitando a operação da rede. Por exemplo, observe a saída a seguir: R1#sh ip ospf Routing Process "ospf 10" with ID 1.1.1.1 Start time: 00:01:08.196, Time elapsed: 00:09:44.664 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS) Supports area transit capability Event-log enabled, Maximum number of events: 1000, Mode: cyclic Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Incremental-SPF disabled Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Number of areas transit capable is 0 IETF NSF helper support enabled

É possível ver a linha IETF NSF, ou NonStop Forward, habilitada. Nesse caso, basta que o vizinho OSPF envie um Grace LSA para que esse roteador passe para o modo Helping Router. Para ativar o modo Restarting Router, basta inserir os seguintes comandos antes de reiniciar o processo OSPF: R1# (config)# router ospf 10 R1# (config-router)#nsf ietf restart-interval <0-1800>


External flood list length 0

125

11 Para iniciar o Graceful Restart no Restarting Router basta configurar o processo OSPF:

q

R1# (config)# router ospf 10 R1# (config-router)#nsf ietf restart-interval <0-1800>

11 E na sequência, reiniciar o processo OSPF 11 Ao solicitar a reinicialização, um Grace LSA será enviado com o tempo informado no comando restart-interval. Após aplicar esse comando, quando o operador reiniciar o processo OSPF, um Grace LSA

l

será enviado com o tempo informado no comando restart-interval.

BFD para OSPF Na sessão 1, o processo de estabelecimento de uma vizinhança OSPF foi apresentado, bem como o processo para detectar a queda dos vizinhos. Em particular, o Dead Interval, intervalo de tempo em que o OSPF espera por pacotes Hello de um vizinho antes de declará-lo "morto" foi apresentado, com alguns exemplos. De acordo com a RFC 2328, o Dead Interval padrão é especificado em 40 segundos. Esse tempo de 40 segundos é extremamente elevado para as aplicações modernas e, principalmente, as aplicações interativas. Para situações onde os roteadores estão diretamente conectados, a queda de interface OSPF ativa imediatamente o processo de convergência OSPF. Porém, alguns cenários apresentam desafios extras. Observe a topologia da figura 4.5. 11 Sessão 1 apresentou o processo de estabelecimento e identificação da queda da adjacência OSPF, usando ambos Hello (10 segundos) e Dead Interval (40 segundos)

q

O modo Restarting Router, da funcionalidade Graceful Restart, só é suportado por equipamentos com suporte ao encaminhamento de pacotes, mesmo sem o módulo de gerência estar em operação. Esse comportamento é comum em equipamentos de chassis, que são modulares. Equipamentos menores normalmente suportam apenas o modo Helper Router.

11 Quando uma enlace OSPF muda de estado, o roteador diretamente conectado detecta a mudança e notifica os demais roteadores OSPF 11 Se o enlace não estiver diretamente conectado, o Dead Interval é utilizado 11 Observe a figura 4.5

Internet R3

s1/0 s1/0

R1

f0/0 2

SW2

SW1 1

OSPF Avançado

f0/0

1

Rede de Transporte A

3

f0/0

R2 A rede da figura 4.5 possui três roteadores, R1, R2 e R3, e dois switches, SW1 e SW2. Os dois switches fazem parte da "Rede de Transporte A", contratada para interconectar os roteadores OSPF R1, R2 e R3. Além disso, há um enlace serial entre os roteadores R1 e R3. Observe as configurações a seguir.

126

2

Figura 4.5 Bidirectional Forwarding Detection.

R1: interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ! interface Serial1/0 ip address 10.1.3.1 255.255.255.0 ! router ospf 10 network 0.0.0.0 255.255.255.255 area 0 R2: interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet0/0 ip address 10.0.0.2 255.255.255.0 ! router ospf 10 network 0.0.0.0 255.255.255.255 area 0 R3: interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface FastEthernet0/0 ip address 10.0.0.3 255.255.255.0 ! interface Serial1/0 ip address 10.1.3.3 255.255.255.0 ! router ospf 10 network 0.0.0.0 255.255.255.255 area 0

É possível observar que todas as interfaces fazem parte da Área Backbone. A rede 10.0.0.0/24 conecta todos os roteadores via a "Rede de Transporte A", e a rede 10.1.3.0/24 que a interface Serial1/0, a interface Serial1/0 será utilizada apenas como uma interface de proteção em caso de queda na infraestrutura da "Rede de Transporte A". 11 A "Rede de Transporte A" conecta os três roteadores, criando uma rede Broadcast 11 Uma rede ponto-a-ponto em um enlace serial conecta R1 e R3 11 O enlace serial deve ser usado para backup 11 Todos os roteadores estão na Área Backbone 11 Todas as adjacências estão estabelecidas: R1#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 0 FULL/ - 00:00:36 10.1.3.3 Serial1/0

q


conecta R1 e R3. Como a interface FastEthernet0/0 dos roteadores R1 e R3 tem melhor custo

2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0

127

3.3.3.3 1 FULL/DR 00:00:33 10.0.0.3 FastEthernet0/0

q

R2#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DROTHER 00:00:37 10.0.0.1 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:35 10.0.0.3 FastEthernet0/0 R3#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/ - 00:00:39 10.1.3.1 Serial1/0 1.1.1.1 1 FULL/DROTHER 00:00:36 10.0.0.1 FastEthernet0/0 2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0

Observe que entre R1 e R3 existem duas adjacências estabelecidas, uma via rede Broadcast, outra via rede Ponto-a-Ponto. A seguir, algumas saídas mostrando o funcionamento da Rede OSPF: R1#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 0 FULL/ - 00:00:36 10.1.3.3 Serial1/0 2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:33 10.0.0.3 FastEthernet0/0 R2#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DROTHER 00:00:37 10.0.0.1 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:35 10.0.0.3 FastEthernet0/0 R3#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/ - 00:00:39 10.1.3.1 Serial1/0 1.1.1.1 1 FULL/DROTHER 00:00:36 10.0.0.1 FastEthernet0/0 2.2.2.2 1 FULL/BDR 00:00:36 10.0.0.2 FastEthernet0/0

R1 e R3 possuem 3 vizinhanças, sendo duas entre eles. Uma via interface Serial1/0, uma via interface FastEthernet0/0. É possível ver que uma vizinhança é Ponto-a-Ponto (State: Full/-) e outra é Broadcast (Full/DROTHER, BDR ou DR). Vamos analisar algumas possibilidades de alteração de estado de alguns enlaces para entender como a rede OSPF se comportaria: 11 Interface 2 do SW1 e Interface FastEthernet0/0 do R3 tem seus estados alterados para DOWN (problema no enlace): ao perceber que a interface FastEthernet0/0 está DOWN, R3 cria um LSA Router notificando seus vizinhos OSPF. Nesse caso, como a interface FastEthernet0/0 está DOWN, apenas R1 seria notificado. Através da interface FastEthernet0/0, R1 notifica R2; R2 atualiza suas rotas para chegar em R3 via R1. A convergência foi concluída; 11 Interface 3 do SW1 e Interface FastEthernet0/0 do R2 tem seus estados alterados para DOWN (problema no enlace): como R2 não tem redundância de acesso, R2 não tem o que fazer. R1 e R3 vão esperar pelo Dead Interval (40s) para removerem R2 do OSPF Avançado

LSDB da Área Backbone; 11 Interface 2 do SW2 e Interface FastEthernet0/0 do R1 tem seus estados alterados para DOWN (problema no enlace): ao perceber que a FastEthernet0/0 está DOWN, R1 cria um LSA Router notificando seus vizinhos OSPF. Nesse caso, como a interface FastEthernet0/0 está DOWN, apenas R3 seria notificado. Através da interface FastEthernet0/0, R3 notifica R2; R2 atualiza suas rotas para chegar em R1 via R3. A convergência foi concluída; 128

Algumas possibilidades de indisponibilidades e impacto na rede: 11 Enlace SW1-R3 indisponível: R3 cria um LSA Router para os vizinhos, nesse caso R1;

q

R1 atualiza R2 para enviar os pacotes para R3 via R1. Convergência concluída; 11 Enlace SW1-R2 indisponível: R2 não tem redundância, fica indisponível; 11 Enlace SW2-R1 indisponível: R1 cria um LSA Router para os vizinhos; nesse caso, R3; R3 atualiza R2 para enviar os pacotes para R1 via R3. Convergência concluída; Em nenhum desses casos, o Dead Interval causou indisponibilidade extra. Outra possibilidade seria: 11 Enlace SW1-SW2 indisponível: nenhum roteador OSPF diretamente afetado, Dead Interval será utilizado. Enquanto isso, o enlace R1-R3 de backup fica sem utilização. 40 segundos de indisponibilidade pode ser observado. É possível observar que nesses três casos listados, apesar do fato de o Dead Interval ser relativamente alto, esse valor não trouxe impacto, pois a queda da interface é tratada imediatamente pelos roteadores OSPF. Vamos ver o caso a seguir: 11 Interface 1 do SW1 e Interface 1 do SW2 tem seus estados alterados para DOWN (problema no enlace): nesse caso, apesar de haver um problema na "Rede de Transporte A", esse problema não afeta nenhuma interface dos roteadores OSPF. Então, os roteadores R1, R2 e R3 vão esperar pelo Dead Interval para fazer a convergência da rede, ou seja, apesar de o enlace entre R1 e R3 estar disponível, esse só será utilizado após o Dead Interval. 22 Enlace entre SW1 e SW2 desativado. As adjacências OSPF são removidas após 40 segundos. Observe o Dead Interval decrementando. R1#show ip ospf neighbor

q

Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 0 FULL/ - 00:00:30 10.1.3.3 Serial2/0 2.2.2.2 1 FULL/BDR 00:00:17 10.0.0.2 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:15 10.0.0.3 FastEthernet0/0 R1# *Jun 21 14:50:12.483: %OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired R1# *Jun 21 14:50:14.343: %OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired R3# from FULL to DOWN, Neighbor Down: Dead timer expired

Após os alertas de Neighbor Down, R1 e R3 executam o SPF em seus LSDBs. Com isso, o enlace serial entre R1 e R2 passa a ser utilizado, permitindo que todos os roteadores sejam alcançáveis novamente. R1#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 0 FULL/ - 00:00:30 10.1.3.3 Serial2/0 2.2.2.2 1 FULL/BDR 00:00:17 10.0.0.2 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:15 10.0.0.3 FastEthernet0/0 R1# *Jun 21 14:50:12.483: %OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on FastEthernet0/0


*Jun 21 14:50:03.607: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on FastEthernet0/0

129

from FULL to DOWN, Neighbor Down: Dead timer expired R1# *Jun 21 14:50:14.343: %OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired R3# *Jun 21 14:50:03.607: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

Na sessão de aprendizagem 1, a funcionalidade de Fast Hello do OSPF foi apresentada justamente para resolver esse tipo de problema, uma vez que a detecção de desconexão dos vizinhos ocorre em menos de 1 segundo. Porém, o Fast Hello é processado pelo Módulo de Gerência, no Plano de Controle, consumindo recursos extras de CPU e Memória. Para permitir uma solução mais escalável e independente do tipo de protocolo de roteamento, o IETF padronizou um protocolo chamado Bidirectional Forwarding Detection, ou BFD, na RFC 5880. O BFD é um protocolo de teste de conectividade entre Planos de Encaminhamento. Por ser mais leve, o BFD permite que mais sessões sejam monitoradas, com intervalos de monitoramento de 50 milisegundos. Além disso, o BFD é agnóstico ao protocolo de roteamento, podendo ser utilizado para rotas estáticas, OSPF, ISIS, entre outros. Alguns equipamentos suportam centenas de sessões BFD ao mesmo tempo. 11 Funcionalidade Fast Hello permite convergência em menos de 1 segundo, porém

q

consume CPU do roteador 11 Protocolo Bidirectional Forwarding Detection, ou BFD, foi padronizado na RFC 5880 11 Protocolo de testes em Planos de Encaminhamento 11 Permite convergência em intervalos de testes de 50 milissegundos 11 Independente de protocolo: funciona com OSPF, rota estática, ISIS, BGP, etc. O BFD funciona como o protocolo Hello: uma mensagem é enviada por cada roteador a cada intervalo definido pelo Engenheiro de Redes, e após uma quantidade de mensagens perdidas (também definidas pelo Engenheiro de Redes), a sessão BFD é declarada DOWN. Quando utilizado com o OSPF, o BFD também notifica o processo OSPF da queda da sessão, logo o roteador OSPF atualiza seu LSDB removendo o vizinho indisponível. Nesse caso, o Engenheiro de Redes pode inclusive aumentar o intervalo das mensagens Hello, desonerando o processo OSPF. Assim como o protocolo Hello, o BFD também suporta autenticação das suas mensagens, inclusive com MD5. Nas redes atuais, o protocolo BFD tem sido muito utilizado em casos onde a conexão entre roteadores é feita através de redes Ethernet ou MPLS, que não geram circuitos fim-a-fim. 11 BFD utiliza sistema de mensagem de teste similar ao Hello do OSPF 11 Engenheiro de Redes pode definir o intervalo de testes e quantidade de mensagens permitidas antes de declarar vizinho como morto 11 BFD suporta MD5 por sessão OSPF Avançado

11 Muito utilizado para testar enlaces providos via Ethernet ou MPLS

130

q

A configuração BFD é extremamente simples de ser feita: 1. Habilita-se o BFD nas interfaces dedicadas, definindo o intervalo entre mensagens (interval), o tempo mínimo entre mensagens (min_rx) e a quantidade de mensagens que devem ser perdidas para considerar o vizinho OSPF como indisponível (multiplier): configure terminal interface fastEthernet0/0 bfd interval 50 min_rx 50 multiplier 3

Esse comando habilita o BFD na interface fastEthernet0/0, com intervalo entre mensagens de 50 milisegundos, tempo mínimo para receber as mensagens de 50 milisegundos e a quantidade de mensagens perdidas de 3. Ou seja, em caso de indisponibilidades, após 150 milisegundos (3x50), a sessão OSPF com o roteador inativo seria terminada e o processo de convergência executado. 11 A configuração BFD é tão simples quanto o protocolo:

q

22 1. Configura-se a(s) interface(s) que terão o BFD habilitado: configure terminal interface fastEthernet0/0 bfd interval 50 min_rx 50 multiplier 3

22 O intervalo de testes foi configurado para 50 milisegundos

q

22 O tempo mínimo para receber as mensagens foi configurado para 50 milisegundos 22 Mensagens que devem ser perdidas antes de considerar a sessão BFD indisponível: 3 22 Neste caso, o tempo de detecção da queda da adjacência ocorre em 150 milisegundos. 2. Ativa-se o BFD no processo OSPF (todas as interfaces) ou em interfaces específicas. Para ativar por interface: configure terminal interface fastEthernet 0/0 ip ospf bfd

Para ativar para todas as interfaces OSPF: configure terminal router ospf 10

2. Configura-se o processo OSPF para usar as informações do processo BFD Pode ser feito por interface:

l Em alguns fabricantes, o BFD só é ativado quando a adjacência OSPF é recriada; logo pode ser necessário reiniciar o processo OSPF.

configure terminal interface fastEthernet 0/0 ip ospf bfd

*ou para todas as interfaces: configure terminal router ospf 10 bfd all-interfaces

q


bfd all-interfaces

131

Para confirmar a ativação, execute o comando a seguir e observe a linha "BFD is enabled". R1#show ip ospf Routing Process "ospf 10" with ID 1.1.1.1 Start time: 00:00:35.700, Time elapsed: 00:06:41.904 Supports only single TOS(TOS0) routes Supports opaque LSA (...) 0 stub 0 nssa Number of areas transit capable is 0 External flood list length 0 IETF NSF helper support enabled Cisco NSF helper support enabled BFD is enabled (...)

Verifique se o BFD está habilitado via comando:

q

R1#show ip ospf (...) BFD is enabled

l

Para verificar se as sessões estão criadas: R1#sh bfd neighbors

Assim como no Fast Hello, o Engenheiro de Redes deve ser cauteloso na escolha de quando ativar o BFD e também na escolha do intervalo entre testes. Intervalos muito curtos tendem a consumir mais recursos e todos os roteadores possuem um número máximo de sessões BFD suportadas, a depender da plataforma.

IPv4 Sessions NeighAddr LD/RD RH/RS State Int 10.0.0.3 8003/3 Up Up f0/0 10.0.0.2 8004/4 Up Up f0/0

Para confirmar se as sessões BFD estão criadas, utilize o comando a seguir: R1#sh bfd neighbors IPv4 Sessions NeighAddr LD/RD RH/RS State Int 10.0.0.3 8003/3 Up Up f0/0 10.0.0.2 8004/4 Up Up f0/0

Uma vez que a sessão BFD foi ativada, no próximo incidente que mude o estado do enlace, o processo BFD vai detectar a queda e notificar o processo OSPF. Assim, o processo OSPF vai executar o SPF novamente para computar a SPT. 11 A partir do momento que a sessão BFD foi estabelecida, o processo BFD fará os testes no intervalo determinado, e ao detectar a queda, notificará o processo OSPF. 11 Ao ser notificado pelo BFD, o processo OSPF imediatamente desfaz a adjacência com o vizinho indisponível e recria a SPT. 11 O Engenheiro de Redes deve ser cauteloso ao definir o tempo mínimo de intervalo OSPF Avançado

do BFD e a quantidade de sessões a serem estabelecidas. Mais sessões e tempos

132

menores consomem mais recursos do roteador.

q

Supressão de Prefixos Redes de provedores de serviços de internet (internet Service Providers: ISPs) contêm milhares de rotas, principalmente se contarmos com a tabela BGP global (mais de 500 mil prefixos IPv4 atualmente). E muitas dessas redes possuem diversos enlaces conectando diversos roteadores, aumentando a capacidade de tráfego e a resiliência da rede. Em muitos casos, as conexões são feitas entre pares de roteadores, seja através de circuitos seriais, ópticos ou via VLANs específicas. No tópico do Incremental SFP, foi apresentada uma abordagem para evitar a execução completa do SPF em casos de alteração de estados mais simples, como em roteadores folhas ou enlaces que não fazem parte da SPT (Shortest Path Tree). Em redes que possuem muitos enlaces que concentram apenas roteadores – enlaces chamados de Redes de Trânsito –, além do ISPF, outro recurso está à disposição do Engenheiro de Redes para aumentar a escalabilidade do processo OSPF: a Supressão de Prefixos. Esse recurso foi padronizado na RFC 6860 com o objetivo de remover os prefixos desses enlaces de trânsito da tabela de rotas. Essa funcionalidade se aplica tanto em enlaces ponto-a-ponto como enlaces do tipo Broadcast. Observe o cenário da figura 4.6 (arquivo adr9-cap4-supressao.zip). 11 Redes de ISPs já possuem milhares de rotas, recebidas via BGP e IGP

q

11 Quanto mais enlaces entre roteadores, mais Redes de Trânsito são criadas 11 Redes altamente conectadas possuem em seus LSDBs muitos prefixos apenas para trânsito, ou seja, desnecessários do ponto de vista dos usuários 11 RFC 6860 padronizou uma funcionalidade para melhorar a escalabilidade do OSPF: a Supressão de Prefixos 11 Redes de Trânsito são removidas do LSDB quando a Supressão de Prefixos é habilitada 11 Melhora o tempo de convergência através da diminuição do LSDB

192.168.1.0/24

R2 10.1.2.0/24

R3 10.2.3.0/24

10.2.4.0/24

Figura 4.6 Topologia para Supressão de Prefixos.

192.168.2.0/24

10.3.5.0/24

10.4.5.0/24

192.168.3.0/24

R4

R5

Nesta topologia, existem três redes de usuários (192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) e cinco roteadores (R1, R2, R3, R4 e R5). O prefixo 10.0.0.0/24 foi utilizado para endereçar as interfaces Loopbacks (10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4 e 10.0.0.5), e o prefixo 10.X.Y.N/24 para endereçar as conexões entre roteadores, seguindo o modelo em uso ao longo deste livro.


R1

133

Para ilustrar algumas diferenças de funcionamento, o enlace R1-R2 ficou configurado no modo Broadcast, enquanto os demais enlaces estão configurados como ponto-a-ponto. A seguir está a configuração das interfaces do roteador R5: interface FastEthernet0/0 ip address 10.4.5.5 255.255.255.0 ip ospf network point-to-point ! interface GigabitEthernet1/0 ip address 10.3.5.5 255.255.255.0 ip ospf network point-to-point

11 A rede da figura 4.6 possui:

q

22 Três redes de usuários (192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24); 22 Cinco roteadores (R1, R2, R3, R4 e R5); 22 Cinco interfaces Loopbacks (10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4 e 10.0.0.5); 22 Cinco redes de trânsito (10.1.2.0/24, 10.2.3.0/24, 10.2.4.0/24, 10.3.5.0/24, 10.4.5.0/24); 22 Enlace R1-R2 está configurado como Broadcast; 22 Demais enlaces estão configurados como Ponto-a-Ponto. Observe a seguir a saída da tabela de rotas de R5:

q

R5#show ip route ospf 10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks O 10.0.0.2/32 [110/21] via 10.4.5.4, 00:03:12, FastEthernet0/1 [110/21] via 10.3.5.3, 00:03:12, FastEthernet0/0 O 10.1.2.0/24 [110/30] via 10.4.5.4, 00:03:12, FastEthernet0/1 [110/30] via 10.3.5.3, 00:03:12, FastEthernet0/0 O 10.0.0.3/32 [110/11] via 10.3.5.3, 00:03:12, FastEthernet0/0 O 10.2.3.0/24 [110/20] via 10.3.5.3, 00:03:12, FastEthernet0/0 O 10.0.0.1/32 [110/31] via 10.4.5.4, 00:03:12, FastEthernet0/1 [110/31] via 10.3.5.3, 00:03:12, FastEthernet0/0 O 10.2.4.0/24 [110/20] via 10.4.5.4, 00:03:12, FastEthernet0/1 O 10.0.0.4/32 [110/11] via 10.4.5.4, 00:03:12, FastEthernet0/1 192.168.1.0/32 is subnetted, 1 subnets O 192.168.1.1 [110/31] via 10.4.5.4, 00:03:12, FastEthernet0/1 [110/31] via 10.3.5.3, 00:03:12, FastEthernet0/0 O E2 192.168.2.0/24 [110/20] via 10.3.5.3, 00:03:12, FastEthernet0/0 192.168.3.0/32 is subnetted, 1 subnets O 192.168.3.1 [110/11] via 10.4.5.4, 00:03:13, FastEthernet0/1

Nessa tabela de rotas, é possível observar diversas rotas, incluindo as rotas que endereçam conexões entre roteadores (redes de trânsito), como por exemplo os prefixos 10.1.2.0/24, OSPF Avançado

10.2.3.0/24 e 10.2.4.0/24. A rede de usuário 192.168.2.0/24 foi redistribuída no processo OSPF pelo roteador R3 (por isso O E2 à frente da rota). Observe também que o ECMP está em uso, com alguns prefixos possuindo mais de um caminho – por exemplo, 10.0.0.2/32 pode ser alcançado via R4 (10.4.5.4) e R3 (10.3.5.3). É muito comum em ISPs de médio e grande porte que as conexões entre roteadores sejam criadas via enlaces ponto-a-ponto e utilizando prefixos /30 e/ou /31. Nesse caso, quanto maior 134

a quantidade de roteadores e enlaces entre estes, maior a quantidade de rotas associadas a Redes de Trânsito. Porém, essas rotas têm pouco ou nenhuma importância na maioria dos casos, e acabam consumindo recursos do LSDB e dos roteadores OSPF. A RFC 6860 propôs justamente remover esses prefixos das tabelas de roteamento OSPF, diminuindo o LSBD, o tempo de convergência, aumentando a escalabilidade e a segurança da rede. Antes de apresentar o funcionamento da RFC 6860, uma revisão sobre os LSA Router e Network será feita a seguir, utilizando a topologia da figura 4.6 como exemplo. A saída a seguir mostra o LSDB da Área 0 coletado a partir de R5: R5#sh ip ospf database OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 10.0.0.1 10.0.0.1 183 0x80000002 0x005215 3 10.0.0.2 10.0.0.2 34 0x80000004 0x00B788 6 10.0.0.3 10.0.0.3 28 0x80000003 0x00273C 5 10.0.0.4 10.0.0.4 40 0x80000004 0x00E7F4 6 10.0.0.5 10.0.0.5 28 0x80000004 0x0081D0 5 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.1.2.1 10.0.0.1 183 0x80000001 0x006B9E Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 192.168.2.0 10.0.0.3 39 0x80000001 0x00B374 0

É possível ver que R1 está anunciando três enlaces no LSA Router (Link count). Observe-os a seguir. R5#sh ip ospf database router adv-router 10.0.0.1 OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) LS Type: Router Links Link State ID: 10.0.0.1 Advertising Router: 10.0.0.1 Number of Links: 3 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.1.1 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.0.1 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 10.1.2.1 (Link Data) Router Interface address: 10.1.2.1 Number of MTID metrics: 0 TOS 0 Metrics: 1



135

Nesta saída existem os seguintes tipos de enlace: dois do Tipo 3 (Stub Network) e um do Tipo 2 (Transit Network). O Tipo 2 é utilizado para informar em qual rede existe um Designated Router. O Tipo 3 informa a rota que será instalada na tabela de rotas. Observe agora o LSA Router originado por R2: R5#sh ip ospf database router adv-router 10.0.0.2 OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) LS Type: Router Links Link State ID: 10.0.0.2 Advertising Router: 10.0.0.2 Number of Links: 6 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.0.2 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.3 (Link Data) Router Interface address: 10.2.3.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.2.3.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.4 (Link Data) Router Interface address: 10.2.4.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.2.4.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 10.1.2.1 (Link Data) Router Interface address: 10.1.2.2 Number of MTID metrics: 0 TOS 0 Metrics: 1

Observe que R2 anunciou 3 enlaces do Tipo 3 (Stub Network), 1 enlace do Tipo 2 (Transit OSPF Avançado

Network) e 2 enlaces do Tipo 1 (point-to-point). O Tipo 1 é utilizado para o cálculo do SPF e está relacionado a enlaces ponto-a-ponto. Quando o Tipo 1 é utilizado, o campo “Link Data” informa o endereço IP da interface a ser utilizada para alcançar o vizinho OSPF. Quando o Tipo 3 é utilizado, o campo “Link Data” informa a máscara de subrede da rede Stub. No caso do Tipo 2, o campo “Link Data” informa o endereço IP da interface do originador do LSA. No Tipo 2, o campo “Link ID” informa o endereço IP da interface do roteador DR. Em caso de dúvidas, consulte a tabela 1.2, da sessão 1. 136

É possível notar que existem dois registros associados com o mesmo enlace entre o roteador R2 e o roteador R3: Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.3 (Link Data) Router Interface address: 10.2.3.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.2.3.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1

Observe os LSAs do tipo Router na Área Backbone:

q

R5#sh ip ospf database OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 10.0.0.1 10.0.0.1 183 0x80000002 0x005215 3 10.0.0.2 10.0.0.2 34 0x80000004 0x00B788 6 10.0.0.3 10.0.0.3 28 0x80000003 0x00273C 5 10.0.0.4 10.0.0.4 40 0x80000004 0x00E7F4 6 10.0.0.5 10.0.0.5 28 0x80000004 0x0081D0 5

Nesses LSAs, existem LSAs do Tipo 1(Ponto-a-Ponto), do Tipo 2(Transit) e do Tipo 3(Stub. Observe os LSAs gerados pelo R2 (valores de métrica removidos para simplificar): R5#sh ip ospf database router adv-router 10.0.0.2 OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) LS Type: Router Links Link State ID: 10.0.0.2 Advertising Router: 10.0.0.2 Number of Links: 6 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.0.2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.3 (Link Data) Router Interface address: 10.2.3.2 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.2.3.0 (Link Data) Network Mask: 255.255.255.0 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.4 (Link Data) Router Interface address: 10.2.4.2 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.2.4.0 (Link Data) Network Mask: 255.255.255.0



137

Link connected to: a Transit Network

q

(Link ID) Designated Router address: 10.1.2.1 (Link Data) Router Interface address: 10.1.2.2

O prefixo IP desse enlace não precisa ser acessado por usuários e seria mais seguro que eles realmente não fossem alcançáveis de fora da rede. Então, bastaria ativar a supressão de prefixos para remover esse e outros prefixos de trânsito do LSDB. A configuração para remoção pode ser feita de duas maneiras: Por interface OSPF: configure terminal interface fastEthernet 0/1 ip ospf prefix-suppression

Por roteador: configure terminal router ospf 10 prefix-suppression

11 A Supressão de Prefixos pode ser feita por interface:

q

configure terminal interface fastEthernet 0/1 ip ospf prefix-suppression

11 Por roteador: configure terminal router ospf 10 prefix-suppresion

11 Uma vez inseridos os comandos, nenhuma rota associada a registros do Tipo 3 para redes de trânsito é gerada. Quando esses comandos são inseridos em interfaces do tipo ponto-a-ponto, nenhuma rota associada a registros do Tipo 3 é gerada. Observe o LSDB após a inserção do comando prefix-suppresion: R5#sh ip ospf database OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 10.0.0.1 10.0.0.1 1579 0x80000004 0x004E17 3 10.0.0.2 10.0.0.2 73 0x80000007 0x00E09D 4 10.0.0.3 10.0.0.3 25 0x80000006 0x004261 3 10.0.0.4 10.0.0.4 32 0x80000007 0x008B93 4 OSPF Avançado

10.0.0.5 10.0.0.5 12 0x80000007 0x00593D 3 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.1.2.1 10.0.0.1 22 0x80000004 0x0065A1 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 192.168.2.0 10.0.0.3 1391 0x80000003 0x00AF76 0

138

q

11 Observe o LSBD com a Supressão de Prefixos habilitada: R5#sh ip ospf database OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) Link ID

ADV Router

Age

Seq#

10.0.0.1

10.0.0.1

1579

0x80000004 0x004E17 3

Checksum Link count

10.0.0.2

10.0.0.2

73

0x80000007 0x00E09D 4

10.0.0.3

10.0.0.3

25

0x80000006 0x004261 3

10.0.0.4

10.0.0.4

32

0x80000007 0x008B93 4

10.0.0.5

10.0.0.5

12

0x80000007 0x00593D 3

11 Observe que a quantidade de enlaces na coluna Link Count diminui se comparado com o LSBD sem supressão. 11 Lembre-se que redes de usuários, interfaces passivas e loopbacks não são redes de trânsito, logo continuam a ser anunciados via OSPF Note pela coluna "Link count" que a quantidade de enlaces anunciados por R2, R3, R4 e R5 diminuiu dois valores comparando com a saída antes de aplicarmos o comando prefix-suppresion. A seguir é possível ver o LSA Router gerado por R2: R5#sh ip ospf database router adv-router 10.0.0.2 OSPF Router with ID (10.0.0.5) (Process ID 10) Router Link States (Area 0) LS Type: Router Links Link State ID: 10.0.0.2 Advertising Router: 10.0.0.2 Number of Links: 4 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.0.2 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.3 (Link Data) Router Interface address: 10.2.3.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 (Link ID) Neighboring Router ID: 10.0.0.4 (Link Data) Router Interface address: 10.2.4.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 10.1.2.1 (Link Data) Router Interface address: 10.1.2.2 Number of MTID metrics: 0 TOS 0 Metrics: 1


Link connected to: another Router (point-to-point)

139

l

É possível verificar que não existem mais enlaces do Tipo 3 (Stub) associados os enlaces

Só há supressão para LSAs Router e Network.

ponto-a-ponto. Enlaces associados a interfaces loopbacks ou interfaces passívas não são suprimidos, pois não são considerados redes de trânsito. Confirmando a tabela de rotas em R5: R5#sh ip route ospf 10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks O 10.0.0.1/32 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0 [110/4] via 10.3.5.3, 01:35:06, GigabitEthernet1/0 O 10.0.0.2/32 [110/3] via 10.4.5.4, 01:35:16, FastEthernet0/0 [110/3] via 10.3.5.3, 01:35:06, GigabitEthernet1/0 O 10.0.0.3/32 [110/2] via 10.3.5.3, 01:35:06, GigabitEthernet1/0 O 10.0.0.4/32 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0 192.168.1.0/32 is subnetted, 1 subnets O 192.168.1.1 [110/4] via 10.4.5.4, 01:35:16, FastEthernet0/0 [110/4] via 10.3.5.3, 01:35:06, GigabitEthernet1/0 O E2 192.168.2.0/24 [110/20] via 10.3.5.3, 01:35:06, GigabitEthernet1/0 192.168.3.0/32 is subnetted, 1 subnets O 192.168.3.1 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0

11 Verificando a tabela de rotas em R5:

q

R5#sh ip route ospf 10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks O

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

O

10.0.0.2/32 [110/3] via 10.4.5.4, 01:35:16, FastEthernet0/0

[110/4] via 10.3.5.3, 01:35:06, GigabitEthernet1/0 [110/3] via 10.3.5.3, 01:35:06, GigabitEthernet1/0 O

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

O

10.0.0.4/32 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0 192.168.1.0/32 is subnetted, 1 subnets

O

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

O E2

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

192.168.3.0/32 is subnetted, 1 subnets O

192.168.3.1 [110/2] via 10.4.5.4, 01:35:16, FastEthernet0/0

11 É possível observar que não existem prefixos da rede 10.X.Y.N/24, somente prefixos de usuários e interfaces Loopback. Por essa saída é possível confirmar que as redes de trânsito não fazem mais parte da tabela de rotas. Nesse ponto, o aluno pode estar se perguntando: por que o prefixo 10.1.2.0/24 sumiu da

OSPF Avançado

tabela de rotas se ele não era um registro do Tipo 3, e sim do Tipo 2?

140

11 É possível observar que o enlace 10.1.2.0/24 também não está na tabela de rotas de R5, apesar de não ser Tipo 3. 11 Enlaces tipo 2(Transit) também são considerados redes de trânsito, por isso também são suprimidos 11 RFC6860 define que a máscara de subrede do LSA Network seja alterada para /32.

q

Os enlaces do Tipo 2, apesar de não serem redes ponto-a-ponto, também são considerados redes de trânsito, logo também não há necessidade de estarem na tabela de rotas. A RFC 6860 muda isso forçando que os roteadores que suportem supressão de prefixos anunciem a máscara do segmento de rede como /32 (nesse caso, sem a supressão seria /24): R5#sh ip ospf database network OSPF Router with ID (10.0.0.5) (Process ID 10) Net Link States (Area 0) LS age: 158 LS Type: Network Links Link State ID: 10.1.2.1 (address of Designated Router) Advertising Router: 10.0.0.1 Network Mask: /32 Attached Router: 10.0.0.1 Attached Router: 10.0.0.2

Observe o LSA Network:

q

R5#sh ip ospf database network OSPF Router with ID (10.0.0.5) (Process ID 10) Net Link States (Area 0) LS age: 158 LS Type: Network Links Link State ID: 10.1.2.1 (address of Designated Router) Advertising Router: 10.0.0.1 Network Mask: /32 Attached Router: 10.0.0.1 Attached Router: 10.0.0.2

Verifique a Network Mask não está como /24, e sim como /32. Com essa alteração, o roteador OSPF não cria uma rota para a rede de trânsito do Tipo 2. Uma vez que não são mais divulgadas as redes de trânsito, qualquer teste com PING ou TRACEROUTE gerado localmente no roteador não vai funcionar se a opção SOURCE não for definida: R1#ping 10.0.0.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds: Success rate is 0 percent (0/5) R1#ping 10.0.0.5 source 10.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds: Packet sent with a source address of 10.0.0.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/42/52 ms

Esse problema acontece porque o roteador usa o endereço da interface mais próxima do destino, e como endereços de interfaces não são mais anunciados, os pacotes não têm como voltar!


.....

141

11 A princípal diferença, do ponto de vista da operação da rede, e o PING ou TRACEROUTE

q

de dentro dos roteadores. Observe: R1#ping 10.0.0.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

11 R1 tem rota para 10.0.0.5, mas não pinga. Ao fazer o PING ou TRACEROUTE de dentro do roteador, o mesmo escolhe como IP de origem, o IP da interface mais próxima do destino. 11 Como o IP da interface mais próxima faz parte da rede de trânsito, R5 não tem rota para enviar o pacote de volta. 11 Nesse caso, a origem do teste deve ser definida: R1#ping 10.0.0.5 source 10.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds: Packet sent with a source address of 10.0.0.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/42/52 ms

Nesse ponto, o aluno pode estar novamente se questionando: qual o impacto para o iBGP e para o monitoramento da rede se não consigo mais “pingar” o IP das interfaces? Dada as múltiplas redundâncias disponíveis na rede, as melhores práticas do iBGP é que as sessões iBGP sejam feitas entre interfaces loopbacks, haja vista que essas não ficam indisponíveis com quedas de enlaces. Quanto ao monitoramento via ping, esse realmente não é possível, mas via SNMP é possível monitorá-las, além do Syslog. O IETF também criou a RFC 5837 para expandir o ICMP a fim de ajudar nesse tipo de situação. Em breve as ferramentas de traceroute estarão disponíveis com suporte a RFC 5837, que permitirão o traceroute fornecer informações sobre as interfaces envolvidas no caminho IP. As alterações propostas na RFC 6860 permitem que em uma rede OSPF dispositivos que suportem supressão de prefixo funcionem com dispositivos que não suportam tal funcionalidade. Nesse caso, o roteador que não suportar supressão de prefixos vai funcionar do modo normal e, no caso de enlaces do Tipo 2, vai criar uma rota /32 apontando para o DR da rede. Apesar de não ser parte do contexto desse material, supressão de prefixos tem sido muito utilizado em redes MPLS. Nessas redes, quando se utiliza o protocolo LDP (Label Distribution Protocol), um label MPLS é associado a cada prefixo do IGP. Quanto mais prefixos, mais labels são utilizados, o que também consome recursos extras do roteador OSPF/MPLS.

OSPF Avançado

Monitorando o OSPF com a RFC 4750: OSPF Version 2 MIB

142

11 Redes de computadores devem ter seus ativos de rede e protocolos monitorados constantemente. 11 O protocolo SNMP (Simple Network Management Protocol) provê diversas informações para operação da rede.

q

11 Itens como utilização e erros das interfaces, CPU e memória, fontes, ventiladores e

q

laser recebido nas interfaces são itens mínimos a serem monitorados. 11 Monitoramento OSPF via SNMP está definido na RFC 4750, que especifica a Management Information Base (MIB) do OSPF. 11 Diversos objetos estão contemplados e disponíveis para os operadores de rede. 11 Esses objetos podem ser monitorados por qualquer NMS (Network Management System) disponível que use SNMP, como Nagios, Cacti e Zabbix etc. Até esse ponto, diversas funcionalidades, técnicas e abordagens para configurar o protocolo OSPF foram apresentadas para fazer a rede OSPF robusta, escalável e funcional. Porém, o Engenheiro de Redes não pode apenas configurar os roteadores e esquecê-los. Todos os ativos da rede precisam ser monitorados constantemente, para que quando houver algum incidente, o Engenheiro de Redes tenha informação suficiente para identificar, isolar e restaurar a rede. Normalmente, apenas os monitoramentos padrão são feitos utilizando SNMP (Simple Network Management Protocol): utilização e erros nas interfaces, quantidade de pacotes unicast, broadcast e multicast, uso de CPU e memória, e poucos outros. Porém, via SNMP, é possível monitorar muitos outros objetos, entre eles objetos relacionados ao protocolo OSPF. A RFC 4750 especifica a Management Information Base (MIB), que descreve quais objetos são monitorados e quais são os identificadores desses objetos (OID: Object Identifier). O SNMP é suportado em praticamente todos os Sistemas Operacionais de uso geral: Microsoft Windows, GNU/Linux, Unix e MAC OS X, e por todos os fabricantes de equipamentos de rede corporativas. Atualmente, existem diversas MIBs que podem ser utilizadas para monitorar desde interface de rede até objetos do próprio Sistema Operacional, como transações de bancos de dados. Aplicações como MRTG e Cacti se consolidaram como interfaces web para o SNMP; aplicações mais modernas, como Zabbix, e algumas proprietárias, como o Tivoli ou CA, também fazem uso do SNMP nativamente. Como não é um monitoramento comumente implantado, muitos desses softwares mencionados não possuem templates já prontos para usar com OSPF, mas há vasta documentação na internet – não é dificil criá-los. Porém, mais importante que apresentar as ferramentas, é apresentar a MIB especificada na RFC 4750 e descrever os principais objetos que podem ser monitorados. 11 A MIB do OSPF consiste das seguintes tabelas:

q

22 Estrutura de Dados de Áreas 22 Tabela de Métricas de Áreas Sub 22 Link State Database 22 Tabelas de range de endereços e Hosts Para ajudar no entendimento, as seções que compõem a MIB do OSPF serão apresentadas, bem como o OID da tabela e os principais objetos a serem explorados adiante.


22 Variáveis Gerais

143

Tabela

OID

Principais Objetos

Variáveis Gerais (General Variables): descreve variáveis globais do processo OSPF

ospfGeneralGroup 1.3.6.1.2.1.14.1

ospfRouterId

Estrututas de Dados de Áreas (Area Data Structure): descreve todas as áreas da qual o roteador faz parte

ospfAreaTable 1.3.6.1.2.1.14.2

ospfAreaId ospfAuthType

Tabela de Métricas de Áreas Stub (Area Stub Metric Table): descreve as métricas enviadas para a(s) área(s) Stub

ospfStubAreaTable

ospfStubAreaId

Link State Database (LSDB): provê informações do LSDB para tratamento de erros

ospfLsdbTable

Tabela de Range de Endereços (Address Range Table): provê informações sobre sumários e rotas de hosts

ospfAreaRangeTable

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

ospfHostTable

ospfHostMetric

1.3.6.1.2.1.14.6

ospfHostAreaID

Tabela de Interfaces (Interface Table): provê informações sobre as interfaces OSPF

ospfIfTable 1.3.6.1.2.1.14.7

ospfIfType

ospfAdminStat

1.3.6.1.2.1.14.3 ospfLsdbAreaId

1.3.6.1.2.1.14.4 ospfAreaRangeNet

1.3.6.1.2.1.14.5

ospfIfHelloInterval ospfIfDesignatedRouter

Tabela de Métrica de Interface (Interface Metric Table): provê informações de métrica das interfaces OSPF

ospfIfMetricTable

ospfIfMetricValue

Tabela de Interface Virtual (Virtual Interface Table): provê informações sobre os Virtual Links

ospfVirtIfTable 1.3.6.1.2.1.14.9

ospfVirtIfNeighbor

Tabela de Vizinho (Neighbor Table): descreve os vizinhos OSPF

ospfNbrTable 1.3.6.1.2.1.14.10

ospfNbrIpAddr

1.3.6.1.2.1.14.8

ospfNbrRtrId ospfNbrState

Tabela de Vizinho Virtual (Virtual Neighbor Table): descreve os vizinhos OSPF usando Virtual Links

ospfVirtNbrTable

ospfVirtNbrArea

1.3.6.1.2.1.14.11

ospfVirtNbrRtrId

LSDB Externo (External Link State Database): provê informações do LSDB para tratamento de erros

ospfExtLsdbTable

ospfExtLsdbType

Tabela de Range Agregado (Aggregate Range Table): informa os prefixos sumarizados

ospfAreaAggregateTable

LSDB Local (Local Link State Database): idêntico ao LSDB mas contém apenas LSAs Opacos (Tipo 9)

ospfLocalLsdbTable

LSDB escopo AS (AS-scope Link State Database): idêntico ao LSDB mas contém apenas LSAs Externos

ospfAsLsdbTable

1.3.6.1.2.1.14.12

1.3.6.1.2.1.14.19

11 Tabelas de Interface, Métrica de Interface e Interface Virtual;

OSPF Avançado

11 LSDB Externo, LSDB Local, LSBD escopo AS;

144

11 Tabela de Range Agregado.

ospfLocalLsdbEntry

1.3.6.1.2.1.14.17

Continuação das tabelas disponíveis na MIB do OSPF:

11 Tabelas de Vizinho e Vizinho Virtual;

ospfAreaAggregateAreaID

1.3.6.1.2.1.14.14

ospfAsLsdbEntry

q

Tabela 4.1 Seções que compõem a MIB do OSPF.

l Cada seção possui diversos objetos, que podem ser do tipo "somente leitura" (read-only) ou "leitura e escrita" (read-write). É importante o aluno ter em mente que um roteador mal-configurado pode criar riscos de segurança.

Conforme mencionado anteriormente, a MIB do OSPF foi criada para permitir o monitoramento remoto dos objetos, tabelas e parâmetros que compõem a operação do OSPF em um determinado roteador. Os resultados obtidos via SNMP também podem ser obtidos pela linha de comando do equipamento; porém, em ambientes com muitos equipamentos, o ideal é automatizar a operação e monitoramento. Para ilustrar as saídas possíveis, vamos utilizar a topologia da figura 4.7.

q

11 A MIB OSPF possui o OID 1.3.6.1.2.1.14 11 Cada tabela tem um OID - Object Identifier que a representa, através de um índice especifico. 11 Exemplos: 22 Variáveis gerais - Índice 1 - 1.3.6.1.2.1.14.1 22 Tabela de Interfaces - Índice 7 - 1.3.6.1.2.1.14.7 11 Para demonstrar a utilização da MIB do OSPF, a figura 4.7 será utilizada. A topologia da figura possui diversas configurações, como tipos de área, de autenticação, de rede e métricas diferentes. Todas as configurações já são de conhecimento dos alunos.

R1

Area 1 Stub

R2 10.1.2.0/24

10.2.3.0/24

192.168.3.0/24

.0/ 6.1 2.1 17

4-

/2

5.0 D5

M

10.2.4.0/24 Senha Simples Custo 15

.2.

10

24

192.168.1.0/24

R3

10.4.5.0/24

192.168.2.0/24

R4 Figura 4.7 SNMP.

Area 2

R5

Essa rede possui as seguintes características: 11 Cinco roteadores OSPF, atuando como roteadores internos (R3), ABR (R2, R4 e R5) e ASBR (R1); 11 Os enlaces R1-R2 e R4-R5 não possuem autenticação; 11 O enlace R2-R5 possui autenticação MD5; 11 O enlace R2-R4 possui autenticação simples; 11 Além da Área Backbone, há uma área Stub (Area 1) e uma Área Normal (Área 2); 11 R1 faz a redistribuição do prefixo 192.168.1.0/24 na Área Backbone; 11 O enlace R2-R4 possui custo alterado para 15; 11 O enlace R2-R5 está configurado como ponto-a-ponto; 11 R4 gera um LSA-Summary para o prefixo 192.168.2.0/24; 11 Um Virtual Link será criado entre R4 e R5; 11 Um servidor de gerência, com pacote SNMP instalado, foi instalado com o IP 172.16.1.2.


Gerência

145

11 Todas as consultas SNMP serão feitas a partir de um servidor Linux com o pacote

q

SNMP instalado. 11 As consultas foram feitas com o comando snmpwalk, SNMP versão 2 e a community (senha) public. 11 Nos roteadores, a configuração a seguir foi feita para habilitar o SNMP: configure terminal snmp-server community public

11 Não habilite essa configuração em ambientes de produção, a menos que troque a community.. O servidor Gerência possui o pacote SNMP instalado, o que lhe dá acesso às ferramentas de consulta e modificação via SNMP. Nos exemplos a seguir, o comando snmpwalk será utilizado, sempre com a community SNMP "public" e a versão 2 do SNMP (2c). A community é equivalente a uma senha de acesso e deve ser configurada no roteador. Em ambientes de produção, considere utilizar communities mais complexas e a versão 3 do SNMP, que suporta autenticação. Antes de iniciar as consultas SNMP, o seguinte comando deve ser aplicado em cada roteador: configure terminal snmp-server community public

Atenção: esse comando habilita o processo SNMP no roteador, e permite consultas que usarem a community "public". Não aplique esse comando dessa maneira em equipamentos de produção, a menos que saiba exatamente o que está fazendo! No servidor de gerência, a MIB OSPF deve estar instalada. A configuração do SNMP e a instalação da MIB OSPF serão apresentados como parte das atividades práticas da sessão de aprendizagem 4. A seguir, as principais tabelas serão apresentadas, usando como referência o nome do OID apresentado na tabela de OIDs, com os principais objetos exemplificados. Caso queira conhecer todos os objetos disponíveis, consulte a RFC 4750.

Explorando a tabela ospfGeneralGroup (Variáveis Globais) 11 A tabela Variáveis Globais é representada pelo objeto ospfGeneralGroup, com ID 1.3.6.1.2.1.14.1. 11 Observe os objetos disponíveis no roteador R2: snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfGeneralGroup OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2 OSPF-MIB::ospfAdminStat.0 = INTEGER: enabled(1)

OSPF Avançado

OSPF-MIB::ospfVersionNumber.0 = INTEGER: version2(2) OSPF-MIB::ospfAreaBdrRtrStatus.0 = INTEGER: true(1) OSPF-MIB::ospfASBdrRtrStatus.0 = INTEGER: false(2) OSPF-MIB::ospfExternLsaCount.0 = Gauge32: 1 OSPF-MIB::ospfExternLsaCksumSum.0 = INTEGER: 51808 OSPF-MIB::ospfTOSSupport.0 = INTEGER: false(2) OSPF-MIB::ospfOriginateNewLsas.0 = Counter32: 60

146

q

OSPF-MIB::ospfRxNewLsas.0 = Counter32: 42

q

OSPF-MIB::ospfExtLsdbLimit.0 = INTEGER: -1 OSPF-MIB::ospfMulticastExtensions.0 = INTEGER: 0 OSPF-MIB::ospfExitOverflowInterval.0 = INTEGER: 0 OSPF-MIB::ospfDemandExtensions.0 = INTEGER: true(1)

11 É possível ver na saída o router-id configurado em R2, a versão do OSPF, o tipo de roteador (ABR). Vamos iniciar com a OID ospfGeneralGroup (1.3.6.1.2.1.14.1), consultando o roteador R2. Os objetos mais importantes estão em negrito: snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfGeneralGroup OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2 OSPF-MIB::ospfAdminStat.0 = INTEGER: enabled(1) OSPF-MIB::ospfVersionNumber.0 = INTEGER: version2(2) OSPF-MIB::ospfAreaBdrRtrStatus.0 = INTEGER: true(1) OSPF-MIB::ospfASBdrRtrStatus.0 = INTEGER: false(2) OSPF-MIB::ospfExternLsaCount.0 = Gauge32: 1 OSPF-MIB::ospfExternLsaCksumSum.0 = INTEGER: 51808 OSPF-MIB::ospfTOSSupport.0 = INTEGER: false(2) OSPF-MIB::ospfOriginateNewLsas.0 = Counter32: 60 OSPF-MIB::ospfRxNewLsas.0 = Counter32: 42 OSPF-MIB::ospfExtLsdbLimit.0 = INTEGER: -1 OSPF-MIB::ospfMulticastExtensions.0 = INTEGER: 0 OSPF-MIB::ospfExitOverflowInterval.0 = INTEGER: 0 OSPF-MIB::ospfDemandExtensions.0 = INTEGER: true(1)

É possível ver nessa saída acima o router-id do roteador: OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2

Além do router-id, podemos ver que o processo OSPF está habilitado: OSPF-MIB::ospfAdminStat.0 = INTEGER: enabled(1)

A versão do OSPF, nesse caso, versão 2: OSPF-MIB::ospfVersionNumber.0 = INTEGER: version2(2)

OSPF-MIB::ospfAreaBdrRtrStatus.0 = INTEGER: true(1)

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

Vamos consultar o router-id de cada roteador: snmpwalk -v 2c -c public 10.0.0.1 ospfRouterId OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.1 snmpwalk -v 2c -c public 10.0.0.2 ospfRouterId OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.2 snmpwalk -v 2c -c public 10.0.0.3 ospfRouterId


E que esse roteador é um ABR, já que está na Área 1 também:

147

OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.3 snmpwalk -v 2c -c public 10.0.0.4 ospfRouterId OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.4 snmpwalk -v 2c -c public 10.0.0.5 ospfRouterId OSPF-MIB::ospfRouterId.0 = IpAddress: 10.0.0.5

Nesse momento, podemos confirmar que todos os roteadores estão com o SNMP configurado e todos têm suporte a MIB do OSPF. Vamos dar prosseguimento e explorar outras tabelas.

Explorando a tabela ospfAreaTable 11 Usando a OID ospfAreaTable, podemos consultar informações sobre as Áreas OSPF.

q

11 Observe a saída de R2: snmpwalk -v 2c -c public 10.0.0.2 ospfAreaID OSPF-MIB::ospfAreaId.0.0.0.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfAreaId.0.0.0.1 = IpAddress: 0.0.0.1 snmpwalk -v 2c -c public 10.0.0.2 ospfAuthType OSPF-MIB::ospfAuthType.0.0.0.0 = INTEGER: 0 OSPF-MIB::ospfAuthType.0.0.0.1 = INTEGER: 0

11 É possível ver que R2 é um ABR (possui duas áreas (0.0.0.0 e 0.0.0.1)), sem autenticação (valor 0) por área. Vamos explorar a ospfAreaTable. Nessa tabela, os objetos mais importantes são: 11 ospfAreaID: informa as áreas presentes em um roteador; 11 ospfAuthType: informa que tipo de autenticação existe para cada área. Observe a consulta à ospfAreaTable do roteador R2. snmpwalk -v 2c -c public 10.0.0.2 ospfAreaID OSPF-MIB::ospfAreaId.0.0.0.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfAreaId.0.0.0.1 = IpAddress: 0.0.0.1 snmpwalk -v 2c -c public 10.0.0.2 ospfAuthType OSPF-MIB::ospfAuthType.0.0.0.0 = INTEGER: 0 OSPF-MIB::ospfAuthType.0.0.0.1 = INTEGER: 0

Observe que o R2 possui duas áreas (Área 0 ou Backbone e Área 1) e que não há autenticação para a área (valor 0 representa sem autenticação). Observe a consulta feita ao roteador R4, que também possui duas áreas (Backbone e Área 2) e não possui autenticação por área. snmpwalk -v 2c -c public 10.0.0.4 ospfAreaID OSPF-MIB::ospfAreaId.0.0.0.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfAreaId.0.0.0.2 = IpAddress: 0.0.0.2

OSPF Avançado

snmpwalk -v 2c -c public 10.0.0.4 ospfAuthType

148

OSPF-MIB::ospfAuthType.0.0.0.0 = INTEGER: 0 OSPF-MIB::ospfAuthType.0.0.0.2 = INTEGER: 0

Além disso, a ospfAreaTable possui os seguintes objetos que podem ser muito úteis:

q

11 ospfSpfRuns: informa a quantidade de vezes que o SPF foi executado para uma área específica. Quando há muitas modificações em um curto espaço de tempo, significa que algum enlace ou roteador está oscilando; 11 ospfAreaBdrRtrCount: informa quantos ABRs existem na área; 11 ospfAsBdrRtrCount: informa quantos ASBRs existem na área. 11 Como esses objetos estão associados às áreas, a sintaxe de saída será sempre: OSPF-MIB::OBJETO.ÁREA = Valor

11 Por exemplo: snmpwalk -v 2c -c public 10.0.0.4 ospfSpfRuns OSPF-MIB::ospfSpfRuns.0.0.0.0 = Counter32: 17 OSPF-MIB::ospfSpfRuns.0.0.0.1 = Counter32: 6

Como esses objetos estão associados às áreas, a sintaxe de saída será sempre: OSPF-MIB::OBJETO.ÁREA = Valor

Observe a saída de R2 com esses objetos, com as áreas adicionadas à OID: snmpwalk -v 2c -c public 10.0.0.4 ospfSpfRuns OSPF-MIB::ospfSpfRuns.0.0.0.0 = Counter32: 17 OSPF-MIB::ospfSpfRuns.0.0.0.1 = Counter32: 6 snmpwalk -v 2c -c public 10.0.0.4 ospfAreaBdrRtrCount OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.0 = Gauge32: 3 OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.1 = Gauge32: 1 snmpwalk -v 2c -c public 10.0.0.4 ospfAsBdrRtrCount OSPF-MIB::ospfAsBdrRtrCount.0.0.0.0 = Gauge32: 1 OSPF-MIB::ospfAsBdrRtrCount.0.0.0.1 = Gauge32: 0

Na topologia da figura 4.7, existem três ABRs na Área Backbone e um ABBR. Na Área 1, só há um ABR e nenhum ASBR. Lembre-se de que essa consulta é feita por roteador. Logo, se consultarmos R4, veremos informações também da Área 2: snmpwalk -v 2c -c public 10.0.0.4 ospfSpfRuns OSPF-MIB::ospfSpfRuns.0.0.0.0 = Counter32: 8 OSPF-MIB::ospfSpfRuns.0.0.0.2 = Counter32: 4 OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.0 = Gauge32: 3 OSPF-MIB::ospfAreaBdrRtrCount.0.0.0.2 = Gauge32: 2 snmpwalk -v 2c -c public 10.0.0.4 ospfAsBdrRtrCount OSPF-MIB::ospfAsBdrRtrCount.0.0.0.0 = Gauge32: 1 OSPF-MIB::ospfAsBdrRtrCount.0.0.0.2 = Gauge32: 0


snmpwalk -v 2c -c public 10.0.0.4 ospfAreaBdrRtrCount

149

Explorando a tabela ospfStubAreaTable 11 A tabela ospfStubAreaTable só existe nos roteadores que possuem um Área Stub.

q

11 Caso o roteador consultado não possua um Área Stub, esse erro será visto: snmpwalk -v 2c -c public 10.0.0.4 ospfStubAreaId OSPF-MIB::ospfStubAreaId = No Such Instance currently exists at this OID

11 A Área 1 é Stub, logo: snmpwalk -v 2c -c public 10.0.0.2 ospfStubAreaId OSPF-MIB::ospfStubAreaId.0.0.0.1.0 = IpAddress: 0.0.0.1

11 Além disso, é possível ver a métrica associada à rota padrão gerada pelo ABR: snmpwalk -v 2c -c public 10.0.0.2 ospfStubMetric OSPF-MIB::ospfStubMetric.0.0.0.1.0 = INTEGER: 1

11 Que pela linha de comando pode ser vista com : R3#show ip route ospf O*IA 0.0.0.0/0 [110/2] via 10.2.3.2, 00:00:14, FastEthernet2/0

11 Nesse caso, em R3 a rota tem métrica 2, 1 da própria interface FastEthernet e 1 da rota enviada por R2 A tabela ospfStubAreaTable só existe nos roteadores que possuem um Área Stub. Caso o roteador consultado não possua um Área Stub, esse erro será visto: snmpwalk -v 2c -c public 10.0.0.4 ospfStubAreaId OSPF-MIB::ospfStubAreaId = No Such Instance currently exists at this OID

Esse erro significa que a tabela não existe nesse roteador. Como o roteador R2 está conectado à Área 1 que é Stub, essa tabela estará presente: snmpwalk -v 2c -c public 10.0.0.2 ospfStubAreaId OSPF-MIB::ospfStubAreaId.0.0.0.1.0 = IpAddress: 0.0.0.1

Outros objetos podem ser consultados, como o ospfStubMetric, que informa o custo associado à rota padrão gerada pelo ABR: snmpwalk -v 2c -c public 10.0.0.2 ospfStubMetric OSPF-MIB::ospfStubMetric.0.0.0.1.0 = INTEGER: 1

Nesse caso, o custo foi de 1, como pode ser visto pela linha de comando em R3: R3#sh ip route ospf O*IA 0.0.0.0/0 [110/2] via 10.2.3.2, 00:00:14, FastEthernet2/0

O valor da métrica total é de 2: 1 da interface FastEthernet + 1 anunciado por R2 para essa rota. Observe a troca do custo em R2:

OSPF Avançado

configure terminal

150

router ospf 10 area 1 default-cost 5

Confirmando via linha de comando e via SNMP: R3#sh ip route ospf O*IA 0.0.0.0/0 [110/6] via 10.2.3.2, 00:00:37, FastEthernet2/0 snmpwalk -v 2c -c public 10.0.0.2 ospfStubMetric OSPF-MIB::ospfStubMetric.0.0.0.1.0 = INTEGER: 5

É possível observar que tanto via SNMP quanto via CLI é possível monitorar o custo da rota padrão na Área Stub.

Explorando a tabela ospfLsdbTable 11 A tabela ospfLsdbTable apresenta o LSDB inteiro, de cada área

q

11 Contém os LSA existentes, número de sequência, Age, tipos, etc. 11 Observe a saída abaixo, apresentando os LSAs por tipo, usando o formato: 22 OSPF-MIB::ospfLsdbAreaId.AREA.TIPO.LINK_ID.ADV_ROUTER IpAddress: AREA $ snmpwalk -v 2c -c public 10.0.0.2 ospfLsdbAreaId (Saída simplificada) OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.1.10.0.0.1 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.routerLink.10.0.0.2.10.0.0.2 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.networkLink.10.2.4.2.10.0.0.2 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.2.1.10.0.0.5 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.3.1.10.0.0.2 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.2.10.0.0.2 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.3.10.0.0.3 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.networkLink.10.2.3.2.10.0.0.2 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.summaryLink.0.0.0.0.10.0.0.2 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 0.0.0.1

A tabela ospfLsdbTable apresenta o LSDB inteiro, de cada área. Nessa tabela podemos observar quais são os LSAs existentes, número de sequência, Age, tipos etc. É possível inclusive ver o LSA anunciado, em formato hexadecimal. Dessa tabela, o objeto mais importante é o ospfLsdbAreaId. Observe a saída a seguir de R2: a saída do comando snmpwalk foi quebrada em blocos por tipo de LSA. A sintaxe tem a seguinte forma:

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


OSPF-MIB::ospfLsdbAreaId.AREA.TIPO.LINK_ID.ADV_ROUTER IpAddress: aREA

151

OSPF-MIB::ospfLsdbAreaId.0.0.0.0.networkLink.10.2.4.2.10.0.0.2 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.3.10.0.0.2 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.4.10.0.0.4 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.4.10.0.0.5 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.5.10.0.0.4 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.0.0.5.10.0.0.5 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.2.3.0.10.0.0.2 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.4.5.0.10.0.0.4 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.10.4.5.0.10.0.0.5 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.2.0.10.0.0.4 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.2.1.10.0.0.5 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.summaryLink.192.168.3.1.10.0.0.2 = IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.0.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 0.0.0.0 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.2.10.0.0.2 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.routerLink.10.0.0.3.10.0.0.3 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.networkLink.10.2.3.2.10.0.0.2 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.summaryLink.0.0.0.0.10.0.0.2 = IpAddress: 0.0.0.1 OSPF-MIB::ospfLsdbAreaId.0.0.0.1.asExternalLink.192.168.1.0.10.0.0.1=IpAddress: 0.0.0.1

O primeiro bloco está associado aos LSAs do tipo Router na Área Backbone (0.0.0.0). É possível ver os roteadores R1, R2, R4 e R5. O segundo bloco está associado aos LSAs do tipo Network na Área Backbone (0.0.0.0). É possível ver os segmentos R1-R2 (10.1.2.0) e R2-R4 (10.2.4.0). Lembre-se de que o enlace com R5 foi configurado como Ponto-a-Ponto, por isso não existe um LSA Network. O terceiro bloco está associado aos LSAs do tipo Summary na Área Backbone (0.0.0.0). O quarto bloco lista os LSAs do tipo AS-External. Na sequência, os mesmos tipos de LSA para a Área 1 (0.0.0.1).

Explorando a tabela ospfHostTable 11 A tabela ospfHostTable mostra informações sobre as interfaces de usuário, ou hosts(interfaces passivas). 11 Essas interfaces não tem roteadores OSPF como vizinhos 11 Objetos mais importantes: ospfHostMetric e ospfHostAreaID 11 Exemplo:

OSPF Avançado

$ snmpwalk -v 2c -c public 10.0.0.3 OSPF-MIB::ospfHostTable OSPF-MIB::ospfHostMetric.10.0.0.3.0 = INTEGER: 1 OSPF-MIB::ospfHostMetric.192.168.3.1.0 = INTEGER: 1 OSPF-MIB::ospfHostAreaID.10.0.0.3.0 = IpAddress: 0.0.0.1 OSPF-MIB::ospfHostAreaID.192.168.3.1.0 = IpAddress: 0.0.0.1 $ snmpwalk -v 2c -c public 10.0.0.4 .1.3.6.1.2.1.14.6 OSPF-MIB::ospfHostMetric.10.0.0.4.0 = INTEGER: 1

152

q

OSPF-MIB::ospfHostMetric.192.168.2.1.0 = INTEGER: 1

q

OSPF-MIB::ospfHostAreaID.10.0.0.4.0 = IpAddress: 0.0.0.2 OSPF-MIB::ospfHostAreaID.192.168.2.1.0 = IpAddress: 0.0.0.2

A tabela ospfHostTable mostra informações sobre as interfaces de usuário ou hosts. Essas interfaces não têm roteadores OSPF como vizinhos. Dessa tabela, os objetos mais importantes são: 11 ospfHostMetric: métrica associada à interface; 11 ospfHostAreaID: área da qual a interface faz parte. Observe a seguir o snmpwalk. Os demais objetos foram omitidos para simplificar a visualização. $ snmpwalk -v 2c -c public 10.0.0.3 OSPF-MIB::ospfHostTable OSPF-MIB::ospfHostMetric.10.0.0.3.0 = INTEGER: 1 OSPF-MIB::ospfHostMetric.192.168.3.1.0 = INTEGER: 1 OSPF-MIB::ospfHostAreaID.10.0.0.3.0 = IpAddress: 0.0.0.1 OSPF-MIB::ospfHostAreaID.192.168.3.1.0 = IpAddress: 0.0.0.1 snmpwalk -v 2c -c public 10.0.0.4 .1.3.6.1.2.1.14.6 OSPF-MIB::ospfHostMetric.10.0.0.4.0 = INTEGER: 1 OSPF-MIB::ospfHostMetric.192.168.2.1.0 = INTEGER: 1 OSPF-MIB::ospfHostAreaID.10.0.0.4.0 = IpAddress: 0.0.0.2 OSPF-MIB::ospfHostAreaID.192.168.2.1.0 = IpAddress: 0.0.0.2

É possível ver o custo ou métrica da interface com valor 1 e a área à qual as interfaces pertencem (0.0.0.1 – Área 1 e 0.0.0.2 – Área 2).

Explorando a tabela ospfIfTable 11 A tabela ospfIfTable mostra diversas informações sobre as interfaces OSPF

q

11 Principais objetos: 22 ospfIfAreaId: informa a área da qual a interface faz parte. A interface é representada pelo IP que possui. Formato: 33 OSPF-MIB::ospfIfAreaId.IP.0 = IpAddress: AREA 22 ospfIfType: informa o tipo de rede da interface (broadcast(1), pointToPoint(3), nbma(2) e pointToMultipoint(4)) 22 ospfIfRtrPriority: informa a prioridade da interface para escolha do DR

q

22 ospfIfState: O estado da interface. Pode ser down, loopback, waiting, pointToPoint, designatedRouter, backupDesignatedRouter ou otherDesignatedRouter. 22 ospfIfAuthType: Informa o tipo de autenticação configurada na interface. 0 significa sem autenticação, 1 significa autenticação simples, 2 significa autenticação com MD5. A tabela ospfIfTable mostra diversas informações sobre as interfaces OSPF, e os principais objetos são: 11 ospfIfAreaId: informa a área da qual a interface faz parte. Observe que a interface é representada pelo IP que possui, e não pelo nome da interface. O formato está apresentado a seguir: OSPF-MIB::ospfIfAreaId.IP.0 = IpAddress: AREA


22 ospfIfHelloInterval, ospfIfRtrDeadInterval: informam o Hello e o Dead Interval

153

11 ospfIfType: informa o tipo de rede da interface. Os tipos podem ser broadcast(1), pointToPoint(3), nbma(2) e pointToMultipoint(4). Novamente, o endereço IP da interface é utilizado ao invés do nome da interface; 11 ospfIfRtrPriority: informa a prioridade da interface para escolha do DR. Prioridade 0 é não elegível, muito comum em redes ponto-a-ponto; 11 ospfIfHelloInterval: indica o intervalo Hello da interface. O padrão é 10 segundos; 11 ospfIfRtrDeadInterval: informa o intervalo Dead Interval da interface, indicando quando o roteador vizinho será considerado desconectado. O padrão é 40 segundos; 11 ospfIfState: o estado da interface. Pode ser down, loopback, waiting, pointToPoint, designatedRouter, backupDesignatedRouter ou otherDesignatedRouter; 11 ospfIfAuthType: indica o tipo de autenticação configurada na interface. 0 significa sem autenticação, 1 significa autenticação simples, 2 significa autenticação com MD5. Observe a seguir o snmpwalk do roteador R2 e do roteador R5. Os demais objetos foram omitidos para simplificar a visualização. Analise a saída e veja se corresponde com a descrição da topologia da figura 4.7. $ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfIfTable OSPF-MIB::ospfIfAreaId.10.0.0.2.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfAreaId.10.1.2.2.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfAreaId.10.2.3.2.0 = IpAddress: 0.0.0.1 OSPF-MIB::ospfIfAreaId.10.2.4.2.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfAreaId.10.2.5.2.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfType.10.0.0.2.0 = INTEGER: pointToPoint(3) OSPF-MIB::ospfIfType.10.1.2.2.0 = INTEGER: broadcast(1) OSPF-MIB::ospfIfType.10.2.3.2.0 = INTEGER: broadcast(1) OSPF-MIB::ospfIfType.10.2.4.2.0 = INTEGER: broadcast(1) OSPF-MIB::ospfIfType.10.2.5.2.0 = INTEGER: pointToPoint(3) OSPF-MIB::ospfIfRtrPriority.10.0.0.2.0 = INTEGER: 0 OSPF-MIB::ospfIfRtrPriority.10.1.2.2.0 = INTEGER: 1 OSPF-MIB::ospfIfRtrPriority.10.2.3.2.0 = INTEGER: 1 OSPF-MIB::ospfIfRtrPriority.10.2.4.2.0 = INTEGER: 1 OSPF-MIB::ospfIfRtrPriority.10.2.5.2.0 = INTEGER: 0 OSPF-MIB::ospfIfHelloInterval.10.0.0.2.0 = INTEGER: 10 OSPF-MIB::ospfIfHelloInterval.10.1.2.2.0 = INTEGER: 10 OSPF-MIB::ospfIfHelloInterval.10.2.3.2.0 = INTEGER: 10 OSPF-MIB::ospfIfHelloInterval.10.2.4.2.0 = INTEGER: 10 OSPF-MIB::ospfIfHelloInterval.10.2.5.2.0 = INTEGER: 10 OSPF-MIB::ospfIfRtrDeadInterval.10.0.0.2.0 = INTEGER: 40 OSPF-MIB::ospfIfRtrDeadInterval.10.1.2.2.0 = INTEGER: 40 OSPF-MIB::ospfIfRtrDeadInterval.10.2.3.2.0 = INTEGER: 40 OSPF-MIB::ospfIfRtrDeadInterval.10.2.4.2.0 = INTEGER: 40 OSPF-MIB::ospfIfRtrDeadInterval.10.2.5.2.0 = INTEGER: 40 OSPF Avançado

OSPF-MIB::ospfIfState.10.0.0.2.0 = INTEGER: loopback(2)

154

OSPF-MIB::ospfIfState.10.1.2.2.0 = INTEGER: designatedRouter(5) OSPF-MIB::ospfIfState.10.2.3.2.0 = INTEGER: designatedRouter(5) OSPF-MIB::ospfIfState.10.2.4.2.0 = INTEGER: designatedRouter(5) OSPF-MIB::ospfIfState.10.2.5.2.0 = INTEGER: pointToPoint(4) OSPF-MIB::ospfIfAuthType.10.0.0.2.0 = INTEGER: 0

OSPF-MIB::ospfIfAuthType.10.1.2.2.0 = INTEGER: 0 OSPF-MIB::ospfIfAuthType.10.2.3.2.0 = INTEGER: 0 OSPF-MIB::ospfIfAuthType.10.2.4.2.0 = INTEGER: 1 OSPF-MIB::ospfIfAuthType.10.2.5.2.0 = INTEGER: 2 snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfIfTable OSPF-MIB::ospfIfAreaId.10.0.0.5.0 = IpAddress: 0.0.0.2 OSPF-MIB::ospfIfAreaId.10.2.5.5.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfAreaId.10.4.5.5.0 = IpAddress: 0.0.0.2 OSPF-MIB::ospfIfType.10.0.0.5.0 = INTEGER: pointToPoint(3) OSPF-MIB::ospfIfType.10.2.5.5.0 = INTEGER: pointToPoint(3) OSPF-MIB::ospfIfType.10.4.5.5.0 = INTEGER: broadcast(1) OSPF-MIB::ospfIfRtrPriority.10.0.0.5.0 = INTEGER: 0 OSPF-MIB::ospfIfRtrPriority.10.2.5.5.0 = INTEGER: 0 OSPF-MIB::ospfIfRtrPriority.10.4.5.5.0 = INTEGER: 1 OSPF-MIB::ospfIfHelloInterval.10.0.0.5.0 = INTEGER: 10 OSPF-MIB::ospfIfHelloInterval.10.2.5.5.0 = INTEGER: 10 OSPF-MIB::ospfIfHelloInterval.10.4.5.5.0 = INTEGER: 10 OSPF-MIB::ospfIfRtrDeadInterval.10.0.0.5.0 = INTEGER: 40 OSPF-MIB::ospfIfRtrDeadInterval.10.2.5.5.0 = INTEGER: 40 OSPF-MIB::ospfIfRtrDeadInterval.10.4.5.5.0 = INTEGER: 40 OSPF-MIB::ospfIfState.10.0.0.5.0 = INTEGER: loopback(2) OSPF-MIB::ospfIfState.10.2.5.5.0 = INTEGER: pointToPoint(4) OSPF-MIB::ospfIfState.10.4.5.5.0 = INTEGER: designatedRouter(5) OSPF-MIB::ospfIfDesignatedRouter.10.0.0.5.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfDesignatedRouter.10.2.5.5.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfDesignatedRouter.10.4.5.5.0 = IpAddress: 10.4.5.5 OSPF-MIB::ospfIfBackupDesignatedRouter.10.0.0.5.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfBackupDesignatedRouter.10.2.5.5.0 = IpAddress: 0.0.0.0 OSPF-MIB::ospfIfBackupDesignatedRouter.10.4.5.5.0 = IpAddress: 10.4.5.4 OSPF-MIB::ospfIfAuthType.10.0.0.5.0 = INTEGER: 0 OSPF-MIB::ospfIfAuthType.10.2.5.5.0 = INTEGER: 2 OSPF-MIB::ospfIfAuthType.10.4.5.5.0 = INTEGER: 0

Observe a tabela ospfIfTable de R2 (simplificada):

q

$ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfIfTable OSPF-MIB::ospfIfAreaId.10.2.3.2.0 = IpAddress: 0.0.0.1 OSPF-MIB::ospfIfType.10.2.4.2.0 = INTEGER: broadcast(1) OSPF-MIB::ospfIfType.10.2.5.2.0 = INTEGER: pointToPoint(3) OSPF-MIB::ospfIfRtrPriority.10.0.0.2.0 = INTEGER: 0 OSPF-MIB::ospfIfRtrPriority.10.1.2.2.0 = INTEGER: 1 OSPF-MIB::ospfIfHelloInterval.10.2.5.2.0 = INTEGER: 10 OSPF-MIB::ospfIfRtrDeadInterval.10.2.5.2.0 = INTEGER: 40 OSPF-MIB::ospfIfState.10.0.0.2.0 = INTEGER: loopback(2) OSPF-MIB::ospfIfState.10.1.2.2.0 = INTEGER: designatedRouter(5) OSPF-MIB::ospfIfAuthType.10.0.0.2.0 = INTEGER: 0 OSPF-MIB::ospfIfAuthType.10.2.5.2.0 = INTEGER: 2


OSPF-MIB::ospfIfAreaId.10.0.0.2.0 = IpAddress: 0.0.0.0

Observe que a interface com IP 10.0.0.2, não possui autenticação (ofpfIfAuthType = 0) 155

Pelas saídas citadas, é possível identificar quais são as interfaces Loopback, Ponto a Ponto e Broadcast, além de saber quais possuem autenticação. Apenas usando o SNMP, o Engenheiro da Rede pode consultar todos os roteadores OSPF e validar se as configurações estão corretas e de acordo com a Política de Segurança. Por exemplo, com um script de poucas linhas de código é possível ver que existem interfaces que não têm autenticação, oferecendo riscos à infraestrutura de rede.

Explorando a tabela ospfVirtIfTable 11 A tabela ospfVirtIfTable descreve as configurações relacionadas aos Virtual Links.

q

11 A mesma só existe em roteadores que tem Virtual-Link ativado 11 Exemplo da tabela a partir do roteador R5: $ snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfVirtIfTable OSPF-MIB::ospfVirtIfAreaId.0.0.0.2.10.0.0.4 = IpAddress: 0.0.0.2 OSPF-MIB::ospfVirtIfNeighbor.0.0.0.2.10.0.0.4 = IpAddress: 10.0.0.4 OSPF-MIB::ospfVirtIfHelloInterval.0.0.0.2.10.0.0.4 = INTEGER: 10 OSPF-MIB::ospfVirtIfRtrDeadInterval.0.0.0.2.10.0.0.4 = INTEGER: 40 OSPF-MIB::ospfVirtIfAuthType.0.0.0.2.10.0.0.4 = INTEGER: 0

11 É possível ver a área de trânsito (0.0.0.2), o IP do neighbor (10.0.0.4 - R4), valores de Hello e Dead Interval e se existe autenticação (0 significa sem autenticação). A tabela ospfVirtIfTable descreve as configurações relacionadas aos Virtual Links e só existe em roteadores que têm Virtual-Link ativado. Na topologia da figura 4.7, existe um Virtual-Link entre R4 e R5. Observe o snmpwalk a seguir, onde a tabela ospfVirtIfTable foi consultada: $ snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfVirtIfTable OSPF-MIB::ospfVirtIfAreaId.0.0.0.2.10.0.0.4 = IpAddress: 0.0.0.2 OSPF-MIB::ospfVirtIfNeighbor.0.0.0.2.10.0.0.4 = IpAddress: 10.0.0.4 OSPF-MIB::ospfVirtIfHelloInterval.0.0.0.2.10.0.0.4 = INTEGER: 10 OSPF-MIB::ospfVirtIfRtrDeadInterval.0.0.0.2.10.0.0.4 = INTEGER: 40 OSPF-MIB::ospfVirtIfAuthType.0.0.0.2.10.0.0.4 = INTEGER: 0

É possível ver qual é a área de trânsito (ospfVirtIfAreaId) (Área 2 – 0.0.0.2), quem é o vizinho do Virtual-Link (ospfVirtIfNeighbor) (R4 – 10.0.0.4), se há autenticação (ospfVirtIfAuthType) (0 – não há) e valores de Hello (ospfVirtIfHelloInterval) e Dead Interval (ospfVirtIfRtrDeadInterval).

Explorando a tabela ospfNbrTable 11 A tabela ospfNbrTable descreve as vizinhanças estabelecidas pelo roteador OSPF 11 Essa é uma das tabelas mais importantes 11 Objetos mais importantes: 22 ospfNbrIpAddr: informa o endereço IP da interface do vizinho OSPF 22 ospfNbrRtrId: informa o Router-ID do vizinho OSPF OSPF Avançado

22 ospfNbrPriority: informa a prioridade para escolha do DR. 22 spfNbrState: informa o estado de sincronismo do LSDB. Os estados possíveis são: down (1), attempt (2), init (3), twoWay (4), exchangeStart (5), exchange (6), loading (7) ou full (8). 11 O Engenheiro de Redes deve consultar frequentemente o objeto ospfNbrState e manter histórico de todas os valores passados para fins de resolução de problema. 156

q

A tabela ospfNbrTable descreve as vizinhanças estabelecidas pelo roteador OSPF. Essa é uma das tabelas mais importantes e que, se possível, deve ter seu monitoramento automatizado. Os objetos a seguir são extremamente úteis: 11 ospfNbrIpAddr: informa o endereço IP da interface do vizinho OSPF; 11 ospfNbrRtrId: indica o Router-ID do vizinho OSPF; 11 ospfNbrPriority: informa a prioridade para escolha do DR. Se o valor é 0, não é elegível ou é Ponto-a-Ponto; 11 ospfNbrState: indica o estado de sincronismo do LSDB. Os estados possíveis são: down (1), attempt (2), init (3), twoWay (4), exchangeStart (5), exchange (6), loading (7) ou full (8). Caso a vizinhança não esteja em "full", a menos que seja uma adjacência entre roteadores DROthers, há um problema entre os dois roteadores. Observe a seguir o snmpwalk de R5 e R2. Os demais objetos foram omitidos para simplificar a visualização. $ snmpwalk -v 2c -c public 10.0.0.5 OSPF-MIB::ospfNbrTable OSPF-MIB::ospfNbrIpAddr.10.2.5.2.0 = IpAddress: 10.2.5.2 OSPF-MIB::ospfNbrIpAddr.10.4.5.4.0 = IpAddress: 10.4.5.4 OSPF-MIB::ospfNbrRtrId.10.2.5.2.0 = IpAddress: 10.0.0.2 OSPF-MIB::ospfNbrRtrId.10.4.5.4.0 = IpAddress: 10.0.0.4 OSPF-MIB::ospfNbrPriority.10.2.5.2.0 = INTEGER: 0 OSPF-MIB::ospfNbrPriority.10.4.5.4.0 = INTEGER: 1 OSPF-MIB::ospfNbrState.10.2.5.2.0 = INTEGER: full(8) OSPF-MIB::ospfNbrState.10.4.5.4.0 = INTEGER: full(8) $ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfNbrTable OSPF-MIB::ospfNbrIpAddr.10.1.2.1.0 = IpAddress: 10.1.2.1 OSPF-MIB::ospfNbrIpAddr.10.2.3.3.0 = IpAddress: 10.2.3.3 OSPF-MIB::ospfNbrIpAddr.10.2.4.4.0 = IpAddress: 10.2.4.4 OSPF-MIB::ospfNbrIpAddr.10.2.5.5.0 = IpAddress: 10.2.5.5 OSPF-MIB::ospfNbrRtrId.10.1.2.1.0 = IpAddress: 10.0.0.1 OSPF-MIB::ospfNbrRtrId.10.2.3.3.0 = IpAddress: 10.0.0.3 OSPF-MIB::ospfNbrRtrId.10.2.4.4.0 = IpAddress: 10.0.0.4 OSPF-MIB::ospfNbrRtrId.10.2.5.5.0 = IpAddress: 10.0.0.5 OSPF-MIB::ospfNbrPriority.10.1.2.1.0 = INTEGER: 1 OSPF-MIB::ospfNbrPriority.10.2.3.3.0 = INTEGER: 1 OSPF-MIB::ospfNbrPriority.10.2.5.5.0 = INTEGER: 0 OSPF-MIB::ospfNbrState.10.1.2.1.0 = INTEGER: full(8) OSPF-MIB::ospfNbrState.10.2.3.3.0 = INTEGER: full(8) OSPF-MIB::ospfNbrState.10.2.4.4.0 = INTEGER: full(8) OSPF-MIB::ospfNbrState.10.2.5.5.0 = INTEGER: full(8)

Exemplo da tabela ofpfNbrTable a partir de R2: OSPF-MIB::ospfNbrIpAddr.10.1.2.1.0 = IpAddress: 10.1.2.1 OSPF-MIB::ospfNbrIpAddr.10.2.3.3.0 = IpAddress: 10.2.3.3 OSPF-MIB::ospfNbrIpAddr.10.2.4.4.0 = IpAddress: 10.2.4.4 OSPF-MIB::ospfNbrIpAddr.10.2.5.5.0 = IpAddress: 10.2.5.5 OSPF-MIB::ospfNbrRtrId.10.1.2.1.0 = IpAddress: 10.0.0.1

q


OSPF-MIB::ospfNbrPriority.10.2.4.4.0 = INTEGER: 1

157

OSPF-MIB::ospfNbrRtrId.10.2.3.3.0 = IpAddress: 10.0.0.3

q

OSPF-MIB::ospfNbrRtrId.10.2.4.4.0 = IpAddress: 10.0.0.4 OSPF-MIB::ospfNbrRtrId.10.2.5.5.0 = IpAddress: 10.0.0.5 OSPF-MIB::ospfNbrPriority.10.1.2.1.0 = INTEGER: 1 OSPF-MIB::ospfNbrPriority.10.2.3.3.0 = INTEGER: 1 OSPF-MIB::ospfNbrPriority.10.2.4.4.0 = INTEGER: 1 OSPF-MIB::ospfNbrPriority.10.2.5.5.0 = INTEGER: 0 OSPF-MIB::ospfNbrState.10.1.2.1.0 = INTEGER: full(8) OSPF-MIB::ospfNbrState.10.2.3.3.0 = INTEGER: full(8) OSPF-MIB::ospfNbrState.10.2.4.4.0 = INTEGER: full(8) OSPF-MIB::ospfNbrState.10.2.5.5.0 = INTEGER: full(8)

Observe que todas as vizinhanças estão no estado "full". O Engenheiro de Redes deve consultar frequentemente o objeto ospfNbrState e manter histórico de todas os valores passados para fins de resolução de problema.

Explorando a tabela ospfAreaAggregateTable 11 A tabela ospfAreaAggregateTable descreve as rotas sumarizadas pelo roteador OSPF

q

11 Caso não exista rota sumarizada, a tabela não será criada. 11 Principais objetos: 22 ospfAreaAggregateAreaID: informa a área associada à sumarização. 22 ospfAreaAggregateLsdbType: informa o tipo de sumarização sendo executado. Pode ser summaryLink (3) ou nssaExternalLink (7). 22 ospfAreaAggregateNet: informa o prefixo sumarizado; 22 ospfAreaAggregateMask: informa a máscara de sub-rede do prefixo sumarizado. A tabela ospfAreaAggregateTable descreve as rotas sumarizadas pelo roteador OSPF. Como é uma funcionalidade opcional, caso o roteador não esteja fazendo sumarização, a tabela não será criada e, quando consultada, apresentará o seguinte erro: $ snmpwalk -v 2c -c public 10.0.0.2 OSPF-MIB::ospfAreaAggregateTable OSPF-MIB::ospfAreaAggregateTable = No Such Object available on this agent at this OID

Na topologia da figura 4.7, R4 está fazendo sumarização via comando area range: router ospf area 2 range 192.168.2.0 255.255.255.0

Nesse caso, a tabela ospfAreaAggregateTable está sendo criada e tem como principais objetos: 11 ospfAreaAggregateAreaID: informa a área associada à sumarização. No caso de R4, é a Área 2 (0.0.0.2); 11 ospfAreaAggregateLsdbType: informa o tipo de sumarização sendo executado. Pode

OSPF Avançado

ser summaryLink (3) ou nssaExternalLink (7). Como em R4 foi feito com o comando area

158

range, é do tipo LSA Summary; 11 ospfAreaAggregateNet: informa o prefixo sumarizado; 11 ospfAreaAggregateMask: informa a máscara de subrede do prefixo sumarizado.

A seguir, observe a saída do snmpwalk de R4. É possível ver o prefixo 192.168.2.0/255.255.255.0 sendo sumarizado. $ snmpwalk -v 2c -c public 10.0.0.4 OSPF-MIB::ospfAreaAggregateTable OSPF-MIB::ospfAreaAggregateAreaID.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = IpAddress: 0.0.0.2 OSPF-MIB::ospfAreaAggregateLsdbType.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = INTEGER: summaryLink(3) OSPF-MIB::ospfAreaAggregateNet.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = IpAddress: 192.168.2.0 OSPF-MIB::ospfAreaAggregateMask.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = IpAddress: 255.255.255.0

Em R4 foi aplicado o seguinte comando:

q

router ospf area 2 range 192.168.2.0 255.255.255.0

Observe a saída do snmpwalk em R4: $ snmpwalk -v 2c -c public 10.0.0.4 OSPF-MIB::ospfAreaAggregateTable OSPF-MIB::ospfAreaAggregateAreaID.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = IpAddress: 0.0.0.2 OSPF-MIB::ospfAreaAggregateLsdbType.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = INTEGER: summaryLink(3) OSPF-MIB::ospfAreaAggregateNet.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = IpAddress: 192.168.2.0 OSPF-MIB::ospfAreaAggregateMask.0.0.0.2.summaryLink.192.168.2.0.255.255.255.0 = IpAddress: 255.255.255.0

Nesta última parte foram apresentados os objetos e as tabelas mais comumente utilizadas, porém outros objetos estão documentados na RFC 4750. Além disso, a RFC 4750 especifica como fazer configurações OSPF via SNMP, por isso a importância de configurações seguras. 11 Neste material, foram apresentados apenas os objetos principais. Mais objetos estão

q

disponíveis na RFC 4750 11 Além disso, a RFC 4750 especifica como fazer configurações usando SNMP. É possível adicionar uma interface ou criar uma área OSPF via SNMP.

SNMPv3 e com Listas de Controle de Acesso filtrando os prefixos de origem. 11 É importante ter essas medições integradas com algum software de gerência de rede, até para registrar o histórico das saídas. Mas não basta apenas monitorar pontualmente: é importante que essas consultas sejam integradas com algum sistema de gerência de rede, como Nagios, Cacti ou Zabbix, para que sejam criados históricos. A configuração dessa integração está fora do escopo desse material, uma vez que existe vasta documentação desses softwares. Na sessão de Atividades Práticas, o aluno será instruído como preparar um ambiente e fazer testes na linha de comando para obter as informações desejadas.


11 Por isso, garanta que está usando uma community complexa, se possível usando

159

Conclusão Nesta sessão, foram apresentados alguns tópicos que podem auxiliar o Engenheiro de Redes na implantação de redes OSPF de larga escala. Tópicos de escalabilidade e convergência foram apresentados; porém, alguns deles são relativamente novos e não são suportados por todos os fabricantes. Mas, conforme foi apresentado, muitos deles são compatíveis com a versão padrão do OSPF definida na RFC 2328, o que permite uma implementação gradual.

Comandos OSPF A seguir, uma lista de comandos de configuração que têm relação com o tema da sessão 4. Os comandos a seguir são aplicados na sessão de OSPF do roteador. 11 Habilita o ISPF no processo OSPF: ispf

11 Habilita e define o tempo de expiração do Grace LSA: nsf ietf restart-interval <0-1800>

11 Habilita BFD em todas as interfaces OSPF: bfd all-interfaces

11 Habilita supressão dos prefixos de todas as redes de trânsito do roteador OSPF: prefix-suppresion

Os comandos a seguir são aplicados na configuração das interfaces do roteador. 11 Configura os temporizadores do processo BFD na interface: bfd interval VALOR min_rx VALOR multiplier NUMERO

11 Habilita BFD no processo OSPF da interface: ip ospf bfd

11 Habilita supressão de prefixos na interface OSPF: ip ospf prefix-suppression

Os comandos a seguir são aplicados no modo de configuração global do roteador. 11 Habilita o processo SNMP server no roteador com a comunidade estabelecida:

OSPF Avançado

snmp-server community

160

Jerônimo Aguiar Bezerra é mestre em Mecatrônica e Bacharel em Ciência da Computação pela Universidade Federal da Bahia, Jeronimo Aguiar Bezerra tem vasta experiência com redes de computadores, sistemas 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.

LIVRO DE APOIO AO CURSO

avançada do protocolo OSPF em Redes TCP/IP de grande porte. São estudados os pacotes OSPF e a sua utilização. São descritas as áreas OSPF e as suas características. São apresentadas as técnicas de Engenharia de Tráfego processo de escolha de rotas do OSPF. São descritos os métodos de otimização do OSPF. O curso garante ao ção avançada do protocolo OSPF na rede de sua instituição. Este livro inclui os roteiros das atividades práticas e o conteúdo dos slides apresentados em sala de aula, mento em suas organizações ou localidades de origem.

02 5

630025

OSPF Avançado

Recommend Documents