UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMTICA DEPARTAMENTO DE INFORMTICA APLICADA

INF01154 Redes de Computadores N - Turma D Laboratrio 05

Gilson Souza 180586 William Vidal 170982 Atividades OBS: para obter n. IP e MAC pode-se utilizar o comando ipconfig /all 1. Leia o help do ping (ping /?) e efetue os seguintes testes: a. Fazer um ping com 8 requisies de echo, tamanho do pacote de 200 bytes, TTL de 80. Mostre o comando utilizado e prove que funcionou atravs de uma imagem. O comando utilizado pode ser visto na imagem abaixo, bem como o seu funcionamento.

Figura 01 - Comando ping. b. Fazer um ping forando a no fragmentao do pacote (-f) e tamanho do pacote de 1600 bytes. Verificar qual o mximo tamanho do pacote que funciona. Explique. Com um pacote de 1600bytes no foi possvel, como pode-se ver na imagem abaixo.

Figura 02 - Comando ping forando a no fragmentao. O tamanho mximo do pacote no fragmentado foi de 1472 bytes. O tamanho mximo de dados de um pacote Ethernet 1500 bytes. Porm, os primeiros 20 bytes so o cabealho do protocolo IP e outros 8 bytes do protocolo ICMP. Na imagem abaixo, mostrado o pacote de 1472 bytes enviados com sucesso em contraste com um de 1473 bytes, onde gerou a falha.

Figura 03 - comando ping, erro na fragmentao.

c. Qual a mensagem (pacote de dados) enviados num comando de ping? Sugesto: analise o pacote ICMP.

Figura 04 - Comando ping, dados. mandado uma sequncia de caracteres (de "a" a "w") repetidamente, como pode ser visto na imagem acima. 2. Utilizar um sniffer de redes para analisar o funcionamento do ping. Capturar o ping de sua mquina para um vizinho, preencha na tabela linha a linha a sequncia de comandos de um ping, explicando cada linha (mostrando o endereo nvel 2 e nvel 3 envolvido em cada linha). Tambm deve ser considerado o protocolo ARP, alm do ICMP. Pode-se utilizar a simbologia MAC_A (MAC da mquina A), MAC_B (MAC da mquina B) e MAC-R (MAC do roteador), por exemplo. Da mesma forma, pode-se utilizar IP_A, IP_B, etc. Quando no existir pacotes no nvel, basta colocar No tem na tabela.

Protocolo End. Nvel 2 End. Nvel 3 Descrio Ex: arq request Ex: Mac_x -> bl Ex: icmp request Ex: Mac_x -> Mac_y Ex: IPx->IPy

Protocolo

End. Nvel 2 MAC_A -> Broadcast MAC_B -> MAC_B MAC_A -> MAC_B MAC_B -> MAC_A

End. Nvel 3 No tem No tem IP_A -> IP_B IP_B -> IP_A

Descrio

ARP Request ARP Reply ICMP Request ICMP Reply

MAC_A pergunta em Broadcast MAC_B Retorna o end. fsico do Ip solicitado anteriormente MAC_A envia ping para MAC_B MAC_B responde ping para MAC_A

Tabela 01 - Funcionamento do ping nas camadas. 3. Repetir a tabela acima, porm fazendo ping para uma subrede diferente. Qual a principal diferena?

Protocolo

End. Nvel 2

End. Nvel 3

Descrio

MAC_A solicita end. IP do roteador (default gateway). Retorna o endereo MAC_R -> MAC_A No tem ARP Reply fsico do roteador. IP_A -> Requisita a resoluo No tem DNS Request DNS_UFRGS do endereo. DNS_UFRGS -> Retorna o IP do end. No tem DNS Reply IP_A requisitado. MAC_A envia ping MAC_A -> MAC_R IP_A -> IP_R ICMP Request para MAC_R MAC_R responde MAC_R -> MAC_A IP_R -> IP_A ICMP Reply ping para MAC_A MAC_R que saber MAC_R -> MAC_A No tem quem possui o end. IP ARP Request 10.67.105.7 MAC_A responde que MAC_A -> MAC_R No tem ele (retornando seu ARP Reply end. MAC) Tabela 02 - Funcionamento do ping nas camadas. ARP Request MAC_A -> Broadcast No tem Onde MAC_R o MAC do roteador (gateway) e IP_R o IP do roteador. A principal diferena que toda a comunicao acontece atravs do roteador. O MAC_A envia seus dados para o roteador, que envia para o MAC_B. Assim como a resposta de MAC_B

