OSPF Avançado

(1)

Jerônimo Aguiar Bezerra

OSPF

(2)

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.

(3)

Jerônimo Aguiar Bezerra

OSPF

(4)

(5)

Jerônimo Aguiar Bezerra

Rio de Janeiro

Escola Superior de Redes

2016

OSPF

(6)

22290-906 Rio de Janeiro, RJ Diretor Geral

Nelson Simões

Diretor de Serviços e Soluções José Luiz Ribeiro Filho Escola Superior de Redes Coordenador Nacional

Leandro Marcos Oliveira Guimarães Edição

Lincoln da Mata

Coordenador Acadêmico da Área e Administração de Projetos de Redes Luiz Carlos Lobo Lobato

Equipe ESR (em ordem alfabética)

Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlinéa Miranda, Elimária Barbosa, Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato , Renato Duarte e Yve Marcial.

Capa, projeto visual e diagramação Tecnodesign

Versão 1.0.0

Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [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.

(7)

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

(8)

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

(9)

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

(10)

(11)

A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunica-ção (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicá-veis ao uso eficaz e eficiente das TIC.

A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI.

A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos edu-cacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR

A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típi-cos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do pro-blema, em abordagem orientada ao desenvolvimento de competências.

Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de apren-dizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

(12)

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atua-ção do futuro especialista que se pretende formar.

As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir:

Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem.

Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos).

Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e oferecer explicações complementares.

Terceira etapa: discussão das atividades realizadas (30 minutos).

O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso

O curso descreve os detalhes do funcionamento do protocolo OSPF, permitindo ao aluno entender como o OSPF monta sua hierarquia em áreas e quais mensagens e tipos de pacotes são utilizados. Além disso, serão apresentadas alternativas para trabalhar com engenharia de tráfego, serão apresentados modos de como mudar as métricas e forçar o roteamento de tráfego por caminhos mais otimizados. Também serão apresentadas técnicas para controlar a redistribuição de prefixos utilizando os mapas de rotas (ou

route-maps). O curso termina com uma sessão de sugestões de otimizações para a

conver-gência do OSPF além de apresentar o SNMP como uma ferramenta de monitoramento do ambiente OSPF. Ao final do curso o aluno estará capacitado a:

6 Descrever o funcionamento do OSPF

6 Descrever os tipos de pacotes OSPF

6 Descrever quais são e como são utilizados os LSA (Link State Advertisements)

6 Descrever quais são os estados possíveis de um roteador OSPF

6 Distinguir os tipos de áreas existentes

6 Projetar e justificar quais tipos de área deseja utilizar

6 Entender o porquê de cada estado de cada banco de dados por área

6 Entender as técnicas de Engenharia de Tráfego com OSPF

(13)

6 Entender o processo de escolha de rotas do OSPF

6 Entender Incremental OSPF

6 Entender Graceful Restart

6 Configurar BFD para OSPF

6 Configurar Supressão de Prefixos

6 Implementar Monitoramento da MIB para OSPF

A quem se destina

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

Convenções utilizadas neste livro

As seguintes convenções tipográficas são usadas neste livro:

Itálico

Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante

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

Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula. Símbolo w

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

d

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

Indica um vídeo como referência complementar.

Símbolo

s

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

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

Símbolo

p

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

Símbolo l

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

(14)

Permissões de uso

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

(15)

Ca pí tu lo 1 - F un ci on am en to d o b an co d e d ad os d o O SP F

obj

et

ivo

s

co

nc

ei

to

s

1 Funcionamento do banco de

dados do OSPF

Descrever o funcionamento do OSPF; Descrever os tipos de pacotes OSPF; Descrever quais são e como são utilizados os Link State Advertisements; Descrever quais são os estados possíveis de um roteador OSPF.

Funcionamento do protocolo OSPF; Tipos de pacotes OSPF; Transição de Estados no Sincronismo do OSPF; Link State Advertisement ou LSA; Router LSA; Network LSA; Network Summary LSA; ASBR Summary LSA; AS External LSA; NSSA External LSA; Remoção de LSAs.

Entendendo o funcionamento do banco de dados do OSPF

q

1 OSPF está definido na RFC 2328 (atualmente usa-se a versão 2 para IPv4 e versão 3 para IPv6).

1 Funcionamento se baseia em um banco de dados topológico.

1 Existe apenas um banco de dados topológico por área (chamado de Link-State Database ou LSDB).

1 Todos os roteadores da área têm de ter o mesmo LSDB.

1 Banco de dados criados a partir da troca de mensagens Link State Advertisements (LSAs). 1 Roteadores enviam LSAs com informações de enlaces conectados e seus custos. 1 Algoritmo SPF utilizado para calcular as rotas.

1 Cinco tipos de pacotes OSPF existem para fazer a troca das mensagens LSA.

O funcionamento do protocolo OSPF se baseia no banco de dados topológico (ou Link-State Database – LSDB), criado com informações dos enlaces de todos os roteadores que fazem parte da mesma área hierárquica, ou seja, todos os roteadores de cada área precisam manter um banco de dados síncrono para garantir o roteamento adequado dos pacotes IP. É através desse banco de dados topológico que o processo do OSPF calcula o menor caminho para cada destino, utilizando o algoritmo SPF Short Path First. O modo de funcio-namento desse algoritmo foi detalhado e exemplificado na sessão de aprendizagem 3 do curso "Protocolos de Roteamento IP".

SPF – Short Path First Ou algoritmo de Dijkstra. Criado por Edsger Dijkstra em 1956.

(16)

O SP F A va nç ad o

O banco de dados topológico do OSPF é criado a partir dos LSAs, ou Link State Advertisements, que são as estruturas de dados responsáveis pelas informações topológicas dos roteadores OSPF, ou seja, contém informações sobre o estado de cada enlace pelo qual um determinado roteador é responsável. Nas mensagens LSA estão indicados o prefixo IP e a máscara de subrede do enlace, qual o roteador responsável pelo prefixo, qual é a métrica (ou custo) para alcançar aquele destino, um tempo de expiração e outras informações.

É através dessas informações que o algoritmo SPF define qual é o melhor caminho para alcançar um destino IP. Após essa definição, uma rota IP é criada e enviada para o software gerenciador da tabela de rotas (Plano de Controle do roteador) decidir se vai ou não instalar na tabela de rotas.

Para entender como o banco de dados topológico é montado e sincronizado, é impor-tante conhecer os tipos de pacotes OSPF existentes, como os pacotes funcionam e em que momento eles são utilizados.

Tipos de pacotes OSPF

q

Sincronização do banco de dados OSPF ocorre a partir de cinco pacotes OSPF: 1 Hello.

1 DD: database Description. 1 LSR: link State Request. 1 LSU: link State Update.

1 LSAck: link State Acknowledgement.

O protocolo OSPF, diferentemente do RIP e do BGP, opera diretamente sobre o protocolo IP (usando o número de protocolo 89), ou seja, não utiliza o protocolo TCP para garantir a consistência dos dados trocados. Então, cabe ao próprio protocolo OSPF definir os meca-nismos de controle e garantia na troca de informações entre os roteadores OSPF. Entre outros métodos, o OSPF utiliza confirmação de recebimento, controle de versão por registro e números de sequência.

De acordo com a RFC 2328, existem cinco pacotes OSPF que rodam sobre o protocolo IP e são responsáveis pelas operações do OSPF, cada método com sua abordagem de controle e garantia. Esses cinco pacotes OSPF serão detalhados a seguir e seus cabeçalhos serão apresentados. Porém, todos compartilham de um cabeçalho comum, então é importante detalhá-lo antecipadamente. Observe na figura 1.1 o formato desse cabeçalho, que possui nove campos e 24 bytes de tamanho total sem autenticação (se utilizar autenticação MD5, são 40 bytes).

q

Todos os cinco pacotes OSPF contêm um cabeçalho comum de 24 bytes (sem autenti-cação com MD5) ou 40 bytes (com autentiautenti-cação com MD5):

(17)

Ca pí tu lo 1 - F un ci on am en to d o b an co d e d ad os d o O SP F Versão=2 32 bits

8 bits 8 bits 8 bits 8 bits

Tipo Tamanho do Pacote

Autenticação Autenticação Tipo de Autenticação Checksum Area ID Router ID

Os campos estão detalhados a seguir:

1 Versão: para o protocolo IPv4, a versão atual do protocolo OSPF é a versão 2; para IPv6 é a versão 3;

1 Tipo: identifica um dos cinco pacotes OSPF (Hello (1), DD(2), LSR(3), LSU(4), LSAck(5)); 1 Tamanho do Pacote: tamanho do pacote OSPF em Bytes, somando o cabeçalho e o

con-teúdo, sem contar com a mensagem de autenticação MD5;

1 Router ID: endereço IP selecionado pelo processo OSPF para identificar o roteador. Geralmente está associado ao endereço IP da interface Loopback ou é configurado manualmente;

1 Area ID: identifica a área OSPF;

1 Checksum: valor de checksum do pacote OSPF, utilizado para verificar se o pacote está íntegro ou não na sua recepção. Usa o mesmo algoritmo do checksum do pacote IP; 1 Tipo de Autenticação: informa qual esquema de autenticação está sendo utilizado. Pode

assumir os seguintes valores: 2 0: Sem autenticação;

2 1: Autenticação simples, utilizando texto sem criptografia. Pode utilizar senhas de até oito caracteres. Nesse tipo de autenticação, os dois campos Autenticação acima arma-zenam o valor da senha, como se fossem um único campo;

2 2: Autenticação criptográfica. Nesse caso, os dois campos Autenticação assumem o seguinte formato:

Número de Sequência Criptográﬁco

Tamanho Key ID

0x0000

3 Key ID: identifica a chave a ser utilizada (várias chaves são possíveis na configu-ração OSPF);

3 Tamanho: tamanho da mensagem criptográfica (digest). Esse tamanho não está incluso no tamanho informado anteriormente no campo Tamanho do Pacote; 3 Número de Sequência Criptográfico: utilizado para evitar ataques do tipo Replay,

por isso fica sempre incrementando.

2 Além dessas modificações no formato dos campos Autenticação do cabeçalho, o cabe-çalho é aumentado com mais um campo, de 16 bytes, onde a mensagem digest do MD5 é inserida. Caso a autenticação com MD5 seja utilizada, o cabeçalho OSPF passa de 24 bytes para 40 bytes. No final, o cabeçalho OSPF completo com autenticação MD5 teria a Figura 1.1 Cabeçalho OSPF compartilhado. Figura 1.2 Informações de Criptografia do cabeçalho OSPF para MD5. Os dois campos Autenticação viram novos campos.

(18)

Número de Sequência Criptográﬁco

Digest MD5 Tamanho Key ID 0x0000 Versão=2 32 bits

Tipo Tamanho do Pacote

Tipo de Autenticação Checksum

Area ID Router ID

q

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

1 IP de origem do pacote OSPF é sempre o IP da interface conectada à área, não o Router-ID;

1 IP de destino pode ser o endereço IP do roteador adjacente ou um dos grupos multi-cast definidos: allSPFRouters (224.0.0.5) ou AllDRouters (224.0.0.6).

É importante ressaltar que, por tratar apenas de adjacências, todos os pacotes IP utilizados pelo OSPF são criados para serem enviados apenas para os roteadores adjacentes e, por isso, são criados com o campo Time to Live (TTL) do pacote IP configurado como "1". Isso garante que os pacotes não serão roteados para outras redes da qual o roteador OSPF não faz parte.

O endereço IP de origem dos pacotes OSPF é sempre o endereço IP da interface de rede onde existe a adjacência, e o endereço IP de destino pode ser o endereço IP do roteador OSPF adjacente ou um endereço IP multicast: AllSPFRouters (224.0.0.5) ou AllDRouters (224.0.0.6).

A seguir, os pacotes OSPF e o uso serão detalhados.

Pacotes Hello

q

Pacotes Hello possuem diversas funções: 1 Descobrir roteadores OSPF adjacentes. 1 Estabelecer adjacências com esses roteadores. 1 Manter as adjacências.

1 Detectar falhas de enlaces e roteadores.

1 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em redes tipo Broadcast e NBMA.

1 Utiliza o grupo Multicast AllSPFRouters (224.0.0.5) em redes Broadcast e NBMA.

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

(19)

Relembrando: O OSPF pode funcionar em três tipos diferentes de rede: 1 Redes Ponto-a-Ponto: conecta um par de roteadores;

1 Redes Broadcast: suportam múltiplos roteadores e endereço IP que representam todos os roteadores da rede (endereço Broadcast);

1 Redes Non-Broadcast: suportam múltiplos roteadores, mas não suportam broadcast. No contexto do OSPF, podem ser operadas de duas maneiras: 2 Simulação de uma rede Broadcast na rede Non-Broadcast, denominada

non-broadcast multi-access ou NBMA;

2 Tratando a rede como uma coleção de enlaces ponto-a-ponto, denominada redes Ponto-a-Multiponto.

Apesar de ser um tipo de pacote do OSPF, o Hello também é considerado um protocolo por si só. Esse protocolo possui as seguintes responsabilidades:

1 Descobrir roteadores OSPF adjacentes; 1 Estabelecer adjacências com esses roteadores; 1 Manter as adjacências;

1 Detectar falhas de enlaces e roteadores;

1 Definir o roteador Designated Router (DR) e o Backup Designated Router (BDR) em redes tipo Broadcast e NBMA.

Esse é considerado o principal pacote OSPF, pois é a partir dele que todas as descobertas e adjacências são criadas, além de ser o responsável por detectar falhas de enlaces e rote-adores. Por ser o primeiro pacote OSPF a ser utilizado, funciona enviando pacotes Hello para o endereço IP multicast AllSPFRouters (224.0.0.5). Os roteadores OSPF que recebem o pacote Hello enviam outro pacote Hello de volta para iniciar as adjacências.

Formato do pacote Hello

A figura 1.4 apresenta o pacote Hello. Observe que o cabeçalho OSPF apresentado anterior-mente é simplificado, mostrando apenas o número que representa o tipo do pacote Hello, que é o tipo “1”.

(20)

Intervalo de Roteador Morto Designated Router Backup Designated Router

Vizinhos Ativos Vizinhos Ativos

. . .

Prioridade Opções Intervalo Hello 32 bits

Tipo=1

Máscara de sub-rede Cabeçalho OSPF

Os campos estão detalhados a seguir:

1 Máscara de sub-rede: máscara de sub-rede da interface que está enviando o pacote Hello. Essa máscara deve ser a mesma em todas as interfaces dos roteadores conectados no mesmo segmento, por exemplo, na mesma VLAN ou no enlace serial;

1 Intervalo Hello: tempo em segundos entre o envio dos pacotes Hello. O valor tem de ser o mesmo nos roteadores conectados no mesmo segmento. Em caso de discrepâncias, a adjacência não será estabelecida;

1 Opções: existem cinco tipos de opções definidas na RFC 2328. Essas opções são utili-zadas para estender as capacidades do roteador OSPF, além de informar outros rotea-dores dessas capacidades. As possibilidades são apresentadas a seguir:

2 E-bit: descreve como os LSA AS-External são anunciados na rede;

2 MC-bit : descreve se os datagramas IP multicast são enviados de acordo com a RFC 1584 (Multicast OSPF);

2 N/P bit: esse bit descreve como manipular os LSAs do Tipo 7;

2 EA bit: descreve o interesse do roteador para receber e encaminhar LSA External-Attributes;

2 DC bit: descreve se o roteador manipula circuitos sob demanda.

1 Prioridade: utilizado para a eleição do DR (Designated Router) e BDR (Backup Designated Router) em redes Broadcast e NBMA. Prioridade “0” significa que o roteador não é ele-gível para virar DR ou BDR. O roteador com a maior prioridade é eleito o DR;

1 Intervalo de Roteador Morto (Dead Interval): intervalo em segundos para definir que o roteador adjacente está desconectado da rede e assim encerrar a adjacência. Assim como o “Intervalo Hello”, o valor tem de ser o mesmo nos roteadores conectados no mesmo segmento. Em caso de discrepâncias, a adjacência não será estabelecida;

Figura 1.4 Pacote Hello com o cabeçalho OSPF simplificado.

(21)

1 Designated Router: endereço IP da interface do DR no segmento de rede (não o Router-ID). Caso não seja uma rede tipo Broadcast ou NBMA, esse campo é preenchido com 0.0.0.0; 1 Backup Designated Router: endereço IP da interface do BDR no segmento de rede (não

o Router-ID). Caso não seja uma rede tipo Broadcast ou NBMA, esse campo é preenchido com 0.0.0.0;

1 Vizinhos Ativos: lista dos roteadores vizinhos do qual o roteador OSPF que está enviando o pacote recebeu pacotes Hello válidos. Em redes do tipo Broadcast e NBMA, são listados todos os roteadores OSPF que fazem parte do segmento. Em redes ponto-a-ponto, o ende-reço IP do roteador remoto é informado nesse campo.

Responsabilidades do protocolo Hello

O protocolo Hello é responsável por um conjunto grande de tarefas em uma rede OSPF, con-forme citado anteriormente. Então, de posse das informações sobre os campos do pacote Hello, as principais atividades terão seu funcionamento detalhado a seguir.

Descobrir roteadores OSPF adjacentes e estabelecer adjacências

q

1 Protocolo Hello é utilizado para descobrir e estabelecer as adjacências.

1 As adjacências OSPF são iniciadas logo após um roteador OSPF detectar outro na rede. 1 A figura 1.5 será usada para exemplificar o estabelecimento das adjacências.

No momento em que o roteador OSPF finaliza sua inicialização e habilita suas interfaces, o processo OSPF começa a enviar pacotes Hello por todas as interfaces que estão configu-radas para fazerem parte do OSPF. Considere a topologia na figura a seguir.

s1/0

10.1.1.0/24

R3 R4

s0/0

q

1 Nesse exemplo, ambos os roteadores estão configurados na Área Backbone ou Área 0.0.0.0;

1 Pacotes Hello são enviados;

1 Primeiro pacote não possui o campo “Vizinho Ativo” (Active Neighbor); 1 DR e BDR não são utilizados em enlaces seriais.

Ambos os roteadores R3 e R4 estão conectados por um enlace serial, utilizando o endereça-mento IP 10.1.1.0/24, onde R3 possui IP 10.1.1.1 e R4 possui IP 10.1.1.2. Suponha que o rote-ador R4 acabou de ser ligado e configurado, e suponha também que ambos os roterote-adores foram configurados com OSPF nas interfaces mostradas, todas na Área Backbone (também conhecida como Área 0.0.0.0). No momento em que R4 inicia seu processo OSPF, suas estru-turas de dados são criadas, porém o banco de dados topológico está vazio. O primeiro passo é enviar pacotes Hello pela interface serial 0/0.

O primeiro pacote OSPF seria montado como está na figura 1.6. Observe como os campos do pacote Hello foram preenchidos:

Figura 1.5 Topologia de Exemplo para exemplificar a funcionamento do protocolo Hello.

(22)

O SP F A va nç ad o Cabeçalho comum: 1 OSPF Version: 2; 1 Type: 1 (Pacote Hello);

1 Packet Length: 44 (24 bytes do cabeçalho OSPF mais 20 bytes do pacote Hello); 1 Source OSPF Router ou Router ID: 10.1.1.2 (IP da interface);

1 Area ID: 0.0.0.0, conhecida como Área Backbone; 1 Auth Type: null, ou seja, sem autenticação. Pacote Hello:

1 Network Mask: 255.255.255.0 (pois a rede é 10.1.1.0/24); 1 Hello Interval: (intervalo entre os Hellos): 10 segundos; 1 Router Priority: 1;

1 Router Dead Interval: 40 segundos;

1 Designated Router: 0.0.0.0 (enlace serial não tem DR);

1 Backup Designated Router: 0.0.0.0 (enlace serial não tem BDR).

Podemos observar que o campo de Vizinhos Ativos não está presente, pois o roteador R4 ainda não conhece o roteador remoto.

q

R4 envia o primeiro pacote Hello: Open Shortest Path First OSPF Header

OSPF Version: 2

Message Type: Hello Packet (1) Packet Length: 44

Source 0SPF Router: 10.1.1.2 (10.1.1.2) Area ID: 0.0.0.0 (Backbone)

Packet Checksum: 0xe19b [correct] Auth Type: Null

Auth Data (none) OSPF Hello Packet

Network Mask: 255.255.255.0 Hello Interval: 10 seconds Options: 0x12 (L, E) Router Priority: 1

Router Dead Interval: 40 seconds Designated Router: 0.0.0.0 Backup Designated Router: 0.0.0.0

Após receber o pacote Hello vindo de R4 (10.1.1.2), o R3 envia um pacote Hello, conforme figura 1.7.

q

1 R3 envia seu primeiro pacote Hello, porém após receber o Hello do R4 (nesse exemplo); 1 Campo Vizinho Ativo ou Active Neighbor é preenchido a partir do Hello do roteador R4;

Figura 1.6 Captura do primeiro pacote Hello enviado por R4.

(23)

Open Shortest Path First OSPF Header

OSPF Version: 2

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

Router Dead Interval: 40 seconds Designated Router: 0.0.0.0 Backup Designated Router: 0.0.0.0 Active Neighbor: 10.1.1.2

OSPF Version: 2

Packet Checksum: 0xd695 [correct] Auth Type: Null

Observe que o R3 envia um pacote Hello similar, porém com campo Source OSPF Router indicando seu endereço IP (10.1.1.1) e com o campo Active Neighbor com o valor 10.1.1.2. Isso ocorre pois R3 recebeu o pacote Hello vindo do R4. Na próxima vez que o R4 enviar um pacote Hello, o campo Active Neighbor estará presente (conforme a figura 1.8). Ter o campo

Active Neighbor no pacote Hello significa que ambos os roteadores concordam em

estabe-lecer a adjacência. Outros pontos que requerem atenção: Figura 1.7 Captura do pacote Hello de R3 (Source OSPF Router: 10.1.1.1 Figura 1.8 Captura do pacote Hello de R4 agora informando ter visto R3.

(24)

1 Na figura 1.6, o Packet Length tinha 44 bytes, porém nas figura 1.7 e figura 1.8, tem 48 Bytes. Isso se deve ao fato de que o campo Active Neighbor estava presente com o ende-reço IP do vizinho nas figura 1.7 e figura 1.8 (lembre-se de que o endeende-reço IPv4 possui 4 bytes de tamanho, ou 32 bits);

1 A adjacência só foi estabelecida devido aos roteadores possuírem as mesmas configurações de temporizadores (Hello Interval e Router Dead Interval) e área (0.0.0.0).

q

1 Observe os campos Packet Length: por que mudou?

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

Processo de eleição dos roteadores Designated Router e Backup

Designated Router

q

1 Redes Broadcast e NBMA precisam ter um DR e um BDR por questões de escalabilidade.

1 Roteadores da área somente vão sincronizar com o DR. 1 Três tipos de roteadores OSPF na área:

2 Designated Router (DR).

2 Backup Designated Router (BDR). 2 DR Others (DROther).

1 Grupo Multicast AllDRouters (224.0.0.6) criado para comunicação com o DR e o BDR. No cenário do exemplo anterior, por ser uma rede ponto-a-ponto, o processo de estabeleci-mento de adjacência foi bastante simplificado, uma vez que em circuitos ponto-a-ponto só temos dois roteadores envolvidos. Porém, em redes tipo Broadcast ou NBMA, por questões de escalabilidade, o processo requer etapas extras, para que sejam escolhidos os rotea-dores Designated Router e Backup Designated Router.

Esses papéis existem nas redes Broadcast e NBMA para servirem de centralizadores de atualização das informações topológicas, evitando assim que todos os roteadores tenham de sincronizar seus bancos de dados com todos os outros roteadores da mesma sub-rede, melhorando a escalabilidade do OSPF, além de reduzir a quantidade de mensagens tro-cadas. Nesses casos, teremos três papéis:

1 Designated Router (DR);

1 Backup Designated Router (BDR); 1 DR Others (DROther).

Apenas o DR tem o papel de sincronizar o banco de dados topológico com os demais. Agora, em caso de alterações na rede, os roteadores DROthers terão de notificar o DR e o BDR dessas alterações, e o DR atualizará o banco de dados dos demais roteadores da rede. Para que o DROthers possam notificar apenas o DR e o BDR, um novo grupo multicast foi criado, chamado de AllDRouters (224.0.0.6). Apesar de apenas o DR ser responsável por encami-nhar as atualizações recebidas para os demais roteadores OSPF da rede, é importante que o BDR também seja notificado, uma vez que este será o responsável por substituir o DR em caso de falha.

(25)

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

R1 f0/0 f0/0 f0/0 10.1.0.0/24 SW1 1 2 3 R2 R3

Nessa topologia, o roteador R1 possui endereço IP 10.1.0.1, o roteador R2 possui endereço 10.1.0.2 e o roteador R3 possui endereço 10.1.0.3. O switch (sw1) na figura 1.9 atua sem con-figuração especial. O processo OSPF em cada roteador está configurado para operar apenas na interface fastEthernet 0/0. Supondo que os roteadores R1 e R2 são inicializados e o R3 permanece desligado, o processo ocorrerá da seguinte maneira:

a. Ambos os roteadores, ao terminarem de inicializar o processo OSPF, vão verificar se na rede já foram definidos o DR e/ou o BDR. Caso verifiquem que já foram definidos, o roteador aceita a escolha. Essa verificação é feita através dos pacotes Hello no grupo multicast AllSPFRouters (224.0.0.5), observando os campos Designated Router e Backup

Designated Router;

b. Nesse exemplo, como ambos foram recém-inicializados e não existem outros roteadores, ambos os roteadores enviarão pacotes Hello sem o campo Active Neighbors. Nesse momento, os campos Designated Router e Backup Designated Router estão preenchidos com 0.0.0.0; c. Ao receberem o pacote Hello, cada roteador passará a enviar os próximos pacotes Hello

com o campo Active Neighbors indicando o IP do roteador remoto; por exemplo, R2 vai enviar o pacote com Router-ID 10.1.0.2 e Active Neighbor 10.1.0.1;

d. Nesse momento, o processo de escolha do BDR é iniciado. Caso algum roteador tenha preenchido o próprio IP no campo Backup Designated Router, aquele com a maior Router Priority será escolhido. Em caso de empate, aquele com o endereço IP mais alto será o escolhido. Caso nenhum roteador tenha preenchido, o roteador com a maior Router Priority será escolhido. Novamente, em caso de empate, aquele com o endereço IP mais alto será escolhido. Após esse processo, nesse exemplo, o R2 será escolhido tempora-riamente como BDR, pois ambos estão com a Router Priority configurada com o valor padrão (1) e o Router-ID de R2 é maior que o Router-ID de R1;

Figura 1.9 Rede tipo Broadcast.

(26)

e. Após a escolha do R2 como BDR, o processo de escolha do DR é iniciado. Caso mais de um roteador tenha preenchido o próprio IP no campo Designated Router, aquele com a maior Router Priority será escolhido. Caso ambos tenham o mesmo valor de prioridade, aquele com o endereço IP mais alto será eleito o DR. Caso apenas um roteador tenha preenchido, esse será considerado o DR. Se nenhum roteador tiver preenchido o campo de Designated Router, o BDR é escolhido para ser o DR. Nesse caso, o R2 também será considerado o Designated Router desse segmento;

f. Como o DR e o BDR não podem estar associados ao mesmo roteador, uma nova eleição para o BDR é estabelecida, seguindo os passos detalhados no passo D. Com isso, R1 será escolhido BDR do segmento;

g. Após a escolha do novo BDR, o DR e o BDR ficarão com seus papéis até que o processo OSPF seja forçado pelo administrador a acontecer novamente ou em caso de queda de algum dos dois. Se o DR cair, o BDR assumirá o papel de DR e uma eleição para o BDR acontecerá. Caso o BDR caia, apenas uma eleição para BDR acontecerá;

h. Caso o administrador da rede inicialize o roteador R3 agora, este vai observar nos pacotes Hello que o DR e o BDR já estão definidos, logo ele se caracterizará como DROther, esta-belecendo adjacências com o DR e o BDR.

q

1 Roteadores, ao entrarem na rede, verificam se já há um DR e/ou um BDR:

2 Checam os campos Designated Router e Backup Designated Router do pacote Hello; 1 Caso positivo, aceitam a escolha;

1 No exemplo, não existem outros roteadores, então iniciam da forma normal; 1 Enviam pacotes Hello sem o campo Active Neighbors;

1 Campos Designated Router e Backup Designated Router preenchidos com 0.0.0.0; 1 Ao receber um pacote Hello, campo Active Neighbors passa a conter o IP do roteador

remoto;

1 Processo de escolha do BDR é iniciado. Depende de quem tiver maior Router Priority. Desempate com o maior endereço IP;

2 Roteadores com Router Priority 0 não são elegíveis; 1 Após escolha do BDR, processo de escolha do DR é iniciado;

2 Mesmos critérios de desempate do processo do BDR;

1 DR e BDR não mudam mesmo que outro roteador tenha prioridade maior; 2 Evita instabilidade na rede;

1 BDR só assume no momento em que o DR fica inativo; 1 Outros roteadores que entrarem na rede serão os DROthers.

O fato de que, após escolhidos, o DR e o BDR não mudam, mesmo com a entrada de outros roteadores com prioridade mais alta, serve para garantir a estabilidade da rede, uma vez que a cada eleição todo o processo de adjacência tem de ocorrer novamente, gerando instabilidade no roteamento da rede. Observe na figura 1.10 o pacote Hello com o DR e o BDR definidos.

(27)

OSPF Version: 2

Packet Checksum: 0xc490 [correct] Auth Type: Null

Auth Data (none) OSPF He11o Packet

Como ambos os roteadores estão utilizando a mesma prioridade (1), o R2 foi eleito DR por ter o IP mais alto (10.1.0.2 > 10.1.0.1). É importante ressaltar que, caso o roteador seja configurado com Router Priority igual a zero, esse roteador não poderá ser candidato à DR ou BDR. Após o estabelecimento das adjacências, os roteadores OSPF precisam trocar informações de estado de enlace para, assim, sincronizar seus bancos de dados topológicos e calcular a melhor rota para cada destino. Essa troca de informação de estado de enlace é feita pelos pacotes OSPF Database Description, Link State Request, Link State Update e Link State Acknowledgement, apresentados a seguir.

Database Description – DD

q

1 Após os roteadores OSPF tornarem-se adjacentes, os bancos de dados topológicos precisam ser sincronizados;

1 Pacotes Database Description são utilizados para esta atividade; 1 Pacotes DD são os pacotes OSPF do Tipo “2”

1 Database Exchange Process é iniciado: 2 Eleição Master/Slave;

2 Envio dos cabeçalhos LSA;

2 Verificação do aging para descobrir se o LSA é mais novo ou não;

2 Caso verifique que não está atualizado, uma lista de cabeçalhos LSA é criada para solicitar o LSA completo no próximo passo;

2 Utiliza endereçamento Unicast em redes Broadcast e NBMA e endereçamento Multicast em redes ponto a ponto.

Figura 1.10 R2 escolhido como

(28)

Após os roteadores OSPF estabelecerem adjacências, estes precisam verificar se seus bancos de dados topológicos estão sincronizados. Para essa tarefa, o pacote OSPF Database Description – DD – (pacote OSPF tipo “2”) é utilizado. Durante o período chamado “Database Exchange Process”, um processo de eleição de Master/Slave acontecerá e, após eleito, o Master começará a enviar os cabeçalhos dos LSAs existentes no seu banco de dados topo-lógico. Como cada cabeçalho LSA contém um aging (tempo de existência), o roteador Slave conseguirá verificar se seu banco de dados está mais atualizado ou não. Caso perceba que não está, este registra essa informação para solicitar o LSA completo na próxima etapa. O mesmo acontece com o Master, que ao receber o pacote DD do Slave verifica se seu banco está atualizado a partir dos cabeçalhos LSAs recebidos e os respectivos tempos de aging. Assim como o pacote Hello, o pacote DD também usa o cabeçalho OSPF apresentado ante-riormente, adicionando apenas os campos listados a seguir. A troca dos pacotes de DD ocorre utilizando endereçamento Unicast (em redes Broadcast e NBMA) e Multicast (em redes ponto a ponto).

Tipo=2 Cabeçalho OSPF 32 bits Opções MTU 00000 I M Ms Número de Sequência Cabeçalhos LSA

1 MTU: tamanho do Maximum Transmission Unit da interface OSPF a ser utilizada para sin-cronismo dos bancos de dados topológicos. Caso sejam diferentes entre os roteadores, o processo de sincronismo não vai ocorrer;

1 Options: mesmas opções definidas no pacote Hello;

1 Bit I (Initial): caso esteja marcado com “1”, indica que esse é o primeiro pacote DD da sequência de sincronismo;

1 Bit M (More): caso esteja marcado com “1”, indica que o pacote atual não é o último da sequência. “0” indica que é o último;

1 Bit MS (Master/Slave): se esse bit estiver marcado como “1”, significa que roteador origi-nador é o Master na relação de sincronismo entre os dois roteadores. Se estiver marcado como “0”, esse roteador é o Slave do processo;

1 Número de Sequência: utilizado pelo Master para definir o sequenciamento dos pacotes DD; 1 Cabeçalhos LSA: lista dos cabeçalhos de parte ou todos os LSAs contidos no banco de dados do originador do pacote. A partir desse campo, o recebedor do pacote poderá confirmar se possui todos os LSAs e, caso não tenha, solicitará tais LSAs faltantes no próximo processo. Para ilustrar, vamos utilizar a topologia apresentada na figura 1.9. Como as adjacências já foram criadas, o passo seguinte é o Database Exchange Process. Observe a figura 1.12, a figura 1.13 e a figura 1.14. Figura 1.11 Pacote Database Description. Também usa o cabeçalho OSPF.

(29)

Ca pí tu lo 1 - F un ci on am en to d o b an co d e d ad os d o O SP F OSPF Header OSPF version: 2

Message Type: DB Description (2) Packet Length: 32

Packet checksum: 0x8386 [correct] Auth Type: Null

Auth Data (none) OSPF DB Description Interface MTU: 1500 Options: 0x52 (O, L, E) DB Description: 0x07 (I, M, MS)

.... 0... = R: OOBResync bit is NOT set .... .1.. = I: Init bit is SET

.... ..1. = M: More bit is SET

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

OSPF Header OSPF version: 2

Source OSPF Router: 10.1.0.2 (10.1.0.2) Area ID: 0.0.0.0 (backbone)

Packet checksum: 0x7f27 [correct] Auth Type: Null

Na figura 1.12 é possível observar que ambos os roteadores R1 (10.1.0.1) e R2 (10.1.0.2) enviam o pacote DD informando serem Masters do processo. Cada um envia seu próprio número de sequência (R1 envia 6258 e R2 envia 7376).

Na figura 1.13., o roteador R1 envia o pacote com o bit M/S configurado para “0”, indicando ser o Slave da relação. No mesmo pacote R1 já envia o número de sequência recebido do R2 (7376) e os cabeçalhos dos LSAs que estão no seu banco de dados (a explicação sobre LSA se dará mais à frente).

Packet checksum: 0x7ffe [correct] Auth Type: Null

Auth Data (none) OSPF DB Description

Interface MTU: 1500 Options: 0x52 (O, L, E) DB Description: 0x02 (M)

.... 0... = R: OOBResync bit is NOT set .... .0.. = I: Init bit is NOT SET .... ..1. = M: More bit is SET

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

LSA Header

Source OSPF Router: 10.1.0.2 (10.1.0.2) Area ID: 0.0.0.0 (backbone)

Packet checksum: 0x7f27 [correct] Auth Type: Null

.... ...1 = MS: Master/Slave bit is SET DD Sequence: 7376 Figura 1.12 Database Exchange Process: eleição do Master. Figura 1.13 Database Exchange Process: início da troca de pacotes DD.

(30)

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

OSPF Header OSPF: version: 2

Packet checksum: 0x7f2e [correct] Auth Type: Null

Auth Data (none) OSPF DB Description Interface MTU: 1500 Options: 0x52 (O, L, E) DB Description: 0x00

.... 0... = R: OOBResync bit is NOT set .... .0.. = I: Init bit is NOT set .... ..0. = More bit is NOT set

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

OSPF Header OSPF: version: 2

Packet checksum: 0x8fe9 [correct] Auth Type: Null

Auth Data (none) OSPF DB Description Interface MTU: 1500 Options: 0x52 (O, L, E) DB Description: 0x03 (M, MS)

.... 0... = R: OOBResync bit is NOT set .... .0.. = I: Init bit is NOT set .... ..1. = M: More bit is SET

LSA Header

Após isso, R2 envia mais um pacote DD com o bit M configurado como “0” e um novo número de sequência (7378), indicando o fim do processo, e R1 confirma com um pacote DD com o mesmo número. Agora, de posse dos cabeçalhos LSAs existentes no roteador remoto, ambos os roteadores enviarão pacotes OSPF chamados Link State Request, solicitando os LSAs completos para serem inseridos no banco de dados topológico. O processo de requi-sição será apresentado a seguir.

Link State Request ou LSR

q

1 Após o Database Exchange Process, os roteadores OSPF têm uma lista com LSAs que precisam ser solicitados.

1 A solicitação dos LSAs acontece via pacote OSPF Link State Request ou LSR. 1 Pacote OSPF do Tipo 3.

1 Também faz uso do cabeçalho OSPF, assim como o Hello e o DD. 1 Adiciona apenas três campos novos, que podem ocorrer diversas vezes.

Concluído o Database Exchange Process, o próximo passo para o sincronismo dos bancos de dados é solicitar os LSAs completos que cada roteador recebeu do roteador remoto, seja por não possuir tal LSA, seja devido ao aging recebido ser mais novo que o existente no banco de dados atual.

Para fazer tal requisição ao roteador remoto, o pacote OSPF Link State Request (pacote OSPF tipo 3) é utilizado. Também fazendo uso do mesmo cabeçalho do Hello e do DD, esse pacote apenas adiciona três campos, conforme pode ser visto na figura 1.15. Esses

Figura 1.14 Database Exchange Process – R2 enviando seus LSAs.

(31)

Ca pí tu lo 1 - F un ci on am en to d o b an co d e d ad os d o O SP F 32 bits

Tipo=3 Cabeçalho OSPF Tipo de Link-State 1 ID do Link-State 1 Advertising Router 1

...

Tipo de Link-State n ID do Link-State n Advertising Router n

1 Tipo do LSA: identifica o tipo do LSA (os tipos estão listados na tabela 1.1); 1 ID do LSA: varia de acordo com o tipo do LSA;

1 Advertising Router: o Router-ID do roteador que originou o LSA.

Esses campos podem se repetir diversas vezes, para solicitar múltiplos LSAs no mesmo pacote. Assim como a comunicação no Database Exchange Process, a comunicação entre os roteadores OSPF ocorre utilizando endereçamento Unicast (redes Broadcast e NBMA) e Multicast (redes Ponto-a-Ponto). Na figura 1.16 é possível ver um pacote LSR sendo enviado do R2 para R1:

OSPF Version: 2

Message Type: LS Request (3) Packet Length: 36

Packet Checksum: 0xdfd0 [correct] Auth Type: Null

Auth Data (none) Link State Request

Link-State Advertisement Type: Router-LSA (1) Link State ID: 10.1.0.1

Advertising Router: 10.1.0.1 (10.1.0.1)

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

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

(32)

Link State Update ou LSU

q

1 Recebido o Link State Request, o roteador OSPF receptor verifica no seu banco de dados e responde com um pacote Link State Update.

1 O Link State Update é o pacote OSPF Tipo “4”. 1 O pacote pode ser enviado por Unicast ou Multicast. 1 Também faz uso do cabeçalho OSPF.

Recebida a solicitação do LSA via pacote LSR, o roteador OSPF enviará um pacote OSPF Link State Update, cujo tipo é o 4. Esse pacote utiliza o mesmo cabeçalho OSPF, e a resposta é feita via uma das possibilidades a seguir:

1 Um pacote LSU via Unicast para o solicitante;

1 Um pacote LSU via Multicast para o grupo AllSPFRouters.

Apenas dois campos existem nesse pacote, conforme pode ser observado na figura 1.17. 32 bits

Tipo=4

Cabeçalho OSPF

Número de LSAs LSAs

1 Número de LSAs: informa a quantidade de LSAs que estão sendo enviados nesse pacote; 1 LSAs: nesse campo são enviados os LSAs requisitados pelo LSR.

Na figura 1.18 é possível verificar um pacote LSU respondendo com um LSA completo. Porém, para garantir que o roteador remoto realmente recebeu o LSU, o roteador remoto precisa informar ao originador a confirmação de recebimento. Essa confirmação ocorre através do pacote OSPF Link State Acknowledgement ou LSAck.

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

(33)

Ca pí tu lo 1 - F un ci on am en to d o b an co d e d ad os d o O SP F OSPF Header OSPF Version: 2

Message Type: LS Update (4) Packet Length: 64

Source OSPF Router : 10.1. 0.1 (10.1. 0.1) Area ID: 0.0.0.0 (Backbone)

Packet Checksum: 0xe898 [correct] Auth Type: Null

Auth Data (none) LS Update Packet Number of LSAs: 1 LS Type: Router-LSA

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

Link State Acknowledgement ou LSAck

q

1 Depois de enviado o LSU, o roteador OSPF precisa da confirmação do roteador remoto que esse recebeu o pacote enviado.

1 A confirmação pode se dar de duas maneiras:

2 O receptor envia um pacote LSU com o mesmo conteúdo de volta para o originador. 2 O receptor gera um pacote Link State Acknowlegdement e envia para o originador. 1 Pacote Link State Acknowledgement ou LSAck possui o Tipo “5”.

1 Também utiliza o cabeçalho OSPF.

Como o LSU também ocorre em modo flooding: enviando as informações para todos os roteadores OSPF do segmento de rede do qual faz parte: o LSAck é importante para garantir confiabilidade ao protocolo OSPF. Cada LSA recebido deve ser explicitamente confirmado pelo recebedor através do pacote LSAck. Essa confirmação ocorre quando o recebedor envia os cabeçalhos do LSA no pacote LSAck, podendo confirmar um ou diversos LSAs em uma única mensagem. O LSAck é o pacote de tipo número “5” do OSPF.

Tipo=5 Cabeçalho OSPF 32 bits Cabeçalhos LSAs Figura 1.18 Resposta do R1 ao LSR de R2. Figura 1.19 Pacote Link State Acknowledgement.

(34)

É importante salientar que a especificação do OSPF também permite que a confirmação se dê através do próprio LSU, onde o recebedor enviaria um LSU de volta com os mesmos dados. Em redes Broadcast ou NBMA, a confirmação pode ocorrer também via Unicast (diretamente para o originador) ou via Multicast. Na figura 1.20, podemos observar a confir-mação do roteador R2 ao LSU do R1 via pacote LSAck.

OSPF Header OSPF Version: 2

Message Type: LS Acknowledge (5) Packet Length: 64

Packet Checksum: 0x6b41 [correct] Auth Type: Null

Auth Data (none) LSA Header

Após a confirmação de todos os LSAs recebidos por todos os roteadores OSPF, estes entram no estado chamado “FULL”, uma vez que seus bancos de dados estão sincronizados. A partir desse momento, apenas alterações de estado dos enlaces gerarão novas atualizações na rede.

q

1 Após todos os LSA serem trocados e confirmados, os roteadores entram no estado FULL;

1 Nesse estado, o algoritmo SFP faz o cálculo das rotas para serem inseridas no roteador; 1 Só haverá novos LSU/LSAck em caso de alterações no estado de algum enlace:

2 Enlace inativo, queda de circuito, queda de roteador etc.;

1 Caso o LSA não seja atualizado por 30 minutos, o roteador deve anunciá-lo nova-mente para os roteadores da área:

2 Garantir que os bancos de dados estão sincronizados; 2 Esse tempo é chamado de LSRefreshTime e é fixo;

2 Nota: o anúncio é feito por LSA, e não de todo o banco de dados.

Apesar do protocolo OSPF só enviar notificações de atualizações quando estas ocorrem (por exemplo, um enlace fica inativo), para garantir que todos os bancos de dados estão atualizados, toda vez que um LSA atingir o tempo aging de 30 minutos, uma atualização será enviada para o grupo Multicast AllSPFRouters, mesmo que no final o mesmo LSA permaneça no banco de dados OSPF. Esse tempo é fixo e chamado de LSRefreshTime na especificação do OSPF.

É importante salientar que o anúncio é feito por LSA, e não para todo o banco de dados. O OSPF não faz flooding da tabela de roteamento ou do banco de dados topológico.

Transição de Estados no Sincronismo do OSPF

Cada etapa do processo de sincronização do banco de dados topológico do OSPF tem um nome de estado associado. Esses nomes são importantes para entender o funcionamento do OSPF e para a resolução de problemas. A figura 1.21 ilustra essa transição de estados.

Figura 1.20 LSAck do R2 para R1.

(35)

Ca pí tu lo 1 - F un ci on am en to d o b an co d e d ad os d o O SP F R1 R2 HELLO (DR=0, Vizinhos=0) HELLO (DR=R2, Vizinhos=R1) D-D (Seq =X, I, M, Master) D-D (Seq =Y, l, M, Master)

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

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

D-D (Seq =Y+n, Master) D-D (Seq =Y+n, Slave)

LS Request LS Update LS Request LS Update DOWN DOWN INIT ExStart ExStart Exchange Exchange Full Full Loading

De maneira resumida, o processo de sincronização da figura 1.21 ocorre da seguinte maneira: a. R1 inicializa seu processo OSPF no estado DOWN e envia um pacote Hello sem DR e sem

indicação de vizinhos ativos;

b. R2 recebe o pacote Hello, e sai do estado DOWN para o estado INIT. R2 então envia uma mensagem Hello informando ser o DR e, na lista de vizinhos ativos, adiciona o IP de R1; c. Ao receber o pacote Hello vindo de R2 com seu endereço IP no campo de vizinhos ativos,

R1 sai do estado DOWN e passa para o estado ExStart. Nesse estado, R1 e R2 farão a verificação do banco de dados topológicos entre eles. Primeiramente, R1 envia um pacote DD informando ser o Master do processo;

d. Ao receber o pacote DD, R2 entende que o R1 quer estabelecer a adjacência, e sai do estado INIT para o estado ExStart, e envia um pacote DD para R1 também informando ser o Master;

e. Ao receber o pacote DD de R2, como este é o DR, R1 aceita ser o Slave do processo e passa do estado ExStart para o estado Exchange. Um pacote DD é enviado de volta com o número de sequência informado por R2;

f. R2 recebe o pacote DD com seu número de sequência e passa para o estado Exchange. A partir desse momento, começa a troca de mensagens DD com os cabeçalhos dos LSAs de cada banco de dados;

g. Após todos os cabeçalhos serem trocados, R1 entra no estado de Loading, pois agora vai solicitar os LSAs completos de R2. Mensagens de LSR são enviadas com os cabeçalhos dos LSA desejados;

Figura 1.21 Transição de estados OSPF.

(36)

h. Ao receber o LSR vindo de R1, se o R2 não precisar de nenhum LSA do R1, o este entra no estado FULL direto. Se R2 precisar, um pacote LSR será enviado para R1 e entrará no estado LOADING. No exemplo, como o R2 não precisará de informações do R1, R2 já foi para o estado FULL, e enviará os pacotes LSU com os LSAs requisitados;

i. Quando o R1 receber todos os LSU requisitados, fará a confirmação de recebimento com os LSAck e entrará no estado FULL também. A partir desse momento, o banco de dados OSPF estará completo e as rotas serão calculadas e inseridas na tabela de rotas do roteador. Caso um novo roteador entre na rede OSPF, este fará o processo acima com o DR apenas. Com os outros DROthers da rede, as adjacências serão criadas, porém os roteadores DROthers ficarão parados no estado ExStart (ou 2-Way para alguns fabricantes) entre eles, pois não há necessidade do sincronismo. Em redes não Broadcast e NBMA, onde não há DR e BDR, ambos os roteadores devem chegar até o estado FULL.

q

1 Em redes Broadcast e NBMA, esse processo ocorre entre o roteador OSPF (DROther)e o DR;

2 Entre os DROthers, o maior estado é o ExStart;

1 Em redes Ponto-a-Ponto, ambos os roteadores têm de chegar ao estado FULL. Agora que o processo de sincronização do banco de dados topológico já está claro, será apresentada a estrutura de dados chamada Link State Advertisement, ou LSA, que são as estruturas que contêm as informações topológicas que populam o banco de dados do OSPF.

Link State Advertisement ou LSA

q

1 Link State Advertisement é a estrutura de dados responsável por armazenar as infor-mações sobre os estados de enlaces;

2 Endereço IP, máscara de sub-rede, métrica etc.;

1 Pacotes OSPF DD e LSR usam apenas o cabeçalho; pacote LSU usa o LSA completo; 1 Através das informações no LSA é que o roteador faz os cálculos para definir as rotas; 1 Existem onze tipos, porém seis utilizados rotineiramente: router LSA, Network LSA,

Network Summary LSA, ASBR Summary LSA, AS External LSA e NSSA External LSA. Link State Advertisement é a estrutura de dados responsável por armazenar as diversas informações usadas pelo processo OSPF sobre os estados de enlaces, como tipo de enlace, IP, máscara de subrede, métrica, origem etc. Foi apresentado anteriormente que, nos pacotes OSPF DD e LSR, apenas o cabeçalho do LSA é trocado, enquanto que no LSU o LSA completo é enviado.

Como os LSAs são os responsáveis por todas as informações e métricas da rede OSPF, diversos tipos foram criados, com propósitos específicos. Na tabela 1.1, os onze tipos exis-tentes atualmente para IPv4 são apresentados. Porém, nas redes OSPF atuais, apenas seis tipos são realmente utilizados e serão detalhados nas sessões a seguir: router LSA, Network LSA, Network Summary LSA, ASBR Summary LSA, AS External LSA e NSSA External LSA.

(37)

Código Nome Quem faz uso? Descrição Definição 1 Router LSA Todos Descreve o ambiente

do roteador, inter-faces, métricas

RFC2328

2 Network LSA DR Informa todos os

roteadores na rede Broadcast/NBMA

RFC2328

3 Network Summary

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

chegar no roteador ASBR

RFC2328

5 AS external LSA ASBRs Anuncia rota de fora

do AS RFC2328

6 Group Membership

LSA - Usado para Multicast OSPF RFC1584 7 NSSA External LSA ASBRs em NSSA Anuncia rota de fora

do AS RFC3101

8 External Attributes

LSA - Possível substituto do iBGP Pendente

9 Opaque LSA - Usado em MPLS RFC5250

Assim como os pacotes OSPF, o LSA também tem um cabeçalho que é compartilhado por todos os tipos de LSA. Esse cabeçalho possui 20 Bytes e está apresentado na figura 1.22, sendo detalhado a seguir.

Sequence Number Age

32 bits

Opções Tipo

Advertising Router Link-State ID

Tamanho Checksum

1 Age (Tempo de vida): tempo em segundos desde que o LSA foi gerado; 1 Opções: mesmas definições do campo de Opções do protocolo Hello; 1 Tipo: identifica o Tipo do LSA;

1 Link-State ID: conteúdo dependente do Tipo do LSA. Será detalhado à frente; 1 Advertising Router: router-ID do roteador que originou o LSA;

1 Sequence Number: utilizado como controle de versão do LSA; Tabela 1.1

Lista dos tipos de LSA.

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

(38)

1 Checksum: utilizado para garantir integridade. Não inclui o campo Age; 1 Tamanho: tamanho do LSA em Bytes, incluindo o cabeçalho.

A seguir, os principais tipos de LSA serão apresentados, e seus cabeçalhos serão detalhados, bem como seu modo de uso.

Router LSA

q

1 Router LSA é utilizado para informar os roteadores adjacentes com informações como Router-ID, enlaces locais e métricas de saída.

1 Esse é o primeiro LSA enviado pelo roteador OSPF;

1 Contém todas as informações de todos os enlaces que o roteador possui; 1 Todas as informações de estado de enlace enviadas em apenas um LSA; 1 É o LSA Tipo “1”;

1 Todos os roteadores OSPF enviam LSAs do tipo Router LSA; 1 O Router LSA é mantido apenas dentro da área que faz parte.

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

Sequence Number Link ID Link Data 00000 V E B 0x00 Número de Links Age 32 bits

Opções Tipo = 1 Advertising Router Link-State ID Tamanho Checksum Tipo de Link TOS

Número TOS Métrica

0x00 Métrica TOS

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

1 Bit V (Virtual): informa se o roteador é a ponta de um Virtual Link; 1 Bit E (External): indica que o roteador originador é um ASBR; 1 Bit B (Border): indica que o roteador originador é um ABR; 1 Número de Links: número de enlaces incluídos no LSA.

Figura 1.23 Router LSA.