Rede de Computadores

Transcrição

1 Rede de Computadores Relatório Final Mestrado em Engenharia Informática e Computação EIC0032 Redes de Computadores Grupo: Antonieta Oliveira ei07157 Ricardo Amorim ei08103

2 Introdução Numa fase inicial, desenvolveu-se um cliente FTP simples cujo objetivo seria implementar as diversas fases de negociação bem como a transferência de um arquivo alojado no servidor. Esta aplicação, desenvolvida na linguagem C, faz uso das diversas potencialidades do protocolo referido e do conceito de sockets no ambiente UNIX. Já numa segunda fase foi feita a configuração de uma rede local de computadores e o respetivo estudo e interpretação dos conceitos envolvidos. No final foi utilizada a aplicação desenvolvida na primeira fase para transferir um arquivo que se encontrava num servidor FTP através da rede configurada na segunda fase. Sumário O relatório constitui uma análise detalhada da implementação feita, bem como dos resultados obtidos ao longo das experiências feitas. Inicialmente será feita uma descrição da fase de desenvolvimento da aplicação de download, posteriormente abordar-se-ão as várias experiências da segunda fase do projeto e a respetiva análise dos resultados obtidos, incluindo a parte respeitante à utilização da aplicação na rede configurada e no final concluir-se-á acerca dos conceitos envolvidos em todo o projeto bem como a sua importância. Ao longo da análise serão apresentados os comandos mais importantes utilizados na configuração da rede. 2

3 Parte 1 Aplicação de download A aplicação foi desenvolvida em linguagem C e num único ficheiro, download.c, destinando-se a implementar uma versão simplificada do protocolo FTP. Esta implementação inclui as fases de negociação com o servidor, como por exemplo a autenticação opcional, a criação dos sockets de controlo e de dados e posterior transferência do ficheiro especificado. A sintaxe de chamada da aplicação segue o especificado na norma RFC1738: ftp://<username>:<password>@<host>/<url-path> Um exemplo da utilização desta sintaxe, que foi utilizado nos testes durante o desenvolvimento é ftp://ftp.up.pt/pub/robots.txt. Após a verificação do número de argumentos recebidos, é feita a separação do URL recebido nos diferentes componentes: nome de utilizador, respetiva password, host, e caminho para o ficheiro. Esta separação foi feita com recurso à função sscanf da linguagem C juntamente com uma expressão regular, o que permite a rejeição em caso de falta de argumentos ou da sua especificação estar errada. Depois da operação do parser, a fase de ligação ao servidor faz uso de um socket, representando o canal de controlo, que é aberto através da porta do servidor destinada ao protocolo FTP (porta 21). Para esta ligação são utilizadas as funcionalidades do serviço DNS, para converter o nome do servidor para o seu endereço IP. Após a abertura do canal de controlo, é feita a autenticação com os dados obtidos a partir do URL. Esta autenticação tem em conta a resposta do servidor, nomeadamente a aceitação ou rejeição do nome de utilizador ou da password fornecidos sendo que no caso de rejeição a aplicação termina. Depois da autenticação estar garantida é feito um pedido ao servidor para a transferência de um arquivo no modo passivo. Este modo aplica-se para situações em que, por exemplo o cliente se encontra protegido por uma firewall e portanto incapaz de aceitar ligações TCP (o que acontece no modo ativo). Desta forma o cliente fica responsável por abrir o canal de dados para a ligação TCP com o mesmo IP utilizado para o canal de controlo, mas com a porta calculada com base na resposta do servidor ao comando pasv. O número da porta é obtido com 256*MSB+LSB e é então aberto o socket para a transferência de dados. 3

