–UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMÁTICA

DEPARTAMENTO DE INFORMÁTICA APLICADA INF01154 – Redes de Computadores N - Turma D

Laboratório 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 requisições de echo, tamanho do pacote de 200 bytes, TTL de

80. Mostre o comando utilizado e prove que funcionou através 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 forçando a não fragmentação do pacote (-f) e tamanho do pacote de

1600 bytes.

Verificar qual o máximo tamanho do pacote que funciona. Explique.

Com um pacote de 1600bytes não foi possível, como pode-se ver na imagem abaixo.

Figura 02 - Comando ping forçando a não fragmentação.

O tamanho máximo do pacote não fragmentado foi de 1472 bytes. O tamanho máximo

de dados de um pacote Ethernet é 1500 bytes. Porém, os primeiros 20 bytes são o

cabeçalho 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 fragmentação.

c. Qual a mensagem (pacote de dados) enviados num comando de ping?

Sugestão: analise o pacote ICMP.

Figura 04 - Comando ping, dados.

É mandado uma sequência 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 máquina para um vizinho, preencha na tabela linha a linha a sequência de

comandos de um ping, explicando cada linha (mostrando o endereço nível 2 e nível 3

envolvido em cada linha). Também deve ser considerado o protocolo ARP, além do

ICMP. Pode-se utilizar a simbologia MAC_A (MAC da máquina A), MAC_B

(MAC da máquina B) e MAC-R (MAC do roteador), por exemplo. Da mesma forma,

pode-se utilizar IP_A, IP_B, etc. Quando não existir pacotes no nível, basta colocar

“Não tem” na tabela.

Protocolo End. Nível 2 End. Nível 3 Descrição

Ex: arq request Ex: Mac_x -> … blá

Ex: icmp request Ex: Mac_x -> Mac_y Ex: IPx->IPy

Protocolo

End.

Nível 2

End.

Nível 3

Descrição

ARP Request MAC_A -> Broadcast Não tem MAC_A pergunta em

Broadcast MAC_B

ARP Reply MAC_B -> MAC_B Não tem

Retorna o end. físico

do Ip solicitado

anteriormente

ICMP Request MAC_A -> MAC_B IP_A -> IP_B MAC_A envia ping

para MAC_B

ICMP Reply MAC_B -> MAC_A IP_B -> IP_A MAC_B responde

ping para MAC_A

Tabela 01 - Funcionamento do ping nas camadas.

3. Repetir a tabela acima, porém fazendo ping para uma subrede diferente. Qual a

principal diferença?

Protocolo

End.

Nível 2

End.

Nível 3

Descrição

ARP Request MAC_A -> Broadcast Não tem

MAC_A solicita end.

IP do roteador (default

gateway).

ARP Reply MAC_R -> MAC_A Não tem Retorna o endereço

físico do roteador.

DNS Request Não tem IP_A ->

DNS_UFRGS

Requisita a resolução

do endereço.

DNS Reply Não tem DNS_UFRGS ->

IP_A

Retorna o IP do end.

requisitado.

ICMP Request MAC_A -> MAC_R IP_A -> IP_R MAC_A envia ping

para MAC_R

ICMP Reply MAC_R -> MAC_A IP_R -> IP_A MAC_R responde

ping para MAC_A

ARP Request MAC_R -> MAC_A Não tem

MAC_R que saber

quem possui o end. IP

10.67.105.7

ARP Reply MAC_A -> MAC_R Não tem

MAC_A responde que

é ele (retornando seu

end. MAC)

Tabela 02 - Funcionamento do ping nas camadas.

Onde MAC_R é o MAC do roteador (gateway) e IP_R é o IP do roteador. A principal

diferença é que toda a comunicação acontece através do roteador. O MAC_A envia seus

dados para o roteador, que envia para o MAC_B. Assim como a resposta de MAC_B

também é enviada para o roteador (que responde ao MAC_A). As duas máquinas não

sabem a localização 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 cabeçalho.

Para isso, pode-se olhar na especificação do protocolo (buscar na RFC) ou analisar no

sniffer, pois o mesmo provê todos os campos do protocolo. Explique o motivo do ARP

request não conter o endereço MAC do destino (campo zerado), e o motivo que o ARP

