Redes Digitais 2

Engenharia Informática; Engenharia de Telecomunicações e Informática; Informática e Gestão de

Empresas
Relatório do 1º Laboratório de Avaliação ARP e DHCP 2010/2011

Licenciatura: ETI
Turma : 4
Grupo: rd2_t4-03 Data: 2010/10/15

Número do Aluno Nome do Aluno

29408 Ruben Joaquim Pestana Ruiz
27791 Fabiana Cruz Moura
28399 Tiago Filipe Lopes Tavares

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
1
2010/2011 Rev. 1.5
Índice de conteúdos:

II. ARP ............................................................................................................................................. 3

A. ENTRADAS DINÂMICAS NA TABELA ARP. ......................................................................................................3
B. ENTRADAS ESTÁTICAS NA TABELA ARP. .......................................................................................................7
III. DHCP .......................................................................................................................................... 8
A. CONFIGURAÇÃO E ARRANQUE DO SERVIDOR DHCP. ......................................................................................8
B. ARRANQUE DE UM CLIENTE DHCP. ............................................................................................................8
C. RENOVAÇÃO DE UM ENDEREÇO IP. ...........................................................................................................11
D. MÚLTIPLOS SERVIDORES DHCP NA MESMA REDE. .......................................................................................12

Índice de figuras:
ILUSTRAÇÃO 1 - RESULTADO DO COMANDO ARP -ANV EM PC3-1-V1 ............................................................................3
ILUSTRAÇÃO 2 - RESULTADO DO COMANDO ARP -ANV EM PC3-2-V1 ............................................................................3
ILUSTRAÇÃO 3 - TABELA ARP DE PC3-1-V1 APÓS EXECUÇÃO DO COMANDO ARP –D .......................................................3
ILUSTRAÇÃO 4 - TABELA ARP DE PC3-2-V1 APÓS EXECUÇÃO DO COMANDO ARP -D ........................................................3
ILUSTRAÇÃO 5 - CAPTURA DE PACOTES ARP EM PC3-1-V1 UTILIZANDO O WIRESHARK ....................................................4
ILUSTRAÇÃO 6 - CONTEÚDO DE UMA TRAMA ARP .....................................................................................................4
ILUSTRAÇÃO 7 - CONTEÚDO DE UMA TRAMA ARP: CAMPOS ORIGEM E DESTINO .............................................................4
ILUSTRAÇÃO 8 - CONTEÚDO DE UMA TRAMA ARP .....................................................................................................4
ILUSTRAÇÃO 9 - CONTEÚDO DE UMA TRAMA ARP .....................................................................................................5
ILUSTRAÇÃO 10 - DIAGRAMA SEQUENCIAL: MENSAGENS ICMP E ARP TROCADAS ENTRE PC3-1-V1 E PC3-2-V1II.A.13.A) ..6
ILUSTRAÇÃO 11 - CAPTURA DO ARRANQUE DE UM CLIENTE DHCP................................................................................8
ILUSTRAÇÃO 12 - CAMPO OPTION: DHCP MESSAGE TYPE .........................................................................................9
ILUSTRAÇÃO 13 - DIAGRAMA SEQUENCIAL: OBTENÇÃO DE UM ENDEREÇO IP NUMA REDE DHCP .....................................10
ILUSTRAÇÃO 14 - CAPTURA DA RENOVAÇÃO DE UM ENDEREÇO IP NUMA REDE DHCP ....................................................11
ILUSTRAÇÃO 15 - CAPTURA DAS MENSAGENS RECEBIDAS PELO SERVIDOR QUANDO ESTE É DESLIGADO. ...............................11
ILUSTRAÇÃO 16 - PACOTES RECEBIDOS PELO CLIENTE QUE PEDIU UM NOVO IP NUMA REDE DHCP....................................12
ILUSTRAÇÃO 17 - CAPTURA DOS PACOTES RECEBIDOS PELO CLIENTE DHCP ..................................................................12

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
2
2010/2011 Rev. 1.5
 II. ARP
A. Entradas dinâmicas na tabela ARP.

II.A.1.a)

Ilustração 1 - Resultado do comando arp -anv em PC3-1-v1

Ilustração 2 - Resultado do comando arp -anv em PC3-2-v1

Podemos observar que o comando arp –anv nos devolve a tabela ARP do host em questão na qual
constam os pares IP/Endereço Físico com os quais foram trocados dados.

II.A.2.a)

Ilustração 3 - Tabela ARP de PC3-1-v1 após execução do comando arp –d

Ilustração 4 - Tabela ARP de PC3-2-v1 após execução do comando arp -d

