Redes Digitais 2

Engenharia Informática; Engenharia de Telecomunicações e Informática; Informática e Gestão de Empresas

Relatório do 2º Laboratório de AvaliaçãoEncaminhamento de Pacotes 2010/2011

Licenciatura: ETI
Turma : ETC1
Grupo : rd2_t4_03 Data: 2010/10/29

Número do Aluno Nome do Aluno

27791 Fabiana Moura
28399 Tiago Tavares
29408 Ruben Pestana

II – Encaminhamento Estático

F – Interconectividade
4.
a) Executámos o comando tracert (máquinas Windows) e o comando traceroute (máquinas Linux) de
cada host para os dois hosts restantes, como mostram as imagens seguintes.

Figura 1: Comandos efectuados a partir da máquina XP Pro. Traceroute para 10.0.2.1(Server 2003) e 10.0.3.1 (Linux4).

Figura 2: Comandos efectuados a partir da máquina Server 2003. Traceroute para 10.0.1.1(Xp Pro) e 10.0.3.1 (Linux4).
__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
1
2010/2011 Rev. 1.0
 Figura 3: Comandos efectuados a partir da máquina Linux4. Traceroute para 10.0.1.1(Xp Pro) e 10.0.2.1 (Server 2003).

b) Os pacotes comutados entre routers mantêm sempre o mesmo endereço IP Origem e Destino.
Apenas observamos mudanças nos endereços MAC Origem e Destino.
Como podemos observar na figura 4, o primeiro Echo (ping) request tem como origem a máquina
XP Pro com endereço MAC 00.50.56.00.54.12 e destino a sua gateway (eth0 do router Linux1)
com MAC 00:50:56:00:54:25. Por sua vez, após passagem do pacote ICMP pelo router Linux1, o
segundo Echo (ping) request tem como origem o interface eth2 do router Linux1, com MAC
00:50:56:00:54:27 e destino o interface eth1 do router Linux2 com MAC 00:50:56:00:54:29.

Figura 4: Captura da comutação efectuada pelo router Linux 1 de um pacote ICMP.

c) ICMP Echo (Ping) request – É feito com o intuito de saber se existe determinado host activo na
rede.
ICMP Echo (Ping) reply – Resposta ao ICMP Echo (ping) request, com origem no host para assim
se determinar que o host está activo.
ICMP Time-to-Live Exceeded – Como estamos perante um endereçamento estático, em que
nenhum host consegue saber onde estão os seus vizinhos e quantos saltos precisa de dar até
conseguir enviar um pacote até eles, o TTL do pacote a enviar começa sempre em 1. Se o número
de saltos for maior que um, assim que este TTL chegar a 0, irá ser descartado e irá ser enviado de
novo com o TTL igual a 2 e incrementado sucessivamente, até que consiga determinar o TTL
necessário para enviar o pacote até determinado destino sem que este expire. Este tipo é enviado
quando o TTL do pacote expira, ou seja, chega a 0.
d) Sempre que um pacote passa por um router, subtrai-se um valor ao TTL.
e) O TTL é necessário para que um pacote não corra o risco de ficar eternamente na rede, a passar de
router em router. Neste caso é também necessário para saber quantos saltos o pacote deu, isto é,
por quantos routers passou.

5.
a) Uma entrada.
b) Custo zero, pois o host pertence à mesma rede.

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
2
2010/2011 Rev. 1.0
 9. Não conseguimos efectuar ping para esse endereço, dado que não existe na tabela de encaminhamento
do router Linux 1 nenhum caminho que lhe permita enviar pacotes para a rede 10.0.6.0/24, nem um
default gateway definido.

12. Ao efectuarmos o comando do ponto 10 (routeadd default gw 10.0.5.253), adicionámos um default

gateway para que quando o router Linux 1 receba pacotes e não saiba para onde os encaminhar, utilize o
default gateway para encaminhar esses pacotes, em vez de os descartar. Sendo assim, conseguimos
efectuar o ping para a rede 10.0.6.0/24.

G – Diagnóstico do Problema

3.

Figura 5: Resultado do comando “ping – n 1 10.0.3.1”