tambm enviada para o roteador (que responde ao MAC_A). As duas mquinas no sabem a localizao uma da outra, elas enviam para o roteador e ele que realiza o trabalho.

4. SOBRE O ARP: a. Explicar o funcionamento do protocolo ARP baseado nos seus campos de cabealho. Para isso, pode-se olhar na especificao do protocolo (buscar na RFC) ou analisar no sniffer, pois o mesmo prov todos os campos do protocolo. Explique o motivo do ARP request no conter o endereo MAC do destino (campo zerado), e o motivo que o ARP reply contm todos os campos preenchidos.

Figura 05 - Cabealho do Protocolo ARP. O protocolo ARP utilizado para que o transmissor descubra o endereo fsico do receptor atravs de seu IP. Para isso o receptor envia uma mensagem com o endereo de broadcast no campo TARGET HA. Ele envia seu endereo fsico (MAC) no campo SENDER HA, o seu endereo IP no campo SENDER IP e o endereo IP alvo no campo TARGET IP. A mquina que possui o IP alvo do campo TARGET IP responde a mensagem informando o seu endereo fsico no campo SENDER HA e atualiza os campos TARGET HA com o endereo fsico da mquina que o procurava, o TARGET IP com o IP da mquina que o procurava, e o SENDER IP com o seu endereo IP. A partir de ento o transmissor conhece o endereo fsico para qual destinar as futuras mensagens. b. Explicar o motivo pelo qual o ARP acontece somente na primeira vez que feito o ping para uma determinada mquina. Dica: utilizar "arp /?" e "arp -a". Quanto tempo dura essa informao?. Isso acontece pois, na primeira vez que feito m ping para uma maquina, o endereo MAC do destino colocado na tabela ARP, que pode ser vista utilizando o comando arp -a. O tempo que essa informao dura depende da implementao que foi feita. Na implementao feita pela Microsoft essa informao criada com um tempo estipulado de10 minutos mas, se ela no for utilizada, ela apagada em dois minutos.

5. SOBRE O TRACEROUTE a. Utilizar o traceroute (ou tracert) para descobrir o nmero de hops e os roteadores por onde os pacotes esto trafegando at: i. www.ufrgs.br ii. http://www.nhk.or.jp Como estamos na rede da ufrgs, o primeiro caminho teve poucos roteadores, como pode ser visto na imagem abaixo.

Figura 06 - Rota at o Servidor da UFRGS. No caso do segundo caminho, possvel ver a rota da UFRGS at destino, passando pelo pop-rs, pela rede rnp, chegando nos roteadores do Japo, at o destino, como pode ser visto na imagem abaixo.

Figura 07 - Rota da INF at o Japo. b. Para que serve o traceroute? Qual sua relao com o TTL? Para que serve o TTL?

Serve para rastrear a rota de um pacote atravs da rede. Seu funcionamento esta diretamente relacionado com o TTL do pacote. Para descobrir a rota Ele envia um pacote ICMP com TTL incremental, comeando em 1 at atingir a mquina de destino. Logo, a primeira mensagem tem TTL=1, e retorna com o nome do primeiro roteador. Quando TTL=2, descobre-se o nome do segundo roteador, e assim por diante. 6. Instalar o software Polycom PVX (Windows XP) ou Polycom Telepresence m100 (Windows 7) ou Ekiga (Linux ou Windows) e estabelecer uma chamada em duplas. Medir o atraso ida e volta da transmisso com cmera (no com captura de tela). Disparar o xnote stopwatch (ou equivalente) na mquina A. A mquina A filma (com a webcam) a tela da mquina A, transmitindo essa imagem para a mquina B. A mquina B filma a tela. Na mquina A recebida a imagem transmitida, do seu prprio cronmetro. Captura-se a tela e obtm-se o atraso.

Figura 08 - Captura de tela usando o Polycom Telepresence m100. O atraso, como pode ser visto na imagem acima, de 29 centsimos de segundo, considerando o atraso de envio e de recebimento. 7. Instalar o sniffer de redes Wireshark e fazer uma comunicao em duplas via PVX. Sugesto: usar