Relativamente ao ponto 1, podemos observar que ao executar o comando arp –d <end_ip> o que fizemos
foi desassociar os pares IP/Endereço Físico da tabela ARP, mais concretamente eliminámos os endereços
físicos da tabela.

II.A.12.a.i)
__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
3
2010/2011 Rev. 1.5
 Ilustração 5 - Captura de pacotes ARP em PC3-1-v1 utilizando o Wireshark

Inicialmente, ao fazer o comando ping para o PC3-2-V1, o host PC3-1-V1 não tem qualquer referência
dele na tabela ARP, para solucionar essa questão envia um pacote ARP em broadcast para perguntar
quem é o detentor do IP 192.168.34.21, em resposta a esse pedido o detentor desse IP, neste caso é o host
PC3-2-V1, envia seu endereço físico de rede em unicast.
O segundo par de mensagens é enviado pelo host que recebeu o ping (PC3-2-V1) para o host que
efectuou o dito comando (PC3-1-V1) a fim de confirmar que a máquina para a qual enviou a resposta em
unicast no primeiro par de mensagens seria a correcta.

II.A.12.a.ii)

Ilustração 6 - Conteúdo de uma trama ARP

Originariamente a máquina PC3-1-V1 não tinha o endereço físico do IP 192.168.34.21 na sua tabela
ARP, assim sendo, enviou um ARP request em broadcast para toda a rede (neste caso o endereço de
broadcast é ff:ff:ff:ff:ff:ff ).

Ilustração 7 - Conteúdo de uma trama ARP: Campos origem e destino

O host PC3-2-V1, ao compreender que o ARP request era dirigido a ele próprio, envia uma resposta para
o endereço físico do PC3-1-V1.

Ilustração 8 - Conteúdo de uma trama ARP

Para confirmar se a resposta que deu ao ARP request foi enviada para o endereço correcto, o PC3-2-V1
envia também um ARP request, neste caso em unicast, para o PC3-1-V1. Isto é possível porque obteve o
par IP/endereço físico no primeiro par de mensagens que trocou PC3-1-V1.

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
4
2010/2011 Rev. 1.5
 Ilustração 9 - Conteúdo de uma trama ARP

Por último, a máquina PC3-1-V1 envia a resposta ao ARP request feito por PC3-2-V1 em unicast para
PC3-2-V1. Isto é possível porque obteve o par IP/endereço físico no primeiro par de mensagens que
trocou PC3-2-V1.

II.A.12.a.iii)

Tipicamente, a distinção entre tramas ARP ou não-ARP é feita mediante um campo do cabeçalho da
trama denominado Type, neste caso o valor desse campo é ARP (0x0806).

II.A.12.a.iv)

Os pacotes ICMP são sempre encapsulados dentro de um pacote IP porque não possuem campos onde
conste o endereço de destino ou de origem.
No caso dos pacotes ARP request a situação é diferente porque possuem campos com o endereço de
origem e destino e são reconhecidos no nível de ligação de dados.

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
5
2010/2011 Rev. 1.5
II.A.12.b)

PC3-1-V1 Rede PC3-2-V1

ARP Request (Broadcast)

ARP Request (Broadcast)

ARP Reply

Ping Request (10 vezes)

Ping Reply (10 vezes)

ARP Request (Unicast)

ARP Reply

Ping Request (10 vezes)

Ping Reply (10 vezes)

Ilustração 10 - Diagrama sequencial: Mensagens ICMP e ARP trocadas entre PC3-1-v1 e PC3-2-v1
__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
6
2010/2011 Rev. 1.5
 II.A.13.a)

Na primeira captura realizada, como ambos os hosts não têm qualquer tipo de informação na sua tabela
ARP relativamente ao endereço físico da outra máquina, foram necessários dois pares de mensagem para
que o mac adress de PC3-1-V1 constasse na tabela ARP de PC3-2-V2 e vice-versa.

No que diz respeito à segunda captura apenas temos um par de mensagens, ao efectuar o ping de PC3-1-
V1 para PC3-2-V1 o primeiro host já tem um par IP/endereço físico na sua tabela ARP que diz respeito a
PC3-2-V1 logo pode efectuar o ping sem ter que enviar qualquer tipo de mensagem arp. No segundo host,
fazer o ping reply é uma história diferente, uma vez que apagámos explícitamente o par IP/endereço físico
de PC3-1-V1 presente na tabela ARP de PC3-2-V2, assim sendo este host terá que, novamente, fazer o
ARP request em broadcast e receber a consequente resposta.

II.A.14.a)

A entrada criada dinamicamente devido ao comando ping –c 1 192.168.34.201, resultante de uma ligação
ARP bem sucedida, já não consta na tabela ARP porque as entradas dinâmicas guardadas em cache são
apagadas após um determinado período de tempo.

II.A.14.b)