4. Observamos que, por termos inserido na tabela de encaminhamento do router Linux3, uma entrada
para encaminhar pacotes para a rede 10.0.3.0/24 através do router Linux2 que por sua vez tem na sua
tabela de encaminhamento que os pacotes deverão ser enviados pelo router Linux3, irá ocorrer uma
situação de loop entre estes dois routers, pelo que não conseguimos efectuar o ping com sucesso.

5.

Figura 6: Duas mensagens ICMP EchoRequest consecutivas.

Como podemos observar na figura 6, as diferenças entre as duas mensagens ICMP aqui representadas, são
os MACs de origem e destino e o TTL, que é decrementado a cada salto. Nas mensagens iniciais os
endereços MAC são os do percurso normal entre a máquina XP Pro e o router Linux 3, ao chegar a este
verifica-se que o MAC de origem e de destino trocam repetidamente entre as portas eth2 do router Linux
2 e Linux 3.

6. O ICMP Echo Request não fica eternamente em loop pois quando o TTL chega a 0 o pacote é
descartado.

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
3
2010/2011 Rev. 1.0
 9.

Figura 7: Resultado do comando “tracert –d 10.0.3.1”

10. Ao efectuarmos o traceroute para a rede 10.0.3.0/24, o router Linux 3 como tem na sua tabela de
encaminhamento que para encaminhar pacotes para essa rede tem que encaminhá-los para o interface eth2
do router Linux 2 que por sua vez tem na sua tabela de encaminhamento que para enviar pacotes para a
rede 10.0.3.0/24 tem que encaminhar o pacote para o interface eth2 do router Linux 3, estamos na
situação de loop já referida anteriormente e por isso, o pacote irá “saltar” de router em router até que
atinja os 30 saltos (hops) que lhe são permitidos. Estes 30 hops são uma forma de nos certificarmos que o
pacote não fica eternamente na rede.

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
4
2010/2011 Rev. 1.0
 III – Encaminhamento Dinâmico
A - RIP
1.

Figura 8: Tabela de Encaminhamento do router Linux 1.

Figura 9: Tabela de Encaminhamento do router Linux 2.

Figura 10: Tabela de Encaminhamento do router Linux 3.

As entradas adicionadas a cada tabela devido à utilização do protocolo RIP encontram-se sinalizadas nas
respectivas figuras. A flag U significa que o destino está activo, ou seja, “up”. A flag G significa que esse
dispositivo é um gateway e que será por aí que irão ter que ser encaminhados os pacotes, dependendo do
destino que se pretender.

4.
a) O protocolo RIP (Routing Information Protocol) é um protocolo de encaminhamento cujas tabelas
de encaminhamento utilizam um processo chamado route-d, do nível de aplicação. No nível de
transporte, as mensagens RIP são encapsuladas num pacote UDP(porto 520) que, por ser um
serviço sem ligação lógica e muito mais simples do que o TCP, permite ao RIP uma maior rapidez
na troca de informação, já que este gera um elevado volume de tráfego, o que seria um problema
caso se utilizasse o protocolo TCP e tivesse que se estabelecer ligações e etc. Já no nível de rede,
as mensagens são encapsuladas pelo protocolo IP.

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
5
2010/2011 Rev. 1.0
b) A versão do protocolo RIP é a versão 2, como é dito no “Routing Information Protocol”, campo
“Version”.

Figura 11: Versão do protocolo RIP.

c) Detectamos mensagens do tipo RIPv2 Response enviadas em Multicast, pelos nós para os seus
vizinhos de 20/30 em 20/30 segundos com informação das suas tabelas de encaminhamento.
Noutras situações também se podem observar mensagens RIPv2 Response quando é efectuado um
RIPv2 Request, por um router, quando este se liga pela primeira vez à rede.

d) O endereço IP do destinatário de cada mensagem RIP é o 224.0.0.9 que é o endereço Multicast,

utilizado para enviar mensagens a todos os routers que estejam a funcionar em RIP. Este endereço
Multicast é utilizado na versão 2 do RIP e apenas envia para routers, isto é, não envia para hosts,
dado que quem necessita de conhecer os caminhos possíveis na rede são os routers e não os hosts.

e) Em cada resposta do RIP é enviada a tabela de encaminhamento, que contém os vizinhos de cada
host e quantos "saltos" precisa de dar para chegar a determinado destino, como podemos observar
na figura 12. Esta informação ajuda os routers a poderem determinar o melhor caminho (mais
curto e com menor sobre carregamento) para cada ponto possível na rede.