4 Por fim, é enviado o pedido para transferência do ficheiro através do comando retr ao que o servidor responde com o início da transmissão sobre o canal de dados. Após esta transferência são fechados os dois canais (sockets) bem como o ficheiro aberto e a aplicação termina a execução. Na figura 1 apresenta-se o exemplo de uma transferência do ficheiro japanese.xml alojado num servidor ftp com nome de utilizador e password test, juntamente com as respetivas respostas do servidor no decorrer do processo. FTP. O código fonte desenvolvido pode ser consultado em código fonte do cliente Parte 2 Configuração e análise da rede no laboratório 2.1 Configurar rede IP Inicialmente foi desligado o cabo que liga o switch ao router laboratorial (resultando na perda do acesso à internet dos terminais). De seguida, configuraram-se o tux1 e tux4 com os endereços necessários para garantir a comunicação entre eles. Depois da eliminação da tabela ARP, que constitui um meio de facilitar o reconhecimento dos endereços mac associados aos endereços IP, utilizou-se o comando ping para testar a conectividade. O não reconhecimento do endereço fornecido faz com que sejam enviados pacotes ARP para obter o endereço físico do recetor. O cliente envia um pacote ARP para o endereço de broadcast que reencaminha o pacote para todos os terminais. Posteriormente, o terminal que tiver o endereço IP contido no pacote enviado irá responder com o seu endereço físico. Para uma melhor eficiência, este endereço é temporariamente guardado na tabela ARP, que armazena correspondências do tipo ARP-IP, evitando assim novos pedidos posteriores durante esse tempo. O registo 2.a evidencia o comportamento do protocolo. O comando ping gera pacotes ICMP com mensagens de pedido e resposta echo request e echo reply - que contêm os endereços de origem e destino. Cada pacote ethernet transmitido é diferenciado com base no seu cabeçalho: no caso de ser um pacote IP, o seu cabeçalho terá o valor 0x0800; por outro lado se se tratar de um pacote ARP, o cabeçalho será igual a 0x

5 2.2 Virtual LAN Na segunda parte configuraram-se duas Virtual Lans e atribuíram-se as respetivas interfaces, garantido a conformidade com o especificado tux 1 e 4 pertencentes à primeira, e tux 2 pertencente à segunda. Em primeiro lugar foram criadas as duas vlans no switch e adicionados os tuxs, sendo que para isso foi necessário configurar o tux2. Os comandos apresentam-se nas tabelas 3.b.i e 3.b.ii. Após nova utilização do comando ping verificou-se que existia conectividade entre os TUXs 1 e 4, mas nenhum destes podia comunicar com o tux2. Isto acontece devido ao facto de estarem em redes distintas (e como tal o resultado de um pacote enviado será Destination Unreachable ). Por outro lado fez-se também o teste em relação aos endereços de broadcast (ping b [...]) e constatou-se que também se encontram em broadcasts distintos, pelo que se conclui que há um endereço de broadcast para cada vlan. 2.3 Configuração de um router em Linux Neste passo, transformámos o tux4 num router, de forma a permitir a comunicação entre o tux1 e o tux2. Para isso foram utilizados os comandos conforme as tabelas 3.c.i e 3.c.ii. Esta configuração faz com que cada interface do tux4 esteja ligada a uma vlan, e que este possa funcionar como router, reencaminhando os pacotes recebidos. De seguida foi necessário reconfigurar os tuxs 1 e 2 com os comandos da tabela 3.c.iii, de modo a garantir a sua comunicação. Por fim, a comunicação entre os dois TUXs, 1 e 2, já é possível. As rotas disponíveis em cada tux garantem que os pacotes transitam entre as duas sub-redes, passando pelo tux4. Observou-se também a troca de pacotes ARP para o reconhecimento do tux2, uma vez que a tabela ARP dos tuxs 1 e 4 ainda não tinha uma entrada com o seu endereço. 2.4 Configurar Router commercial e implementar NAT Nesta parte, foi adicionado à rede um router comercial com o intuito de fornecer acesso a uma rede externa aos tuxs anteriormente configurados. 5

