Licenciaturas em Informática e Gestão de Empresas, Engenharia de Telecomunicações e Informática e Engenharia Informática Redes Digitais II Relatório do 2º Guião Laboratorial de Avaliação: Encaminhamento de pacotes Licenciatura: ETI Turma : ETC1 Grupo : rd2_t3_02 Data: 30/10/2009 Número do Aluno Nome do Aluno 28428 Carlos Duque 28422 Diogo Neves 28423 João Rodrigues II. Encaminhamento Estático F. Interconectividade 4. a) Xp XP-Server XP-Linux4 1
Server 2003 Server - XP Server-Linux4 Linux 4 Xp Linux4 Server2003 b) Não observamos nenhuma alteração dos endereços de IP de origem e destino, observamos sim alterações nos endereços fisicos de origem e destino à medida que o pacote vai sendo comutado pelos diferentes routers, com o objectivo de este ser entregue correctamente. c) ICMP TTL (Time to Live Excedeed in Transit) Tem como objectivo descobrir o número de saltos necessários entre a origem e o destino da mensagem. Inicialmente é enviada uma mensagem com TTL igual a um para ver se chega ao destino, caso não chegue ao destino, a mensagem é descartada porque o TTL passa a zero. De seguida é enviada um nova mensagem com TTL igual a dois, este valor vai sendo incrementado, e volta-se a repetir o processo todo até que a mensagem chegue ao destino e deixe de ser descartada pela rede, neste momento o TTL é igual ao número de saltos necessários para percorrer o caminho desde a origem até ao destino. ICMP Echo (Ping) Request Tem como objectivo descobrir se um host está activo na rede. ICMP Echo (Ping) Reply É a resposta ao request indicando assim que um host está activo ou não na rede. 2
d) Sempre que a mensagem passa num router é decrementado um valor no campo TTL. e) O TTL determina o número de routers por onde o pacote passa desde o emissor até ao destino, evitando assim que o pacote fique infinitamente na rede, quando o TTL for igual a zero o pacote é descartado. 5) a) Uma entrada. b) Segundo o campo Metric o custo associado a cada entrada é igual a zero porque o host está ligado directamente à rede. 7) 9) O resultado foi o esperado uma vez que o router Linux 1 não tem na sua tabela de encaminhamento conhecimento de nenhum caminho que o leve até à rede 10.0.6.0/24 e também não existe nenhum default gateway o que faz com o pacote seja descartado. 12) Ao adicionarmos um default gateway à tabela de encaminhamento do router Linux 1, sempre que um pacote chega a esse router e ele não sabe por onde encaminhá-lo este vai ser enviado por esse gateway, em vez de ser descartado. Neste caso como o destino final é conhecido pelo router Linux 2 (definido como default gateway) o ping será bem sucedido. 3
G. Diagnóstico de Problema 3) 4) Ao efectuarmos um ping da máquina Xp para Linux4 este não será bem sucedido uma vez que no router Linux3, que encaminharia o pacote correctamente, mudámos a porta de saída com destino à rede 10.0.3.0/24 para uma que encaminha os pacotes de forma incorrecta, ficando o pacote em loop entre o Linux2 e o Linux3. 5) Podemos observar que o endereço físico de origem e de destino vão sendo ciclicamente alternados entre as portas eth2 do Linux2 e Linux3 originando assim o loop verificado e que o campo TTL é decrementado entre cada salto. 6) O ICMP echo Request não ficou eternamente em loop devido à diminuição do campo TTL até este se esgotar e o pacote ser descartado. 9) 4
10) Criámos uma situação de loop ao dizermos ao Linux3 que o gateway para a rede 10.0.3.0/24 é a porta com o IP 10.0.6.253 sendo assim sempre que uma mensagem com destino a esta rede passar neste router vai ser encaminhada para o router Linux2 que por sua vez tem na sua tabela de encaminhamento uma entrada que faz com que os pacotes com destino a esta rede sejam encaminhados para o router Linux3. Voltámos assim a cair numa situação de loop. O traceroute acaba quando o pacote atinge um número de saltos igual a 30, que é o máximo possível do comando tracert para evitar que o pacote fique infinitamente na rede. 5
III Encaminhamento Dinâmico A. RIP 1) Linux 1 Destino Gateway Flags 10.0.6.0 10.0.4.253 UG 10.0.2.0 10.0.5.253 UG 10.0.3.0 10.0.4.253 UG Linux 2 Destino Gateway Flags 10.0.4.0 10.0.5.254 UG 10.0.1.0 10.0.5.254 UG 10.0.3.0 10.0.6.254 UG Linux 3 Destino Gateway Flags 10.0.5.0 10.0.4.254 UG 10.0.1.0 10.0.4.254 UG 10.0.2.0 10.0.6.253 UG Todas as entradas apresentam as flags U e G. A flag G significa que o caminho utiliza um gateway e a flag U (UP) significa que o caminho está operacional. 4) a) As mensagens RIP são encapsuladas no protocolo UDP. Faz-se isto porque: Não é necessário estabelecer uma ligação (que adiciona atrasos); Simplicidade: não existem estados de ligação no receptor e no emissor; Pequeno cabeçalho do segmento. E uma vez que o RIP está constantemente (30 em 30 segundos) a enviar mensagens para a rede é útil fazer encapsulamento num protocolo que não seja muito complexo. 6
b) A versão do protocolo RIP é a versão 2 pois podemos observar isso no campo Version do Routing Information Protocol. c) Detectámos mensagens RIP Response, que contêm informação das tabelas de encaminhamento dos routers sendo enviadas por Multicast, cada nó informa os seus vizinhos com a informação da sua tabela de encaminhamento. Têm como objectivo actualizar os caminhos da rede, são efectuadas actualizações regulares, aproximadente de 30 em 30 segundos. Podem também servir como resposta a um request, pedido de um router que não se encontrava na rede para conhecer a topologia da rede. Ou ainda são utilizadas quando se verifiquem alterações nas tabelas de RIP local. d) O endereço de destino é 224.0.0.9 (Multicast de classe D), que é característico da versão RIPv2 que em vez de enviar pacotes para todos os pontos da rede, envia apenas para os routers que se encontram na rede e não para os hosts, uma vez que são os routers que precisam de conhecer a topologia da rede para saber como encaminhar os pacotes de forma correcta. e) Observamos que a informação contida na mensagem de anúncio RIP mostra os IP s e as distâncias (Metric) entre um nó e os seus vizinhos. Este anúncio tem como objectivo enviar para outros routers esta informação para que estes construam as suas próprias tabelas de encaminhamento e caso verifiquem que se passarem pelo router que envia o anúncio, o custo até ao destino é menor poderem actualizar a suas tabela com um novo e melhor caminho. 7
f) Vão apenas aparecer informações sobre as redes há qual o router não está ligado através de outro router por split horizon (O router A não anuncia ao router B os caminhos pelos quais envia pacotes via B). Na imagem anterior podemos ver uma mensagem que foi enviada através da porta eth1 do router Linux2 e vimos que apenas são transmitidas informações sobre as redes 10.0.2.0/24, 10.0.3.0/24 e 10.0.6.0/24 e não das redes 10.0.1.0/24, 10.0.4.0/24 e 10.0.5.0/24, uma vez que este router está ligado por split horizon ao router Linux1 que por sua vez está ligado directamente às redes 10.0.1.0/24, 10.0.4.0/24 e 10.0.5.0/24, ou seja o Linux2 vai encaminhar pacotes pelo Linux1 quando estes tenham por destino estas redes logo não vai anunciar estes caminhos. g) Tempo = 38 4 = 34 segundos perto dos 30 segundos como seria de esperar pelos tempos teóricos. 8
9) a) O tempo decorrido entre o comando do ponto 6 e a actualização da tabela foi de aproximadamente 180 segundos. Obtivemos este tempo através da diferença entre a primeira vez que não foi possivel aceder à rede, momento aproximado em que a interface foi desligada, e a ultima vez, momento em que as tabelas foram actualizadas. As alterações que observamos são que todas as entradas em que o gateway era 10.0.4.253, eth1 router Linux3 desapareceram, uma vez que esta interface foi desligada. Linux 1 Destino Gateway Flags 10.0.2.0 10.0.5.253 UG Após o tempo calculado já foi possivel aceder novamente à rede através de outro caminho que passa pelo Linux2, foi feita uma nova actualização da tabela, em que temos um novo gateway para chegar à rede de destino, 10.0.3.0/24. As duas actualizações são feitas imediatamente uma a seguir à outra. Observamos nas capturas que o campo metric nessa altura é igual a 3 ou seja tem que efectuar o caminho Linux1 Linux2 Linux3 para chegar ao destino. Linux 1 Destino Gateway Flags 10.0.6.0 10.0.5.253 UG 10.0.2.0 10.0.5.253 UG 10.0.3.0 10.0.5.253 UG 9
11) a) Tempo = 4.346253(tempo do primeiro response após o request) 4.346001(tempo em que o request foi efectuado) = 0.000252. Obtivemos uma diferença tão grande entre os tempos das duas alineas, uma vez que é efectuado um request em multicast por parte da porta eth1 do Linux3 com o objectivo de conhecer a topologia e automaticamente é efectuada um response em unicast por parte da porta eth1 do Linux1, que se encontram ligadas por split horizon, fazendo assim com que seja possivel actualizar novamente as suas tabelas de encaminhamento para um caminho mais económico. 10