reply contém todos os campos preenchidos.

Figura 05 - Cabeçalho do Protocolo ARP.

O protocolo ARP é utilizado para que o transmissor descubra o endereço físico do

receptor através de seu IP. Para isso o receptor envia uma mensagem com o endereço de

broadcast no campo TARGET HA. Ele envia seu endereço físico (MAC) no campo

SENDER HA, o seu endereço IP no campo SENDER IP e o endereço IP alvo no campo

TARGET IP. A máquina que possui o IP alvo do campo TARGET IP responde a

mensagem informando o seu endereço físico no campo SENDER HA e atualiza os

campos TARGET HA com o endereço físico da máquina que o procurava, o TARGET

IP com o IP da máquina que o procurava, e o SENDER IP com o seu endereço IP. A

partir de então o transmissor conhece o endereço físico 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 máquina. Dica: utilizar "arp /?" e "arp -a". Quanto tempo

dura essa informação?.

Isso acontece pois, na primeira vez que é feito m ping para uma maquina, o endereço

MAC do destino é colocado na tabela ARP, que pode ser vista utilizando o comando

“arp -a”. O tempo que essa informação dura depende da implementação que foi feita.

Na implementação feita pela Microsoft essa informação é criada com um tempo

estipulado de10 minutos mas, se ela não for utilizada, ela é apagada em dois minutos.

5. SOBRE O TRACEROUTE

a. Utilizar o traceroute (ou tracert) para descobrir o número de hops e os roteadores

por onde os pacotes estão 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, é possível ver a rota da UFRGS até destino, passando

pelo pop-rs, pela rede rnp, chegando nos roteadores do Japão, até o destino, como pode

ser visto na imagem abaixo.

Figura 07 - Rota da INF até o Japão.

b. Para que serve o traceroute? Qual sua relação com o TTL? Para que serve o TTL?

Serve para rastrear a rota de um pacote através da rede. Seu funcionamento esta

diretamente relacionado com o TTL do pacote. Para descobrir a rota Ele envia um

pacote ICMP com TTL incremental, começando em 1 até atingir a máquina 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 transmissão com câmera (não é com captura de tela).

Disparar o “xnote stopwatch” (ou equivalente) na máquina A. A máquina A filma (com

a webcam) a tela da máquina A, transmitindo essa imagem para a máquina B. A

máquina B filma a tela. Na máquina A é recebida a imagem transmitida, do seu próprio

cronômetro. Captura-se a tela e obtém-se o atraso.

Figura 08 - Captura de tela usando o Polycom Telepresence m100.

O atraso, como pode ser visto na imagem acima, é de 29 centésimos de segundo,

considerando o atraso de envio e de recebimento.

7. Instalar o sniffer de redes Wireshark e fazer uma comunicação em duplas via PVX.

Sugestão: usar

filtros: ip.src==… ou RTCP ou RTP ou …

a. Identificar cabeçalhos RTP e RTCP (mostrar uma imagem com RTP e outra com

RTCP no wireshark). Qual a diferença de direção e quantidade de pacotes de cada um?

RTP são mensagens para transmissão de dados, enquanto RTCP funciona como

mensagens de controle. Ao longo de uma sessão de videoconferência, são enviadas

poucas mensagens do tipo RTCP (no nosso print de exemplo não há nenhuma),

enquanto que há muita troca de dados (pacotes RTP) para que a videoconferência seja

possível, conforme mostra as figuras 10 e 11 para vídeo, e figura 9 para áudio.

Figura 09 - Pacote de Áudio.

Figura 10 - Pacote de vídeo, parte 1 com 934 bytes.

Figura 11 - Pacote de Vídeo, parte 02, com 534 bytes.

b. Para o RTP, identificar e justificar os campos “versão”, “Payload Type”,

“Sequence Number”, “timestamp”.

Versão - indica a versão do protocolo RTP usado. Nesse caso, a versão é a

correspondente ao RFC 1889.

Payload Type - identifica o tipo de dados contidos no Payload (áudio, vídeo, imagem,

texto, HTML, etc.).

Sequence Number - serve para ordenar os pacotes de uma comunicação, sendo que o