6 A configuração do router passa por atribuir as interfaces para a rede configurada respeitando as ligações feitas entre o router e o switch, e adicionar as rotas para garantir a comunicação de todos os TUXs. A configuração utilizada pode ser consultada na 3.d.i. Como se pode observar nesta tabela, as rotas estáticas são adicionadas segundo o comando ip route <ip_destino> <máscara> <gateway>. De seguida, o router foi definido como default gateway do quer do tux4 (interface eth1) quer do tux2. Para mostrar a existência de comunicação foi feito ping a partir do tux1 para as interfaces do tux4 e do router. Com esta configuração, os pacotes transitam do tux1 para o tux4 e to tux4 para o router ou para o tux2, conforme o seu endereço de destino. Neste ponto da experiência as tentativas de contacto com a rede exterior não recebem resposta. Esta situação deve-se ao facto de os terminais exteriores não terem forma de saber qual o endereço para onde devem responder dado que todos os TUXs são vistos como tendo o mesmo endereço. Esta situação resolve-se recorrendo à funcionalidade NAT do router comercial da bancada. Com esta funcionalidade, os endereços da rede são mapeados para endereços públicos, e a resposta já é concretizável. Mais uma vez, a configuração feita pode ser consultada na tabela 3.d.ii. Nesta configuração optou-se por incluir o tux4 no conjunto de endereços a mapear, garantindo assim a sua comunicação com o exterior. A configuração feitaa até agora é apresentada na imagem seguinte: 2.5 DNS Com o objetivo de se poder utilizar diretamente o hostname em vez do seu endereço IP, foi implementada a funcionalidade DNS. Desta vez, a configuração passou por editar o ficheiro resolv.conf de cada TUX (localizado em /etc/resolv.conf) e mudar o seu conteúdo para: 6

7 Search netlab.fe.up.pt Nameserver Com esta configuração foi então possível fazer, por exemplo, ping e obter resposta do servidor. Este pedido subdivide-se em duas fases: inicialmente, o tux pergunta ao servidor DNS ( ) qual o IP que corresponde ao endereço fornecido. O servidor responde com vários endereços IP, dos quais é escolhido o primeiro para o envio dos pacotes ICMP. 2.6 Protocolo FTP No teste da aplicação desenvolvida anteriormente foi feita uma transferência de um ficheiro com um cerca de 600MB a partir do servidor ftp da Universidade do Porto. Uma vez que a rede da universidade é bastante complexa, o comportamento observado afastou-se ligeiramente da situação ideal, em que haveria um pico de velocidade inicial, vindo a estabilizar posteriormente. Na situação real, o gráfico apresenta uma forma mais irregular, evidenciando os diversos fatores que influenciam a velocidade de transferência de um ficheiro: Fig. 1 Transferência de um único TUX Na situação seguinte, o cliente ftp foi executado em dois dos Tuxs (1 e 2), de modo a observar a gestão de tráfego feita. Nesta situação é possível observar um decréscimo da velocidade no tux1 quando o tux2 inicia a transferência. De igual modo, o pico de velocidade atingido no tux2 é menor do que aquele atingido inicialmente no tux1. Estes factos demonstram a execução da política de gestão de congestionamento de tráfego que é feita pelos intervenientes no processo. A figura seguinte evidencia o decréscimo da velocidade de transferência no tux1, quando o tux2 inicia outra transferência mostrando um equilíbrio de pacotes que transitam na rede para cada tux: 7

8 Fig. 2 Transferência do TUX1, em simultâneo com o TUX2 A comunicação com o servidor é feita através de dois canais: o canal de controlo onde transitam todos os comandos para a obtenção do ficheiro, e o canal de dados, por onde são enviados todos os dados deste. É feito um pedido inicial ao servidor de DNS pelo endereço IP do servidor FTP sendo seguido pelo processo de transferência sobre o protocolo TCP. Conclusão Terminado o projeto foram consolidados os conhecimentos acerca das redes de computadores, bem como a sua importância para a atualidade. Por outro lado, os conceitos relacionados com os diversos protocolos envolvidos (TCP, ARP, entre outros) foram mais facilmente interiorizados graças à sua divisão em experiências laboratoriais. Foi também evidente a importância da organização das redes de computadores em sub-redes e a razão pela qual se tem dado cada vez mais importância a mecanismos de controlo de tráfego e de resolução de congestionamentos. 8

