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
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).
Roteamento avançado
Apresentação
Escola Superior de Redes RNP
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
Escola Superior de Redes RNP
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
Roteamento avançado – Sessão de aprendizagem 1
Escola Superior de Redes RNP
Conceito de roteamento
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:

 Determinação das rotas ótimas;
Transporte da informação (pacotes) através da


rede (processo de comutação — switching).
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
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.
Conceito de roteamento (1)
O que é roteamento?
Roteamento é a transferência de informação da
origem até o destino através de uma rede.
Conceito de roteamento (2)
Componentes do roteamento
Determinação de rotas
Transporte dos pacotes (comutação)
Determinação de rotas
Métrica
Tabelas de roteamento =>
Troca de mensagens
Para chegar na rede Enviar para
10 Nó A
15 Nó B
20 Nó C
30 Nó A
25 Nó B
45 Nó A
9
Conceitos básicos de roteamento
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
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.
Transporte dos pacotes
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)
10
Roteamento avançado – Sessão de aprendizagem 1
Escola Superior de Redes RNP
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
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:
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.
A 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.
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
Rede Host
32 Bits 8 Bits
131 . 108 . 122 . 204
8 Bits 8 Bits 8 Bits
Classe A N H H H
Classe B N N H H
Classe C N N N H
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
11
Conceitos básicos de roteamento
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
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
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
12
Roteamento avançado – Sessão de aprendizagem 1
Escola Superior de Redes RNP
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:
Hosts
1. que não precisam acessar a internet;
Hosts
2. 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
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.
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
13
Conceitos básicos de roteamento
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.
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.
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:
Se ele estiver configurado como
1. router, executará os procedimentos de
roteamento IP baseado na sua tabela de roteamento residente na memória
do host.
Se ele não estiver configurado como
2. router, o datagrama será
simplesmente descartado.
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
O host pertence à rede 131.108.2.0
1000 0011.0110 1100.0000 0010.0001 0000
1111 1111.1111 1111.1111 1111.0000 0000
1000 0011.0110 1100.0000 0010.0000 0000
Endereço IP:
Máscara:
Rede:
Roteamento IP
Diretamente conectado
Gateway padrão
Configuração do host IP
Somente como host
Como host e roteador
14
Roteamento avançado – Sessão de aprendizagem 1
Escola Superior de Redes RNP
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,
no RJ o endereço 172.16.10.1 e em SP o endereço
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.
Exemplo de roteamento IP
Rede local RJ 172.16.10.0/24
Rede local SP 172.16.20.0/24
15
Conceitos básicos de roteamento
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 do endereçamento das subredes


Definição dos endereços dos

 gateways padrão
Configuração dos micros de cada subrede


Testes de continuidade


Em caso de mau funcionamento, resolução de problemas


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).
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).
Arquitetura TCP/IP
Conjunto pioneiro de protocolos
“Universal”
16
Roteamento avançado – Sessão de aprendizagem 1
Escola Superior de Redes RNP
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.
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
Camadas da arquitetura TCP/IP (1)
Camadas da arquitetura TCP/IP (2)
17
Conceitos básicos de roteamento
para enviar o pacote IP. Existe então a necessidade de uma interface entre o
protocolo IP e a subrede.
Camada de subrede
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
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.
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.
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
Protocolo ARP
Mapeia IP Ethernet
Domínio de broadcasting
18
Roteamento avançado – Sessão de aprendizagem 1
Escola Superior de Redes RNP
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:
Os hubs e
1. switches propagam as mensagens ARP broadcasting por default;
Os roteadores NÃO propagam as mensagens ARP
2. broadcasting por default.
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.
Captura de pacotes IP
A janela principal do Ethereal consiste das seguintes
partes:

 Menu – Usado para iniciar algumas operações;
Barra de ferramentas principal

 – Provê
acesso rápido às operações mais usadas do
menu;
Captura de pacotes IP
Programa Ethereal de captura de pacotes
19
Conceitos básicos de roteamento

 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

 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;
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.
20
Roteamento avançado – Sessão de aprendizagem 1
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 IP


Classes de endereçamento


Máscara de subrede


Roteamento IP


Camadas da arquitetura TCP/IP


Protocolo ARP


Competências técnicas desenvolvidas
Planejamento do endereçamento das subredes


Definição dos endereços dos

 gateways padrão
Configuração dos micros de cada subrede


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
Roteamento avançado – Sessão de aprendizagem 1
Escola Superior de Redes RNP
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 inter-
face definida (eth0) é a
interface real. Ela pode
ter qualquer endereço de
rede, porque não será
usada nesta atividade.
Melhor deixar como esti-
ver.
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
Conceitos básicos de roteamento
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.
Testar a continuidade dentro da subrede
1.
Comando ping para as demais máquinas da subrede
Nota: todos os coman-
dos devem funcionar cor-
retamente. Se não, corri-
gir o problema.
Testar a continuidade entre subredes
2.
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 coman-
dos devem funcionar cor-
retamente. Se não, corri-
gir o problema.
Iniciar o programa Wireshark
1.
Iniciar a captura na interface de rede local
2.
Testar a continuidade entre subredes
3.
Comando

 ping para uma máquina de cada subrede
Comando

 traceroute para uma máquina de cada subrede
Parar o programa Wireshark
4.
Analisar o arquivo de captura
5.
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.
24
Roteamento avançado – Sessão de aprendizagem 1
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.
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
Roteamento avançado – Sessão de aprendizagem 2
Escola Superior de Redes RNP
Subredes
O mundo exterior enxerga nossa organização como
uma rede única, e nenhuma informação detalhada
sobre nossa estrutura interna é requerida.
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.
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.
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.
Subredes (1)
Rede 131.108.0.0
sem subredes
(131.108.0.0/16)
Rede 131.108.0.0
com subredes
(131.108.0.0/24)
Subredes (2)
Subredes (3)
131
255
255
108
255
255
0
0
255
0
0
0
Endereço
de rede
Máscara de
subrede padrão
(16 bits)
Máscara
de subrede
de 24 bits
Rede
Rede
Rede
Host
Host
Subrede Host
Usa bits do campo de host a partir
do bit mais significativo
27
Configuração de máscara de subrede
Tabela de subredes
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.
Tabela de subredes
Bits bit 8 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1
Pesos 128 64 32 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 0,128
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,..
Decimal bits rede bits host ID redes
28
Roteamento avançado – Sessão de aprendizagem 2
Escola Superior de Redes RNP
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.
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.
Exemplo de subrede
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 BITS
SUBNET HOST SIGNIFICADO
01 000000=64 Subnet ID
01 000001=65 1o
host válido
01 111110=126 Último host válido
01 111111=127 Subnet broadcasting
BITS BITS
SUBNET HOST SIGNIFICADO
10 000000=128 Subnet ID
10 000001=129 1o
host válido
10 111110=190 Último host válido
10 111111=191 Subnet broadcasting
29
Configuração de máscara de subrede
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
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.
IP Subnet Calculator
30
Roteamento avançado – Sessão de aprendizagem 2
Escola Superior de Redes RNP
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 <Enter>.
O programa mostra todos os dados pertinentes a
esta rede (tela 1).
Na opção Subnet Info escolhemos 8 bits para
subrede e apertamos <Enter>.
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.
Exemplo IP Subnet Calculator (1)
Exemplo IP Subnet Calculator (2)
31
Configuração de máscara de subrede
VLSM e CIDR
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;
Uma subrede com 126

 hosts, dividida por sua vez em duas subredes com 62
hosts cada;
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.
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
Exemplo IP Subnet Calculator (2)
32
Roteamento avançado – Sessão de aprendizagem 2
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,

 broadcast 192.214.11.191 e hosts 11.129 até 11.190,
com máscara 255.255.255.192
192.214.11.192,

 broadcast 192.214.11.255 e hosts 11.193 até 11.254,
com máscara 255.255.255.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 IP


Classes de endereçamento


Máscara de subrede


Roteamento IP


Camadas da arquitetura TCP/IP


Protocolo ARP


Competências técnicas desenvolvidas
Planejamento do endereçamento das subredes


Definição dos endereços dos

 gateways padrão
Configuração dos micros de cada subrede


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.
34
Roteamento avançado – Sessão de aprendizagem 2
Escola Superior de Redes RNP
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ª subrede: 192.168.100.16/29, com endereços de

 hosts de .17 a .22 (usar
o endereço .22 para o gateway padrão desta subrede);
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
Configuração de máscara de subrede
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ª subrede: 192.168.100.32/27, com endereços de

 hosts de .33 a .62 (usar
o endereço .62 para o gateway padrão desta subrede);
2ª subrede: 192.168.100.64/27, com endereços de

 hosts de .65 a .94 (usar
o endereço .94 para o gateway padrão desta subrede);
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
Roteamento avançado – Sessão de aprendizagem 2
Escola Superior de Redes RNP
Nota: deve aparecer ape-
nas o gateway padrão.
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
Nota: devem aparecer
todas as máquinas da
subrede.
Nota: todos os coman-
dos devem funcionar cor-
retamente. Se não, corri-
gir o problema.

 Testar a continuidade entre subredes
Comando

 ping para uma máquina de cada subrede
Comando

 traceroute para uma máquina de cada subrede
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
Este estudo de caso deve ser resolvido em 15
minutos. Os alunos podem fazê-lo em duplas.
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.


Estudo de caso
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
37
Configuração de máscara de subrede
Atividade 3 – Estudo de caso
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.
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?
Estudo de caso (cont.)
Planejamento de endereçamento IP
Mais duas filiais, com 8-10 computadores cada
38
Roteamento avançado – Sessão de aprendizagem 2
Escola Superior de Redes RNP
4. Considerando a rede abaixo, complete as tabelas de roteamento de cada
roteador.
Roteador 2621A
Destino Int Dist
172.16.10.0 F0/0 0
Roteador 2501A
Destino Int Dist
172.16.10.0 E0 0
Roteador 2501B
Destino Int Dist
172.16.10.0 S0 1
Roteador 2501C
Destino Int Dist
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
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
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.
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:
<Network id> <Subnet mask> <Gateway> <Metric> <outras informações>
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 de rede


Protocolos 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
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.1
189.6.12.158 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
Tabela de rotas
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
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:>
41
Configuração de rotas estáticas
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.
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.
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
42
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
Roteamento dinâmico
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.
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
43
Configuração de rotas estáticas
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. Pode-
se 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.
Tela do simulador de redes IMUNES
44
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
Configuração das subredes
Nesta figura vemos a configuração das subredes:

 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

 2a. 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}
Configuração das subredes
LAN10 172.16.10.0/24
.1
.10 .11
LAN30 172.16.30.0/24
.1
.10 .11
LAN50 172.16.50.0/24
.1
.10 .11
.1
.2 .1
.2
45
Configuração de rotas estáticas
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 uma rede com software de simulação IMUNES


Projetar o endereçamento das subredes


Configurar os equipamentos das subredes


Configuração básica de roteadores


Comando ping
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.
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
46
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
Comando traceroute
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.
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.
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.
Comando traceroute (2)
47
Configuração de rotas estáticas
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
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


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
48
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
3
Sessão de aprendizagem 3
Configuração de rotas estáticas
Roteiro de atividades
Tópicos e conceitos
Tabela de rotas


Roteamento estático e dinâmico


Principais comandos de configuração de rotas


Competências técnicas desenvolvidas
Desenhar uma rede com

 software de simulação IMUNES
Projetar o endereçamento das subredes


Configurar os equipamentos das subredes


Configuração básica de roteadores


Tempo previsto para as atividades
60-90 minutos


Observação
Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou
em máquina do laboratório.
50
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
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 <rede> <máscara
subrede> <next hop>, onde:
<rede>

 é a identificação da rede (network ID), no caso 172.16.30.0;
172.16.40.0; 172.16.50.0;
<máscara subrede>

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

 <next 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
Configuração de rotas estáticas
5. Digitando agora o comando sh ip route veremos as rotas aprendidas
pelo router0.
A figura a seguir ilustra esse processo.
Precisamos agora configurar os demais roteadores.
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 sal-
var 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 per-
didas.
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
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
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
Configuração de rotas estáticas
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
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
9. Para adicionar a rota padrão e definir o gateway padrão no PC, o formato
do comando é:
route add <rede> <máscara de subrede> <gateway>, onde:
<rede>

 0.0.0.0 (rota padrão)
<máscara de subrede>

 /0
<gateway>

 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