primeiro pacote recebe um número sequencial aleatório e os seguintes recebem o

número sequencial do pacote anterior incrementado de um. Pode ser útil também para

detectar perda de pacotes intermediários.

timestamp: indica o momento em que o primeiro byte do pacote RTP foi gerado.

c. Descobrir quais pacotes são de áudio e quais são de vídeo. Justificar, utilizando

como base a diferença 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 conclusão de que os pacotes com RTP Type-126

são de vídeo e os com RTP Type-127 são de áudio. Isso pode ser observado através dos

timestamps dos pacotes, por exemplo.

Para vídeo, existem vários pacotes com o mesmo timestamp. Já para áudio, apenas um

pacote para cada timestamp. Como os pacotes de vídeo são normalmente maiores, é

necessário que o pacote seja fragmentado.

Os pacotes de áudio, além 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 codificação de áudio utilizada e características do laboratório, calcule:

a. Tempo médio de inserção

O pacote de áudio tem 294 bytes e a banda no laboratório é de 100Mbps (12,5MBps),

logo:

b. Atraso no meio físico, supondo 40m a distância entre sua máquina e o switch do INF.

A distância de ida e volta equivale a 80m e a velocidade de transmissão no par trançado

equivale a

logo:

9. Obtenha um histograma do valor médio do tamanho dos pacotes que trafegaram pela

rede durante o período considerado. Ver opção “statistics+packet lengths”. Faça a

análise duas vezes:

a) iniciando a captura e navegando na web (perfil navegação web);

Figura 12 - Navegação em site.

b) iniciando a captura e fazendo um download de arquivo de tamanho razoavelmente

grande (acima de 10 Mbytes). Compare os resultados em relação ao tamanho do

pacote. Explique.

Figura 13 - Realização de download. Através dos relatórios gerados no Wireshark, para uma navegação normal e para um

download, é perceptível que na navegação 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/médio. A maioria dos pacotes (66,27%) tem tamanho grande (1280-

2559).

10. Faça uma análise completa de um quadro MAC que contenha encapsulado um

pacote IP e TCP (sugestão: faça um download qualquer). Liste todos os valores dos

diversos campos encontrados no cabeçalho do quadro MAC e nos cabeçalhos do

pacote IP e do segmento TCP encapsulado. Explique os valores encontrados e suas

unidades quando for o caso.

Começamos pelo quadro Ethernet, podemos ver na imagem abaixo, os campos de fonte

e destino MAC.

Figura 14 - Endereço MAC destino.

No destino, está o endereço MAC do roteador.

Figura 15 - Endereço MAC fonte.

Com o terminal aberto ao lado é possível perceber que os valores estão 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 prática, como pode ser visto na imagem abaixo:

Figura 17 - Cabeçalho do Protocolo Ethernet 802.1.

Passando para o quadro IP, analisando o seu cabeçalho vemos as seguintes informações:

Versão do IP, tamanho do cabeçalho, prioridade(Differentiated services Field), tamanho

total do payload, identificação, flags, offset fragmento, TTL, protocolo usado, Cheksum

do cabeçalho, origem e destino. Cada um desses campos será explicado detalhadamente.

Figura 18 - Cabeçalho do Protocolo IP sniffado.

Agora vamos relacionar o que vimos sniffando a rede com a teoria. Usaremos a figura

19 abaixo como base.

A versão do Protocolo IP corresponde ao IPv4, como estudado na teoria (pode ser visto

na imagem abaixo), o tamanho do cabeçalho é 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á três

bits de flags, que são usados para controle e/ou identificação dos fragmentos. Em

Fragment Offset indica que não houve fragmentação. 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

detecção 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 - Cabeçalho do protocolo IP teórico.

Passando para o segmento TCP, analisando as informações sniffadas, temos:

Porta da fonte, porta de destino, stream, número de sequencia, next byte, ack, tamanho

do cabeçalho, Flags, tamanho da janela (inclui o calculo da janela é o fator escalável),

Checksum e SEQ/ACK (onde encontram-se informações sobre o tempo de RTT para o

ack e número do segmento Ack).

Figura 20 - Cabeçalho do protocolo TCP sniffado.