9 ANEXOS 1. Imagens de execução 2. LOGS parciais a. Protocolo ARP Source Destination Protocol Info Kye_08:d5:b3 Broadcast ARP Who has ? Tell Hewlett- Kye_08:d5:b ARP is at 00:21:5a:c7:64:8e _c7:64:8e ICMP Echo (ping) request ICMP Echo (ping) reply Log 1 funcionamento do protocolo ARP b. Comunicação do tux1 com as restantes interfaces tux1 >> ping bytes from : icmp_seq=1 ttl=64 time=0.199ms tux1>> ping bytes from : icmp_seq=1 ttl=64 time=0.190ms (TUX4.eth0) (TUX4.eth1) 9

10 tux1>> ping bytes from : icmp_seq=1 ttl=254 time=0.563ms (Router) Log 2 Comunicação do tux1 com as interfaces na rede 3. CONFIGURAÇÕES a. Exp1 i. Configurar interfaces tux1 e 4 tux1 >> ifconfig eth0 tux1>> ifconfig eth Y01/24 tux4>> ifconfig eth0 up tux4>> ifconfig eth Y0.254/24 //ativar interface eth0 //atribuir endereço IP Configuração 1 interfaces dos tuxs 1 e 4 b. Exp2 i. Interface do Tux2 tux2 >> ifconfig etho up tux2>> ifconfig eth Y1./24 //ativar interface eth0 //endereço pertence a vlan1 Configuração 2 interface do tux2 ii. Configuração do Switch >>vlan Y0 //criar virtual lan 0 >>vlan Y1 //criar virtual lan 1 >>interface fastethernet 0/1 //interface do TUX1 >>switchport access vlan Y0 //atribuir interface à vlan0 >>interface fastethernet 0/4 //interface do TUX4 >>switchport access vlan Y0 //atribuir interface à vlan0 >>interface fasethernet 0/2 //interface do TUX2 >>switchport access vlan Y1 //atribuir interface à vlan1 Configuração 3 configuração do switch 10

11 c. Exp3 i. Interface tux4.eth1 tux4 >> ifconfig eth1 up //ativar interface eth1 tux4>> ifconfig eth Y1.253 //atribuir endereço IP tux4>> echo 1 > /[...]/IP_FORWARD //ativar reencaminhamento tux4>> echo 0 > /[...]/ICMP_ECHO_IGNORE_BROADCASTS Configuração 4 interface eth1 do tux4 ii. Adicionar interface à vlan1 >>interface fasethernet 0/5 >>switchport access vlan Y1 //interface eth1 do TUX4 //atribuir interface à vlan1 Configuração 5 - Adicionar interface eth1 à vlan1 iii. Reconfiguração das interfaces tux1>> route add default gw Y0.254 tux2>>route add default gw Y1.253 //interface eth0 do TUX4 // interface eth1 do TUX4 Configuração 6 reconfigurar interfaces d. Exp4 i. Configurar router comercial >>interface gigabitethernet 0/0 //interface 0 >>ip address Y >>interface gigabitethernet 0/1 //interface 1 >>ip address Y >>ip route //rede exterior >>ip route Y //vlany0 Configuração 7 comandos para a configuração do router 11

12 ii. Configurar NAT >> interface gigabitethernet 0/0 >>no shutdown >>ip nat inside >> interface gigabitethernet 0/1 >>no shutdown >>ip nat outside >>ip nat pool ovrld prefix 24 >>ip nat inside source list 1 pool ovrld overload >>access-list 1 permit >> access-list 1 permit Configuração 8 configuração do serviço NAT no router 12