Verificámos que agora já não temos qualquer IP associado a um endereço MAC “<incomplete>”, como
sucedeu quando eliminamos explicitamente a entrada da tabela ARP.

B. Entradas estáticas na tabela ARP.

II.B.9.a)

Na primeira captura, criámos estaticamente na tabela ARP do PC3-2-V1 o par IP/endereço físico
correspondente ao host PC3-1-V1. Assim sendo, a sessão telnet foi correctamente estabelecida desde o
PC3-2-V1 para o PC3-1-V1.

Na segunda captura, a entrada correspondente ao PC3-1-V1 foi modificada de maneira a ter um endereço
físico associado que não é o correspondente ao real, como tal não foi possível estabelecer a sessão telnet
após várias tentativas.

C. Endereços IP duplicados.

II.C.8.a)

Ao fazer o ping request é feito um broadcast para a toda a rede com o intuito de obter o endereço físico da
máquina a quem esse comando se destina, ambas as máquinas com IP duplicado respondem com um ARP
reply mas o endereço físico que prevalece é o da máquina que responde primeiro. A partir desse
momento, todos os requests são feitos para esse mac adress.

II.C.8.b)

O motivo pelo qual nunca houve uma situação de erro deve-se ao facto de que sempre irá existir na tabela
ARP uma entrada correspondente ao IP ao qual estamos a fazer o ping request, ainda que o mac adress da
entrada em questão possa variar o comando será sempre executado sem nenhum tipo de erro. Apenas
ocorreria algum erro se não houvesse um endereço físico associado ao terminal em questão.
__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
7
2010/2011 Rev. 1.5
 III. DHCP
A. Configuração e arranque do servidor DHCP.

Escolhemos para o servidor DHCP o endereço IP 192.168.34.251 que não se encontra dentro da gama de
IPs atribuíveis pelo servidor.

B. Arranque de um cliente DHCP.

III.B.6.a)

Ilustração 11 - Captura do arranque de um cliente DHCP

O protocolo DHCP funciona ao nível de aplicação do modelo OSI, dado que apenas as camadas
superiores conseguem recorrer às camadas inferiores e como este protocolo usa UDP como transporte que
posteriormente é passado para o nível de rede para o protocolo IP, é necessário que o DHCP esteja num
nível superior ao da camada de transporte.

III.B.6.b)

O endereço atribuído ao cliente DHCP foi: 192.168.34.21 que se encontra na rede: 192.168.34.0 e que
tem a seguinte máscara de rede: 255.255.255.0.

III.B.6.c)

Observamos uma mensagem do protocolo ICMP após o cliente efectuar o DHCP Discover. Esta
mensagem é do tipo Echo (ping) e é enviada para o endereço IP que o servidor irá fornecer ao cliente. Isto
é feito porque o servidor precisa de saber se esse IP está a ser usado ou não. Quanto a mensagens do
protocolo ARP encontramos algumas. A primeira que encontrámos apresenta-se logo a seguir ao servidor
ter respondido ao cliente com a mensagem DHCP ACK e tem como origem o servidor e alvo o cliente,
onde é perguntado qual o MAC ao cliente. Posteriormente o cliente responde com o seu MAC. Estas
mensagens são trocadas com o objectivo de actualizar as tabelas ARP do servidor.

III.B.6.d)
__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
8
2010/2011 Rev. 1.5
O que permite distinguir os diferentes tipos de mensagem DHCP é o campo option : DHCP Message
Type, que se pode observar no Wireshark, dentro do BOOTP Protocol, como podemos observar através
da figura 2.

Ilustração 12 - Campo Option: DHCP Message Type

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
9
2010/2011 Rev. 1.5
III.B.6.e)

Servidor DHCP Cliente DHCP

IP: 192.168.34.0251 IP: 192.168.34.21
MAC: 00:50:56:00:34:11 MAC: 00:50:56:00:34:21

PC3-1-V1 Rede PC3-2-V2

DHCP Discover From 0.0.0.0 To 255.255.255.255

DHCP Discover From 0.0.0.0 To 255.255.255.255

Echo (Ping) Request to 192.168.34.21 ICMP Protocol

DHCP Offer (yiaddrr: 192.168.34.21)

DHCP Request From 0.0.0.0 To 255.255.255.255

DHCP Request From 0.0.0.0 To 255.255.255.255

DHCP ACK (yiaddrr: 192.168.34.21)

Who has 192.168.34.21? Tell 192.168.34.251 (ARP Protocol)

192.168.34.21 is at 00:50:56:00:34:21 (ARP Protocol)

Após aproximadamente 45% do Lease

DHCP Request()

DHCP Acknowledge