filtros: ip.src== ou RTCP ou RTP ou a. Identificar cabealhos RTP e RTCP (mostrar uma imagem com RTP e outra com RTCP no wireshark). Qual a diferena de direo e quantidade de pacotes de cada um? RTP so mensagens para transmisso de dados, enquanto RTCP funciona como mensagens de controle. Ao longo de uma sesso de videoconferncia, so enviadas poucas mensagens do tipo RTCP (no nosso print de exemplo no h nenhuma), enquanto que h muita troca de dados (pacotes RTP) para que a videoconferncia seja possvel, conforme mostra as figuras 10 e 11 para vdeo, e figura 9 para udio.

Figura 09 - Pacote de udio.

Figura 10 - Pacote de vdeo, parte 1 com 934 bytes.

Figura 11 - Pacote de Vdeo, parte 02, com 534 bytes.

b. Para o RTP, identificar e justificar os campos verso, Payload Type, Sequence Number, timestamp. Verso - indica a verso do protocolo RTP usado. Nesse caso, a verso a correspondente ao RFC 1889. Payload Type - identifica o tipo de dados contidos no Payload (udio, vdeo, imagem, texto, HTML, etc.). Sequence Number - serve para ordenar os pacotes de uma comunicao, sendo que o primeiro pacote recebe um nmero sequencial aleatrio e os seguintes recebem o nmero sequencial do pacote anterior incrementado de um. Pode ser til tambm para detectar perda de pacotes intermedirios. timestamp: indica o momento em que o primeiro byte do pacote RTP foi gerado. c. Descobrir quais pacotes so de udio e quais so de vdeo. Justificar, utilizando como base a diferena entre tamanho e quantidade dos pacotes de cada fluxo. Utilize como apoio o timestamp dos pacotes. Sugere-se fortemente filtrar por fluxo. Analisando os pacotes, chegamos a concluso de que os pacotes com RTP Type-126 so de vdeo e os com RTP Type-127 so de udio. Isso pode ser observado atravs dos timestamps dos pacotes, por exemplo. Para vdeo, existem vrios pacotes com o mesmo timestamp. J para udio, apenas um pacote para cada timestamp. Como os pacotes de vdeo so normalmente maiores, necessrio que o pacote seja fragmentado. Os pacotes de udio, alm de serem nicos, tem um tamanho pequeno e fixo (de acordo com o teste realizado, permanecendo maior parte do tempo sem conversar). 8. Para a codificao de udio utilizada e caractersticas do laboratrio, calcule: a. Tempo mdio de insero O pacote de udio tem 294 bytes e a banda no laboratrio de 100Mbps (12,5MBps), logo:

b. Atraso no meio fsico, supondo 40m a distncia entre sua mquina e o switch do INF. A distncia de ida e volta equivale a 80m e a velocidade de transmisso no par tranado equivale a logo:

9. Obtenha um histograma do valor mdio do tamanho dos pacotes que trafegaram pela rede durante o perodo considerado. Ver opo statistics+packet lengths. Faa a anlise duas vezes: a) iniciando a captura e navegando na web (perfil navegao web);

Figura 12 - Navegao em site. b) iniciando a captura e fazendo um download de arquivo de tamanho razoavelmente grande (acima de 10 Mbytes). Compare os resultados em relao ao tamanho do pacote. Explique.

Figura 13 - Realizao de download. Atravs dos relatrios gerados no Wireshark, para uma navegao normal e para um download, perceptvel que na navegao existem poucos pacotes de tamanho elevado

(1280-2559). Nesse caso, a maior parte dos pacotes se concentra em pacotes com tamanho entre 40-80. Quando realizamos um download, percebemos que existem poucos pacotes de tamanho pequeno/mdio. A maioria dos pacotes (66,27%) tem tamanho grande (12802559).

10. Faa uma anlise completa de um quadro MAC que contenha encapsulado um pacote IP e TCP (sugesto: faa um download qualquer). Liste todos os valores dos diversos campos encontrados no cabealho do quadro MAC e nos cabealhos do pacote IP e do segmento TCP encapsulado. Explique os valores encontrados e suas unidades quando for o caso. Comeamos pelo quadro Ethernet, podemos ver na imagem abaixo, os campos de fonte e destino MAC.

Figura 14 - Endereo MAC destino. No destino, est o endereo MAC do roteador.

Figura 15 - Endereo MAC fonte. Com o terminal aberto ao lado possvel perceber que os valores esto corretos. Ainda resta o campo Type, que indica o tipo de protocolo superior usado, no caso o IP, como destaca a figura abaixo.