13 4. código fonte do cliente FTP 5. #include <stdio.h> 6. #include <sys/types.h> 7. #include <sys/socket.h> 8. #include <netinet/in.h> 9. #include <arpa/inet.h> 10. #include <stdlib.h> 11. #include <unistd.h> 12. #include <signal.h> 13. #include <netdb.h> 14. #include <strings.h> 15. #include <string.h> 16. #include <errno.h> 17. #include <netdb.h> #define TRUE #define FALSE #define SIZE //TAMANHO MAXIMO DA RESPOSTA DO SERV 24. #define MSG_LEN //PORTA TCP DO SERVIDOR 27. #define SERVER_PORT char SERVER_ADDR[SIZE]; //RECEBER buff DO SERVIDOR 33. int receive_cmd(int fd, char* buffer) { 34. //sleep(1); 35. memset(buffer, (char) '\0', strlen(buffer)); 36. return read(fd, buffer, MSG_LEN); 37. } //ENVIAR COMANDO PARA O SERVIDOR 41. void send_cmd(int fd, char* buffer) { 42. char tmp_cmd[size]; 43. memcpy(tmp_cmd, buffer, sizeof(char)*size); 44. printf("\n>> %s", tmp_cmd); 45. strcat(tmp_cmd, "\r\n"); 46. write(fd, tmp_cmd, sizeof(char) * strlen(tmp_cmd)); 47. } int main(int argc, char** argv){ if(argc < 2) 54. { 55. printf("usage: %s ftp://<username>:<password>@<host>/<url_path>\n", argv[0]); 56. exit(1); 57. } struct hostent *h; //LIG. CONTROLO 62. int sockfd = (int) NULL; 13

14 63. struct sockaddr_in server_addr; //LIG. DADOS 66. int sockfd2 = (int) NULL; 67. struct sockaddr_in server_addr2; char host[size]; 70. //PATH DO FICHEIRO 71. char file_path[size]; 72. //USER 73. char user_name[size]; 74. //PASSWORD 75. char pw[size]; 76. //BUFFER PARA AS RESPOSTAS DO SERV. 77. char buff[msg_len]; 78. //FICHEIRO DESTINO 79. FILE* f=null; //USER E PASS ESPECIFICADOS 82. if(strchr(argv[1], '@')!= NULL) 83. { 84. sscanf(argv[1], "ftp://%[^:]:%[^@]@%[^/]/%[^\n]",user_name, pw, host, file_path); 85. } //USER E PASS PRE' DEFINIDOS 88. else { 89. sscanf(argv[1], "ftp://%[^/]/%[^\n]", host, file_path); 90. memcpy(user_name, "anonymous", sizeof(char) * SIZE); 91. memcpy(pw, "anonymous@anonymous.pass", sizeof(char) * SIZE); 92. } printf("\nligar A: %s\nutilizador: %s\npassword: %s", host, user_name, pw); if ((h=gethostbyname(host)) == NULL) { 97. herror("gethostbyname"); 98. exit(1); 99. } memcpy(server_addr, inet_ntoa(*((struct in_addr *)h- >h_addr)), sizeof(char)*size); //SOCKET PARA LIG DE CONTROLO 104. /*server address handling*/ 105. bzero((char*)&server_addr,sizeof(server_addr)); 106. server_addr.sin_family = AF_INET; 107. server_addr.sin_addr.s_addr = inet_addr(server_addr); /*32 bit Internet address network byte ordered*/ 108. server_addr.sin_port = htons(server_port); 109. /*server TCP port must be network byte ordered */ 110. /*open an TCP socket*/ 111. if ((sockfd = socket(af_inet,sock_stream,0)) < 0) { 112. perror("socket()"); 113. exit(0); 114. } /*connect to the server*/ 117. if(connect(sockfd, 14