Configuração de rotas estáticas
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
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
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
Configuração de rotas estáticas
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.
O Ethereal pergunta o que fazer com o arquivo de captura corrente. É possível
escolher descartá-lo ou gravá-lo para análise posterior.
Este arquivo de captura
do comando ping está
gravado com o nome:
Captura_Ping_Ethereal,
no formato libpcap.
Quando o programa Ethereal é encerrado, sempre pergunta se queremos salvar o
arquivo de captura de pacotes.
58
Roteamento avançado – Sessão de aprendizagem 3
Escola Superior de Redes RNP
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 cap-
tura com o nome que vier
a seguir. O arquivo será
gravado no diretório cor-
rente (provavelmente
/root). Não estamos
usando o programa
Ethereal para capturar os
pacotes do traceroute
por dois motivos:
1. queremos
mostrar o programa
tcpdump;
2. dependendo
da velocidade da CPU do
PC que está sendo
usado, o Ethereal perde
pacotes, não conseguin-
do capturar todos os
pacotes mostrados nas
figuras a seguir.
Para mostrar os pacotes
usaremos o Ethereal,
aproveitando a sua inter-
face gráfica.
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:
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
Configuração de rotas estáticas
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.
60
Roteamento avançado – Sessão de aprendizagem 3
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.
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
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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
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
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.
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:
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 (CIDR)
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
63
Protocolo de roteamento RIP
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
particular de redes sob uma mesma autoridade
administrativa e de controle (AS). Roteadores usados
para troca de informação no interior dos ASs são
chamados roteadores interiores (interior routers) e
usam uma variedade de protocolos chamada Interior
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).
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
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.
Classificação de protocolos de roteamento
Protocolos de roteamento podem ser:
Interiores (Interior Gateway Protocol – IGP) – Usados
para comunicação entre roteadores de um mesmo AS
Exemplos: RIP – RFC2453, OSPF – RFC2328
Exteriores (Exterior Gateway Protocol – EGP) –
Usados para comunicação entre roteadores de ASs
diferentes
Exemplos: EGP (obsoleto), BGP-4 – RFC4271
Listagem de RFCs
http://www.rfc-editor.org/rfc-index2.html
Roteamento dinâmico
Métrica dos protocolos de roteamento
Contador de hops
Bandwidth (largura de banda)
Delay (retardo)
Custo
Confiabilidade
Carga
MTU
Ticks
64
Roteamento avançado – Sessão de aprendizagem 4
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
Processo de montagem da tabela de rotas:
Quando o roteador executa o
1. 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.
Periodicamente cada roteador envia uma cópia da
2.
sua tabela para qualquer outro roteador que seja
diretamente alcançável (seus vizinhos).
Cada roteador que recebe uma cópia da tabela
3.
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.
Se a rota já existe na tabela e a métrica calculada é menor do que a da
3.1.
rota conhecida, então remove a entrada anterior e adiciona a nova rota
divulgada;
Se a rota já existe na tabela e a métrica calculada é igual a da rota
3.2.
conhecida, então não altera a entrada, desprezando a rota divulgada;
Se a rota já existe na tabela e a métrica divulgada é maior do que a da
3.3.
rota conhecida, então verifica se o gateway para esta rota é o mesmo
que está fazendo a nova divulgação:
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
65
Protocolo de roteamento RIP
Se o
3.3.1. gateway é o mesmo, altera a métrica para esta rota;
Se o
3.3.2. gateway não é o mesmo, não altera a rota conhecida,
desprezando a rota anunciada.
Tabela de roteamento Vetor-Distância
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.
As tabelas vistas na figura anterior serão anunciadas
pelos roteadores a seus vizinhos, da seguinte forma:

 router0 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
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
Tabela de roteamento Vetor-Distância (2)
Tabelas após o primeiro anúncio de rotas
router0
Destino Next Hop Métrica
Rede 10 - 1
Rede 20 - 1
Rede 30 router1 2
Rede 40 router1 2
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
66
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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.
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
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
Tabela de roteamento Vetor-Distância (3)
Tabelas após o segundo anúncio de rotas
router0
Destino Next Hop Métrica
Rede 10 - 1
Rede 20 - 1
Rede 30 router1 2
Rede 40 router1 2
Rede 50 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
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
67
Protocolo de roteamento RIP
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
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
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
68
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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
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.
Contagem ao infinito
Tabela rotas router0 Tabela rotas router1
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
Destino Next Hop Métrica
Rede 10 - 1
Rede 20 - 1
Rede 30 router1 2
Destino Next Hop Métrica
Rede 10 router0 2
Rede 20 - 1
Rede 30 - 1
69
Protocolo de roteamento RIP
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.
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
70
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
Pacote RIP
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.
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;
Atributo 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;
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.
Pacote RIP
RIP usa protocolo UDP porta 520 para enviar e receber
mensagens de atualização de rotas
Formato da mensagem
Comando Identificador
Versão
Deve ser zero
Identificador do endereço da família Atributo da rota
Endereço IP
Máscara de subrede
Próximo hop
Métrica
0 7 8 15 16 31
Cab
R
T
E
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 do protocolo RIP


Pacotes RIP


Configuração do protocolo RIP


Competências técnicas desenvolvidas
Entender o funcionamento do protocolo RIP


Calcular tabela de rotas RIP


Configurar roteadores com protocolo RIP


Tempo previsto para as atividades
60-90 minutos


Observação
Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou
em máquina do laboratório.
72
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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
73
Protocolo de roteamento RIP
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
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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
Protocolo de roteamento RIP
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 paco-
tes 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
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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
Protocolo de roteamento RIP
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
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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 paco-
tes 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
Protocolo de roteamento RIP
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 t (entra no modo de configuração global);
int eth0

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

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

 (sai do modo de configuração e volta para o modo privilegiado).
80
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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
Protocolo de roteamento RIP
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
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP

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

 eth0 (entra no modo de configuração de interface, no caso a eth0);
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
Protocolo de roteamento RIP
Isto ocorreu imediatamente após colocarmos off-line a rede 30, derrubando a
interface eth0.
84
Roteamento avançado – Sessão de aprendizagem 4
Escola Superior de Redes RNP
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
Roteamento avançado – Sessão de aprendizagem 5
Escola Superior de Redes RNP
Open Shortest Path First (OSPF)
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
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
87
Protocolo de roteamento OSPF – Parte 1
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 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;
Comparação RIP x OSPF
CARACTERÍSTICA RIP OSPF
Limite de hops 15 Não
Suporta VLSM (Variable Length Subnet Mask) Sim Sim
Broadcasting periódico da tabela de roteamento Sim Não
Broadcasting somente quando a tabela é atualizada Não Sim
Atualização de tabelas com mensagens IP multicast Sim Sim
Convergência das tabelas de roteamento Lenta Rápida
Decisão de roteamento baseada somente nos hops Sim Não
Decisão de roteamento baseada em várias métricas Não Sim
Rotas alternativas para o mesmo destino Não Sim
Hierarquia de roteamento (divisão em áreas) Não Sim
Autenticação das mensagens de atualização de rotas Sim Sim
Comunicação com protocolos exteriores ao AS Não Sim
88
Roteamento avançado – Sessão de aprendizagem 5
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
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 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


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
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
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.
89
Protocolo de roteamento OSPF – Parte 1
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)
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;
A
B C
D
E F
G H
2
2
6
1
7
2
4
3
2
3
2
Algoritmo SPF – Dijkstra (3)
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;
A
B(2,A) C(f,-)
D(f,-)
E(f,-) F(f,-)
G(6,A) H(f,-)
2
2
6
1
7
2
4
3
2
3
2
90
Roteamento avançado – Sessão de aprendizagem 5
Escola Superior de Redes RNP
Algoritmo SPF – Dijkstra (4)
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);
A
B(2,A) C(9,B)
D(f,-)
E(4,B) F(f,-)
G(6,A) H(f,-)
2
2
6
1
7
2
4
3
2
3
2
Algoritmo SPF – Dijkstra (5)
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);
A
B(2,A) C(9,B)
D(f,-)
E(4,B) F(6,E)
G(5,E) H(f,-)
2
2
6
1
7
2
4
3
2
3
2
Algoritmo SPF – Dijkstra (6)
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);
A
B(2,A) C(9,B)
D(f,-)
E(4,B) F(6,E)
G(5,E) H(9,G)
2
2
6
1
7
2
4
3
2
3
2
91
Protocolo de roteamento OSPF – Parte 1
Algoritmo SPF – Dijkstra – Resumo
A figura acima resume os passos explicados
anteriormente.

 Passo 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).
Algoritmo SPF – Dijkstra (7)
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).
A
B(2,A) C(9,B)
D(10,H)
E(4,B) F(6,E)
G(5,E) H(8,F)
2
2
6
1
7
2
4
3
2
3
2
Algoritmo SPF – Dijkstra – Resumo
A
B C
D
E F
G H
2
2
6
1
7
2
4
3
2
3
2
A
B(2,A) C
D
E F
G(6,A) H
2
2
6
1
7
2
4
3
2
3
2
A
B(2,A) C(9,B)
D
E(4,B) F
G(6,A) H
2
2
6
1
7
2
4
3
2
3
2
A
B(2,A) C(9,B)
D
E(4,B)F(6,E)
G(5,E) H
2
2
6
1
7
2
4
3
2
3
2
A
B(2,A) C(9,B)
D
G(5,E) H(9,G)
2
2
6
1
7
2
4
3
2
3
2
A
B C(9,B)
D(10,H)
G(5,E) H(8,F)
2
2
6
1
7
2
4
3
2
3
2
E(4,B)F(6,E) E(4,B)F(6,E)
92
Roteamento avançado – Sessão de aprendizagem 5
Escola Superior de Redes RNP
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.
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.
5
Sessão de aprendizagem 5
Protocolo de roteamento OSPF – Parte 1
Roteiro de atividades
Tópicos e conceitos
Comparação RIP x OSPF


Conceito de Estado do Enlace (

 Link State)
Algoritmo SPF (

 Shortest Path First)
Funcionamento do protocolo OSPF


Configuração básica do protocolo OSPF


Competências técnicas desenvolvidas
Entender o funcionamento do protocolo OSPF


Calcular tabela de rotas OSPF


Configurar roteadores com protocolo OSPF


Tempo previsto para as atividades
30-45 minutos


Observação
Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou
em máquina do laboratório.
94
Roteamento avançado – Sessão de aprendizagem 5
Escola Superior de Redes RNP
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
Protocolo de roteamento OSPF – Parte 1
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 t (entra no modo de configuração global);
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
Roteamento avançado – Sessão de aprendizagem 5
Escola Superior de Redes RNP
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
Protocolo de roteamento OSPF – Parte 1
10. Outro comando específico para o protocolo OSPF é sh ip ospf.
As figuras mostram os resultados para os roteadores da rede.
98
Roteamento avançado – Sessão de aprendizagem 5
Escola Superior de Redes RNP
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
Protocolo de roteamento OSPF – Parte 1
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
Roteamento avançado – Sessão de aprendizagem 5
Escola Superior de Redes RNP
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
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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 – É 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;
Glossário
Link
Router ID
Loopback interface
Neighbors
103
Protocolo de roteamento OSPF – Parte 2

 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;

 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;
Glossário (cont.)
Adjacency
Hello protocol
Flooding
Neighborship database
Topology database
Link State Advertisement
Designated router
Backup designated router
104
Roteamento avançado – Sessão de aprendizagem 6
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;

 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
Glossário (cont.)
OSPF areas
Stub areas
Broadcast (multi-access)
Non-broadcast (multi-access)
Point-to-point
Point-to-multipoint
105
Protocolo de roteamento OSPF – Parte 2
conexão ponto-multiponto pertencem à mesma rede. Como nas redes ponto-a-
ponto, 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
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.
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
106
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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).

 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
Os diferentes tipos de pacotes de estado de enlace
mais comuns estão ilustrados na figura acima. São
eles:

 Router 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;
OSPF – Roteadores de borda e área (2)
Pacotes de Estado de Enlace
Router Links
Network Links
Summary Links
External Links
107
Protocolo de roteamento OSPF – Parte 2

 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
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:
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
108
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP

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

 Authentication – 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;

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

 Stub 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.
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
Protocolo de roteamento OSPF – Parte 2
Autenticação OSPF
É 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 <key> (no modo de configuração da
interface conectada à área)
area area-id authentication (após o comando router ospf
<process-id>)
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
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
110
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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 <process-id>)
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
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.
Backbone OSPF
Todas as áreas devem estar conectadas ao backbone
O backbone deve ser o ponto de partida do projeto
111
Protocolo de roteamento OSPF – Parte 2
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
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 ID – Identificação do roteador que originou o pacote;

 Area 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
Layout dos pacotes OSPF (1)
Cabeçalho pacote OSPF
Pacote Hello (sem o cabeçalho)
0 7 8 15 16 31
Version # Type Packet Length
Router ID
Area ID
Checksum AuType
Authentication
Authentication
0 15 16 23 24 31
HelloInterval
Network Mask
Options Rtr Pri
RouterDeadInterval
DesignatedRouter
BackupDesignatedRouter
Neighbor
....
112
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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 – Número de segundos decorridos entre os pacotes Hello;

 Options – 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
Protocolo de roteamento OSPF – Parte 2
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
Layout dos pacotes OSPF (2)
Pacote de descrição do banco de dados (s/ cabeçalho)
Cabeçalho do LSA
0 15 16 23 24 31
Interface MTU Options
DD sequence number
0 0 0 0
0 I M MS
An LSA Header
0 15 16 23 24 31
Link State ID
LS age Options LS type
Advertising Router
LS sequence number
LS checksum length
114
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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.
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.
Layout dos pacotes OSPF (3)
Pacote Link State Request (s/ cabeçalho)
Pacote Link State Update (s/ cabeçalho)
Pacote Link State Acknowledgement (s/ cabeçalho)
0 31
LS type
Link State ID
Advertising Router
....
0 31
# LSAs
LSAs
....
0 31
An LSA Header
....
6
Sessão de aprendizagem 6
Protocolo de roteamento OSPF – Parte 2
Roteiro de atividades
Tópicos e conceitos
Conceito de roteadores de borda e de área


Pacotes de Estado de Enlace


Autenticação OSPF


Backbone

 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


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.
116
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
Atividade 1 – Configuração do protocolo OSPF
router0 router1 router4
router2
router3
pc10
switch0
ser0
172.16.20.1/24
ser1
172.16.30.1/24
ser0
172.16.50.2/24
ser2
172.16.40.1/24
ser1
172.16.60.1/24
ser0
172.16.20.1/24
ser2
172.16.80.1/24
ser0
172.16.40.2/24
ser1
172.16.60.2/24
ser0
172.16.30.2/24
ser1
172.16.50.1/24
eth0
172.16.10.1/24
eth0
172.16.10.10/24
e1
e0
router5
pc11
switch1
ser0
172.16.80.2/24
eth0
172.16.90.1/24
eth0
172.16.90.20/24
e1
e0
Área 1 Área 2
Área 0
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
Protocolo de roteamento OSPF – Parte 2
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 t

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

 (habilita o protocolo OSPF);
network 172.16.0.0/16 area 1

 (informa a rede que será roteada na
área 1).
Ctrl-Z

 (para encerrar a configuração);
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 t

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

 (habilita o protocolo OSPF);
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
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
network 172.16.40.0/24 area 0

 (esta interface está na área 0).
Ctrl-Z

 (para encerrar a configuração);
A figura a seguir mostra o console do router1.
8. Os demais roteadores são configurados conforme mostram as figuras.
119
Protocolo de roteamento OSPF – Parte 2
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
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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
Protocolo de roteamento OSPF – Parte 2
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.
122
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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).
123
Protocolo de roteamento OSPF – Parte 2
A configuração do router4 é semelhante a do router1.
124
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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 t
int eth0


ip address 172.16.10.1/24


quit


int ser0