Figura 16 - Campo Type. Na teoria os valores batem com a prtica, como pode ser visto na imagem abaixo:

Figura 17 - Cabealho do Protocolo Ethernet 802.1.

Passando para o quadro IP, analisando o seu cabealho vemos as seguintes informaes: Verso do IP, tamanho do cabealho, prioridade(Differentiated services Field), tamanho total do payload, identificao, flags, offset fragmento, TTL, protocolo usado, Cheksum do cabealho, origem e destino. Cada um desses campos ser explicado detalhadamente.

Figura 18 - Cabealho do Protocolo IP sniffado. Agora vamos relacionar o que vimos sniffando a rede com a teoria. Usaremos a figura 19 abaixo como base. A verso do Protocolo IP corresponde ao IPv4, como estudado na teoria (pode ser visto na imagem abaixo), o tamanho do cabealho de 20 bytes, ou seja, 5 palavras de 4bytes. O campo TOS est relacionado com a prioridade, por default est zerado. Em Total Length indica o tamanho do payload, ou seja, o valor puro dos dados (sem o overhead). Em identification esta relacionado com o fragmento do datagrama. H trs bits de flags, que so usados para controle e/ou identificao dos fragmentos. Em

Fragment Offset indica que no houve fragmentao. O TTL o tempo de vida dos pacotes, que nesse caso de 128 segundos. Em Protocol, indica o protocolo usado na camada superior (transporte), no caso o TCP (valor 6). Em Header Checksum, est o valor do checksum do pacote que ser utilizado posteriormente no recebimento para deteco de erro. Em Source IP Address, vai o valor IP da fonte e em Destination IP Address, vai o valor IP do destino, ambos com 32bits e em Options o campo dos opcionais.

Figura 19 - Cabealho do protocolo IP terico.

Passando para o segmento TCP, analisando as informaes sniffadas, temos: Porta da fonte, porta de destino, stream, nmero de sequencia, next byte, ack, tamanho do cabealho, Flags, tamanho da janela (inclui o calculo da janela o fator escalvel), Checksum e SEQ/ACK (onde encontram-se informaes sobre o tempo de RTT para o ack e nmero do segmento Ack).

Figura 20 - Cabealho do protocolo TCP sniffado. Finalizando com o segmento TCP, vamos relacionar o seu cabealho com a parte terica, importante notar que alguns campos vistos com o wireshark no sniffamento da rede no so mencionados nos cabealhos encontrados na teoria (vamos detalha-los em seguida). Usaremos a figura (xxx) abaixo como base. Source Port Number indica o valor da porta que est enviando (fonte). Destination Port Number indica o valor da porta que est recebendo (destino). Em Sequence Number, h o valor do nmero de sequencia onde encontramos o campo stream index (visto no sniffamento). Em seguida h o campo do Ack onde encontramos o campo next sequence number (visto no snifamento). Em Header Length est o tamanho do cabealho, assim como o IP, 5 palavras de 4bytes. Dentro de Flags (6 bits, URG, ACK, PSH, RST, SYN e FIN), h um campo de 6 bits reservado para o futuro. Em Window Size, o valor do tamanho da janela deslizante (usada para o controle de fluxo). Em TCP Checksum, h o valor do checksum do pacote que ser utilizado posteriormente no recebimento para deteco de erro. O campo Urgent Pointer no foi possvel visualizar no wireshark,

indica o ltimo segmento que tenha o flag URG setado e em Options o campo dos opcionais

Figura 21 - Cabealho do protocolo TCP terico. 11. Utilizar o software Iperf (iperf h para help), que deve ser disparado em duas mquinas, uma sendo servidor iperf s e outra cliente. Tem que disparar o servidor de forma diferente para teste em UDP ou TCP. iperf s u para UDP ou iperf s para TCP. EXEMPLO DE CLIENTE COM UDP: iperf f m i 1 c ipservidor t 30 p 2000 u b 10M l 1400 (formato em Mbit/s, informa banda enviada a cada segundo, tempo de 30s, porta 2000, banda mxima de 10Mbit/s, tamanho de pacote 1400 bytes). No relatrio devem constar o resultado dos trs seguintes objetivos: a. Mostrar linhas de comando utilizadas e gerar grfico udp para 3 bandas diferentes (ex: 1Mbit/s, 10Mbit/s e 30Mbit/s). Mostrar e explicar o grfico gerado.

