Roteamento avançado

ADR-003: Roteamento avançado

Escola Superior de Redes RNP

Copyright © 2008, Escola Superior de Redes RNP

Autor Luiz Carlos Lobato Lobo de Medeiros Revisão final Pedro Sangirardi Editoração eletrônica Tecnodesign Coordenação acadêmica Luiz Coelho Versão 2.0.0 Todos os direitos reservados, no Brasil, por Escola Superior de Redes RNP http://www.esr.rnp.br

Roteamento avançado Apresentação A Escola Superior de Redes da Rede Nacional de Ensino e Pesquisa (RNP) oferece cursos em tecnologia da informação e da comunicação para quem busca formação essencialmente prática. As atividades são situações-problema semelhantes às que são encontradas na prática do profissional de TI. Estas atividades exigem análise, síntese e construção de hipóteses para a superação do problema. A aprendizagem torna-se mais efetiva se contextualizada à realidade profissional. Os cursos propostos possuem 30 (trinta) horas de duração divididas em 10 (dez) sessões de aprendizagem. Os participantes trabalham em grupo ou em duplas e cada um pode dispor de sua própria estação de trabalho. O material de ensino é composto de apostilas contendo slides comentados e roteiro de atividades práticas em laboratório.

Pré-requisito \\Modelo

OSI, endereçamento IP, arquitetura e protocolos TCP/IP, protocolos de roteamento ou o Curso ADR-001: Arquitetura e protocolos de redes TCP-IP.

Objetivos \\Fornecer

ao aluno recursos que o habilitem a entender e projetar esquemas de roteamento para redes de computadores de diversos tamanhos, intra e inter sistemas autônomos, e para redes que dão suporte a tráfego constante (áudio e/ou vídeo).


Ao final do curso o aluno terá aprendido \\Projetar

esquemas de roteamento para redes de diversos tamanhos

\\Configurar

protocolos de roteamento:

\\Protocolos

intra AS

\\Protocolos

inter AS

\\Protocolos

multicast

\\Configurar

protocolos para redes de tráfego constante (áudio e/ou vídeo) com exigência de QoS

\\Resolução

de problemas de configuração

Sumário Sessão de aprendizagem 1 Conceitos básicos de roteamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Sessão de aprendizagem 2 Configuração de máscara de subrede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Sessão de aprendizagem 3 Configuração de rotas estáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Sessão de aprendizagem 4 Protocolo de roteamento RIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Sessão de aprendizagem 5 Protocolo de roteamento OSPF – Parte 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Sessão de aprendizagem 6 Protocolo de roteamento OSPF – Parte 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Sessão de aprendizagem 7 Protocolo de roteamento BGP – Parte 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Sessão de aprendizagem 8 Protocolo de roteamento BGP – Parte 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Sessão de aprendizagem 9 Resolução de problemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Sessão de aprendizagem 10 Roteamento multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Bibliografia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239


1 Sessão de aprendizagem 1 Conceitos básicos de roteamento Sumário da sessão Conceito de roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Transporte dos pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Endereçamento IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Classes de endereçamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Endereços especiais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Máscara de subrede padrão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Roteamento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Exemplo de roteamento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Arquitetura TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Camadas da arquitetura TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Camada de subrede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Protocolo ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Captura de pacotes IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Barra de ferramentas do Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Atividade 1 – Configuração de subredes IP Classe C. . . . . . . . . . . . . . . . . . . . . 22 Atividade 2 – Captura de pacotes IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

8


Conceito de roteamento

Conceito de roteamento (1) O que é roteamento? Roteamento é a transferência de informação da origem até o destino através de uma rede.

Roteamento é a transferência de informação da fonte até o destino através de uma rede. Ao longo do caminho, tipicamente teremos pelo menos um nó intermediário. De acordo com esta definição, a função do roteador parece ser a mesma que a de uma ponte (switch/bridge). A principal diferença entre ambos é que a ponte opera na camada 2 (enlace de dados) do modelo OSI, enquanto que os roteadores operam na camada 3 (rede). Assim, eles operam de maneiras diferentes, embora ambos executem operações de comutação. O roteamento envolve duas atividades básicas:

Conceito de roteamento (2)

\\Determinação

Componentes do roteamento Determinação de rotas Transporte dos pacotes (comutação) Determinação de rotas Para chegar na rede 10 Métrica 15 Tabelas de roteamento => 20 30 Troca de mensagens 25

das rotas ótimas;

\\Transporte

da informação (pacotes) através da rede (processo de comutação — switching).

Enviar para Nó A Nó B Nó C Nó A Nó B Nó A

Os algoritmos de roteamento usam algum padrão de medida (chamado métrica) para determinar a rota ótima para um dado destino. Para ajudar no 45 processo de determinação de rotas, os algoritmos de roteamento inicializam e mantêm tabelas de roteamento, que contêm informações de rotas. Essas informações tipicamente são armazenadas no formato destino/próximo nó (destination/next hop). A tabela mostrada abaixo exemplifica o que foi dito. Para chegar na rede

Enviar para

10

Nó A

15

Nó B

20

Nó C

30

Nó A

25

Nó B

45

Nó A

Os roteadores se comunicam entre si, para terem conhecimento de seus vizinhos e manterem atualizadas as tabelas de rotas. A internet é uma rede em constante mudança e não pode parar; deste modo, as mudanças precisam ser feitas dinamicamente. Para isso, os roteadores trocam mensagens para a manutenção das tabelas.

Roteamento avançado – Sessão de aprendizagem 1

9

Transporte dos pacotes

Transporte dos pacotes

Algoritmos de comutação são relativamente simples e basicamente os mesmos para a maioria dos protocolos de roteamento. Tipicamente, um host determina que precisa enviar um pacote para outro host. Para isso ele tem que saber, de alguma forma, o endereço do roteador que fará a ação (se não souber, não há como enviar o pacote). O host envia o pacote para o roteador, colocando o endereço físico do roteador (normalmente estão na mesma rede local, portanto o endereço físico será o MAC address) e o endereço do protocolo de rede do host de destino. O roteador então examina o pacote e tenta encaminhá-lo para o host de destino, baseado no seu endereço de rede. Se o roteador tiver na sua tabela de rotas a rota adequada, ele encaminhará para o próximo nó, mudando o endereço físico para o endereço do próximo nó e mantendo o endereço de rede do host de destino. Se não tiver a rota na tabela, o roteador simplesmente descartará o pacote. E o processo se repetirá até chegar no roteador que está na mesma rede do host de destino, que entregará o pacote enviando-o para o endereço físico do host de destino. Assim, à medida que o pacote atravessa a rede, seu endereço físico vai mudando; porém, o endereço do protocolo de rede permanece igual (host de destino).

Endereçamento IP

Endereçamento IP Endereços IP são baseados nos conceitos de rede e host Host é qualquer equipamento com capacidade de transmitir e receber pacotes IP em uma rede Hosts são interconectados por uma ou mais redes O endereço IP é composto por: Identificação da rede Identificação do host na rede Tamanho de 32 bits (4 octetos) representados por 4 números decimais separados por um ponto Exemplo: 200.201.152.93 (notação decimal pontuada)

Um endereço IP é composto de um identificador de rede acrescido de um identificador da estação nesta rede. Esta identificação independe da rede física subjacente. Assim, para efeito de encaminhamento local (dentro da mesma rede), o endereço IP é utilizado na estação emissora para a obtenção do endereço físico da estação de destino. Esse processo é denominado mapeamento.

No caso do envio de uma mensagem para uma estação situada em outra rede, a estação de origem obtém o endereço físico do gateway para a rede de destino. Vale ressaltar que a rede de destino não necessariamente está conectada à rede local. Neste caso, a mensagem é transportada por várias redes intermediárias, de gateway a gateway, preservando o endereço IP de destino, que é utilizado na obtenção dos endereços intermediários dos gateways presentes na rota. Assim, o encaminhamento IP é uma seqüência de ciclos repetidos: análise do endereço IP, obtenção do endereço físico da estação (se a rede de destino foi atingida) ou do gateway de saída (se a estação pertence a uma rede remota) e envio do datagrama para o endereço físico obtido.

Conceitos básicos de roteamento

10


O endereço IP, com seus 32 bits, torna-se demasiado grande para a notação binária. Por isso é utilizada a notação decimal pontuada. Os 32 bits são divididos em quatro grupos de 8 bits cada. Por exemplo, dado o endereço IP: 00000011.0 0000111.00001111.00000001, sua representação seria: 3.7.15.1.

Classes de endereçamento

Classes de endereçamento (1) Os primeiros bits do primeiro octeto definem a classe do endereço N = número da rede (network) dado pelo NIC H = número da estação (host) dado pelo administrador da rede 32 Bits

Rede

8 Bits

Host

Classe A Classe B Classe C

8 Bits

131 . 108 N N N

H N N

8 Bits

8 Bits

. 122 . 204 H H N

H H H

O endereço IP tem tamanho de 32 bits e possui duas partes: \\Número

de rede

\\Número

de host

O formato do endereço é conhecido como notação decimal pontuada (separada por pontos). Endereço exemplo: 131.108.122.204.

Cada bit no octeto tem um peso conforme sua posição, como (128, ..., 4, 2, 1). O valor mínimo para um octeto é 0; ele tem todos os bits 0. O valor máximo para um octeto é 255; ele tem todos os bits 1. Portanto, todos os endereços IP no intervalo 0.0.0.0 a 255.255.255.255 são endereços válidos. A alocação dos endereços é gerenciada por uma autoridade central. Números de rede são administrados pelo Internet Network Information Center (InterNIC). O NIC também é o principal arquivo de RFCs (padrões dos protocolos da arquitetura TCP/IP). No Brasil, a delegação de endereços IP é feita pela Fundação de Amparo à Pesquisa de São Paulo (FAPESP), órgão credenciado pelo InterNIC. Para facilidade de administração, os endereços IP são divididos em classes:

Classes de endereçamento (2) Classe A

0000 0000 . 0000 0000 . 0000 0000 . 0000 0000 1.0.0.0 - 126.0.0.0

Classe B

1000 0000 . 0000 0000 . 0000 0000 . 0000 0000 128.1.0.0 - 191.254.0.0

Classe C

1100 0000 . 0000 0000 . 0000 0000 . 0000 0000 192.0.1.0 - 223.255.254.0

Classe D

1110 0000 . 0000 0000 . 0000 0000 . 0000 0000 224.0.0.0 - 239.0.0.0

Classe E

1111 0000 . 0000 0000 . 0000 0000 . 0000 0000 240.0.0.0 - 254.0.0.0

\\A

\\A

classe A utiliza somente o primeiro octeto para identificar a rede. Os outros 3 octetos identificam o host e são usados livremente pelo administrador da rede. A classe A atende às necessidades de redes de grande abrangência, constituídas de poucas redes e com elevado número de estações, estando disponíveis 8 bits (o bit mais significativo vale 0) para identificação das redes, e 24 bits para a identificação das estações.

classe B utiliza somente os dois primeiros octetos para identificar a rede. Os demais 2 octetos identificam o host e são para uso do administrador da rede.


11

A classe B representa redes intermediárias, com 16 bits (os bits mais significativos valem 1 e 0) para a identificação das redes, e 16 para as estações. \\A

classe C utiliza somente os três primeiros octetos para identificar a rede. O octeto restante identifica o host e pode ser usado pelo administrador da rede.

A classe C atende tipicamente à faixa das rede locais. Como estas são bastante numerosas, são reservados 24 bits (os três bits mais significativos valem 1, 1 e 0) para a identificação das redes e apenas 8 bits para a identificação das estações. O(s) bit(s) mais significativo(s) do primeiro octeto determina(m) a classe do endereço e também quantos bits representam a porção correspondente à rede. Endereços classe A: \\Faixa dos números das redes: 1.0.0.0 até 126.0.0.0; \\Quantidade

de endereços de hosts: 16.777.214.

Endereços classe B: \\Faixa dos números das redes: 128.1.0.0 até 191.254.0.0; \\Quantidade

de endereços de hosts: 65.534.

Endereços classe C: \\Faixa dos números das redes: 192.0.1.0 até 223.255.254.0; \\Quantidade

de endereços de hosts: 254.

Classes A, B e C são as classes mais comuns de endereço IP. Endereços de classes D e E estão também definidos. Endereços de classe D começam em 224.0.0.0 e são usados para propósitos multicast. Endereços de classe E começam em 240.0.0.0 e são reservados para propósitos experimentais.

Endereços especiais

Endereços especiais RFC 1918 – Endereços privados 10.0.0.1 10.255.255.254 (10/8 prefix) 172.16.0.1 172.31.255.254 (172.16/12 prefix) 192.168.0.1 192.168.255.254 (192.168/16 prefix) Somente endereços IP públicos globais têm acesso à internet Empresas que usam endereços IP privados terão que usar servidor proxy para traduzir endereços privados para públicos

O RFC 1918 (Address Allocation for Private Internets) define as faixas de endereços que somente podem ser usados em redes privadas (ditos endereços privados). Esses endereços não podem ser roteados na internet. Os endereços que podem ser roteados são os demais endereços das classes A, B e C que são denominados endereços globais (ou endereços públicos) e não podem ser repetidos dentro da internet. A utilização dos endereços públicos é controlada pelo InterNIC.

Os endereços privados, como são usados no âmbito de uma organização, não precisam ser únicos na internet, podendo ser repetidos de uma organização para outra. Assim, cada organização tem liberdade para usar como quiser as faixas acima definidas, sem necessidade de obter permissão do InterNIC para isso. Por Conceitos básicos de roteamento

12


outro lado, esses endereços não poderão ser usados para acesso à internet, sendo necessário fazer uma tradução desses endereços privados para públicos através de um servidor chamado Proxy Server que faz a função Network Address Translation (NAT). A utilização de endereços IP públicos no âmbito de uma organização é desencorajada por causa da escassez de endereços IP e principalmente de segurança (vulnerável a ataques de hackers). De maneira geral, podemos classificar os hosts que usam endereços IP dentro de uma organização nas seguintes categorias: 1. Hosts que não precisam acessar a internet; 2. Hosts que precisam acessar um limitado conjunto de serviços da internet (e-mail, FTP, www etc.) que podem ser ajudados por gateways de aplicação; 3. Hosts que precisam de acesso irrestrito à internet (normalmente servidores disponibilizados para a internet). Os hosts das categorias 1 e 2 podem usar endereços privados, mas não os da categoria 3. Nos endereços privados relacionados acima, o prefixo indica o número de bits reservados para identificar a rede, do total de 32 bits. O primeiro bloco é uma classe A (10.0.0.0), o segundo bloco representa 16 classes B contíguas (todas as 16 classes têm os 12 bits de rede iguais) e o terceiro bloco representa 256 classes C contíguas (todas têm os 16 bits de rede iguais). Os bits que restam para hosts em cada bloco são denominados respectivamente de “bloco de 24 bits”, “bloco de 20 bits” e “bloco de 16 bits”.

Máscara de subrede padrão (1) A máscara de subrede informa aos dispositivos de rede quais octetos de um endereço IP representam a rede, para uma possível decisão de roteamento. A máscara de subrede usa a mesma representação do endereço IP; a única diferença é o uso do binário 1 em todos os bits do campo de rede e 0 nos de host. As três primeiras classes possuem uma máscara padrão Classe A 255.0.0.0 ou /8 Classe B 255.255.0.0 ou /16 Classe C 255.255.255.0 ou /24

Máscara de subrede padrão A máscara de subrede é um dos principais parâmetros de configuração dos equipamentos de rede, inclusive dos hosts. É ela que define quais bits (ou octetos) do endereço IP identificam a rede e quais identificam o host.

Note que os bits que identificam a rede têm obrigatoriamente o valor binário 1 e os bits que identificam o host possuem o valor binário 0. Os bits de rede estão, em geral, mais à esquerda, e os bits de host mais à direita no campo de endereço IP. Embora isso não seja obrigatório, de acordo com o RFC, é uma prática comum entre os administradores de redes. Outra maneira de indicar a máscara de subrede é contar quantos bits são usados para rede e indicá-los usando a notação “/nn”, como mostrado na figura.


13

Máscara de subrede padrão (2) Dado um endereço de host e uma máscara de subrede, é possível identificar a qual rede o host pertence A operação lógica realizada é o AND (E) Exemplo: host 131.108.2.16/24

A razão da máscara de subrede ser definida no formato de bits 1 para os octetos de rede e bits 0 para os octetos de host é permitir a rápida identificação da rede através de uma operação lógica simples: AND, como exemplificado na figura.

Endereço IP: 1000 0011.0110 1100.0000 0010.0001 0000 Máscara: 1111 1111.1111 1111.1111 1111.0000 0000 Rede:

1000 0011.0110 1100.0000 0010.0000 0000

O host pertence à rede 131.108.2.0

Roteamento IP

Roteamento IP

Conceitualmente, o roteamento do IP é bastante simples para um host. Se o destino estiver diretamente conectado ao host (enlace ponto a ponto) ou numa rede Ethernet compartilhada, o datagrama IP é enviado diretamente para o destino. Caso contrário, o host envia o datagrama para um default router (gateway padrão) e deixa o roteador entregar o datagrama no seu destino.

Diretamente conectado Gateway padrão Configuração do host IP Somente como host Como host e roteador

O host poderá ser configurado para atuar como host ou como host e roteador. Se o host estiver configurado para atuar como um roteador, ele poderá encaminhar datagramas de uma de suas interfaces de rede para outra. Se não estiver configurado como roteador, ele só poderá encaminhar datagramas gerados pelas camadas superiores do protocolo nele residente (TCP, UDP, ICMP ou IGRP), não podendo encaminhar datagramas recebidos de suas interfaces de rede. O IP pesquisa uma tabela de roteamento na memória do host cada vez que ele recebe um datagrama de uma interface de rede para enviar. Os seguintes procedimentos serão executados: \\Primeiro

o IP verifica se o endereço IP de destino é o seu próprio ou se é um endereço IP broadcasting; se for este o caso, ele entrega o datagrama para o protocolo especificado no campo protocolo do cabeçalho do datagrama;

\\Se

o datagrama não se destina a ele, o IP verifica a sua configuração de host/router: 1. Se ele estiver configurado como router, executará os procedimentos de roteamento IP baseado na sua tabela de roteamento residente na memória do host. 2. Se ele não estiver configurado como router, o datagrama será simplesmente descartado.


14


Exemplo de roteamento IP

Exemplo de roteamento IP

Considerando as duas redes locais da figura, uma no Rio de Janeiro e outra em São Paulo. A rede local do RJ usa o endereço de rede 172.16.10.0/24 e a de SP usa o endereço de rede 172.16.20.0/24. Os respectivos roteadores usam na interface diretamente conectada às redes (interface Ethernet E0) um endereço válido de cada uma delas; no caso, Rede local RJ 172.16.10.0/24 no RJ o endereço 172.16.10.1 e em SP o endereço Rede local SP 172.16.20.0/24 172.16.20.1. Esses endereços serão os gateways padrão das respectivas redes, tendo que ser configurados em todos os hosts das duas redes. Para se comunicarem entre si, os roteadores usam uma linha dedicada conectada a uma interface serial (S0). Os endereços dessas interfaces têm que ser diferentes dos endereços das interfaces Ethernet, ou, em outras palavras, têm que ser de outra rede. Assim, os roteadores se comunicam através da rede 172.16.30.0/24, sendo que a interface serial do roteador RJ tem o endereço 172.16.30.1 e a de SP o endereço 172.16.30.2. Dessa forma, a rede 172.16.30.0/24 é uma “ponte” entre as duas redes locais. Suponha que a máquina RJ 01 tenha que enviar um pacote para a máquina SP 03. Os respectivos endereços de origem e destino serão: Origem: 172.16.10.10 Destino: 172.16.20.22 Usando a operação AND descrita anteriormente, a máquina RJ 01 conclui que o endereço de destino não é da rede dela e, nesse caso, envia para o gateway padrão, porque o host não foi configurado como roteador. Ao chegar no roteador RJ (via interface 172.16.10.1), o roteador consulta sua tabela de rotas para saber como despachar o pacote. A sua tabela de rotas informa que, para chegar na rede de destino (172.16.20.0/24), ele precisa enviar o pacote para o roteador de SP no endereço 172.16.30.2 (next hop), via interface serial que tem o endereço 172.16.30.1. E assim ele o faz. O roteador de SP consulta sua tabela de rotas e verifica que está diretamente conectado à rede de destino, logo ele entrega o pacote ao host 172.16.20.22 via interface 172.16.20.1.


15

Dirija-se a págna 22 e faça a atividade 1. Esta atividade deve ser executada em até 30 minutos. Todos os comandos devem funcionar corretamente. Não esqueça de manter todas as máquinas com a mesma configuração. Conclusão \\Esta atividade mostra como configurar subredes com máscara de subrede padrão e endereços privados \\Permite

que os alunos possam executar

\\Planejamento \\Definição

dos endereços dos gateways padrão

\\Configuração \\Testes \\Em

do endereçamento das subredes

dos micros de cada subrede

de continuidade

caso de mau funcionamento, resolução de problemas

Arquitetura TCP/IP

Arquitetura TCP/IP

A arquitetura TCP/IP é composta de um conjunto de protocolos e foi pioneira na concepção de conectar qualquer máquina Unix (ou que utilize TCP/IP) a qualquer outra, através de subredes interconectadas por gateways (roteadores). Conjunto pioneiro de protocolos “Universal”

Como as especificações seguem um padrão e são de conhecimento público (Request for Comments – RFC), o TCP/IP é de aplicação universal.

Em um ambiente TCP/IP, estações comunicam-se com servidores ou outras estações. Isso é possível porque cada nó que usa o protocolo TCP/IP tem um único endereço de rede lógico de 32 bits. O Transmission Control Protocol (TCP) é o protocolo de transporte responsável pela entrega confiável dos dados no destino. No RFC 793 que o define, ele é chamado de Host to Host Protocol, porque é um protocolo residente somente nos hosts e não nos gateways. Os dados são enviados de nó a nó, cada um deles decidindo qual é o próximo (next hop). O responsável pelo roteamento na rede é o Internet Protocol (IP).


16


Camadas da arquitetura TCP/IP (1)

Camadas da arquitetura TCP/IP Segundo os RFCs, a arquitetura TCP/IP possui 4 camadas: 1. Aplicação – Nesta camada estão os protocolos das aplicações suportadas por esta arquitetura. Por exemplo, o protocolo HTTP é da aplicação www, o protocolo SMTP é da aplicação e-mail etc. 2. Transporte – Nesta camada existem dois protocolos: TCP (orientado à conexão) e UDP (sem conexão). A aplicação usará o que for mais adequado.

3. Rede – Nesta camada temos o IP, que é um protocolo de rede sem conexão (serviço datagrama) e os protocolos Internet Control Message Protocol (ICMP), que envia mensagens de erro, e Internet Group Management Protocol (IGMP) para endereçamento multicast. 4. Subrede – Nesta camada temos as subredes que são suportadas pelo IP. Tipicamente são redes locais (LAN), enlaces seriais (WAN) etc.

Camadas da arquitetura TCP/IP (2)

A arquitetura TCP/IP, conforme já vimos, é constituída de 4 camadas de protocolos. Cada camada trata seus dados e monta a sua Unidade de Dados do Protocolo (Protocol Data Unit – PDU). A camada de aplicação monta a sua PDU com os dados da aplicação e o respectivo protocolo (SMTP, FTP etc.) e passa para o TCP entregar ao host do outro lado. Visto dessa forma, o TCP é comumente denominado Host to Host Protocol, uma vez que ele se encarrega da comunicação fim a fim entre os hosts que estão trocando informações.

O TCP monta a sua PDU (segmento TCP) e passa para o protocolo IP, que fica com a tarefa de entregar o segmento TCP através de uma rede IP. Para isso, o protocolo IP coloca o seu header (cabeçalho), criando assim a sua PDU (chamada de datagrama IP ou simplesmente pacote IP). Nesse momento, o protocolo IP precisa se comunicar com a subrede, seja ela qual for, para enviar o pacote IP devidamente “encapsulado” dentro do quadro da camada de enlace de dados. Evidentemente a subrede não entende o endereçamento IP e tem seu próprio endereçamento. Assim, o protocolo IP precisa usar o endereçamento da subrede Roteamento avançado – Sessão de aprendizagem 1

17

para enviar o pacote IP. Existe então a necessidade de uma interface entre o protocolo IP e a subrede.

Camada de subrede

Camada de subrede Rede local Ethernet Address Resolution Protocol (ARP) Reverse ARP (RARP) Enlace serial Point to Point Protocol (PPP) Fibra – Packet Over Sonet (POS) Par metálico – V.24 / V.35 ... Outras FDDI Rede local token ring

As subredes mais usadas são: Rede Local Ethernet Usa o endereçamento físico da interface de rede (placa Ethernet) e por isso é chamado de endereço físico da estação. No caso, o protocolo de camada de enlace usado é o protocolo de Controle de Acesso ao Meio (Media Access Control – MAC). O endereço MAC é constituído de 6 octetos (48 bits), é definido pelo fabricante da placa e não pode ser mudado.

Então o protocolo IP precisa fazer um mapeamento do endereço IP no endereço MAC. Ele faz isso usando o protocolo Address Resolution Protocol (ARP). O mapeamento inverso (endereço MAC em endereço IP) é feito pelo protocolo Reverse ARP (RARP). Enlace serial Nesse caso é necessário encapsular o pacote IP e enviá-lo através do enlace serial. Para isso, é usado o protocolo Point to Point Protocol (PPP), sucessor do SLIP, que está obsoleto atualmente. Os enlaces seriais mais usados são o par metálico (interfaces V.24, V.35 etc.) para velocidades de até 2 Mbps, e a fibra óptica (interface Packet Over Sonet – POS) que permite a utilização de velocidades muito altas (atualmente até 10 Gbps). Outras Temos ainda as redes Metropolitan Area Network (MAN), construídas com a tecnologia FDDI (obsoleta), e também redes locais token ring pouco utilizadas.

Protocolo ARP

Protocolo ARP O protocolo IP tem que entregar um datagrama IP, e ele só conhece o endereço IP do destino, e não o endereço físico; assim, ele precisa fazer o mapeamento do endereço IP em endereço físico, no caso o endereço MAC de uma rede local Ethernet.

Mapeia IP Ethernet Domínio de broadcasting


Antes de enviar uma mensagem ARP, a máscara de subrede é consultada. Suponhamos, nesse caso, que a máscara determinou que os nós estão na mesma subrede.

18


O ARP é usado para resolver ou mapear um endereço IP conhecido em um endereço MAC, para permitir a comunicação em um meio compartilhado como o de uma rede Ethernet. Primeiro é consultado um cache ARP para os endereços resolvidos anteriormente. Se o endereço estiver no cache, o IP envia diretamente o datagrama IP encapsulado no quadro Ethernet. Se não estiver no cache, a resolução é feita enviando uma mensagem broadcasting de requisição ARP (ARP request). A máquina que tem o endereço IP consultado responderá então com um ARP reply. Para consultar o cache ARP, no modo comando do MS-DOS (janela DOS), digite o comando arp –a. Se não tiver sido enviado nenhum datagrama ainda, somente existirá uma entrada na tabela ARP, contendo o endereço IP e o endereço MAC do gateway padrão. Isto porque o host precisará enviar o datagrama para o gateway padrão se o endereço de destino for de outra rede. Da mesma forma, caso cheguem datagramas IP de outra rede, eles serão entregues pelo gateway padrão, que usará o processo descrito acima. Isto significa que o gateway padrão poderá também enviar mensagens ARPs broadcasting. Um conjunto de máquinas numa rede local — tal que todas recebam mensagens ARP broadcasting de suas vizinhas — é chamado de domínio de broadcasting. Duas coisas importantes sobre mensagens ARP broadcasting: 1. Os hubs e switches propagam as mensagens ARP broadcasting por default; 2. Os roteadores NÃO propagam as mensagens ARP broadcasting por default.

Captura de pacotes IP

Assim, se as mensagens ARP broadcasting estiverem congestionando o tráfego da rede local, a solução é dividir a rede em subredes usando roteadores. Note que a segmentação das redes locais usando switches resolve o problema de domínio de colisão, mas não o de domínio de broadcasting.

Programa Ethereal de captura de pacotes

Captura de pacotes IP A janela principal do Ethereal consiste das seguintes partes: \\Menu \\Barra

– Usado para iniciar algumas operações;

de ferramentas principal – Provê acesso rápido às operações mais usadas do menu;


19

\\Barra

de ferramentas de filtro – Permite manipular diretamente o filtro que está sendo usado;

\\Lista

de pacotes – Mostra um resumo de cada pacote capturado; selecionando um determinado pacote os dados detalhados serão mostrados nos quadros seguintes;

\\Detalhes

dos pacotes – Mostra os campos do pacote selecionado no quadro anterior;

\\Dados

dos pacotes – Mostra os bytes dos campos do pacote selecionado na lista de pacotes; destaca os campos selecionados no quadro anterior;

\\Barra

de status – Mostra informações detalhadas sobre o estado do programa e os dados capturados.

Barra de ferramentas do Ethereal

Barra de ferramentas do Ethereal Interfaces – Mostra as interfaces de rede disponíveis para captura; Options – Opções de captura; permite o início da captura de pacotes; Start – Inicia a captura de pacotes com as opções previamente definidas; Stop – Interrompe o processo corrente (ao vivo) de captura de pacotes; Restart – Interrompe o processo de captura de pacotes e o reinicia; Open – Permite a carga de um arquivo de captura para análise; Save As – Permite gravar o arquivo de captura corrente; Close – Fecha o arquivo de captura corrente.

\\Interfaces

– Abre a caixa de diálogo Lista de interfaces de captura, que mostra as interfaces de rede disponíveis para captura de pacotes;

\\Options

– Abre a caixa de diálogo Opções de captura e permite o início da captura de pacotes;

\\Start

– Inicia a captura de pacotes de acordo com as opções previamente definidas;

\\Stop

– Interrompe o processo corrente (ao vivo) de captura de pacotes;

\\Restart

– Interrompe o processo corrente (ao vivo) de captura de pacotes e o reinicia novamente, para sua conveniência;

\\Open

– Abre uma caixa de diálogo de abertura de arquivo que permite a carga de um arquivo de captura para visualização e análise;

\\Save

As – Permite gravar o arquivo de captura corrente onde você desejar; abre a caixa de diálogo Save capture file as;

\\Close

– Fecha o arquivo de captura corrente; se você não gravou o arquivo ainda, será solicitado que o faça antes;

\\Reload

– Permite que seja novamente carregado o arquivo de captura corrente para visualização e análise;

\\Print

– Permite a impressão de todos ou de parte dos pacotes do arquivo de captura; abre a caixa de diálogo Impressão Ethereal;

\\Find

Packet – Abre uma caixa de diálogo que permite a localização de pacotes;


\\Go

Back – Volta atrás no histórico de pacotes;

\\Go

Forward – Avança no histórico de pacotes;

20

Escola Superior de Redes RNP \\Go

to Packet – Abre uma caixa de diálogo que permite especificar o número de um pacote específico que se deseja visualizar;

\\Go

To First Packet – Vai para o primeiro pacote do arquivo de captura;

\\Go

To Last Packet – Vai para o último pacote do arquivo de captura;

\\Colorize

– Permite colorir (ou não) a lista de pacotes;

\\Auto

Scroll in Live Capture – Na captura de pacotes, permite rolar a lista de pacotes (ou não) enquanto é feita a captura ao vivo;

\\Zoom

In – Faz o zoom nos dados do pacote (aumenta o tamanho da fonte);

\\Zoom

Out – Faz o zoom nos dados do pacote (diminui o tamanho da fonte);

\\Normal

Size – Retorna o nível de zoom para 100%;

\\Resize

Columns – Modifica a largura das colunas de forma que o conteúdo seja visualizado corretamente;

\\Capture

Filters – Abre uma caixa de diálogo que permite criar e editar filtros de captura; você pode dar nomes aos filtros e gravá-los para uso posterior;

\\Display

Filters – Abre uma caixa de diálogo que permite criar e editar filtros de visualização; você pode dar nomes aos filtros e gravá-los para uso posterior;

\\Coloring

Rules – Abre uma caixa de diálogo que permite colorir pacotes no quadro de lista de pacotes de acordo com os filtros escolhidos; pode ser muito útil para destacar certos tipos de pacotes;

\\Preferences

– Abre uma caixa de diálogo que permite configurar preferências para muitos parâmetros que controlam o Ethereal; é possível salvar essas configurações para usá-las na próxima vez;

\\Help

– Abre uma caixa de diálogo de ajuda.

Dirija-se a págna 23 e faça a atividade 2. Esta atividade deve ser executada em até 15 minutos.


1 Sessão de aprendizagem 1 Conceitos básicos de roteamento Roteiro de atividades Tópicos e conceitos \\Conceito

de roteamento

\\Endereçamento \\Classes

IP

de endereçamento

\\Máscara

de subrede

\\Roteamento

IP

\\Camadas

da arquitetura TCP/IP

\\Protocolo

ARP

Competências técnicas desenvolvidas \\Planejamento \\Definição


\\Configuração \\Testes



de continuidade

\\Resolução

de problemas

Tempo previsto para as atividades \\45-60

minutos

Observação Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou em máquina do laboratório.


22

Atividade 1 – Configuração de subredes IP Classe C 1. A rede Classe B 192.168.0.0/16 deve ser subdividida em subredes Classe C, de modo que cada subrede contenha, no máximo, 4 micros, com 1 aluno por micro. É responsabilidade dos alunos dos grupos configurarem corretamente seus micros. Os alunos devem verificar a configuração dos seus micros com o comando: ipconfig As configurações dos micros dos alunos serão feitas no ambiente Windows via Painel de Controle » Conexões de Rede » Propriedades TCP/IP. Deverão ser configurados: endereço IP, máscara de subrede: 255.255.255.0 e o gateway padrão. 2. No SSA que será o gateway padrão de todas as subredes, usando o sistema operacional Linux, faça as configurações conforme mostrado a seguir: \\O

número de interfaces eth0:n configuradas deve ser proporcional ao número de subredes existentes.

\\O

gateway padrão das subredes deve ser o SSA (Servidor de Sala de Aula – Linux) e tem que estar na mesma rede local dos micros dos alunos.

\\As

subredes serão: 192.168.1.0/24, 192.168.2.0/24, etc., e os respectivos gateways padrão serão: 192.168.1.254, 192.168.2.254 etc.

Acrescentar então as interfaces virtuais eth0:1, eth0:2, eth0:3 etc., uma para cada subrede configurada pelos alunos. Note que a primeira interface definida (eth0) é a interface real. Ela pode ter qualquer endereço de rede, porque não será usada nesta atividade. Melhor deixar como estiver.

Criar as interfaces virtuais no SSA utilizando os comandos abaixo: ifconfig eth0:1 192.168.1.254/24 ifconfig eth0:2 192.168.2.254/24 ifconfig eth0:3 192.168.3.254/24 etc. 3. O arquivo /etc/sysctl.conf deve ser configurado com o parâmetro net/ipv4/ip_forward=1 para garantir que o Linux fará o encaminhamento de pacotes IP (IP forwarding) entre as interfaces de rede virtuais aqui definidas. O serviço inet.d deve ser reiniciado ou o servidor SSA deve ser reiniciado, para garantir que esta modificação esteja operacional. Garantir que a interface física (eth0) esteja up e funcionando corretamente.


23

4. Os alunos devem executar os procedimentos a seguir individualmente e na seqüência determinada. Nota: Antes de executar os comandos a seguir, desativar o firewall do Windows.

Observe que no teste de continuidade entre subredes o gateway padrão tem que estar ligado e carregado com o sistema Linux. O comando traceroute deve indicar o gateway padrão como HOP 1. Recomendar aos alunos que anotem os resultados de cada atividade.

Nota: todos os comandos devem funcionar corretamente. Se não, corrigir o problema.

1. Testar a continuidade dentro da subrede Comando ping para as demais máquinas da subrede 2. Testar a continuidade entre subredes \\Comando

ping para uma máquina de cada subrede

\\Comando

traceroute para uma máquina de cada subrede

Ao final desta atividade todas as máquinas devem continuar com a configuração atual, porque vamos usá-las novamente.

Atividade 2 – Captura de pacotes IP Os alunos devem executar os seguintes procedimentos individualmente e na seqüência determinada: Nota: todos os comandos devem funcionar corretamente. Se não, corrigir o problema.

1. Iniciar o programa Wireshark 2. Iniciar a captura na interface de rede local 3. Testar a continuidade entre subredes \\Comando


\\Comando


4. Parar o programa Wireshark 5. Analisar o arquivo de captura \\Devem

aparecer as mensagens ARP

\\Devem

aparecer as mensagens ICMP

Observe que no teste de continuidade entre subredes o gateway padrão tem que estar ligado e carregado com o sistema Linux.


Escola Superior de Redes RNP Se não aparecerem mensagens ARP broadcasting é porque a tabela ARP está atualizada e o micro não precisou fazer broadcasting para descobrir o endereço MAC da estação de destino. Basta verificar esse fato com o comando: arp –a Para forçar o broadcasting, basta apagar as entradas da tabela ARP com o comando: arp –d Após o término desta atividade, retornar as máquinas à configuração original.

Mais informações: Manual do Ethereal (tradução parcial baseada no documento): LAMPING, Ulf; SHARPE, Richard. Ethereal´s User Guide, 18029 for Ethereal 0.10.14.


24

2 Sessão de aprendizagem 2 Configuração de máscara de subrede Sumário da sessão Subredes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Tabela de subredes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Exemplo de subrede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 IP Subnet Calculator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 VLSM e CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Exemplo de VLSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Atividade 1 – Configuração de subredes IP Classe C. . . . . . . . . . . . . . . . . . . . . 34 Atividade 2 – Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Atividade 3 – Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Atividade 4 – Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

26


Subredes

Subredes (1) Rede 131.108.0.0 sem subredes (131.108.0.0/16)

O mundo exterior enxerga nossa organização como uma rede única, e nenhuma informação detalhada sobre nossa estrutura interna é requerida.

Rede 131.108.0.0 com subredes (131.108.0.0/24)

Sem subredes, a utilização do espaço de endereçamento é muito ineficiente; com muitos hosts na mesma rede, a administração torna-se complicada. Com subredes, a utilização dos endereços de rede é mais eficiente e a administração é mais simples. No exemplo acima, a rede 131.108.0.0 é subdividida ou quebrada em três subredes: 131.108.1.0, 131.108.2.0 e 131.108.3.0. Essas subredes não serão enxergadas pelo mundo exterior. É necessário utilizar roteadores para efetuar o roteamento entre elas. Na definição das subredes foi utilizado o terceiro octeto, originalmente dedicado a host, para identificar as subredes. Do ponto de vista de endereçamento, subredes são uma extensão do número da rede. Subredes são usadas para dividir uma rede grande em subredes menores. Os bits que deveriam ser usados exclusivamente para hosts (no caso o terceiro octeto) são usados para identificação das subredes.

Subredes (2)

O administrador da rede decide o tamanho das subredes. O equipamento da rede precisa entender as subredes. Somente os roteadores internos conhecem essa divisão em subredes. Decisões de roteamento são portanto baseadas em números de rede e subrede.

Subredes (3) Rede

Endereço de rede

131

Host

108

0

Rede

Máscara de subrede padrão (16 bits) Máscara de subrede de 24 bits

255

255 Rede

255

255

0 Host

0 Subrede

255

0 Host

0

Usa bits do campo de host a partir do bit mais significativo


A rede 131.108.0.0/16 foi subdividida em subredes, usando para isso o terceiro octeto (que seria de host). Lembre-se de que somente o endereço de rede é usado pelos roteadores para realizar a operação de roteamento e o administrador de rede não pode usar os octetos de rede para subredes, mas pode usar como quiser os octetos de host, pois estes são de administração local.

27

Tabela de subredes

Tabela de subredes Bits

bit 8 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1

Pesos

128 64 32

Decimal bits rede bits host

ID redes

16

8

4

2

1

Máscara

0

0

0

0

0

0

0

0

0

0

8

Máscara

1

0

0

0

0

0

0

0

128

1

7

Máscara

1

1

0

0

0

0

0

0

192

2

6

0,64,128,192

Máscara

1

1

1

0

0

0

0

0

224

3

5

0,32,64,96,…

Máscara

1

1

1

1

0

0

0

0

240

4

4

0,16,32,48,…

Máscara

1

1

1

1

1

0

0

0

248

5

3

0,8,16,24,32,..

Máscara

1

1

1

1

1

1

0

0

252

6

2

0,4,8,12,16,…

Máscara

1

1

1

1

1

1

1

0

254

7

1

0,2,4,6,8,10,..

Máscara

1

1

1

1

1

1

1

1

255

8

0

0,1,2,3,4,5,6,..

0,128

Bits de subredes devem ser alocados a partir dos bits de ordem mais alta (bits mais significativos) do campo correspondente aos bits de host. O roteador extrai o endereço de destino IP de um pacote e obtém a máscara de subrede. O roteador executa uma operação lógica AND para obter um número de rede. Durante uma operação lógica AND, a porção de host do endereço de destino é removida.

As decisões de roteamento são então baseadas somente no número da rede. Para cada rede/subrede, o primeiro endereço da faixa de endereços identifica a rede/subrede. Exemplo: o endereço 131.108.0.0 é o NetID (identificação da rede) da rede 131.108.x.x. O endereço 131.108.1.0 é o SubNetID (identificação da subrede) da subrede 131.108.1.x. Para cada rede/subrede, o último endereço da faixa de endereços é o endereço de broadcasting da rede/subrede. Exemplo: o endereço 131.108.255.255 é o endereço de broadcasting da rede 131.108.x.x. O endereço 131.108.1.255 é o endereço de broadcasting da subrede 131.108.1.x. Os endereços de SubNetID (identificação) e de broadcasting explicados acima são derivados da regra de “todos os bits 0” e “todos os bits 1”, que determina que nenhum endereço de host/rede pode ter todos os bits com o valor 0 ou todos os bits com o valor 1. Broadcasts são suportados pela internet. O endereço de broadcast é formado pelo uso de 1’s em um campo dentro do endereço IP. Broadcasts de todas as redes (255.255.255.255) não são propagados; são considerados broadcasts locais. Broadcasts diretos em redes específicas são permitidos e roteados pelo roteador. Esse broadcast direto contém somente 1’s na parte do endereço correspondente aos bits de host. Note que os RFCs declaram que você não pode ter um bit apenas para subrede, o que significaria que o bit sempre seria 0 ou 1, o que é ilegal. Assim, a primeira máscara de subrede válida legalmente (segundo os RFCs, bem entendido) é 192, e a última é 252, uma vez que você precisa de pelo menos 2 bits para hosts e 2 bits para redes.

Configuração de máscara de subrede

28


Exemplo de subrede

Exemplo de subrede

Considere a rede Classe C 200.252.6.0/24, que desejamos dividir em subredes tais que cada uma tenha até 64 micros (o máximo, teoricamente). A máscara de subrede para isso é 255.255.255.192.

Rede Classe C 200.252.6.0/24 Máscara 255.255.255.192 Tabela bits – /26 2 bits para subrede 6 bits para hosts Subredes possíveis: 00, 01, 10, 11 Válidas: 01 (64) e 10 (128) BITS SUBNET 01 01 01 01

BITS HOST 000000=64 000001=65 111110=126 111111=127

BITS SIGNIFICADO SUBNET Subnet ID 10 1o host válido 10 Último host válido 10 Subnet broadcasting 10

BITS HOST SIGNIFICADO 000000=128 Subnet ID 000001=129 1o host válido 111110=190 Último host válido 111111=191 Subnet broadcasting

Na tabela de bits vemos que 192 = 11000000, logo temos 2 bits para subrede e 6 bits para hosts. A máscara de subrede ficaria assim em binário: 11111111.11111111.11111111.11000000 (/26).

As subredes possíveis (combinando os 2 bits) seriam: 00, 01, 10 e 11. Segundo os RFCs, você não pode ter todos os bits 0 ou todos os bits 1 ao mesmo tempo, portanto as duas únicas subredes válidas são: \\01000000

= 64 (todos os hosts com bits 0) ou

\\10000000

= 128 (todos os hosts com bits 0)

Os hosts válidos devem ser definidos usando os números entre as subredes, menos os hosts com todos os bits 0 e todos os bits 1. O subnet ID (endereço da subrede) é calculado usando todos os bits de hosts 0, 01000000 = 64 para a primeira subrede e 10000000 = 128 para a segunda subrede. O broadcast address (endereço de broadcast) é calculado usando todos os bits de hosts 1, 01111111 = 127 para a primeira subrede e 10111111 = 191 para a segunda subrede. Os endereços válidos de hosts ficam entre os dois: 65-126 para a primeira subrede e 129-190 para a segunda subrede. Resumo: \\200.252.6.64 e 200.252.6.127 são os subnet ID e broadcast da primeira subrede; \\200.252.6.128

e 200.252.6.191 são os subnet ID e broadcast da segunda subrede;

\\200.252.6.65-200.252.6.126

são os hosts válidos da primeira subrede;

\\200.252.6.129-200.252.6.190

são os hosts válidos da segunda subrede.

Em decorrência de usarmos os bits do campo de host com valor 0 (zero) para indicar a identificação da subrede, e de usarmos os bits do campo de host com valor 1 para indicar o endereço de broadcasting da subrede, perdemos dois endereços de host por subrede.


29

A fórmula de cálculo dos endereços disponíveis de host por subrede fica assim: 2n – 2, onde n = número de bits usados para hosts. De maneira análoga, perdemos a primeira e a última subrede, conforme demonstrado no exemplo. A fórmula de cálculo da quantidade de subredes fica assim: 2n – 2, onde n = número de bits usados para subredes.

IP Subnet Calculator

IP Subnet Calculator

Esses mesmos cálculos são feitos automaticamente por um programa chamado IP Subnet Calculator, que pode ser obtido gratuitamente no site: http://www.wildpackets.com/products/ ipsubnetcalculator. Existem outros programas disponíveis na internet. Basta digitar na janela IP Address o endereço IP em questão (no caso 200.252.6.100), selecionar a opção Subnet Info, informar o número de bits que será usado para subrede (no caso 2) e pronto. O programa automaticamente calcula a subnet mask, o número máximo de subredes (janela Max # of Subnets) e o número máximo de hosts por subrede (janela Max # of Hosts/Subnet). Mostra também a distribuição dos bits na máscara de subrede (bits de rede, subrede e host) e informa o número de bits usado para identificar a rede e subredes (janela Mask Bits), que no caso é 26. Nesse caso, é comum chamar a rede de 200.252.6.0/26. Como o endereço IP informado pertence à primeira subrede, ele informa também o subnet ID e o subnet broadcast da subrede. A opção Subnet/Hosts informa todas as possíveis subredes e as informações calculadas na página anterior. O programa aceita também a opção Allow 1 subnet bit que, apesar de não ser permitida nos RFCs, é amplamente usada. Nesse caso específico, se usarmos essa opção, será possível definirmos 4 subredes e não apenas duas, conforme previsto nos RFCs. Em roteadores Cisco, podemos configurar essa opção com o comando ip subnet-zero.


30


Exemplo IP Subnet Calculator (1)

Veremos um exemplo de configuração usando a rede 131.108.0.0. Na opção Address Info digitamos o endereço da rede Classe B (131.108.0.0) e apertamos . O programa mostra todos os dados pertinentes a esta rede (tela 1). Na opção Subnet Info escolhemos 8 bits para subrede e apertamos .

O programa informa os bits da máscara (24 bits), a máscara (255.255.255.0), a quantidade máxima de subredes e hosts por subrede, a distribuição dos bits por rede, subrede e host, a faixa de endereços válidos de host, a subnet ID e o endereço de broadcast (tela 2). Observe que a opção Allow 1 Subnet Bit permite que usemos para subredes o primeiro endereço de subrede (131.108.0.0), e também o último (131.108.255.255).


Na opção Subnets/Hosts vemos todas as possíveis subredes, de acordo com os RFCs, seus IDs, broadcasts e faixas de endereços de hosts válidos. A primeira tela mostra os primeiros endereços de subredes e a segunda tela mostra os últimos endereços. Se usarmos a opção Allow 1 Subnet Bit veremos que o programa automaticamente calcula 256 subredes, e não somente 254.

Dirija-se a página 34 e faça a atividade 1. Esta atividade deve ser executada em até 30 minutos. Ao final desta atividade todas as máquinas devem retornar à configuração original. Não esqueça de retornar todas as máquinas à configuração original.


31

VLSM e CIDR

VLSM e CIDR Variable Length Subnet Mask (VLSM) Otimização de subredes com grande número de hosts Subrede dentro de subrede – RFC 1009 Suportado por RIP v.2 e OSPF Classless InterDomain Routing (CIDR) RFCs 1518, 1519 e 1467 Agrupamento de Classes C contíguas Otimiza tabela de roteamento Conhecido como supernetting

A idéia por trás de VLSM é oferecer maior flexibilidade na divisão de uma rede em subredes, de forma a manter o número adequado de hosts em cada subrede. Sem VLSM, somente podemos aplicar uma máscara de subrede a todas as subredes da rede maior, obrigando que todas as subredes tenham o mesmo limite de quantidade de hosts. Pode ser necessário ter subredes com quantidades diferentes de hosts.

Por exemplo, suponha que você tenha uma Classe C 192.214.11.0 e tenha que dividi-la em 3 subredes, sendo uma com 100 hosts e as outras duas com 50 hosts cada. Ou você divide em 2 subredes (126 hosts em cada uma) ou divide em 4 subredes (62 hosts em cada). Nenhuma dessas opções resolve o seu problema. A solução é usar VLSM e criar as seguintes subredes: \\Uma

subrede com 126 hosts;

subrede com 126 hosts, dividida por sua vez em duas subredes com 62 hosts cada;

\\Uma

A seguir veremos como fazer isso. CIDR é o agrupamento de Classes C contíguas, embora possa ser aplicado a outras classes de endereçamento. O objetivo é otimizar a tabela de roteamento, reduzindo o número de entradas na tabela. É o oposto de subnetting, e por isso é chamado de supernetting.


Exemplo de VLSM Sem usar VLSM, teríamos duas alternativas de divisão da rede 192.214.11.0: \\2

subredes com 128 hosts cada, máscara de subrede 255.255.255.128 ou

\\4

subredes com 64 hosts cada, máscara de subrede 255.255.255.192

Com VLSM, podemos usar as duas máscaras, dividindo como mostrado na figura acima. Ficamos apenas com um pequeno problema de RFC: não poder usar subrede com máscara de 1 bit, porque teríamos uma subrede com todos os bits zero, contrariando as normas. Para superar esse pequeno inconveniente, emitimos o comando ip subnet-zero, que permite a divisão de subredes que queremos. Configuração de máscara de subrede

32

Escola Superior de Redes RNP Como podemos observar na figura acima, ficamos com 3 subredes, da seguinte forma: \\192.214.11.0,

broadcast 192.214.11.127 e hosts 11.1 até 11.126, com máscara 255.255.255.128

\\192.214.11.128,


\\192.214.11.192,


O único cuidado que precisamos tomar é o de definir os endereços das interfaces do roteador na faixa correta da subrede onde a interface está localizada.

Dirija-se à página 36 e faça a atividade 2. Este estudo de caso deve ser resolvido em 15 minutos. Os alunos podem fazê-lo em duplas. Conclusão \\Este estudo de caso simula a atividade de planejamento de endereçamento de subredes \\Cálculo

de endereços e máscaras de subredes

\\Acréscimo

de novas redes sem refazer a configuração

\\Configuração


de interfaces de roteadores

2 Sessão de aprendizagem 2 Configuração de máscara de subrede Roteiro de atividades Tópicos e conceitos \\Conceito

de roteamento

\\Endereçamento \\Classes

IP

de endereçamento

\\Máscara

de subrede

\\Roteamento

IP

\\Camadas

da arquitetura TCP/IP

\\Protocolo

ARP

Competências técnicas desenvolvidas \\Planejamento \\Definição


\\Configuração \\Testes



de continuidade

\\Resolução

de problemas


minutos



34

Atividade 1 – Configuração de subredes IP Classe C 1. A rede Classe C 192.168.100.0/24 deve ser subdividida em subredes Classe C, tais que cada subrede contenha, no máximo, 4 micros, com 1 aluno por micro. É responsabilidade dos alunos dos grupos configurarem corretamente seus micros. Os alunos devem verificar a configuração dos seus micros com o comando: ipconfig As configurações dos micros dos alunos serão feitas no ambiente Windows via Painel de Controle » Conexões de Rede » Propriedades TCP/IP. Deverão ser configurados: endereço IP, máscara de subrede e o gateway padrão.” 2. No SSA que será o gateway padrão de todas as subredes, usando o sistema operacional Linux, faça as configurações conforme mostrado a seguir. O número de interfaces eth0:n configuradas deverá ser proporcional ao número de subredes existentes. O gateway padrão das subredes deve ser o SSA (Servidor de Sala de Aula – Linux) e tem que estar na mesma rede local dos micros dos alunos. Note que a primeira interface definida (eth0) é a interface real. Ela pode ter qualquer endereço de rede, porque não será usada nesta atividade. Melhor deixar como estiver. Acrescente então as interfaces virtuais eth0:1, eth0:2, eth0:3 etc, uma para cada subrede configurada pelos alunos. A configuração das subredes pode ser feita com base na quantidade de hosts por subrede (4) ou na quantidade de subredes. Se for pela primeira opção, precisaremos de 3 bits de hosts, porque permite até 6 hosts por subrede (23 – 2 = 6). Consultando a tabela de bits na linha que tem 3 bits de hosts, vemos que a máscara de subrede será: 255.255.255.248 e que as subredes serão: 0, 8, 16, 24, 32 etc. Teremos então as seguintes subredes: \\1ª

subrede: 192.168.100.8/29, com endereços de hosts de .9 a .14 (usar o endereço .14 para o gateway padrão desta subrede);

\\2ª


\\3ª

subrede: 192.168.100.24/29, com endereços de hosts de .25 a .30 (usar o endereço .30 para o gateway padrão desta subrede); etc


35

Se for pela segunda opção, precisaremos de 3 bits de redes, permitindo até 6 subredes (23 – 2 = 6). Consultando a tabela de bits na linha que tem 3 bits de redes, vemos que a máscara de subrede será 255.255.255.224, e que as subredes serão 0, 32, 64, 96 etc. Teremos então as seguintes subredes: \\1ª


\\2ª


\\3ª

subrede: 192.168.100.96/27, com endereços de hosts de .97 a .126 (usar o endereço .126 para o gateway padrão desta subrede); Etc.

Configurar os gateways padrão de acordo com a opção escolhida, usando o comando: \\ifconfig

eth0:1 192.168.100.x (onde x = endereço escolhido para o gateway padrão da 1a subrede)

\\ifconfig

eth0:2 192.168.100.x (onde x = endereço escolhido para o gateway padrão da 2a subrede)

\\ifconfig

eth0:3 192.168.100.x (onde x = endereço escolhido para o gateway padrão da 3a subrede) etc.

3. O arquivo /etc/sysctl.conf deve ser configurado com o parâmetro net/ipv4/ip_forward=1, e é necessário remover o comentário ou, no caso de não existir, inserir a seguinte linha de comando no final do arquivo net.ipv4.conf.default.forwarding = 1, para garantir que o Linux fará o encaminhamento de pacotes IP (IP forwarding) entre as interfaces de rede virtuais aqui definidas. O serviço inet.d deve ser reiniciado ou o servidor SSA deve ser reiniciado, para garantir que esta modificação esteja operacional. Garanta que a interface física (eth0) esteja up e funcionando corretamente. Reiniciar a máquina, se necessário. Não é preciso fazer login nesse caso. 4. Os alunos devem executar os procedimentos a seguir individualmente e na seqüência determinada. Observe que no teste de continuidade entre subredes o gateway padrão tem que estar ligado e carregado com o sistema Linux. O comando traceroute deve indicar o gateway padrão como HOP 1. Recomendar aos alunos que anotem os resultados de cada atividade.


36


Nota: deve aparecer apenas o gateway padrão.

Nota: devem aparecer todas as máquinas da subrede. Nota: todos os comandos devem funcionar corretamente. Se não, corrigir o problema.

\\Testar

a continuidade dentro da subrede

\\Comando

arp –a para verificar o cache ARP

\\Comando

ping para as demais máquinas da subrede

\\Comando

arp –a para verificar o cache ARP

\\Testar

a continuidade entre subredes

\\Comando


\\Comando


Após dar os comandos ping para as outras subredes, pode-se ver na tabela ARP (comando arp –a) que as máquinas das outras subredes não aparecem na tabela, uma vez que o gateway não propaga ARP broadcasting. Assim, o domínio de broadcasting fica restrito ao âmbito de cada subrede. Ao final desta atividade todas as máquinas devem retornar à configuração original.

Atividade 2 – Estudo de caso

Estudo de caso

Este estudo de caso deve ser resolvido em 15 minutos. Os alunos podem fazê-lo em duplas.

Planejamento de endereçamento IP Escritório central 4 redes departamentais/1 backbone corporativo Disponível 1 Classe C: 200.248.228.0/24 20-30 computadores/rede

Considerando a rede corporativa da figura ao lado:

Cada departamento tem uma rede com cerca de 20 a 30 computadores. Essas redes estão interligadas ao backbone corporativo composto por um switch Gigabit Ethernet que interliga todas as redes departamentais. Está disponível uma classe C 200.248.228.0/24, que se deseja dividir em subredes, de modo a acomodar as necessidades de endereçamento de todas as redes descritas acima. Não é permitido configurar subrede com 1 bit. Usando o conceito de VLSM, defina: \\Máscara

de subrede que será usada em cada uma das subredes;

\\Endereços

IP de cada subrede;

\\Endereços

IP das interfaces dos roteadores.


37

Atividade 3 – Estudo de caso

Estudo de caso (cont.)

Suponhamos agora que seja necessário acrescentar a esta rede do Escritório Central (site A) mais duas filiais (sites B e C), cada uma com cerca de 8 a 10 computadores.

Planejamento de endereçamento IP Mais duas filiais, com 8-10 computadores cada

Note que o site A continua como está, e o roteador router A será acrescentado ao backbone corporativo (via interface E0), respeitando o endereçamento previamente definido. Só dispomos da Classe C 200.248.228.0. Deve-se manter, tanto quanto possível, os endereços IP atribuídos à rede do Escritório Central, para evitar transtornos aos usuários. Não é permitido configurar subrede com 1 bit. Definir: \\Máscara

de subrede que será usada;

\\Endereços

IP de cada subrede (Subnet ID, Broadcast ID, Hosts ID);

\\Endereços

IP das interfaces dos roteadores.

Atividade 4 – Exercícios Esses exercícios podem ser realizados durante ou após o término desta sessão. 1. Considerando o endereço 192.168.10.42 numa rede que usa 4 bits para subrede, quais são os endereços de Subnet ID e Broadcast ID, respectivamente?

2. Qual é o endereço de broadcast do endereço 172.16.99.99, máscara de subrede 255.255.192.0?

3. Qual é a faixa de endereços IP válidos a qual pertence o endereço IP 172.16.10.22, máscara 255.255.255.240?


38

Escola Superior de Redes RNP 4. Considerando a rede abaixo, complete as tabelas de roteamento de cada roteador.

Roteador 2621A

Roteador 2501B

Destino

Int

Dist

Destino

Int

Dist

172.16.10.0

F0/0

0

172.16.10.0

S0

1

Roteador 2501A

Roteador 2501C

Destino

Int

Dist

Destino

Int

Dist

172.16.10.0

E0

0

172.16.10.0

S0

2


3 Sessão de aprendizagem 3 Configuração de rotas estáticas Sumário da sessão Tabela de rotas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Exemplo de tabela de rotas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Roteamento estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Roteamento dinâmico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Tela do simulador de redes IMUNES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Configuração das subredes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Comando ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Comando traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Monitoração de tráfego na rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Atividade 1 – Configuração dos equipamentos de subredes. . . . . . . . . . . . . . . . 50 Atividade 2 – Monitoração e captura de pacotes IP. . . . . . . . . . . . . . . . . . . . . . 56

40


Tabela de rotas

Tabela de rotas

Quando um pacote chega em uma das interfaces do roteador, ele analisa a sua tabela de roteamento para verificar se nela existe uma rota para a rede de destino. Pode ser uma rota direta ou a indicação do roteador para o qual o pacote deve ser enviado. Este processo continua até que o pacote seja entregue na rede de destino.

Tabela com as rotas conhecidas do roteador Formato padrão Identificação da rede de destino Máscara de subrede Gateway (next hop) Métrica Outras informações (depende do protocolo) As rotas podem ser aprendidas através de Administrador de rede Protocolos de roteamento

As informações da tabela de roteamento devem ser suficientes para que o roteador possa fazer isso. O formato padrão de uma entrada na tabela de roteamento é o seguinte:

Se a rede de destino não estiver na tabela, o datagrama será descartado sumariamente. Para montar essa tabela, o roteador pode “aprender” as rotas de duas maneiras: \\Administrador \\Protocolos

de rede

de roteamento

A primeira maneira é manual e a segunda é automática. Mais adiante veremos em que situações elas se aplicam melhor.

Exemplo de tabela de rotas Tabela de rotas do Windows C:\>route print =========================================================================== Lista de interfaces 0x1 ........................ MS TCP Loopback interface 0x2 ...00 60 67 01 d3 06 ... Acer ALN-330 10/100M PCI Fast Ethernet Adapter =========================================================================== =========================================================================== Rotas ativas: Endereço de rede Máscara Ender. gateway Interface Custo 0.0.0.0 0.0.0.0 189.6.12.1 189.6.12.158 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 189.6.12.0 255.255.252.0 189.6.12.158 189.6.12.158 1 189.6.12.158 255.255.255.255 127.0.0.1 127.0.0.1 1 189.6.255.255 255.255.255.255 189.6.12.158 189.6.12.158 1 224.0.0.0 224.0.0.0 189.6.12.158 189.6.12.158 1 255.255.255.255 255.255.255.255 189.6.12.158 189.6.12.158 1 Gateway padrão: 189.6.12.1 =========================================================================== Rotas persistentes: Nenhuma C:\>

Exemplo de tabela de rotas O comando route print do DOS lista a tabela de rotas atual aprendida pelo Windows. Na primeira parte temos a lista de interfaces de rede atualmente ativas: a loopback (teste interno) e, no caso, uma interface Ethernet. Depois vêm as rotas ativas. Seja, por exemplo, a primeira entrada: 0.0.0.0 0.0.0.0 189.6.12.158 1

189.6.12.1

Esta entrada é a chamada de rota padrão. Esta rota é indicada por uma identificação de rede 0.0.0.0 com uma máscara de subrede 0.0.0.0. Quando o TCP/IP tenta encontrar uma rota para um determinado destino, ele percorre todas as entradas da tabela de roteamento em busca de uma rota específica para a rede de destino. Caso não seja encontrada uma rota para a rede de destino, será utilizada a rota padrão. Em outras palavras, se não houver uma rota específica, mande através da rota padrão. Observe que a rota padrão é justamente o default Roteamento avançado – Sessão de aprendizagem 3

41

gateway da rede (189.6.12.1), ou seja, a interface de LAN do roteador da rede. O parâmetro Interface (189.6.12.158) é o número IP da placa de rede do próprio computador. Não havendo uma rota específica, deve-se mandar para a rota padrão, onde o próximo hop da rede deverá ser o 189.6.12.1, e o envio para este hop é feito através da interface 189.6.12.158 (ou seja, a própria placa de rede do computador). A próxima entrada define o endereço de loopback que, como já dissemos, é usado para a finalidade de testes internos. A terceira entrada define a rota para a rede 189.6.12.0/22: 189.6.12.0 255.255.252.0 189.6.12.158 189.6.12.158 1 Esta rota é conhecida como rota da rede local. Ela basicamente diz o seguinte: “Quando o endereço IP de destino for um endereço da minha rede local, envie as informações através da minha placa de rede” (observe que tanto o parâmetro gateway como o parâmetro Interface estão configurados com o número IP do próprio computador). Ou seja, “se for para uma das máquinas da minha rede local, mande através da placa de rede, não precisa enviar para o roteador”. As demais entradas não são relevantes para nosso estudo.

Roteamento estático Vantagens Sem overhead na CPU do roteador Roteadores não usam a largura de banda Segurança (administrador define as rotas) Desvantagens Exige maior conhecimento técnico Cada mudança de configuração deve ser feita em todos os roteadores da rede Inviável em grandes redes

Quando um roteador é configurado com os endereços IP de cada interface, ele só pode enviar pacotes IP para as redes às quais está diretamente conectado. Se ele receber um pacote destinado a uma rede remota que não está na tabela de roteamento, ele simplesmente descarta o pacote (não envia em nenhuma hipótese um broadcasting para localizar a rede remota). Para que o roteador seja capaz de enviar pacotes para redes remotas é necessário configurar as rotas. Podem ser usados os seguintes métodos:

Roteamento estático Nesse método o administrador da rede configura manualmente todas as rotas em cada roteador da rede. Em redes pequenas é até relativamente simples, como veremos em nosso exemplo mais adiante. Porém, em redes grandes, esse procedimento é inviável, por causa do tempo necessário para atualizar todas as tabelas em todos os roteadores da rede a cada mudança de topologia (seja por adição de novo hardware ou por falha de algum componente). Suas vantagens são principalmente simplicidade, segurança e menor overhead de CPU do roteador e de largura de banda da rede.

Configuração de rotas estáticas

42


Roteamento dinâmico

Roteamento dinâmico (1) Vantagens Configuração mais fácil que a da rota estática Atualizações dinâmicas pelos roteadores Usado em redes grandes Desvantagens Overhead na CPU do roteador Roteadores usam a largura de banda

Roteamento dinâmico (2) Para rotear pacotes, o roteador precisa conhecer: Endereço de destino Roteadores vizinhos dos quais possa aprender rotas para as redes remotas Rotas possíveis para todas as redes remotas A melhor rota para cada rede remota Como manter e verificar a informação das rotas

Este método é usado normalmente em grandes redes, porque permite que os próprios roteadores construam e atualizem suas tabelas de roteamento, através de protocolos de roteamento: IPX (só em redes Novell), RIP, IGRP, OSPF etc. É mais simples de configurar do que rotas estáticas, porém às custas da CPU dos roteadores e da largura de banda da rede. O roteador faz o roteamento do tráfego para todas as redes interconectadas. O roteador aprende as rotas para as redes remotas através dos roteadores vizinhos ou do administrador da rede. O roteador então constrói a tabela de roteamento que descreve a forma de achar as redes remotas. Se a rede estiver diretamente conectada a uma interface do roteador, então o roteador já sabe como chegar nela. Se as redes não estiverem diretamente conectadas, o roteador precisará aprender como chegar nelas, seja através de rotas estáticas configuradas pelo administrador ou através de rotas dinâmicas aprendidas dos roteadores vizinhos.

Roteamento dinâmico é o processo pelo qual protocolos de roteamento executados no roteador se comunicam com os roteadores vizinhos. Os roteadores trocam informações entre si a respeito de todas as redes para as quais eles conhecem as rotas. Se ocorrer uma mudança de topologia na rede, os protocolos de roteamento dinâmico automaticamente informam todos os roteadores a respeito da mudança. Se, por outro lado, forem usadas rotas estáticas, é responsabilidade do administrador de rede atualizar as rotas em todos os roteadores da rede.


43

Tela do simulador de redes IMUNES

Tela do simulador de redes IMUNES Na figura temos a tela de abertura do Simulador de Redes IMUNES (Integrated Multiprotocol Network Emulator / Simulator), desenvolvido pela Faculty of Electrical Engineering and Computing, da Universidade de Zagreb, na Croácia. A home page pode ser encontrada na URL: \\http://www.tel.fer.hr/imunes/

Mais informações podem ser obtidas em: \\http://www.tel.fer.hr/imunes/dl/imunes.pdf \\http://www.elo.utfsm.cl/~elo324/wp-content/

uploads/2006/03/manual_imunes.pdf Este simulador roda no ambiente FreeBSD-4.11-RELEASE e utiliza recursos do Kernel FreeBSD 4.11, não podendo rodar em nenhum outro ambiente. Tem dois modos de operação: Edit mode e Exec mode. A tela mostra o Edit mode, onde é possível construir uma topologia com elementos básicos mostrados no painel da esquerda, de cima para baixo, respectivamente: Link, Hub, Switch, Roteador, Servidor, PC, conector externo RJ-45 (para uma rede real). À medida que os elementos são criados na topologia, os nomes das interfaces e dos elementos são adicionados automaticamente. Para criar um elemento, basta selecioná-lo com a seta do painel esquerdo usando o mouse, e depois levar o mouse até o local onde se deseja inserir o elemento, e clicar (point and click). Pode-se inserir quantos elementos quiser. Depois basta ligá-los com o elemento link. O IMUNES gera automaticamente as características dos elementos e suas interfaces, bem como o tipo e velocidade dos links. Podese editá-los e personalizar a rede, conforme mostrado acima. Com um duplo clique do mouse em qualquer elemento (link ou equipamento), teremos uma janela com as características da configuração do referido elemento, onde se pode editar toda a configuração do mesmo. Uma vez terminada a edição, pode-se salvar a figura com a extensão .imn. Esta figura chama-se RedeTeste1.imn.


44


Configuração das subredes

Configuração das subredes .2

Nesta figura vemos a configuração das subredes:

.1 .1

\\1a.

Subrede: LAN10 172.16.10.0/24; router0:eth0 172.16.10.1; pc1_LAN10 172.16.10.10; pc2_LAN10 172.16.10.11

.2 .1

.1

.1 .10

.10

.11

\\2a.

.11

.10

.11

LAN30 172.16.30.0/24

LAN10 172.16.10.0/24

LAN50 172.16.50.0/24

Subrede: WAN20 172.16.20.0/24; router0:ser0 172.16.20.1; router1:ser0 172.16.20.2

\\3a.

Subrede: LAN30 172.16.30.0/24; router1:eth0 172.16.30.1; pc1_LAN30 172.16.30.10; pc2_LAN30 172.16.30.11

\\4a.

Subrede: WAN40 172.16.40.0/24; router1:ser1 172.16.40.1; router2:ser0 172.16.40.2

\\5a.

Subrede: LAN50 172.16.50.0/24; router2:eth0 172.16.50.1; pc1_ LAN50 172.16.50.10; pc2_LAN50 172.16.50.11

A configuração das subredes mostrada acima já está pronta. Os endereços IP de cada interface estão assinalados na figura. As subredes WAN20 e WAN40 servem apenas para interligação das LANs, e são enlaces seriais de longa distância, supondo que os roteadores estejam em localidades distantes entre si. O arquivo que descreve essa configuração para o software IMUNES tem o seguinte conteúdo: node n0 { type router cpu {{min 0} {max 100} {weight 1}} model quagga network-config { hostname router0 ! interface ser0 ip address 172.16.20.1/24 ! interface eth0 ip address 172.16.10.1/24 ! } canvas c0 iconcoords {192.0 168.0} labelcoords {192.0 144.0} interface-peer {eth0 n3} Roteamento avançado – Sessão de aprendizagem 3

45

interface-peer {ser0 n1} ... E assim por diante, para todos os nós da rede. Como é um arquivo texto, pode ser editado facilmente. Faça agora a atividade 1. Esta atividade deve ser executada em até 30 minutos. Conclusão Nesta atividade aprendemos a: \\Desenhar \\Projetar

uma rede com software de simulação IMUNES

o endereçamento das subredes

\\Configurar

os equipamentos das subredes

\\Configuração

básica de roteadores

Comando ping

Comando ping Verificação de conectividade Envia um pacote Echo Request para o destino O destino responde com um pacote Echo Reply É informado o Round Time Trip (RTT) – tempo de ida e volta

O comando ping serve para verificar a conectividade entre origem e destino, não importando se ambos estão na mesma rede ou não. É usado o protocolo Internet Control Message Protocol (ICMP) – RFC 792. Este protocolo utiliza o datagrama IP para enviar suas mensagens, que são basicamente de dois tipos: \\Solicitação

– Tempo, máscara, rotas ou eco;

\\Erro

– Destino inatingível (port, host ou rede), TTL = 0 em trânsito etc.

A origem envia um pacote Echo Request (mensagem ICMP tipo 8) e o destino responde com Echo Reply (mensagem ICMP tipo 0). A origem calcula o tempo total de ida e volta (RTT) e imprime uma linha com os resultados. Se o destino não existir, emitirá uma mensagem de erro ICMP.


46


Comando traceroute

Comando traceroute (1) Mostra o caminho do pacote até o destino Envia datagramas UDP para o destino; Inicia com TTL=1 e vai incrementando até o destino; Envia 3 datagramas para cada hop; Cada roteador (hop) no caminho subtrai 1 do TTL; Quando o TTL=0, o roteador envia uma mensagem de erro ICMP tipo 11, informando seu endereço IP; A origem calcula o RTT médio e imprime uma linha para cada hop que respondeu; O destino responde com mensagem ICMP tipo 3.

Este comando se baseia no fato de que quando o campo TTL (Time To Live – Tempo de Vida) do datagrama IP atinge zero, o roteador não pode rotear o datagrama, mas tem que obrigatoriamente descartá-lo e enviar uma mensagem ICMP de erro tipo 11, informando seu endereço IP. Esta mensagem é de “tempo expirado em trânsito” (TTL = 0). É assim que a origem fica sabendo o caminho que o datagrama está percorrendo.

O datagrama UDP carrega um número de port improvável para o destino, de modo que, quando ele finalmente chega lá, o destino responde com uma mensagem de erro de port inatingível (ICMP tipo 3), não de tempo expirado em trânsito (TTL = 0). É assim que a origem fica sabendo que o destino foi atingido. A figura acima mostra o mecanismo do comando traceroute na nossa rede de teste. Na figura está representado apenas um datagrama para cada hop, mas a aplicação envia 3 datagramas idênticos para cada hop.

Comando traceroute (2)

Os 3 primeiros datagramas têm TTL=1 e são descartados pelo primeiro hop (router0), porque este subtrai 1 do TTL (1-1=0), com uma mensagem de erro ICMP tipo 11, “tempo expirado em trânsito” (TTL=0). Os 3 seguintes têm TTL=2 e passam pelo primeiro hop (subtrai 1 do TTL: 2-1=1) e são descartados pelo segundo hop (router1), também com a mesma mensagem de erro. Os 3 seguintes têm TTL=3 e passam pelo primeiro hop (subtrai 1 do TTL: 3-1=2), passam pelo segundo hop (subtrai 1 do TTL: 2-1=1) e são descartados pelo terceiro hop (router2), também com a mesma mensagem de erro.


47

Finalmente, os 3 últimos passam por todos os hops porque têm TTL=4 e chegam no destino ainda com TTL=1. Porém, o port UDP de destino não existe no host de destino, daí o host de destino gera uma mensagem de erro ICMP tipo 3.

Monitoração de tráfego na rede TCPDUMP Opera no modo texto (CLI) em ambientes Unix e Windows Captura pacotes IP na interface de rede Pode ser obtido no URL: http://www.winpcap.org/windump/default.htm

Ethereal Opera no modo gráfico (GUI) em ambientes Unix e Windows Captura pacotes IP na interface de rede Pode ser obtido no URL: www.ethereal.com

Monitoração de tráfego na rede O utilitário TCPDUMP foi extensivamente utilizado por W. Richard Stevens no livro TCP/IP Illustrated, Vol. 1 – The Protocols. Aliás, a razão do livro se chamar TCP/IP Ilustrado é justamente pelo uso do TCPDUMP, para mostrar em detalhes o que está acontecendo na rede. Ambos permitem a captura e visualização de pacotes IP que trafegam por uma determinada interface de rede e permitem gravar os pacotes num arquivo para análise posterior.

No processo de captura podem ser usados filtros de captura com uma sintaxe sofisticada e muito flexível. Ambos utilizam a mesma sintaxe. No entanto, no processo de visualização e análise o Ethereal oferece mais recursos, justamente por operar em modo gráfico. O Ethereal permite filtros de visualização com uma sintaxe própria poderosa, embora bastante simples de usar. Ambos podem ser usados em conjunto com o IMUNES; veremos como na próxima atividade.

Faça agora a atividade 2. Esta atividade deve ser executada em até 30 minutos. Conclusão Nesta atividade aprendemos a


\\Monitorar

o tráfego na rede usando os programas Ethereal e TCPDUMP

\\Monitorar

o comando ping

\\Monitorar

o comando traceroute



48

3 Sessão de aprendizagem 3 Configuração de rotas estáticas Roteiro de atividades Tópicos e conceitos \\Tabela

de rotas

\\Roteamento \\Principais

estático e dinâmico

comandos de configuração de rotas

Competências técnicas desenvolvidas \\Desenhar \\Projetar

uma rede com software de simulação IMUNES

o endereçamento das subredes

\\Configurar

os equipamentos das subredes

\\Configuração

básica de roteadores


minutos


50


Atividade 1 – Configuração dos equipamentos de subredes 1. Dar boot no Windows, iniciar o VMware Player, maximizar a janela do VMware Player e só então iniciar a máquina virtual Imunes. Se a janela não for maximizada, não será possível visualizar a barra de ferramentas na parte inferior da tela. 2. Após iniciar o programa IMUNES, carregar o arquivo de topologia RedeTeste1.imn, selecionar no menu a opção Experiment/Execute para entrar no modo de execução. Apontar para o router0, apertar o botão direito do mouse (manter apertado) e selecionar a opção shell window/ vtysh. Teremos então a tela que simula o console do roteador router0. 3. O prompt inicial é router0>, que indica que estamos no modo user. Digite enable. Assim, teremos o prompt router0#, que indica que estamos no modo privilegiado (padrão Cisco IOS). Neste modo podemos ver as configurações do roteador. O comando sh ip route mostra as rotas que o router0 conhece neste momento. Como podemos observar na figura, o router0 conhece somente as redes as quais está diretamente conectado (C>*). 4. Para configurar as rotas estáticas para as demais redes, precisamos entrar no modo de configuração global, digitando o comando: \\config

t (forma abreviada de configure terminal).

O prompt muda, mostrando que estamos no modo de configuração global. O formato do comando de adicionar rotas é: ip route , onde: \\

é a identificação da rede (network ID), no caso 172.16.30.0; 172.16.40.0; 172.16.50.0;

\\
subrede> é a máscara da subrede no formato /número de bits de rede (/24 equivale a 255.255.255.0);

\\
hop> é o próximo hop, no caso o endereço IP da interface do roteador seguinte (172.16.20.2);

Após digitar esses comandos, tecle Ctrl-z para encerrar a configuração. Volta o prompt do modo privilegiado.


51

5. Digitando agora o comando sh ip route veremos as rotas aprendidas pelo router0. A figura a seguir ilustra esse processo. Atenção para um detalhe de configuração do IMUNES. No modo de edição (Edit mode) podemos salvar as mudanças de configuração num arquivo com extensão .imn. No modo de execução (Exec mode) não é possível salvar a configuração feita. Não existe, como no caso dos roteadores Cisco, os comandos copy run star ou write mem. Após encerrar o IMUNES ou dar reboot no Unix, as configurações realizadas no Exec mode serão perdidas.

Precisamos agora configurar os demais roteadores.

6. Fazer para o router1 o mesmo processo feito para o router0. Após o comando sh ip route vemos as redes diretamente conectadas ao roteador router1. Precisamos configurar as rotas para as demais redes, no caso as redes 172.16.10.0; 172.16.50.0. Após digitar os comandos necessários, tecle Ctrl-z para encerrar a configuração. Volta o prompt do modo privilegiado. Digitando agora o comando sh ip route veremos as rotas aprendidas pelo router1.



52

A figura a seguir ilustra esse processo:

7. Fazer para o router2 o mesmo processo feito nos outros roteadores. Após o comando sh ip route vemos as redes diretamente conectadas ao roteador router2. Precisamos configurar as rotas para as demais redes, no caso as redes 172.16.10.0; 172.16.20.0; 172.16.30.0. Após digitar os comandos necessários, tecle Ctrl-z para encerrar a configuração. Volta o prompt do modo privilegiado. Digitando agora o comando sh ip route veremos as rotas aprendidas pelo router2.


53

A figura ilustra esse processo. Precisamos agora configurar o gateway padrão dos micros PC.

8. As figuras a seguir representam os consoles dos diversos PCs: pc1, pc2,... pc6.

Para abrir o console de um PC qualquer, siga os procedimentos: \\Apontar

para o pc1 (por exemplo);

\\Apertar

o botão direito do mouse (manter apertado);

\\Selecionar

a opção shell window/bin/sh.

Teremos então a tela que simula o console do pc1. Note que esses consoles são reais do ponto de vista do Kernel do FreeBSD, uma vez que estão utilizando todos os recursos do Kernel. É possível emitir todos os comandos shell aceitos pelo Kernel.


54


9. Para adicionar a rota padrão e definir o gateway padrão no PC, o formato do comando é: route add , onde: \\

0.0.0.0 (rota padrão)

\\
de subrede> /0

172.16.10.1 (pc1 e pc2); 172.16.30.1 (pc3 e pc4); 172.16.50.1 (pc5 e pc6)

\\

Teremos a confirmação de que foi adicionada a rede padrão e o endereço do gateway, conforme mostrado nas figuras dos consoles dos PCs. Neste ponto, a configuração das rotas estáticas está pronta. Para verificar, podemos usar dois comandos básicos: ping e traceroute. 10. Para verificar, podemos usar dois comandos básicos: ping e traceroute. No console do pc1, digitamos o comando: ping –c4 172.16.50.10 (este é o endereço do pc5). Para atingir o pc5, a rota passa por todos os roteadores na ida e na volta. Vemos que o comando foi bem-sucedido na figura a seguir.


55

11. No console do pc6, digitamos o comando ping –c4 172.16.10.11 (este é o endereço do pc2). Vemos que o comando foi bem-sucedido na figura a seguir.

12. Vamos verificar agora o caminho que os pacotes estão percorrendo (rota) No console do pc1 digitamos o comando traceroute 172.16.50.10, que traça a rota desde a origem até o destino (pc5). Ainda temos na mesma figura o resultado do comando traceroute 172.16.30.10, que traça a rota até o destino (pc3).

Procedimentos idênticos aparecem na próxima figura, desta vez no console do pc6.



56

Observe que o endereço das interfaces dos roteadores é sempre o da interface de entrada do pacote, e não o da interface de saída. Mais adiante veremos o porquê disto, quando monitorarmos o tráfego da rede.

Atividade 2 – Monitoração e captura de pacotes IP 1. Para iniciar o Ethereal, aponte para o pc1, mantenha apertado o botão direito do mouse e selecione a opção ethereal/eth0. Teremos então a tela principal do Ethereal, mostrada a seguir. No início os campos de dados estão vazios. A tela mostra os pacotes capturados pelo Ethereal na interface eth0 do pc1, após a execução do comando ping.

2. Para iniciar uma captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture) e clique nele. Surgirá uma tela onde é mostrado o número total de pacotes por protocolo, à medida que são capturados na interface eth0. 3. Inicie outra janela de console no pc1 e nela execute o comando ping conforme mostrado anteriormente (destino: pc5). Após a execução completa do comando (4 pacotes), vá na tela de total de pacotes e clique em stop. Isto encerra a captura e mostra automaticamente a tela acima com todos os pacotes capturados.


57

4. Observe que os dois primeiros pacotes se destinam a descobrir o endereço MAC do gateway padrão (no caso 40:00:aa:aa:00:00). O primeiro é um broadcast ARP solicitando o endereço MAC do equipamento que tiver o endereço IP 172.16.10.1 (gateway padrão), pedindo que responda à origem que, no caso, é o pc1 (endereço IP 172.16.10.10). O segundo pacote é a resposta do gateway padrão informando seu endereço MAC. Isto ocorre, conforme explicado anteriormente, porque o endereço IP de destino (172.16.50.10) NÃO pertence à rede do pc1 (172.16.10.0). Então o pc1 precisa enviar o pacote para o gateway padrão, e para isso precisa descobrir o endereço MAC dele antes de enviar o pacote. Sabendo o endereço MAC do gateway padrão, são enviados os pacotes de Echo request, que são respondidos com o correspondente Echo reply. 5. Na figura está selecionado o pacote 3 no quadro de pacotes. No quadro seguinte são mostradas as camadas de protocolos que estão representadas no pacote. Observe que temos a camada física [frame 3 (98 bytes on wire, ...)], a camada de enlace de dados (Ethernet II, Src: ...), a camada de rede (Internet Protocol, Src Addr:...) e finalmente os dados do protocolo ICMP inseridos no pacote IP. No último quadro temos o detalhamento dos bytes em hexadecimal. Podemos selecionar as diversas camadas no segundo quadro e detalhar os campos de cada camada. Automaticamente os bytes correspondentes serão destacados no último quadro. Note que o programa Ethereal está sendo realmente executado no console do pc1, como se estivéssemos usando o PC real. Desta forma podemos executar qualquer programa instalado no Kernel do FreeBSD. Para iniciar outra captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture...) e clique nele. 6. Para iniciar outra captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture...) e clique nele. Este arquivo de captura do comando ping está gravado com o nome: Captura_Ping_Ethereal, no formato libpcap.


O Ethereal pergunta o que fazer com o arquivo de captura corrente. É possível escolher descartá-lo ou gravá-lo para análise posterior. Quando o programa Ethereal é encerrado, sempre pergunta se queremos salvar o arquivo de captura de pacotes.

58


7. Para monitorarmos o comando usaremos, desta vez, o programa tcpdump. Para isso, abrir uma nova console no pc1 conforme mostrado anteriormente e digitar o comando: tcpdump -w Captura_Traceroute_Tcpdump A opção –w indica ao tcpdump que queremos gravar o arquivo de captura com o nome que vier a seguir. O arquivo será gravado no diretório corrente (provavelmente /root). Não estamos usando o programa Ethereal para capturar os pacotes do traceroute por dois motivos:

Deve aparecer a mensagem: \\tcpdump:

listening on eth0

8. Iniciar outra janela de console no pc1 e nela executar o comando traceroute conforme mostrado anteriormente (destino: pc5). Após a execução completa do comando, vá ao console onde foi iniciado o tcpdump e digite Ctrl-C. Isto encerra a captura e mostra a quantidade de pacotes recebidos e excluídos. Abrir o Ethereal no arquivo de saída do tcpdump. Deveremos visualizar a tela a seguir:

1. queremos mostrar o programa tcpdump; 2. dependendo da velocidade da CPU do PC que está sendo usado, o Ethereal perde pacotes, não conseguindo capturar todos os pacotes mostrados nas figuras a seguir. Para mostrar os pacotes usaremos o Ethereal, aproveitando a sua interface gráfica.

9. Na figura destacamos o primeiro datagrama UDP e os campos do cabeçalho do pacote IP, mostrando que TTL = 1. O segundo datagrama mostra que o gateway padrão (endereço IP 172.16.10.1) respondeu com uma mensagem de erro ICMP informando que o “Time-to-live exceeded” (TTL = 0). Os datagramas de 3 a 6 repetem o mesmo procedimento. O datagrama 7 tem o TTL = 2 e, portanto, passa pelo primeiro hop e é descartado pelo segundo hop. No datagrama 8, note o endereço IP 172.16.20.2 de resposta informando o erro ICMP.


59

Note que são as interfaces de entrada dos hops que respondem com a mensagem de erro, porque esta é endereçada para a origem do datagrama UDP. As interfaces de saída dos hops só encaminham os datagramas que não dão erro (TTL>0). E assim por diante, até atingir o destino. 10. A figura a seguir mostra o último datagrama UDP (de número 23) em detalhe, onde podemos ver que o TTL = 4. Note que os 3 últimos datagramas UDP (19, 21 e 23) têm TTL = 4, passaram por todos os roteadores e foram descartados pelo host de destino que enviou a mensagem de erro ICMP correspondente.


Escola Superior de Redes RNP 11. A figura a seguir mostra o último datagrama ICMP (de número 24) respondido pelo host de destino em detalhe, onde podemos ver que o erro ICMP é do tipo 3 (Destination unreachable) e código 3 (Port unreachable). Note que no datagrama UDP o port de destino é o de número 33446, que o host de destino recusa.


60

4 Sessão de aprendizagem 4 Protocolo de roteamento RIP Sumário da sessão Conceito de Sistema Autônomo – AS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Classless Interdomain Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Classificação de protocolos de roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Roteamento dinâmico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Algoritmo de roteamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Tabela de roteamento Vetor-Distância. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 RIPv2 – Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Contagem ao infinito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Implementações especiais do RIPv2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Pacote RIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Atividade 1 – Configuração do protocolo RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Atividade 2 – Atualização de rotas RIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

62


Conceito de Sistema Autônomo – AS Sistema autônomo (Autonomous system) Um grupo de redes e roteadores controlados por uma única autoridade administrativa.

Segundo RFC 1930 (definição formal) Um conjunto de roteadores controlados por uma única administração técnica, usando um protocolo interior e métricas comuns para rotear pacotes dentro do AS, e usando um protocolo exterior para rotear pacotes para os outros ASs. Requisito básico: política de roteamento única. A política de roteamento define como são tomadas as decisões de roteamento na internet.

Conceito de Sistema Autônomo – AS Uma definição comumente adotada diz apenas que o AS está sujeito a uma administração única. Uma definição mais rigorosa acrescenta que deve haver uma política de roteamento única no AS. Este é o requisito básico para se ter um AS. Por política de roteamento entendemos a maneira como as decisões de roteamento são tomadas na internet.

Está claro na definição formal que as decisões de roteamento internas ao AS são tão importantes quanto as decisões externas, ou seja, a maneira como o AS se comunica com os outros ASs.

Classless Interdomain Routing (CIDR) Prefixo IP (Prefix) ou “bloco CIDR” Bloco de redes Classes A, B ou C Identificação das redes inicia e termina em múltiplos de 2 O bloco é identificado por um prefixo e uma máscara Exemplo: 192.168.0.0/24

192.168.1.0/24 192.168.2.0/24 192.168.3.0/24

192.168.0.0/22

Um AS é um grupo conectado de um ou mais prefixos IP controlados por operadores de redes, que têm uma política de roteamento única e bem definida.

Classless Interdomain Routing Segundo o RFC 1930, a definição clássica de AS é um tanto ambígua, porque não define corretamente o comportamento de um AS. O conceito de AS está intimamente relacionado ao conceito de CIDR visto anteriormente. Um “bloco CIDR” é um conjunto de redes classful (Classes A, B ou C) cujos números são seqüenciais e iniciam e terminam em múltiplos de 2, conforme o exemplo no slide.

Assim, um AS pode ser definido em função dos prefixos que o compõem. \\O

RFC 1930 enfatiza a importância de uma política de roteamento única, relaciona os erros mais comuns na definição de ASs e também discute os critérios de decisão para definir a necessidade de um AS.

\\O

AS é identificado por um número inteiro de 2 octetos; portanto, é um número na faixa de 1 a 65535. Na época da emissão do RFC 1930 existiam 5.100 ASs autorizados, porém menos de 600 eram ativamente roteados na internet global.

\\Os

ASs são controlados pelo Internet Assigned Numbers Authority – IANA (http://www.iana.org).

Para registrar um AS veja: \\http://www.iana.org/numbers.html


63

Classificação de protocolos de roteamento

Classificação de protocolos de roteamento

Os roteadores na internet são organizados hierarquicamente. Alguns roteadores são usados para enviar informação através de um grupo Exemplos: RIP – RFC2453, OSPF – RFC2328 particular de redes sob uma mesma autoridade Exteriores (Exterior Gateway Protocol – EGP) – administrativa e de controle (AS). Roteadores usados Usados para comunicação entre roteadores de ASs para troca de informação no interior dos ASs são diferentes Exemplos: EGP (obsoleto), BGP-4 – RFC4271 chamados roteadores interiores (interior routers) e Listagem de RFCs usam uma variedade de protocolos chamada Interior http://www.rfc-editor.org/rfc-index2.html Gateway Protocols (IGPs). Roteadores usados para troca de informação entre os ASs são chamados roteadores exteriores (exterior routers) e usam protocolos chamados Exterior Gateway Protocols (EGPs). Protocolos de roteamento podem ser: Interiores (Interior Gateway Protocol – IGP) – Usados para comunicação entre roteadores de um mesmo AS

Os principais protocolos padronizados usados atualmente são RIP, OSPF e BGP-4. Existem outros protocolos proprietários de fabricantes, como por exemplo o IGRP e o EIGRP da Cisco. É recomendável usar sempre que possível protocolos padronizados. Os padrões podem ser encontrados na listagem de RFCs disponível em: \\http://www.rfc-editor.org/rfc-index2.html

Roteamento dinâmico

Roteamento dinâmico Métrica dos protocolos de roteamento Contador de hops Bandwidth (largura de banda) Delay (retardo) Custo Confiabilidade Carga MTU Ticks

Roteadores usam um protocolo em comum para trocar informações de roteamento. Atualizações de informações de roteamento são mandadas quando a topologia da rede muda ou em intervalos fixos. As informações de roteamento atualizadas contêm as redes acessíveis acrescidas de um valor de métrica associado a cada caminho possível.

O melhor caminho entre redes ou subredes é determinado por uma métrica de roteamento. As métricas são importantes porque, além de determinarem uma rota para o destino, os roteadores têm que determinar a melhor rota para cada destino. Na figura acima, por exemplo, no caminho de A para B é evidente que a rota que passa por R1 é mais rápida que a rota que passa por R2. Assim, o roteador R0 deve usar essa informação para escolher a melhor rota. Variáveis usadas para métricas incluem o seguinte: \\Contador

de hops (saltos) – O número de paradas intermediárias que um pacote faz em um caminho para seu destino. Passando através de um roteador/gateway conta-se um hop.

Protocolo de roteamento RIP

64

Escola Superior de Redes RNP \\Largura

de banda (Bandwidth) – A capacidade de transportar dados de um meio. Usualmente medido em Mbps ou alguma fração dessa medida.

\\Atraso

(delay) – A quantidade de tempo associado com o uso de um meio em particular. Usualmente medido em ms (10-3 seg).

\\Confiabilidade

– Um valor associado a cada meio, indicando a probabilidade dos dados serem entregues. Usualmente expresso como um valor fracionário; algum número dividido por 255.

\\Carga

– Um valor dinâmico indicando a utilização de um meio. Usualmente expresso como um valor fracionário; algum número dividido por 255.

\\MTU

– Unidade máxima de transmissão. O maior tamanho do pacote para um meio em particular.

\\Custo

– Um valor arbitrário indicando o custo para usar essa interface. Usualmente expressa como um valor inteiro; definido para uma interface de saída.

\\Ticks

– Um valor arbitrário associado com um delay quando do uso dos links e interfaces. O valor usualmente adotado é 1/18 de segundo.

Algoritmo de roteamento

Algoritmo de roteamento Vetor-Distância (Bellman-Ford) Cada roteador mantém uma lista de rotas conhecidas Cada roteador divulga sua tabela para seus vizinhos Cada roteador seleciona os melhores caminhos dentre as rotas conhecidas e divulgadas A escolha do melhor caminho é baseada na métrica Normal: menor caminho, melhor rota Processo de montagem da tabela de rotas Vide anotações

Processo de montagem da tabela de rotas: 1. Quando o roteador executa o boot, ele armazena na tabela informações sobre cada uma das redes que estão diretamente conectadas a ele. Cada entrada na tabela indica uma rede de destino, o gateway para a rede e a sua métrica. 2. Periodicamente cada roteador envia uma cópia da sua tabela para qualquer outro roteador que seja diretamente alcançável (seus vizinhos).

3. Cada roteador que recebe uma cópia da tabela verifica as rotas divulgadas e suas métricas. O roteador soma à métrica divulgada o custo do enlace entre ele e o roteador que fez a divulgação. Depois, compara cada uma das entradas da tabela divulgada com as entradas da sua tabela de roteamento. Rotas novas são adicionadas, rotas existentes são selecionadas pela sua métrica. 3.1. Se a rota já existe na tabela e a métrica calculada é menor do que a da rota conhecida, então remove a entrada anterior e adiciona a nova rota divulgada; 3.2. Se a rota já existe na tabela e a métrica calculada é igual a da rota conhecida, então não altera a entrada, desprezando a rota divulgada; 3.3. Se a rota já existe na tabela e a métrica divulgada é maior do que a da rota conhecida, então verifica se o gateway para esta rota é o mesmo que está fazendo a nova divulgação: Roteamento avançado – Sessão de aprendizagem 4

65

3.3.1. Se o gateway é o mesmo, altera a métrica para esta rota; 3.3.2. Se o gateway não é o mesmo, não altera a rota conhecida, desprezando a rota anunciada.

Tabela de roteamento Vetor-Distância

Tabela de roteamento Vetor-Distância (1) Tabelas de rotas na inicialização router0 Destino Next Hop Métrica Rede 10 1 Rede 20 1

router1 Destino Next Hop Métrica Rede 20 1 Rede 30 1 Rede 40 1

router2 Destino Next Hop Métrica Rede 40 1 Rede 50 1

Considere a rede exemplo acima com 3 roteadores e 5 subredes. Todas as subredes são /24. O mecanismo de cálculo da tabela de rotas através do algoritmo Vetor-Distância (Bellman-Ford) funciona conforme explicado a seguir. \\Na

inicialização, antes de trocar informações com seus vizinhos, cada roteador só conhece as redes às quais está diretamente conectado.

\\Então

as respectivas tabelas, mostradas na figura, só têm as seguintes redes diretamente conectadas: \\router0

– redes 10 e 20;

\\router1

– redes 20, 30 e 40;

\\router2

– redes 40 e 50.

\\Todas

as redes têm métrica =1, porque não há nenhum roteador entre as redes e os respectivos roteadores.

Segundo a recomendação do RFC 2453, usualmente adota-se a métrica =1 nesse caso, embora não haja nenhum hop intermediário para redes diretamente conectadas. Teoricamente a métrica seria zero para redes diretamente conectadas.

Tabela de roteamento Vetor-Distância (2) Tabelas após o primeiro anúncio de rotas Destino Rede 10 Rede 20 Rede 30 Rede 40

router0 Next Hop Métrica 1 1 router1 2 router1 2

Destino Rede 20 Rede 30 Rede 40 Rede 10 Rede 50

router1 Next Hop Métrica 1 1 1 router0 2 router2 2

Destino Rede 40 Rede 50 Rede 20 Rede 30

As tabelas vistas na figura anterior serão anunciadas pelos roteadores a seus vizinhos, da seguinte forma: \\router0

router2 Next Hop Métrica 1 1 router1 2 router1 2

informa ao router1 que tem acesso às redes 10 e 20;

\\router1

informa ao router0 e ao router2 que tem acesso às redes 20, 30 e 40;

\\router2

informa ao router1 que tem acesso às redes 40 e 50.

Vejamos agora o que cada roteador faz com essas informações: \\router0

recebe as informações do router1 e ignora a rota da rede 20, porque ele já a tem na tabela com métrica = 1; as rotas para as redes 30 e 40 são


66


acrescentadas na tabela com métrica = 2, porque elas passam pelo router1, que informou essas rotas com métrica = 1; \\router1

recebe as informações do router0 e do router2; quanto ao router0, ele ignora a rota da rede 20, mas atualiza a rota da rede 10, com métrica = 2, que passa pelo router0; quanto ao router2, ele ignora a rota da rede 40, mas atualiza a rota da rede 50, com métrica = 2, que passa pelo router2;

\\router2

recebe as informações do router1 e ignora a rota da rede 40, porque ele já a tem na tabela com métrica = 1; as rotas para as redes 20 e 30 são acrescentadas na tabela com métrica = 2, porque elas passam pelo router1, que informou essas rotas com métrica = 1.

Nesse ponto, a tabela do router1 está completa, mas as tabelas dos roteadores router0 e router2 ainda não estão. No router0 falta a rota para a rede 50 e no router2 falta a rota para a rede 10.

Tabela de roteamento Vetor-Distância (3) Tabelas após o segundo anúncio de rotas Destino Rede 10 Rede 20 Rede 30 Rede 40 Rede 50

router0 Next Hop Métrica 1 1 router1 2 router1 2 router1 3

router1 Destino Next Hop Métrica Rede 20 1 Rede 30 1 Rede 40 1 Rede 10 router0 2 Rede 50 router2 2

router2 Destino Next Hop Métrica Rede 40 1 Rede 50 1 Rede 20 router1 2 Rede 30 router1 2 Rede 10 router1 3

Finalmente, os roteadores router0 e router2 receberão do router1 as informações de rotas que faltavam. \\O

router1 vai ignorar as informações de rotas dos outros dois roteadores, porque a tabela dele está completa.

\\router0

atualiza a rota para a rede 50 com métrica = 3, porque o router1 informou que sua métrica era 2 e essa rota passa pelo router1;

\\router2

atualiza a rota para a rede 10 com métrica = 3, porque o router1 informou que sua métrica era 2 e essa rota passa pelo router1.

Fim de atualização. Finalmente as tabelas estão completas. Dizemos que o protocolo convergiu. O tempo de convergência vai depender do tempo de cada atualização.

RIPv2 – Características (1) Distribuído em 1982 junto com BSD Unix (v1) RFC 2453 (standard 56) (v2) Protocolo interior (IGP) Algoritmo Vetor-Distância (contagem de hops) Limite de hops: 15 (16 = destino inalcançável) Administrador pode definir métricas das rotas Cada roteador divulga sua tabela a cada 30 segundos Tempo máximo para atualização da rota: 180 segundos A divulgação é por multicast para os vizinhos


RIPv2 – Características O protocolo RIP foi projetado inicialmente para a arquitetura Xerox Network Systems (XNS). Em 1982 a versão RIP-IP (v1) foi distribuída junto com o BSD Unix, formalmente definida pelo RFC 1058 de 1988. A versão atual (v2) foi definida pelo RFC 2453. A tabela de roteamento do RIP fornece várias informações sobre as rotas, tais como: métrica, máscara de subrede, temporizadores etc. A métrica usada indica o número de hops até o destino, por default. Em algumas implementações de RIP o

67

administrador pode definir uma métrica diferente de 1, para um determinado enlace. O RIP mantém apenas a melhor rota para cada destino, sem rotas alternativas. Quando chega nova informação sobre rotas, a antiga é desprezada. Cada roteador, ao perceber modificações nos seus enlaces, manda informação de atualização de rotas para os outros roteadores e assim por diante, propagando as mudanças ao longo da rede. Na versão 1 (RIPv1) essa atualização era feita através de mensagens broadcast. Na versão 2 são usadas mensagens multicast com endereço multicast padrão: 224.0.0.9. Como outros protocolos de roteamento, o RIP usa certos temporizadores (timers) para regular sua performance. Cada roteador enviará uma cópia completa de sua tabela de rotas a seus vizinhos a cada 30 segundos, através de uma mensagem de resposta não solicitada. Há mais dois temporizadores associados a cada rota: timeout (tempo expirado) e garbage collection (coleta de lixo). O timeout, normalmente configurado para 180 segundos, determina quanto tempo precisa decorrer sem que um roteador receba qualquer informação sobre uma rota antes que a rota seja declarada inválida. A rota também pode ser declarada inválida se tem métrica = 16. Quando uma rota é declarada inválida, ela permanece na tabela para que os vizinhos possam ser notificados do fato. Esta notificação tem que ocorrer antes do término do temporizador garbage-collection, normalmente configurado para 120 segundos. Quando este temporizador expira, a rota é removida da tabela. \\Mais

informações: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rip.pdf

RIPv2 – Características (2) Vantagens Simples de configurar Funciona bem em redes pequenas Baixo consumo de largura de banda Desvantagens Limitado a 15 hops, sendo inviável em redes grandes Não suporta rotas alternativas Problemas de estabilidade Tempo de convergência alto Loops

Com o advento dos protocolos OSPF e IS-IS, parecia que o protocolo RIP se tornaria obsoleto. Embora os novos protocolos sejam superiores ao RIP, este ainda tem algumas vantagens interessantes. Considerando as pequenas redes, o overhead do RIP é muito pequeno, tanto em termos do uso de largura de banda, como em termos de simplicidade de configuração e implementação. Além disso, existem muito mais implementações de RIP nas redes atuais do que nos outros dois protocolos combinados.

Como desvantagens, podemos citar o fato de que ele é limitado a 15 hops, tornando-o inviável em redes grandes. Por outro lado, com grande número de roteadores, teremos muitas mensagens de anúncio de rotas. Também não suporta rotas alternativas, mantendo apenas a melhor rota Protocolo de roteamento RIP

68


para cada destino na tabela. Essas limitações são, na realidade, conseqüências da concepção do protocolo. Ainda como conseqüência da concepção do RIP, existem problemas de estabilidade e convergência de tabelas de rotas. A convergência das tabelas dos diversos roteadores é lenta, devido ao tempo de atualização. Definimos tempo de convergência como o tempo necessário para que todas as tabelas dos roteadores fiquem atualizadas, quando há mudança de topologia. Quanto aos problemas de estabilidade, podemos citar a contagem ao infinito. Veremos que esse problema pode ser minimizado com as técnicas de horizonte dividido, horizonte dividido com inversão envenenada e atualizações imediatas.

Contagem ao infinito

Contagem ao infinito Tabela rotas router0 Tabela rotas router1 Destino Next Hop Métrica Destino Next Hop Métrica Rede 10 router0 2 Rede 10 1 Rede 20 1 Rede 20 1 Rede 30 1 Rede 30 router1 2 Suponha que a rede 10 esteja fora (caiu o link) router0 anuncia que a rota tem métrica 3 (via router1) router1 atualiza a métrica para 4 (3+1) (via router0) router0 atualiza a métrica para 5 (4+1) (via router1) E assim por diante, até atingir a métrica 16

O problema da “contagem ao infinito” (count to infinity) pode ser demonstrado na figura acima. \\O

router0 está diretamente conectado às redes 10 e 20, e o router1 às redes 20 e 30. Cada um anuncia sua tabela para o outro.

\\Quando

o router0 recebe a tabela do router1, ele atualiza sua tabela incluindo a rede 30, com métrica = 2 via router1.

\\Quando

o router1 recebe a tabela do router0, ele atualiza sua tabela incluindo a rede 10, com métrica = 2 via router0.

As tabelas ficam como estão na figura. Imagine agora que o link do router0 para a rede 10 caiu (representado pelo X). O router0 verifica que o router1 anuncia que tem rota para a rede 10 com métrica = 2. O router0 então atualiza sua tabela para a rede 10 com métrica = 3, via router1. O que o router0 não percebe (e aí está o problema) é que a rota anunciada pelo router1 passa por ele mesmo (router0), deixando de ser uma rota válida. O router1 por sua vez atualiza sua tabela colocando métrica = 4 para a rede 10. O router0, baseado na informação do router1, atualiza a sua tabela para métrica = 5 e assim por diante, até atingir a métrica = 16, que significa “rede inatingível”. Considerando que as atualizações são feitas a cada 30 segundos, vai demorar muito para as tabelas convergirem. Algumas implementações foram feitas no RIPv2 para resolver ou contornar esse problema.


69

Implementações especiais do RIPv2 Solução do problema de contagem ao infinito Horizonte dividido (split horizon) Não retorna informações de uma rota ao roteador do qual aprendeu essa rota

Horizonte dividido com inversão envenenada (split horizon with poison reverse) Retorna informação de uma rota com métrica = 16 para o roteador que aprendeu essa rota

Atualizações imediatas (triggered updates) Informa imediatamente modificações de rota, sem aguardar o próximo período de anúncio

Implementações especiais do RIPv2 \\Split

horizon (horizonte dividido): Com esta técnica, o roteador registra a interface através da qual recebeu informações sobre uma rota, e não difunde informações sobre esta rota, através desta mesma interface. No nosso exemplo, o router1 receberia informações sobre a rota para a rede 10, a partir do router0, logo o router1 não iria enviar informações sobre rotas para a rede 10, de volta para o router0. Com isso já seria evitado o problema do count to infinity. Em outras palavras, esta característica pode ser resumida assim: eu aprendi uma rota para a rede X através de você, logo você não pode aprender uma rota para a mesma rede X através de minhas informações.

\\Split

horizon with poison reverse (inversão envenenada): Nesta técnica, quando um roteador aprende o caminho para uma determinada rede, ele anuncia o seu caminho de volta para esta rede, com uma métrica = 16. No exemplo da figura anterior, o router1 recebe a informação do router0 que a rede 10 está a 1 hop de distância. O router1 anuncia para o router0 que a rede 10 está a 16 hops de distância. Com isso, jamais o router0 vai tentar achar um caminho para a rede 10 através do router1, o que faz sentido, já que o router0 está diretamente conectado à rede 10.

\\Triggered

updates (atualizações instantâneas): Com esta técnica os roteadores podem anunciar mudanças na métrica de uma rota imediatamente, sem esperar o próximo período de anúncio. Neste caso, redes que se tornem indisponíveis podem ser anunciadas imediatamente com um hop de 16, ou seja, inalcançável. Esta técnica é utilizada em combinação com a técnica de inversão envenenada, para tentar diminuir o tempo de convergência da rede, em situações onde houve indisponibilidade de um roteador ou de um link. Esta técnica diminui o tempo necessário para convergência da rede, porém gera mais tráfego na rede.

As implementações de RIP têm que suportar split horizon e split horizon with poison reverse, embora essa última possa ser desabilitada pelo administrador, se ele o desejar. Normalmente isso é feito por motivo de tráfego. Por outro lado, as atualizações imediatas geram muito tráfego, mas aumentam a velocidade de convergência.


70


Pacote RIP

Pacote RIP

0

RIP usa protocolo UDP porta 520 para enviar e receber mensagens de atualização de rotas Formato da mensagem 78

Comando

15 16

31

Identificador Versão

Cab

Deve ser zero

Identificador do endereço da família

O protocolo RIP (v1 ou v2) utiliza o UDP, port 520, para enviar e receber datagramas. Todas as mensagens de atualização de rotas usam o port UDP520.

Atributo da rota

Endereço IP

R

Máscara de subrede

T E

Próximo hop Métrica

Mensagens de atualização em resposta a um pedido são enviadas ao port de onde veio o pedido. Isto quer dizer que consultas específicas podem ser enviadas de qualquer port, mas o destino delas sempre será o port UDP520.

O layout do pacote RIP está mostrado na figura. O cabeçalho tem 4 octetos (32 bits) e cada anúncio de rota (RouTe Entry – RTE) tem 20 octetos. São permitidas até 25 RTE por pacote. Se o roteador tiver que anunciar mais de 25 rotas, terá que enviar um segundo pacote. Descrição dos campos do cabeçalho: \\Comando

– Especifica o propósito desta mensagem: pedido (1) ou resposta

(2); \\Identificador

de versão – Versão 1 ou 2.

Descrição dos campos do anúncio das rotas (RTE): \\Identificador

do endereço da família – Tipo de endereço; na prática RIP só é usado para endereços IP; da rota (route tag) – Deve ser usado para diferenciar as rotas RIP internas do domínio de outras rotas aprendidas de outros AS, via BGP, ou ainda de outros protocolos IGP do domínio como, por exemplo, OSPF;

\\Atributo

\\Endereço

IP – Identificação da rede para a qual a rota está sendo anunciada;

\\Máscara

de subrede (subnet mask) – Deve ser aplicada ao endereço IP para separar a parte de endereço de rede da parte de endereço de host;

\\Próximo

hop (next hop) – Endereço IP do próximo hop imediato para o qual os pacotes destinados à rede anunciada devem ser encaminhados;

\\Métrica

– Deve conter um valor entre 1 e 15; o valor de 16 indica destino inalcançável.

Faça agora as atividades 1 e 2. Cada atividade deve ser executada em até 30 minutos.


4 Sessão de aprendizagem 4 Protocolo de roteamento RIP Roteiro de atividades Tópicos e conceitos \\Conceito

de AS

\\Conceito

de Vetor-Distância

\\Algoritmo

de cálculo de hops

\\Funcionamento \\Pacotes

do protocolo RIP

RIP

\\Configuração

do protocolo RIP

Competências técnicas desenvolvidas \\Entender \\Calcular

o funcionamento do protocolo RIP

tabela de rotas RIP

\\Configurar

roteadores com protocolo RIP


minutos



72

Atividade 1 – Configuração do protocolo RIP 1. Dar boot no Windows, iniciar o VMware Player, maximizar a janela do VMware Player e só então iniciar a máquina virtual Imunes. Se não maximizar a janela, não será possível visualizar a barra de ferramentas na parte inferior da tela. 2. Após iniciar o programa IMUNES, carregar o arquivo de topologia RedeTeste1.imn. Selecione no menu a opção Experiment/Execute para entrar no modo de execução. 3. Aponte para o router0, mantenha apertado o botão direito do mouse e selecione a opção Ethereal/ser0 (interface ser0 do roteador). 4. Para iniciar uma captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture...) e clique nele. Surgirá a tela de opções do Ethereal (Ethereal: capture options); selecione OK. Em seguida, surgirá uma tela exibindo o total de pacotes por protocolo, à medida que são capturados na interface eth0. Minimize essas janelas. 5. Para abrir o console do router0, aponte para o router0, aperte o botão direito do mouse (mantenha apertado) e selecione a opção shell window/ vtysh. Teremos então a tela que simula o console do roteador router0. 6. O prompt inicial é router0>, que indica que estamos no modo user. Digite enable. Assim teremos o prompt router0#, que indica que estamos no modo privilegiado (padrão Cisco IOS). Neste modo podemos ver as configurações do roteador. O comando sh ip rip mostra as rotas RIP que o router0 conhece neste momento. Como podemos ver na figura, nada acontece, porque não configuramos ainda o protocolo RIP. Nota: o comando sh ip route deve ser usado para verificar se aparecem as redes diretamente conectadas (C>*). Isto confirma que as interfaces correspondentes do roteador estão ativas. Se não aparecerem as redes Roteamento avançado – Sessão de aprendizagem 4

73

diretamente conectadas, significa que houve um erro de inicialização quando foi executada a opção Experiment/Execute no item 2. A operação deve ser feita novamente.

7. Para configurar as rotas RIP, precisamos entrar no modo de configuração global digitando o comando: \\config

t (forma abreviada de configure terminal).

O prompt muda, mostrando que estamos no modo de configuração global. \\Em

seguida digite o comando: router rip

Observe a mudança do prompt indicando o modo de configuração de rotas. \\Em

seguida digite o comando: network 172.16.0.0/16

Pode parecer estranho digitar a identificação da rede Classe B 172.16.0.0/16, mas esta rede foi dividida em subredes Classe C: 172.16.10.0/24, 172.16.20.0/24 etc. Para o protocolo RIP não há necessidade de especificar cada uma das subredes. Ele irá descobrir sozinho as subredes, analisando as máscaras de subrede. Após digitar esses comandos, tecle Ctrl-z para encerrar a configuração. Volta o prompt do modo privilegiado. O comando sh ip rip só deve ser digitado depois que completar a captura dos pacotes, conforme orientação do instrutor.



74

8. Fazer a mesma coisa com os demais roteadores, conforme mostram as figuras a seguir.

9. Volte à janela de captura do Ethereal e aguarde até que sejam capturados pelo menos 10 pacotes, entre pacotes RIP e IGMP. Lembre-se de que o protocolo RIP anuncia suas rotas a cada 30 segundos e que estamos monitorando a interface ser0 do router0; portanto, veremos apenas as rotas anunciadas pelo router1 para o router0 e do router0 para o router1.


75

10. Conforme orientação do instrutor, vá à tela de total de pacotes e clique em STOP. Isto encerra a captura e mostra automaticamente a tela a seguir com todos os pacotes capturados. Esta tela pode variar um pouco de computador para computador, em função do tempo que se levou para digitar os comandos de configuração nos 3 roteadores, da ordem em que os roteadores foram configurados e do tempo de captura. Esta tela mostra os pacotes capturados que estão no arquivo Captura1..

Os pacotes podem estar em ordem diferente da apresentada na figura. 11. Estão relacionados 11 pacotes, sendo 4 mensagens IGMP (Internet Group Management Protocol) e 7 mensagens RIP. Na figura está destacado o pacote 1, destinado ao endereço multicast 224.0.0.9, originado pelo router1, interface 172.16.20.2. Lembre-se de que o protocolo RIPv2 utiliza mensagens multicast para economia de largura de banda da rede. Assim, os roteadores fazem parte de um grupo multicast identificado pelo endereço 224.0.0.9. 12. Na figura a seguir, vemos o destaque do pacote 2 — que é uma mensagem RIP Request originada pelo router1, interface 172.16.20.2 —, destinado ao endereço multicast 224.0.0.9, recebida pelo router0, interface ser0, que estamos monitorando. Esta mensagem é um pedido (RIPv2 Request) do router1, que tem um significado especial, pois o identificador de família de protocolos é zero e a métrica é infinita (16 hops).



76

Segundo o RFC 2453, isto significa que o router1 está solicitando o envio da tabela de rotas inteira do router0. Nenhuma rota é anunciada. Observe que é uma mensagem UDP com port 520 de destino/origem. 13. Na figura a seguir vemos o destaque do pacote 4 — que é uma mensagem RIP Response originada pelo router1, interface 172.16.20.2 —, destinado ao endereço multicast 224.0.0.9, recebida pelo router0, interface ser0, que estamos monitorando. Nesta mensagem o router1 está anunciando a rota para a rede 50: 172.16.50.0/24, com métrica = 2. Conforme previsto, usa o protocolo UDP port 520.


77

14. Na figura a seguir vemos o destaque do pacote 11 — que é uma mensagem RIP Response originada pelo router0, interface 172.16.20.1 —, destinado ao endereço multicast 224.0.0.9. Nesta mensagem o router0 está anunciando a rota para a rede 10: 172.16.10.0/24, com métrica = 1. Observe que, nesta implementação do RIP, as redes diretamente conectadas têm métrica = 1 por default, segundo recomendação do RFC 2453.

15. Neste ponto, é razoável supor que todos os roteadores tenham atualizado as suas tabelas de rotas e tenham aprendido todas as rotas desta rede. Para verificar isso, voltamos aos consoles dos roteadores. Em cada console digite o comando sh ip rip, e teremos a situação mostrada nas figuras iniciais de consoles, com todas as rotas aprendidas. Como todas as tabelas de rotas estão atualizadas, dizemos que o protocolo convergiu. Verificar que as métricas estão corretas, de acordo com o critério do RFC 2453.


78


Uma vez que todas as rotas foram aprendidas, devemos ter continuidade entre os PC’s da rede. Para verificar isso, basta ativar o console do PC1 (shell window /bin/ sh) e digitar o comando: \\ping

–c3 172.16.50.11, que é o endereço IP do PC6.

Se funcionar, as rotas estão corretas. Se não funcionar, use o comando ping para localizar o problema. 16. A seguir mostramos uma figura com outra captura de pacotes feita nas mesmas condições da anterior. Há uma pequena variação na ordem dos pacotes, dependendo da seqüência de configuração e dos tempos envolvidos, conforme já foi dito. Esta tela mostra os pacotes capturados que estão no arquivo Captura2..

Observe que o pacote 14 contém uma mensagem RIP anunciando duas rotas, para as redes 30 e 40, respectivamente.


79

Atividade 2 – Atualização de rotas RIP 1. Iniciar nova captura de pacotes na mesma interface. Se desejar, pode gravar o arquivo corrente de captura para posterior visualização.

2. No router1 vamos colocar off-line a rede 30, derrubando a interface eth0. Para fazer isso usamos o comando shutdown, conforme mostrado na figura a seguir. Antes de “derrubar” a rede, verificamos como está a tabela de rotas IP usando o comando sh ip route, que mostra todas as rotas IP, não apenas as rotas RIP. É o primeiro comando que aparece na figura. Podemos observar que a rota para a rede 30 está na tabela. Em seguida emitimos os comandos: \\config \\int

t (entra no modo de configuração global);

eth0 (entra no modo de configuração de interface, no caso a eth0);

\\shutdown \\Ctrl-Z


(coloca em off a interface, derrubando a rede 30);

(sai do modo de configuração e volta para o modo privilegiado).


80

Emitindo novamente o comando sh ip route verificamos que a rota para a rede 30 desapareceu da tabela (segundo comando sh ip route na figura).

3. Assim como o router1 retirou a rota da tabela dele, os demais roteadores têm que ter sido informados dessa modificação, senão suas tabelas ficarão desatualizadas. No console do router0 mostrado a seguir, vemos que a rota para a rede 30 desapareceu da tabela, como era de se esperar (saída do segundo comando sh ip route). 4. No console do router2 mostrado a seguir, vemos que a rota para a rede 30 também desapareceu da tabela, como era de se esperar (saída do segundo comando sh ip route).


81

Assim, as tabelas de rotas de todos os roteadores convergiram.

5. O passo seguinte é colocar em on a interface eth0 do router1, ativando de novo a rede 30. Podemos observar a seqüência de comandos no console do router1 mostrado numa figura anterior:


82

Escola Superior de Redes RNP \\config

eth0 (entra no modo de configuração de interface, no caso a eth0);

\\int \\no


shut (coloca em on a interface, reativando a rede 30);

\\Ctrl-Z

(sai do modo de configuração e volta para o modo privilegiado).

Emitindo pela terceira vez o comando sh ip route, verificamos que a rota para a rede 30 apareceu novamente na tabela. 6. O mesmo aconteceu com os demais roteadores, conforme pudemos ver nas figuras dos respectivos consoles, onde emitimos pela terceira vez, em ambos os roteadores, o comando sh ip route. Assim, as tabelas de rotas convergiram novamente. 7. Para que as tabelas de rotas de todos os roteadores pudessem ser atualizadas dinamicamente, conforme pudemos observar nos respectivos consoles, certamente houve uma troca de mensagens RIP entre os roteadores. Então, nesse ponto, interrompemos a captura de pacotes do Ethereal. Teremos então a tela a seguir, mostrando os pacotes capturados na interface ser0 do router0, ou seja, as mensagens RIP enviadas pelo router1. Como já foi dito, pequenas variações podem ter ocorrido em função dos tempos envolvidos. Lembre-se de que estamos lidando com processos dinâmicos. O pacote 3 em destaque mostra exatamente isso: o router1 informa que a rede 30 está inalcançável (métrica = 16).


83

Isto ocorreu imediatamente após colocarmos off-line a rede 30, derrubando a interface eth0.



84

8. Na figura a seguir, vemos o pacote 11 em destaque, que mostra o anúncio da rota para a rede 30, ativando de novo essa rota, colocando a rede 30 on-line. Na mesma mensagem são informadas também as rotas para as redes 40 e 50 (observe que as métricas das redes 40 e 50 são diferentes). Isto ocorreu imediatamente após colocarmos a rede 30 on-line, colocando em on a interface eth0.


5 Sessão de aprendizagem 5 Protocolo de roteamento OSPF – Parte 1 Sumário da sessão Open Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Comparação RIP x OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Conceito de Estado do Enlace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Algoritmo SPF – Dijkstra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Algoritmo SPF – Dijkstra – Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Funcionamento do protocolo OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Atividade 1 – Configuração do protocolo OSPF. . . . . . . . . . . . . . . . . . . . . . . . . 94

86


Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) Protocolo de roteamento IP tipo IGP (Interior) Substituiu o protocolo RIP RFC 2328 – STD54 – OSPF v2 Algoritmo SPF (Shortest Path First) Protocolo de Estado de Enlace (Link State) Métrica: custo de saída da interface Convergência rápida das tabelas de rotas Utilizado em redes de médio e grande porte

O OSPF é um protocolo de roteamento desenvolvido para redes IP pelo grupo de trabalho do Interior Gateway Protocol (IGP) do Internet Engineering Task Force (IETF). Esse grupo de trabalho foi formado em 1988 para projetar um protocolo IGP baseado no algoritmo Shortest Path First (SPF) para uso na internet.

O OSPF foi criado pela mesma razão que o IGRP: o protocolo RIP estava se tornando incapaz de operar em redes grandes e heterogêneas. O OSPF é padronizado pelo RFC 2328 sendo, portanto, um padrão aberto e bastante difundido entre todos os fabricantes de roteadores. O OSPF é um protocolo do tipo Estado do Enlace (Link State). Como tal, ele solicita aos roteadores dentro da mesma área hierárquica que enviem Anúncios do Estado do Enlace (Link State Advertisements – LSAs), que contêm informações sobre métricas usadas, interfaces conectadas e outras variáveis. À medida que os roteadores acumulam informações sobre o estado dos enlaces, eles usam o algoritmo SPF para calcular a menor trajetória para cada nó. O OSPF contrasta com os protocolos RIP e IGRP, que usam algoritmo de Vetor de Distância (Distance Vector). Estes últimos enviam parte ou toda a tabela de roteamento em mensagens de atualização de rotas, mas somente para seus vizinhos. Diferentemente do RIP, o OSPF pode operar dentro de uma hierarquia. A entidade de nível mais alto é o Sistema Autônomo (Autonomous System – AS) que é uma coleção de redes sob uma administração comum, compartilhando uma estratégia de roteamento comum. OSPF é um protocolo de roteamento intra-AS (Interior Gateway), embora seja capaz de receber e enviar rotas para outros ASs. O algoritmo SPF é a base para operação do OSPF. Quando um roteador OSPF é ligado, ele inicializa suas estruturas de dados do protocolo de roteamento e espera que os protocolos da camada inferior indiquem que suas interfaces estão funcionais. Uma vez assegurado do funcionamento de suas interfaces, o roteador usa mensagens de Hello para conhecer seus vizinhos, que são roteadores com interfaces para uma rede comum. As métricas, por default, são calculadas segundo a velocidade do enlace, usando a fórmula: \\Custo

= 108 / velocidade de enlace.

Exemplo: um enlace de 100Mbps terá o custo = 100000000 / 100000000 = 1. Um enlace E1 de 2,048 Mbps terá o custo = 100000000 / 2048000 = 48. Enquanto o RIP converge proporcionalmente ao número de nós da rede, o OSPF converge em uma proporção logarítmica ao número de enlaces. Isto torna a Roteamento avançado – Sessão de aprendizagem 5

87

convergência do OSPF muito mais rápida. Além disso, no protocolo RIP, a mensagem é proporcional ao número de destinos; portanto, se a rede é muito grande, cada mensagem terá de ser subdividida em vários pacotes, diminuindo mais ainda a velocidade de convergência. Por sua concepção, o OSPF é adequado a redes de médio e grande porte.

Comparação RIP x OSPF

Comparação RIP x OSPF CARACTERÍSTICA

RIP

OSPF

Limite de hops Suporta VLSM (Variable Length Subnet Mask) Broadcasting periódico da tabela de roteamento Broadcasting somente quando a tabela é atualizada Atualização de tabelas com mensagens IP multicast Convergência das tabelas de roteamento Decisão de roteamento baseada somente nos hops Decisão de roteamento baseada em várias métricas Rotas alternativas para o mesmo destino Hierarquia de roteamento (divisão em áreas) Autenticação das mensagens de atualização de rotas Comunicação com protocolos exteriores ao AS

15 Sim Sim Não Sim Lenta Sim Não Não Não Sim Não

Não Sim Não Sim Sim Rápida Não Sim Sim Sim Sim Sim

Comparação das características dos protocolos RIP e OSPF: \\RIP

é limitado a 15 hops, acima disso é inalcançável; o OSPF não tem limite no número de hops;

\\RIPv1

não suporta VLSM, que é um recurso muito útil para o aproveitamento de endereçamento IP; o RIPv2 suporta VLSM, bem como o OSPF, que faz um uso inteligente desse recurso;

\\Broadcasts

periódicos da tabela de roteamento completa consomem grandes quantidades de largura de banda, especialmente em redes maiores, e são críticos em enlaces seriais lentos e redes WAN; OSPF só faz broadcast quando há alteração na tabela de roteamento;

\\RIPv1

não suporta mensagens multicast de atualização de tabelas, apenas o RIPv2, bem como o OSPF;

\\RIP

tem uma convergência mais lenta do que o OSPF, porque os roteadores RIP temporizam hold-down e garbage collection, e demoram para perceber o timeout de informações; o OSPF propaga instantaneamente as informações da tabela de roteamento, e não periodicamente como o RIP;

\\RIP

usa somente a métrica de número de hops, sem considerar retardo dos enlaces e custos das rotas, que são parâmetros importantes em grandes redes; links com menos hops são sempre preferidos em detrimento de links com mais hops, embora esses últimos possam ser mais velozes;

\\OSPF

considera o custo de cada rota e faz um melhor balanceamento de carga considerando o uso de rotas alternativas; isso é possível porque o OSPF tem um banco de dados da topologia da rede e não apenas dados de cada rota que ele conhece; em conseqüência disso, o OSPF calcula rotas livres de loops;

\\Redes

RIP não têm hierarquia (são ditas flat — planas), não permitindo a definição de áreas; OSPF permite a divisão do domínio de roteamento (AS) em várias áreas, reduzindo a propagação de informações de roteamento;

\\RIPv1

não autentica mensagens de atualização de tabelas, apenas o RIPv2, bem como o OSPF;

Protocolo de roteamento OSPF – Parte 1

88

Escola Superior de Redes RNP \\RIP

não permite a comunicação com protocolos exteriores ao AS (como o BGP, por exemplo); o OSPF permite a introdução de rotas externas oriundas do BGP.

Conceito de Estado do Enlace

Conceito de Estado do Enlace O Estado do enlace pode ser considerado como uma descrição da interface do roteador Link State Routing Protocol Substituiu o protocolo Vetor-Distância Características Descobrir seus vizinhos e seus endereços de rede Calcular o retardo ou custo para cada um dos vizinhos Construir um pacote informando tudo que aprendeu Propagar o pacote para todos os roteadores Calcular o menor caminho para todos os roteadores

Podemos considerar um enlace (link) como uma interface do roteador. O estado do enlace (link state) é uma descrição da interface e de seu relacionamento com os seus roteadores vizinhos. Uma descrição da interface pode incluir, por exemplo, o endereço IP da interface, a máscara de subrede, o tipo de rede a qual está conectada, os roteadores conectados àquela rede e assim por diante.

O conjunto de todos os estados de enlace forma um banco de dados de estado de enlace. Este protocolo com abordagem dinâmica é um dos mais populares algoritmos empregados em redes modernas, substituindo o protocolo Vetor-Distância pelas vantagens apresentadas na comparação RIP x OSPF. O protocolo se baseia nos cinco pontos relacionados abaixo: \\Descobrir \\Calcular

seus vizinhos e seus endereços de rede

o retardo ou custo para cada um dos vizinhos

\\Construir

um pacote informando tudo que aprendeu

\\Propagar

o pacote para todos os roteadores

\\Calcular

o menor caminho para todos os roteadores

Algoritmo SPF – Dijkstra (1) Cada nó é etiquetado com a distância desde o nó fonte, ao longo do melhor caminho conhecido. Inicialmente todos os nós são etiquetados com “f”. À medida que o algoritmo vai calculando os caminhos mais curtos, as etiquetas vão mudando. Uma etiqueta pode ser experimental ou permanente. Inicialmente todas as etiquetas são experimentais. Quando uma etiqueta representa o menor caminho possível entre a fonte e o nó específico, ela se torna permanente e não será mais alterada.

Algoritmo SPF – Dijkstra O roteamento pelo caminho mais curto se baseia no algoritmo de Dijkstra, cujos passos estão representados acima. Basicamente consiste em construir um grafo da rede, onde cada nó representa um roteador, e o arco que interliga um par de nós representa uma linha de comunicação (link). Para escolher uma rota entre um dado par de roteadores, o algoritmo precisa apenas determinar o


89

caminho mais curto entre os roteadores no grafo. Para isso, pode se basear em diferentes métricas: \\Número

de hops entre fonte e destino;

\\Distância

física (geográfica);

\\Fila

média e atraso de transmissão associado a cada linha de comunicação no caminho.

O administrador pode definir um valor único que representa a ponderação desses fatores e que se chama custo da rota. O caminho mais curto será o caminho mais rápido, não necessariamente o de menor número de hops ou de quilômetros.

Algoritmo SPF – Dijkstra (2) B

C

7

2

2

A

E

1

6

F

2

3

3

D

2

4

G

2 H

Exemplo de funcionamento do algoritmo SPF Os números representam o custo das rotas Desejamos determinar o menor caminho de A até D 1. Nó A é marcado como nó permanente (círculo cheio); 2. Nó A é chamado “nó de trabalho”; 3. Cada um dos nós adjacentes ao nó A é examinado e re-etiquetado com a distância entre ele e o nó A;

Algoritmo SPF – Dijkstra (3) B(2,A) 2 A 6

2 1 G(6,A)

C(f,-)

7 E(f,-)

2 4

F(f,-)

3

3

D(f,-)

2

2 H(f,-)

4. Sempre que um nó é re-etiquetado, é marcado com a identificação do nó a partir do qual o cálculo foi feito, para permitir a reconstrução do caminho final; 5. Tendo sido examinados todos os nós adjacentes ao nó A, aquele com o menor valor é feito nó permanente, passando a ser o novo “nó de trabalho”, no caso, o nó B;


90



2

C(9,B)

7 E(4,B)

1

2

F(f,-)

3 2

4

3 D(f,-) 2 H(f,-)

G(6,A)

6. A partir do novo nó de trabalho (nó B), cada um dos nós adjacentes é examinado. Se a soma da etiqueta em B com a distância entre o nó B e o nó que está sendo examinado for menor que o valor da etiqueta naquele nó, está definido o menor caminho, e o nó é re-etiquetado; 7. Após todos os nós adjacentes ao nó de trabalho terem sido examinados, o nó com o menor valor se torna permanente e passa a ser o novo nó de trabalho (nó E);


2

C(9,B)

7 E(4,B)

1

2

F(6,E)

3 2

4

3 D(f,-) 2 H(f,-)

G(5,E)

8. A partir do novo nó de trabalho (nó E), cada um dos nós adjacentes é examinado. Se a soma da etiqueta em E com a distância entre o nó E e o nó que está sendo examinado for menor que o valor da etiqueta naquele nó, está definido o menor caminho e o nó é re-etiquetado; 9. Após todos os nós adjacentes ao nó de trabalho terem sido examinados, o nó com o menor valor se torna permanente e passa a ser o novo nó de trabalho (nó G);


2 1 G(5,E)

C(9,B)

7 E(4,B)

2 4

F(6,E)

3 2

3 D(f,-) 2 H(9,G)

10. A partir do novo nó de trabalho (nó G), cada um dos nós adjacentes é examinado; 11. Após todos os nós adjacentes ao nó de trabalho terem sido examinados, o nó com o menor valor se torna permanente e passa a ser o novo nó de trabalho (nó F);


91

Algoritmo SPF – Dijkstra (7) B(2,A) 2

2

A

E(4,B)

3

3

F(6,E)

2

1

6

C(9,B)

7

D(10,H)

2

4

G(5,E)

2 H(8,F)

12. A partir do novo nó de trabalho (nó F), cada um dos nós adjacentes é examinado; 13. Após todos os nós adjacentes ao nó de trabalho terem sido examinados, o nó com o menor valor se torna permanente e passa a ser o novo nó de trabalho (nó H); 14. A partir do nó H, determina-se o nó D (10,H).

Algoritmo SPF – Dijkstra – Resumo

Algoritmo SPF – Dijkstra – Resumo B 2 A 6

2

7 E

C F

2 4

1

G B(2,A) 7 2 A 6

3

2

E(4,B) F

1

2 4

2

2 6

2

3

G(5,E)

2 4

D

A 6

2

2

2

2 D

A 6

2

3

2 D

H(9,G)

E

C F

2 4

1

3 2

2

3 E(4,B)F(6,E) 2 4

1

2

G(5,E) B 7

H C(9,B)

2

2

G(6,A) B(2,A) 7

3

3 E(4,B)F(6,E)

1

2

H C(9,B)

G(6,A) B(2,A) 7 A

B(2,A) 7 3

A 6

2

3 E(4,B)F(6,E)

1 G(5,E)

2 4

2

3 D 2 H C(9,B)

\\Passo

3 D 2 H C(9,B) 3 D(10,H) 2 H(8,F)

A figura acima resume os passos explicados anteriormente. 1: O nó A é o “nó de trabalho” (círculo azul cheio); a etiqueta torna-se permanente e os nós adjacentes a ele são examinados para determinar a distância dele até o nó em exame; os nós B e G ganham etiquetas, mas apenas o nó B é permanente, porque tem o menor valor; todas as etiquetas são marcadas com a identificação do nó a partir do qual o cálculo foi feito, para permitir a reconstrução do caminho;

\\Passo

2: Como o nó B é de menor valor, ele passa a ser o novo “nó de trabalho”; a partir dele são calculadas as distâncias relativas aos nós C e E; o nó E é tornado permanente porque tem o menor valor;

\\Passo

3: O nó E é o novo “nó de trabalho”; a partir dele são calculadas as distâncias relativas aos nós G e F; note que o nó G tem seu valor redefinido; era (6,A) e ficou (5,E), porque o valor é menor a partir de E do que a partir de A; o nó G é tornado permanente porque tem o menor valor;

\\Passo

4: O nó G é o novo “nó de trabalho”; a partir dele é calculada a distância relativa ao nó H; o nó F é tornado permanente porque tem o menor valor;

\\Passo

5: O nó F é o novo “nó de trabalho”; a partir dele são calculadas as distâncias relativas aos nós C e H; o nó H é tornado permanente porque tem o menor valor; sua distância foi recalculada porque foi encontrado um caminho menor; o nó C permanece com o mesmo valor, pois as duas rotas calculadas são iguais;

\\Passo

6: O nó H é o novo “nó de trabalho”; a partir dele é calculada a distância relativa ao nó D (10,H).


92


Funcionamento do protocolo OSPF Os passos do algoritmo do estado de enlace: 1. O roteador gera um anúncio de estado de enlace; 2. Os roteadores trocam informações entre si usando o protocolo flooding (inundação); 3. Após completar o banco de dados, cada roteador calcula o caminho mais curto para os demais; 4. Se nenhuma alteração de topologia ocorrer, nenhuma informação será trocada entre os roteadores; se ocorrer mudança, o caminho mais curto será recalculado.

Funcionamento do protocolo OSPF O protocolo OSPF usa o algoritmo do estado de enlace para construir e calcular o caminho mais curto para todos os destinos conhecidos. Um resumo dos passos do algoritmo pode ser descrito como: \\Na

inicialização ou devido a alguma mudança de topologia na rede, o roteador gera um anúncio de estado de enlace. Este anúncio contém o conjunto de todos os estados de enlace do roteador.

\\Todos

os roteadores trocarão informações do estado de enlace através do protocolo de inundação (flooding). Cada roteador que recebe uma atualização do estado de enlace armazena uma cópia no seu banco de dados de estado de enlace, e depois propaga a atualização para os outros roteadores;

\\Depois

que cada roteador completa o seu banco de dados, ele calcula a árvore de trajetórias mais curta (Shortest Path Tree) para todos os destinos. O roteador usa o algoritmo de Dijkstra para fazer esse cálculo. Os destinos, o seu respectivo custo associado e o próximo hop para atingir aquele destino formam a tabela de roteamento IP.

\\Se

nenhuma alteração na rede OSPF ocorrer, como, por exemplo, o custo de um link ou novas redes adicionadas ou excluídas, OSPF permanecerá em silêncio. Quaisquer mudanças que ocorram serão informadas via pacotes de estado de enlace e o algoritmo de Dijkstra é recalculado para encontrar o caminho mais curto.


5 Sessão de aprendizagem 5 Protocolo de roteamento OSPF – Parte 1 Roteiro de atividades Tópicos e conceitos \\Comparação \\Conceito

RIP x OSPF

de Estado do Enlace (Link State)

\\Algoritmo

SPF (Shortest Path First)

\\Funcionamento \\Configuração

do protocolo OSPF

básica do protocolo OSPF

Competências técnicas desenvolvidas \\Entender \\Calcular

o funcionamento do protocolo OSPF

tabela de rotas OSPF

\\Configurar

roteadores com protocolo OSPF


minutos



94

Atividade 1 – Configuração do protocolo OSPF 1. Dar boot no Windows, iniciar o VMware Player, maximizar a janela do VMware Player e só então iniciar a máquina virtual Imunes. Se não maximizar a janela, não será possível visualizar a barra de ferramentas na parte inferior da tela.. 2. Após iniciar o programa IMUNES, carregar o arquivo de topologia RedeTeste1.imn. Essa rede é a mesma que utilizamos nas outras unidades e está representada na figura a seguir. Selecionar no menu a opção Experiment/Execute para entrar no modo de execução. 3. Aponte para o router0, mantenha apertado o botão direito do mouse e selecione a opção Ethereal/ser0 (interface ser0 do roteador). 4. Para iniciar uma captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture...) e clique nele. Surgirá a tela de opções do Ethereal (Ethereal: capture options); selecione OK. Em seguida, surgirá uma tela onde é mostrado o total de pacotes por protocolo, à medida que são capturados na interface ser0. Minimize essas janelas.

5. Para abrir o console do router0, aponte para o router0, mantenha apertado o botão direito do mouse e selecione a opção Shell window/ vtysh. Teremos então a tela que simula o console do roteador router0. 6. O prompt inicial é router0>, que indica que estamos no modo user. Digite enable. Assim teremos o prompt router0#, que indica que estamos no modo privilegiado (padrão Cisco IOS). Nota: o comando sh ip route deve ser usado para verificar se aparecem as redes diretamente conectadas (C>*). Isto confirma que as interfaces


95

correspondentes do roteador estão ativas. Se não aparecerem as redes diretamente conectadas, significa que houve um erro de inicialização quando foi executada a opção Experiment/Execute no item 2. A operação deve ser feita novamente. Neste modo podemos configurar o protocolo OSPF no roteador. Para isso, digitar os comandos: \\ config


\\router

ospf (habilita o protocolo OSPF);

\\network

172.16.0.0/16 area 0 (informa a rede que será roteada no

backbone); \\Ctrl-Z

(para encerrar a configuração);

Como veremos mais adiante, o protocolo OSPF é hierárquico, permitindo a divisão da rede em áreas, sendo a área 0 o backbone. Esses comandos estão mostrados na figura a seguir.

7. A mesma coisa deve ser feita nos consoles dos roteadores router1 e router2.



96

8. Os roteadores ativarão o protocolo OSPF, que começará a montar sua tabela de rotas, como podemos ver na figura a seguir, que mostra o console do router0, onde digitamos o comando sh ip route.

Note que as rotas OSPF têm uma distância administrativa de 110 e as métricas variando de 10 a 30, conforme a rota. A distância administrativa é um valor que mede a confiabilidade da rota. Quanto menor, melhor. Pode ser um valor de 0 (rede diretamente conectada) a 255 (nenhum tráfego). Rotas estáticas têm AD = 1, por default. Rotas RIP têm AD = 120, por default. Isto significa que, se um roteador receber um anúncio de rota RIP (AD = 120), e na tabela dele constar uma rota OSPF (AD = 110), ele irá ignorar a rota anunciada, não importando a métrica. Assim, se o roteador tiver rotas estáticas na tabela, irá ignorar todos os anúncios de rotas dos protocolos RIP, OSPF etc. 9. Mesma coisa para os roteadores router1 e router2.


97

10. Outro comando específico para o protocolo OSPF é sh ip ospf. As figuras mostram os resultados para os roteadores da rede.



98

Esses comandos servem para verificar se o protocolo OSPF está funcionando. 11. Volte na janela de captura do Ethereal e, conforme orientação do instrutor, vá à tela de total de pacotes e clique em STOP. Isto encerra a captura e mostra automaticamente a tela a seguir com todos os pacotes capturados. Esta tela pode variar um pouco de computador para computador, em função do tempo que se levou para digitar os comandos de configuração nos 3 roteadores, da ordem em que os roteadores foram configurados e do tempo de captura.


99

12. Na tela do Ethereal vemos em destaque o pacote número 2, que é um pacote de Hello do protocolo OSPF originado na interface ser0 do router0 (IP 172.16.20.1). Note que o destino é um endereço multicast: 224.0.0.5. 13. Na próxima figura, vemos mais uma tela do Ethereal, desta vez destacando o pacote número 10, que foi originado na interface ser0 do router1 (IP 172.16.20.2).


100


14. Uma vez que todas as rotas foram aprendidas, devemos ter continuidade entre os PC’s da rede. Para verificar isso, basta ativar o console do PC1 (shell window /bin/sh) e digitar o comando: \\ping

–c3 172.16.50.11, que é o endereço IP do PC6.

Se funcionar, as rotas estão corretas. Se não funcionar, use o comando ping para localizar o problema. Podemos ainda verificar a rota dos pacotes com o comando: \\traceroute


172.16.50.11

6 Sessão de aprendizagem 6 Protocolo de roteamento OSPF – Parte 2 Sumário da sessão Glossário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 OSPF – Roteadores de borda e área . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Pacotes de Estado de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 OSPF – Resumo de funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Autenticação OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Backbone OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Layout dos pacotes OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Atividade 1 – Configuração do protocolo OSPF. . . . . . . . . . . . . . . . . . . . . . . . 116

102


Glossário

Glossário

A seguir faremos uma rápida revisão da terminologia usada no protocolo OSPF. Alguns termos já são conhecidos, mas outros podem ser novidade.

Link Router ID Loopback interface Neighbors

\\Link

– É uma interface de rede ou de roteador associada a uma dada rede. Quando uma interface é adicionada ao processo OSPF, ela é considerada pelo OSPF como um link (enlace). Este enlace ou interface terá informação de estado associada como, por exemplo, up ou down, um ou mais endereços IP etc;

\\Router

ID – A identificação do roteador (RID) é um endereço IP usado para identificar o roteador. A Cisco escolhe a RID como o maior endereço IP de todas as interfaces de loopback configuradas. Se não forem configuradas interfaces de loopback, o OSPF escolherá o maior endereço IP entre todas as interfaces físicas ativas;

\\Loopback

interface – A configuração de interfaces de loopback é importante quando usamos o protocolo OSPF, e a Cisco recomenda que seja realizada sempre que for feita configuração OSPF no roteador. Loopback interfaces são interfaces lógicas, que são virtuais e somente de software, e não interfaces reais. O uso de interfaces de loopback garante que pelo menos uma interface estará sempre ativa para os processos OSPF. Elas podem ser usadas para diagnósticos, bem como para configuração do OSPF. Se não for configurada uma interface de loopback, a interface real ativa com o maior endereço IP será a RID do roteador. A RID é usada para anunciar rotas e também para a eleição dos DR (Designated Router) e BDR (Backup Designated Router). Se a interface usada como RID sair do ar (down), será necessária uma eleição de DR ou BDR na rede. Se a interface usada como RID for uma interface serial e o enlace estiver saindo do ar com freqüência, isto pode ser um problema. Interfaces loopback nunca saem do ar; portanto, a RID do roteador nunca muda.

\\Neighbors

– Vizinhos são dois ou mais roteadores que têm uma interface numa mesma rede como, por exemplo, dois roteadores conectados por um enlace serial ponto-a-ponto; a relação de vizinhança entre dois roteadores é, usualmente, descoberta e mantida dinamicamente pelo protocolo Hello;


103

\\Adjacency

– Uma adjacência é uma relação entre dois roteadores OSPF que permite a troca direta de atualizações de rotas. O OSPF somente troca atualizações de rotas entre vizinhos que tenham estabelecido adjacências. Nem todos os roteadores vizinhos serão adjacentes; vai depender do tipo de rede e da configuração dos roteadores;

Glossário (cont.) Adjacency Hello protocol Flooding Neighborship database Topology database Link State Advertisement Designated router Backup designated router

\\Hello

protocol – O protocolo de Hello (Alô) permite a descoberta dinâmica de vizinhos e a manutenção de relações de vizinhança. Pacotes de Hello e Link State Advertisement (LSA) são usados para construir e manter atualizado o banco de dados de topologia da rede. Os pacotes de Hello são endereçados para o endereço IP multicast 224.0.0.5;

\\Flooding

– A parte do protocolo OSPF que distribui e sincroniza o banco de dados de estado de enlace entre roteadores OSPF;

\\Neighborship

database – O banco de dados de vizinhança é uma lista de todos os roteadores OSPF dos quais foram recebidos pacotes de Hello. Diversas informações, como a RID e o estado de enlace, são armazenadas no banco de dados de vizinhança de cada roteador;

\\Topology

database – O banco de dados de topologia contém informações de todos os pacotes de Anúncio de Estado de Enlace (Link State Advertisement – LSA) que foram recebidos de uma área OSPF. O roteador usa esta informação como entrada para o algoritmo de Dijkstra que calcula a rota mais curta (Shortest Path First – SPF) para cada rede;

\\Link

State Advertisement – Um Anúncio de Estado de Enlace (LSA) é um pacote de dados OSPF contendo informações de estado de enlace e de roteamento que são compartilhadas somente entre os roteadores OSPF que tenham estabelecido adjacências;

\\Designated

router – Um roteador designado (DR) é eleito sempre que roteadores OSPF são conectados à mesma rede multi-acesso. A Cisco chama essas redes de redes broadcast como, por exemplo, uma rede local Ethernet. Para reduzir a quantidade de adjacências criadas, um DR é escolhido para receber e divulgar informações de roteamento dos demais roteadores, com a finalidade de garantir que as tabelas de topologia estejam sincronizadas. Todos os roteadores na rede multi-acesso estabelecerão adjacências com o DR e seu backup (BDR). Esta eleição é ganha pelo roteador com a mais alta prioridade ou, caso existam dois com a mesma prioridade, com o de RID maior;

\\Backup

designated router – O backup do roteador designado (BDR) é um hot standby do DR. O BDR recebe todas as informações de atualização de rotas dos roteadores OSPF adjacentes, mas não as propaga;


104

Escola Superior de Redes RNP \\OSPF

areas – Áreas OSPF são um agrupamento de roteadores e redes contíguas. Todos os roteadores na mesma área compartilham uma Area ID (Identificação de Área) comum. Como um roteador pode ser membro de mais de uma área ao mesmo tempo, a Area ID é associada a interfaces específicas do roteador. Isto permite que, por exemplo, uma interface pertença à área 1 e outra à área 0 (backbone). Todos os roteadores dentro da mesma área têm a mesma tabela de topologia. Áreas OSPF permitem estabelecer uma hierarquia na rede e aumentar a escalabilidade do OSPF;

Glossário (cont.) OSPF areas Stub areas Broadcast (multi-access) Non-broadcast (multi-access) Point-to-point Point-to-multipoint

\\Stub

areas – OSPF permite que certas áreas sejam configuradas como stub areas. Essas áreas têm as seguintes restrições: 1. Rotas externas, informadas a partir de outros protocolos, não podem ser propagadas nelas (flooded); 2. O roteamento dessas áreas para o mundo exterior é baseado em rotas padrão; 3. Não podem ser áreas de trânsito para enlaces virtuais nem podem ser o backbone; 4. Não podem conter um ASBR. Todos os roteadores nessas áreas são configurados como stub routers; em função das restrições, eles terão um banco de dados de topologia reduzido e menor consumo de memória; todas as interfaces que pertencem a essas áreas trocam pacotes de Hello com um flag indicando que esta interface é stub (bit E); todos os roteadores da área devem concordar quanto ao uso do flag para poderem ser vizinhos;

\\Broadcast

(multi-access) – Redes broadcast de acesso múltiplo (multi-access), tais como as redes locais Ethernet, permitem que múltiplos dispositivos se conectem (ou acessem) à mesma rede, bem como também permitem a facilidade de broadcasting, onde um único pacote pode ser entregue a todos os nós da rede. Um DR e um BDR têm que ser eleitos para cada rede broadcast (multi-access);

\\Non-broadcast

(multi-access) – Redes non-broadcast (multi-access) (NBMA), tais como as redes Frame Relay, X.25 (Renpac) e Asynchronous Transfer Mode (ATM) não têm facilidade de broadcasting como a rede local Ethernet, mas permitem acesso múltiplo. Assim, as redes NBMA requerem configuração especial do OSPF e as relações de vizinhança precisam ser definidas;

\\Point-to-point

– Ponto-a-ponto é um tipo de topologia de rede na qual existe uma conexão direta entre dois roteadores formando um único enlace de comunicação. A conexão ponto-a-ponto pode ser física, como num enlace serial, ou lógica, como num circuito Frame Relay. Em ambos os casos, este tipo de configuração elimina a necessidade de DRs ou BDRs, mas os vizinhos são descobertos automaticamente;

\\Point-to-multipoint

– É um tipo de topologia de rede na qual existe uma série de conexões entre uma única interface de um roteador e múltiplos roteadores de destino. Todas as interfaces de todos os roteadores que compartilham a


105

conexão ponto-multiponto pertencem à mesma rede. Como nas redes ponto-aponto, não há necessidade de DRs ou BDRs. Todos esses termos são importantes para o correto entendimento do funcionamento do protocolo OSPF. Nem todas as características do protocolo OSPF serão abordadas aqui, porque fogem do escopo deste curso. Para aqueles que têm a tarefa de administrar redes OSPF recomendamos as seguintes leituras: \\OSPF-Design-Guide,

encontrado no URL (formatos .html e .pdf): http://www.cisco.com/en/US/tech/tk365/technologies_white_ paper09186a0080094e9e.shtml

\\RFC2328

OSPF – Roteadores de borda e área (1) Rede é dividida em áreas Objetivo: reduzir o tráfego Hierarquia de roteamento dentro do AS Área 0 (zero): Backbone OSPF Todas as áreas se conectam ao backbone Função do roteador depende da localização Internal Router Backbone Router Area Border Router AS Border Router

OSPF – Roteadores de borda e área Um AS pode ser dividido em áreas, que são um grupo de redes contíguas e seus hosts conectados. Roteadores com múltiplas interfaces podem participar em múltiplas áreas e são chamados roteadores de fronteira de área (Area Border Routers).

Eles mantêm bancos de dados topológicos para cada área. Um banco de dados topológico é essencialmente uma visão geral de redes relativamente a roteadores, contendo a coleção de Anúncios de Estado de Enlace (LSAs) recebidos de todos os roteadores na mesma área. Como os roteadores dentro da mesma área compartilham a mesma informação, todos têm idênticos bancos de dados topológicos. O termo domínio é algumas vezes usado para descrever uma parte da rede na qual os roteadores têm bancos de dados topológicos idênticos, sendo, portanto, freqüentemente usado no lugar de AS, embora seja diferente. Eventualmente, um AS pode conter apenas um domínio. A topologia de uma área é invisível para entidades fora da área; desta forma, o OSPF reduz o tráfego de roteamento em relação a ASs não particionados. O particionamento de áreas cria dois tipos diferentes de roteamento OSPF, dependendo se a origem e o destino estão na mesma área ou em áreas diferentes. Roteamento intra-área ocorre quando a origem e o destino estão na mesma área; roteamento inter-área ocorre quando eles estão em áreas diferentes.


106


Um roteador que pertence a apenas uma área é um Internal Router. Um roteador que pertence ao backbone é um Backbone Router. Um backbone OSPF é responsável pela distribuição de informações de roteamento entre áreas. Ele é composto pelos roteadores de fronteira de área (Area Border Routers), pelas redes não contidas em nenhuma área e seus roteadores conectados. O backbone é a área 0 (zero). Todas as áreas têm que estar conectadas ao backbone OSPF, seja diretamente por enlaces reais ou por enlaces virtuais através de outras áreas. Os roteadores responsáveis pela distribuição de informações para outros ASs são os AS Border Routers. Os roteadores de fronteira no AS (AS Border Routers) que executam o OSPF aprendem as rotas exteriores por meio de protocolos EGPs (Exterior Gateway Protocols), tais como o Border Gateway Protocol (BGP).

OSPF – Roteadores de borda e área (2)

\\Backbone

router – Um roteador que possui interface(s) para o backbone.

\\Area

Border Router – Está conectado a múltiplas áreas e executa várias cópias do algoritmo de roteamento para cada área em que está conectado.

\\Internal

Router – Um roteador que está conectado a redes pertencentes à mesma área; executa apenas uma única cópia do algoritmo de roteamento.

\\Autonomous

System (AS) Border Router – Um roteador que troca informações de roteamento com roteadores pertencentes a outros sistemas autônomos.

Pacotes de Estado de Enlace

Pacotes de Estado de Enlace

Router Links

Os diferentes tipos de pacotes de estado de enlace mais comuns estão ilustrados na figura acima. São eles:

Network Links

\\Router

Summary Links External Links


links – Descrevem o estado e o custo dos enlaces do roteador (interfaces) para a área (intraárea);

\\Network

links – Originados por um Designated Router (DR) para segmentos multi-acesso com mais de um roteador conectado. Descreve todos os roteadores conectados ao segmento específico;

107

\\Summary

links – Originados somente por ABRs (Area Border Routers). Descrevem as redes no AS fora de uma área (inter-área). Também descrevem a localização do Autonomous System Border Router (ASBR);

\\External

links – Originados por um ASBR. Descreve os destinos externos ao AS ou uma rota padrão para fora do AS.

Como mostrado acima, os pacotes router links são uma indicação do estado das interfaces de um roteador que pertence a uma certa área. Cada roteador gera um router link para todas as suas interfaces. Pacotes summary links são gerados por ABRs. Esta é a maneira como a informação de rotas das redes é disseminada entre áreas. Normalmente, toda a informação é enviada para o backbone (área 0) e, por sua vez, o backbone a propaga para as outras áreas. ABRs também têm a tarefa de propagar a rota para o ASBR. Esta é a maneira como os roteadores conhecem as rotas externas para outros ASs. Pacotes network links são gerados por um DR num segmento de rede. Esta informação é uma indicação de todos os roteadores conectados a um particular segmento multi-acesso, tal como redes locais Ethernet, Token ring e FDDI, além de redes NBMA. Pacotes external links são uma indicação de redes fora do AS. Essas redes são informadas ao OSPF via redistribuição. O ASBR tem a tarefa de informar essas rotas para o AS.

OSPF – Resumo de funcionamento Cada área tem uma cópia independente do OSPF Quando ligado, o roteador executa a seguinte seqüência: Inicializa as estruturas de dados do protocolo Determina as interfaces funcionais Executa o protocolo Hello para conhecer seus vizinhos Em redes multi-acesso (broadcast e NBMA) é eleito um DR

Tenta formar adjacências com seus novos vizinhos Periodicamente anuncia o estado de seus enlaces LSAs são propagados na área OSPF usando o algoritmo de flooding para sincronizar os bancos de dados A partir do banco de dados calcula as rotas para as redes

OSPF – Resumo de funcionamento Uma cópia independente do algoritmo de roteamento básico do OSPF roda em cada área. Roteadores que têm interfaces para múltiplas áreas rodam múltiplas cópias do algoritmo. A seguir um resumo do funcionamento do algoritmo de roteamento. Quando um roteador é ligado, ele primeiro inicializa as estruturas de dados do protocolo de roteamento. O roteador então aguarda a indicação dos protocolos de camadas inferiores (enlace de dados e física) de que suas interfaces estão funcionais.

O roteador usa o protocolo Hello para conhecer seus vizinhos. O roteador envia pacotes de Hello para seus vizinhos e, em troca, recebe deles pacotes de Hello. Em redes ponto-a-ponto e broadcast, o roteador detecta dinamicamente seus vizinhos enviando pacotes de Hello para o endereço multicast 224.0.0.5. Em redes NBMA e broadcast o protocolo de Hello elege um DR para a rede. Dois roteadores não se tornarão vizinhos, a menos que concordem com as seguintes condições: Protocolo de roteamento OSPF – Parte 2


108

– Para dois roteadores no mesmo segmento, suas interfaces têm que pertencer à mesma área no segmento;

\\Area-id

– OSPF permite a configuração de uma senha para a área específica. Roteadores que querem ser vizinhos têm que ter a mesma senha num segmento em particular;

\\Authentication

and Dead Intervals – OSPF troca pacotes Hello em cada segmento; isto é uma forma de keep alive usada pelos roteadores para conhecer a existência deles num segmento e também para eleição de um DR.

\\Hello

O intervalo de Hello especifica o tempo, em segundos, entre os pacotes Hello que um roteador envia numa interface OSPF. O intervalo chamado dead interval especifica o tempo (em segundos) que os pacotes Hello podem deixar de ser enviados antes que um roteador seja declarado inativo (down). OSPF exige que esses dois intervalos sejam exatamente iguais entre dois vizinhos. Se não, os roteadores não se tornarão vizinhos. area flag – Dois roteadores também têm que concordar com o stub area flag (caso pertençam ambos a uma stub area) nos pacotes Hello, para que possam ser vizinhos.

\\Stub

O roteador tentará criar adjacências com alguns de seus novos vizinhos conhecidos. Os bancos de dados de estado de enlace são sincronizados entre pares de roteadores adjacentes. Em redes broadcast e NBMA, o DR determina que os roteadores se tornarão adjacentes. Adjacências controlam a distribuição de informação de roteamento. Atualizações de rotas são enviadas e recebidas somente entre roteadores adjacentes. Um roteador periodicamente anuncia seu estado, também chamado de estado de enlace. O estado de enlace também é anunciado quando o estado de um roteador muda. As adjacências de um roteador estão descritas no conteúdo dos LSAs. Este relacionamento entre adjacências e estado de enlace permite que o protocolo detecte rotas inativas de tempos em tempos. LSAs são propagadas na área por flooding (inundação). O algoritmo de flooding é confiável, garantindo que todos os roteadores numa área tenham exatamente o mesmo banco de dados de estado de enlace. Este database consiste de um conjunto de LSAs originados de cada roteador pertencente à área. A partir deste banco de dados, cada roteador calcula os caminhos mais curtos (shortest-path tree), sendo ele mesmo a raiz. Estes caminhos mais curtos permitem a montagem da tabela de roteamento do protocolo OSPF.


109

Autenticação OSPF

Autenticação OSPF Autenticação nula, por default Autenticação com senha simples (simple password) Senha (chave) por área Todos os roteadores da área têm a mesma senha Método vulnerável a sniffers Autenticação Message Digest (MD-5) Autenticação criptográfica Uma key (senha) e uma key-id por roteador Algoritmo baseado no pacote OSPF, key e key-id Gera uma message digest adicionada ao pacote

É possível autenticar os pacotes OSPF de forma que os roteadores possam participar do roteamento baseado em senhas (password) pré-definidas. Por default, um roteador usa autenticação nula, que significa que as informações de roteamento trocadas na rede não são autenticadas. Isto torna a rede vulnerável a ataques que informem rotas falsas. Existem dois métodos de autenticação: Simple password e Message Digest (MD-5).

Simple Password Authentication A autenticação com senha simples permite que uma senha (chave) seja configurada por área. Roteadores na mesma área que quiserem participar do roteamento terão que ser configurados com a mesma chave. A desvantagem deste método é que ele é vulnerável a ataques passivos, porque qualquer um com um sniffer pode capturar a senha da rede. Para habilitar autenticação com senha use os seguintes comandos: ip ospf authentication-key (no modo de configuração da interface conectada à área) area area-id authentication (após o comando router ospf ) Exemplo: interface Ethernet0 ip address 10.10.10.10 255.255.255.0 ip ospf authentication-key mypassword router ospf 10 network 10.10.0.0 0.0.255.255 area 0 (note que aqui não é subnet mask, mas a máscara que indica a rede 10.10.0.0/16). area 0 authentication

Message Digest Authentication Autenticação Message Digest é uma autenticação criptográfica. Uma key (senha) e uma key-id são configuradas em cada roteador. O roteador usa um algoritmo baseado no pacote OSPF, a key e a key-id para gerar uma message digest que é adicionada ao pacote no final dele. Ao contrário da autenticação simples, a chave não é trocada entre os roteadores. Um número de seqüência é incluído em cada pacote OSPF para proteção contra ataques de repetição (replay attacks). Este método também permite transições Protocolo de roteamento OSPF – Parte 2

110


sem interrupção entre chaves. Isto é muito útil para administradores que desejam trocar a senha OSPF sem interromper o funcionamento da rede. Se uma interface for configurada com uma nova chave, o roteador enviará múltiplas cópias do mesmo pacote, cada uma com uma chave de autenticação diferente. O roteador irá parar de enviar pacotes duplicados assim que ele detectar que todos os seus vizinhos já adotaram a nova chave. Para habilitar autenticação com message digest use os seguintes comandos: ip ospf message-digest-key key-id md5 key (no modo de configuração da interface conectada à área) area area-id authentication message-digest (após o comando router ospf ) Exemplo: interface Ethernet0 ip address 10.10.10.10 255.255.255.0 ip ospf message-digest-key 10 md5 mypassword router ospf 10 network 10.10.0.0 0.0.255.255 area 0 area 0 authentication message-digest

Backbone OSPF

Backbone OSPF Todas as áreas devem estar conectadas ao backbone O backbone deve ser o ponto de partida do projeto

OSPF tem restrições especiais quando múltiplas áreas estão envolvidas. Se mais de uma área for configurada, uma dessas áreas tem que ser a área 0 (zero). Ela é chamada backbone (espinha dorsal). No projeto de redes, uma boa prática é iniciar com a área 0 e expandir para as outras áreas depois.

O backbone tem que estar no centro de todas as áreas, ou seja, todas as áreas tem que estar fisicamente conectadas ao backbone, porque o OSPF espera que todas as áreas propaguem informações de roteamento para o backbone e este, por sua vez, propagará essas informações para as outras áreas. A figura acima ilustra o fluxo de informação numa rede OSPF. Observe que todas as áreas estão conectadas ao backbone. Quando acontece de uma área nova não poder ser fisicamente conectada ao backbone, um enlace virtual terá que ser configurado. As rotas que têm origem e destino na mesma área são chamadas intra-area routes e são representadas pela letra O na tabela de roteamento IP.


111

Rotas originadas de outras áreas são chamadas inter-area routes ou summary routes e são representadas por O IA na tabela de roteamento IP. Rotas originadas de outros protocolos de roteamento (ou de diferentes processos OSPF) e que são propagadas para o OSPF através de redistribuição são chamadas external routes e são representadas por O E2 ou O E1 na tabela de roteamento IP. Se existirem múltiplas rotas para o mesmo destino, a ordem de preferência é a seguinte: intra-area, inter-area, external E1, external E2. Nota: enlaces virtuais (virtual links) são usados para conectar áreas que não têm conexão física com o backbone. O enlace virtual tem que passar por outra área que sirva de “ponte” entre a área em questão e o backbone. Também podem ser usados para particionamento do backbone. Rotas externas do tipo 2 são aquelas nas quais o custo é sempre o custo externo, independente do custo interno para aquela rota. Rotas externas do tipo 1 são aquelas nas quais o custo é a soma do custo externo com o custo interno para aquela rota. Uma rota do tipo 1 tem sempre preferência sobre uma rota do tipo 2 para o mesmo destino.

Layout dos pacotes OSPF

Layout dos pacotes OSPF (1) 0

Cabeçalho pacote OSPF Version #

78

Checksum

0

Type

15 16

Packet Length

Router ID Area ID

AuType

Authentication Authentication

Pacote Hello (sem o cabeçalho) 15 16

HelloInterval

31

23 24

Network Mask

Options RouterDeadInterval DesignatedRouter BackupDesignatedRouter Neighbor ....

31

Rtr Pri

Todo pacote OSPF começa com um cabeçalho (header) de 24 bytes. O cabeçalho contém toda a informação necessária para determinar se o pacote deve ser aceito para processamento. Os campos do cabeçalho são os seguintes: \\Version

# – Número da versão do OSPF; o RFC2328 especifica a versão 2;

\\Type

– Tipo do pacote OSPF; tipo 1) Hello; tipo 2) descrição do banco de dados (database description); tipo 3) pedido de estado de enlace (Link State Request); tipo 4) atualização de estado de enlace (Link State Update); tipo 5) reconhecimento de estado de enlace (Link State Acknowledgement)

\\Packet

Length – Tamanho do pacote OSPF em bytes, incluindo o cabeçalho padrão;

\\Router \\Area

ID – Identificação do roteador que originou o pacote;

ID – Número de 32 bits que identifica a área à qual este pacote pertence. Todos os pacotes OSPF são associados com uma única área. A


112


maioria atravessa um único hop somente. Pacotes que atravessam um enlace virtual são identificados com 0.0.0.0, que é a identificação da área do backbone (backbone Area ID); \\Checksum

– Soma de verificação padrão do IP a partir do início do cabeçalho do pacote OSPF, exclusive o campo de autenticação de 64 bits. A soma verificadora é considerada parte do processo de autenticação do pacote;

\\AuType

– Identifica o procedimento de autenticação a ser aplicado ao pacote

OSPF; \\Authentication

– Campo de 64 bits para uso do esquema de autenticação.

Pacotes Hello são pacotes OSPF tipo 1. Esses pacotes são enviados periodicamente para todas as interfaces (incluindo enlaces virtuais) com o objetivo de estabelecer e manter relacionamentos de vizinhança. Além disso, pacotes Hello usam endereço multicast nas redes que têm capacidade multicast/broadcast, permitindo a descoberta dinâmica de roteadores vizinhos. Todos os roteadores conectados numa mesma rede têm que negociar certos parâmetros (Network mask, HelloInterval e RouterDeadInterval). Esses parâmetros são incluídos nos pacotes Hello, para que eventuais diferenças não possam impedir a formação de relacionamentos de vizinhança. Os campos do pacote Hello são os seguintes: \\Network

Mask – Máscara de subrede associada a esta interface;

\\HelloInterval \\Options

– Número de segundos decorridos entre os pacotes Hello;

– Opções suportadas pelo roteador;

\\Rtr

Pri – Prioridade deste roteador. Usado na eleição de DR e BDR; se inicializada com 0 (zero), este roteador será inelegível para DR ou BDR;

\\RouterDeadInterval

– Número de segundos decorridos para que se declare um roteador silencioso fora do ar (down);

\\Designated

Router – Identificação do DR desta rede, do ponto de vista do roteador que está enviando o pacote. O DR é identificado aqui pelo endereço IP da sua interface nesta rede. Se for 0.0.0.0, não existe DR;

\\Backup

Designated Router – Identificação do BDR desta rede, do ponto de vista do roteador que está enviando o pacote. O BDR é identificado aqui pelo endereço IP da sua interface nesta rede. Se for 0.0.0.0, não existe BDR;

\\Neighbor

– As identificações (Router IDs) de cada roteador que recebeu pacotes Hello recentemente na rede. Recentemente significa um tempo menor do que o RouterDeadInterval.


113


Pacote de descrição do banco de dados (s/ cabeçalho) Interface MTU

15 16

23 24

Options DD sequence number

31

0 0 0 0 0 I M MS

An LSA Header

0

Cabeçalho do LSA LS age

LS checksum

15 16

23 24

Options Link State ID Advertising Router LS sequence number

LS type

length

31

Pacotes de descrição do banco de dados são pacotes OSPF tipo 2. Esses pacotes são trocados quando uma adjacência está sendo inicializada. Eles descrevem o conteúdo do banco de dados de estado de enlace. O procedimento é do tipo master slave, onde o roteador designado como master envia os pacotes e o outro (slave) recebe e envia reconhecimentos como resposta; as respostas são relacionadas aos pacotes enviados via DD sequence number. Os campos do pacote Database description são os seguintes:

\\Interface

MTU – O tamanho em bytes do maior datagrama IP que pode ser enviado nesta interface, sem fragmentação. No RFC1191, tabela 7-1, há uma lista das MTUs em uso na internet;

\\Options

– Opções suportadas pelo roteador;

\\I-bit

– O bit de Init; quando ligado (valor 1), indica que este pacote é o primeiro da seqüência de pacotes de descrição do banco de dados; os 5 bits anteriores a este precisam ter valor zero;

\\M-bit

– O bit de More; quando ligado (valor 1), indica que mais pacotes de descrição do banco de dados virão em seguida;

\\MS-bit

– O bit Master/Slave; quando ligado (valor 1), indica que este roteador é o master no processo de troca de informações do banco de dados; caso contrário, este roteador é o slave;

\\DD

sequence number – Usado para numerar o conjunto de pacotes de descrição do banco de dados; ele é incrementado a partir do valor único que vai no pacote que tem o bit-I ligado; a partir daí todos os pacotes são numerados até que toda a descrição do banco de dados tenha sido enviada.

O resto do pacote (An LSA Header) é uma lista das partes do banco de dados de estado de enlace. Cada LSA existente no banco de dados é descrito pelo seu cabeçalho. Os campos do cabeçalho do LSA são os seguintes: \\LS

age – O tempo em segundos desde que o LSA foi criado;

\\Options

– As opções suportadas por esta parte do domínio de roteamento;

\\LS

type – O tipo do LSA; cada LSA tem um formato específico. Os tipos são: 1) Router LSAs; 2) Network LSAs; 3) Summary LSAs (IP network); 4) Summary LSAs (ASBR); 5) AS-External_LSAs;

\\Link

State ID – Este campo identifica a porção do ambiente internet (domínio de roteamento) que está sendo descrita neste LSA. O conteúdo depende do


114


tipo de LSA; por exemplo, nos Network LSAs este campo contém o endereço IP da interface do DR da rede; \\Advertising

Router – A Router ID do roteador que originou o LSA; por exemplo, nos Network LSAs este campo contém a Router ID do DR da rede;

\\LS

sequence number – Numera os LSAs para detectar os mais antigos ou duplicados;

\\LS

checksum – A soma verificadora Fletcher do conteúdo completo do LSA, incluindo o cabeçalho LSA, mas excluindo o campo LS age;

\\Length

– O tamanho em bytes do LSA, incluindo os 20 bytes do cabeçalho.


0

Pacote Link State Request (s/ cabeçalho) LS type Link State ID Advertising Router ....

Pacote Link State Update (s/ cabeçalho) # LSAs

31

31

LSAs .... 0

Pacote Link State Acknowledgement (s/ cabeçalho) An LSA Header ....

31

Link State Request (Pedido de Estado de Enlace) são pacotes OSPF do tipo 3. Após a troca de pacotes de descrição de banco de dados com um roteador vizinho, o roteador pode achar que partes do seu banco de dados de estado de enlace estão desatualizadas. Um ou mais pacotes de Pedido de Estado de Enlace são usados para solicitar as partes do banco de dados do vizinho que estejam mais atualizadas. O roteador que solicita essas partes sabe exatamente do que está precisando. Cada parte é identificada pelos campos LS sequence number, LS checksum e LS age.

Cada pedido enviado é identificado pelos campos LS type, Link State ID e Advertising Router, que identifica o LSA, mas não a sua instância. Os pacotes Link State Request são entendidos como pedidos da instância mais recente (seja ela qual for). Os campos deste pacote já foram descritos anteriormente. Pacotes Link State Update (Atualização de Estado de Enlace) são pacotes OSPF tipo 4. Esses pacotes implementam o algoritmo de flooding (inundação) de LSAs. Cada pacote transporta um conjunto de LSAs, um hop além da sua origem. Um pacote pode conter vários LSAs. Os campos do pacote Link State Update são os seguintes: \\#

LSAs – Número de LSAs contidos no pacote. O conteúdo do pacote é uma lista de LSAs, cada um iniciando com um cabeçalho de 20 bytes descrito anteriormente.

\\Link

State Acknowledgement (Reconhecimento de Estado de Enlace) – Pacotes OSPF tipo 5. Para garantir a confiabilidade do processo de flooding, os LSAs enviados são explicitamente reconhecidos. O conteúdo deste pacote é simplesmente uma lista de cabeçalhos LSAs.


6 Sessão de aprendizagem 6 Protocolo de roteamento OSPF – Parte 2 Roteiro de atividades Tópicos e conceitos \\Conceito \\Pacotes

de roteadores de borda e de área de Estado de Enlace

\\Autenticação \\Backbone

OSPF

OSPF

\\Configuração

avançada do protocolo OSPF

Competências técnicas desenvolvidas \\Apresentar

roteadores de borda e de área usando protocolo OSPF

\\Apresentar

características avançadas do protocolo OSPF

\\Configurar

roteadores com protocolo OSPF

\\Considerações

práticas sobre configuração do protocolo OSPF


minutos


116


Atividade 1 – Configuração do protocolo OSPF Área 0 router2 Área 1

ser0 172.16.30.2/24

router0

router1 ser0 172.16.20.1/24

ser0 172.16.20.1/24 eth0 172.16.10.1/24 e1

router4 ser1 ser0 172.16.30.1/24 172.16.50.2/24

ser2 172.16.40.1/24

ser0 172.16.80.2/24

eth0 172.16.90.1/24 e1

ser1 172.16.60.2/24

switch0

eth0 172.16.10.10/24

router5 ser2 172.16.80.1/24

ser1 172.16.60.1/24

ser0 172.16.40.2/24

e0

Área 2

ser1 172.16.50.1/24

switch1 router3

e0 eth0 172.16.90.20/24

pc10

pc11

Esta é a rede de teste RedeTeste2.imn. É composta de 3 áreas: área 0 (backbone), área 1 e área 2. \\A

área 0 tem as redes 172.16.30.0/24, 172.16.40.0/24, 172.16.50.0/24 e 172.16.60.0/24.

\\A

área 1 tem as redes 172.16.10.0/24 e 172.16.20.0/24.

\\A

área 2 tem as redes 172.16.80.0/24 e 172.16.90.0/24.

Os roteadores router1 e router4 são Area Border Router (ABR), os roteadores router0 e router5 são Internal Router e os roteadores router2 e router3 são Backbone Router. 1.

Dar boot no Windows, iniciar o VMware Player, maximizar a janela do VMware Player e só então iniciar a máquina virtual Imunes. Se não maximizar a janela, não será possível visualizar a barra de ferramentas na parte inferior da tela.2. Após iniciar o programa IMUNES, carregue o arquivo de topologia RedeTeste2.imn. Essa rede está representada na figura a seguir. Selecione no menu a opção Experiment/Execute para entrar no modo de execução.

3.

Aponte para o router1, mantenha apertado o botão direito do mouse e selecione a opção Ethereal/ser0 (interface serial0 do roteador).

4.

Para iniciar uma captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture...) e clique nele. Surgirá a tela de opções do Ethereal (Ethereal: capture options); selecione OK. Em seguida, surgirá uma tela onde é mostrado o total de pacotes por protocolo, à medida que são capturados na interface ser0. Minimize essas janelas.


117

5. Para abrir o console do router0, aponte para o router0, mantenha apertado o botão direito do mouse e selecione a opção Shell window/ vtysh. Teremos então a tela que simula o console do roteador router0. 6. O prompt inicial é router0>, que indica que estamos no modo user. Digite enable. Assim teremos o prompt router0#, que indica que estamos no modo privilegiado (padrão Cisco IOS). Neste modo podemos configurar o protocolo OSPF no roteador. Nota: o comando sh ip route deve ser usado para verificar se aparecem as redes diretamente conectadas (C>*). Isto confirma que as interfaces correspondentes do roteador estão ativas. Se não aparecerem as redes diretamente conectadas, significa que houve um erro de inicialização quando foi executada a opção Experiment/Execute no item 2. A operação deve ser feita novamente. Para isso, digite os comandos: \\config


\\router


\\network

172.16.0.0/16 area 1 (informa a rede que será roteada na

área 1). \\Ctrl-Z


A figura mostra o console do router0.

7. Procedimento idêntico deve ser feito no router1, que também pertence à área 1, só que, no caso do router1, ele tem uma interface (ser0 172.16.20.2/24) na área 1, e as outras duas interfaces (ser1 172.16.30.1/24; ser2 172.16.40.1/24) na área 0 (backbone). Os comandos são os seguintes: \\config


\\router


\\network

172.16.20.0/24 area 1 (esta interface está na área 1);

\\network

172.16.30.0/24 area 0 (esta interface está na área 0);


118

Escola Superior de Redes RNP \\network \\Ctrl-Z

172.16.40.0/24 area 0 (esta interface está na área 0).


A figura a seguir mostra o console do router1.

8. Os demais roteadores são configurados conforme mostram as figuras.


119

9. Após a configuração de todos os roteadores, é hora de verificarmos o funcionamento dos mesmos. Para isso, podemos usar dois comandos: \\sh

ip route (mostra todas as rotas IP aprendidas pelo roteador);

\\sh

ip ospf (mostra os dados do protocolo OSPF).

As telas a seguir mostram, para cada roteador, ambos os comandos.

Observe que as rotas OSPF aparecem com distância administrativa 110 (default OSPF) e custo proporcional ao percurso para atingir a rede em questão. Aparecem também o Next Hop e a interface de saída. Nesta tela podemos verificar que o router0 aprendeu as rotas para todas as redes.



120

Observe que o Router ID do router0 é o endereço IP mais alto de suas interfaces, no caso, o endereço 172.16.20.1 da interface serial 0 (ser0). A tela também diz que esta implementação (quagga software) está em conformidade com o RFC 2328. Em seguida são mostrados os dados do roteador na área 1 a que ele pertence.

Observe que no caso do router1, existem rotas alternativas com o mesmo custo [110/30] para a rede 80 e para a rede 90 [110/40], que pode ser confirmado pela análise da topologia da rede.


121

Observe que o router1 é um Area Border Router (ABR), porque tem interfaces nas áreas 1 e 0. Também são mostrados os dados de ambas as áreas OSPF, inclusive os roteadores adjacentes em cada área.



Os roteadores router2 e router3 têm configurações idênticas, porque ambos estão no backbone e são Internal Router do backbone (Backbone Router).


122

123

A configuração do router4 é semelhante a do router1.


124


O router5 tem configuração semelhante à do router0, porque ambos são Internal Router. Nota: se algum roteador não tiver ativado as suas interfaces e, mesmo após a repetição da operação de inicialização do item 2, o problema não se resolver, a solução mais simples é configurar manualmente no modo de execução as interfaces do roteador. Exemplo: suponha que o router0 não ativou suas interfaces. Digite os comandos: \\config \\int \\ip

t

eth0 address 172.16.10.1/24

\\quit \\int \\ip

ser0 address 172.16.20.1/24

\\Ctrl-Z

Verifique novamente as interfaces com os comandos: \\sh

run

\\sh

ip route

Para os demais roteadores, se for o caso, digite comandos similares, de acordo com as interfaces.


125

10. Volte na janela de captura do Ethereal e, conforme orientação do instrutor, vá à tela de total de pacotes e clique em STOP. Isto encerra a captura e mostra automaticamente a tela a seguir com todos os pacotes capturados. Esta tela pode variar um pouco de computador para computador, em função do tempo que se levou para digitar os comandos de configuração em todos os roteadores, da ordem em que os roteadores foram configurados e do tempo de captura.

Observe que o pacote 2 está destacado. É um pacote Hello enviado pelo router0 (interface 172.16.20.1) pertencente à área 1. Essas informações estão no cabeçalho do OSPF (OSPF Header). No corpo do pacote propriamente dito podemos ver a máscara de subrede (255.255.255.0), o intervalo de envio de pacotes Hello (10 segundos), o temporizador Router Dead Interval (40 segundos), e constatar que ainda não foram escolhidos os DR e BRD. Os pacotes mostrados aqui foram capturados na interface serial 0 do router1. Entre os demais roteadores foram trocados pacotes semelhantes.



126

11. Na próxima figura vemos em destaque o pacote 23, que é um pacote de descrição de banco de dados (DB Description), no qual temos dois tipos de LSA: Router-LSA e Summary-LSA. Ambos foram anunciados pelo roteador router1, interface serial 1, endereço IP 172.16.30.1.


127

12. Na próxima figura vemos em destaque o pacote 30, que é um pacote LS Update (Atualização de Estado de Enlace) enviado pelo router0 pela interface serial 0 de endereço IP 172.16.20.1, tipo Router-LSA, anunciando rota para duas redes: 172.16.10.0 e 172.16.20.0.



128

13. Na próxima figura vemos em destaque o pacote 52, que é um pacote LS Update (Atualização de Estado de Enlace) enviado pelo router1 pela interface serial 0 de endereço IP 172.16.20.2, tipo Router-LSA, anunciando o enlace 172.16.40.1. Ainda nesse pacote é anunciado o enlace tipo 2 — conexão para uma rede de trânsito, e informado o endereço do Roteador Designado (DR): 172.16.20.1.


129

14. Na próxima figura vemos em destaque o pacote 61, que é um pacote Hello enviado pelo router1 pela interface serial 0 de endereço IP 172.16.20.2, informando o DR, BDR e um vizinho ativo.

15. Na próxima figura vemos o console do pc10, no qual digitamos os comandos ping e traceroute para o pc11, que fica do outro lado da rede. Podemos ver que ambos foram bemsucedidos, indicando completa conectividade através de toda a rede.



130

16. Na próxima figura vemos o console do pc11 no qual digitamos os comandos ping e traceroute para o pc10, que fica do outro lado da rede. Esta é a operação no sentido inverso da anterior. Podemos ver que foram ambos bem-sucedidos, indicando completa conectividade através de toda a rede, não importando o sentido da comunicação. Observe que os endereços das interfaces dos roteadores são diferentes no traceroute, dependendo do sentido da rota. Isto acontece porque a aplicação informa o endereço da interface que respondeu com a mensagem ICMP de tempo expirado em trânsito, que sempre será a interface de entrada no roteador.


7 Sessão de aprendizagem 7 Protocolo de roteamento BGP – Parte 1 Sumário da sessão Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Border Gateway Protocol BGP-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Glossário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Vizinhos e pares BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Atributos do BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Configuração BGP – Roteadores Cisco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Configuração BGP – Simulador Zebra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Atividade 1 – Configuração do protocolo BGP. . . . . . . . . . . . . . . . . . . . . . . . . 148

132


Histórico

Histórico Roteamento interno – IGP (Interior Gateway Protocol) RIP, OSPF, IS-IS, IGRP, EIGRP Roteamento externo – EGP (Exterior Gateway Protocol) BGP-4 (RFC 4271) Backbone Arpanet Core router Non-core router Gateway to Gateway Protocol (GGP)

Os roteadores utilizados para trocar informações dentro de Sistemas Autônomos são chamados de roteadores internos (interior routers) e podem utilizar uma variedade de protocolos de roteamento interno (Interior Gateway Protocols – IGPs). Dentre eles estão: RIP, OSPF, IS-IS, IGRP e EIGRP. Os dois primeiros são padronizados pelo IETF (RFCs), e já foram vistos nas unidades anteriores. O IS-IS (ISO 10589) é um protocolo padrão do modelo OSI. Os protocolos IGRP e EIGRP são proprietários da Cisco.

Roteadores que trocam dados entre Sistemas Autônomos são chamados de roteadores externos (exterior routers) e utilizam o Exterior Gateway Protocol (EGP) ou o BGP (Border Gateway Protocol). Para este tipo de roteamento são consideradas basicamente coleções de prefixos Classless Inter Domain Routing (CIDR), identificados pelo número de um Sistema Autônomo. O BGP (RFCs 4271, 1772, 1773, 1930, 1997, 2119, 2858, 3065, 4456), assim como o EGP, é um protocolo de roteamento inter-domínios, criado para uso nos roteadores principais da internet. O BGP foi projetado para evitar loops de roteamento em topologias arbitrárias, que era o problema mais sério de seu antecessor, o EGP (Exterior Gateway Protocol). Outro problema que o EGP não resolve — e é abordado pelo BGP — é o do roteamento baseado em política (policy-based routing), um roteamento com base em um conjunto de regras não-técnicas, definidas pelos Sistemas Autônomos. A última versão do BGP, o BGP4, foi projetada para suportar os problemas causados pelo grande crescimento da internet. Parafraseando o Dr. Douglas E. Comer, o BGP-4 é “a cola que mantém a internet unida e permite a interconexão universal” atualmente. O BGP-4 possibilita o intercâmbio de informações de roteamento entre os diversos sistemas autônomos, ou ASs (Autonomous Systems), que em conjunto formam a internet. Explicando de uma forma simplificada: ele permite que os dados trafeguem entre os ASs até chegar ao AS de destino, e dentro dele siga até o seu destino final (host). A seguir vamos rever um breve histórico da criação da internet, com o objetivo de justificar a necessidade do protocolo BGP-4. Há alguns anos, quando o principal backbone da internet era a Arpanet, as instituições de pesquisa conectadas à rede precisavam gerenciar manualmente as tabelas de rotas para todos os possíveis destinos, ou seja, todas as outras redes Roteamento avançado – Sessão de aprendizagem 7

133

conectadas. Com o crescimento da internet, verificou-se que era impraticável manter todas as tabelas atualizadas dessa forma, e que eram necessários mecanismos de atualização automática. Os pesquisadores da internet optaram, então, por usar uma arquitetura que consistia de um reduzido e centralizado grupo de roteadores (core routers) que tinham, em suas tabelas, as rotas para todos os possíveis destinos da internet; e um outro grupo maior de roteadores que possuíam em suas tabelas apenas informações (rotas) parciais, e não para toda a internet. Os core routers eram administrados pelo Internet Network Operations Center (INOC), e o grupo maior de roteadores externos ficou conhecido pelo termo noncore routers (roteadores fora do núcleo), que conectavam as redes locais das instituições de pesquisa ao backbone da Arpanet. Foi desenvolvido, então, o protocolo Gateway-to-Gateway Protocol (GGP), que foi usado nos core routers para atualização automática das tabelas de rotas entre eles. O GGP era um protocolo baseado no algoritmo de vetor de distância (Vector-Distance, também conhecido como Bellman-Ford). Essa arquitetura tem, tecnicamente, graves pontos fracos, principalmente com relação a sua capacidade de expansão, e a internet acabou crescendo muito, indo além de um único backbone gerenciado de forma centralizada. Verificou-se, portanto, não ser possível expandir esse backbone arbitrariamente, pelas diversas limitações técnicas. Como o backbone de cada site pode ter uma estrutura complexa, o esquema de core routers não iria conseguir conectar todas as redes diretamente. Era necessário um novo esquema que permitisse aos noncore routers passar informações aos core routers sobre as redes que estavam “atrás” deles, além de oferecer autonomia de gerenciamento aos sites. Até o momento, estava sendo usado o conceito de interconexão que levava em conta apenas a arquitetura do roteamento em uma internet e não contemplava as questões administrativas envolvidas. Os projetistas notaram que as interconexões de um backbone com arquitetura complexa não devem ser encaradas como várias redes independentes conectadas a uma internet, mas como uma organização que controla várias redes e garante que as informações sobre as rotas internas são consistentes, e que pode escolher um de seus roteadores para fazer a ponte de comunicação para o “mundo exterior”.

Histórico (cont.) Sistemas autônomos Exemplos de AS

Entra em cena o conceito do Sistema Autônomo (Autonomous Systems – AS), no qual as redes e roteadores estão sob o controle de uma mesma entidade administrativa. Esse conceito substitui a idéia das redes locais conectadas ao backbone central. Cada AS tem a liberdade de escolher o esquema e a arquitetura mais adequados para si para descobrir, propagar, validar e verificar a consistência das suas rotas internas e a responsabilidade de anunciar Protocolo de roteamento BGP – Parte 1

134

Escola Superior de Redes RNP para os outros ASs as rotas para suas redes internas invisíveis. A figura acima ilustra o conceito de Sistema Autônomo (AS 1900).

Para anunciar as rotas para suas redes internas entre si, os ASs precisavam concordar em usar um esquema único, como um mesmo idioma por toda a internet. Para permitir que um algoritmo de roteamento automatizado pudesse distinguir entre um AS e outro, foi designado a cada AS um número (Autonomous System Number – ASN) por uma autoridade central, a Internet Assigned Numbers Authority – IANA (http://www.iana.org/) encarregada de atribuir todos os endereços identificadores das redes conectadas à internet. A figura do backbone da National System Foundation Network (NSFnet) ilustra a interconexão de ASs.

Histórico (cont.) Exterior Gateway Protocol – EGP Vizinhos internos Vizinhos externos Problemas Loops de roteamento Pouca flexibilidade para políticas de roteamento

Dois roteadores que pertençam ao mesmo AS são considerados “vizinhos internos” (interior neighbors). Se ambos pertencerem a ASs diferentes e trocarem informações de roteamento entre si, são considerados “vizinhos externos” (exterior neighbors). O protocolo de roteamento usado pelos exterior neighbors é o Exterior Gateway Protocol ou simplesmente EGP (RFC 904). É ele que permite o anúncio das rotas para as redes internas do AS para o núcleo (core) da internet, como mostra a figura acima.

Com o tempo, o EGP apresentou diversas limitações técnicas e potenciais problemas ao ser usado na internet. Apesar das tentativas para produzir novas versões (EGP2 e EGP3) do protocolo, os projetistas não obtiveram sucesso, por haver a necessidade de muitas alterações fundamentais na estrutura do mesmo. O EGP apresentou deficiências insustentáveis, como restrições em topologia, incapacidade de evitar loops de roteamento e pouca flexibilidade para a configuração de políticas de roteamento. Um grande desafio para os projetistas era transformar uma arquitetura internet que não dependesse de um sistema centralizado (core routers), deixando uma topologia organizada hierarquicamente e iniciando outra com estrutura diferente. Além disso, tinha o desafio de fazer uma arquitetura internet suportar uma forma de colaboração mais próxima entre certos ASs do que entre outros. Isso levou os engenheiros do IETF a desenvolverem uma solução para esses problemas através de um novo, mais moderno e mais robusto protocolo de roteamento externo, como veremos a seguir.


135

Border Gateway Protocol BGP-4

Border Gateway Protocol BGP-4 Sucessor do EGP Roteamento entre ASs Suporta CIDR Interage com IGPs: RIP, OSPF etc. Usa TCP porta 179 Estabelecimento de uma sessão BGP Estabelecimento da conexão TCP entre os roteadores Envio da tabela de rotas completa só uma vez Atualização parcial da tabela (incremental) Mensagens de keepalive para manter a sessão aberta

O BGP é um protocolo de roteamento para ser usado entre múltiplos sistemas autônomos em redes baseadas no protocolo TCP/IP. O BGP-4 (RFCs 4271, 1772) tornou-se o sucessor natural do EGP, efetivamente atacando suas deficiências mais sérias, ou seja, evitando loops de roteamento e permitindo o uso de políticas de roteamento entre ASs baseadas em regras arbitrárias por eles definidas. Além disso, o BGP-4 foi a primeira versão do BGP a suportar endereços agregados (Classless Interdomain Routing, ou simplesmente CIDR) e o conceito de supernets.

O protocolo BGP-4 assume que o roteamento interno do AS é feito através de um sistema IGP (Interior Gateway Protocol) de roteamento interno. Este pode ser um protocolo de roteamento como o RIP, OSPF, IGRP, EIGRP; ou até mesmo através de rotas estáticas. O BGP constrói um gráfico dos ASs, usando as informações trocadas pelos “vizinhos BGP” (BGP neighbors), que são compostas dos números identificadores dos ASs, os ASN. A conexão entre ASs forma um “caminho” (path), e a coleção desses caminhos acaba formando uma rota composta pelos números dos ASs que devem ser percorridos até se chegar a um determinado AS de destino. O BGP faz uso do TCP (porta 179) para o transporte das informações de roteamento, de modo que ele próprio não precisa preocupar-se com a correta transmissão das informações. Outra característica do BGP-4 é a atualização das tabelas de rotas feitas de forma incremental, como nos algoritmos de estado de enlace. A atualização completa da tabela de rotas é feita somente uma vez, quando se estabelece a sessão entre os neighbors ou peers. Para o estabelecimento de uma sessão BGP entre neighbors ou peers, basicamente, os seguintes passos são executados: \\É

estabelecida a conexão TCP entre os dois roteadores que trocam mensagens de abertura da sessão e negociam os parâmetros de operação;

\\O

primeiro fluxo de dados transmitido é a tabela completa de rotas BGP. Atualizações posteriores são feitas nesta tabela, incrementalmente, à medida que as mudanças ocorrem;

\\Como

não há a atualização completa da tabela após a primeira atualização, o roteador mantém a informação da versão da tabela que todos os seus peers possuem, enquanto durar a sessão entre eles. Se esta for interrompida por qualquer motivo, o processo é iniciado novamente a partir do primeiro passo;

\\Mensagens

aberta; Protocolo de roteamento BGP – Parte 1

de keepalive são enviadas periodicamente para manter a sessão

136

Escola Superior de Redes RNP \\Mensagens

de aviso são enviadas quando ocorrem erros ou outras situações

especiais; \\Caso

uma conexão verifique um erro, uma mensagem é enviada e a conexão fechada, encerrando a sessão.

Basicamente, o BGP serve para informar às redes externas a um AS quais são as rotas para redes atingíveis dentro de sua rede. Falando de outra forma: o propósito do BGP-4 é anunciar rotas para outras redes externas ou sistemas autônomos. Esses anúncios são como “garantias” de que os dados serão transportados para o espaço IP representado pela rota anunciada. Se, por exemplo, um AS anunciar uma rota para 192.168.4.0/24 (na sintaxe anterior ao CIDR, este endereço é a classe C que começa em 192.168.4.0 e termina em 192.168.4.255), e alguém enviar dados destinados a qualquer endereço dentro dessa faixa, esse AS estará “garantindo” que sabe enviar os dados até o destino.

Glossário

Glossário Adj-RIB-In Adj-RIB-Out Autonomous System (AS) BGP Identifier BGP speaker EBGP External peer Feasible route

IBGP Internal peer IGP Loc-RIB NLRI Route RIB Unfeasible route

A seguir veremos definições dos termos usados no protocolo BGP:

\\Adj-RIB-In

– Contém informações de roteamento não processadas que foram anunciadas ao BGP speaker local por seus pares;

\\Adj-RIB-Out

– Contém as rotas para anúncio a pares específicos, por meio das mensagens de UPDATE (atualização) do speaker local;

\\Autonomous

System (AS) – A definição clássica de Sistema Autônomo é um conjunto de roteadores sob uma administração técnica única, usando um protocolo interior (IGP) e métricas comuns para determinar a forma de rotear pacotes dentro do AS, e usando um protocolo de roteamento inter-AS para determinar o modo de rotear pacotes para outros ASs. Desde o surgimento desta definição clássica tem sido comum a utilização de diversos IGPs num único AS e, algumas vezes, vários conjuntos de métricas dentro do AS. O uso do termo AS implica que, mesmo quando múltiplos IGPs e métricas são usados, a administração de um AS aparece para os outros ASs com um único e coerente plano de roteamento interior, e apresenta um conjunto consistente dos destinos alcançáveis através dele;

\\BGP

Identifier – Um número inteiro positivo de 4 octetos que indica a identificação do BGP que enviou as mensagens BGP. Um dado BGP speaker define o valor do seu identificador BGP como um endereço IP atribuído ao próprio BGP speaker. O valor do identificador BGP é determinado no início da operação, e é o mesmo para cada interface local e par BGP;


137

\\BGP

speaker – Um roteador que implementa o protocolo BGP;

\\EBGP

– BGP externo (uma conexão BGP entre pares externos);

\\External

peer – Par que pertence a um AS diferente do sistema local;

\\Feasible

route – Uma rota anunciada que está disponível para uso do roteador;

\\IBGP

– BGP interno (uma conexão BGP entre pares internos);

\\Internal

peer – Par que está no mesmo AS que o sistema local;

– Protocolo de gateway interior, um protocolo de roteamento usado para trocar informações de roteamento entre roteadores dentro de um único AS;

\\IGP

\\Loc-RIB

– Contém as rotas selecionadas pelo processo de decisão do BGP speaker local;

\\Network

Layer Reachability Information (NLRI) – Informação de Alcance da Camada de Rede. Informa as redes alcançáveis conhecidas por este AS;

\\Route

– Uma unidade de informação composta de um conjunto de destinos com os atributos do caminho (path) para aqueles destinos. O conjunto de destinos é formado por sistemas cujos endereços IP estão contidos num prefixo de endereço IP que faz parte do campo NLRI de uma mensagem de UPDATE. O caminho (path) é a informação contida no campo de atributos de caminho (path attibutes) da mesma mensagem de UPDATE;

\\RIB

– Routing Information Base (ver ref. 2 na bibliografia abaixo);

\\Unfeasible

route – Uma rota previamente anunciada como viável, que não está mais disponível para uso.

Todos esses termos são importantes para o correto entendimento do funcionamento do protocolo BGP. Nem todas as características do protocolo BGP serão abordadas aqui, mesmo porque é um assunto que foge do escopo deste curso. Para aqueles que têm a tarefa de administrar redes BGP, recomendamos as seguintes leituras: \\BGP

Fundamentals: http://www.riverstonenet.com/support/bgp/fundamentals/index.htm

\\RS

Routing Model: http://www.riverstonenet.com/support/bgp/routing-model/index.htm

\\Path

attributes: http://www.riverstonenet.com/support/bgp/fundamentals/attributes.htm#_ Path_Attributes

\\O

protocolo BGP-4 – Parte 1: http://www.rnp.br/newsgen/9903/bgp4.html

\\O

protocolo BGP-4 – Parte 2: http://www.rnp.br/newsgen/9905/bgp4p2.html

Protocolo de roteamento BGP – Parte 1

138

Escola Superior de Redes RNP \\O

protocolo BGP-4 – Parte 3 (final): http://www.rnp.br/newsgen/9907/pgbp4p3.html

\\Dicas

na Configuração do Protocolo BGP-4 – Parte 1: http://www.rnp.br/newsgen/0101/bgp4-dicas.html

\\Dicas

na Configuração do Protocolo BGP-4 (final): http://www.rnp.br/newsgen/0109/bgp4_dicas2.html

\\Network

Protocols Configuration Guide, Part 1 (htm e pdf): http://www.cisco.com/univercd/cc/td/doc/product/software/ ios113ed/113ed_cr/np1_c/1cbgp.htm

\\RFC

4271

Vizinhos e pares BGP

Vizinhos e pares BGP

Sistemas (roteadores) que são “vizinhos BGP” (BGP neighbors) comunicam-se através de “sessões TCP” estabelecidas entre eles. Os roteadores de borda (border routers) de ASs vizinhos são considerados peers (pares). Esses pares são as “fronteiras políticas” dos ASs, que trocam tráfego de acordo com as regras definidas pelos ASs participantes. São chamados neighbors os sistemas BGP (roteadores) que possuem sessões BGP estabelecidas entre eles. Então, os roteadores de borda são neighbors? Sim. Porém, quando uma importância política é atribuída a eles, a forma correta de chamá-los é de peers, enquanto que os neighbors são quaisquer vizinhos BGP. Existem outras situações em que os vizinhos BGP não são, obrigatoriamente, os roteadores entre ASs, e sim roteadores do mesmo AS. Neste caso, as sessões estabelecidas entre eles acontecem internamente ao AS. O que permite isso é o iBGP ou internal BGP, que permite a troca de rotas no mesmo AS. De forma análoga, a troca de rotas entre ASs é feita pelo eBGP (exterior BGP). Um importante conceito do iBGP é que os neighbors não têm a obrigação de estarem diretamente conectados (como na figura acima) através de uma linha serial ou via interface Ethernet, por exemplo. Os peers, por outro lado, não podem estar conectados de outra forma que não seja a direta, seja link serial ou interface Ethernet. O algoritmo do eBGP trabalha, basicamente, anunciando todas as rotas que conhece, enquanto o do iBGP faz o possível para não anunciar rotas. Assim, para fazer o iBGP funcionar adequadamente dentro de um AS é necessário estabelecer sessões BGP entre todos os roteadores que “falam” iBGP (AS 4200), formando uma “malha completa” (full mesh) de sessões iBGP dentro do AS.


139

Atributos do BGP

Atributos do BGP Controlam informações relativas a rotas Usados pelo algoritmo para tomada de decisões AS_path Next hop Local preference Multi-Exit Discriminator (MED) Origin Atomic Aggregator Aggregator Community Weight

A seguir são descritos alguns dos atributos do BGP. Para conhecer todos os atributos, ver RFC 4271. \\AS_path

– É uma seqüência de ASNs que uma rota cruza para alcançar uma determinada rede de destino. O AS que origina uma rota acrescenta seu ASN ao anunciar uma rota sua para seus vizinhos BGP externos. Daí para frente, cada AS que receber a rota acrescenta seu próprio ASN no início da seqüência de ASNs, e repassa a rota para outros peers seus, que farão o mesmo. A lista final vai representar todos os ASNs que uma rota atravessou com o ASN do AS de origem da rota no final da seqüência, também conhecida como AS_Sequence. Caso um AS receba um anúncio de rota que contenha seu próprio ASN na seqüência inclusa no AS_PATH, este anúncio será rejeitado e descartado, garantindo que não haverá loop de roteamento na tabela BGP desse AS. Caso o AS_PATH seja anunciado para um vizinho do mesmo AS, a informação contida no AS_PATH não é alterada. A informação contida no AS_PATH é uma das informações usadas no processo de seleção da melhor rota para determinado destino. Ao comparar duas rotas para um mesmo destino (considerando que os outros atributos sejam idênticos), o BGP vai preferir a que possuir o AS_PATH menor. Caso o caminho (path) seja do mesmo tamanho, o BGP vai usar outros atributos para fazer a sua escolha da melhor rota;

\\Next

hop – Basicamente, este atributo recebe o endereço IP da interface do próximo roteador — próximo salto (next hop) a ser dado — para alcançar determinado destino. Existem três situações diferentes que determinam o NEXT_HOP: 1. Em sessões eBGP, o NEXT_HOP será sempre o IP de um roteador de borda (peer BGP) de um AS vizinho que originou a rota; 2. Em sessões iBGP onde a rota foi originada dentro do AS, o NEXT_HOP será o endereço IP do vizinho que anunciou a rota originalmente; 3. O NEXT_HOP aprendido pelo eBGP não é alterado pelo iBGP, permanecendo o endereço IP do peer eBGP que originou o anúncio da rota. Quando a rota é anunciada em mídias de multiacesso (como Ethernet e Frame Relay), o NEXT_HOP geralmente é o endereço IP da interface do roteador conectada à mídia que originou a rota. Existem ainda outras regras definidas pelo RFC 4271;

\\Local

preference – Este atributo serve para anunciar o caminho preferencial de saída (de pacotes) para uma determinada rota, destinada a uma rede externa ao AS. Como o próprio nome do atributo sugere, o LOCAL_PREF somente é anunciado (repassado) entre os roteadores vizinhos BGP (iBGP) do mesmo AS, e não é repassado aos roteadores vizinhos externos (eBGP).


140

Escola Superior de Redes RNP Caminhos (paths) que possuem o LOCAL_PREF com maior valor são preferidos pelo BGP. O valor padrão do LOCAL_PREF é 100; \\Multi-Exit

Discriminator (MED) – Este atributo tem como finalidade informar para os vizinhos BGP externos (peers) o melhor caminho (path) para uma determinada rota do próprio AS, influenciando-os, assim, em relação ao caminho que deve ser seguido no caso do AS possuir diversos pontos de entrada. O MED é anunciado somente entre ASs. Porém, só o AS de origem pode fazer anúncios com valores neste atributo, enquanto um AS vizinho que receba o atributo via mensagem UPDATE não pode repassar o valor deste atributo a outros ASs, fazendo uso dos mesmos apenas para tomadas de decisão internas ao AS;

\\Origin

– Indica a origem do anúncio de rota, ou NLRI (que indica o prefixo e a máscara de bits), com relação ao AS que o originou. Pode conter um dos valores: \\0

IGP – A origem é interna ao AS originário da mensagem (indicado por um i na tabela de rotas), seja ela recebida através da redistribuição das rotas do IGP para o BGP (daquele AS) ou pela simples configuração do BGP naquele roteador.

\\1

EGP – A origem é de um AS externo e foi recebida por um anúncio de um EGP. É identificada por um e na tabela de rotas. Este tipo de entrada dificilmente será vista nas tabelas de rotas atualmente.

\\INCOMPLETE

– A NLRI é desconhecida ou aprendida por outros meios (além dos citados acima). Geralmente acontece quando uma rota estática (configurada manualmente por um operador) é redistribuída no BGP e a origem da rota fica incompleta. É indicada por um ? na tabela de rotas;

\\Atomic

Aggregator – Este atributo é usado por um roteador que, ao ter que selecionar uma rota dentre outras — recebidas de seu peer — que se sobrepõem, escolhe uma, ignorando a mais específica. Então, ele deve incluir o atributo ATOMIC_AGGREGATE à rota quando for propagá-la a seus vizinhos (caso o atributo ainda não esteja presente na rota menos específica recebida). Um roteador que receba uma rota com o atributo ATOMIC_AGGREGATE não deve removê-lo e não deve fazer nenhum NLRI da rota mais específica quando for propagar a rota aos vizinhos BGP. Ele precisa também reconhecer que o caminho atual para os destinos (como especificado no campo NLRI da rota), respeitando a ausência de loops de roteamento, pode cruzar ASs que não estejam listados no AS_PATH. Uma outra observação importante: não é possível agregar um endereço sem ter uma rota mais específica daquele endereço na tabela de roteamento. Por exemplo: um roteador não pode gerar uma rota agregada para 160.0.0.0 sem possuir previamente uma rota de 160.0.0.0 em sua tabela de roteamento;

\\Aggregator

– Este atributo pode ser incluído em mensagens UPDATE formadas por agregação. O atributo AGGREGATOR contém o ASN do último roteador que formou uma rota agregada, seguido de seu próprio ASN e endereço IP;


141

\\Community

– Este atributo é usado para representar um agrupamento de destinos que compartilhem uma ou mais características, não sendo estas restritas a um mesmo AS, rede ou conjunto de redes. As delimitações do agrupamento são políticas, podendo envolver mais de um AS, inclusive. As comunidades (communities) podem ser compostas de diversas redes pertencentes a qualquer AS, usadas para simplificar políticas de roteamento, identificando rotas por algum parâmetro lógico ao invés de por prefixos CIDR ou ASNs. Usando esses atributos, um roteador pode combiná-los com outros para determinar, para cada comunidade, quais rotas devem ser aceitas, descartadas, preferidas ou repassadas para outros vizinhos. O valor deste atributo pode estar entre 0 (zero) e 4.294.967.200, e consiste de conjuntos de valores de 4 bytes;

\\Weight

– Definido pela Cisco Systems, o WEIGHT não é propriamente um atributo BGP. Ele influencia no processo de seleção da melhor rota do roteador onde for definido e, como é um atributo local ao roteador, não é repassado e nem propagado aos seus vizinhos nas mensagens de UPDATE. O WEIGHT é um valor decimal localizado entre 0 e 65535, sendo o valor padrão igual a 32768, assumido para rotas originadas pelo roteador. Outras rotas possuem o WEIGHT igual a 0 (zero), por padrão. Havendo mais de uma rota possível para um mesmo destino, o BGP-4 seleciona a que possuir o atributo WEIGHT com maior valor. Este atributo é comumente usado pelos operadores de redes para influenciar o processo de escolha de rotas do BGP.

Configuração BGP – Roteadores Cisco Configuração básica Enable BGP Routing (obrigatório) BGP Neighbors (obrigatório) BGP Soft Reconfiguration Reset BGP Connections BGP Interactions with IGPs BGP Route Filtering by Neighbor BGP Path Filtering by Neighbor Disable Next-Hop Processing on BGP Updates BGP Version Multi Exit Discriminator Metric (MED)

Configuração BGP – Roteadores Cisco A configuração do protocolo BGP pode ser dividida em configuração básica e avançada. As duas primeiras tarefas da configuração básica são obrigatórias e as demais, bem como as tarefas da configuração avançada, são opcionais. A seguir descrevemos cada tarefa da configuração básica e sua implementação em roteadores Cisco: \\Enable

BGP Routing – Para habilitar o roteamento BGP, use os seguintes comandos no modo de configuração global no console do roteador:

1. router bgp , onde é o número do Sistema Autônomo; 2. network mask route-map O primeiro comando estabelece um processo de roteamento BGP no AS indicado. O segundo comando indica que esta rede é local a este AS e a coloca na tabela BGP. A máscara de rede permite subnetting e supernetting; \\BGP

Neighbors – É necessário configurar os vizinhos BGP manualmente. BGP suporta dois tipos de vizinhos:



142

1. Vizinhos externos que residem em diferentes ASs e, normalmente, são adjacentes e compartilham uma subrede; 2. Vizinhos internos que residem em qualquer lugar do mesmo AS, não sendo necessariamente adjacentes. Para isso, use o seguinte comando no modo de configuração de roteador: neighbor {ip-address|peer-group-name} remote-as , onde o primeiro parâmetro especifica o endereço IP do vizinho ou o nome do grupo par (peer-group-name) ao qual ele pertence, e o segundo parâmetro especifica o número do AS remoto (se for um vizinho remoto); \\BGP

Soft Reconfiguration – Sempre que houver uma modificação na política de roteamento, a sessão BGP tem que ser encerrada e reiniciada para que as alterações tenham efeito. Isto provoca um tremendo impacto na operação das redes. Para permitir que as políticas possam ser modificadas e ativadas sem encerrar as sessões BGP usa-se esta opção, que deve ser configurada para cada vizinho. O comando é: neighbor {ip-address|peer-groupname} soft-reconfiguration inbound;

\\Reset

BGP Connections – Sempre que dois roteadores forem definidos como vizinhos, eles estabelecerão uma conexão BGP e trocarão informações de roteamento. Se, posteriormente, forem feitas alterações de filtro BGP, peso (weight), distância, versão ou outras alterações similares, a conexão BGP deve sofrer um reset para que as alterações tenham efeito. Qualquer um dos dois comandos a seguir pode ser usado: 1. Clear ip bgp
, dá reset numa conexão BGP específica; 2. Clear ip bgp *, dá reset em todas as conexões BGP.

\\BGP

Interactions with IGPs – Se o seu AS estiver conduzindo tráfego de um AS para outro AS, é importante que o protocolo BGP esteja sincronizado com o protocolo IGP do seu AS, para que as rotas anunciadas sejam consistentes. A sincronização BGP/IGP é habilitada por default; porém, nos casos em que o seu AS não conduz tráfego de um AS para outro, não há necessidade dessa sincronização. Para desabilitá-la use o comando no synchronization. Também é preciso dar reset nas conexões BGP;

\\BGP

Route Filtering by neighbor – É possível filtrar os anúncios de rotas BGP de duas maneiras: 1. através de filtros de trajetória de AS (AS-path) usando os comandos ip as-path access-list e neighbor filter-list; 2. Usando listas de acesso ou de prefixo com o comando neighbor distributelist, cujo formato é: neighbor {ip-address|peer-group-name} distribute-list {access-list-number|name} {in|out};

\\BGP

Path Filtering by neighbor – Além da filtragem das atualizações de roteamento baseado nos números de redes, é possível especificar um filtro de lista de acesso em ambas as atualizações (de entrada e saída) baseado nas trajetórias BGP do AS. Cada filtro é uma lista de acesso. Na configuração de


143

filtragem BGP são usados os comandos (iniciando no modo de configuração global): 1. ip as-path access-list access-list-number {permit|deny} as-regular-expression, onde o parâmetro as-regular-expression permite complexas manipulações de filtros (ver bibliografia para exemplos); 2. router bgp ; 3. neighbor {ip-address|peer-group-name} filter-list access-list-number|name {in|out}; \\Disable

Next-Hop Processing on BGP Updates – O IOS Cisco pode ser configurado para desabilitar o processamento do próximo hop (Next-Hop Processing) nas atualizações BGP (BGP Updates). Isto é útil em redes Frame Relay e X.25 que possuem topologia em malha parcialmente ligada, onde os vizinhos BGP não têm acesso direto a todos os outros vizinhos na mesma subrede. Há duas maneiras de fazer isso: 1. neighbor {ip-address|peer-group-name} next-hop-self faz com que o roteador corrente anuncie a si mesmo como o próximo hop para o vizinho especificado; todos os demais roteadores enviarão para este roteador os pacotes ao invés de enviar para o vizinho especificado, e este roteador se encarregará de encaminhá-los; 2. set ip next-hop ip-address [...ip-address] [peeraddress] especifica que o próximo hop é o endereço IP do par remoto (remote peer).

\\BGP

Version – Por default, a versão do BGP é a 4. Se necessário, o BGP negocia a operação em versões anteriores. Para impedir a negociação e forçar o uso específico de uma versão, use o comando neighbor {ip-address|peer-group-name} version value;

\\Multi

Exit Discriminator Metric (MED) – BGP usa esta métrica para indicar aos vizinhos externos as trajetórias preferidas. O comando é default-metric number.

Configuração BGP – Simulador Zebra BGP router BGP route Route Aggregation Redistribute to BGP Defining Peer Group Defining Peer BGP Peer neighbor Show IP BGP


Configuração BGP – Simulador Zebra Os comandos a seguir se referem ao simulador Zebra usado pelo IMUNES. Ver bibliografia para mais informações. \\BGP

router – É preciso primeiro configurar o roteador BGP definindo o número do AS onde ele reside. O número do AS é usado pelo protocolo BGP para detectar se a conexão BGP é interna ou externa. Para habilitar o protocolo BGP num determinado AS, use o comando router bgp asn, onde asn é o número do AS. Depois podem

144


ser digitados quaisquer comandos BGP. Para especificar a identificação do roteador (router-ID) use o comando bgp router-id ip-address, onde o endereço IP deve ser o da interface de loopback, porque esta interface nunca fica fora (down); se não for especificada uma interface, o BGP usará como identificação do roteador a interface de maior endereço IP; se por algum problema no enlace a interface cair (down), o protocolo BGP ficará instável;

\\BGP

route – É preciso adicionar redes ao AS com o comando network A.B.C.D/M, onde A.B.C.D é o endereço de rede e /M é a máscara de subrede (notação CIDR); essa rede será anunciada pelo BGP aos seus pares. Exemplo: router bgp 1; network 10.0.0.0/8. A rede 10.0.0.0/8 será anunciada a todos os vizinhos. Alguns fabricantes de roteadores não permitem que os roteadores anunciem redes que não estejam nas tabelas de roteamento do protocolo IGP (OSPF, RIP etc.). Nesta implementação o BGP não leva em consideração as rotas IGP;

\\Route

Aggregation – É possível reduzir as tabelas de roteamento agregando rotas (ou supernets), usando a facilidade do CIDR (Classless InterDomain Routing). O comando é aggregate-address A.B.C.D/M {as-set}. Para que as rotas agregadas não sejam anunciadas no AS, use o comando aggregate-address A.B.C.D/M summary-only.

\\Redistribute

to BGP – O protocolo BGP pode aprender rotas internas ao AS, sejam elas do kernel, estáticas, de redes diretamente conectadas ou de protocolos IGP (RIP, OSPF). O comando é redistribute {kernel| static|connected|rip|ospf}. Apenas um deles pode ser informado de cada vez. Se necessário, redistribua várias rotas, digitando vários comandos;

\\Defining

Peer Group – Para simplificar a configuração de vizinhos, pode-se criar um ou mais peer group e definir os vizinhos dentro dos grupos; são necessários 3 passos: \\Criar

o peer group com o comando neighbor peer-group-name peer group, onde peer-group-name é o nome do grupo;

\\Configurar

opções para o grupo, entre elas:

peer-group-name remote-as asn, para especificar um vizinho BGP;

\\neighbor

\\neighbor

peer-group-name update-source interface, para permitir que as sessões BGP internas possam usar qualquer interface operacional para as conexões TCP;

peer-group-name description, para associar uma descrição a um vizinho BGP.

\\neighbor

\\Defining

Peer – Para criar um vizinho em outro AS use o comando neighbor ip-address remote-as asn, onde o endereço IP informado é o do vizinho no AS remoto de número asn. Exemplo: router bgp 1; neighbor 10.0.0.1 remote-as 2. O roteador do AS 1 está tentando o acesso ao par (peer) 10.0.0.1 no AS 2. Este comando tem que ser o primeiro a ser usado na configuração de vizinho;


145

\\BGP

Peer neighbor – O protocolo BGP requer configurações específicas de vizinhos. Vejamos algumas delas: ip-address shutdown; este comando tira do ar o vizinho, mas preserva a configuração dele; para excluir também a configuração do vizinho use o comando no neighbor ip-address remote-as asn;

\\neighbor

\\neighbor

ip-address description descrição-do-vizinho;

ip-address next-hop-self; faz com que o roteador corrente anuncie a si mesmo como o próximo hop para o vizinho especificado; todos os demais roteadores enviarão para este roteador os pacotes, ao invés de enviar para o vizinho especificado, e este roteador se encarregará de encaminhá-los;

\\neighbor

ip-address default-originate; por default, o BGP não anuncia a rota padrão (0.0.0.0/0), mesmo que ela esteja na tabela de roteamento; este comando faz com que a rota padrão seja anunciada para o vizinho.

\\neighbor

\\Show

IP BGP – Lista as rotas BGP; se for especificado um endereço, lista as rotas relacionadas; se não, lista todas as rotas. O comando é show ip bgp A.B.C.D.




146

7 Sessão de aprendizagem 7 Protocolo de roteamento BGP – Parte 1 Roteiro de atividades Tópicos e conceitos \\Conceito

de protocolo EGP

\\Funcionamento

do protocolo BGP

\\Conceito

de pares e vizinhos

\\Atributos

do BGP

Competências técnicas desenvolvidas \\Entender

o funcionamento do protocolo BGP

\\Entender

as características do protocolo BGP

\\Configurar

roteadores com protocolo BGP


minutos


148


Atividade 1 – Configuração do protocolo BGP AS 6500

AS 1900

router 1

router 4

ser1 172.16.30.1/24

ser0 172.16.20.2/24 ser0 172.16.20.1/24

router 3

router 2 ser0 ser0 172.31.10.2/24 ser1 172.16.30.2/24 172.31.10.1/24

ser0 192.168.30.2/24

ser1 92.168.30.1/24

ser1 192.168.20.2/24 ser0 192.168.20.1/24

router 0

router 5

eth0 172.16.10.1/24

eth0 192.168.10.1/24 e0

e1 e0

eth0 172.16.10.10/24

switch 1

eth0 92.168.10.20/24

pc 10

pc 20

e1

switch 2

Na rede de teste temos dois ASs: 6500 e 1900. AS 6500 é composto de 3 roteadores: router0, router1 e router2 e das redes 172.16.0.0/16.

\\O

\\O

router0 está configurado com uma interface eth0 (IP: 172.16.10.1/24) e uma interface ser0 (IP: 172.16.20.1/24).

\\O

router1 está configurado com duas interfaces seriais: ser0 (IP: 172.16.20.2/24) e ser1 (IP: 172.16.30.1/24).

\\O


\\O

router0 usa somente o protocolo OSPF.

\\O

router1 e o router2 usam OSPF e BGP.

router 2 mantém sessão iBGP com o router1 e sessão eBGP com o router3.

\\O

\\O

AS 1900 é composto de 3 roteadores: router3, router4 e router5 e das redes 192.168.0.0/16.

\\O

router5 está configurado com uma interface eth0 (IP: 192.168.10.1/24) e uma interface ser0 (IP: 192.168.20.1/24).

\\O


\\O


\\O

router5 usa somente o protocolo OSPF.

\\O

router3 e o router4 usam OSPF e BGP.

\\O

router3 mantém sessão iBGP com o router4 e sessão eBGP com o router2.

Os hosts pc10 e pc20 têm endereços IP: 172.16.10.10/24 e 192.168.10.20/24, respectivamente. Roteamento avançado – Sessão de aprendizagem 7

149

1. Dar boot no Windows, iniciar o VMware Player, maximizar a janela do VMware Player e só então iniciar a máquina virtual Imunes. Se não maximizar a janela, não será possível visualizar a barra de ferramentas na parte inferior da tela. 2. Após iniciar o programa IMUNES, carregue o arquivo de topologia RedeTeste3.imn. Esta rede está representada na figura a seguir. Selecione no menu a opção Experiment/Execute para entrar no modo de execução. 3. Aponte para o router2, mantenha apertado o botão direito do mouse e selecione a opção Ethereal/ser1 (interface serial 1 do roteador). 4. Para iniciar uma captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture...) e clique nele. Surgirá a tela de opções do Ethereal (Ethereal: capture options); selecione OK. Em seguida, surgirá uma tela onde são mostrados os totais de pacotes por protocolo, à medida que são capturados na interface ser1. Minimize essas janelas. 5. Para abrir o console do router0, aponte para o router0, mantenha apertado o botão direito do mouse e selecione a opção Shell window/ vtysh. Teremos então a tela que simula o console do roteador router0. 6. O prompt inicial é router0>, que indica que estamos no modo user. Digite enable. Assim teremos o prompt router0#, que indica que estamos no modo privilegiado (padrão Cisco IOS). Neste momento podemos configurar o protocolo OSPF no roteador. Nota: o comando sh ip route deve ser usado para verificar se aparecem as redes diretamente conectadas (C>*). Isto confirma que as interfaces correspondentes do roteador estão ativas. Se não aparecerem as redes diretamente conectadas, significa que houve um erro de inicialização quando foi executada a opção Experiment/Execute no item 2. A operação deve ser feita novamente. Para isso, digite os comandos: \\config


\\router


\\ospf

router-id 172.16.20.1 (define a identificação do roteador);

\\redistribute

connected (o OSPF pode aprender as rotas das redes

conectadas); \\redistribute

static (o OSPF pode aprender as rotas estáticas);

\\redistribute

bgp (o OSPF pode aprender as rotas BGP);


150


172.16.0.0/16 area 0 (informa as redes que serão roteadas na área 0 );

\\network

\\Ctrl-z

(termina a configuração do protocolo).


7. Abra o console no router1 e digite os comandos: \\config

t

\\router

ospf

\\ospf

router-id 172.16.30.1

\\redistribute

connected

\\redistribute

static

\\redistribute

bgp

\\network

172.16.0.0/16 area 0

\\Ctrl-z

A figura a seguir mostra o console do router1. Nesta figura está mostrada também a configuração do protocolo BGP que será feita mais adiante.


151


t

\\router

ospf

\\ospf

router-id 172.16.30.2

\\redistribute

connected

\\redistribute

static

\\redistribute

bgp

\\network

172.16.0.0/16 area 0

\\Ctrl-z



t

\\router

ospf

\\ospf

router-id 192.168.30.1

\\redistribute

connected

\\redistribute

static

\\redistribute

bgp

\\network \\Ctrl-z


192.168.0.0/16 area 0

152

Escola Superior de Redes RNP A figura a seguir mostra o console do router3. Nesta figura está mostrada também a configuração do protocolo BGP, que será feita mais adiante.


t

\\router

ospf

\\ospf

router-id 192.168.30.2

\\redistribute

connected

\\redistribute

static

\\redistribute

bgp

\\network

192.168.0.0/16 area 0

\\Ctrl-z



153


t

\\router

ospf

\\ospf

router-id 192.168.20.1

\\redistribute

connected

\\redistribute

static

\\redistribute

bgp

\\network

192.168.0.0/16 area 0

\\Ctrl-z


12. Neste ponto estamos com o protocolo OSPF configurado. Ele é o nosso protocolo IGP. Podemos verificar o funcionamento do OSPF com os comandos: \\Console

do pc10:

\\ping

–c3 172.31.10.1 (interface ser1 do router2, ainda no AS

6500). Podemos tentar também a interface ser0 do router3 que está no AS 1900 vizinho: \\ping


–c3 172.31.10.2

154


Como era esperado, apenas o ping no AS 6500 foi bem-sucedido, indicando que os ASs estão sem conectividade porque o protocolo BGP não foi configurado. A figura a seguir mostra o console do pc10.

\\Console

do pc20:

–c3 172.31.10.1 (que é a interface ser1 do router2, que está no AS 6500 vizinho). A mesma coisa vale para a interface ser0 do router3. Os resultados são exatamente os opostos aos obtidos no console do pc10, conforme mostrado na figura a seguir. Confirmada a falta de conectividade dos ASs 6500 e 1900, qualquer tentativa de acesso a endereços internos do AS vizinho não será bem-sucedida.

\\ping

Se esses comandos não funcionarem, existe um erro de configuração que tem que ser localizado e corrigido. Se necessário, peça ajuda ao instrutor.


155

13. Feito isto, podemos configurar o protocolo BGP para interligar os ASs. Os roteadores router0 e router5 não utilizam o protocolo BGP, porque são interiores aos respectivos ASs. Os demais têm que ser configurados, conforme mostrado nas figuras correspondentes anteriores. Observe que os roteadores router2 e router3 têm sessões iBGP no próprio AS e sessões eBGP com o AS vizinho. Os roteadores router1 e router4 têm somente sessões iBGP no próprio AS. Os comandos de configuração do protocolo BGP para cada roteador são os seguintes: router1 \\config t \\router \\bgp

bgp 6500

router-id 172.16.30.1

\\neighbor

INTRA-6500 peer-group

\\neighbor

INTRA-6500 remote-as 6500

\\neighbor

INTRA-6500 update-source 172.16.30.1

\\neighbor

172.16.30.2 peer-group INTRA-6500

\\neighbor

172.16.30.2 description sessao iBGP com

router2 router2 \\config t \\router

bgp 6500

\\network \\bgp

172.16.0.0/16

router-id 172.16.30.2

\\neighbor


\\neighbor


\\neighbor


\\neighbor


\\neighbor


router1 \\neighbor

172.31.10.2 remote-as 1900

\\neighbor

172.31.10.2 description sessao eBGP com

router3


156

Escola Superior de Redes RNP router3 \\config t \\router

bgp 1900

\\network \\bgp

192.168.0.0/16

router-id 192.168.30.1

\\neighbor


\\neighbor


\\neighbor


\\neighbor


\\neighbor


router4 \\neighbor

172.31.10.1 remote-as 6500

\\neighbor


router2 router4 \\config t \\router \\bgp

bgp 1900

router-id 192.168.30.2

\\neighbor

INTRA-1900 peer-group neighbor INTRA-1900 remote-as 1900

\\neighbor


\\neighbor


\\neighbor


router3 14. Neste ponto, deveremos ter conectividade entre os ASs. Para verificar as rotas aprendidas pelos roteadores, usaremos o comando: \\sh

ip route

O resultado está nas figuras a seguir. Console do router0:


157

Podemos confirmar que foram aprendidas as rotas para todas as redes. Note que são todas rotas OSPF, embora a rota para a rede 192.168.0.0/16 tenha sido aprendida do protocolo BGP. Observe que as rotas OSPF aparecem com distância administrativa 110 (default OSPF) e custo proporcional ao percurso para atingir a rede em questão. Aparecem também o Next Hop e a interface de saída. A seguir o console do router1:

Podemos confirmar que foram aprendidas as rotas para todas as redes e que algumas foram marcadas com B, indicando que são rotas anunciadas pelo protocolo BGP. A seguir as figuras relativas aos consoles dos roteadores router2, router3, router4 e router5.




158

159

15. Após a configuração de todos os roteadores, é hora de verificar o funcionamento dos mesmos. No console do pc10 digite o comando traceroute 192.168.10.20, que é o endereço IP do pc20. O resultado está mostrado na figura a seguir. Observe as interfaces dos roteadores no caminho entre os dois PCs. É sempre a interface de entrada do roteador que responde.

16. Idem para o console do pc20, desta vez no sentido oposto.

É assim que os ASs se comunicam na internet. Esta configuração é adequada para interligar dois ASs privados, mas não é adequada para interligar um AS privado a um AS público como, por exemplo, de uma Telemar, Embratel ou Brasil Telecom. A razão disso é que as rotas BGP são redistribuídas para as rotas OSPF intra-domínio. Se o AS vizinho for público, os roteadores internos do AS privado que estão rodando OSPF receberão todas as rotas do AS público, quantidade essa que pode chegar facilmente a 200.000 rotas, sobrecarregando assim a tabela de rotas sem necessidade. Na próxima sessão veremos como esse problema pode ser evitado.



160

17. Vamos ver os pacotes capturados pelo Ethereal na interface ser1 do router2. Volte na janela de captura do Ethereal e, conforme orientação do instrutor, acesse a tela de total de pacotes e clique em STOP. Isto encerra a captura e mostra automaticamente a tela a seguir com todos os pacotes capturados. Esta tela pode variar um pouco de computador para computador, em função do tempo que se levou para digitar os comandos de configuração em todos os roteadores, da ordem em que os roteadores foram configurados e do tempo de captura. Podemos observar que os três primeiros pacotes capturados são mensagens de erro ICMP originadas no pc10 (endereço IP 172.16.10.10) e destinadas ao router3/ser0 (endereço IP 172.31.10.2). Essas mensagens são devidas aos comandos ping vistos no item 12. O mesmo vale para os pacotes 4 a 6 originados no pc20 (endereço IP 192.168.10.20) e destinados ao router2/ser1 (endereço IP 172.31.10.1). Os pacotes de 7 a 9 (o 7 está em destaque) constituem o já conhecido three-way handshaking do protocolo TCP no estabelecimento de uma conexão TCP. O pacote 7 solicita o estabelecimento de uma conexão TCP (bit SYN ligado) no sentido do router2 para o router3 (veja os endereços de origem e destino). Na origem, a porta TCP usada é a 2128, e no destino é a porta 179 (padrão, usada pelo protocolo BGP). O pacote 8 solicita o estabelecimento de uma conexão TCP (bit SYN ligado) no sentido do router3 para o router2 (veja os endereços de origem e destino) e ao mesmo tempo reconhece o pacote anterior. O pacote 9 reconhece o pacote anterior e completa o conjunto de 3 pacotes do three-way handshaking.


161

18. Na próxima janela podemos ver o pacote 10 em destaque, que é uma mensagem de OPEN do protocolo BGP originada pelo router2 e destinada ao router3. Observe que essa mensagem vem imediatamente após a abertura de conexão TCP (pacotes 7 a 9) e antes do encerramento da mesma conexão (pacotes 11 a 13). A mensagem BGP informa o router-id do router2 (172.16.30.2) e o AS ao qual ele pertence (6500).


Escola Superior de Redes RNP 19. Na próxima figura vemos o pacote 57 em destaque, referente a uma mensagem de atualização BGP (UPDATE message) do router2 para o router3, que informa atributos do BGP (Path Attributes).


162

163

20. Na figura a seguir vemos o pacote 58 em destaque, referente a uma mensagem de atualização BGP (UPDATE message) do router3 para o router2 (sentido inverso ao da anterior), que também informa atributos do BGP (Path Attributes).

Os pacotes IP mostrados acima foram capturados na interface ser1 do router2. Também aconteceram sessões BGP entre os roteadores router2 e router1, sessões internas (iBGP) ao AS 6500 e sessões BGP entre os roteadores router3 e router4, sessões internas (iBGP) ao AS 1900.




164

8 Sessão de aprendizagem 8 Protocolo de roteamento BGP – Parte 2 Sumário da sessão Sessão BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Mensagens BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Tipos de mensagens BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Mensagem OPEN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Mensagem NOTIFICATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Mensagem KEEPALIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Mensagem UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Mensagem ROUTE-REFRESH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Mensagens de Erro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Mapas de rotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Uso de mapas de rotas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Route Reflector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Atividade 1 – Configuração do protocolo BGP. . . . . . . . . . . . . . . . . . . . . . . . . 180

166


Sessão BGP

Sessão BGP Entre vizinhos BGP (BGP neighbors) Usa o protocolo TCP (porta 179) Negocia diversos parâmetros Envia as “melhores rotas” (best paths) conhecidas Depois as atualizações são incrementais Mensagens UPDATE Somente quando houver alteração Controle do número de versão da atualização Mensagens KEEPALIVE (estou vivo)

Antes do estabelecimento de uma sessão BGP, os roteadores “vizinhos BGP” trocam mensagens entre si para entrar em acordo sobre quais serão os parâmetros (exemplo: tempo máximo de espera entre mensagens – hold time) da sessão. Não havendo discordância nem erros durante a negociação dos parâmetros entre as partes, a sessão BGP é estabelecida. Caso contrário, serão enviadas mensagens de erro e a sessão não será aberta.

Quando a sessão é estabelecida entre os roteadores, são trocadas mensagens contendo todas as informações de roteamento, ou seja, todos os “melhores caminhos” (best paths) previamente selecionados por cada um, para os destinos conhecidos. Posteriormente, eles trocarão somente mensagens de atualização das informações de roteamento (mensagens do tipo UPDATE) de forma incremental. Esta técnica mostrou-se um avanço no que se refere à diminuição de carga nas CPUs dos roteadores e na economia da largura de banda dos enlaces, quando comparada a outros protocolos que, ao comunicarem suas atualizações, enviam periodicamente a totalidade das rotas existentes em suas tabelas. Neste sentido, o BGP é bem econômico, somente enviando mensagens de atualização quando ocorrem mudanças nas rotas (exemplo: uma rota se tornou inválida) e informando novas rotas. Caso não existam atualizações a serem informadas, os roteadores trocam apenas mensagens do tipo KEEPALIVE para se certificarem de que a comunicação entre eles está “viva”, ou seja, ainda está ativa. Estas mensagens são pequenas (apenas 19 bytes), não sobrecarregando a CPU dos roteadores e nem o enlace entre eles. Uma característica das tabelas de rotas BGP é a existência de um número de versão, que é incrementado a cada atualização feita (através das mensagens do tipo UPDATE), permitindo assim a verificação de inconsistências nas informações de roteamento. Se ocorrer um rápido aumento no número da versão das tabelas, isto pode ser um indicativo de instabilidade na rede.


167

Mensagens BGP

Mensagens BGP

As mensagens trocadas em sessões BGP têm o comprimento mínimo de 19 bytes e máximo de 4.096 bytes. Todas as mensagens são compostas de, no mínimo, um cabeçalho e, opcionalmente, de dados. O formato do cabeçalho das mensagens BGP está descrito na figura acima. É opcional uma seqüência de dados após o cabeçalho.

Tamanho mínimo de 19 e máximo de 4096 bytes Cabeçalho + Dados Campos do cabeçalho Marcador Comprimento Tipo

Dados (opcional)

Os campos do cabeçalho são os seguintes: \\Campo

Marcador (Marker) Serve para verificar a autenticidade da mensagem recebida e se houve perda de sincronização entre os roteadores vizinhos BGP. Pode ter dois formatos: caso a mensagem seja do tipo OPEN (abrir), ou se a mensagem do tipo OPEN não possuir informação de autenticação, o campo deve estar todo preenchido com números um (1); senão, o campo marker terá o seu conteúdo baseado em parte do mecanismo de autenticação usado.

\\Campo

Comprimento (Lenght) Deve conter um número que representa o comprimento total da mensagem, incluindo o cabeçalho. Como podem haver mensagens que não possuem dados após o cabeçalho, a menor mensagem BGP enviada é de 19 bytes (16 + 2 + 1 bytes).

\\Campo

Tipo (Type) Deve conter um número que representa o código de um tipo de mensagem. Os tipos de mensagens são: KEEPALIVE, NOTIFICATION, OPEN, UPDATE e ROUTE-REFRESH.

Tipos de mensagens BGP

Tipos de mensagens BGP (1) OPEN Versão Número do AS (ASN) Tempo de espera Identificador BGP Comprimento dos parâmetros opcionais Parâmetros opcionais Versão (Version) 1 byte

No. do AS (ASN) 2 bytes

Tempo de espera

(Hold Time) 2 bytes

Identificador BGP (BGP ID) 4 bytes

Parâmetros Opcionais (Tipo/Comprimento/Valor) Tamanho variável

Mensagem OPEN

C. P. O. (OPL) 1 byte

A mensagem do tipo OPEN (tipo 1) é enviada para que seja iniciada a abertura de uma sessão BGP entre neighbors ou peers BGP. O formato desta mensagem está mostrado na figura acima. Descrição dos campos:

\\Versão

(Version) Identifica a versão do BGP (3 ou 4). Este é um dos parâmetros negociados pelos roteadores que, normalmente, tentam entrar em acordo para usar a maior versão suportada. Não havendo possibilidade de consenso (exemplo:



168

um dos roteadores não suporta o BGP-4), eles tentam usar versões anteriores, até que coincidam. Nos roteadores Cisco, há como configurar a versão a ser usada pelos roteadores (se previamente sabemos a versão que ambos suportam), eliminando esta fase de negociação do processo de abertura da sessão BGP, resultando em economia de tempo. \\Número

do AS (AS Number) Deve conter o número do AS ao qual o roteador (remetente da mensagem tipo OPEN) pertence.

\\Tempo

de espera (Hold Time) Deve conter o valor, em segundos, do maior tempo de espera (hold time) permitido entre mensagens do tipo UPDATE ou KEEPALIVE. O BGP mantém um contador do hold time, que é reiniciado (zerado) a cada vez que uma mensagem do tipo KEEPALIVE ou UPDATE é recebida. Caso nenhuma das duas seja recebida no prazo máximo, o BGP considera que a comunicação com o outro roteador foi perdida, e a sessão é encerrada, tendo que ser reiniciada novamente. Os roteadores tentam usar o menor hold time entre os dois. Caso o valor seja estabelecido como zero, a sessão será considerada como estando sempre “viva” (ativa) e mensagens de KEEPALIVE não serão transmitidas, pois os contadores do hold time e do KEEPALIVE não serão zerados nunca. O valor mínimo recomendado para este parâmetro é de três segundos.

\\Identificador

BGP (BGP ID) É a identificação BGP do roteador que enviou a mensagem OPEN. Contém o endereço IP definido no comando bgp router-id.

\\Comprimento

dos Parâmetros Opcionais (Optional Parameters Lenght) Indica o comprimento total do campo de Parâmetros Opcionais (Optional Parameters). No caso de ausência de parâmetros opcionais, este campo será preenchido com zero.

\\Parâmetros

Opcionais (Optional Parameters) Pode conter vários parâmetros opcionais para a negociação de abertura de uma sessão BGP. Este campo deve ser preenchido com conjuntos formados por 3 valores: 1. Tipo do parâmetro (1 byte); 2. Comprimento do Parâmetro (1 byte); 3. Valor do parâmetro (comprimento variável). Um exemplo de parâmetro é o de informação de autenticação (tipo 1), usado para autenticar a sessão com o vizinho BGP.


169

Na sessão anterior foram capturados pacotes de sessões BGP. Um deles está mostrado na figura acima: OPEN Message.

Mensagem OPEN

Podemos notar que foi utilizada uma conexão TCP entre os roteadores de endereços 172.31.10.1 (origem) e 172.31.10.2 (destino), portas TCP 2128 e 179 (BGP). A mensagem está detalhada na figura. O tamanho total da mensagem é de 45 bytes, sendo 19 bytes do cabeçalho, 10 bytes dos campos fixos da mensagem OPEN e 16 bytes de parâmetros opcionais (3 anúncios de capacidades). Todos os campos podem ser visualizados no quadro de bytes em hexadecimal que está destacado.

Mensagem NOTIFICATION

Tipos de mensagens BGP (2)

Este tipo de mensagem (tipo 4) é enviada no caso de detecção de erros durante ou após o estabelecimento de uma sessão BGP. O formato da mensagem NOTIFICATION está mostrado na figura.

NOTIFICATION Erro Subcódigo de erro Dados Erro (Error) 1 byte

Subcódigo de erro

(Error Subcode) 1 byte

Dados (Data) Tamanho variável

KEEPALIVE Somente o cabeçalho padrão BGP (19 bytes)

\\Campo

Erro (Error)

Deve conter o tipo da notificação. \\Campo

Sub Código de Erro (Error subcode)

Deve conter um valor que fornece maiores informações sobre o erro. \\Campo

de Dados (Data)

Pode conter dados referentes ao erro, como por exemplo um cabeçalho mal formado (inválido), ou um número de AS inválido

Mensagem KEEPALIVE São mensagens (tipo 3) trocadas periodicamente com o propósito de verificar se a comunicação entre os vizinhos está ativa. A mensagem do tipo KEEPALIVE é composta apenas do cabeçalho padrão das mensagens BGP, sem dados transmitidos após o cabeçalho. O tempo máximo permitido para o recebimento de mensagens KEEPALIVE ou UPDATE é definido pelo hold time, como foi visto na descrição do tipo de mensagem OPEN. Para manter aberta a sessão, a mensagem de KEEPALIVE deve ser enviada antes que expire o prazo definido no hold time; caso contrário, a sessão será encerrada. A recomendação é de que a mensagem seja enviada em até 1/3 do


170


tempo definido no hold time. Se o seu valor for igual a zero, então as mensagens do tipo KEEPALIVE não serão enviadas.. Na sessão anterior foram capturados pacotes de sessões BGP. Um deles está mostrado na figura acima: KEEPALIVE Message.

Mensagem KEEPALIVE

Podemos notar que foram trocadas 4 mensagens entre os roteadores de endereços 172.31.10.1 e 172.31.10.2, portas TCP 2322 e 179 (BGP). A mensagem está detalhada na figura. O tamanho total da mensagem é de 19 bytes, conforme previsto. Todos os campos podem ser visualizados no quadro de bytes em hexadecimal que está destacado.

Mensagem UPDATE

Mensagem UPDATE Rotas removidas (Unfeasible routes) Atributos Caminho (Path attributes) Informações NLRI

Comprimento do campo (Length) Rotas removidas (Withdrawn routes) Comprimento do campo (Length) Atributos Caminho (Path attributes) Comprimento (Length), Prefixo (Prefix)...

As mensagens UPDATE (tipo 2) trocadas entre os peers ou neighbors BGP são de extrema importância, pois são elas que levam as informações para a atualização da tabela de rotas mantida pelo BGP. A estrutura básica das mensagens do tipo UPDATE é composta de 3 itens: 1. Rotas inalcançáveis (unreachable routes); 2. Atributos de caminhos (path attributes); 3. Informação de alcance da camada de rede (Network Layer Reachability Information – NLRI).

O formato da mensagem do tipo UPDATE está mostrado na figura acima. \\Comprimento

das rotas removidas ou inalcançáveis (Unfeasible Routes

Length) Neste campo, é indicado o comprimento total, em bytes, do total de rotas removidas (withdrawn routes). \\Rotas

removidas (withdrawn routes) Este campo inclui uma lista de prefixos de endereços para rotas que devem ser removidas da tabela de rotas BGP. É composto de endereços IP acrescidos do comprimento do número de bits contados a partir da esquerda no endereço IP, como mostrado na figura e detalhado a seguir;


171

\\Comprimento

(Lenght) Deve indicar o comprimento total, em bits, do total de rotas removidas. Um comprimento igual a 0 (zero), indica que não há rotas a serem removidas nesta mensagem UPDATE.

\\Prefixo

(Prefix) Contém prefixos de endereços IP seguidos de bits suficientes para fazer o final deste campo terminar “arredondado” em bytes completos. O valor dos bits complementares não tem importância.

\\Comprimento

Total do Atributo Caminho (Total Path Attribute Length)

Deve indicar o comprimento total, em bits, do campo Atributos Caminho. O valor contido neste campo deve permitir a determinação do comprimento do campo NLRI. Se o valor deste campo for 0 (zero), significa que não há informação NLRI presente na mensagem UPDATE. \\Atributos

do Caminho (Path Attributes)

São um conjunto de parâmetros associados a uma determinada rota que influenciam no processo de decisão, feito pelo BGP, para a escolha da melhor rota. \\Informações

NLRI (NLRI Information)

São prefixos de endereços IP de informações no formato igual ao do campo de rotas removidas (withdrawn routes). Este campo é preenchido por várias entradas. Um exemplo de entrada seria: <18,192.213.134.0>, que indica uma rota para 192.213.134.0 255.255.192.0 (ou 192.213.134.0/18, na notação CIDR).

Mensagem ROUTE-REFRESH

Mensagem ROUTE-REFRESH Definida no RFC2918 Address Family Identifier (AFI) Reservado (valor 0) Subsequent Address Family Identifier (SAFI) Serve para solicitar a retransmissão de todas as informações de roteamento de um vizinho BGP Não precisa fechar e reiniciar a sessão BGP Independente do protocolo (IPv4 ou IPv6) Identificador da família de endereços AFI – Address Family Identifier 2 bytes

Reservado 1 byte

SAFI (Subsequent AFI) 1 byte

A mensagem ROUTE-REFRESH (tipo 5) não está definida no RFC4271, mas sim no RFC2918, como uma capacidade de BGP. Ela é usada para solicitar a completa retransmissão de todas as informações de roteamento de um vizinho, sem necessidade de encerrar e reabrir uma sessão BGP com o vizinho. Desta forma, mudanças nas políticas de roteamento podem ser feitas dinamicamente, economizando recursos do roteador.

Esta mensagem foi projetada para ser independente de protocolo; assim pode ser solicitada a retransmissão das rotas IPv4, mas não das rotas IPv6, por exemplo. Por exemplo: o campo AFI pode ser IPv4 ou IPv6, enquanto o campo SAFI pode ser unicast ou multicast.


172


Mensagens de Erro

Mensagens de Erro ERROR CODE 1

ERROR SUBCODE

1 – Conexão não sincronizada Erro no cabeçalho 2 – Comprimento da mensagem inválido da mensagem 3 – Tipo de mensagem inválido

1 – Número de versão não suportado 2 – Número de AS vizinho inválido Erro na mensagem 3 – Identificador BGP inválido 2 OPEN 4 – Parâmetro opcional não suportado 5 – Falha na autenticação 6 – Tempo de espera inaceitável 1 – Lista de atributos mal formada 2 – Atributo Well-Known desconhecido 3 – Atributo Well-Known faltando 4 – Erro nas flags de atributos 5 – Erro no comprimento do atributo Erro na mensagem 3 6 – Atributo de origem inválido UPDATE 7 – Loop de roteamento em AS 8 – Atributo NEXT_HOP inválido 9 – Erro no atributo Opcional 10 – Campo de rede inválido 11 – AS_path mal formado 4 Hold Timer Expired No Subcodes 5

Finite State Error

No Subcodes

6

Cease

No Subcodes

Mapas de rotas

Mapas de rotas (1) Redistribuição Cada protocolo de roteamento mantém sua própria tabela O roteador mantém uma tabela de todas as rotas A redistribuição é o repasse de rotas entre os protocolos Mapas de rotas (Route maps) Controlam e modificam informações de roteamento Formato: route-map nome permit|deny seq Comandos match e set Listas de prefixo (Prefix lists) ip prefix-list nome seq número permit|deny prefix [le len] [ge len]

Num roteador, cada protocolo de roteamento mantém a sua tabela de rotas individual na memória, enquanto o próprio roteador mantém uma outra tabela montada com rotas fornecidas por todos os protocolos de roteamento que estiverem sendo executados nele. Esta é a tabela utilizada pelo roteador para executar sua função de rotear pacotes de dados.

A redistribuição acontece quando, em um roteador, um protocolo de roteamento repassa as rotas de sua tabela para outro protocolo de roteamento. O outro protocolo pode aceitar (ou não) todas ou apenas algumas, e incluí-las em sua tabela de rotas. Posteriormente, estas rotas serão anunciadas por este outro protocolo para os roteadores vizinhos que “falam” este mesmo protocolo. O comando network é uma das formas de anunciar as redes de um AS no protocolo BGP. Outra forma é redistribuir as rotas conhecidas pelo IGP para o BGP. Isso pode ser muito perigoso, pois pode-se injetar todas as rotas internas do AS no BGP desnecessariamente. Se, por exemplo, uma das rotas foi aprendida através do próprio BGP, então não há necessidade de repassá-la novamente. Uma filtragem cuidadosa deve ser aplicada para garantir que só serão anunciadas para a internet rotas que realmente desejamos anunciar, e não anunciar todas indiscriminadamente. Na sessão anterior vimos o exemplo oposto: as rotas BGP sendo anunciadas para o protocolo OSPF, que é um IGP. Também existem riscos naquele caso. Route maps servem para o BGP controlar e modificar informações de roteamento e também definir as condições da propagação de rotas entre domínios de roteamento. Os route-maps possibilitam a definição de condições para, por


173

exemplo, redistribuição de rotas entre protocolos de roteamento (BGP e algum IGP) ou para o controle das rotas injetadas (ou removidas) no BGP. A sintaxe de um route map é: \\route-map

nome [[permit | deny] | [seq]] O nome identifica o route map. O seq indica a posição que a instância do route map deve ter em relação a outras instâncias do mesmo route map, sendo as instâncias ordenadas seqüencialmente. Exemplos de route maps:

\\route-map

TESTE permit 10 Primeiro conjunto de condições.

\\route-map

TESTE permit 20 Segundo conjunto de condições. (...)

Quando o BGP aplica o route map TESTE nas atualizações de roteamento (route updates), primeiro é aplicada a instância que possuir o menor número seqüencial (no exemplo acima, a instância 10) e depois as subseqüentes, se houver. Se o primeiro conjunto de condições não for satisfeito, o segundo será aplicado e assim por diante, até que algum conjunto de condições seja satisfeito ou quando não houver mais condições a serem aplicadas. Os comandos match e set são usados para definir as condições no route map. O comando match define a condição a ser satisfeita e o comando set especifica a ação a ser tomada caso o update corresponda à condição. Abaixo, um exemplo de route map simples: route-map TESTE permit 10 match ip address 10.10.8.1 set metric 10 Quando uma rota corresponder ao endereço IP 10.10.8.1, o BGP vai configurar a métrica do update para 10, propagá-lo (pelo uso da palavra-chave permit) e vai sair da lista de instâncias de route maps. Caso o update não corresponda ao critério de uma instância definida, o BGP vai comparar com a instância seguinte, até que uma ação seja tomada ou até que a última instância seja comparada. Se o update não satisfizer nenhuma das condições, o update não será propagado. Caso seja usada a palavra-chave deny na configuração do route map e o update corresponder ao critério definido, o BGP interromperá a comparação com a lista de instâncias e o update não será propagado. Uma restrição que deve ser observada no uso de route maps é que eles podem ser usados para filtrar anúncios (redistribuição) de updates baseados em endereços IP, mas não para filtrar o recebimento de updates baseados nos endereços IP. Listas de Prefixo (Prefix lists) podem ser usadas como uma alternativa para as listas de acesso (Access Control Lists – ACLs) em muitos comandos de filtragem


174

Escola Superior de Redes RNP de rotas BGP. Tais listas fornecem o mais poderoso mecanismo de filtragem baseado em prefixos, com as seguintes vantagens sobre as listas de acesso: \\Significativa

melhoria de performance na carga e pesquisa de rotas em grandes listas;

\\Suporte

para atualizações incrementais; a filtragem que usa listas de acesso estendidas não suporta atualizações incrementais;

\\Interface

de linha de comando mais amigável; a interface de linha de comando para uso de listas de acesso na filtragem de atualizações BGP é difícil de compreender e de utilizar, porque utiliza o formato de filtragem de pacotes;

\\Maior

flexibilidade; antes de usar uma lista de prefixo num comando é necessário preparar a aplicação da lista num mapa de rotas, como veremos mais adiante.

O formato é: ip prefix-list nome seq número permit|deny prefix [le len] [ge len], onde: \\nome:

nome da lista de prefixo;

\\número:

número seqüencial que determina a ordem dentro da lista; pode ser numerado manualmente ou automaticamente; neste último caso a numeração será de 5 em 5;

\\le

len: este comando especifica o comprimento do prefix (prefix length); as condições da lista de prefixo serão aplicadas se o comprimento do prefixo for menor ou igual ao valor len;

\\ge

len: este comando especifica o comprimento do prefix (prefix length); as condições da lista de prefixo serão aplicadas se o comprimento do prefixo for maior ou igual ao valor len;

Esses dois últimos comandos podem ser usados sozinhos ou em conjunto, não importando a ordem. A filtragem por lista de prefixo envolve a comparação dos prefixos das rotas com aquelas relacionadas na lista de prefixo. Quando ocorre uma igualdade (match), a rota é usada. A comparação é similar àquela usada nas listas de acesso. Mais especificamente, a permissão ou a negação de um prefixo é baseada nas seguintes regras: \\Uma

lista de prefixo vazia permite (permit) todos os prefixos;

negação (deny) implícita é assumida se um determinado prefixo não existe (doesn´t match) na lista de prefixo;

\\Uma

\\Quando

um dado prefixo aparece várias vezes na lista de prefixo (multiple entries), a ocorrência com o menor número de seqüência será a escolhida (match).


175

O roteador inicia a pesquisa no início (top) da lista de prefixo, pelas ocorrências de menor número seqüencial. Quando ocorrer uma igualdade (match), o roteador interrompe a pesquisa e ignora o resto da lista, executando as ações definidas na ocorrência em que ocorreu a igualdade. Para maior eficiência na pesquisa da lista, é recomendável colocar as ocorrências mais comuns no topo da lista.

Uso de mapas de rotas

Uso de mapas de rotas route-map meumapa permit 10 match ip address 10.0.0.1 set metric 5 ip prefix-list abc permit 192.0.0.0/8 le 24 ip prefix-list abc deny 192.0.0.0/8 ge 25 ip prefix-list abc permit 0.0.0.0/0 le 32 route-map rotaspadrao permit 10 match ip address prefix-list BOGONS

Embora existam muitos métodos para filtragem de rotas em BGP, vamos exemplificar aqui o uso de listas de prefixo e mapas de rotas. O primeiro exemplo verifica as atualizações que têm o endereço IP 10.0.0.1, alterando a métrica para 5. Como o mapa foi declarado com a condição permit, a rota será propagada. Se a condição fosse deny, a rota não seria propagada. Nota: é inútil declarar a cláusula set quando a condição for deny, porque a rota não será propagada, e a alteração não será feita.

Os três exemplos seguintes são de lista de prefixo. O primeiro deles permite rotas 192.0.0.0/8 de tamanho de prefixo de até 24. O segundo deles nega as rotas 192.0.0.0/8 de tamanho de prefixo maior ou igual a 25. O terceiro deles permite todas as rotas. O último exemplo define um mapa de rotas chamado rotaspadrao, que usa a lista de prefixo chamada BOGONS, que define as rotas que não vamos aceitar porque são as rotas óbvias: rota padrão, endereços privados (RFC1918), endereço multicast e outras específicas do domínio local. Nota: a palavra chave BOGONS é usada para definir este tipo de lista de prefixo. A lista aceita como referência padrão é a seguinte: prefix-list BOGONS description (redes “óbvias” que não serão aceitas)

\\ip

\\ip

prefix-list BOGONS seq 5 deny 0.0.0.0/8 le 32

\\ip


\\ip


\\ip


\\ip


\\ip


\\ip


\\ip


\\ip

prefix-list BOGONS seq 45 permit 0.0.0.0/0 le 32


176


Route Reflector

Route Reflector (1) Número de sessões BGP: n(n-1)/2 Full-mesh BGP Solução: Route Reflector Sem Route Reflector

Com Route Reflector (RR)

Como vimos anteriormente, não há detecção de loop de roteamento em sessões iBGP. Desta forma, o anúncio de rotas para um vizinho iBGP pode causar um loop de roteamento que não será detectado. É por esta razão que os roteadores iBGP não anunciam rotas para seus vizinhos. Em outras palavras: cada roteador iBGP tem que manter uma sessão BGP com todos os outros roteadores iBGP, mesmo não tendo uma conexão física com eles. É o que nós chamamos de full mesh BGP.

Na figura acima, com apenas 6 roteadores teríamos n(n-1)/2 sessões: 6(6-1)/2 = 15 sessões, o que torna quase inviável a comunicação iBGP. Por outro lado, não configurar todos os vizinhos (peers) dentro do AS pode fazer com que alguns roteadores desconheçam algumas rotas. Para resolver esse problema, duas soluções podem ser adotadas: route reflection (reflexão de rotas) e confederations (confederações). Ambas são amplamente utilizadas e não são mutuamente exclusivas, podendo ser utilizadas dentro do mesmo AS. Route reflection é definida no RFC2796 e introduz um enfoque de hierarquia para resolver o problema do full-mesh BGP. Ao invés de definir vizinhança (peering) com todos os roteadores do AS, apenas define-se vizinhança com um roteador escolhido para ser o route reflector, conforme mostrado na figura acima. Com 6 roteadores, reduzimos 15 sessões para apenas 5 sessões iBGP. Os vizinhos do route reflector são chamados clientes (clients). O roteador escolhido para ser o route reflector pode redistribuir rotas iBGP para seus clientes. Cada grupo de clientes com seu respectivo route reflector é chamado de cluster (concentração). Cada cluster recebe uma identificação única (cluster ID). Todos os atributos de caminho (path attributes) são passados para os clientes sem modificação, especialmente o endereço do próximo salto (next hop address), senão todo o tráfego teria que passar pelo route reflector (RR). Já que agora o route reflector pode anunciar rotas iBGP para seus vizinhos, podem ocorrer loops de roteamento. Para evitar isso foram definidos dois novos atributos de caminho: ORIGINATOR-ID e CLUSTER-LIST, ambos definidos no RFC2796. Suponha, na figura acima, que o roteador 192.168.1.1 anunciou a rota 10.0.0.0/8 para o RR que, por sua vez, a repassou para os seus clientes. O RR anunciou a rota com o atributo ORIGINATOR-ID = 192.168.1.1, para indicar o roteador que anunciou aquela rota. Este anúncio nunca será feito para o roteador


177

que originou esta rota (o próprio 192.168.1.1), senão poderíamos ter um loop de roteamento. Os clientes nunca usam esse atributo.

Route Reflector (2) Cluster list

A lista de cluster (Cluster list) registra os clusters que um anúncio de prefixo atravessou. Os RRs acrescentam o cluster-ID à lista de clusters quando anunciam a rota para outro cluster. Se um RR detectar seu próprio cluster-ID no anúncio feito por um vizinho, este RR não aceitará o anúncio do prefixo, pois isto poderia provocar um loop de roteamento. Os clientes nunca modificam o atributo CLUSTER-LIST. Na figura acima, a rota 10.0.0.0/8 foi anunciada pelo cluster 192.168.1.1 e depois de passar pelos clusters 192.168.1.2 e 192.168.1.3 será anunciada para o cluster 192.168.1.1, que originou esta rota; por isso ela é rejeitada.




178

8 Sessão de aprendizagem 8 Protocolo de roteamento BGP – Parte 2 Roteiro de atividades Tópicos e conceitos \\Sessão

BGP

\\Mensagens \\Mapas

BGP

de rotas

Competências técnicas desenvolvidas \\Apresentar \\Entender \\Projetar

funcionamento de uma sessão BGP

as mensagens do protocolo BGP

e configurar redes com protocolo BGP


minutos


180


Atividade 1 – Configuração do protocolo BGP router 2 ser0 172.16.30.2/24

router 1

ser1 172.16.30.1/24

ser1 172.31.10.1/24

eth0 10.0.31.17/28

eth1 10.0.31.1/28

ser0 172.16.20.2/24

border2

border1

ser0 172.31.10.2/24

ser0 192.168.1.1/24 eth0 eth0 192.1681.2/24 10.0.31.18/28

eth1 10.0.31.2/28

e0

ser0 172.16.20.1/24

switch 1

router 0

e2

eth0 172.16.10.1/24

e0

e3

e2

eth0 10.0.31.3/28

e1

switch 0 e0 eth0 172.16.10.10/24

LAN 1

eth2 10.0.0.1/24

ISP-A

e1 e1

eth1 10.0.31.19/28

switch 2 e3

eth1 10.0.31.20/28 eth0 10.0.31.4/28

core2

core1

eth2 10.0.1.1/24

e0 eth0 10.0.1.2/24

pc 10

LAN 2 e0 e1

pc 20

Na rede de teste temos dois ASs: 6500 e 1900. \\O

AS 6500 é composto de 3 roteadores: router0, router1 e router2 e das redes 172.16.0.0/16.

\\O

router0 está configurado com uma interface Ethernet eth0 (IP: 172.16.10.1/24) e uma interface serial ser0 (IP: 172.16.20.1/24).

\\O


\\O


\\Todos

os roteadores usam o protocolo OSPF e são vizinhos BGP.

\\O

router2 é Route Reflector (RR) para os demais roteadores do AS 6500; portanto, mantém sessões iBGP com os roteadores router1 e router0. Os roteadores router0 e router1 não são vizinhos entre si e não mantêm sessões iBGP entre eles. Além disso, o router2 mantém uma sessão eBGP com o border1 e é a rota padrão para saída do AS 6500.

\\O

AS 1900 é composto de 4 roteadores: border1, border2, core1 e core2 e das redes 10.0.0.0/16 e 192.168.0.0/16. Somente a rede 10.0.0.0/16 está sendo anunciada pelo BGP para fora do AS 1900. Este AS tem uma configuração dual, com caminhos redundantes entre os 4 roteadores. É uma configuração semelhante às usadas pelas empresas que provêem acesso à internet para seus clientes, inclusive para provedores de conteúdo (como o ISP-A). Observe que são usadas duas redes para permitir o estabelecimento dos caminhos duais: rede 10.0.31.0/28 e rede 10.0.31.16/28. As interfaces de loopback dos roteadores usam endereços IP da rede 10.0.31.32/28.

\\Os

4 roteadores são identificados por suas interfaces de loopback: 10.0.31.33, 10.0.31.34, 10.0.31.35 e 10.0.31.36, respectivamente. Essa identificação tem a vantagem de garantir maior estabilidade nas conexões


181

TCP do protocolo BGP, porque a interface de loopback nunca sai do ar. Esse tipo de identificação é recomendado para uso local, somente dentro do AS. Para outros ASs, recomenda-se usar endereço IP de uma interface física do roteador de borda. \\O

border1 é Route Reflector (RR) para os demais roteadores do AS 1900; portanto, mantém sessões iBGP com os roteadores border2, core1 e core2. Os roteadores border2, core1 e core2 não são vizinhos entre si e não mantêm sessões iBGP entre eles. Além disso, o border1 mantém uma sessão eBGP com o router2 e é a rota padrão para saída do AS 1900.

\\O

border1 está configurado com uma interface serial ser0 (IP: 172.31.10.2/24) e duas interfaces Ethernet: eth0 (IP: 10.0.31.17/28) e eth1 (IP: 10.0.31.1/28).

\\O

border2 está configurado com uma interface serial ser0 (IP: 192.168.1.1/24) e duas interfaces Ethernet: eth0 (IP: 10.0.31.18/28) e eth1 (IP: 10.0.31.2/28).

\\O

core1 está configurado com 3 interfaces Ethernet: eth0 (IP: 10.0.31.3/28), eth1 (IP: 10.0.31.19/28) e eth2 (IP: 10.0.0.1/24).

\\O

core2 está configurado com 3 interfaces Ethernet: eth0 (IP: 10.0.31.4/28), eth1 (IP: 10.0.31.20/28) e eth2 (IP: 10.0.1.1/24).

\\Todos

os roteadores usam o protocolo OSPF.

\\Os

hosts pc10 e pc20 têm endereços IP: 172.16.10.10/24 e 10.0.1.2/24, respectivamente.

1. Dar boot no Windows, iniciar o VMware Player, maximizar a janela do VMware Player e só então iniciar a máquina virtual Imunes. Se não maximizar a janela, não será possível visualizar a barra de ferramentas na parte inferior da tela. 2. Após iniciar o programa IMUNES, carregue o arquivo de topologia RedeTeste4.imn. Essa rede está representada na figura a seguir. Selecionar no menu a opção Experiment/Execute para entrar no modo de execução. 3. Aponte para o border1, mantenha o botão direito do mouse apertado e selecione a opção Ethereal/eth1 (interface Ethernet1 do roteador). 4. Para iniciar uma captura, selecione o primeiro ícone no alto à esquerda na barra principal (Start a new live capture...) e clique nele. Selecione um filtro de captura do protocolo TCP. Basta digitar tcp na janela de filtragem. Clique em Apply. Clique em OK. Surgirá uma tela onde é mostrado o total de pacotes por protocolo, à medida que são capturados na interface eth1. Minimize essas janelas.


182


5. Para abrir o console do router0, aponte para o router0, mantenha o botão direito do mouse apertado e selecione a opção Shell window/vtysh. Teremos então a tela que simula o console do roteador router0. 6. O prompt inicial é router0>, que indica que estamos no modo user. Digite enable. Assim teremos o prompt router0#, que indica que estamos no modo privilegiado (padrão Cisco IOS). O protocolo OSPF já está configurado. Se quiser ver a configuração atual, basta digitar o comando sh run. O comando sh ip route mostra somente as rotas OSPF do AS 6500. Nota: Observe que na configuração dos roteadores não há o comando redistribute bgp. Neste momento podemos configurar o protocolo BGP no roteador. Para isto, basta digitar os comandos: \\config


\\router

bgp 6500 (habilita o protocolo BGP no AS 6500);

\\network \\bgp

172.16.0.0/16 (informa as redes que serão anunciadas no AS);

router-id 172.16.20.1 (define a identificação do roteador);

\\neighbor

172.16.30.2 remote-as 6500 (define o router2 como

vizinho); \\neighbor


router2 \\Ctrl-z

(termina a configuração do protocolo).


183

A figura a seguir mostra o console do router0 após o comando sh run.


t

\\router

bgp 6500

\\network \\bgp

172.16.0.0/16

router-id 172.16.30.1

\\neighbor

172.16.30.2 remote-as 6500

\\neighbor


router2 \\Ctrl-z



184



t \\router bgp 6500 \\network 172.16.0.0/16 \\bgp router-id 172.16.30.2 \\neighbor 172.16.20.1 remote-as 6500 (define o router0 como vizinho) \\neighbor 172.16.20.1 description sessao iBGP com router0 \\neighbor 172.16.20.1 default-originate (anuncia a rota default do AS) \\neighbor 172.16.20.1 route-reflector-client (define o router0 como cliente do RR) \\neighbor 172.16.30.1 remote-as 6500 (define o router1 como vizinho) \\neighbor 172.16.30.1 description sessão iBGP com router1 Roteamento avançado – Sessão de aprendizagem 8

185

\\neighbor

172.16.30.1 do AS) \\neighbor 172.16.30.1 como cliente do RR) \\neighbor 172.31.10.2 vizinho) \\neighbor 172.31.10.2 border1 \\Ctrl-z

default-originate (anuncia a rota default route-reflector-client (define o router1 remote-as 1900 (define o border1 como description sessao eBGP com



186

Escola Superior de Redes RNP 9. Abra o console no border1 e digite os comandos: \\config \\int \\ip

t

lo0 address 10.0.31.33/32 (define o endereço da interface loopback)

\\Ctrl-z \\config

t

\\router

bgp 1900

\\network \\bgp

10.0.0.0/16 (informa as redes que serão anunciadas no AS)

router-id 10.0.31.33

\\neighbor

10.0.31.34 remote-as 1900 (define o border2 como

vizinho) \\neighbor

10.0.31.34 description sessao iBGP com border2

\\neighbor

10.0.31.34 route-reflector-client

\\neighbor

10.0.31.34 default-originate

10.0.31.34 update-source 10.0.31.33 (define a interface loopback como interface de origem das atualizações)

\\neighbor

\\neighbor

10.0.31.35 remote-as 1900 (define core1 como vizinho)

\\neighbor

10.0.31.35 description sessao iBGP com core1

\\neighbor


\\neighbor


\\neighbor

10.0.31.35 update-source 10.0.31.33

\\neighbor

10.0.31.36 remote-as 1900 (define core2 como vizinho)

\\neighbor

10.0.31.36 description sessao iBGP com core2

\\neighbor


\\neighbor


\\neighbor

10.0.31.36 update-source 10.0.31.33

\\neighbor

172.31.10.1 remote-as 6500 (define router2 como

vizinho) \\neighbor


router2 \\Ctrl-z


187

A figura a seguir mostra o console do border1 após o comando sh run.


188

Escola Superior de Redes RNP 10. Abra o console no border2 e digite os comandos: \\config

t

\\int

lo0 address 10.0.31.34/32 (define o endereço da interface loopback) \\Ctrl-z \\config t \\router bgp 1900 \\network 10.0.0.0/16 \\bgp router-id 10.0.31.34 \\neighbor 10.0.31.33 remote-as 1900 (define o border1 como vizinho) \\neighbor 10.0.31.33 description sessao iBGP com border1 \\neighbor 10.0.31.33 update-source 10.0.31.34 \\Ctrl-z \\ip

A figura a seguir mostra o console do border2 após o comando sh run.


189

11. Abra o console core1 e digite os comandos: \\config

t

\\int


A figura a seguir mostra o console do core1 após o comando sh run.


190

Escola Superior de Redes RNP 12. Abra o console core2 e digite os comandos: \\config

t

\\int


A figura a seguir mostra o console do core2 após o comando sh run.


191

13. Vamos ver os pacotes capturados pelo Ethereal na interface eth1 do border1. Volte à janela de captura do Ethereal e, conforme orientação do instrutor, acesse a tela de total de pacotes e clique em STOP. Isto encerra a captura e mostra automaticamente a tela a seguir com todos os pacotes capturados. Esta tela pode variar um pouco de computador para computador, em função do tempo que se levou para digitar os comandos de configuração em todos os roteadores, da ordem em que os roteadores foram configurados e do tempo de captura. Nesta tela podemos ver mensagens do tipo OPEN, KEEPALIVE e UPDATE, que são as mensagens mais comuns em sessões BGP.

Note que as primeiras mensagens que aparecem neste arquivo de captura são mensagens de estabelecimento de conexões TCP (3-way handshaking). 14. Neste ponto, deveremos ter conectividade entre os ASs. Para ver as rotas que foram aprendidas pelos roteadores, usaremos o comando: \\sh


ip route


192

O resultado está nas figuras a seguir. Console do router0:

Podemos confirmar que foram aprendidas as rotas para todas as redes. Note que são rotas OSPF e BGP. Observe que as rotas OSPF aparecem com distância administrativa 110 (default OSPF) e custo proporcional ao percurso para atingir a rede em questão. Já as rotas BGP têm distância administrativa 200 (default BGP). Aparecem também o Next Hop e a interface de saída. Note que foram aprendidas a rota padrão (0.0.0.0/0) e a rota para a rede 10.0.0.0/16 do outro AS, via protocolo BGP. A seguir o console do router1:

Podemos confirmar que foram aprendidas as rotas para todas as redes e que algumas foram marcadas com B, indicando que são rotas anunciadas pelo protocolo BGP. A seguir as figuras relativas aos consoles dos roteadores router2, border1, border2, core1 e core2.


193


194


Podemos observar que, em todos os roteadores do AS 1900, todas as rotas foram aprendidas, inclusive com todos os caminhos duais, quando existem. Caso os caminhos duais não estejam aparecendo exatamente como nas figuras acima, pode acontecer de alguma interface de algum roteador não estar executando corretamente o protocolo OSPF. Para verificar, use o comando: \\sh

ip ospf neighbors


195

15. Após a configuração de todos os roteadores, é hora de verificarmos o funcionamento. No console do pc10 digite o comando traceroute 10.0.1.2, que é o endereço IP do pc20. O resultado está mostrado na figura a seguir. Observe as interfaces dos roteadores no caminho entre os dois PCs. É sempre a interface de entrada do roteador que responde.

16. O mesmo vale para o console do pc20, desta vez no sentido oposto. Esta configuração é adequada para interligar quaisquer tipos de ASs.




196

9 Sessão de aprendizagem 9 Resolução de problemas Sumário da sessão Orientações gerais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Formação de grupos de trabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Problemas propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Apresentação das soluções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Atividade 1 – RedeTeste5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Atividade 2 – RedeTeste6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Atividade 3 – RedeTeste7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Atividade 4 – RedeTeste8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

198


Orientações gerais

Orientações gerais Entender o problema Em geral o problema é relatado pelo usuário e as informações são insuficientes Fazer o diagnóstico correto Pode haver mais de um erro de configuração Usar ferramentas disponíveis Comandos ping e traceroute Verificação das configurações de roteadores e hosts Verificação das rotas aprendidas pelos roteadores Ethereal para captura de pacotes

Na resolução de problemas, muitas vezes as informações fornecidas pelos usuários são insuficientes e tecnicamente incorretas. O usuário se baseia no feeling dele, naquilo que ele está vendo e pensando que está ocorrendo, que nem sempre é necessariamente a realidade.

É necessário um diagnóstico correto do problema, antes de fazer qualquer modificação na configuração. Procure usar procedimentos que não alterem a “cena do crime”. Não é uma boa idéia partir para “tentativa e erro”. Em geral esse procedimento aleatório introduz mais erros e até mascara o problema real. Lembre-se de que o problema pode ser ocasionado por uma série de erros e não apenas por um. Procure usar todas as ferramentas disponíveis para auxílio no diagnóstico e verificação.

Formação de grupos de trabalho Formar 4 grupos de trabalho Cada grupo deve resolver um problema proposto Tempo para resolução: 90 minutos Cada grupo deve preparar uma apresentação da solução para os demais grupos

Problemas propostos (1) RedeTeste5

Formação de grupos de trabalho O instrutor deve orientar a formação dos grupos e distribuir os problemas entre eles. O tempo previsto para solução é de 90 minutos.

Problemas propostos Problema 1 Esta rede apresenta uma configuração simétrica de roteadores com rotas alternadas. Em caso de falha de uma interface que está conectada ao switch1, por exemplo, há uma rota alternativa passando pelo switch2 e vice-versa. Por exemplo, o pc10 pode atingir o pc40 passando pelo router0, switch1 e router3. O caminho


199

alternativo é: router0, switch2 e router3. Ambas as rotas são iguais em termos de custo (número de hops).


Problema 2 Esta rede apresenta 4 redes locais interligadas por 3 roteadores em diferentes localidades. Portanto, as ligações entre os roteadores constituem uma rede WAN que serve de “ponte” entre as redes LAN. O rot02 tem duas redes locais, enquanto que os outros têm apenas uma rede local cada um. Os enlaces entre os roteadores rot01 e rot03 e entre rot01 e rot02 são linhas de longa distância dedicadas (enlaces seriais).


Problema 3 Esta rede apresenta 3 redes locais em localidades remotas interligadas por 3 roteadores. Foi utilizada uma subdivisão de uma rede Classe C que estava disponível: 201.38.10.0/24. A figura mostra o plano de endereçamento planejado pelo administrador da rede.


Resolução de problemas

Problema 4 Esta rede apresenta duas redes locais interligadas pela rede WAN de um provedor. O provedor utiliza os endereços da rede Classe B (131.100.0.0/16). As redes locais do cliente usam endereços IP privativos (RFC 1918), conforme mostrado na figura.

200


Apresentação das soluções Cada grupo apresenta para os demais Tempo por grupo: 15 minutos + 5 minutos para perguntas Tempo previsto total: 80 minutos


Apresentação das soluções O instrutor deve determinar a ordem de apresentação e controlar os tempos de cada grupo.

9 Sessão de aprendizagem 9 Resolução de problemas Roteiro de atividades Tópicos e conceitos \\Orientações

gerais

\\Formação

de grupos de trabalho

\\Problemas

propostos

\\RedeTeste5 \\RedeTeste6 \\RedeTeste7 \\RedeTeste8 \\Apresentação

das soluções

Competências técnicas desenvolvidas \\Testes

e verificação de funcionamento

\\Diagnóstico \\Correção

de problemas

de erros de configuração

Tempo previsto para as atividades \\180

minutos



202

Atividade 1 – RedeTeste5

A implementação foi feita utilizando duas subredes da rede 192.168.31.0/24, sendo uma subrede baseada no switch1 e a outra no switch2, conforme mostrado na figura. Infelizmente, alguns problemas surgiram: 1. O pc10 não consegue enxergar todos os outros PCs; 2. O mesmo ocorre com o pc40; 3. Nenhum roteador enxerga as interfaces eth1/192.168.31.19 do router2 e eth1/192.168.31.20 do router3. Siga os seguintes procedimentos para fazer o diagnóstico dos problemas (há mais de um erro de configuração) e corrigi-los: 1. Anote os passos do diagnóstico (ping, traceroute etc.) e os problemas encontrados; 2. Anote as correções efetuadas. Procure manter o esquema de endereçamento sempre que possível. Salve a configuração corrigida com outro nome que não seja RedeTeste5; 3. Teste a continuidade entre todos os PCs; 4. Verifique se todos os roteadores aprenderam as rotas de todas as redes; 5. Verifique se as rotas alternativas estão funcionando. Para isso, faça o seguinte teste: 1. Verifique se a rota do router0 para o pc40 passa pela interface eth0/192.168.31.4 (a alternativa é a interface eth1/192.168.31.20); 2. Abra o console do router3 e entre no modo de configuração da interface eth0, e dê o comando shut (coloca a interface em down); Roteamento avançado – Sessão de aprendizagem 9

203

3. Aguarde algum tempo até que o router0 aprenda a nova rota pela interface eth1/192.168.31.20 (lembre-se: o protocolo RIP demora um pouco para convergir); 4. -Verifique novamente as rotas aprendidas pelo router0; 5. Verifique a rota executando um traceroute do pc10 para o pc40. Nota: se no passo 5.1 a rota for pela interface eth1/192.168.31.20, faça o procedimento para a interface eth1. Anote todos os procedimentos e aguarde a orientação do instrutor para fazer a apresentação do problema para os outros grupos.

Atividade 2 – RedeTeste6 A implementação foi feita utilizando subredes da rede 10.10.0.0/16, conforme mostrado na figura.

Infelizmente, alguns problemas surgiram: 1. O PC-01 não consegue enxergar a rede além do Rot01; 2. O PC-03 não consegue enxergar a rede além do Rot03; 3. O PC-02 não consegue enxergar a rede além do Rot02; 4. O PC-04 não consegue enxergar a rede além do Rot02; 5. Os roteadores Rot01 e Rot03 não enxergam as redes do Rot02. Resolução de problemas


204

Siga os seguintes procedimentos para fazer o diagnóstico dos problemas (há mais de um erro de configuração) e corrigi-los: 1. Anote os passos do diagnóstico (ping, traceroute etc.) e os problemas encontrados; 2.

Anote as correções efetuadas. Procure manter o esquema de endereçamento sempre que possível. Salve a configuração corrigida com outro nome que não seja RedeTeste6;

3. Teste a continuidade entre todos os PCs; 4. Verifique se todos os roteadores aprenderam as rotas de todas as redes. Anote todos os procedimentos e aguarde a orientação do instrutor para fazer a apresentação do problema para os outros grupos.

Atividade 3 – RedeTeste7 A implementação foi feita utilizando subredes da rede 201.38.10.0/24, conforme mostrado na figura.

Infelizmente, alguns problemas surgiram: 1. Os PCs não conseguem enxergar todas as interfaces de seus respectivos roteadores; 2. A tabela de rotas dos roteadores não mostra todas as subredes.


205

Siga os seguintes procedimentos para fazer o diagnóstico dos problemas (há mais de um erro de configuração) e corrigi-los: 1. Anote os passos do diagnóstico (ping, traceroute etc.) e os problemas encontrados; 2. Anote as correções efetuadas. Procure manter o esquema de endereçamento sempre que possível. Salve a configuração corrigida com outro nome que não seja RedeTeste7; 3. Teste a continuidade entre todos os PCs; 4. Verifique se todos os roteadores aprenderam as rotas de todas as redes. Anote todos os procedimentos e aguarde a orientação do instrutor para fazer a apresentação do problema para os outros grupos.

Atividade 4 – RedeTeste8 A implementação foi feita utilizando subredes da rede 131.100.10.0/24 do provedor, conforme mostrado na figura.

Infelizmente, alguns problemas surgiram: 1. Os PCs não conseguem enxergar todas as interfaces de seus respectivos roteadores; 2. A tabela de rotas dos roteadores não mostra todas as subredes; 3. O provedor não aceitou a configuração proposta, alegando desperdício de endereços IP; 4. Questão especial: Curiosamente, testando a continuidade no console do router1, quando se executa o comando ping 131.100.10.15 (endereço IP da interface ser0/ router3), a resposta vem do endereço IP: 131.100.10.9 (interface ser0/ router0). Por quê? Resolução de problemas


206

Siga os seguintes procedimentos para fazer o diagnóstico dos problemas (há mais de um erro de configuração) e corrigi-los: 1. Anotar os passos do diagnóstico (ping, traceroute etc.) e os problemas encontrados; 2. Anotar as correções efetuadas. Procure manter o esquema de endereçamento sempre que possível. Salve a configuração corrigida com outro nome que não seja RedeTeste8; 3. Teste a continuidade entre os PCs; 4. Verifique se todos os roteadores aprenderam as rotas de todas as subredes. Anote todos os procedimentos e aguarde a orientação do instrutor para fazer a apresentação do problema para os outros grupos.


10 Sessão de aprendizagem 10 Roteamento multicast Sumário da sessão Endereçamento multicast – Camada 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Endereçamento multicast – Camada 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Serviços multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Tráfego multicast x unicast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Modelo IP multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Funcionamento do IP multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Conceito de MBone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Protocolo PIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Árvore de distribuição multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Algoritmo de roteamento multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Mensagens do protocolo PIM-SM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Multicast Source Discovery Protocol (MSDP). . . . . . . . . . . . . . . . . . . . . . . . . . 221 Protocolo MOSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Protocolo IGMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Requisitos de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 QoS na internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Topologia do multicast backbone RNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Malha multicast da RNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Conexão multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Conexão direta ao domínio PIM-SM/RNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Conexão via túnel GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231


208

Conexão via RP local e MSDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Conexão via RP local e MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Atividade 1 – Acesso ao conteúdo multicast. . . . . . . . . . . . . . . . . . . . . . . . . . 236


209

Endereçamento multicast – Camada 3 Endereços IP Classe D: 224.0.0.0 a 239.255.255.255 Grupos de endereços com características comuns Endereço 224.0.0.0/24 224.0.1.0 até 238.255.255.255 233.0.0.0/8 239.0.0.0/8

Descrição Permanentes Alcance global Atribuído para Sistemas Autônomos Endereços de alcance limitado

Endereços permanentes Endereço 224.0.0.1 224.0.0.2 224.0.0.5 224.0.0.12

Time to Live (TTL)

Utilização Todos os sistemas da subrede Todos os roteadores da subrede Roteadores OSPF DHCP

Endereçamento multicast – Camada 3 Multicast é uma maneira mais eficiente de enviar dados de uma fonte para vários destinos. Com ele, torna-se possível um nodo enviar dados a vários destinos fazendo apenas uma requisição à fonte, ocasionando uma redução de tráfego. O IP multicast é um mecanismo de comunicação em grupo que utiliza endereçamento IP de grupo (endereçamento classe D) para transmissão de um para muitos ou de muitos para muitos.

A cada endereço IP multicast é relacionado um grupo que pode conter de nenhum a vários dispositivos que receberam os pacotes IP multicast. O dispositivo que envia os pacotes IP multicast não é, necessariamente, um elemento pertencente àquele grupo, assim como não precisa saber quais são os membros daquele grupo. A classe D é utilizada somente para designar endereços de grupo. O endereço da fonte para os pacotes IP multicast é sempre um endereço unicast. A ligação do endereço IP do grupo multicast com o dispositivo pode ser considerada uma generalização da ligação com o endereço IP unicast. Enquanto o endereço IP unicast é atribuído a uma placa de rede de maneira que não possa mais ser utilizado, o endereço IP do grupo multicast é atribuído dinamicamente a várias placas de rede. Assim sendo, o endereço multicast pode se estender por toda a internet. Na tabela de grupos de endereços acima, os endereços da classe D estão subdivididos em grupos com características diferentes. Os grupos estão descritos conforme sua característica comum. Esta característica pode ser o alcance, ou seja, o limite até onde um determinado endereço pode atingir na internet, ou uma determinada finalidade.

Endereços permanentes A IANA restringiu o uso dos endereços 224.0.0.0/24 para protocolos de rede no interior de um segmento de rede local. Os pacotes que possuem estes endereços não podem ser passados pelos roteadores. Usualmente são enviados com valor de Time to Live (TTL) igual a 1. Estes endereços são utilizados pelos protocolos de rede para realizar uma descoberta automática de roteadores e para informações ligadas ao roteamento. A tabela acima fornece alguns exemplos de endereços permanentes ligados a protocolos de rede. Complementando os endereços permanentes existem os endereços reservados a aplicações 224.0.13.0/24, destinados a canais de notícias. A descrição completa dos endereços IP multicast reservados pode ser vista no RFC 1700.

Roteamento multicast


210

Endereços de alcance global Estes endereços são utilizados para transmissões IP multicast através da internet, por não possuírem qualquer tipo de restrição de alcance. Estão localizados entre 224.0.1.0 e 238.255.255.255. Existe uma subdivisão destes endereços, representada pelos endereços atribuídos para organizações com numeração reservada de sistema autônomo, também conhecidos como endereços GLOP. São os endereços 233.0.0.0/8.

Endereços de alcance limitado São endereços que possuem o alcance de uma organização ou de um grupo local, não podendo ser passados por seus roteadores para outros domínios. São os endereços 239.0.0.0/8.

Time to Live O campo TTL dos pacotes IP multicast é utilizado como parâmetro limitador de alcance, uma vez que ele controla o número de roteadores que o pacote pode passar. Quando o campo TTL de um pacote IP multicast tem o valor zero, este pacote é descartado, sem que o dispositivo responsável pelo seu envio receba qualquer notificação. Quando o TTL é igual a 1, uma rede local multicast pode encontrar todos os membros do grupo multicast nos vizinhos imediatos. Com TTL maior que 1, o pacote é passado a outras redes que possuam membros do grupo multicast. De acordo com o valor do TTL podemos determinar o alcance da transmissão; como exemplos temos: 1 para a rede local, 15 para a organização, 63 para a região e 127 para o mundo. Esta característica faz do TTL um mecanismo de confinamento da transmissão IP multicast. Também permite ao dispositivo implementar o expanding ring search para determinar o emissor de um grupo específico mais próximo. O dispositivo envia um pacote com TTL igual a 1 e espera por uma resposta. Caso não seja respondido, o dispositivo envia um pacote com TTL igual a 2. Caso não seja respondido, o dispositivo continua sistematicamente incrementando o valor do TTL até que descubra o emissor mais próximo. É um mecanismo semelhante ao usado na aplicação TraceRoute.


211

Endereçamento multicast – Camada 2 Broadcast Ethernet – FF:FF:FF:FF:FF:FF Multicast Ethernet Metade do bloco – 01:00:5E:00:00:00 Faixa 01:00:5E:00:00:00 – 01:00:5E:7F:FF:FF 23 bits de ordem mais baixa 5 bits desperdiçados

Endereçamento multicast – Camada 2 Para comunicações do tipo unicast, o destinatário processa as informações que possuem endereço Media Access Control (MAC), também conhecido como endereço físico, por estar gravado na sua placa de rede. As comunicações realizadas em broadcast são destinadas a todos os elementos da rede e possuem endereço de destino composto por uma seqüência completa de bits 1, fazendo FF:FF:FF:FF:FF:FF como endereço de destino.

Em uma comunicação IP multicast, vários receptores precisam estar aptos para receber um único fluxo de dados. Isto é conseguido através do endereço MAC comum a todos os receptores. Alguns mecanismos foram desenvolvidos a fim de permitir que várias máquinas, pertencentes ao mesmo grupo multicast, recebam o mesmo fluxo de dados e sejam diferenciadas de outros grupos multicast. Um desses mecanismos é a determinação estática do endereço MAC associado ao endereço IP multicast de cada grupo. Desta maneira, cada endereço IP multicast de um grupo sempre terá o mesmo endereço MAC. Este mecanismo está em oposição ao utilizado em unicast, que através do Address Resolution Protocol (ARP) relaciona um endereço IP a um endereço MAC. Através da determinação estática, as placas de rede podem receber pacotes destinados a endereços diferentes, sendo eles: seu próprio endereço unicast, endereço de broadcast e o endereço multicast. A rede local Ethernet suporta o envio de pacotes multicast através de endereços multicast nos quadros Ethernet. É necessário, portanto, o mapeamento de endereços IP multicast nos endereços multicast Ethernet. A IANA alocou para endereço MAC Ethernet o bloco 01.00.5E, sendo metade deste bloco alocado para endereçamento MAC multicast. A faixa vai de 01.00.5E.00.00.00 a 01.00.5e.7F.FF.FF. Um endereço IP multicast de um grupo de hosts é mapeado no endereço multicast Ethernet, inserindo os 23 bits de ordem mais baixa do endereço IP nos 23 bits de ordem mais baixa do endereço multicast Ethernet 01:00:5E:00:00:00 (em hexadecimal). Como o endereço IP multicast tem os primeiros 4 bits com valor x’1110’, dos 28 bits significativos sobram 5, que ficam “perdidos”, pois somente os últimos 23 bits são mapeados, conforme mostrado na figura da


212


esquerda, onde é exemplificada a determinação do endereço MAC a partir do endereço IP multicast do grupo, mostrando o prefixo de uma classe D, o número de bits do endereço IP, o número de bits perdidos e o número de bits utilizados. Devido à existência de bits do endereço IP que não são utilizados na composição do endereço MAC, alguns destes endereços atendem a mais de um grupo. Em razão disto, deve ser feita uma filtragem antes que a mensagem seja passada para a camada superior. Esta filtragem deve ser realizada com base no endereço IP de destino. Existem 32 (2**5) grupos de endereços IP multicast diferentes que possuem o mesmo endereço MAC multicast; este é um fato que não pode ser descartado durante a determinação de um IP multicast para um grupo. A figura da direita tem a relação dos 32 endereços IP que possuem o mesmo endereço MAC, e por esta razão devem ser evitados. Em resumo: evite endereços IP multicast que tenham os 23 bits de ordem mais baixa iguais.

Serviços multicast

Serviços multicast Objetivo: 1 fonte n destinos Comparação Unicast x Multicast

Entre os serviços que utilizam multicast incluem-se videoconferência, comunicações corporativas, ensino à distância, distribuição de software, informação de ações e notícias.

A evolução da internet trouxe mudanças na característica do tráfego. No início aconteciam trocas de pequenos arquivos e pequenos textos. Atualmente existe uma grande demanda por computação distribuída, som, vídeo e multimídia, consumindo cada vez mais os recursos da rede, como capacidade de tráfego e poder de processamento. A tecnologia IP multicast está em ascensão em todo o mundo, mostrando-se como a mais adaptada para a realização de videoconferências e computação distribuída, devido a sua facilidade de integração à estrutura existente e ao seu baixo investimento. Agregando mais serviços às redes configuradas, estas ficam em sintonia com a vanguarda da tecnologia. A figura acima compara, em termos de quantidade de pacotes, a diferença entre o tráfego unicast e multicast na distribuição de informações de uma fonte para múltiplos destinos.


213

Tráfego multicast x unicast

Tráfego multicast × unicast IP multicast – RFC 1112 Comparação de tráfego Tráfego Mbps

0,8

Streaming Áudio 8kbps/cliente

0,6 0,4

Unicast

Fonte: Cisco Network

0,2 0

Multicast 1

20

40

60

80

N. clientes 100

Modelo IP multicast Protocolos Multicast Dispositivos-Roteadores Protocolos Multicast Roteadores-Roteadores

Funcionamento do IP multicast Todos os dispositivos habilitados com multicasting


A tecnologia IP multicast é uma maneira mais eficiente de transportar os mesmos dados para vários usuários. Foi especificada na Request for Comment (RFC 1112), onde podemos encontrar detalhes sobre endereçamento, modelo de serviço e protocolos de roteamento. A figura acima mostra a comparação entre o tráfego de dados multicast e unicast para uma população de até 100 clientes, considerando um streaming de áudio de 8kbps por cliente.

Modelo IP multicast O modelo de serviço IP multicast propõe a existência de protocolos para a comunicação entre os dispositivos e o roteador de uma rede local e protocolos de comunicação entre os roteadores na internet. Este modelo está descrito na figura acima. Esses protocolos serão vistos adiante.

Funcionamento do IP multicast A figura acima mostra uma visão geral do funcionamento do IP multicast na comunicação entre redes. A parte superior expõe a comunicação multicast dentro da pilha de protocolos, com uma variedade dos possíveis protocolos a serem utilizados. Na parte inferior é mostrado o tráfego de uma transmissão multicast. Nesta figura todos os dispositivos envolvidos estão habilitados com multicast.

214


Conceito de MBone

Conceito de MBone Multicast Backbone (MBone) Internet Engineering Task Force (IETF) Ilhas multicasting interligadas p/ túneis ponto a ponto Encapsulamento em pacotes unicast

A primeira tentativa de utilizar o multicast na escala mundial foi através do Multicast Backbone (MBone), um projeto iniciado em 1992 com o objetivo inicial de fornecer transmissão de áudio em tempo real para a internet de encontros do Internet Engineering Task Force (IETF), via multicasting.

O MBone consiste de várias ilhas de redes de computadores que suportam multicast interligadas por conexões ponto a ponto que funcionam como túneis, onde os pacotes multicast são encapsulados em pacotes unicast. A figura acima mostra o diagrama de uma conexão do MBone. O mundo multicast esteve confinado a redes de túneis entre servidores Unix, sendo a sua utilização restrita a alguns centros de pesquisa e, apesar destas características, o MBone teve um crescimento razoável ao longo dos anos de utilização. A partir da padronização de alguns protocolos o multicast passou a ser configurado diretamente nos roteadores e switches da rede, dispensando o uso de equipamento para possibilitar o tráfego multicast. Esta característica é conhecida como multicast nativo. Além disto, a viabilização de alguns serviços torna hoje o multicast uma realidade da internet. \\MBONE:

Multicasting Tomorrow’s Internet: Classic book about MBONE, por Kevin Savetz, Neil Randall, e Yves Lepage, completo on-line http://www.savetz.com/mbone/

Protocolo PIM

Protocolo PIM Protocol Independent Multicast (PIM) PIM Dense Mode – PIM-DM (RFC 3973) PIM Sparse Mode – PIM-SM (RFC 4601) Protocolo de roteamento multicast Independe dos mecanismos do protocolo unicast Não armazena tabelas de rotas multicast Não troca mensagens de roteamento Algoritmo de roteamento RPF – Reverse Path Forwarding – PIM-DM RP – Rendez-vous Point – PIM-SM

A internet é composta por uma grande variedade de redes conectadas por roteadores. Quando uma fonte de uma informação estava localizada em uma rede e o destino em outra, a solução encontrada foi a criação de protocolos de roteamento que permitissem a construção e atualização de tabelas de roteamento entre os gateways. Os protocolos provêem um meio de transferência de informações de roteamento entre roteadores.

No roteamento unicast, o tráfego é roteado através da rede ao longo de um único caminho da fonte ao destino. O roteador unicast utiliza o endereço de destino e o modo de encaminhar o tráfego ao destino, mas não considera o endereço da fonte, enviando um único pacote através da única interface correta na direção do destinatário. Roteamento avançado – Sessão de aprendizagem 10

215

No roteamento multicast, a fonte envia o tráfego a um grupo de receptores, representados por um endereço de grupo multicast. O roteador multicast tem que determinar a direção da fonte e dos receptores. Quando existirem vários receptores, o roteador tem que replicar os pacotes e encaminhá-los na direção de cada receptor, o que não significa todas as direções. Os protocolos de roteamento podem utilizar dois modos, o modo denso — Dense Mode, ou o modo esparso — Sparse Mode. Os protocolos de modo denso pressupõem a existência densa de receptores e de grupos, isto é, várias subredes participando, com pelo menos um receptor em cada subrede. O tráfego multicast é distribuído segundo a árvore ligada à fonte onde, primeiramente, todas as interfaces são inundadas com o tráfego. As interfaces que não estão participando do grupo utilizam o recurso de poda (prune) para não receberem mais tráfego multicast. Entre esses protocolos podemos citar o Distance Vector Multicast Routing Protocol (DVMRP) e o Protocol Independent Multicast – Dense Mode (PIMDM). Para os protocolos de modo esparso é pressuposta a existência esparsa de receptores e de grupos, isto é, poucas subredes participando. O tráfego multicast pode ser distribuído segundo a árvore compartilhada ou segundo a árvore ligada à fonte. A interface só receberá tráfego se utilizar o recurso de união — join ao grupo. Este join se propaga até a fonte ou até o RP. Entre esses protocolos podemos citar o Protocol Independent Multicast – Sparse Mode (PIM-SM). O protocolo PIM-DM realiza roteamento multicast e, como o próprio nome diz, de maneira independente dos mecanismos fornecidos por algum protocolo de roteamento unicast que esteja sendo utilizado. Contudo, qualquer implementação de PIM-DM necessita da existência de um protocolo de roteamento unicast. Com isso, os roteadores multicast trabalham com as tabelas de roteamento unicast, não armazenam rotas específicas para multicast e não trocam mensagens de roteamento. Sua descrição está no RFC 3973. O algoritmo de roteamento utilizado é o RPF. Assim, quando um roteador habilitado com PIM-DM recebe um pacote multicast, ele verifica em sua tabela de rotas unicast se a interface de rede pela qual o pacote multicast chegou é a utilizada para enviar pacotes unicast à rede de origem. Se não for, o pacote é descartado e a mensagem de poda é enviada de volta à interface de rede de origem. Caso a verificação seja verdadeira, o pacote é enviado a todas as outras interfaces do roteador. Da mesma maneira que o PIM-DM, o protocolo PIM-SM realiza roteamento multicast, como o próprio nome diz, de maneira independente dos mecanismos fornecidos por algum protocolo de roteamento unicast que esteja sendo utilizado. Contudo, qualquer implementação de PIM-SM necessita da existência de um protocolo de roteamento unicast. Com isso os roteadores multicast trabalham com as tabelas de roteamento unicast, não armazenam rotas específicas para multicast e não trocam mensagens de roteamento. Sua descrição está contida na RFC 4601 (obsoletou o RFC 2362).


216


Neste protocolo é definido um ponto de encontro ou RP, o qual recebe as mensagens de união enviadas pelos dispositivos que visam um grupo específico. Quando uma fonte inicia uma transmissão multicast, o roteador mais próximo dela envia um registro para o RP, tornando-o um ponto intermediário necessário ao estabelecimento do tráfego multicast entre as fontes e seus respectivos receptores.

Árvore de distribuição multicast Árvore ligada à fonte Menor caminho

Árvore compartilhada Ponto de encontro

Árvore de distribuição multicast Roteadores multicast criam árvores de distribuição que controlam o caminho percorrido pelo tráfego multicast dentro da rede, com a finalidade de entregar o tráfego a todos os receptores. Estas árvores são criadas com base no endereço do grupo multicast e garantem que só será utilizado um caminho entre dois roteadores, evitando assim a ocorrência de loops.

A característica dinâmica dos grupos multicast, membros que entram e saem a qualquer momento, obriga a constantes atualizações do conteúdo das árvores. Existem dois tipos de árvore de distribuição: a ligada à fonte e a compartilhada. A árvore ligada à fonte é a forma mais simples das árvores de distribuição; possui seu ponto inicial na fonte do grupo multicast e suas ramificações se espalham pela rede até os receptores. Também é conhecida como árvore do menor caminho, por ser baseada no menor caminho unicast até o receptor. Caso a métrica do roteamento unicast seja feita com base em número de saltos, sua ramificação possuirá o menor número de saltos, e se for baseada no atraso possuirá o menor atraso. Diferentemente da árvore ligada à fonte, onde o ponto inicial da árvore era a fonte, a árvore compartilhada utiliza como marco inicial um ponto de encontro localizado em qualquer lugar da rede. Este ponto é chamado de raiz compartilhada ou Rendez-vous Point (RP). A utilização de RP faz com que a fonte envie todo seu tráfego ao RP e este por sua vez encaminhe o tráfego a todos os receptores. Os receptores têm que comunicar ao RP que desejam receber o tráfego; com isso não fica presumido que todos os dispositivos são receptores. Como conseqüência é criada uma árvore para cada grupo multicast, não importando quantas fontes existam para ele; somente os roteadores que pertençam à árvore conhecem a existência do grupo, assim como o tráfego é enviado apenas aos receptores que o requisitaram.


217

Algoritmo de roteamento multicast

Algoritmo de roteamento multicast (1)

Os algoritmos de roteamento multicast são utilizados para estabelecer caminhos através da rede. Estes caminhos permitem ao tráfego multicast atingir de maneira eficiente todos os receptores de cada grupo multicast, e devem seguir uma série de propósitos, sendo eles:

Checagem RPF

\\Rotear

dados somente para os receptores dos grupos;

Na figura à esquerda o pacote é aceito Na figura à direita o pacote é descartado

\\Utilizar

caminhos otimizados da fonte aos receptores;

\\Isenção \\Prover \\Não

de loops nas rotas;

escalabilidade de sinalização para criar e manter relacionamento de grupo;

concentrar tráfego em determinados enlaces.

O RPF é um conceito fundamental dentro do roteamento multicast, pois possibilita aos roteadores encaminharem o tráfego multicast corretamente através da árvore de distribuição a todos os receptores de cada grupo multicast. Utiliza a tabela de roteamento unicast existente para determinar se o pacote chegou através da interface utilizada para atingir a fonte. Caso o pacote tenha chegado através desta interface, este pacote é encaminhado para as outras interfaces. Em caso contrário, quando o pacote é recebido em uma interface que não é utilizada para atingir a fonte, o pacote é descartado. Quando pacotes multicast chegam em um roteador, ele executa uma checagem RPF em cada pacote. Quando a checagem é validada o pacote é encaminhado; quando não é validada o pacote é descartado. Checagem RPF para uma árvore ligada à fonte: \\O

roteador determina o endereço da fonte e consulta sua tabela de roteamento unicast para realizar a checagem RPF;

\\Caso

o pacote tenha chegado através da interface utilizada para atingir a fonte, a checagem RPF é validada e o pacote é encaminhado;

\\Caso

a checagem não tenha sido validada, o pacote é descartado.

Na figura à esquerda, o pacote chega pela interface S0, e é realizada a checagem RPF utilizando a tabela de rotas unicast. Como a checagem foi validada, o pacote foi transmitido a todas as outras interfaces. Na figura à direita o pacote chega pela interface S1, e daí é realizada a checagem RPF que utiliza a tabela de rotas unicast. Como a checagem não foi validada, o pacote foi descartado. Este procedimento evita os loops de roteamento e a “inundação” de pacotes multicast. Roteamento multicast

218


Algoritmo de roteamento multicast (2) Rendez-vous Point (RP)

A seleção do RP pode ser realizada de forma estática ou de forma dinâmica. Na maneira estática, a configuração de cada roteador deve fazer a indicação de qual será o RP. A escolha dinâmica do RP ocorre sempre no início da formação de um grupo multicast. Somente os segmentos de rede que possuem receptores ativos e que tenham realizado um pedido de recebimento de dados multicast receberão o tráfego multicast.

A árvore compartilhada é utilizada no estágio inicial da comunicação multicast. Dependendo da configuração utilizada, o tráfego pode continuar utilizando a árvore compartilhada ou passar a utilizar a árvore ligada à fonte mais otimizada. De acordo com a implementação pode ser feita uma opção para que seja somente utilizada a árvore compartilhada durante todo o tráfego multicast. O seu funcionamento pode ser visto na figura acima. Na Figura (a) a rede está no seu estado inicial, totalmente habilitada para IP multicast, porém ainda sem tráfego multicast. Na Figura (b) a fonte começa a transmitir para um grupo específico; o roteador da sua LAN então envia ao RP o tráfego multicast encapsulado em mensagens unicast de registro.

Algoritmo de roteamento multicast (3) Rendez-vous Point – RP (cont.)

Na Figura (c) o receptor 1 comunica ao roteador da sua LAN que deseja participar do grupo 224.1.1.1 através do IGMP; este roteador envia uma mensagem PIM-SM de união ao RP. Na Figura (d), o RP envia uma mensagem PIM-SM de união ao próximo roteador na direção da fonte, que também envia uma mensagem de união na direção da fonte, estabelecendo a conexão inicial entre o receptor e a fonte.


219


Na Figura (e) o RP já recebe tráfego multicast e envia uma mensagem de Parada de Registro, com a finalidade de cessar o tráfego de mensagens unicast de registro. Na Figura (f) o tráfego multicast é encaminhado ao RP e a partir dele chega até o receptor, ou seja, flui através da árvore compartilhada.


Na Figura (g) é iniciada a transição para a árvore ligada à fonte com uma mensagem de união do roteador C para o roteador A; durante a transição houve a ocorrência de pacotes duplicados na recepção. Na Figura (h) as mensagens de poda finalizam a transição entre as árvores de distribuição.



Na Figura (i) um novo receptor é indicado ao roteador que envia uma mensagem de união. Na Figura (j) está o fluxo final do tráfego multicast.

220


Mensagens do protocolo PIM-SM Tipos de mensagens 0 Hello Enviado periodicamente 1 Register Registra a fonte no RP 2 Register-Stop Pára o registro no RP 3 Join/Prune Join une e Prune poda membros 4 Bootstrap Determinação dinâmica do RP 5 Assert Encaminhamento de pacotes 6 Candidate RP Determinação do RP

Mensagens do protocolo PIM-SM As mensagens dividem-se, basicamente, em dois grupos: o grupo de descoberta de vizinhos e o grupo de controle. Todas as mensagens são encapsuladas em pacotes IP. As mensagens de Hello são utilizadas pelos roteadores habilitados com PIM para a descoberta de roteadores habilitados com PIM próximos. Estas mensagens são enviadas periodicamente, endereçadas ao IP 224.0.0.13 (grupo de todos os roteadores habilitados com PIM). Os roteadores não enviam avisos de recebimento para mensagens deste tipo.

Diferentemente dos protocolos de modo denso, quando uma mensagem de Hello é recebida em uma determinada interface, esta não é automaticamente adicionada à lista de interfaces de saída para encaminhamento do tráfego multicast. É necessário o recebimento de uma mensagem de união (join) para que o tráfego seja entregue àquela interface. Quando um dispositivo pretende participar de um grupo multicast, este envia ao roteador uma mensagem de união IGMP, significando que o roteador pode começar a aceitar tráfego multicast para aquele grupo. Com o intuito de aceitar o tráfego, o roteador notifica o RP que pretende participar da sua árvore de distribuição através de uma mensagem PIM-SM de união, indicando o grupo do qual aceitará o tráfego. Esta mensagem é enviada ao endereço unicast do RP e ao endereço multicast 224.0.0.13 (grupo de todos os roteadores habilitados com PIM), de forma que todos os roteadores com PIM habilitado são notificados desta união, mas somente os roteadores no caminho do RP realizarão a união. Este mesmo mecanismo é utilizado para a poda. Quando o primeiro roteador recebe os pacotes multicast, estes são encapsulados em mensagens unicast de registro e enviados ao RP, a partir do momento em que um receptor faz o pedido de união ao RP. O RP faz essa união até a fonte; este processo pode ser visualizado nas figuras (b), (c), (d) e (e) anteriores. No início o RP recebe o tráfego multicast duplicado, uma vez que está recebendo o tráfego encapsulado nas mensagens de registro e o tráfego multicast de dados. Quando o RP recebe os pacotes multicast da fonte e os pacotes encapsulados, envia uma mensagem de Parada de Registro. Este tipo de mensagem notifica ao primeiro roteador que o tráfego multicast agora deverá ser enviado apenas via multicast.


221

Em redes com multi-acesso, isto é, redes com vários roteadores de acesso, podem ocorrer caminhos paralelos para a fonte ou para o RP, podendo implicar aos membros do grupo o recebimento de pacotes duplicados através dos múltiplos roteadores. Com o intuito de evitar esse problema, o PIM-SM utiliza as mensagens de Assert, que determinam o roteador responsável por encaminhar o tráfego multicast para aquela rede. As mensagens de Bootstrap são utilizadas na determinação dinâmica do RP e na propagação da informação sobre o RP, sendo enviadas para todos os roteadores PIM através do IP 224.0.0.13. O roteador eleito a partir deste mecanismo é chamado de bootstrap router (BSR). Quando um ou mais roteadores são configurados para serem candidatos a BSR, eles inundam a rede com a informação de que são candidatos. O roteador com a maior prioridade será eleito o BSR. Caso as prioridades sejam iguais, o roteador eleito BSR será aquele que possuir o maior endereço IP.

MSDP (1)

Multicast Source Discovery Protocol (MSDP) Protocolo que permite aos RPs de cada AS trocarem informações acerca das fontes de informação. Uma fonte contacta o RP local e este distribui essa informação por uma árvore de RPs, usando ligações TCP dedicadas para o efeito. Os RPs que tiverem membros no seu domínio registram-se na fonte de modo a participarem da árvore de escoamento. Cada Rendezvous Point (RP) é configurado com a identificação dos RPs com os quais vai estabelecer trocas de informação. Quando uma nova fonte se registra, esta informação é disseminada para os restantes RPs numa mensagem designada por Source Active (SA). As mensagens SAs são propagadas deste modo por uma árvore de escoamento estabelecida entre os RPs. Esta árvore é estabelecida, seguindo regras de RPF para decidir os anúncios que devem ser inundados e os que devem ser descartados.


222

Escola Superior de Redes RNP Responsável pela:

MSDP (2)

\\Interconexão

de domínios PIM-SM;

\\Troca

de informações entre RP’s em diferentes domínios multicast;

Importante para: \\Viabilizar

multicast entre AS’s;

\\Permitir

domínios PIM-SM locais com alguma independência.

Protocolo MOSPF

Protocolo MOSPF (1) Extensão multicast do protocolo OSPF v2 Envia pacotes multicast diretamente Uma cópia por enlace Não utiliza túneis unicast As decisões de roteamento dependem da origem Datagramas marcados com ToS (cabeçalho IP) minimize delay maximize throughput maximize reliability minimize monitary cost normal service

A extensão multicast para o protocolo de roteamento IP Open Shortest Path First (OSPF) é denominada Multicast Open Shortest Path First (MOSPF). O protocolo OSPF é baseado no estado dos enlaces, diferente do RIP, que é baseado na contagem dos nodos. Uma rede de roteadores utilizando MOSPF pode enviar pacotes multicast diretamente, enviando não mais que uma cópia por cada enlace, e sem a necessidade de túneis.

O MOSPF transmite os datagramas IP multicast da origem para os vários membros do grupo sem formar laços, gerando uma árvore. Esta árvore tem como raiz o nodo de origem do datagrama, e todos os “braços” terminam em membros do grupo. Seguindo a filosofia multicast, o datagrama é replicado apenas quando surge uma divisão, um braço, na árvore. Este esquema de roteamento, onde o caminho dos datagramas depende da origem e dos destinos (já que a árvore possui raiz na origem), é denominado source/destination routing. Ele é diferente da maioria dos algoritmos de roteamento unicast (incluindo o OSPF), que se baseiam somente no destino do datagrama ao fazer o roteamento. A necessidade de considerar a origem para tomar as decisões do roteamento causa maior quantidade de cálculos de roteamento, porém resulta em melhores caminhos em termos de utilização da rede e atraso para membros individuais do grupo. No MOSPF, os datagramas são marcados com a sua classificação do Type of Service (TOS), baseada em um dos cinco valores mutuamente exclusivos: minimize delay, maximize throughput, maximize reliability, minimize monitary cost e normal service. O caminho do datagrama multicast no MOSPF pode variar de acordo com a classificação TOS utilizada. Por exemplo, um tráfego multicast sensitivo ao delay (retardo) pode seguir rotas diferentes de uma aplicação multicast de alto throughput (vazão).


223

Apenas um bit pode estar ligado, indicando um dos quatro primeiros tipos de serviço. Se nenhum bit estiver ligado, a indicação é de serviço normal. O protocolo MOSPF possui a capacidade de encaminhar datagramas multicast de uma rede IP para outra. O encaminhamento é feito com base em Novo tipo de LSA: group membership LSA ambos os endereços de origem e destino (também Os membros dos grupos são adicionados ao BD OSPF chamado source/destination routing). O banco de O caminho multicast é calculado pelo algoritmo SPF Os caminhos que não têm membros são podados dados do estado de enlace fornece uma descrição A origem pode estar em outra área OSPF ou em outro AS completa da topologia do Sistema Autônomo. Características do roteamento multicast Adicionando um novo tipo de LSA (anúncio de estado Source/destination routing do enlace) chamado group membership LSA, a Caminho de menor custo Nas bifurcações o datagrama é replicado localização de todos os membros dos grupos Caminho único entre fonte e destino (sem rota alternativa) multicast é destacada no BD. O caminho de um Os pacotes IP são encaminhados como multicast de enlace datagrama multicast pode então ser calculado construindo uma árvore de caminhos mais curtos (shortest-path tree), cuja raiz está na origem do datagrama.

Protocolo MOSPF (2)

Todos os ramos da árvore que não contenham membros multicast são podados (pruned) da árvore. Essas árvores de caminhos mais curtos são inicialmente construídas quando o primeiro datagrama é recebido, ou seja, sob demanda. Os resultados dos cálculos de caminho mais curto são então armazenados (cached) para uso pelos datagramas seguintes que tenham a mesma origem e destino. OSPF particiona um Sistema Autônomo em áreas, o que faz com que o conhecimento da topologia global do Sistema Autônomo se perca, porque cada área só conhece a sua própria topologia. Quando é preciso fazer roteamento multicast entre as áreas, as árvores de caminho mais curto (shortest-path trees) ficam incompletas, gerando ineficiência no roteamento. Um situação análoga ocorre quando a origem do datagrama multicast fica em outro AS. Em ambos os casos acima descritos (áreas OSPF ou ASs diferentes), a vizinhança próxima à origem é desconhecida. Nesses casos, a vizinhança é conhecida de forma aproximada através de anúncios de resumo de enlaces (OSPF summary link advertisements) ou de enlaces externos do AS (OSPF AS external link advertisements). À medida que o datagrama é encaminhado através da árvore, a partir de seu caminho mais curto (shortest-path tree), o datagrama é entregue a cada membro do grupo multicast de destino. No MOSPF o roteamento multicast tem as seguintes características: \\O

caminho seguido pelo datagrama multicast depende da origem e do destino; esse roteamento é chamado roteamento origem/destino, contrastando com os algoritmos de roteamento unicast (como o OSPF) que roteiam com base somente no endereço de destino;

\\O

caminho entre a origem do datagrama e um destino qualquer é o de menor custo disponível (custo é a métrica do OSPF);


224

Escola Superior de Redes RNP \\O

MOSPF usa os caminhos de menor custo para atingir os membros do grupo multicast. Entretanto, quando os membros do grupo multicast estão dispersos em múltiplas redes, o datagrama precisa ser replicado de vez em quando. Esta replicação é feita o mínimo possível (utilizada somente nas bifurcações);

\\Para

um determinado datagrama multicast, todos os roteadores calculam uma árvore de caminho mais curto (shortest-path tree) idêntica. Existe somente um caminho entre a origem e o destino do datagrama. Isto significa que não há previsão de rota alternativa, ao contrário do que ocorre no roteamento unicast OSPF;

\\Em

cada hop, o MOSPF normalmente encaminha o datagrama IP multicast encapsulado num quadro multicast de enlace de dados.

Protocolo IGMP

Protocolo IGMP Troca de informações entre host e roteador É uma extensão do ICMP Mensagens encapsuladas em datagramas IP RFC 2236 – ICMPv2 Mensagens IGMP Membership query Membership report (v1) Membership report (v2) Leave group

O IGMP é um mecanismo utilizado para troca de informações entre um dispositivo e o roteador multicast mais próximo, permitindo determinar se um pacote multicast deve ser enviado a uma rede específica, usado para entrar e sair de grupos multicast. É considerado uma extensão do ICMP; suas mensagens são encapsuladas nos datagramas IP e sua versão 2 está descrita integralmente no RFC 2236. Atualmente o IGMP se encontra na versão 2; já existem implementações da versão 3 beta.

Todas as especificações desta versão estão descritas no RFC 1112. Abordaremos seu funcionamento bem como o formato das suas mensagens. As mensagens podem ser de dois tipos: pergunta por participação (membership query) ou relatório de participação (membership report). Quando alguma aplicação inicia um socket multicast, a pilha de protocolos TCP/IP do dispositivo envia, automaticamente, uma mensagem do tipo relatório de participação. Como esta mensagem é enviada com referência a um determinado grupo multicast, indicando que deseja participar deste grupo, o dispositivo também determina o endereço MAC deste grupo. O roteador transmite, a cada 60 segundos e a todos os dispositivos da rede, mensagens do tipo relatório de participação, a fim de verificar se existe pelo menos um participante dentro da subrede interessado em receber tráfego do grupo. Uma vez que o roteador não receba resposta, envia 3 mensagens do tipo “pergunta por participação”, em espaços de 60 segundos. Quando não recebe resposta a essas 3 mensagens, o roteador determina o fim do tráfego daquele grupo para aquela subrede. As mensagens do tipo relatório de participação, quando originadas no roteador, são destinadas a todos os dispositivos da rede, através do IP 224.0.0.1, e possuem valor de TTL igual a 1.


225

O pacote IGMPv1 possui 64 bits, com os campos de versão, tipo, checksum e endereço do grupo multicast, como pode ser visto na figura acima (na parte superior). O IGMPv2 veio substituir a sua versão anterior e, atualmente, é a versão padrão. As mensagens podem ser de quatro tipos: pergunta por participação (membership query), relatório de participação para a versão 1 (membership report), relatório de participação para a versão 2 (membership report) e sair do grupo (leave group). Seu funcionamento é, basicamente, o mesmo da versão anterior. A principal diferença é a existência de um novo tipo de mensagem: sair do grupo. Através desta mensagem o dispositivo pode comunicar ao roteador multicast local que possui a intenção de sair do grupo, que envia uma mensagem do tipo relatório de participação para aquele determinado grupo, a fim de determinar se existe mais algum outro dispositivo interessado em continuar recebendo o tráfego daquele grupo. Se não existir resposta em aproximadamente três segundos, o roteador pára de encaminhar o tráfego para aquela interface. A adição da mensagem do tipo sair do grupo reduziu, quando comparada com a versão anterior, a latência de saída de um grupo, fazendo com que o tráfego desnecessário e sem utilidade seja cessado muito antes. Com o intuito de evitar tráfego desnecessário de mensagens do tipo relatório de participação, duas técnicas são utilizadas: \\Quando

um dispositivo recebe uma mensagem do tipo pergunta por participação, antes de enviar um relatório de participação é inicializado um contador para cada participação em grupo. Cada contador é configurado com uma escolha randômica de zero a D segundos. Quando este tempo expira, a mensagem de relatório de participação é enviada para aquele grupo. Logo, as mensagens de relatório de participação são propagadas dentro de um intervalo de D segundos.

\\Quando

uma mensagem de relatório de participação é enviada e possui como endereço de destino o IP do grupo ao qual ela se refere e o campo TTL tem valor igual a 1, os outros participantes que estejam na mesma rede verificam que já foi enviado o relatório. Se um dispositivo percebe que já foi enviada uma mensagem de relatório para o grupo ao qual ele pertence, o seu contador é automaticamente paralisado, não gerando a sua mensagem de relatório. Usualmente é enviada como resposta apenas uma mensagem de relatório para cada grupo dentro de uma subrede.

O pacote IGMPv2 possui 64 bits, com os campos de tipo, tempo máximo de espera para uma resposta, checksum e endereço do grupo multicast, como pode ser visto na figura acima (na parte inferior).


226


Requisitos de QoS

Requisitos de QoS Redes IP não garantem QoS (melhor esforço) Parâmetros de QoS Retardo fim-a-fim Taxa de perda de pacotes Jitter Vazão Exemplo de experimento de videoconferência

As redes IP atuais oferecem um serviço de entrega de pacotes chamado de “melhor esforço”, que não oferece garantias de desempenho para seus usuários; pacotes podem ser perdidos em trânsito. As aplicações tradicionais (www, correio eletrônico, transferência de arquivos) requerem confiabilidade, garantida através do uso do protocolo de transporte TCP. Estas aplicações são chamadas de “elásticas”, pois não requerem uma capacidade mínima de transmissão ou retardo máximo para funcionarem corretamente.

O retardo, a perda de pacotes e a capacidade de transmissão da rede são muito importantes para as aplicações de mídia contínua pois, embora elas possam tolerar pequenas perdas de pacotes, em contrapartida impõem restrições severas de temporização ou de capacidade mínima de transmissão para garantir sua própria viabilidade. Ao atraso total que um pacote experimenta durante o seu trajeto pela rede dá-se o nome de retardo fim-a-fim. Este é a soma dos retardos associados aos comutadores ou roteadores e aos enlaces intermediários, os quais são devidos ao processamento de comutação, à espera em filas aguardando retransmissão, ao tempo de transmissão pela interface, ao enlace e ao tempo de propagação pelo enlace. A ocorrência de congestionamento causa aumento no tamanho das filas e conseqüentemente no retardo. Além disto, pode haver uma variação no retardo fim-a-fim, chamada jitter. Uma aplicação de reprodução poderá eliminar o jitter através do uso de um buffer de recepção, adiando com ele o “ponto de reprodução” do fluxo recebido. A conseqüência deste tratamento do jitter é o aumento do retardo fim-a-fim. A taxa de perda de pacotes é calculada no lado do receptor como a razão entre as quantidades de pacotes perdidos e a quantidade de pacotes transmitidos, em cada intervalo de tempo considerado. As perdas de pacotes em aplicações de mídia contínua geralmente devem-se ao descompasso entre a taxa de transmissão (ou demanda) dos pacotes e à capacidade de transmissão do canal, o que leva ao congestionamento em um ou mais roteadores da rede, com o conseqüente crescimento das filas de pacotes, aumento de retardo e eventual descarte dos pacotes. Um dos principais atributos de um enlace de transmissão de dados é sua capacidade nominal de transportar bits, ou banda nominal. A vazão ou a banda de rede ocupada pela mídia corresponde à taxa de bits que são efetivamente transportados, tendo como valor máximo a banda nominal. Uma bancada de testes montada em laboratório (ver figura acima) permitiu examinar, no enlace serial entre os dois roteadores, o efeito da concorrência entre Roteamento avançado – Sessão de aprendizagem 10

227

dois tipos de tráfego: o tráfego de videoconferência da estação Videocon1 à estação Videocon2, e o tráfego cruzado (sintético) da estação Tráfego1 à estação Tráfego3. Os dois tipos de tráfego foram gerados com os softwares NetMeeting 3.01 da Microsoft e NetSpec 3.0, respectivamente. Interpretação dos resultados Embora simples, o experimento realizado permitiu examinar o comportamento da videoconferência pessoal em situações importantes. Em primeiro lugar, confirmou a intuição de que o mais importante para o sucesso da transmissão é providenciar banda nominal suficiente no canal para acomodar a taxa de transmissão utilizada. Quando foi gerado tráfego com taxas superiores à banda nominal, os parâmetros de QoS (perdas, retardo e jitter) registraram a deterioração da qualidade. Na prática, então, a taxa de transmissão da videoconferência deveria ser configurada para se manter dentro da banda efetivamente disponível.

QoS na internet

QoS na internet

Integrar diferentes tipos de tráfegos em uma rede comutada de pacotes de forma escalável e flexível é uma solução almejada, sobretudo se considerarmos que esta rede é a internet. O que dificulta esta integração é que aplicações de tempo real têm necessidades diferentes daquelas das aplicações Espaço de armazenamento e sobrecarga nos roteadores convencionais. O modelo de serviço tradicional Recursos especiais nos roteadores oferece somente serviço de melhor esforço, Serviços diferenciados Prioridade relativa sobre outras aplicações bastante adequado para um grande número de Dependendo da carga da rede o desempenho é inaceitável aplicações (que não são sensíveis ao tempo). Entretanto, o serviço de melhor esforço não é adequado para tráfego sensível a atrasos, perdas de pacotes ou variações no atraso. Estes tipos de distorções podem diminuir severamente a qualidade da transmissão de tempo real, podendo até mesmo inviabilizá-la.

Aplicações de tempo real x aplicações convencionais Propostas do IETF Serviços integrados (IntServ) – RFC 1633 Serviços diferenciados (DiffServ) – RFC 2475 Problemas Serviços integrados

Para atender às necessidades de uma aplicação de tempo real (vídeo sob demanda, videoconferência etc), faz-se necessária a inserção de novas características à infra-estrutura para oferecer qualidade de serviço. Com a preocupação de tratar tais necessidades para o ambiente de tráfego da internet, duas abordagens distintas de fornecimento de serviços foram propostas pelo Internet Engineering Task Force (IETF) nos últimos anos: a Arquitetura de Serviços Integrados e a Arquitetura de Serviços Diferenciados. O modelo de serviços integrados é caracterizado pela reserva de recursos e pelo controle de admissão. Para aplicações de tempo real, antes da transmissão dos dados, as aplicações devem configurar caminhos e reservar recursos. O Resource Reservation Protocol – RFC 2205 (RSVP) é um protocolo de sinalização para configurar caminhos e reservar recursos. O modelo propõe duas classes de Roteamento multicast


228

serviço além do serviço de melhor esforço. O primeiro é o serviço garantido para aplicações que exigem limites fixos de atraso. O segundo é o serviço preditivo ou de carga controlada para aplicações que exigem um limite probabilístico de atraso. A filosofia deste modelo determina que “existe uma exigência inescapável para roteadores serem capazes de reservar recursos de forma a fornecer QoS especial para seqüências específicas ou fluxos de pacotes de usuários. Este, por sua vez, exige estado de fluxo específico nos roteadores”. Os problemas com a Arquitetura de Serviços Integrados são: A quantidade de informação de estado aumenta proporcionalmente com o número de fluxos. Isto exige enorme espaço de armazenamento e gera sobrecarga de processamento nos roteadores. Por esta razão, esta arquitetura não é escalável para o núcleo da internet. A exigência nos roteadores é alta; todos devem implementar RSVP, controle de admissão, classificação MF e escalonamento de pacotes. Devido à dificuldade em implementar e empregar puramente serviços integrados e RSVP, foram introduzidos serviços diferenciados. O esforço de serviços diferenciados no IETF desenvolveu um modelo simples para diferenciar qualidades na entrega de pacotes. O modelo assume que cada pacote carrega um valor apropriado no campo DS (anteriormente chamado byte TOS – Type Of Service) do cabeçalho IP. Cada campo DS corresponde a um tratamento diferente de encaminhamento, chamado Per Hop Behavior (PHB). Dentro do núcleo da rede, roteadores ordenam pacotes de entrada em diferentes classes de encaminhamento, de acordo com seus valores de DS. Logo, o modelo de serviços diferenciados é essencialmente um esquema de prioridade relativa. Afim de que um cliente receba serviços diferenciados a partir de seu provedor de serviços de internet (Internet Service Provider – ISP), ele deve ter um Service Level Agreement (SLA) com seu ISP. Um SLA basicamente especifica as classes de serviços suportadas e a quantidade de tráfego permitida em cada classe. Clientes podem marcar o campo DS de pacotes individuais para indicar o serviço desejado, ou podem ser marcados pelo roteador. Serviços diferenciados, como já foi descrito, são um refinamento do esquema de prioridades relativas, cuja principal desvantagem é assegurar desempenho às aplicações apenas em termos relativos. Esquemas de prioridade relativa garantem que uma aplicação que esteja gerando tráfego de determinada prioridade terá desempenho melhor que outra gerando tráfego de menor prioridade. Entretanto, dependendo da carga da rede, ambas as aplicações podem ter desempenho muito aquém de suas reais necessidades.


229

Topologia do multicast backbone RNP Topologia de interconexão dos PoPs da RNP

Topologia do multicast backbone RNP Em 2001, a RNP realizou diversos testes com a tecnologia multicast em seu backbone. Eles fizeram parte de um projeto piloto na área de multicast, cujo objetivo principal era adquirir conhecimento técnico necessário para fornecer esta tecnologia como um serviço de produção no backbone RNP2.

Os testes envolveram Pontos de Presença (PoPs) da RNP em várias localidades. Foi feita a configuração de multicast nativo em roteadores de produção do backbone RNP2, cuja operação foi avaliada em termos de estabilidade no roteamento unicast e desempenho nas funções relativas ao roteamento multicast. O projeto piloto forneceu subsídios para a implantação de um serviço multicast de produção na RNP. É nesta fase de implantação que a RNP encontra-se atualmente. O backbone atual da RNP é composto de roteadores e switches de diversos modelos, interconectados através de enlaces DWDM (10Gbps) e PDH (34Mbps). A figura acima ilustra a topologia de interconexão dos PoPs no backbone RNP2. http://www.rnp.br/backbone/

Topologia do multicast backbone RNP Malha PIM-SM

Com a implantação do backbone RNP2 nos anos de 2000 e 2001, 13 dos 27 PoPs da RNP receberam roteadores da Cisco que incluíam suporte para realizar roteamento multicast nativo. Este suporte era basicamente garantido pela versão de Internetwork Operating System (IOS) fornecida com estes roteadores, que garantia funcionalidades básicas para multicast nativo, como Protocol Independent Multicast (PIM) e Internet Group Management Protocol (IGMPv2).

Os 13 PoPs que receberam roteadores multicast foram: RJ, SP, DF, MG, RS, SC, PR, BA, PE, CE, RN, GO e PB. Uma vez que todos estes apresentam condições de realizar roteamento multicast nativo, todos foram incluídos em uma topologia multicast utilizando PIMSM (PIM Sparse Mode). O uso de PIM-SM é muito recomendado para uso em backbones e redes WAN por suas características em termos de escalabilidade e economia de banda. Além disso, seu uso pode ser considerado padrão de facto nas atuais implantações de multicast nativo, incluindo grandes backbones americanos como o da Sprint. A figura acima mostra os PoPs que estão conectados nesta malha PIM-SM, assim como os enlaces ATM que estão com multicast nativo habilitado. Conforme ilustrado na figura acima, percebe-se que a topologia é em forma de estrela, Roteamento multicast

230


partindo do PoP-RJ. De fato, é no PoP-RJ que foi configurado o Rendezvous Point (RP) da rede PIM-SM. O protocolo PIM-SM será explicado mais adiante. A implantação desta estrutura multicast foi bastante simples, com o uso de três comandos: \\Habilitação

de multicast global nos roteadores ip multicast-routing distributed

\\Habilitação

de PIM-SM nas interfaces ATM da estrutura acima ip pim sparse-mode

\\Indicação

estática do endereço IP do RP ip pim rp-address 198.32.252.238

Durante a implantação, não houve nenhum tipo de alteração no desempenho global dos roteadores, o que garantiu a estabilidade na operação do backbone. Este fato foi ajudado pelo baixo volume de tráfego multicast no backbone durante esta fase inicial.

Malha multicast da RNP

Malha multicast da RNP Conexão multicast com o backbone RNP2 Anexação ao domínio PIM-

Criação de domínio PIM-SM

SM da RNP:

local:

• Uso do RP mantido pela RNP

• Uso de RP próprio

• Configuração simples

• Configuração mais complexa

• Somente PIM-SM necessário

• PIM-SM e MSDP requeridos

Conexão com domínios locais multicast: \\MSDP

para conexão entre o RP local e o RP mantido pela RNP.

Conexão com outros AS’s: \\Conexão

via MSDP + MBGP;

\\Internet2,

RedeRio.

Malha nativa PIM-SM: \\Qualquer \\Mais

cliente da RNP pode utilizá-lo;

fácil de utilizar (menos configuração);

\\Recomendado

para cenário de poucos clientes, ambientação com a tecnologia.

Roteador RP no PoP-RJ: \\rp.bb3.rnp.br


(200.143.254.9)

231

Conexão multicast

Conexão multicast

Conexão direta ao domínio PIM-SM/RNP

Conexão direta ao domínio PIM-SM/RNP Conectar os roteadores do laboratório à malha PIMSM da RNP: \\Habilitar

o roteamento multicast em todos os roteadores;

\\Habilitar

PIM-SM nas interfaces de interesse;

\\Configurar

o endereço do RP nos roteadores.

router(config)#ip multicast-routing router(config)# router(config)#interface Ethernet0 router(config-if)#ip pim sparse-mode router(config)# router(config)#interface Ethernet1 router(config-if)#ip pim sparse-mode router(config)# router(config)#ip pim rp-address 200.143.254.9 router(config)#

Conexão via túnel GRE

Conexão via túnel GRE Conectar os roteadores do laboratório à malha PIMSM da RNP, através de um túnel GRE para um roteador do backbone.


232

Escola Superior de Redes RNP router(config)# interface Tunnel 1 router(config-if)# ip unnumbered Ethernet 0 router(config-if)# ip pim sparse-mode router(config-if)# tunnel source ethernet 0 router(config-if)# tunnel destination 192.0.2.33 router(config-if)# exit router(config)#ip mroute 0.0.0.0 0.0.0.0 tunnel 1

Conexão via RP local e MSDP

Conexão via RP local e MSDP Criar um domínio local PIM-SM com RP próprio e conexão MSDP à malha multicast da RNP.

router(config)# ip access-list standard borda-multicast router(config-std-nacl)# deny 224.0.1.39 router(config-std-nacl)# deny 224.0.1.40 router(config-std-nacl)# deny 239.0.0.0 0.255.255.255 router(config-std-nacl)# permit any router(config-std-nacl)# exit router(config)# router(config)# interface Ethernet0 router(config-if)# ip multicast boundary borda-multicast router(config)# access-list router(config)# access-list router(config)# access-list router(config)# access-list router(config)# access-list router(config)# access-list router(config)# access-list router(config)# access-list router(config)# access-list router(config)# access-list 0.255.255.255 router(config)# access-list 0.255.255.255 any router(config)# access-list 0.255.255.255 any router(config)# access-list 0.15.255.255 any Roteamento avançado – Sessão de aprendizagem 10

111 111 111 111 111 111 111 111 111 111

deny deny deny deny deny deny deny deny deny deny

ip ip ip ip ip ip ip ip ip ip

any any any any any any any any any any

host 224.0.2.2 host 224.0.1.3 host 224.0.1.24 host 224.0.1.22 host 224.0.1.2 host 224.0.1.35 host 224.0.1.60 host 224.0.1.39 host 224.0.1.40 239.0.0.0

111 deny ip 10.0.0.0 111 deny ip 127.0.0.0 111 deny ip 172.16.0.0

233

router(config)# access-list 111 deny ip 192.168.0.0 0.0.255.255 any router(config)# access-list 111 permit ip any any router(config)# router(config)# ip msdp peer 200.143.254.9 connect-source loopback0 router(config)# ip msdp sa-filter in 200.143.254.9 list 111 router(config)#

Conexão via RP local e MSDP

Conexão via RP local e MSDP (cont.)

Protocolos utilizados no backbone multicast da RNP:

Verificação

\\PIM-SM

router# show ip msdp summary MSDP Peer Status Summary Peer Address 192.0.2.10 192.0.2.25 router#

AS

65001

65500

State

Up

Up

Uptime/

Reset SA

Peer Name

4d15h

7

peer1.net

Downtime Count Count 4d10h

7

28

4212

peer2.com

(roteamento interno multicast)

\\MSDP

(anúncio de fontes ativas entre domínios)

\\MBGP

(fora do escopo deste laboratório)

Nome DNS do roteador RP da RNP: \\rp.bb3.rnp.br

(200.143.254.9)

Tipos de conexão com a malha PIM-SM da RNP: \\Anexação \\Criação


ao domínio PIM-SM da RNP

de domínio local + MSDP



234

10 Sessão de aprendizagem 10 Roteamento multicast Roteiro de atividades Tópicos e conceitos \\Conceito

de endereçamento multicast

\\Protocolo

PIM

\\Protocolo

MOSPF

\\Protocolo

IGMP

\\Requisitos

de QoS

Competências técnicas desenvolvidas \\Entender

o ambiente multicast

\\Entender

o funcionamento dos protocolos multicast

\\Entender

o conceito de QoS

\\Utilizar

aplicações multimídia na internet

Tempo previsto para as atividades \\30

minutos


236


Atividade 1 – Acesso ao conteúdo multicast 1. Baixe e instale o VLC Media Player \\http://www.videolan.org/vlc/

2. Baixe um vídeo “.wmv” das fontes abaixo: \\http://www.esr.rnp.br/leitura/ \\http://rute.rnp.br/videos/ \\http://www.redecomep.rnp.br/videos/ \\http://www.rnp.br/noticias/2006/not-060328.html

3. Configure o VLC como servidor para distribuir tráfego multicast. \\Inicie

o programa VLC Media Player.

\\Selecione

o arquivo a ser transmitido e clique em “Arquivo/OpenFile”; será aberta a tela abaixo:

\\Selecione

o arquivo de áudio e/ou vídeo clicando no botão “Navegar...”.

em “Opções Avançadas” o item “Stream/Save” e clique no botão “Configurações”.

\\Selecione


237

Obs.: O IP Multicast deverá ser escolhido pelo instrutor e atribuído para cada aluno.

\\Clique

na caixa RTP e atribua um IP Multicast, por exemplo o 239.2.1.1, e verifique se a porta padrão 1234 foi habilitada.

Lembrete: O intervalo de endereços 239.0.0.0 a 239.255.255.255 é conhecido como escopo de endereços limitados ou de endereços administrativos, e deve ser utilizado para transmissões em rede local ou em redes de uma organização, conforme definido na RFC 2365 (http://www.ietf. org /rfc/rfc2365.txt). \\Em

“Opções de transcodificação”, selecione as opções de codec de vídeos ou de áudio; poderão ser habilitadas ambas as opções.

Pronto. Seu servidor já está transmitindo o conteúdo desejado para toda a sua rede. Obs.: O consumo de banda será o selecionado nos codecs em taxa de bits (kb/s).


Escola Superior de Redes RNP 4. Visualizando o conteúdo nos clientes.

\\Selecione

“Arquivo /Open Network Stream...”, coloque o IP do servidor e clique em “OK”.


238

Bibliografia \\Comer,

Douglas E.. Interligação em rede com TCP/IP: princípios, protocolos e arquitetura. Rio de Janeiro: Campus. 1998.

\\Stevens,

W. Richard; Addison-Wesley. TCP/IP Illustrated, Volume 1: The Protocols. 1994. ISBN 0-201-63346-9.

\\Tutoriais

de TCP/IP. Disponível em: . Acesso em: 10/10/2006.

\\Moura,

Alex Soares de. O protocolo BGP4. Boletim trimestral sobre tecnologia de redes. RNP. 1999

\\Halabi,

Sam. OSPF Design Guide. Cisco Systems. 1996. Disponível em: . Acesso em: 22/02/2007.

\\De

Castro, Maria Cristina F.. Planejamento de Redes Comutadas. Disponível em: . Acesso em: 03/10/2006.

\\Assis,

Alexandre Urtado de; Alves Jr., Nilton. Protocolos de Roteamento RIP e OSPF. Disponível em: . Acesso em: 03/10/2006. CBPF-NT-011/00

\\Moura,

Alex Soares de. Dicas na Configuração do Protocolo BGP-4 – Parte 1. Boletim trimestral sobre tecnologia de redes, volume 5, no 1. RNP.

\\Moura,

Alex Soares de. Dicas na Configuração do Protocolo BGP-4 (final). Boletim trimestral sobre tecnologia de redes, volume 5, no 5. RNP.

\\Moura,

Alex Soares de. O Protocolo BGP4 – Parte 1. Boletim trimestral sobre tecnologia de redes, volume 3, no 2. RNP.

\\Moura,

Alex Soares de. O Protocolo BGP4 – Parte 2. Boletim trimestral sobre tecnologia de redes, volume 3, no 3. RNP.

\\Moura,

Alex Soares de. O Protocolo BGP4 – Parte 3 (final). Boletim trimestral sobre tecnologia de redes, volume 3, no 4. RNP.


240

\\Tutorial

de Mbone, Cristina Melchiors, sítio http://penta.ufrgs.br/redes296/ mbone/tutmbone.htm, consultado em 15 de abril de 2007-05-30

\\Protocolos

de Roteamento RIP & OSPF, sítio http://www.gta.ufrj.br/ grad/98_2/aline/indice.html, consultado em 19 de janeiro de 2007

\\BGP_OSPF_Interaction_Report.pdf,

Avinash Ramanath, sítio http://www. quagga.net/docs/, consultado em 15 de março de 2007

\\BGP

Fundamentals, sítio http://www.alcatel-lucent.com/wps/portal/riverstone consultado em 13 de março de 2007

\\ZEBRA

BGP commands, sítio http://personals.ac.upc.edu/joseb/BGP_ commands_zebra.pdf consultado em 13 de março de 2007

\\EXAMPLE

ZEBRA CONFIG, John Fraizer, sítio http://tania.be.linux.org/zebra/ msg00338.html, consultado em 11 de março de 2007

\\Network

Protocols Configuration Guide, Part 1, sítio http://www.cisco.com/ univercd/cc/td/doc/product/software/ios113ed/113ed_cr/np1_c/1cbgp.pdf consultado em 13 de março de 2007

\\Using

Regular Expressions in BGP, sítio http://www.cisco.com/warp/ public/459/26.pdf consultado em 15 de março de 2007

\\Route-Maps

for IP Routing Protocol Redistribution Configuration, sítio http:// www.cisco.com/warp/public/459/route-map_bestp.pdf consultado em 15 de março de 2007

\\Module

13 – Multihoming to Different ISPs, sítio http://www.pacnog.org/ pacnog1/day5/module13.pdf, consultado em 12 de março de 2007

\\Roteamento

na RNP – Uma visão geral, Sidney Cunha de Lucena, sítio http:// www.rnp.br/_arquivo/sci/2002/roteamento.pdf consultado em 31 de março de 2007

\\Module

12 – Multihoming to the Same ISP, sítio http://www.pacnog.org/ pacnog1/day5/module12.pdf, consultado em 12 de março de 2007

\\IBGP

Scalability, sítio http://www.riverstonenet.com/support/bgp/scalability/ index.htm consultado em 13 de março de 2007

\\O

MBONE – Videoconferência na Internet, Luiz Velho e Jonas Gomes, sítio www.visgraf.impa.br/Data/RefBib/PS_PDF/mbone-1996/mbone.pdf.gz consultado em 17 de abril de 2007

\\Topologia

do Mbone, sítio http://penta.ufrgs.br/rc952/trab2/hl_topo.html consultado em 17 de abril de 2007

\\Projeto

Multicast, Beethovem Zanella Dias, sítio http://mesonpi.cat.cbpf.br/ mcast/ consultado em 17 de abril de 2007

\\Multicast

nativo no backbone RNP2: panorama atual de implantação, Adenilson Raniery, Boletim trimestral sobre tecnologia de redes – RNP, volume 6, no 3

Roteamento avançado

241

\\Considerações

acerca do estabelecimento de QoS na RNP2, Cybelle Suemi Oda Oyama, Sidney Cunha de Lucena, Boletim trimestral sobre tecnologia de redes – RNP, volume 6, no 3

\\Estudo

experimental de videoconferência pessoal em inter-redes IP com QoS, José Luiz A. da Fonseca, Michael A. Stanton, Boletim trimestral sobre tecnologia de redes – RNP, volume 5, no 6

\\Perspectivas

sobre Qualidade de Serviço nos Protocolos da Internet - Estudo de Caso: Aplicações de Vídeo Sob Demanda, Aline C. Viana, Anibal S. Jukemura, Daniela A. Xavier, Kleber V. Cardoso, Boletim trimestral sobre tecnologia de redes – RNP, volume 4, no 4

\\RFC

1700, Assigned Numbers

\\RFC

2119, Key words for use in RFCs to Indicate Requirement Levels

\\RFC

2328, OSPF Version 2

\\RFC

2453, RIP Version 2

\\RFC

3700, Internet Official Protocol Standards

\\RFC

1112, Host Extensions for IP Multicasting

\\RFC

1584, Multicast Extensions to OSPF

\\RFC

2205, Resource ReSerVation Protocol (RSVP)

\\RFC

2236, Internet Group Management Protocol, Version 2

\\RFC

4601, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)

\\RFC

3376, Internet Group Management Protocol, Version 3

\\RFC

3973, Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)

\\RFC

Bibliografia

4286, Multicast Router Discovery

Roteamento avançado

Recommend Documents