ip 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
Protocolo de roteamento OSPF – Parte 2
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
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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
Protocolo de roteamento OSPF – Parte 2
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
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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
Protocolo de roteamento OSPF – Parte 2
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 bem-
sucedidos, indicando completa conectividade através de toda a rede.
130
Roteamento avançado – Sessão de aprendizagem 6
Escola Superior de Redes RNP
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
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
Histórico
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
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)
133
Protocolo de roteamento BGP – Parte 1
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”.
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
Histórico (cont.)
Sistemas autônomos
Exemplos de AS
134
Roteamento avançado – Sessão de aprendizagem 7
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.
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.
Histórico (cont.)
Exterior Gateway Protocol – EGP
Vizinhos internos
Vizinhos externos
Problemas
Loops de roteamento
Pouca flexibilidade para
políticas de roteamento
135
Protocolo de roteamento BGP – Parte 1
Border Gateway Protocol BGP-4
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 de

 keepalive são enviadas periodicamente para manter a sessão
aberta;
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
136
Roteamento avançado – Sessão de aprendizagem 7
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
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;
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
137
Protocolo de roteamento BGP – Parte 1
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;
IGP – Protocolo de

 gateway interior, um protocolo de roteamento usado para
trocar informações de roteamento entre roteadores dentro de um único AS;
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
138
Roteamento avançado – Sessão de aprendizagem 7
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
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.
Vizinhos e pares BGP
139
Protocolo de roteamento BGP – Parte 1
Atributos do BGP
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:
Em sessões eBGP, o NEXT_HOP será sempre o IP de um roteador de
1.
borda (peer BGP) de um AS vizinho que originou a rota;
Em sessões iBGP onde a rota foi originada dentro do AS, o NEXT_HOP
2.
será o endereço IP do vizinho que anunciou a rota originalmente;
O NEXT_HOP aprendido pelo eBGP não é alterado pelo iBGP,
3.
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).
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
140
Roteamento avançado – Sessão de aprendizagem 7
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
Protocolo de roteamento BGP – Parte 1

 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
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:
router bgp
1. <AS>, onde <AS> é o número do Sistema Autônomo;
2. network <network number> mask <network mask>
route-map <route-map-name>
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:
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)
142
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
Vizinhos externos que residem em diferentes ASs e, normalmente, são
1.
adjacentes e compartilham uma subrede;
Vizinhos internos que residem em qualquer lugar do mesmo AS, não sendo
2.
necessariamente adjacentes.
Para isso, use o seguinte comando no modo de configuração de roteador:
neighbor {ip-address|peer-group-name} remote-as
<number>, 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-group-
name} 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 <address>, dá reset numa conexão BGP específica;
Clear ip bgp *
2. , 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:
através de filtros de trajetória de AS (
1. AS-path) usando os comandos ip
as-path access-list e neighbor filter-list;
Usando listas de acesso ou de prefixo com o comando
2. neighbor distribute-
list, 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
Protocolo de roteamento BGP – Parte 1
filtragem BGP são usados os comandos (iniciando no modo de configuração
global):
ip as-path access-list
1. 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);
router bgp
2. <AS>;
neighbor
3. {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;
set ip next-hop
2. ip-address [...ip-address] [peer-
address] 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
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
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
144
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
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:



 neighbor peer-group-name remote-as asn, para especificar
um vizinho BGP;
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;
neighbor

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

 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
Protocolo de roteamento BGP – Parte 1

 BGP Peer neighbor – O protocolo BGP requer configurações específicas de
vizinhos. Vejamos algumas delas:

 neighbor 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 ip-address description descrição-do-vizinho;

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

 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
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
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


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.
148
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
Atividade 1 – Configuração do protocolo BGP
AS 1900
pc 10
switch 1
router 0
router 1
router 2
eth0
172.16.10.10/24
eth0
172.16.10.1/24
ser0
172.16.20.1/24
ser0
172.16.20.2/24
ser1
172.16.30.1/24
ser1
172.31.10.1/24
ser0
172.16.30.2/24
ser0
172.31.10.2/24
e0
e1
pc 20
switch 2
router 5
router 4
router 3
eth0
92.168.10.20/24
eth0
192.168.10.1/24
ser0
192.168.20.1/24
ser1
192.168.20.2/24
ser0
192.168.30.2/24
e1
e0
ser1
92.168.30.1/24
AS 6500
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 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

 router2 está configurado com duas interfaces seriais: ser0 (IP:
172.16.30.2/24) e ser1 (IP: 172.31.10.1/24).
O

 router0 usa somente o protocolo OSPF.
O

 router1 e o router2 usam OSPF e BGP.
O

 router 2 mantém sessão iBGP com o router1 e sessão eBGP com o
router3.
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

 router4 está configurado com duas interfaces seriais: ser0 (IP:
192.168.30.2/24) e ser1 (IP: 192.168.20.2/24).
O

 router3 está configurado com duas interfaces seriais: ser0 (IP:
172.31.10.2/24) e ser1 (IP: 192.168.30.1/24).
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.
149
Protocolo de roteamento BGP – Parte 1
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 t (entra no modo de configuração global);
router ospf

 (habilita o protocolo OSPF);
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
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
network 172.16.0.0/16 area 0

 (informa as redes que serão roteadas
na área 0 );
Ctrl-z

 (termina a configuração do protocolo).
A figura a seguir mostra o console do router0.
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
Protocolo de roteamento BGP – Parte 1
8. Abra o console no router2 e digite os comandos:

 config 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


A figura a seguir mostra o console do router2. Nesta figura está mostrada
também a configuração do protocolo BGP que será feita mais adiante.
9. Abra o console no router3 e digite os comandos:

 config t
router ospf


ospf router-id 192.168.30.1


redistribute connected


redistribute static


redistribute bgp


network 192.168.0.0/16 area 0


Ctrl-z
152
Roteamento avançado – Sessão de aprendizagem 7
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.
10. Abra o console no router4 e digite os comandos:

 config 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


A figura a seguir mostra o console do router4. Nesta figura está mostrada
também a configuração do protocolo BGP que será feita mais adiante.
153
Protocolo de roteamento BGP – Parte 1
11. Abra o console no router5 e digite os comandos:

 config 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


A figura a seguir mostra o console do router5.
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
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
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:



 ping –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.
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
Protocolo de roteamento BGP – Parte 1
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 6500


bgp 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 172.16.0.0/16


bgp router-id 172.16.30.2


neighbor INTRA-6500 peer-group


neighbor INTRA-6500 remote-as 6500


neighbor INTRA-6500 update-source 172.16.30.2


neighbor 172.16.30.1 peer-group INTRA-6500


neighbor 172.16.30.1 description sessao iBGP com


router1
neighbor 172.31.10.2 remote-as 1900


neighbor 172.31.10.2 description sessao eBGP com


router3
156
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
router3
config t


router bgp 1900


network 192.168.0.0/16


bgp router-id 192.168.30.1


neighbor INTRA-1900 peer-group


neighbor INTRA-1900 remote-as 1900


neighbor INTRA-1900 update-source 192.168.30.1


neighbor 192.168.30.2 peer-group INTRA-1900


neighbor 192.168.30.2 description sessao iBGP com


router4
neighbor 172.31.10.1 remote-as 6500


neighbor 172.31.10.1 description sessao eBGP com


router2
router4
config t


router bgp 1900


bgp router-id 192.168.30.2


neighbor INTRA-1900 peer-group


neighbor INTRA-1900 remote-as 1900
neighbor INTRA-1900 update-source 192.168.30.2


neighbor 192.168.30.1 peer-group INTRA-1900


neighbor 192.168.30.1 description sessao iBGP com


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
Protocolo de roteamento BGP – Parte 1
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
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
159
Protocolo de roteamento BGP – Parte 1
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
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
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
Protocolo de roteamento BGP – Parte 1
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).
162
Roteamento avançado – Sessão de aprendizagem 7
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).
163
Protocolo de roteamento BGP – Parte 1
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
Roteamento avançado – Sessão de aprendizagem 7
Escola Superior de Redes RNP
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
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
Sessão BGP
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.
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)
167
Protocolo de roteamento BGP – Parte 2
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.
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
Mensagem OPEN
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:
Mensagens BGP
Tamanho mínimo de 19 e máximo de 4096 bytes
Cabeçalho + Dados
Campos do cabeçalho
Marcador
Comprimento
Tipo
Dados (opcional)
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
C. P. O.
(OPL)
1 byte
Tempo de espera
(Hold Time)
2 bytes
Identificador BGP
(BGP ID)
4 bytes
Parâmetros Opcionais
(Tipo/Comprimento/Valor)
Tamanho variável
168
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
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:
Tipo do parâmetro (1
1. byte);
Comprimento do Parâmetro (1
2. byte);
Valor do parâmetro (comprimento variável).
3.
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
Protocolo de roteamento BGP – Parte 2
Na sessão anterior foram capturados pacotes de
sessões BGP. Um deles está mostrado na figura
acima: OPEN Message.
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
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.

 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
Mensagem OPEN
Tipos de mensagens BGP (2)
NOTIFICATION
Erro
Subcódigo de erro
Dados
KEEPALIVE
Somente o cabeçalho padrão BGP (19 bytes)
Erro
(Error)
1 byte
Subcódigo de erro
(Error Subcode)
1 byte
Dados (Data)
Tamanho
variável
170
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
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.
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
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:
Rotas inalcançáveis (
1. unreachable routes);
Atributos de caminhos (
2. path attributes);
Informação de alcance da camada de rede
3.
(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;
Mensagem KEEPALIVE
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)...
171
Protocolo de roteamento BGP – Parte 2

 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
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.
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)
Reservado
1 byte
SAFI
(Subsequent AFI)
1 byte
Identificador da família de endereços
AFI – Address Family Identifier
2 bytes
172
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
Mensagens de Erro
Mapas de rotas
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
Mensagens de Erro
ERROR CODE ERROR SUBCODE
1
Erro no cabeçalho
da mensagem
1 – Conexão não sincronizada
2 – Comprimento da mensagem inválido
3 – Tipo de mensagem inválido
2
Erro na mensagem
OPEN
1 – Número de versão não suportado
2 – Número de AS vizinho inválido
3 – Identificador BGP inválido
4 – Parâmetro opcional não suportado
5 – Falha na autenticação
6 – Tempo de espera inaceitável
3
Erro na mensagem
UPDATE
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
6 – Atributo de origem inválido
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 (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]
173
Protocolo de roteamento BGP – Parte 2
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
Roteamento avançado – Sessão de aprendizagem 8
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;
Uma negação (

 deny) implícita é assumida se um determinado prefixo não
existe (doesn´t match) na lista de prefixo;
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
Protocolo de roteamento BGP – Parte 2
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
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:

 ip prefix-list BOGONS description (redes “óbvias” que não serão
aceitas)
ip prefix-list BOGONS seq 5 deny 0.0.0.0/8 le 32


ip prefix-list BOGONS seq 10 deny 10.0.0.0/8 le 32


ip prefix-list BOGONS seq 15 deny 127.0.0.0/8 le 32


ip prefix-list BOGONS seq 20 deny 172.16.0.0/12 le 32


ip prefix-list BOGONS seq 25 deny 169.254.0.0/16 le 32


ip prefix-list BOGONS seq 30 deny 192.168.0.0/16 le 32


ip prefix-list BOGONS seq 35 deny 192.0.2.0/24 le 32


ip prefix-list BOGONS seq 40 deny 224.0.0.0/3 le 32


ip prefix-list BOGONS seq 45 permit 0.0.0.0/0 le 32


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
176
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
Route Reflector
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
Route Reflector (1)
Número de sessões BGP: n(n-1)/2
Full-mesh BGP
Solução: Route Reflector
Com Route Reflector (RR)
Sem Route Reflector
177
Protocolo de roteamento BGP – Parte 2
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.
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.
Route Reflector (2)
Cluster list
178
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
8
Sessão de aprendizagem 8
Protocolo de roteamento BGP – Parte 2
Roteiro de atividades
Tópicos e conceitos
Sessão BGP


Mensagens BGP


Mapas de rotas


Competências técnicas desenvolvidas
Apresentar funcionamento de uma sessão BGP


Entender as mensagens do protocolo BGP


Projetar e configurar redes com protocolo BGP


Tempo previsto para as atividades
60-90 minutos


Observação
Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou
em máquina do laboratório.
180
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
Atividade 1 – Configuração do protocolo BGP
pc 10 pc 20
LAN 1 LAN 2
ISP-A
switch 0
switch 1
core1
router 0
router 1
router 2
eth0
172.16.10.10/24
eth2
10.0.0.1/24
eth2
10.0.1.1/24
eth0
172.16.10.1/24
eth0
10.0.31.3/28
eth1
10.0.31.1/28
ser0
172.16.20.1/24
ser0
172.16.20.2/24
ser1
172.16.30.1/24
ser1
172.31.10.1/24
ser0
172.16.30.2/24
ser0
172.31.10.2/24
ser0
192.168.1.1/24
e0
e0
e1
e2
e0
border1
switch 2
core2
eth0
10.0.31.4/28
eth0
10.0.1.2/24
eth1
10.0.31.19/28
eth1
10.0.31.2/28
eth0
192.1681.2/24
eth0
10.0.31.17/28
eth1
10.0.31.20/28
eth0
10.0.31.18/28
e3
e1
e1
e3
e0
e0
e1
e2
border2
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

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

 router2 está configurado com duas interfaces seriais: ser0 (IP:
172.16.30.2/24) e ser1 (IP: 172.31.10.1/24).
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
Protocolo de roteamento BGP – Parte 2
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
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
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 t (entra no modo de configuração global);
router bgp 6500

 (habilita o protocolo BGP no AS 6500);
network 172.16.0.0/16

 (informa as redes que serão anunciadas no AS);
bgp 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 172.16.30.2 description sessao iBGP com


router2
Ctrl-z

 (termina a configuração do protocolo).
183
Protocolo de roteamento BGP – Parte 2
A figura a seguir mostra o console do router0 após o comando sh run.
7. Abra o console no router1 e digite os comandos:

 config t
router bgp 6500


network 172.16.0.0/16


bgp router-id 172.16.30.1


neighbor 172.16.30.2 remote-as 6500


neighbor 172.16.30.2 description sessao iBGP com


router2
Ctrl-z
184
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
A figura a seguir mostra o console do router1 após o comando sh run.
8. Abra o console no router2 e digite os comandos:

 config 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
185
Protocolo de roteamento BGP – Parte 2
neighbor 172.16.30.1 default-originate

 (anuncia a rota default
do AS)
neighbor 172.16.30.1 route-reflector-client

 (define o router1
como cliente do RR)
neighbor 172.31.10.2 remote-as 1900

 (define o border1 como
vizinho)
neighbor 172.31.10.2 description sessao eBGP com