15 118. (struct sockaddr *)&server_addr, 119. sizeof(server_addr)) < 0){ 120. perror("connect()"); 121. exit(0); 122. } printf("\naberto SOCKET [CONTROLO] EM [ %s:%d ]\n", SERVER_ADDR, SERVER_PORT); 125. while(true) 126. { 127. receive_cmd(sockfd, buff); 128. if(strncmp(buff, "220", 3)!= 0) 129. { printf("\nerro: ESPERAVA CODIGO 220 [%s]...", buff); 132. break; 133. } //USER + PASS = char user[size]; 137. sprintf(user, "user %s", user_name); 138. //ENVIAR USER 139. send_cmd(sockfd, user); 140. //ESPERAR RESPOSTA 141. receive_cmd(sockfd, buff); 142. printf("\n<< %s", buff); char pass[size]; 145. sprintf(pass, "pass %s", pw); 146. //ENVIAR PASS 147. send_cmd(sockfd, pass); 148. //ESPERAR RESPOSTA 149. receive_cmd(sockfd, buff); 150. printf("\n<< %s", buff); if(strncmp(buff, "230", 3)!= 0) 153. { 154. printf("\nerro: LOGIN INCORRETO"); 155. break; 156. } //ENVIAR COMANDO SERVIDOR -> MODO PASSIVO 159. send_cmd(sockfd, "pasv"); 160. receive_cmd(sockfd, buff); 161. printf("\n<< %s", buff); 162. if(strncmp(buff, "227", 3)!= 0) { 163. printf("\nerro: MODO PASSIVO [ %s ]", buff); 164. break; 165. } //CALCULAR PORTA DA LIG DADOS 168. int msb, lsb; 169. sscanf(buff, "%*[^(](%*d,%*d,%*d,%*d,%d,%d)\n", &msb, &lsb); 170. int dest_port = msb*size + lsb; //ABRIR SOCKET LIG DADOS 173. /*server address handling*/ 174. bzero((char*)&server_addr2,sizeof(server_addr2)); 175. server_addr2.sin_family = AF_INET; 15

16 176. server_addr2.sin_addr.s_addr = inet_addr(server_addr); 177. /*32 bit Internet address network byte ordered*/ 178. server_addr2.sin_port = htons(dest_port); 179. /*server TCP port must be network byte ordered */ 180. /*open an TCP socket*/ 181. if ((sockfd2 = socket(af_inet,sock_stream,0)) < 0) { 182. perror("socket()"); 183. exit(0); 184. } 185. /*connect to the server*/ 186. if(connect(sockfd2, 187. (struct sockaddr *)&server_addr2, 188. sizeof(server_addr2)) < 0){ 189. perror("connect()"); 190. exit(0); 191. } 192. printf("\naberto SOCKET [DADOS] EM [ %s:%d ]", SERVER_ADDR, dest_port); 193. //ENVIAR PEDIDO RETR char retr_cmd[size]; 196. sprintf(retr_cmd, "retr %s", file_path); 197. send_cmd(sockfd, retr_cmd); 198. char* filename; 199. filename = strrchr(file_path,'/'); 200. if(filename!= NULL) { 201. filename++; 202. } 203. else{ 204. filename = file_path; 205. } 206. receive_cmd(sockfd, buff); 207. printf("\n<< %s", buff); 208. if(strncmp(buff, "550", 3) == 0) { 209. printf("\nerro: ACESSO AO FICHEIRO [ %s", buff); 210. exit(-1); 211. } 212. //ABRIR FICHEIRO PARA ESCRITA 213. f = fopen((const char *) filename, "wb"); 214. float n_bytes = 1.0; 215. float total_bytes = 0.0; 216. while(n_bytes!= 0) { 217. int bytes = receive_cmd(sockfd2, buff); 218. n_bytes = fwrite(buff, sizeof(char), bytes, f); 219. if(total_bytes < 1024) 220. { 221. printf("\n[ %f B GRAVADOS ]", total_bytes+=n_bytes); 222. } 223. else if(total_bytes >= 1024 && total_bytes < ) 224. { 225. printf("\n[ %.02f kb GRAVADOS ]", (total_bytes+=n_bytes)/1024); 226. } 227. else 228. { 229. printf("\n[ %.02f MB GRAVADOS ]", (total_bytes+=n_bytes)/ ); 16

17 230. } 231. } 232. printf("\ntransferencia Concluida!"); 233. break; 234. } 235. printf("\nencerrar SOCKETS\n"); 236. if(f!= NULL) 237. fclose(f); 238. if(sockfd2!= (int) NULL) 239. close(sockfd2); 240. if(sockfd!= (int) NULL) 241. close(sockfd); 242. exit(0); 243. } 5. Makefile all: download client: download./download ftp://ftp.up.pt/pub/openoffice/packages/10/ooo_3.3.0_win_x86_langpack_gu.exe small: download./download ftp://ftp.up.pt/pub/robots.txt clienttcp: download.c gcc -Wall -o download.o -c download.c gcc -Wall -o app download.o 6. Logs capturados a) Preenchimento da tabela ARP (exp1) Cisco_d4:1c:03 Spanning-tree-(for-bridges)_00 STP 60 Conf. Root = 32768/30/30:37:a6:d4:1c:00 Cost = 0 Port = 0x8003 Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) IEEE Ethernet Logical-Link Control Spanning Tree Protocol 17

