relatorio AR
Propaganda
Arquitectura de Redes 2012/2013 2º Semestre RELATÓRIO LABORATORIAL Nº 3 o Grupo de Trabalho: 73937 – Karan Balu; 73967 – Carina Fonseca; 73991 – Pedro Braz. o 6. IGMP 1. Inicialmente tivemos de configurar as máquinas, PCs e routers: 1. Definimos os endereços IP de todas as máquinas, sabendo que se encontram na mesma subnet, 222.222.50.0/24. 2. Fizemos os PCs subscreverem ao grupo de multicast com endereço 230.0.0.0 1 Arquitectura de Redes 2012/2013 2º Semestre 3. Ligámos o protocolo Pim nos routers, para que possam ser elegidos Queriers na subnet. 4. Confirmámos que o PC1 tinha connectividade com todas as máquina da rede. Fig. 1 Conectividade do PC1 na subnet 2. Aplicando o comando ping 230.0.0.0 na consola do PC1, verificámos, através do Wireshark, que só foram capturados pacotes do tipo ICMP, um request com o endereço de origem do PC1 (222.222.50.110) e de destino 230.0.0.0, e dois de reply, do PC3 e PC2. Foi possível tirar logo conclusões, primeiro, o ping para o endereço de multicast só afectou as máquinas do mesmo grupo, segundo, o reply desssas máquinas foi enviado em unicast para a máquina original. 2 Arquitectura de Redes 2012/2013 2º Semestre Fig. 2 ICMP request em multicast e IMCP reply em unicast Quando se faz ping de um ip de grupo multicast, é enviado um ICMP request, em que o próprio endereço MAC, desse pacote, também é de multicast. Fig. 3 Endereço MAC de destino multicast (01:00:5e:00:00:00), para o endereço IP de multicast 230.0.0.0 3 Arquitectura de Redes 2012/2013 2º Semestre O endereço MAC de multicast é muito específico, dos seus 48 bits, os primeiros 25 têm o conteúdo 01.00.5e, em que o 25º bit é 0 e os 23 bits que restam, são os mesmos últimos bits do endereço multicast (em hexadecimal). Durante este processo não foram trocadas mensagem do protocolo ARP pelo PC1 para saber o endereço MAC do endereço IP de multicast. Usando o comando show ip igmp groups nos dois routers verificou-se o seguinte: Fig. 4 Endereços de grupos conhecidos pelo router 2 Fig. 5 Endereços de grupos conhecidos pelo router 1 Da verificação das tabelas vemos que no protocolo de IGMP os routers não precisam de saber os endereços IP de todas as máquina que estão num determinado grupo, nem quantos membros existem. Apenas precisam de ter conhecimento de que existe pelo menos uma máquina inscrita no grupo de multicast, guardando uma entrada para cada grupo. 4 Arquitectura de Redes 2012/2013 2º Semestre 3. Fig. 6 Mensagens IGMP trocadas Pelo Wireshark são capturados pacotes do tipo IGMP membership query, de 60 em 60 segundos, com origem no router R1, pelo endereço de multicast reservado 224.0.0.1. Sabe-se que o router 1 foi eleito, porque é sempre eleito como Querier o router com o menor endereço IP (esta verificação é feita usando as mensagens Query). Para o envio de pacotes é utilizado o endereço específico de multicast 224.0.0.1 que é enviado para todas as máquinas na subnet que pertençam a qualquer grupo multicast. NOTA: Este modelo de eleição dum Querier só existe para a versão 2 do protoclo IGMP. Após a recepção da mensagem query, cada host espera um tempo aleatório para mandar um report, mas só um host de cada grupo manda o report. Nós verificámos vários intervalos entre o query e o report, que iam de 1 a 5 segundos. Este report é endereçado com o endereço do grupo. 5 Arquitectura de Redes 2012/2013 2º Semestre 4. Neste ponto, fizemos o PC2 juntar-se a um novo grupo multicast, 235.0.0.0. Logo após a isso é enviado pelo próprio host um report endereçado ao novo grupo multicast. Este report não se dá como resposta a um query, por isso tem o nome de unsolicited report. Com o envio desta mensagem, não se deu qualquer resposta. Fig. 7 Unsolicited report do PC2 5. Quando se retirou o primeiro host do grupo e o segundo host do grupo, não se verificou mudanças na captura de mensagems, mas só o PC1 é que ficou a responder às mensagens relativas ao grupo 230.0.0.0. Quando se retirou o último host, este enviou uma mensagem do tipo IGMP Leave Group com endereço reservado 224.0.0.2, que é recebido pelos routers da rede. Isto deu-se porque tinha sido o último host a mandar um report. Quando isto acontece, há duas possibilidades: ou ainda há hosts no grupo, ou este era o último e o router pode apagar o grupo. Quem resolve este problema é o Querier, que, após receber a mensagem Leave Group, envia dois group specific queries endereçadas ao próprio grupo, cada um com intervalo de 1 segundo. Se não houver resposta, quer dizer que o host, que mandou o Leave Query, era o último e que então pode apagar o grupo. 6 Arquitectura de Redes 2012/2013 2º Semestre NOTA: Quando um host recebe um group specific Query não espera um tempo aleatório tão grande para responder, como acontecia com os queries normais, porque tem aproximadamente 2 segundos, até o grupo desaparecer. Fig. 8 Leave Group (PC1) e group specific queries do Querier 6. O processo de eleição do querier já foi falado no ponto 6.3, em que é escolhido o router com menor endereço IP para Querier e a verificação dá-se por mensagens Query. Nós verificámos isto da seguinte maneira: Desactivando o protocolo pim no router 1(Querier), não houve qualquer mudança na troca de mensagens, 1 minuto depois do último query mandado pelo Querier, não se viu uma nova mensagem query, como era suposto. Só 2 minutos depois é que o router 2, assumiu a função de Querier e começou a enviar os queries para a rede. 7 Arquitectura de Redes 2012/2013 2º Semestre Fig. 9 Novo Querier Quando se voltou a activar o protocolo pim no router 1, este verificou que estava a receber queries de um router com maior endereço IP, por isso começou a enviar os seus próprios queries. O router 2 parou de servir de Querier porque recebeu queries que um router com menor endereço IP. o 7.PIM-DM (Dense Mode) 2. Os hello packets servem para descobrir e manter as relações com os vizinhos. O período de cada hello packet é 30 segundos. Nesta captura os hello packets têm como origem o router 3 e o router 4, e o destino é para o endereço multicast (224.0.0.13) que corresponde a todos PIM routers. 8 Arquitectura de Redes 2012/2013 2º Semestre Figura 1 – Hello packets capturados na subnet 222.222.50.0/24 3. Nesta alínea, efectuaram-se os pings para o grupo 230.0.0.0 no PC2 observando-se o seguinte. Figura 2 – Ping no PC2 para o grupo 230.0.0.0 9 Arquitectura de Redes 2012/2013 2º Semestre PC 2 recebe duas respostas do PC1, pois a árvore ainda não foi desbastada. Desta forma a mensagem reply do PC 1 é enviada para os routers 3 e 4 e assim o PC2 recebe as mensagens a partir do router 4 e 3. As figuras seguintes ilustram as incoming interfaces e os estados das outgoing interfaces de cada router. Figura 3 – Multicast routing table do router 1 Figura 4 – Multicast routing table do router 2 Figura 5 – Multicast routing table do router 3 Figura 6 – Multicast routing table do router 4 Respondendo às questões colocadas no enunciado, A interface f0/1 do router 3 encontra-se no estado prune pois o custo total PC2 para os PCs 1 e 3 é menor seguindo a interface f1/0 do router 1. O lifetime da tabela multicast é 3 minutos. 10 Arquitectura de Redes 2012/2013 2º Semestre 4. Depois de se efectuar os multicast pings dos PCs 2 e 3, obteve-se as seguintes multicast routing tables. Figura 7 – Multicast routing table do router 1 Figura 8 – Multicast routing table do router 2 Figura 9 – Multicast routing table do router 3 Figura 10 – Multicast routing table do router 4 11 Arquitectura de Redes 2012/2013 2º Semestre Com base nos estados das interfaces dos routers, conclui-se que haverá duas árvores de distribuição multicast, uma para o PC2 e outra para o PC3. A figura seguinte ilustra as árvores. Figura 10 – Multicast routing table do router 4 Figura 11 – árvores de distribuição 5. Pela figura 13, é possível verificar que o assert winner na subnet 222.222.50.0/24 será a interface f0/1 do router 4 pois contem a flag A. Figura 12 – multicast routing table do router 3 Figura 13 – multicast routing table do router 4 12 Arquitectura de Redes 2012/2013 2º Semestre Com a base nas capturas feitas, notou-se que o router 1 envia o pacote request para os routers 3 e 4, como se pode ver nas figuras 14 e 15. Na subnet 50.0/24 há duas mensagens request, uma do router 3 e outra do router 4, aqui são enviadas mensagens assert para eleger o assert winner. A interface f0/1 do router 4 envia Prune para a interface f0/1 do router 3, pois recebeu um melhor assert. Figura 14 – Captura feita na subnet 222.222.20.0/24 Figura 15 – Captura feita na subnet 222.222.30.0/24 Figura 16 – Captura feita na subnet 222.222.50.0/24 6. Nesta alínea seguiu-se as instruções fornecidas no enunciado. De seguida ilustram-se duas multicast routing tables do router 4, em que a primeira é quando o PC3 não está no grupo 230.0.0.0 e a segunda é quando o PC3 já se encontra no grupo. 13 Arquitectura de Redes 2012/2013 2º Semestre Figura 17 – multicast routing table do router 4 Figura 18 – multicast routing table do router 4 De notar o estado prune da interface f0/0 na figura 17 e o estado forward da mesma interface na figura 18. Analisando as multicast routing tables do router 4 mais a captura feita na subnet 222.222.40.0/24, que é ilustrada na figura 19, pode-se concluir que R2 envia uma mensagem Prune para o router 4 quando o PC3 é removido do grupo 230.0.0.0. É enviado uma mensagem do tipo graft pelo router 2 quando o PC3 junta-se novamente a 230.0.0.0, mudando assim o estado da interface f0/0 do router 4 de prune para forwarding. Figura 19 – Captura feita na subnet 222.222.40.0/24 14 Arquitectura de Redes 2012/2013 2º Semestre 7. De modo a obter as rotas pretendidas, apenas colocou-se um custo de 30 à interface f1/0 do router 4 e mudou-se o custo para 20 da interface f0/1 do router 3. Para verificar se as mudanças de custo tiveram o efeito desejado, basta efectuar o multicast ping para 230.0.0.0 a partir dos PCs 1 e 2 e verificar a multicast routing table do router 1. Figura 20 – multicast routing table do router 1 A árvore para o PC1 tem a interface f0/1 e a interface f0/0 do router 1 em modo prune e forward, respectivamente, obrigando o PC1 a usar a subnet 222.222.30.0/24. Analogamente, a árvore para o PC2 tem a interface f0/1 e a vlan1 do router 1 em modo forward e prune, respectivamente, obrigando o PC2 a não usar a subnet 222.222.30.0/24. o 8.PIM-SM 2. Seguindo as instruções referidas no enunciado e com base na análise das multicast routing tables, segue-se uma explicação de criação de uma árvore PIM-SM shared tree. No início as multicast routing tables encontram-se vazias. Quando PC2 se junta ao grupo 230.0.0.0, este PC envia uma mensagem do tipo IGMP report para o rendevouz point, router 1, colocando a interface f0/0 do router 1 em modo forward. Os restos das tabelas encontram-se vazias. 15 Arquitectura de Redes 2012/2013 2º Semestre Figura 21 – multicast routing table do router 1 Após PC1 se juntar ao grupo 230.0.0.0, o receptor vai enviar um IGMP report para o last hop ou seja R4. Este por sua vez vai enviar uma mensagem join que tem como destino R1. Esta mensagem coloca em estado forward todas as interfaces por qual passa. Figura 22 – multicast routing table do router 1 Figura 23 – multicast routing table do router 3 Figura 24 – multicast routing table do router 4 Quando o PC3 junta-se ao grupo 230.0.0.0, o receptor envia IGMP report e o R2 envia uma mensagem join em direcção ao R1 que ficará por R4 pois a árvore já está formada de R4 para R1. Figura 25 – multicast routing table do router 1 Figura 26 – multicast routing table do router 2 16 Arquitectura de Redes 2012/2013 2º Semestre Figura 27 – multicast routing table do router 3 Figura 28 – multicast routing table do router 4 Neste último passo apenas há alteração nos routers 2 e 4 em que no router 2 a interface f0/1 fica em estado forward e no router 4 a interface f0/0 fica em modo forward. A figura 29 mostra um pacote do tipo join capturado na subnet 222.222.30.0/24 onde se pode verificar o endereço de IP do rendevouz router. Figura 29 – Mensagem join capturada na subnet 222.222.30.0/24 Explicado o processo de construção da shared tree adaptado à experiência do laboratório, procede-se à explicação da desconstrução da mesma árvore. PC3 quando sai do grupo 230.0.0.0 irá enviar um IGMP leave para R2. Este router envia uma mensagem Prune, com destino para RP, que eventualmente será descartada no router 4 pois PC1 ainda encontra-se no grupo. A mensagem Prune retira o estado forward de todos os routers por qual passa. As figuras seguintes ilustram as multicast routing tables que compõem a árvore após o leave do PC3. 17 Arquitectura de Redes 2012/2013 2º Semestre Figura 30 – multicast routing table do router 1 Figura 31 – multicast routing table do router 2 Figura 32 – multicast routing table do router 3 Figura 33 – multicast routing table do router 4 Router 4 sabe que PC1 deseja sair do grupo 230.0.0.0, pois recebeu um IGMP leave. O router vai assim enviar um pacote Prune para o router 1, retirando o estado forward das interfaces f1/0 do router 1 e f0/1 do router 4. Seguem-se as multicast routing tables. Figura 34 – multicast routing table do router 1 Figura 35 – multicast routing table do router 3 18 Arquitectura de Redes 2012/2013 2º Semestre Figura 36 – multicast routing table do router 4 Depois de PC2 sair: Já não existe nenhum host que faça parte do grupo 230.0.0.0, portanto o RP não terá nenhuma outgoing interface. Figura 37 – multicast routing table do router 1 A figura 38 ilustra uma mensagem Prune capturada na subnet 222.222.30.0/24, quando o PC1 saiu do grupo multicast. Figura 38 – mensagem prune capturada na subnet 222.222.30.0/24 19 Arquitectura de Redes 2012/2013 2º Semestre 3. Ao fazer o ping para 230.0.0.0 de todos os PCs obtêm-se as seguintes multicast routing tables. Figura 39 – multicast routing table router 1 Figura 40 – multicast routing table router 2 20 Arquitectura de Redes 2012/2013 2º Semestre Figura 41 – multicast routing table router 3 Figura 42 – multicast routing table router 4 21 Arquitectura de Redes 2012/2013 2º Semestre Analisando as multicast routing tables pode-se concluir que existem 4 árvores, a shared tree mais uma para cada fonte. A topologia destas árvores é a mesma representada na figura seguinte. Figura 43 – topologia das 4 árvores 4. Seguindo as instruções do enunciado, obtiveram-se os seguintes resultados: Multicast routing tables quando PCs 2 e 3 não estão no grupo 230.0.0.0. Figura 44 – multicast routing table do router 1 Figura 45 – multicast routing table do router 2 22 Arquitectura de Redes 2012/2013 2º Semestre Figura 46 – multicast routing table do router 3 Figura 47 – multicast routing table do router 4 Uma captura, na subnet 222.222.40.0/24, no wireshark ilustrando as mensagens Register e Register-Stop. Figura 48 – captura na subnet 222.222.40.0/24 Routing tables depois de efectuar os pings. Figura 49 – multicast routing table router 1 23 Arquitectura de Redes 2012/2013 2º Semestre Figura 50 – multicast routing table router 2 Figura 51 – multicast routing table router 3 Figura 52 – multicast routing table router 4 Juntando toda esta informação, segue-se uma explicação do source register process PIM-SM. PC3 envia multicast packet para o seu last hop, o router 2. Este router envia PIM register message com destino ao rendevouz point, a mensagem register encapsula a multicast packet e é enviado pela shared tree. RP envia uma mensagem join até PC3, colocando no estado forward todas as interfaces dos routers por qual passa. Quando a SPT é formada, RP começa a receber tráfico ou seja o RP difunde a mensagem register e a multicast packet sendo que para o segundo ping efectuado, PC3 recebe duas mensagens do tipo reply como se pode observar na figura 48. Para parar a difusão da mensagem register, o RP envia um register-stop para o router 2. PC3 agora já se encontra incorporado na árvore como se pode verificar com as novas entradas nos routers 2 e 4. 24