Figura 22 - Comandos utilizados para gerao de trafego UDP. A linha de comando utilizada para gerar o trafego na rede pode ser vista na figura acima, onde apenas alteramos o valor do parmetro b para 1, 10 e por fim 30, como foi solicitado no exerccio. A linha exatamente foi: iperf f m i 1 c 143.54.13.185 t 30 p 5001 u -b 1M l 1400

Figura 23 - Grfico da gerao de trafego UDP.

No grfico acima podemos ver a utilizao da rede para cada comando udp rodado. Iniciamos rodando com 1 Mbps, teve um espao de tempo at iniciar o prximo comando que utilizou a banda de rede de 10Mbps e ento o ultimo comando executado para gerar um trafego de 30 Mbps. Pode-se perceber um pico no grfico enquanto utilizava-se 10mbps na rede, o que provavelmente aconteceu por algum outro processo ter disparado durante a execuo do comando.

b. Mostrar linhas de comando utilizadas e gerar grfico TCP da estao incrementando o nmero de conexes para uma mquina servidora. Pode-se fazer de duas formas: a) aumentando o nmero de clientes gradativamente, com 1, 2 e 3 clientes, utilizando mquinas diferentes para clientes; b)utilizando o resultado do prprio iperf (opo -i 1), que mostra a mdia a cada segundo, e depois gerando o grfico com outra ferramenta. Nesse caso, bastam duas mquinas com 3 janelascliente e 3 servidoras. O objetivo ver a adaptao do TCP (tcp-friendly). OBS: no esquecer que definio de banda s faz sentido com o UDP. No TCP, no se deve utilizar flags de controle de taxa, pois o controle feito em nvel 4. Para fazer este item utilizamos a ferramenta grfica jperf e optamos pela alternativa b, com apenas 2 maquinas conectadas, rodando 3 servidores em uma e 3 clientes na outra. Embora o jperf seja uma interface grfica, ele mostra qual a linha de comando utilizada para executar o iperf. Isso pode ser visto na figura abaixo, assim como o uso da banda, que ficou em torno de 80Mbps.

Figura 24 - Cliente 1 sozinho.

Ao iniciar o segundo processo, podemos ver na figura abaixo que a banda utilizada pelo primeiro processo caiu para algo prximo a metade da banda que ele estava utilizando.

Figura 25 - Com dois clientes.

Por fim, ao conectar o terceiro cliente, pode-se verificar na figura abaixo que a banda cai agora para um tero da banda disponvel:

Figura 26 - Com trs clientes.

Por fim, mostramos o grfico do primeiro processo do jperf que foi disparado, onde pode-se verificar o uso da rede diminuindo cada vez que um novo processo iniciado conectando-se ao mesmo servidor, mostrando a adaptao do TCP, como j foi visto no laboratrio 3:

Figura 27 - Grfico de queda do uso da banda do cliente1. 12. Utilizando a ferramenta Wireshark, obtenha a curva de variao da carga da rede local da sua mquina. Explique, sucintamente, como foi obtida e comente os resultados obtidos. Para esta tarefa considere uma estatstica de 1 a 5 minutos. Ver opo statistics+io-graph. Altere o uso da rede (atravs do iperf ou outro mtodo) e explique as variaes na rede. Gere grficos de TCP e UDP e compare os resultados. Para gerar o grfico que pode ser visto na figura abaixo, utilizamos Wireshark e selecionamos os protocolos tcp, udp, arp, ftp e http. O grfico vermelho, que o mais visvel, o do tcp e foi gerado atravs de diversas conexes diferentes para assistir vdeos e outros acessos a internet. Podem ser vistos alguns pontos pretos quase que em zero, esses pontos foram gerados atravs de conexes ftp, onde baixamos um arquivo ftp mas a conexo chegou ao limite de 200kbps, o que muito inferior as conexes do tcp, por exemplo. O grfico em verde representa a banda utilizada pelo protocolo udp. Esse grfico foi gerado utilizando a ferramenta iperf com a opo -u pelo perodo de 10 segundos. Geramos trafego arp, apagando as entradas da tabela arp e fazendo ping para as mesmas mquinas, de tal forma que ele colocou novamente a entrada na tabela. Contudo esse grfico no aparece pois o trafego na rede muito pequeno comparado as outras conexes.

Figura 28 Grfico de trafego da rede separado por protocolos