–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.
Top Related