border1
Ctrl-z


A figura a seguir mostra o console do router2 após o comando sh run.
186
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
9. Abra o console no border1 e digite os comandos:
config t


int lo0


ip address 10.0.31.33/32

 (define o endereço da interface loopback)
Ctrl-z


config t


router bgp 1900


network 10.0.0.0/16

 (informa as redes que serão anunciadas no AS)
bgp 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


neighbor 10.0.31.34 update-source 10.0.31.33

 (define a
interface loopback como interface de origem das atualizações)
neighbor 10.0.31.35 remote-as 1900

 (define core1 como vizinho)
neighbor 10.0.31.35 description sessao iBGP com core1


neighbor 10.0.31.35 route-reflector-client


neighbor 10.0.31.35 default-originate


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 10.0.31.36 route-reflector-client


neighbor 10.0.31.36 default-originate


neighbor 10.0.31.36 update-source 10.0.31.33


neighbor 172.31.10.1 remote-as 6500

 (define router2 como
vizinho)
neighbor 172.31.10.1 description sessao eBGP com


router2
Ctrl-z
187
Protocolo de roteamento BGP – Parte 2
A figura a seguir mostra o console do border1 após o comando sh run.
188
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
10. Abra o console no border2 e digite os comandos:

 config t
int lo0


ip 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


A figura a seguir mostra o console do border2 após o comando sh run.
189
Protocolo de roteamento BGP – Parte 2
11. Abra o console core1 e digite os comandos:

 config t
int lo0


ip address 10.0.31.35/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.35


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


Ctrl-z


A figura a seguir mostra o console do core1 após o comando sh run.
190
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
12. Abra o console core2 e digite os comandos:

 config t
int lo0


ip address 10.0.31.36/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.36


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


Ctrl-z


A figura a seguir mostra o console do core2 após o comando sh run.
191
Protocolo de roteamento BGP – Parte 2
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
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
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
Protocolo de roteamento BGP – Parte 2
194
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
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
Protocolo de roteamento BGP – Parte 2
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
Roteamento avançado – Sessão de aprendizagem 8
Escola Superior de Redes RNP
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
Roteamento avançado – Sessão de aprendizagem 9
Escola Superior de Redes RNP
Orientações gerais
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
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
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
Orientações gerais
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
199
Resolução de problemas
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.
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.
RedeTeste6
Problemas propostos (2)
RedeTeste7
Problemas propostos (3)
RedeTeste8
Problemas propostos (4)
200
Roteamento avançado – Sessão de aprendizagem 9
Escola Superior de Redes RNP
Apresentação das soluções
O instrutor deve determinar a ordem de
apresentação e controlar os tempos de cada grupo.
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
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 de problemas


Correção de erros de configuração


Tempo previsto para as atividades
180 minutos


Observação
Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou
em máquina do laboratório.
202
Roteamento avançado – Sessão de aprendizagem 9
Escola Superior de Redes RNP
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:
O
1. pc10 não consegue enxergar todos os outros PCs;
O mesmo ocorre com o
2. pc40;
Nenhum roteador enxerga as interfaces
3. 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:
Verifique se a rota do
1. router0 para o pc40 passa pela interface
eth0/192.168.31.4 (a alternativa é a interface eth1/192.168.31.20);
Abra o console do
2. router3 e entre no modo de configuração da interface eth0,
e dê o comando shut (coloca a interface em down);
203
Resolução de problemas
Aguarde algum tempo até que o
3. router0 aprenda a nova rota pela interface
eth1/192.168.31.20 (lembre-se: o protocolo RIP demora um pouco para
convergir);
-Verifique novamente as rotas aprendidas pelo
4. router0;
Verifique a rota executando um traceroute do
5. 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:
O
1. PC-01 não consegue enxergar a rede além do Rot01;
O
2. PC-03 não consegue enxergar a rede além do Rot03;
O
3. PC-02 não consegue enxergar a rede além do Rot02;
O
4. PC-04 não consegue enxergar a rede além do Rot02;
Os roteadores
5. Rot01 e Rot03 não enxergam as redes do Rot02.
204
Roteamento avançado – Sessão de aprendizagem 9
Escola Superior de Redes RNP
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:
Os PCs não conseguem enxergar todas as interfaces de seus respectivos
1.
roteadores;
A tabela de rotas dos roteadores não mostra todas as subredes.
2.
205
Resolução de problemas
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:
Os PCs não conseguem enxergar todas as interfaces de seus respectivos
1.
roteadores;
A tabela de rotas dos roteadores não mostra todas as subredes;
2.
O provedor não aceitou a configuração proposta, alegando desperdício de
3.
endereços IP;
Questão especial:
4.
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ê?
206
Roteamento avançado – Sessão de aprendizagem 9
Escola Superior de Redes RNP
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
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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
Roteamento multicast
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.
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ços permanentes
Time to Live (TTL)
Endereço Descrição
224.0.0.0/24 Permanentes
224.0.1.0 até 238.255.255.255 Alcance global
233.0.0.0/8 Atribuído para Sistemas Autônomos
239.0.0.0/8 Endereços de alcance limitado
Endereço Utilização
224.0.0.1 Todos os sistemas da subrede
224.0.0.2 Todos os roteadores da subrede
224.0.0.5 Roteadores OSPF
224.0.0.12 DHCP
210
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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
Roteamento multicast
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
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
212
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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
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.
Serviços multicast
Objetivo: 1 fonte n destinos
Comparação Unicast x Multicast
213
Roteamento multicast
Tráfego multicast x unicast
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.
Tráfego multicast × unicast
IP multicast – RFC 1112
Comparação de tráfego
1 20 40 60 80 100
N. clientes
Tráfego
Mbps
0,8
0,6
0,4
0,2
0
Streaming Áudio
8kbps/cliente
Multicast
Unicast
Fonte: Cisco Network
Modelo IP multicast
Protocolos Multicast Dispositivos-Roteadores
Protocolos Multicast Roteadores-Roteadores
Funcionamento do IP multicast
Todos os dispositivos habilitados com multicasting
214
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
Conceito de MBone
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
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.
Conceito de MBone
Multicast Backbone (MBone)
Internet Engineering Task Force (IETF)
Ilhas multicasting interligadas p/ túneis ponto a ponto
Encapsulamento em pacotes unicast
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
215
Roteamento multicast
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 (PIM-
DM).
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
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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
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.
Árvore de distribuição multicast
Árvore ligada à fonte
Menor caminho
Árvore compartilhada
Ponto de encontro
217
Roteamento multicast
Algoritmo de roteamento multicast
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:
Rotear dados somente para os receptores dos


grupos;
Utilizar caminhos otimizados da fonte aos


receptores;
Isenção de

 loops nas rotas;
Prover escalabilidade de sinalização para criar e manter relacionamento de grupo;


Não 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.
Algoritmo de roteamento multicast (1)
Checagem RPF
Na figura à esquerda o pacote é aceito
Na figura à direita o pacote é descartado
218
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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.
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.
Algoritmo de roteamento multicast (2)
Rendez-vous Point (RP)
Algoritmo de roteamento multicast (3)
Rendez-vous Point – RP (cont.)
219
Roteamento multicast
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.
Algoritmo de roteamento multicast (4)
Rendez-vous Point – RP (cont.)
Algoritmo de roteamento multicast (5)
Rendez-vous Point – RP (cont.)
Algoritmo de roteamento multicast (6)
Rendez-vous Point – RP (cont.)
220
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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.
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
221
Roteamento multicast
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.
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.
MSDP (1)
222
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
Responsável pela:
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
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).
MSDP (2)
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
223
Roteamento multicast
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
ambos os endereços de origem e destino (também
chamado source/destination routing). O banco de
dados do estado de enlace fornece uma descrição
completa da topologia do Sistema Autônomo.
Adicionando um novo tipo de LSA (anúncio de estado
do enlace) chamado group membership LSA, a
localização de todos os membros dos grupos
multicast é destacada no BD. O caminho de um
datagrama multicast pode então ser calculado
construindo uma árvore de caminhos mais curtos
(shortest-path tree), cuja raiz está na origem do datagrama.
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);
Protocolo MOSPF (2)
Novo tipo de LSA: group membership LSA
Os membros dos grupos são adicionados ao BD OSPF
O caminho multicast é calculado pelo algoritmo SPF
Os caminhos que não têm membros são podados
A origem pode estar em outra área OSPF ou em outro AS
Características do roteamento multicast
Source/destination routing
Caminho de menor custo
Nas bifurcações o datagrama é replicado
Caminho único entre fonte e destino (sem rota alternativa)
Os pacotes IP são encaminhados como multicast de enlace
224
Roteamento avançado – Sessão de aprendizagem 10
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
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.
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
225
Roteamento multicast
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
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
Requisitos de QoS
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
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
227
Roteamento multicast
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
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
convencionais. O modelo de serviço tradicional
oferece somente serviço de melhor esforço,
bastante adequado para um grande número de
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.
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
QoS na internet
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
Espaço de armazenamento e sobrecarga nos roteadores
Recursos especiais nos roteadores
Serviços diferenciados
Prioridade relativa sobre outras aplicações
Dependendo da carga da rede o desempenho é inaceitável
228
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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
Roteamento multicast
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/
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 PIM-
SM (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,
Topologia do multicast backbone RNP
Topologia de interconexão dos PoPs da RNP
Topologia do multicast backbone RNP
Malha PIM-SM
230
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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
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 cliente da RNP pode utilizá-lo;


Mais 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)


Malha multicast da RNP
Anexação ao domínio PIM-
SM da RNP:
• Uso do RP mantido pela RNP
• Configuração simples
• Somente PIM-SM necessário
Criação de domínio PIM-SM
local:
• Uso de RP próprio
• Configuração mais complexa
• PIM-SM e MSDP requeridos
Conexão multicast com o backbone RNP2
231
Roteamento multicast
Conexão multicast
Conexão direta ao domínio PIM-SM/RNP
Conectar os roteadores do laboratório à malha PIM-
SM 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
Conectar os roteadores do laboratório à malha PIM-
SM da RNP, através de um túnel GRE para um
roteador do backbone.
Conexão multicast
Conexão direta ao domínio PIM-SM/RNP
Conexão via túnel GRE
232
Roteamento avançado – Sessão de aprendizagem 10
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
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 111 deny ip any host 224.0.2.2
router(config)# access-list 111 deny ip any host 224.0.1.3
router(config)# access-list 111 deny ip any host 224.0.1.24
router(config)# access-list 111 deny ip any host 224.0.1.22
router(config)# access-list 111 deny ip any host 224.0.1.2
router(config)# access-list 111 deny ip any host 224.0.1.35
router(config)# access-list 111 deny ip any host 224.0.1.60
router(config)# access-list 111 deny ip any host 224.0.1.39
router(config)# access-list 111 deny ip any host 224.0.1.40
router(config)# access-list 111 deny ip any 239.0.0.0
0.255.255.255
router(config)# access-list 111 deny ip 10.0.0.0
0.255.255.255 any
router(config)# access-list 111 deny ip 127.0.0.0
0.255.255.255 any
router(config)# access-list 111 deny ip 172.16.0.0
0.15.255.255 any
Conexão via RP local e MSDP
233
Roteamento multicast
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
Protocolos utilizados no backbone multicast da
RNP:
PIM-SM (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 ao domínio PIM-SM da RNP


Criação de domínio local + MSDP


router# show ip msdp summary
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
192.0.2.10 65001 Up 4d15h 7 28 peer1.net
192.0.2.25 65500 Up 4d10h 7 4212 peer2.com
router#
Conexão via RP local e MSDP (cont.)
Verificação
234
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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


Observação
Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou
em máquina do laboratório.
236
Roteamento avançado – Sessão de aprendizagem 10
Escola Superior de Redes RNP
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...”.
Selecione em “

 Opções Avançadas” o item “Stream/Save” e clique no botão
“Configurações”.
237
Roteamento multicast
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).
238
Roteamento avançado – Sessão de aprendizagem 10
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”.
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: <http://www.juliobattisti.com.br/artigos>.
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:
<http://www.cisco.com/warp/public/104/1.html>. Acesso em: 22/02/2007.
De Castro, Maria Cristina F.

 . Planejamento de Redes Comutadas. Disponível em:
<http://www.ee.pucrs.br/~decastro/pdf/Redes_Comutadas_Cap2_1.pdf>.
Acesso em: 03/10/2006.
Assis, Alexandre Urtado de; Alves Jr., Nilton.

 Protocolos de Roteamento RIP e
OSPF. Disponível em: <http://mesonpi.cat.cbpf.br/naj/>. 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
Roteamento avançado
Escola Superior de Redes RNP
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
241
Bibliografia
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 4286, Multicast

 Router Discovery
roteamento-avancadopra estudo proprio.pdf