18 Kye_08:d5:b3 Broadcast ARP 42 Who has ? Tell Frame 2: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) Hewlett-_c7:64:8e Kye_08:d5:b3 ARP is at 00:21:5a:c7:64:8e Frame 3: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Address Resolution Protocol (reply) ICMP 98 Echo (ping) request id=0xe857, seq=1/256, ttl=64 Frame 4: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) b)virtual Lans (exp2) Não há conetividade com o TUX ICMP 98 Echo (ping) request id=0x4160, seq=1/256, ttl=64 Frame 4: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) 18

19 Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol ICMP 98 Echo (ping) reply id=0x4160, seq=1/256, ttl=64 Frame 5: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol Cisco_d4:1c:03 Spanning-tree-(for-bridges)_00 STP 60 Conf. Root = 32768/40/30:37:a6:d4:1c:00 Cost = 0 Port = 0x8003 Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) IEEE Ethernet Logical-Link Control Spanning Tree Protocol 19

20 ICMP 98 Echo (ping) request id=0x4160, seq=2/512, ttl=64 Frame 7: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol ICMP 98 Echo (ping) reply id=0x4160, seq=2/512, ttl=64 Frame 8: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol c)tux4 como router evidenciar conetividade entre TUX2 e TUX ICMP 98 Echo (ping) request id=0x0f19, seq=2/512, ttl=64 20

21 Frame 7: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol ICMP 98 Echo (ping) reply id=0x0f19, seq=2/512, ttl=64 Frame 8: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol ICMP 98 Echo (ping) request id=0x1019, seq=1/256, ttl=64 Frame 9: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) 21

22 Internet Control Message Protocol ICMP 98 Echo (ping) reply id=0x1019, seq=1/256, ttl=64 Frame 10: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol Cisco_d4:1c:03 Spanning-tree-(for-bridges)_00 STP 60 Conf. Root = 32768/40/30:37:a6:d4:1c:00 Cost = 0 Port = 0x8003 Frame 11: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) IEEE Ethernet Logical-Link Control Spanning Tree Protocol ICMP 98 Echo (ping) request id=0x0f19, seq=3/768, ttl=64 22

23 Frame 12: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol ICMP 98 Echo (ping) reply id=0x0f19, seq=3/768, ttl=64 Frame 13: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol ICMP 98 Echo (ping) request id=0x1019, seq=2/512, ttl=64 Frame 14: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) 23

24 Internet Control Message Protocol ICMP 98 Echo (ping) reply id=0x1019, seq=2/512, ttl=64 Frame 15: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) Internet Control Message Protocol d)transferência do ficheiro DNS 69 Standard query A ftp.up.pt Frame 4: 69 bytes on wire (552 bits), 69 bytes captured (552 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: (59492), Dst Port: domain (53) 24

25 Domain Name System (query) DNS 337 Standard query response A Frame 5: 337 bytes on wire (2696 bits), 337 bytes captured (2696 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: domain (53), Dst Port: (59492) Domain Name System (response) TCP > ftp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval= TSecr=0 WS=32 Frame 6: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) Transmission Control Protocol, Src Port: (48687), Dst Port: ftp (21), Seq: 0, Len: 0 25

26 TCP 74 ftp > [SYN, ACK] Seq=0 Ack=1 Win=65228 Len=0 MSS=1460 WS=16 SACK_PERM=1 TSval= TSecr= Frame 7: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3 (00:c0:df:08:d5:b3) Internet Protocol Version 4, Src: ( ), Dst: ( ) Transmission Control Protocol, Src Port: ftp (21), Dst Port: (48687), Seq: 0, Ack: 1, Len: TCP > ftp [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval= TSecr= Frame 8: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e) Internet Protocol Version 4, Src: ( ), Dst: ( ) Transmission Control Protocol, Src Port: (48687), Dst Port: ftp (21), Seq: 1, Ack: 1, Len: FTP 106 Response: 220 Bem-vindo à Universidade do Porto 26