Ilustração 13 - Diagrama sequencial: Obtenção de um endereço IP numa rede DHCP

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
10
2010/2011 Rev. 1.5
III.B.6.f)

Embora a máquina não tenha IP inicialmente, como neste caso pertence fisicamente à rede por isso é
possível esta enviar uma mensagem em broadcast com o pedido de IP, através do DHCP Discover. Para
receber pacotes, se estiver dentro da mesma sub-rede basta que o servidor envie uma mensagem do tipo
DHCP Offer em unicast, sabendo apenas o MAC address da máquina.

C. Renovação de um endereço IP.

III.C.4.a.i)

Ilustração 14 - Captura da renovação de um endereço IP numa rede DHCP

Nos dois cenários (figura 1 e 3) são trocadas dois tipos de mensagens idênticas: o DHCP Request e o
DHCP ACK. Mas podemos observar que as mensagens DHCP Discover e DHCP Offer são apenas
trocadas na primeira vez que o cliente arranca e pede um novo IP ao servidor, dado que não tinha nenhum
IP nem conhecia nenhum servidor DHCP. Depois do cliente estar ligado ao servidor são apenas trocadas
mensagens de Request e ACK de x em x tempo (tempo de lease).

III.C.4.a.ii)

Após o cliente estar ligado ao servidor e obter um IP, este irá enviar para o servidor mensagens do tipo
DHCP Request directamente para o servidor, ou seja, em unicast e não em broadcast como é feito quando
obtém o IP pela primeira vez. Após receber um IP, o cliente irá sempre tentar renovar aquele mesmo
endereço e não outro qualquer.

III.C.4.b)

O tempo de lease que configuramos foi de 100s e observamos que o cliente renova o IP por volta dos 45s,
o que equivale a 45% do tempo de lease.

III.C.9.a)

Ilustração 15 - Captura das mensagens recebidas pelo servidor quando este é desligado.

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
11
2010/2011 Rev. 1.5
Ao desligarmos o servidor DHCP a que o cliente está ligado, o cliente enviará vários DHCP Request para
o servidor, aos quais não irá obter resposta (DHCP ACK), por isso irá continuar a enviar DHCP Request
(neste caso 4) até esgotar o tempo de lease.

III.C.9.b)

Percentualmente, o cliente envia DHCP Requests aos 32%, outro aos 36%, aos 48% e aos 72% do tempo
de lease. Após estas tentativas, o tempo de lease esgota e o cliente perde o IP.

D. Múltiplos servidores DHCP na mesma rede.

Para o novo servidor DHCP atribuímos o endereço 172.16.0.190 que se encontra na rede 172.16.0.128
com máscara de rede 255.255.255.192 e broadcast 172.16.0.191. A gama de endereços atribuíveis pelo
servidor que configurámos é: 172.16.129 até 172.16.180.

III.D.1)

Ao configurar um novo servidor numa nova máquina virtual tivemos que alterar o MAC de modo a não
existirem duas máquinas com o mesmo MAC. O novo MAC que escolhemos foi: 00:50:56:00:34:24.

III.D.2)

O IP que o cliente recebeu foi o 172.16.0.180. Podemos observar através da figura 16 que o primeiro
servidor a enviar a oferta de IP foi o 172.16.0.190 e foi esse IP que o cliente escolheu. Na figura 17
podemos ver que o servidor 192.168.34.251 enviou uma oferta depois do outro servidor e o cliente
descartou essa oferta.

Ilustração 16 - Pacotes recebidos pelo cliente que pediu um novo IP numa rede DHCP

Ilustração 17 - Captura dos pacotes recebidos pelo cliente DHCP

III.D.3)

Ao desligar o servidor DHCP a que o cliente está ligado, após esgotar o tempo de lease o cliente perde o
IP e envia um DHCP Discover para a rede. O outro servidor responde com um DHCP Offer e o cliente
liga-se a esta nova rede, obtendo o IP 192.168.34.21. Voltando a ligar o antigo servidor nada acontece,
pois não irá existir comunicação entre o servidor antigo e o cliente.

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
12
2010/2011 Rev. 1.5
III.D.4)

Estando na rede 192.168.34.0 não conseguimos pingar nem para a rede 172.16.0.128 nem para outra
qualquer, uma vez que não temos uma gateway definida para encaminhamento de pacotes para o exterior.

III.D.5)

O número mínimo de IP's que são necessários para esta questão é 256 + 256 + 128, e as redes criadas
seriam as seguintes:

 A - 192.168.34.0 /24
 C - 192.168.35.0 /24
 B - 192.168.36.0 /25

__________________________________________________________________________
1º Semestre Relatório do 1º Guião Laboratorial de Avaliação: ARP e DHCP
13
2010/2011 Rev. 1.5