roteamento-avancadopra estudo proprio.pdf

  • 1.
  • 2.
    Escola Superior deRedes 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
  • 3.
    A Escola Superiorde 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). Roteamento avançado Apresentação
  • 4.
    Escola Superior deRedes RNP 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
  • 5.
    Sumário Sessão de aprendizagem1 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
  • 6.
  • 7.
    1 Sessão de aprendizagem1 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.
    8 Roteamento avançado –Sessão de aprendizagem 1 Escola Superior de Redes RNP Conceito de roteamento 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: Determinação das rotas ótimas; Transporte da informação (pacotes) através da rede (processo de comutação — switching). 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 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. Conceito de roteamento (1) O que é roteamento? Roteamento é a transferência de informação da origem até o destino através de uma rede. Conceito de roteamento (2) Componentes do roteamento Determinação de rotas Transporte dos pacotes (comutação) Determinação de rotas Métrica Tabelas de roteamento => Troca de mensagens Para chegar na rede Enviar para 10 Nó A 15 Nó B 20 Nó C 30 Nó A 25 Nó B 45 Nó A
  • 9.
    9 Conceitos básicos deroteamento 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 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. Transporte dos pacotes 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)
  • 10.
    10 Roteamento avançado –Sessão de aprendizagem 1 Escola Superior de Redes RNP 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 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: 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. A 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. 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 Rede Host 32 Bits 8 Bits 131 . 108 . 122 . 204 8 Bits 8 Bits 8 Bits Classe A N H H H Classe B N N H H Classe C N N N H 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
  • 11.
    11 Conceitos básicos deroteamento 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 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 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
  • 12.
    12 Roteamento avançado –Sessão de aprendizagem 1 Escola Superior de Redes RNP 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: Hosts 1. que não precisam acessar a internet; Hosts 2. 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 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. 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
  • 13.
    13 Conceitos básicos deroteamento 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. 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. 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: Se ele estiver configurado como 1. router, executará os procedimentos de roteamento IP baseado na sua tabela de roteamento residente na memória do host. Se ele não estiver configurado como 2. router, o datagrama será simplesmente descartado. 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 O host pertence à rede 131.108.2.0 1000 0011.0110 1100.0000 0010.0001 0000 1111 1111.1111 1111.1111 1111.0000 0000 1000 0011.0110 1100.0000 0010.0000 0000 Endereço IP: Máscara: Rede: Roteamento IP Diretamente conectado Gateway padrão Configuração do host IP Somente como host Como host e roteador
  • 14.
    14 Roteamento avançado –Sessão de aprendizagem 1 Escola Superior de Redes RNP 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, no RJ o endereço 172.16.10.1 e em SP o endereço 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. Exemplo de roteamento IP Rede local RJ 172.16.10.0/24 Rede local SP 172.16.20.0/24
  • 15.
    15 Conceitos básicos deroteamento 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 do endereçamento das subredes Definição dos endereços dos gateways padrão Configuração dos micros de cada subrede Testes de continuidade Em caso de mau funcionamento, resolução de problemas 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). 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). Arquitetura TCP/IP Conjunto pioneiro de protocolos “Universal”
  • 16.
    16 Roteamento avançado –Sessão de aprendizagem 1 Escola Superior de Redes RNP 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. 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 Camadas da arquitetura TCP/IP (1) Camadas da arquitetura TCP/IP (2)
  • 17.
    17 Conceitos básicos deroteamento para enviar o pacote IP. Existe então a necessidade de uma interface entre o protocolo IP e a subrede. Camada de subrede 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 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. 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. 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 Protocolo ARP Mapeia IP Ethernet Domínio de broadcasting
  • 18.
    18 Roteamento avançado –Sessão de aprendizagem 1 Escola Superior de Redes RNP 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: Os hubs e 1. switches propagam as mensagens ARP broadcasting por default; Os roteadores NÃO propagam as mensagens ARP 2. broadcasting por default. 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. Captura de pacotes IP A janela principal do Ethereal consiste das seguintes partes: Menu – Usado para iniciar algumas operações; Barra de ferramentas principal – Provê acesso rápido às operações mais usadas do menu; Captura de pacotes IP Programa Ethereal de captura de pacotes
  • 19.
    19 Conceitos básicos deroteamento 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 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; 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.
  • 20.
    20 Roteamento avançado –Sessão de aprendizagem 1 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.
  • 21.
    1 Sessão de aprendizagem1 Conceitos básicos de roteamento Roteiro de atividades Tópicos e conceitos Conceito de roteamento Endereçamento IP Classes de endereçamento Máscara de subrede Roteamento IP Camadas da arquitetura TCP/IP Protocolo ARP Competências técnicas desenvolvidas Planejamento do endereçamento das subredes Definição dos endereços dos gateways padrão Configuração dos micros de cada subrede 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.
    22 Roteamento avançado –Sessão de aprendizagem 1 Escola Superior de Redes RNP 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 inter- face definida (eth0) é a interface real. Ela pode ter qualquer endereço de rede, porque não será usada nesta atividade. Melhor deixar como esti- ver. 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.
    23 Conceitos básicos deroteamento 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. Testar a continuidade dentro da subrede 1. Comando ping para as demais máquinas da subrede Nota: todos os coman- dos devem funcionar cor- retamente. Se não, corri- gir o problema. Testar a continuidade entre subredes 2. 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 coman- dos devem funcionar cor- retamente. Se não, corri- gir o problema. Iniciar o programa Wireshark 1. Iniciar a captura na interface de rede local 2. Testar a continuidade entre subredes 3. Comando ping para uma máquina de cada subrede Comando traceroute para uma máquina de cada subrede Parar o programa Wireshark 4. Analisar o arquivo de captura 5. 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.
  • 24.
    24 Roteamento avançado –Sessão de aprendizagem 1 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.
  • 25.
    2 Sessão de aprendizagem2 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.
    26 Roteamento avançado –Sessão de aprendizagem 2 Escola Superior de Redes RNP Subredes O mundo exterior enxerga nossa organização como uma rede única, e nenhuma informação detalhada sobre nossa estrutura interna é requerida. 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. 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. 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. Subredes (1) Rede 131.108.0.0 sem subredes (131.108.0.0/16) Rede 131.108.0.0 com subredes (131.108.0.0/24) Subredes (2) Subredes (3) 131 255 255 108 255 255 0 0 255 0 0 0 Endereço de rede Máscara de subrede padrão (16 bits) Máscara de subrede de 24 bits Rede Rede Rede Host Host Subrede Host Usa bits do campo de host a partir do bit mais significativo
  • 27.
    27 Configuração de máscarade subrede Tabela de subredes 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. Tabela de subredes Bits bit 8 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 Pesos 128 64 32 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 0,128 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,.. Decimal bits rede bits host ID redes
  • 28.
    28 Roteamento avançado –Sessão de aprendizagem 2 Escola Superior de Redes RNP 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. 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. Exemplo de subrede 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 BITS SUBNET HOST SIGNIFICADO 01 000000=64 Subnet ID 01 000001=65 1o host válido 01 111110=126 Último host válido 01 111111=127 Subnet broadcasting BITS BITS SUBNET HOST SIGNIFICADO 10 000000=128 Subnet ID 10 000001=129 1o host válido 10 111110=190 Último host válido 10 111111=191 Subnet broadcasting
  • 29.
    29 Configuração de máscarade subrede 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 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. IP Subnet Calculator
  • 30.
    30 Roteamento avançado –Sessão de aprendizagem 2 Escola Superior de Redes RNP 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 <Enter>. O programa mostra todos os dados pertinentes a esta rede (tela 1). Na opção Subnet Info escolhemos 8 bits para subrede e apertamos <Enter>. 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. Exemplo IP Subnet Calculator (1) Exemplo IP Subnet Calculator (2)
  • 31.
    31 Configuração de máscarade subrede VLSM e CIDR 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; Uma subrede com 126 hosts, dividida por sua vez em duas subredes com 62 hosts cada; 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. 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 Exemplo IP Subnet Calculator (2)
  • 32.
    32 Roteamento avançado –Sessão de aprendizagem 2 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, broadcast 192.214.11.191 e hosts 11.129 até 11.190, com máscara 255.255.255.192 192.214.11.192, broadcast 192.214.11.255 e hosts 11.193 até 11.254, com máscara 255.255.255.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
  • 33.
    2 Sessão de aprendizagem2 Configuração de máscara de subrede Roteiro de atividades Tópicos e conceitos Conceito de roteamento Endereçamento IP Classes de endereçamento Máscara de subrede Roteamento IP Camadas da arquitetura TCP/IP Protocolo ARP Competências técnicas desenvolvidas Planejamento do endereçamento das subredes Definição dos endereços dos gateways padrão Configuração dos micros de cada subrede 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.
  • 34.
    34 Roteamento avançado –Sessão de aprendizagem 2 Escola Superior de Redes RNP 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ª subrede: 192.168.100.16/29, com endereços de hosts de .17 a .22 (usar o endereço .22 para o gateway padrão desta subrede); 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.
    35 Configuração de máscarade subrede 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ª subrede: 192.168.100.32/27, com endereços de hosts de .33 a .62 (usar o endereço .62 para o gateway padrão desta subrede); 2ª subrede: 192.168.100.64/27, com endereços de hosts de .65 a .94 (usar o endereço .94 para o gateway padrão desta subrede); 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.
    36 Roteamento avançado –Sessão de aprendizagem 2 Escola Superior de Redes RNP Nota: deve aparecer ape- nas o gateway padrão. 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 Nota: devem aparecer todas as máquinas da subrede. Nota: todos os coman- dos devem funcionar cor- retamente. Se não, corri- gir o problema. Testar a continuidade entre subredes Comando ping para uma máquina de cada subrede Comando traceroute para uma máquina de cada subrede 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 Este estudo de caso deve ser resolvido em 15 minutos. Os alunos podem fazê-lo em duplas. 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. Estudo de caso 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
  • 37.
    37 Configuração de máscarade subrede Atividade 3 – Estudo de caso 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. 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? Estudo de caso (cont.) Planejamento de endereçamento IP Mais duas filiais, com 8-10 computadores cada
  • 38.
    38 Roteamento avançado –Sessão de aprendizagem 2 Escola Superior de Redes RNP 4. Considerando a rede abaixo, complete as tabelas de roteamento de cada roteador. Roteador 2621A Destino Int Dist 172.16.10.0 F0/0 0 Roteador 2501A Destino Int Dist 172.16.10.0 E0 0 Roteador 2501B Destino Int Dist 172.16.10.0 S0 1 Roteador 2501C Destino Int Dist 172.16.10.0 S0 2
  • 39.
    3 Sessão de aprendizagem3 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.
    40 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP 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. 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: <Network id> <Subnet mask> <Gateway> <Metric> <outras informações> 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 de rede Protocolos 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 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.1 189.6.12.158 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 Tabela de rotas 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 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:>
  • 41.
    41 Configuração de rotasestáticas 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. 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. 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
  • 42.
    42 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP Roteamento dinâmico 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. 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
  • 43.
    43 Configuração de rotasestáticas 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. Pode- se 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. Tela do simulador de redes IMUNES
  • 44.
    44 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP Configuração das subredes Nesta figura vemos a configuração das subredes: 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 2a. 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} Configuração das subredes LAN10 172.16.10.0/24 .1 .10 .11 LAN30 172.16.30.0/24 .1 .10 .11 LAN50 172.16.50.0/24 .1 .10 .11 .1 .2 .1 .2
  • 45.
    45 Configuração de rotasestáticas 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 uma rede com software de simulação IMUNES Projetar o endereçamento das subredes Configurar os equipamentos das subredes Configuração básica de roteadores Comando ping 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. 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
  • 46.
    46 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP Comando traceroute 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. 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. 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. Comando traceroute (2)
  • 47.
    47 Configuração de rotasestáticas 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 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 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
  • 48.
    48 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP
  • 49.
    3 Sessão de aprendizagem3 Configuração de rotas estáticas Roteiro de atividades Tópicos e conceitos Tabela de rotas Roteamento estático e dinâmico Principais comandos de configuração de rotas Competências técnicas desenvolvidas Desenhar uma rede com software de simulação IMUNES Projetar o endereçamento das subredes Configurar os equipamentos das subredes Configuração básica de roteadores Tempo previsto para as atividades 60-90 minutos Observação Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou em máquina do laboratório.
  • 50.
    50 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP 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 <rede> <máscara subrede> <next hop>, onde: <rede> é a identificação da rede (network ID), no caso 172.16.30.0; 172.16.40.0; 172.16.50.0; <máscara subrede> é a máscara da subrede no formato /número de bits de rede (/24 equivale a 255.255.255.0); <next 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.
    51 Configuração de rotasestáticas 5. Digitando agora o comando sh ip route veremos as rotas aprendidas pelo router0. A figura a seguir ilustra esse processo. Precisamos agora configurar os demais roteadores. 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 sal- var 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 per- didas. 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.
    52 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP 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.
    53 Configuração de rotasestáticas 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.
    54 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP 9. Para adicionar a rota padrão e definir o gateway padrão no PC, o formato do comando é: route add <rede> <máscara de subrede> <gateway>, onde: <rede> 0.0.0.0 (rota padrão) <máscara de subrede> /0 <gateway> 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.
    55 Configuração de rotasestáticas 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.
    56 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP 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.
    57 Configuração de rotasestáticas 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. O Ethereal pergunta o que fazer com o arquivo de captura corrente. É possível escolher descartá-lo ou gravá-lo para análise posterior. Este arquivo de captura do comando ping está gravado com o nome: Captura_Ping_Ethereal, no formato libpcap. Quando o programa Ethereal é encerrado, sempre pergunta se queremos salvar o arquivo de captura de pacotes.
  • 58.
    58 Roteamento avançado –Sessão de aprendizagem 3 Escola Superior de Redes RNP 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 cap- tura com o nome que vier a seguir. O arquivo será gravado no diretório cor- rente (provavelmente /root). Não estamos usando o programa Ethereal para capturar os pacotes do traceroute por dois motivos: 1. queremos mostrar o programa tcpdump; 2. dependendo da velocidade da CPU do PC que está sendo usado, o Ethereal perde pacotes, não conseguin- do capturar todos os pacotes mostrados nas figuras a seguir. Para mostrar os pacotes usaremos o Ethereal, aproveitando a sua inter- face gráfica. 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: 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.
    59 Configuração de rotasestáticas 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.
  • 60.
    60 Roteamento avançado –Sessão de aprendizagem 3 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.
  • 61.
    4 Sessão de aprendizagem4 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.
    62 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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 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 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. 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: 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 (CIDR) 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
  • 63.
    63 Protocolo de roteamentoRIP 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 particular de redes sob uma mesma autoridade administrativa e de controle (AS). Roteadores usados para troca de informação no interior dos ASs são chamados roteadores interiores (interior routers) e usam uma variedade de protocolos chamada Interior 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). 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 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. Classificação de protocolos de roteamento Protocolos de roteamento podem ser: Interiores (Interior Gateway Protocol – IGP) – Usados para comunicação entre roteadores de um mesmo AS Exemplos: RIP – RFC2453, OSPF – RFC2328 Exteriores (Exterior Gateway Protocol – EGP) – Usados para comunicação entre roteadores de ASs diferentes Exemplos: EGP (obsoleto), BGP-4 – RFC4271 Listagem de RFCs http://www.rfc-editor.org/rfc-index2.html Roteamento dinâmico Métrica dos protocolos de roteamento Contador de hops Bandwidth (largura de banda) Delay (retardo) Custo Confiabilidade Carga MTU Ticks
  • 64.
    64 Roteamento avançado –Sessão de aprendizagem 4 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 Processo de montagem da tabela de rotas: Quando o roteador executa o 1. 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. Periodicamente cada roteador envia uma cópia da 2. sua tabela para qualquer outro roteador que seja diretamente alcançável (seus vizinhos). Cada roteador que recebe uma cópia da tabela 3. 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. Se a rota já existe na tabela e a métrica calculada é menor do que a da 3.1. rota conhecida, então remove a entrada anterior e adiciona a nova rota divulgada; Se a rota já existe na tabela e a métrica calculada é igual a da rota 3.2. conhecida, então não altera a entrada, desprezando a rota divulgada; Se a rota já existe na tabela e a métrica divulgada é maior do que a da 3.3. rota conhecida, então verifica se o gateway para esta rota é o mesmo que está fazendo a nova divulgação: 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
  • 65.
    65 Protocolo de roteamentoRIP Se o 3.3.1. gateway é o mesmo, altera a métrica para esta rota; Se o 3.3.2. gateway não é o mesmo, não altera a rota conhecida, desprezando a rota anunciada. Tabela de roteamento Vetor-Distância 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. As tabelas vistas na figura anterior serão anunciadas pelos roteadores a seus vizinhos, da seguinte forma: router0 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 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 Tabela de roteamento Vetor-Distância (2) Tabelas após o primeiro anúncio de rotas router0 Destino Next Hop Métrica Rede 10 - 1 Rede 20 - 1 Rede 30 router1 2 Rede 40 router1 2 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
  • 66.
    66 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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. 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 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 Tabela de roteamento Vetor-Distância (3) Tabelas após o segundo anúncio de rotas router0 Destino Next Hop Métrica Rede 10 - 1 Rede 20 - 1 Rede 30 router1 2 Rede 40 router1 2 Rede 50 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 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
  • 67.
    67 Protocolo de roteamentoRIP 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 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 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
  • 68.
    68 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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 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. Contagem ao infinito Tabela rotas router0 Tabela rotas router1 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 Destino Next Hop Métrica Rede 10 - 1 Rede 20 - 1 Rede 30 router1 2 Destino Next Hop Métrica Rede 10 router0 2 Rede 20 - 1 Rede 30 - 1
  • 69.
    69 Protocolo de roteamentoRIP 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. 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
  • 70.
    70 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP Pacote RIP 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. 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; Atributo 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; 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. Pacote RIP RIP usa protocolo UDP porta 520 para enviar e receber mensagens de atualização de rotas Formato da mensagem Comando Identificador Versão Deve ser zero Identificador do endereço da família Atributo da rota Endereço IP Máscara de subrede Próximo hop Métrica 0 7 8 15 16 31 Cab R T E
  • 71.
    4 Sessão de aprendizagem4 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 do protocolo RIP Pacotes RIP Configuração do protocolo RIP Competências técnicas desenvolvidas Entender o funcionamento do protocolo RIP Calcular tabela de rotas RIP Configurar roteadores com protocolo RIP Tempo previsto para as atividades 60-90 minutos Observação Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou em máquina do laboratório.
  • 72.
    72 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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
  • 73.
    73 Protocolo de roteamentoRIP 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.
    74 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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.
    75 Protocolo de roteamentoRIP 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 paco- tes 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.
    76 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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.
    77 Protocolo de roteamentoRIP 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.
    78 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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 paco- tes 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.
    79 Protocolo de roteamentoRIP 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 t (entra no modo de configuração global); int eth0 (entra no modo de configuração de interface, no caso a eth0); shutdown (coloca em off a interface, derrubando a rede 30); Ctrl-Z (sai do modo de configuração e volta para o modo privilegiado).
  • 80.
    80 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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.
    81 Protocolo de roteamentoRIP 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.
    82 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP config t (entra no modo de configuração global); int eth0 (entra no modo de configuração de interface, no caso a eth0); 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.
    83 Protocolo de roteamentoRIP Isto ocorreu imediatamente após colocarmos off-line a rede 30, derrubando a interface eth0.
  • 84.
    84 Roteamento avançado –Sessão de aprendizagem 4 Escola Superior de Redes RNP 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.
  • 85.
    5 Sessão de aprendizagem5 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.
    86 Roteamento avançado –Sessão de aprendizagem 5 Escola Superior de Redes RNP Open Shortest Path First (OSPF) 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 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
  • 87.
    87 Protocolo de roteamentoOSPF – Parte 1 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 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; Comparação RIP x OSPF CARACTERÍSTICA RIP OSPF Limite de hops 15 Não Suporta VLSM (Variable Length Subnet Mask) Sim Sim Broadcasting periódico da tabela de roteamento Sim Não Broadcasting somente quando a tabela é atualizada Não Sim Atualização de tabelas com mensagens IP multicast Sim Sim Convergência das tabelas de roteamento Lenta Rápida Decisão de roteamento baseada somente nos hops Sim Não Decisão de roteamento baseada em várias métricas Não Sim Rotas alternativas para o mesmo destino Não Sim Hierarquia de roteamento (divisão em áreas) Não Sim Autenticação das mensagens de atualização de rotas Sim Sim Comunicação com protocolos exteriores ao AS Não Sim
  • 88.
    88 Roteamento avançado –Sessão de aprendizagem 5 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 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 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 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 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 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.
  • 89.
    89 Protocolo de roteamentoOSPF – Parte 1 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) 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; A B C D E F G H 2 2 6 1 7 2 4 3 2 3 2 Algoritmo SPF – Dijkstra (3) 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; A B(2,A) C(f,-) D(f,-) E(f,-) F(f,-) G(6,A) H(f,-) 2 2 6 1 7 2 4 3 2 3 2
  • 90.
    90 Roteamento avançado –Sessão de aprendizagem 5 Escola Superior de Redes RNP Algoritmo SPF – Dijkstra (4) 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); A B(2,A) C(9,B) D(f,-) E(4,B) F(f,-) G(6,A) H(f,-) 2 2 6 1 7 2 4 3 2 3 2 Algoritmo SPF – Dijkstra (5) 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); A B(2,A) C(9,B) D(f,-) E(4,B) F(6,E) G(5,E) H(f,-) 2 2 6 1 7 2 4 3 2 3 2 Algoritmo SPF – Dijkstra (6) 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); A B(2,A) C(9,B) D(f,-) E(4,B) F(6,E) G(5,E) H(9,G) 2 2 6 1 7 2 4 3 2 3 2
  • 91.
    91 Protocolo de roteamentoOSPF – Parte 1 Algoritmo SPF – Dijkstra – Resumo A figura acima resume os passos explicados anteriormente. Passo 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). Algoritmo SPF – Dijkstra (7) 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). A B(2,A) C(9,B) D(10,H) E(4,B) F(6,E) G(5,E) H(8,F) 2 2 6 1 7 2 4 3 2 3 2 Algoritmo SPF – Dijkstra – Resumo A B C D E F G H 2 2 6 1 7 2 4 3 2 3 2 A B(2,A) C D E F G(6,A) H 2 2 6 1 7 2 4 3 2 3 2 A B(2,A) C(9,B) D E(4,B) F G(6,A) H 2 2 6 1 7 2 4 3 2 3 2 A B(2,A) C(9,B) D E(4,B)F(6,E) G(5,E) H 2 2 6 1 7 2 4 3 2 3 2 A B(2,A) C(9,B) D G(5,E) H(9,G) 2 2 6 1 7 2 4 3 2 3 2 A B C(9,B) D(10,H) G(5,E) H(8,F) 2 2 6 1 7 2 4 3 2 3 2 E(4,B)F(6,E) E(4,B)F(6,E)
  • 92.
    92 Roteamento avançado –Sessão de aprendizagem 5 Escola Superior de Redes RNP 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. 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.
  • 93.
    5 Sessão de aprendizagem5 Protocolo de roteamento OSPF – Parte 1 Roteiro de atividades Tópicos e conceitos Comparação RIP x OSPF Conceito de Estado do Enlace ( Link State) Algoritmo SPF ( Shortest Path First) Funcionamento do protocolo OSPF Configuração básica do protocolo OSPF Competências técnicas desenvolvidas Entender o funcionamento do protocolo OSPF Calcular tabela de rotas OSPF Configurar roteadores com protocolo OSPF Tempo previsto para as atividades 30-45 minutos Observação Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou em máquina do laboratório.
  • 94.
    94 Roteamento avançado –Sessão de aprendizagem 5 Escola Superior de Redes RNP 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.
    95 Protocolo de roteamentoOSPF – Parte 1 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 t (entra no modo de configuração global); 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.
    96 Roteamento avançado –Sessão de aprendizagem 5 Escola Superior de Redes RNP 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.
    97 Protocolo de roteamentoOSPF – Parte 1 10. Outro comando específico para o protocolo OSPF é sh ip ospf. As figuras mostram os resultados para os roteadores da rede.
  • 98.
    98 Roteamento avançado –Sessão de aprendizagem 5 Escola Superior de Redes RNP 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.
    99 Protocolo de roteamentoOSPF – Parte 1 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.
    100 Roteamento avançado –Sessão de aprendizagem 5 Escola Superior de Redes RNP 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
  • 101.
    6 Sessão de aprendizagem6 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.
    102 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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 – É 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; Glossário Link Router ID Loopback interface Neighbors
  • 103.
    103 Protocolo de roteamentoOSPF – Parte 2 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; 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; Glossário (cont.) Adjacency Hello protocol Flooding Neighborship database Topology database Link State Advertisement Designated router Backup designated router
  • 104.
    104 Roteamento avançado –Sessão de aprendizagem 6 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; 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 Glossário (cont.) OSPF areas Stub areas Broadcast (multi-access) Non-broadcast (multi-access) Point-to-point Point-to-multipoint
  • 105.
    105 Protocolo de roteamentoOSPF – Parte 2 conexão ponto-multiponto pertencem à mesma rede. Como nas redes ponto-a- ponto, 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 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. 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
  • 106.
    106 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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). 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 Os diferentes tipos de pacotes de estado de enlace mais comuns estão ilustrados na figura acima. São eles: Router 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; OSPF – Roteadores de borda e área (2) Pacotes de Estado de Enlace Router Links Network Links Summary Links External Links
  • 107.
    107 Protocolo de roteamentoOSPF – Parte 2 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 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: 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
  • 108.
    108 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP Area-id – Para dois roteadores no mesmo segmento, suas interfaces têm que pertencer à mesma área no segmento; Authentication – 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; Hello 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. 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. Stub 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. 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.
    109 Protocolo de roteamentoOSPF – Parte 2 Autenticação OSPF É 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 <key> (no modo de configuração da interface conectada à área) area area-id authentication (após o comando router ospf <process-id>) 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 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
  • 110.
    110 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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 <process-id>) 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 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. Backbone OSPF Todas as áreas devem estar conectadas ao backbone O backbone deve ser o ponto de partida do projeto
  • 111.
    111 Protocolo de roteamentoOSPF – Parte 2 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 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 ID – Identificação do roteador que originou o pacote; Area 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 Layout dos pacotes OSPF (1) Cabeçalho pacote OSPF Pacote Hello (sem o cabeçalho) 0 7 8 15 16 31 Version # Type Packet Length Router ID Area ID Checksum AuType Authentication Authentication 0 15 16 23 24 31 HelloInterval Network Mask Options Rtr Pri RouterDeadInterval DesignatedRouter BackupDesignatedRouter Neighbor ....
  • 112.
    112 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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 – Número de segundos decorridos entre os pacotes Hello; Options – 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.
    113 Protocolo de roteamentoOSPF – Parte 2 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 Layout dos pacotes OSPF (2) Pacote de descrição do banco de dados (s/ cabeçalho) Cabeçalho do LSA 0 15 16 23 24 31 Interface MTU Options DD sequence number 0 0 0 0 0 I M MS An LSA Header 0 15 16 23 24 31 Link State ID LS age Options LS type Advertising Router LS sequence number LS checksum length
  • 114.
    114 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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. 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. Layout dos pacotes OSPF (3) Pacote Link State Request (s/ cabeçalho) Pacote Link State Update (s/ cabeçalho) Pacote Link State Acknowledgement (s/ cabeçalho) 0 31 LS type Link State ID Advertising Router .... 0 31 # LSAs LSAs .... 0 31 An LSA Header ....
  • 115.
    6 Sessão de aprendizagem6 Protocolo de roteamento OSPF – Parte 2 Roteiro de atividades Tópicos e conceitos Conceito de roteadores de borda e de área Pacotes de Estado de Enlace Autenticação OSPF Backbone 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 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.
  • 116.
    116 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP Atividade 1 – Configuração do protocolo OSPF router0 router1 router4 router2 router3 pc10 switch0 ser0 172.16.20.1/24 ser1 172.16.30.1/24 ser0 172.16.50.2/24 ser2 172.16.40.1/24 ser1 172.16.60.1/24 ser0 172.16.20.1/24 ser2 172.16.80.1/24 ser0 172.16.40.2/24 ser1 172.16.60.2/24 ser0 172.16.30.2/24 ser1 172.16.50.1/24 eth0 172.16.10.1/24 eth0 172.16.10.10/24 e1 e0 router5 pc11 switch1 ser0 172.16.80.2/24 eth0 172.16.90.1/24 eth0 172.16.90.20/24 e1 e0 Área 1 Área 2 Área 0 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.
    117 Protocolo de roteamentoOSPF – Parte 2 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 t (entra no modo de configuração global); router ospf (habilita o protocolo OSPF); network 172.16.0.0/16 area 1 (informa a rede que será roteada na área 1). Ctrl-Z (para encerrar a configuração); 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 t (entra no modo de configuração global); router ospf (habilita o protocolo OSPF); 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.
    118 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP network 172.16.40.0/24 area 0 (esta interface está na área 0). Ctrl-Z (para encerrar a configuração); A figura a seguir mostra o console do router1. 8. Os demais roteadores são configurados conforme mostram as figuras.
  • 119.
    119 Protocolo de roteamentoOSPF – Parte 2 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.
    120 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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.
    121 Protocolo de roteamentoOSPF – Parte 2 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.
  • 122.
    122 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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).
  • 123.
    123 Protocolo de roteamentoOSPF – Parte 2 A configuração do router4 é semelhante a do router1.
  • 124.
    124 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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 t int eth0 ip address 172.16.10.1/24 quit int ser0 ip 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.
    125 Protocolo de roteamentoOSPF – Parte 2 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.
    126 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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.
    127 Protocolo de roteamentoOSPF – Parte 2 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.
    128 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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.
    129 Protocolo de roteamentoOSPF – Parte 2 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 bem- sucedidos, indicando completa conectividade através de toda a rede.
  • 130.
    130 Roteamento avançado –Sessão de aprendizagem 6 Escola Superior de Redes RNP 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.
  • 131.
    7 Sessão de aprendizagem7 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.
    132 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP Histórico 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 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)
  • 133.
    133 Protocolo de roteamentoBGP – Parte 1 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”. 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 Histórico (cont.) Sistemas autônomos Exemplos de AS
  • 134.
    134 Roteamento avançado –Sessão de aprendizagem 7 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. 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. Histórico (cont.) Exterior Gateway Protocol – EGP Vizinhos internos Vizinhos externos Problemas Loops de roteamento Pouca flexibilidade para políticas de roteamento
  • 135.
    135 Protocolo de roteamentoBGP – Parte 1 Border Gateway Protocol BGP-4 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 de keepalive são enviadas periodicamente para manter a sessão aberta; 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
  • 136.
    136 Roteamento avançado –Sessão de aprendizagem 7 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 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; 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
  • 137.
    137 Protocolo de roteamentoBGP – Parte 1 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; IGP – Protocolo de gateway interior, um protocolo de roteamento usado para trocar informações de roteamento entre roteadores dentro de um único AS; 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
  • 138.
    138 Roteamento avançado –Sessão de aprendizagem 7 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 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. Vizinhos e pares BGP
  • 139.
    139 Protocolo de roteamentoBGP – Parte 1 Atributos do BGP 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: Em sessões eBGP, o NEXT_HOP será sempre o IP de um roteador de 1. borda (peer BGP) de um AS vizinho que originou a rota; Em sessões iBGP onde a rota foi originada dentro do AS, o NEXT_HOP 2. será o endereço IP do vizinho que anunciou a rota originalmente; O NEXT_HOP aprendido pelo eBGP não é alterado pelo iBGP, 3. 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). 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
  • 140.
    140 Roteamento avançado –Sessão de aprendizagem 7 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.
    141 Protocolo de roteamentoBGP – Parte 1 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 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: router bgp 1. <AS>, onde <AS> é o número do Sistema Autônomo; 2. network <network number> mask <network mask> route-map <route-map-name> 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: 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)
  • 142.
    142 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP Vizinhos externos que residem em diferentes ASs e, normalmente, são 1. adjacentes e compartilham uma subrede; Vizinhos internos que residem em qualquer lugar do mesmo AS, não sendo 2. necessariamente adjacentes. Para isso, use o seguinte comando no modo de configuração de roteador: neighbor {ip-address|peer-group-name} remote-as <number>, 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-group- name} 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 <address>, dá reset numa conexão BGP específica; Clear ip bgp * 2. , 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: através de filtros de trajetória de AS ( 1. AS-path) usando os comandos ip as-path access-list e neighbor filter-list; Usando listas de acesso ou de prefixo com o comando 2. neighbor distribute- list, 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.
    143 Protocolo de roteamentoBGP – Parte 1 filtragem BGP são usados os comandos (iniciando no modo de configuração global): ip as-path access-list 1. 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); router bgp 2. <AS>; neighbor 3. {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; set ip next-hop 2. ip-address [...ip-address] [peer- address] 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 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 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
  • 144.
    144 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP 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: neighbor peer-group-name remote-as asn, para especificar um vizinho BGP; 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; neighbor peer-group-name description, para associar uma descrição a um vizinho BGP. 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.
    145 Protocolo de roteamentoBGP – Parte 1 BGP Peer neighbor – O protocolo BGP requer configurações específicas de vizinhos. Vejamos algumas delas: neighbor 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 ip-address description descrição-do-vizinho; neighbor 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. 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.
    146 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP
  • 147.
    7 Sessão de aprendizagem7 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 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.
  • 148.
    148 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP Atividade 1 – Configuração do protocolo BGP AS 1900 pc 10 switch 1 router 0 router 1 router 2 eth0 172.16.10.10/24 eth0 172.16.10.1/24 ser0 172.16.20.1/24 ser0 172.16.20.2/24 ser1 172.16.30.1/24 ser1 172.31.10.1/24 ser0 172.16.30.2/24 ser0 172.31.10.2/24 e0 e1 pc 20 switch 2 router 5 router 4 router 3 eth0 92.168.10.20/24 eth0 192.168.10.1/24 ser0 192.168.20.1/24 ser1 192.168.20.2/24 ser0 192.168.30.2/24 e1 e0 ser1 92.168.30.1/24 AS 6500 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 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 router2 está configurado com duas interfaces seriais: ser0 (IP: 172.16.30.2/24) e ser1 (IP: 172.31.10.1/24). O router0 usa somente o protocolo OSPF. O router1 e o router2 usam OSPF e BGP. O router 2 mantém sessão iBGP com o router1 e sessão eBGP com o router3. 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 router4 está configurado com duas interfaces seriais: ser0 (IP: 192.168.30.2/24) e ser1 (IP: 192.168.20.2/24). O router3 está configurado com duas interfaces seriais: ser0 (IP: 172.31.10.2/24) e ser1 (IP: 192.168.30.1/24). 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.
  • 149.
    149 Protocolo de roteamentoBGP – Parte 1 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 t (entra no modo de configuração global); router ospf (habilita o protocolo OSPF); 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.
    150 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP network 172.16.0.0/16 area 0 (informa as redes que serão roteadas na área 0 ); Ctrl-z (termina a configuração do protocolo). A figura a seguir mostra o console do router0. 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.
    151 Protocolo de roteamentoBGP – Parte 1 8. Abra o console no router2 e digite os comandos: config 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 A figura a seguir mostra o console do router2. Nesta figura está mostrada também a configuração do protocolo BGP que será feita mais adiante. 9. Abra o console no router3 e digite os comandos: config t router ospf ospf router-id 192.168.30.1 redistribute connected redistribute static redistribute bgp network 192.168.0.0/16 area 0 Ctrl-z
  • 152.
    152 Roteamento avançado –Sessão de aprendizagem 7 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. 10. Abra o console no router4 e digite os comandos: config 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 A figura a seguir mostra o console do router4. Nesta figura está mostrada também a configuração do protocolo BGP que será feita mais adiante.
  • 153.
    153 Protocolo de roteamentoBGP – Parte 1 11. Abra o console no router5 e digite os comandos: config 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 A figura a seguir mostra o console do router5. 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.
    154 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP 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: ping –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. 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.
    155 Protocolo de roteamentoBGP – Parte 1 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 6500 bgp 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 172.16.0.0/16 bgp router-id 172.16.30.2 neighbor INTRA-6500 peer-group neighbor INTRA-6500 remote-as 6500 neighbor INTRA-6500 update-source 172.16.30.2 neighbor 172.16.30.1 peer-group INTRA-6500 neighbor 172.16.30.1 description sessao iBGP com router1 neighbor 172.31.10.2 remote-as 1900 neighbor 172.31.10.2 description sessao eBGP com router3
  • 156.
    156 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP router3 config t router bgp 1900 network 192.168.0.0/16 bgp router-id 192.168.30.1 neighbor INTRA-1900 peer-group neighbor INTRA-1900 remote-as 1900 neighbor INTRA-1900 update-source 192.168.30.1 neighbor 192.168.30.2 peer-group INTRA-1900 neighbor 192.168.30.2 description sessao iBGP com router4 neighbor 172.31.10.1 remote-as 6500 neighbor 172.31.10.1 description sessao eBGP com router2 router4 config t router bgp 1900 bgp router-id 192.168.30.2 neighbor INTRA-1900 peer-group neighbor INTRA-1900 remote-as 1900 neighbor INTRA-1900 update-source 192.168.30.2 neighbor 192.168.30.1 peer-group INTRA-1900 neighbor 192.168.30.1 description sessao iBGP com 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.
    157 Protocolo de roteamentoBGP – Parte 1 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.
    158 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP
  • 159.
    159 Protocolo de roteamentoBGP – Parte 1 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.
    160 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP 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.
    161 Protocolo de roteamentoBGP – Parte 1 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).
  • 162.
    162 Roteamento avançado –Sessão de aprendizagem 7 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).
  • 163.
    163 Protocolo de roteamentoBGP – Parte 1 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.
    164 Roteamento avançado –Sessão de aprendizagem 7 Escola Superior de Redes RNP
  • 165.
    8 Sessão de aprendizagem8 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.
    166 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP Sessão BGP 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. 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)
  • 167.
    167 Protocolo de roteamentoBGP – Parte 2 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. 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 Mensagem OPEN 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: Mensagens BGP Tamanho mínimo de 19 e máximo de 4096 bytes Cabeçalho + Dados Campos do cabeçalho Marcador Comprimento Tipo Dados (opcional) 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 C. P. O. (OPL) 1 byte Tempo de espera (Hold Time) 2 bytes Identificador BGP (BGP ID) 4 bytes Parâmetros Opcionais (Tipo/Comprimento/Valor) Tamanho variável
  • 168.
    168 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 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: Tipo do parâmetro (1 1. byte); Comprimento do Parâmetro (1 2. byte); Valor do parâmetro (comprimento variável). 3. 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.
    169 Protocolo de roteamentoBGP – Parte 2 Na sessão anterior foram capturados pacotes de sessões BGP. Um deles está mostrado na figura acima: OPEN Message. 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 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. 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 Mensagem OPEN Tipos de mensagens BGP (2) NOTIFICATION Erro Subcódigo de erro Dados KEEPALIVE Somente o cabeçalho padrão BGP (19 bytes) Erro (Error) 1 byte Subcódigo de erro (Error Subcode) 1 byte Dados (Data) Tamanho variável
  • 170.
    170 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 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. 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 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: Rotas inalcançáveis ( 1. unreachable routes); Atributos de caminhos ( 2. path attributes); Informação de alcance da camada de rede 3. (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; Mensagem KEEPALIVE 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)...
  • 171.
    171 Protocolo de roteamentoBGP – Parte 2 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 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. 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) Reservado 1 byte SAFI (Subsequent AFI) 1 byte Identificador da família de endereços AFI – Address Family Identifier 2 bytes
  • 172.
    172 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP Mensagens de Erro Mapas de rotas 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 Mensagens de Erro ERROR CODE ERROR SUBCODE 1 Erro no cabeçalho da mensagem 1 – Conexão não sincronizada 2 – Comprimento da mensagem inválido 3 – Tipo de mensagem inválido 2 Erro na mensagem OPEN 1 – Número de versão não suportado 2 – Número de AS vizinho inválido 3 – Identificador BGP inválido 4 – Parâmetro opcional não suportado 5 – Falha na autenticação 6 – Tempo de espera inaceitável 3 Erro na mensagem UPDATE 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 6 – Atributo de origem inválido 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 (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]
  • 173.
    173 Protocolo de roteamentoBGP – Parte 2 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.
    174 Roteamento avançado –Sessão de aprendizagem 8 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; Uma negação ( deny) implícita é assumida se um determinado prefixo não existe (doesn´t match) na lista de prefixo; 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.
    175 Protocolo de roteamentoBGP – Parte 2 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 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: ip prefix-list BOGONS description (redes “óbvias” que não serão aceitas) ip prefix-list BOGONS seq 5 deny 0.0.0.0/8 le 32 ip prefix-list BOGONS seq 10 deny 10.0.0.0/8 le 32 ip prefix-list BOGONS seq 15 deny 127.0.0.0/8 le 32 ip prefix-list BOGONS seq 20 deny 172.16.0.0/12 le 32 ip prefix-list BOGONS seq 25 deny 169.254.0.0/16 le 32 ip prefix-list BOGONS seq 30 deny 192.168.0.0/16 le 32 ip prefix-list BOGONS seq 35 deny 192.0.2.0/24 le 32 ip prefix-list BOGONS seq 40 deny 224.0.0.0/3 le 32 ip prefix-list BOGONS seq 45 permit 0.0.0.0/0 le 32 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
  • 176.
    176 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP Route Reflector 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 Route Reflector (1) Número de sessões BGP: n(n-1)/2 Full-mesh BGP Solução: Route Reflector Com Route Reflector (RR) Sem Route Reflector
  • 177.
    177 Protocolo de roteamentoBGP – Parte 2 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. 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. Route Reflector (2) Cluster list
  • 178.
    178 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP
  • 179.
    8 Sessão de aprendizagem8 Protocolo de roteamento BGP – Parte 2 Roteiro de atividades Tópicos e conceitos Sessão BGP Mensagens BGP Mapas de rotas Competências técnicas desenvolvidas Apresentar funcionamento de uma sessão BGP Entender as mensagens do protocolo BGP Projetar e configurar redes com protocolo BGP Tempo previsto para as atividades 60-90 minutos Observação Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou em máquina do laboratório.
  • 180.
    180 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP Atividade 1 – Configuração do protocolo BGP pc 10 pc 20 LAN 1 LAN 2 ISP-A switch 0 switch 1 core1 router 0 router 1 router 2 eth0 172.16.10.10/24 eth2 10.0.0.1/24 eth2 10.0.1.1/24 eth0 172.16.10.1/24 eth0 10.0.31.3/28 eth1 10.0.31.1/28 ser0 172.16.20.1/24 ser0 172.16.20.2/24 ser1 172.16.30.1/24 ser1 172.31.10.1/24 ser0 172.16.30.2/24 ser0 172.31.10.2/24 ser0 192.168.1.1/24 e0 e0 e1 e2 e0 border1 switch 2 core2 eth0 10.0.31.4/28 eth0 10.0.1.2/24 eth1 10.0.31.19/28 eth1 10.0.31.2/28 eth0 192.1681.2/24 eth0 10.0.31.17/28 eth1 10.0.31.20/28 eth0 10.0.31.18/28 e3 e1 e1 e3 e0 e0 e1 e2 border2 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 router1 está configurado com duas interfaces seriais: ser0 (IP: 172.16.20.2/24) e ser1 (IP: 172.16.30.1/24). O router2 está configurado com duas interfaces seriais: ser0 (IP: 172.16.30.2/24) e ser1 (IP: 172.31.10.1/24). 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.
    181 Protocolo de roteamentoBGP – Parte 2 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.
    182 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 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 t (entra no modo de configuração global); router bgp 6500 (habilita o protocolo BGP no AS 6500); network 172.16.0.0/16 (informa as redes que serão anunciadas no AS); bgp 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 172.16.30.2 description sessao iBGP com router2 Ctrl-z (termina a configuração do protocolo).
  • 183.
    183 Protocolo de roteamentoBGP – Parte 2 A figura a seguir mostra o console do router0 após o comando sh run. 7. Abra o console no router1 e digite os comandos: config t router bgp 6500 network 172.16.0.0/16 bgp router-id 172.16.30.1 neighbor 172.16.30.2 remote-as 6500 neighbor 172.16.30.2 description sessao iBGP com router2 Ctrl-z
  • 184.
    184 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP A figura a seguir mostra o console do router1 após o comando sh run. 8. Abra o console no router2 e digite os comandos: config 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
  • 185.
    185 Protocolo de roteamentoBGP – Parte 2 neighbor 172.16.30.1 default-originate (anuncia a rota default do AS) neighbor 172.16.30.1 route-reflector-client (define o router1 como cliente do RR) neighbor 172.31.10.2 remote-as 1900 (define o border1 como vizinho) neighbor 172.31.10.2 description sessao eBGP com border1 Ctrl-z A figura a seguir mostra o console do router2 após o comando sh run.
  • 186.
    186 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 9. Abra o console no border1 e digite os comandos: config t int lo0 ip address 10.0.31.33/32 (define o endereço da interface loopback) Ctrl-z config t router bgp 1900 network 10.0.0.0/16 (informa as redes que serão anunciadas no AS) bgp 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 neighbor 10.0.31.34 update-source 10.0.31.33 (define a interface loopback como interface de origem das atualizações) neighbor 10.0.31.35 remote-as 1900 (define core1 como vizinho) neighbor 10.0.31.35 description sessao iBGP com core1 neighbor 10.0.31.35 route-reflector-client neighbor 10.0.31.35 default-originate 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 10.0.31.36 route-reflector-client neighbor 10.0.31.36 default-originate neighbor 10.0.31.36 update-source 10.0.31.33 neighbor 172.31.10.1 remote-as 6500 (define router2 como vizinho) neighbor 172.31.10.1 description sessao eBGP com router2 Ctrl-z
  • 187.
    187 Protocolo de roteamentoBGP – Parte 2 A figura a seguir mostra o console do border1 após o comando sh run.
  • 188.
    188 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 10. Abra o console no border2 e digite os comandos: config t int lo0 ip 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 A figura a seguir mostra o console do border2 após o comando sh run.
  • 189.
    189 Protocolo de roteamentoBGP – Parte 2 11. Abra o console core1 e digite os comandos: config t int lo0 ip address 10.0.31.35/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.35 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.35 Ctrl-z A figura a seguir mostra o console do core1 após o comando sh run.
  • 190.
    190 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 12. Abra o console core2 e digite os comandos: config t int lo0 ip address 10.0.31.36/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.36 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.36 Ctrl-z A figura a seguir mostra o console do core2 após o comando sh run.
  • 191.
    191 Protocolo de roteamentoBGP – Parte 2 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.
    192 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 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.
    194 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP 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.
    195 Protocolo de roteamentoBGP – Parte 2 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.
    196 Roteamento avançado –Sessão de aprendizagem 8 Escola Superior de Redes RNP
  • 197.
    9 Sessão de aprendizagem9 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.
    198 Roteamento avançado –Sessão de aprendizagem 9 Escola Superior de Redes RNP Orientações gerais 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 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 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 Orientações gerais 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
  • 199.
    199 Resolução de problemas 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. 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. RedeTeste6 Problemas propostos (2) RedeTeste7 Problemas propostos (3) RedeTeste8 Problemas propostos (4)
  • 200.
    200 Roteamento avançado –Sessão de aprendizagem 9 Escola Superior de Redes RNP Apresentação das soluções O instrutor deve determinar a ordem de apresentação e controlar os tempos de cada grupo. 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
  • 201.
    9 Sessão de aprendizagem9 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 de problemas Correção de erros de configuração Tempo previsto para as atividades 180 minutos Observação Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou em máquina do laboratório.
  • 202.
    202 Roteamento avançado –Sessão de aprendizagem 9 Escola Superior de Redes RNP 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: O 1. pc10 não consegue enxergar todos os outros PCs; O mesmo ocorre com o 2. pc40; Nenhum roteador enxerga as interfaces 3. 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: Verifique se a rota do 1. router0 para o pc40 passa pela interface eth0/192.168.31.4 (a alternativa é a interface eth1/192.168.31.20); Abra o console do 2. router3 e entre no modo de configuração da interface eth0, e dê o comando shut (coloca a interface em down);
  • 203.
    203 Resolução de problemas Aguardealgum tempo até que o 3. router0 aprenda a nova rota pela interface eth1/192.168.31.20 (lembre-se: o protocolo RIP demora um pouco para convergir); -Verifique novamente as rotas aprendidas pelo 4. router0; Verifique a rota executando um traceroute do 5. 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: O 1. PC-01 não consegue enxergar a rede além do Rot01; O 2. PC-03 não consegue enxergar a rede além do Rot03; O 3. PC-02 não consegue enxergar a rede além do Rot02; O 4. PC-04 não consegue enxergar a rede além do Rot02; Os roteadores 5. Rot01 e Rot03 não enxergam as redes do Rot02.
  • 204.
    204 Roteamento avançado –Sessão de aprendizagem 9 Escola Superior de Redes RNP 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: Os PCs não conseguem enxergar todas as interfaces de seus respectivos 1. roteadores; A tabela de rotas dos roteadores não mostra todas as subredes. 2.
  • 205.
    205 Resolução de problemas Sigaos 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: Os PCs não conseguem enxergar todas as interfaces de seus respectivos 1. roteadores; A tabela de rotas dos roteadores não mostra todas as subredes; 2. O provedor não aceitou a configuração proposta, alegando desperdício de 3. endereços IP; Questão especial: 4. 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ê?
  • 206.
    206 Roteamento avançado –Sessão de aprendizagem 9 Escola Superior de Redes RNP 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.
  • 207.
    10 Sessão de aprendizagem10 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.
    208 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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.
    209 Roteamento multicast 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. 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ços permanentes Time to Live (TTL) Endereço Descrição 224.0.0.0/24 Permanentes 224.0.1.0 até 238.255.255.255 Alcance global 233.0.0.0/8 Atribuído para Sistemas Autônomos 239.0.0.0/8 Endereços de alcance limitado Endereço Utilização 224.0.0.1 Todos os sistemas da subrede 224.0.0.2 Todos os roteadores da subrede 224.0.0.5 Roteadores OSPF 224.0.0.12 DHCP
  • 210.
    210 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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.
    211 Roteamento multicast 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 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
  • 212.
    212 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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 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. Serviços multicast Objetivo: 1 fonte n destinos Comparação Unicast x Multicast
  • 213.
    213 Roteamento multicast Tráfego multicastx unicast 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. Tráfego multicast × unicast IP multicast – RFC 1112 Comparação de tráfego 1 20 40 60 80 100 N. clientes Tráfego Mbps 0,8 0,6 0,4 0,2 0 Streaming Áudio 8kbps/cliente Multicast Unicast Fonte: Cisco Network Modelo IP multicast Protocolos Multicast Dispositivos-Roteadores Protocolos Multicast Roteadores-Roteadores Funcionamento do IP multicast Todos os dispositivos habilitados com multicasting
  • 214.
    214 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP Conceito de MBone 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 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. Conceito de MBone Multicast Backbone (MBone) Internet Engineering Task Force (IETF) Ilhas multicasting interligadas p/ túneis ponto a ponto Encapsulamento em pacotes unicast 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
  • 215.
    215 Roteamento multicast No roteamentomulticast, 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 (PIM- DM). 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.
    216 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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 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. Árvore de distribuição multicast Árvore ligada à fonte Menor caminho Árvore compartilhada Ponto de encontro
  • 217.
    217 Roteamento multicast Algoritmo deroteamento multicast 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: Rotear dados somente para os receptores dos grupos; Utilizar caminhos otimizados da fonte aos receptores; Isenção de loops nas rotas; Prover escalabilidade de sinalização para criar e manter relacionamento de grupo; Não 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. Algoritmo de roteamento multicast (1) Checagem RPF Na figura à esquerda o pacote é aceito Na figura à direita o pacote é descartado
  • 218.
    218 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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. 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. Algoritmo de roteamento multicast (2) Rendez-vous Point (RP) Algoritmo de roteamento multicast (3) Rendez-vous Point – RP (cont.)
  • 219.
    219 Roteamento multicast 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. Algoritmo de roteamento multicast (4) Rendez-vous Point – RP (cont.) Algoritmo de roteamento multicast (5) Rendez-vous Point – RP (cont.) Algoritmo de roteamento multicast (6) Rendez-vous Point – RP (cont.)
  • 220.
    220 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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. 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
  • 221.
    221 Roteamento multicast Em redescom 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. 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. MSDP (1)
  • 222.
    222 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP Responsável pela: 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 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). MSDP (2) 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
  • 223.
    223 Roteamento multicast Apenas umbit 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 ambos os endereços de origem e destino (também chamado source/destination routing). O banco de dados do estado de enlace fornece uma descrição completa da topologia do Sistema Autônomo. Adicionando um novo tipo de LSA (anúncio de estado do enlace) chamado group membership LSA, a localização de todos os membros dos grupos multicast é destacada no BD. O caminho de um datagrama multicast pode então ser calculado construindo uma árvore de caminhos mais curtos (shortest-path tree), cuja raiz está na origem do datagrama. 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); Protocolo MOSPF (2) Novo tipo de LSA: group membership LSA Os membros dos grupos são adicionados ao BD OSPF O caminho multicast é calculado pelo algoritmo SPF Os caminhos que não têm membros são podados A origem pode estar em outra área OSPF ou em outro AS Características do roteamento multicast Source/destination routing Caminho de menor custo Nas bifurcações o datagrama é replicado Caminho único entre fonte e destino (sem rota alternativa) Os pacotes IP são encaminhados como multicast de enlace
  • 224.
    224 Roteamento avançado –Sessão de aprendizagem 10 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 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. 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
  • 225.
    225 Roteamento multicast O pacoteIGMPv1 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.
    226 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP Requisitos de QoS 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 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
  • 227.
    227 Roteamento multicast dois tiposde 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 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 convencionais. O modelo de serviço tradicional oferece somente serviço de melhor esforço, bastante adequado para um grande número de 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. 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 QoS na internet 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 Espaço de armazenamento e sobrecarga nos roteadores Recursos especiais nos roteadores Serviços diferenciados Prioridade relativa sobre outras aplicações Dependendo da carga da rede o desempenho é inaceitável
  • 228.
    228 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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.
    229 Roteamento multicast Topologia domulticast 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/ 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 PIM- SM (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, Topologia do multicast backbone RNP Topologia de interconexão dos PoPs da RNP Topologia do multicast backbone RNP Malha PIM-SM
  • 230.
    230 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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 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 cliente da RNP pode utilizá-lo; Mais 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) Malha multicast da RNP Anexação ao domínio PIM- SM da RNP: • Uso do RP mantido pela RNP • Configuração simples • Somente PIM-SM necessário Criação de domínio PIM-SM local: • Uso de RP próprio • Configuração mais complexa • PIM-SM e MSDP requeridos Conexão multicast com o backbone RNP2
  • 231.
    231 Roteamento multicast Conexão multicast Conexãodireta ao domínio PIM-SM/RNP Conectar os roteadores do laboratório à malha PIM- SM 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 Conectar os roteadores do laboratório à malha PIM- SM da RNP, através de um túnel GRE para um roteador do backbone. Conexão multicast Conexão direta ao domínio PIM-SM/RNP Conexão via túnel GRE
  • 232.
    232 Roteamento avançado –Sessão de aprendizagem 10 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 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 111 deny ip any host 224.0.2.2 router(config)# access-list 111 deny ip any host 224.0.1.3 router(config)# access-list 111 deny ip any host 224.0.1.24 router(config)# access-list 111 deny ip any host 224.0.1.22 router(config)# access-list 111 deny ip any host 224.0.1.2 router(config)# access-list 111 deny ip any host 224.0.1.35 router(config)# access-list 111 deny ip any host 224.0.1.60 router(config)# access-list 111 deny ip any host 224.0.1.39 router(config)# access-list 111 deny ip any host 224.0.1.40 router(config)# access-list 111 deny ip any 239.0.0.0 0.255.255.255 router(config)# access-list 111 deny ip 10.0.0.0 0.255.255.255 any router(config)# access-list 111 deny ip 127.0.0.0 0.255.255.255 any router(config)# access-list 111 deny ip 172.16.0.0 0.15.255.255 any Conexão via RP local e MSDP
  • 233.
    233 Roteamento multicast router(config)# access-list111 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 Protocolos utilizados no backbone multicast da RNP: PIM-SM (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 ao domínio PIM-SM da RNP Criação de domínio local + MSDP router# show ip msdp summary MSDP Peer Status Summary Peer Address AS State Uptime/ Reset SA Peer Name Downtime Count Count 192.0.2.10 65001 Up 4d15h 7 28 peer1.net 192.0.2.25 65500 Up 4d10h 7 4212 peer2.com router# Conexão via RP local e MSDP (cont.) Verificação
  • 234.
    234 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP
  • 235.
    10 Sessão de aprendizagem10 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 Observação Alguns dos documentos mencionados estão disponíveis no CD-ROM do curso ou em máquina do laboratório.
  • 236.
    236 Roteamento avançado –Sessão de aprendizagem 10 Escola Superior de Redes RNP 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...”. Selecione em “ Opções Avançadas” o item “Stream/Save” e clique no botão “Configurações”.
  • 237.
    237 Roteamento multicast Obs.: OIP 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).
  • 238.
    238 Roteamento avançado –Sessão de aprendizagem 10 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”.
  • 239.
    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: <http://www.juliobattisti.com.br/artigos>. 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: <http://www.cisco.com/warp/public/104/1.html>. Acesso em: 22/02/2007. De Castro, Maria Cristina F. . Planejamento de Redes Comutadas. Disponível em: <http://www.ee.pucrs.br/~decastro/pdf/Redes_Comutadas_Cap2_1.pdf>. Acesso em: 03/10/2006. Assis, Alexandre Urtado de; Alves Jr., Nilton. Protocolos de Roteamento RIP e OSPF. Disponível em: <http://mesonpi.cat.cbpf.br/naj/>. 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.
    240 Roteamento avançado Escola Superiorde Redes RNP 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
  • 241.
    241 Bibliografia Considerações acerca doestabelecimento 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 4286, Multicast Router Discovery