Figura 12: Informação enviada pela mensagem anúncio do RIP. Tabela de Encaminhamento do router Linux 1

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
6
2010/2011 Rev. 1.0
 f) Este facto acontece porque o protocolo RIP funciona com o algoritmo de encaminhamento
Distance Vector Routing que pode por vezes levar a um caso de contagem para o infinito e por
isso é implementado o Split Horizon (Router A não anuncia a B os caminhos pelos quais envia
pacotes via B) e é por essa razão que nas tabelas de encaminhamento, por exemplo, do interface
eth1 do router Linux 1, (como visto na figura 12) apenas aparecem os caminhos para as redes:
10.0.1.0/24, 10.0.5.0/24 e 10.0.2.0/24 e não se mencionam as redes: 10.0.4.0/24, 10.0.6.0/24 e
10.0.3.0 pois este interface encontra-se ligado por Split Horizon com o router Linux 3.

g) O tempo entre anúncios consecutivos da mesma interface é entre 20 a 30 segundos, como se

verifica na figura 13.

Figura 13: Tempo entre anúncios consecutivos da mesma interface.

9.
a) Após desligarmos o interface eht1 do router Linux3, esperamos aproximadamente 160 segundos.
Este tempo foi calculado através do primeiro e do último ICMP – Destination Unreachable
(Network unreachable).

Figura 14: Tempo decorrido entre a actualização da tabela do Linux1 e a execução do comando do ponto 6.

As entradas que se alteraram foram as que utilizavam o interface eht1 do router Linux 3 como
gateway, uma vez que assim que se declarou esta ligação como “em baixo”, são invalidadas todas
as rotas que passem por este ponto. Como podemos verificar na figura 15, a entrada com destino
10.0.3.0/24 via 10.0.4.253 (eth1 do Linux3) foi removida.

Figura 15: Tabela de Encaminhamento do router Linux 1.

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
7
2010/2011 Rev. 1.0
 Após a actualização da tabela de encaminhamento é feita outra actualização, já com a nova rota
possível para chegar à rede 10.0.3.0/24 através da gateway 10.0.5.253 (eth1 do Linux2).

11.
a) O tempo decorrido entre o RIPv2 Request e o RIPv2 Response é de aproximadamente 11.110736 -
11.110320 = 0.000416 s.

Figura 16: Tempo decorrido entre o RIPv2 Request e o RIPv2 Response.

Este tempo é bastante diferente do obtido na pergunta 9a) e deve-se ao facto de, assim que o
interface eth1 se liga, pedir em Multicast um RIPv2 Request, ao qual o interface eth1 do router
Liunx1 responde quase automaticamente, permitindo assim ao router Linux3 actualizar a sua
tabela de encaminhamento.

IV – Pergunta Suplementar:

Para que qualquer pacote que entre no “triângulo dos routers” fique em loop eternamente até que
expire o seu TTL, basta apenas reencaminhar para o gateway que se encontra no sentido horário
na topologia todos os pacotes que se encaminhem para qualquer IP, podemos fazer isto
explicitamente para cada IP de destino existente na rede como se mostra nas seguintes tabelas de
encaminhamento:

LINUX 1
Destination Gateway
10.0.1.0 10.0.4.253
10.0.2.0 10.0.4.253
10.0.3.0 10.0.4.253
LINUX 2
Destination Gateway
10.0.1.0 10.0.5.254
10.0.2.0 10.0.5.254
10.0.3.0 10.0.5.254
LINUX 3
Destination Gateway
10.0.1.0 10.0.6.253
10.0.2.0 10.0.6.253
10.0.3.0 10.0.6.253

Outra opção válida e talvez mais simples de implementar seria limpar as tabelas de
encaminhamento presentes no router e adicionar o gateway correspondente ao sentido horário
como sendo o default gateway. Desta forma qualquer pacote com qualquer destino entraria em
loop. Tal poderia ser feito com o seguinte comando:

-Em Linux 1:

route add default gw 10.0.4.253

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
8
2010/2011 Rev. 1.0
-Em Linux 2:

route add default gw 10.0.5.254

-Em Linux 3:

route add default gw 10.0.6.253

__________________________________________________________________________
1º Semestre Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de Pacotes
9
2010/2011 Rev. 1.0