Finalizando com o segmento TCP, vamos relacionar o seu cabeçalho com a parte

teórica, é importante notar que alguns campos vistos com o wireshark no sniffamento da

rede não são mencionados nos cabeçalhos 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 número 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 cabeçalho, 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

detecção de erro. O campo Urgent Pointer não foi possível visualizar no wireshark,

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

opcionais

Figura 21 - Cabeçalho do protocolo TCP teórico.

11. Utilizar o software Iperf (iperf –h para help), que deve ser disparado em duas

máquinas, 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 máxima de 10Mbit/s, tamanho de pacote 1400 bytes).

No relatório devem constar o resultado dos três seguintes objetivos:

a. Mostrar linhas de comando utilizadas e gerar gráfico udp para 3 bandas diferentes

(ex: 1Mbit/s, 10Mbit/s e 30Mbit/s). Mostrar e explicar o gráfico gerado.

Figura 22 - Comandos utilizados para geração 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 parâmetro “–b” para 1, 10 e por fim 30, como

foi solicitado no exercício. 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 - Gráfico da geração de trafego UDP.

No gráfico acima podemos ver a utilização da rede para cada comando udp rodado.

Iniciamos rodando com 1 Mbps, teve um espaço de tempo até iniciar o próximo

comando que utilizou a banda de rede de 10Mbps e então o ultimo comando executado

para gerar um trafego de 30 Mbps. Pode-se perceber um pico no gráfico enquanto

utilizava-se 10mbps na rede, o que provavelmente aconteceu por algum outro processo

ter disparado durante a execução do comando.

b. Mostrar linhas de comando utilizadas e gerar gráfico TCP da estação incrementando

o número de conexões para uma máquina servidora. Pode-se fazer de duas formas: a)

aumentando o número de clientes gradativamente, com 1, 2 e 3 clientes, utilizando

máquinas diferentes para clientes; b)utilizando o resultado do próprio iperf (opção “-i

1”), que mostra a média a cada segundo, e depois gerando o gráfico com outra

ferramenta. Nesse caso, bastam duas máquinas com 3 janelascliente e 3 servidoras. O

objetivo é ver a adaptação do TCP (tcp-friendly).

OBS: não esquecer que definição de banda só faz sentido com o UDP. No TCP, não se

deve utilizar flags de controle de taxa, pois o controle é feito em nível 4.

Para fazer este item utilizamos a ferramenta gráfica 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 gráfica, 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 próximo 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 terço da banda disponível:

Figura 26 - Com três clientes.

Por fim, mostramos o gráfico 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 adaptação do TCP, como já foi visto no

laboratório 3:

Figura 27 - Gráfico de queda do uso da banda do cliente1.

12. Utilizando a ferramenta Wireshark, obtenha a curva de variação da carga da rede

local da sua máquina.

Explique, sucintamente, como foi obtida e comente os resultados obtidos. Para esta

tarefa considere uma estatística de 1 a 5 minutos. Ver opção “statistics+io-graph”.

Altere o uso da rede (através do iperf ou outro método) e explique as variações na rede.

Gere gráficos de TCP e UDP e compare os resultados.

Para gerar o gráfico que pode ser visto na figura abaixo, utilizamos Wireshark e

selecionamos os protocolos tcp, udp, arp, ftp e http. O gráfico vermelho, que é o mais

visível, é o do tcp e foi gerado através de diversas conexões diferentes para assistir

vídeos e outros acessos a internet. Podem ser vistos alguns pontos pretos quase que em

zero, esses pontos foram gerados através de conexões ftp, onde baixamos um arquivo

ftp mas a conexão chegou ao limite de 200kbps, o que é muito inferior as conexões do

tcp, por exemplo. O gráfico em verde representa a banda utilizada pelo protocolo udp.

Esse gráfico foi gerado utilizando a ferramenta iperf com a opção “-u” pelo período de

10 segundos. Geramos trafego arp, apagando as entradas da tabela arp e fazendo ping

para as mesmas máquinas, de tal forma que ele colocou novamente a entrada na tabela.

Contudo esse gráfico não aparece pois o trafego na rede é muito pequeno comparado as

outras conexões.

Figura 28 – Gráfico de trafego da rede separado por protocolos