Seminario de Redes TRABAJO PRACTICO Nº 1. Ping y Traceroute. deimos_azul@yahoo.com Padrón: 77902

Transcripción

1 Departamento de Electrónica Facultad de Ingeniería Seminario de Redes TRABAJO PRACTICO Nº 1 Ping y Traceroute Grupo Nº: Responsable a cargo: Integrantes: Guzmán Pegazzano, Ma. Azul deimos_azul@yahoo.com Padrón: Josa Scorza, Gonzalo gonzalojosa@hotmail.com Padrón: Rodríguez Palacios, Agustina apalaci@fi.uba.ar Padrón: 77677

2 Introducción. El objetivo de este trabajo práctico es utilizar las herramientas ping y traceroute para poder analizar las distintas características del protocolo IP y su aplicación en redes LAN y WAN. Los protocolos a utilizar serán Ethernet, ARP, IP e ICMP. Dado que nuestro análisis se desarrolla mayoritariamente sobre redes LAN, describiremos brevemente el proceso de interacción de estos protocolos en dichas redes. Cuando una PC quiere enviar datagramas IP a otra PC conectada en la misma LAN, debe generar una trama MAC donde encapsular el datagrama IP. En dicha trama se colocan la dirección origen, la dirección destino a nivel físico y el tipo de protocolo de nivel superior que encapsula. Para averiguar la dirección MAC asociada a una IP determinada (destino), la PC envía un mensaje de consulta ARP encapsulado en una trama MAC, la cual posee como dirección destino todos unos (broadcast) y como dirección origen la de quien emite el mensaje. El mensaje ARP contiene la dirección IP y MAC origen, y la dirección IP destino. El encabezado del datagrama IP es el siguiente: VERS LENGTH TOS TOTAL LENGHT IDENTIFICATION FLAGS OFFSET TIME TO LIVE PROTOCOL CHECKSUM. ORIGIN IP ADDRESS DESTINATION IP ADDRESS El datagrama IP se encapsula en la parte del campo de datos de la trama MAC al igual que el mensaje ARP. Por otro lado, los mensajes ICMP se encapsulan en el campo de datos de un datagrama IP y los mismos poseen un encabezado de 4 bytes como mínimo. En éste se incluye un campo tipo de mensaje de 8 bits; un campo código de 8 bits, y un campo checksum de 16 bits. Además, los mensajes ICMP que reportan errores siempre incluyen el encabezado y los primeros 64 bits de datos del datagrama que causó el problema. HEADER ICMP ICMP DATA HEADER IP IP DATA HEADER MAC ETHERNET DATA 2

3 PING Esta aplicación genera mensajes ICMP de echo request. Cuando es utilizada se envía un mensaje de echo request hacia un host destino, el cual es especificado a través de su dirección IP. De acuerdo a si el destino esta accesible o no se generan distintos mensajes ICMP de respuesta; cada uno con un formato distinto. En particular, para el echo request (8) y el echo reply (0) el formato es el siguiente: TYPE (8-0) CODE (0) CHECKSUM IDENTIFIER SEQUENCE NUMBER TRACEROUTE Esta aplicación se utiliza para conocer la ruta que une a dos hosts. Utiliza mensajes ICMP echo request o UDP e ICMP dependiendo de la plataforma en donde es implementada. El proceso que sigue es el siguiente: El origen envía un ping con TTL =1 al destino, y es el primer salto el que se encarga de descontar el TTL y descartarlo, enviando así un mensaje ICMP de tiempo excedido al origen, registrando su dirección IP. Luego se envía un nuevo ping al destino, pero incrementando en uno el TTL, y ahora será el próximo salto el que se encargue de descartarlo, informándole al origen este acontecimiento. Este proceso se repite, hasta que llega el ping al destino con TTL=1. En esta instancia, el host final descuenta en uno el TTL, y envía un mensaje ICMP al host origen, indicando que el puerto al cual se quiso acceder es inaccesible. Esto se realiza así, para que el origen sepa cuando el datagrama llegó a su destino final. 3

4 Maqueta. Para el desarrollo de las pruebas se utilizará la siguiente maqueta. Dependiendo del escenario en cuestión, se utilizará una parte de la maqueta en especial, la cual será especificada en el escenario correspondiente, es decir, la siguiente es la maqueta más general utilizándose ciertos sectores de la misma en cada caso. FILO.UBA. SERVER ETH. A: / PC2 PC3 PC1 INTERNET + PC L14 MDM ETH B: / 24 MDM CABLEMODEM + BR PC5 PC4 Descripción de los equipos utilizados. PC1: Windows XP. Ethereal. PC2: Windows 98. Ethereal. PC3: Linux Red Hat 7.2 PC4: Windows 98. PC5: Windows Ethereal. BR1: BroadBand Router. PCL14: Linux. 4

5 Escenario I. Envío de un datagrama IP dentro de una LAN. Objetivo: El objetivo de este escenario es observar el proceso de envío de un datagrama dentro de una red LAN. Desarrollo: Para lograr el objetivo, se enviarán mediante el comando ping mensajes desde la PC 1 hacia la PC 2, sniffeando el tráfico de paquetes a través de la placa de red de la PC 1 con el Ethereal. El proceso que se espera observar es el siguiente: La PC 1 debe encapsular el datagrama IP dentro de una trama MAC, para ello debe conocer la dirección física de la PC 2. Como lo único que conoce es la dirección IP de la PC 2, se realiza en primer lugar una consulta ARP con el fin de obtener la MAC asociada. Una vez obtenida, se arma la trama MAC con estas direcciones y se encapsula el datagrama en ella. El mensaje ICMP viajará dentro del datagrama. Dado que la trama que le llega al destino, ya incluye la dirección MAC y la dirección IP de quien envió el datagrama, el destino utilizará estas direcciones para armar la trama MAC con el mensaje ICMP de respuesta. Como el mensaje es un echo request, en el campo tipo se deberá observar un valor de 8. Para el caso de echo reply este campo tendrá un valor de 0. Ejecución: Se generó un comando ping desde la PC1 (IP: ) hacia la PC2 (IP: ). La captura realizada es la siguiente: Las tramas 4 y 5 pertenecen a la consulta ARP y a su respectiva respuesta. La consulta es generada por la PC 1 y la respuesta por la PC 2. 5

6 La consulta ARP (trama 4) es del tipo Broadcast de nivel 2 lo que se observa en la dirección de destino del header MAC; mientras que la respuesta (trama 5) es unicast. En el header de Ethernet II se ve también que el tipo de protocolo encapsulado es ARP. A partir de la trama 6 hasta la trama 13 se produce el intercambio de mensajes ICMP. Las tramas 6,8,10 y 12 corresponden a mensajes echo request; mientras que las tramas 7,9,11 y 13 corresponden a mensajes echo reply. Todos estos paquetes poseen el mismo formato con la salvedad de que los mensajes echo request tienen valor 8 en el campo TYPE del header ICMP y los mensajes echo reply tienen el valor 0. Las direcciones IP y MAC se invierten en estos mensajes. En las tramas siguientes se puede ver que el campo secuence number del echo reply en el header ICMP se corresponde con el campo secuence number del echo request 6

7 7

8 Conclusiones: Se pudieron verificar las hipótesis planteadas. A su vez, también pudimos verificar la correspondencia entre mensajes de pregunta respuesta a través del campo secuence number del header ICMP. Una cuestión que no se tuvo en cuenta a la hora de las hipótesis y que se verificó con la ejecución fue el hecho de que en el header de la trama MAC, aparece el tipo de protocolo de nivel superior que se encuentra encapsulado en la misma. 8

9 Escenario II. Envío de un datagrama IP hacia otra red. Objetivo: El objetivo de este escenario es observar el proceso de envío de un datagrama hacia una red distinta a la del host. Se espera ver que en este caso la dirección MAC destino no se corresponderá con la dirección IP destino. Desarrollo: El desarrollo de este escenario es similar al anterior con la salvedad que al enviarse un mensaje de echo request hacia un host que no pertenece a la misma red, la trama MAC que encapsula dicho mensaje, lleva como dirección MAC destino la del gateway de la red, pese a que en el datagrama, la dirección IP destino sea la del host final. Ejecución: Se enviaron 4 paquetes ICMP con el comando ping desde la PC2 (Ana.mshome.net) hacia la IP publica ( ) correspondiente a la Ethernet B. La traza capturada fue la siguiente: El contenido del primer paquete es la siguiente: En este paquete la dirección destino de la trama ethernet corresponde a la dirección física del default gateway de la red Ethernet A (hppav.mshome.net). Esta dirección no se corresponde con la IP destino debido a que la maquina destino del 9

10 mensaje ICMP se encuentra en una red distinta; por lo cual el paquete debe salir de la red A a través de su default gateway. Conclusiones: Comprobamos que cuando se envía un paquete hacia una red externa, la dirección física destino de la trama es siempre la del gateway de la propia red y por lo tanto no se corresponde con la IP destino. 10

11 Escenario III. Mensajes ICMP. Objetivo: Observar mediante los mensajes ICMP recibidos como respuesta a echo request enviados, la condición de un host o una red. Desarrollo: Se enviarán pings desde la PC1 hacia la PC2, cuando está se encuentra conectada, y cuando se halla desconectada; y se repetirá la experiencia, pero hacia el BR1. También se enviarán pings desde la PC3 hacia una dirección IP que no está asignada dentro de la LAN. Ejecución: En primer lugar enviamos pings dentro de la red Ethernet A desde la PC 1 hacia la PC 2 estando esta conectada; durante el envío de paquetes se desconectó por un instante la placa de red y se observó lo siguiente: En este caso solo existen mensajes echo request y echo reply. Cuando se desconecta la placa de red de la PC 2 el mensaje que aparece en pantalla de request timed out es generado por la propia PC 1 al agotarse el tiempo de espera de respuesta. Se repite la operación pero ahora el destino será BR1 que se encuentra conectado a Internet y cuya IP es La traza obtenida fue la siguiente: 11

12 El resultado obtenido es similar al anterior mas allá de que los hosts estuvieran unidos a través de Internet. Esperábamos obtener mensajes de respuesta de host inalcanzable cuando era desconectado el BR1. Se realizó luego un ping desde la PC1 hacia una dirección IP de su misma red pero que no estaba asignada a ningún host. Se obtuvo lo siguiente: Y las trazas asociadas fueron: 12

13 Vemos que lo único que se envían son consultas ARP sobre la MAC asociada a la IP y que al no obtener respuesta se muestra un mensaje de tiempo de respuesta excedido. Repetimos la experiencia desde la PC3 ya que su sistema operativo es Linux. Esperamos obtener una respuesta diferenta a la anterior a pesar de que la situación es la misma. Los mensajes y trazas obtenidas son las siguientes: [root@localhost root]#ping PING ( ) from : 56(84) bytes of data. From icmp_seq=1 Destination Host Unreachable From icmp_seq=2 Destination Host Unreachable From icmp_seq=3 Destination Host Unreachable From icmp_seq=4 Destination Host Unreachable From icmp_seq=5 Destination Host Unreachable From icmp_seq=6 Destination Host Unreachable From icmp_seq=7 Destination Host Unreachable From icmp_seq=8 Destination Host Unreachable From icmp_seq=9 Destination Host Unreachable ping statistics packets transmitted, 0 received, +9 errors, 100% loss, time 9028ms, pipe 3 [root@localhost root]# [root@localhost root]# Conclusiones: Pudimos observar distintos mensajes ICMP obteniéndose resultados según lo esperado, salvo en aquella ocasión en donde se realizo un ping hacia una IP inexistente mediante la plataforma Windows, en donde se esperaba obtener un mensaje de host inexistente y sin embargo la respuesta fue un mensaje de tiempo de respuesta excedido. Esto no sucedió cuando repetimos la experiencia bajo la plataforma Linux, donde sí obtuvimos el mensaje de respuesta esperado. 13

14 Escenario IV. Obtención de la MTU. Objetivo: Determinar la MTU de una red; en particular la de la red Ethernet A. Desarrollo: Para poder determinar la MTU de la red ETH A se enviarán mediante la aplicación ping, datagramas IP entre la PC 1 y la PC2 con el bit DF activado. Se irá incrementando la cantidad de bytes enviados por paquete hasta encontrar el tamaño de la MTU de la red mediante los mensajes ICMP recibidos. Para ello se utilizará la opción f del comando ping, el cual activa el bit DF en el encabezado de los datagramas a enviar, impidiendo que aquellos que tengan un tamaño mayor que el permitido sean enviados. De no activar este bit, se esperaría que, sin importar la cantidad de bytes que se envíen, la respuesta a este comando fuese exitosa. Se especificará también la cantidad de bytes a enviar a través de la opción l. Con estas herramientas, se comenzarán a enviar datagramas de 1000 bytes de longitud; si la respuesta es un echo reply, se irá incrementando el tamaño de los paquetes de a 100 bytes hasta obtener un mensaje que indique que el paquete no pudo ser transmitido. En esta instancia, decrementaremos en 10 bytes la longitud, hasta obtener nuevamente un mensaje echo reply. El ajuste final se hará aumentando de a un byte. El valor de la MTU será aquel con el que se obtuvo finalmente el mensaje de echo reply. La línea de comando a escribir es: ping f l [longitud] [dirección IP destino] Ejecución: Se procedió según el desarrollo y en la última instancia se obtuvo la siguiente salida: 14

15 A partir de la ventana de DOS observamos que la máxima cantidad de bytes que se pueden enviar en el mensaje ICMP sin fragmentar es de Este valor no es el valor real de la MTU ya que deben considerarse los bytes correspondientes al header ICMP (8 bytes) e IP (20 bytes). Debemos recordar que la MTU de la red es la máxima cantidad de datos que puede transferirse en una trama física; por lo tanto en este caso, la MTU será de 1500 bytes ( ). Para verificar esto analizamos la traza de este mensaje ICMP viendo el campo total lenght en el header IP. 15

16 Conclusiones: Para poder hallar la MTU de la red se tuvieron en cuenta no solo la cantidad de datos del mensaje ICMP sino que también la cantidad de bytes de los headers ICMP e IP, ya que ambos forman parte del campo de payload de la trama física. 16

17 Escenario V. Proceso de fragmentación. Objetivo: Observar el proceso de fragmentación de IP. Desarrollo: Sabemos que el protocolo IP deseará fragmentar aquellos paquetes de longitud mayor a la MTU para poder transmitirlos; entonces, si el bit DF no está seteado, el proceso de fragmentación se llevará a cabo. Para ver el proceso de fragmentación se enviarán pings desde la PC1 a la PC2 con un tamaño mayor al de la MTU de la red, y mediante el sniffeo de paquetes se verán los distintos campos del encabezado IP que involucra este proceso (fragment offset, more fragments y don t fragment) Ejecución: Se generó un comando ping con un tamaño de mensaje de 3000 bytes: La captura de los paquetes fue la siguiente: 17

18 18

19 La traza que se corresponde con un mensaje de echo request (compuesto por 3 paquetes) es la siguiente: 19

20 Observaciones: 1- En todos los paquetes no se encontraba activado el bit don t fragment (por default se encuentra en esta condición) con lo cual todos los paquetes que superaban la MTU de la red fueron fragmentados. 2- En el primer y segundo paquete se encuentra activado también el bit more fragment, indicando que aún quedan paquetes pertenecientes al mismo datagrama original. 3- En el ultimo paquete el bit more fragment posee un valor de 0, lo cual indica que este es el último fragmento del datagrama. 4- El campo fragment offset indica la posición del fragmento en el datagrama total. En la trama 25 este campo tiene un valor de 0, lo cual indica que este es el primer fragmento del datagama; mientras que en la trama 26 este campo posee un valor de El ultimo fragmento posee un valor de 2960 en el mismo. Esto nos da la pauta de que los valores de los fragment offset son múltiplos de 1480, el cual es el valor máximo posible de datos que se pueden enviar por esta red (MTU Header IP). 5- El header ICMP solo aparece en el primer fragmento del datagrama original. Conclusiones: En este escenario, no se activo el bit don t fragment, con lo cual todos los datagramas que superaban el valor de la MTU fueron fragmentados y por lo tanto pudieron ser enviados. A partir de los paquetes enviados, se observa que la cantidad de datos que se envían en el echo request es idéntica a la cantidad de datos que regresan en el echo reply (paquetes que también debieron fragmentarse). El hecho de que el header ICMP solo aparezca en el primer fragmento del datagrama original se debe a que la fragmentación es a nivel IP es decir, se genera un solo mensaje ICMP y es la capa de red quien se encarga de realizar la misma. 20

21 Escenario VI. Análisis del incremento del RTT en función de la longitud de los datagramas. Objetivo: Obtener una curva del RTT en función del largo de los paquetes en una LAN. Desarrollo: Comenzamos enviando una serie de 10 pings de 100 bytes desde la PC 3 hacia la PC 1 a través de la red ETH A de 10 Mbps. Tomamos el promedio del tiempo de los 10 paquetes. Luego incrementamos el tamaño de los mismos de a 100 bytes, repitiendo la experiencia hasta llegar a los 64kbytes. Con los resultados obtenidos se elaborará el gráfico buscado. Ejecución: Se generaron secuencias de ping de 10 paquetes con tamaño incremental en unidades de 100 bytes. A partir de los resultados obtenidos se trazó la siguiente curva: Incremento del RTT RTT (ms) 3 2,5 2 1,5 1 0,5 0 y = 0,0016x + 0, Cantidad de Bytes 21

22 Incremento del Round Trip Time RTT (ms) y = 0,0017x + 0, Cantidad de Bytes Conclusiones: El RTT varía en forma lineal a medida que se aumenta el tamaño de los paquetes. En el primer gráfico se observa que la pendiente es menor respecto del segundo. En el primero, el tamaño de los paquetes no supera la MTU de la red, por lo que no hay fragmentación; mientras que en el segundo gráfico todos los paquetes deben ser fragmentados para poder ser enviados, esto lleva a pensar que el proceso de fragmentación incrementa el tiempo medio de viaje de los paquetes. 22

23 Escenario VII. Ancho de banda. Objetivo: Determinar en forma aproximada el ancho de banda del canal de comunicación entre dos hosts en una LAN y en Internet. Desarrollo: Se enviarán dos series de pings, cada una con una longitud distinta (30000 y bytes) entre la PC 1 y la PC 2, y se tomará el RTT promedio de cada una. Con estos datos se hallará un valor estimado de la velocidad del canal según la expresión: 2. L.8 RTT = + 2. t prop + t proces R Donde: RTT: tiempo total que tarda el paquete en ir y volver. L: longitud del paquete en bytes. R: capacidad del canal en bits/seg. t prop : tiempo de propagación en el medio. t proces : tiempo de procesamiento en el receptor. Dado que el tiempo de propagación es fijo, y que el de procesamiento es igual para todas las series (el comando ping lee sólo los encabezados), se obtiene un sistema de dos ecuaciones con dos incógnitas: R y t x (t x = 2.t prop + t proces ). A partir de ellas surge: R = ( L2 L1 ). 16 ( RTT RTT ) 2 1 (1) Este procedimiento se repite para dos hosts que se encuentran conectados a través de Internet. Ejecución: Se enviaron dos comandos ping desde la PC3 hacia la PC1, con dos tamaños distintos (30000 y bytes) según la línea de comandos: ping c 10 s [sizepacket] donde la opción c indica la cantidad de repeticiones (bajo plataforma UNIX). 23

24 Se obtuvieron los siguientes tiempos promedios: root]# ping -c 10 -s PING ( ) from : 30000(30028) bytes of data bytes from : icmp_seq=1 ttl=128 time=51.1 ms bytes from : icmp_seq=2 ttl=128 time=51.1 ms bytes from : icmp_seq=3 ttl=128 time=51.1 ms bytes from : icmp_seq=4 ttl=128 time=51.0 ms bytes from : icmp_seq=5 ttl=128 time=51.1 ms bytes from : icmp_seq=6 ttl=128 time=51.1 ms bytes from : icmp_seq=7 ttl=128 time=51.1 ms bytes from : icmp_seq=8 ttl=128 time=51.0 ms bytes from : icmp_seq=9 ttl=128 time=51.0 ms bytes from : icmp_seq=10 ttl=128 time=51.1 ms ping statistics packets transmitted, 10 received, 0% loss, time 510.6ms rtt min/avg/max/mdev = /51.093/51.173/0.186 ms [root@localhost root]# [root@localhost root]# [root@localhost root]# ping -c 10 -s PING ( ) from : 60000(60028) bytes of data bytes from : icmp_seq=1 ttl=128 time=101 ms bytes from : icmp_seq=2 ttl=128 time=102 ms bytes from : icmp_seq=3 ttl=128 time=101 ms bytes from : icmp_seq=4 ttl=128 time=106 ms bytes from : icmp_seq=5 ttl=128 time=101 ms bytes from : icmp_seq=6 ttl=128 time=101 ms bytes from : icmp_seq=7 ttl=128 time=109 ms bytes from : icmp_seq=8 ttl=128 time=102 ms bytes from : icmp_seq=9 ttl=128 time=101 ms bytes from : icmp_seq=10 ttl=128 time=101 ms ping statistics packets transmitted, 10 received, 0% loss, time 9152ms rtt min/avg/max/mdev = / / / ms [root@localhost root]# # Bytes RTT bytes ms bytes ms En base a estos resultados se aplicó la fórmula (1), y se calculó la capacidad del enlace. La misma resultó ser igual a 9.46 Mbps. 24

25 Del escenario anterior, consideramos el valor de la pendiente de la recta para calcular el valor de R, a partir de la siguiente ecuación: 16 R = * kbps Pendiente En el primer gráfico el valor de la pendiente es de , en tanto en el segundo el valor es de ; lo cual arroja una velocidad de enlace de 10 Mbps y 9.41 Mbps respectivamente. Ahora se conectaron ambas PCs mediante un cable cruzado con el fin de que el enlace entre ambas sea de 100 Mbps. Las series de pings enviadas fueron de y bytes. Las pruebas arrojaron los siguientes resultados: root@localhost root]# ping -c 10 -s PING ( ) from : 35000(35028) bytes of data bytes from : icmp_seq=1 ttl=128 time=7.10 ms bytes from : icmp_seq=2 ttl=128 time=7.11 ms bytes from : icmp_seq=3 ttl=128 time=7.10 ms bytes from : icmp_seq=4 ttl=128 time=7.09 ms bytes from : icmp_seq=5 ttl=128 time=7.09 ms bytes from : icmp_seq=6 ttl=128 time=7.08 ms bytes from : icmp_seq=7 ttl=128 time=7.10 ms bytes from : icmp_seq=8 ttl=128 time=7.16 ms bytes from : icmp_seq=9 ttl=128 time=12.3 ms bytes from : icmp_seq=10 ttl=128 time=7.17 ms ping statistics packets transmitted, 10 received, 0% loss, time 9088ms rtt min/avg/max/mdev = 7.089/7.636/12.320/1.561 ms [root@localhost root]# [root@localhost root]# [root@localhost root]# [root@localhost root]# ping -c 10 -s PING ( ) from : 60000(60028) bytes of data bytes from : icmp_seq=1 ttl=128 time=11.9 ms bytes from : icmp_seq=2 ttl=128 time=11.9 ms bytes from : icmp_seq=3 ttl=128 time=11.9 ms bytes from : icmp_seq=4 ttl=128 time=11.9 ms bytes from : icmp_seq=5 ttl=128 time=12.0 ms bytes from : icmp_seq=6 ttl=128 time=11.9 ms bytes from : icmp_seq=7 ttl=128 time=11.9 ms bytes from : icmp_seq=8 ttl=128 time=11.9 ms bytes from : icmp_seq=9 ttl=128 time=11.9 ms bytes from : icmp_seq=10 ttl=128 time=11.9 ms ping statistics packets transmitted, 10 received, 0% loss, time 9093ms rtt min/avg/max/mdev = /11.971/12.005/0.131 ms [root@localhost root]# [root@localhost root]# 25

26 # Bytes RTT bytes ms bytes ms Utilizando estos valores se vuelve a calcular la capacidad del enlace. El valor de la misma en este caso es: 92.2 Mbps. Se realizó una experiencia similar a la primera, pero enviando los paquetes desde la PC L14 hacia el servidor filo.uba.ar. En este caso se enviaron paquetes de y bytes por limitaciones de timeout, obteniéndose los siguientes resultados: [alumno@l14 alumno]$ ping -c 10 -s PING from : 30000(30028) bytes of data bytes from : icmp_seq=1 ttl=251 time=1029 ms bytes from : icmp_seq=2 ttl=251 time=1659 ms bytes from : icmp_seq=3 ttl=251 time=1813 ms bytes from : icmp_seq=4 ttl=251 time=1325 ms bytes from : icmp_seq=5 ttl=251 time=1152 ms bytes from : icmp_seq=6 ttl=251 time=1026 ms bytes from : icmp_seq=7 ttl=251 time=1055 ms bytes from : icmp_seq=8 ttl=251 time=1361 ms bytes from : icmp_seq=9 ttl=251 time=1057 ms bytes from : icmp_seq=10 ttl=251 time=1026 ms --- jaguar.filo.uba.ar ping statistics packets transmitted, 10 received, 0% loss, time 9094ms rtt min/avg/max/mdev = / / / ms, pipe 2 [alumno@l14 alumno]$ [alumno@l14 alumno]$ ping -c 10 -s PING from : 10000(10028) bytes of data bytes from : icmp_seq=1 ttl=251 time=355 ms bytes from : icmp_seq=2 ttl=251 time=363 ms bytes from : icmp_seq=3 ttl=251 time=352 ms bytes from : icmp_seq=4 ttl=251 time=355 ms bytes from : icmp_seq=5 ttl=251 time=374 ms bytes from : icmp_seq=6 ttl=251 time=355 ms bytes from : icmp_seq=8 ttl=251 time=351 ms bytes from : icmp_seq=9 ttl=251 time=383 ms bytes from : icmp_seq=10 ttl=251 time=378 ms --- jaguar.filo.uba.ar ping statistics packets transmitted, 9 received, 10% loss, time 9083ms rtt min/avg/max/mdev = / / / ms [alumno@l14 alumno]$ # Bytes RTT bytes ms bytes ms 26

27 Utilizando estos valores se vuelve a calcular la capacidad del enlace. El valor de la misma en este caso es: Kbps. Conclusiones: Con esta prueba se pudo determinar con un error menor al 10% la velocidad de transmisión en una red LAN por lo que el método es bueno para obtener una primera aproximación. También se comparó el resultado obtenido con el que pudimos generar en base al escenario anterior y vimos que aquel es mas preciso cuando se trabaja con paquetes cuyo tamaño es menor al de la MTU. Esta diferencia se la puede atribuir al proceso de fragmentación en donde deben tenerse en cuenta los tiempos de permanencia de los fragmentos en la cola (tiempo que espera la capa IP hasta que llega el último fragmento, reensambla y envía a la capa superior). Para el caso del enlace a través de la WAN, no podemos arribar a una conclusión sobre la exactitud del resultado obtenido, ya que no se conoce la capacidad del enlace entre ambos extremos. 27

28 Escenario VIII. Variantes en el uso de las herramientas ping y el traceroute. Objetivo: Comparar la funcionalidad de los comandos ping y traceroute. Desarrollo: La aplicación ping puede también ser utilizada para identificar la ruta entre dos hosts. Para ello cada equipo que rutea el mensaje ICMP registra su dirección IP en el datagrama. De esta manera, cuando la respuesta llega al origen, contiene las direcciones IP de todos los saltos por los que pasó, tanto de ida como de vuelta además del valor del RTT entre el origen y el destino final. Esta opción del comando ping registra hasta un máximo de 9 saltos en la ruta y un mínimo de 1, por lo que aquellas rutas que posean mayor cantidad de saltos, quedarán incompletas. Para salvar esta limitación, se utiliza el comando traceroute (tracert), descripto anteriormente; el cual realiza el trazado de la ruta del paquete sin importar la cantidad de saltos totales (siempre que sea menor a 30). Esta aplicación otorga como resultado las direcciones IP de los saltos, como también 3 RTT diferentes desde el origen a cada uno de ellos. Esta es una ventaja respecto al método mencionado anteriormente, ya que nos permite determinar la ruta completa desde el origen al destino, pudiendo a su vez conocer el tiempo entre saltos. Pueden existir equipos, como por ejemplo un firewall, que no envíen mensajes ICMP de tiempo excedido si a ellos les llega un ping con TTL=1. En este caso, dicho salto no será registrado por el origen, por lo que en los RTT aparecerán asteriscos (*). Utilizaremos la aplicación traceroute para descubrir la ruta entre la PC L14 y el servidor Optamos por esta maqueta, ya que el ISP que provee la conexión dial-up y el cable modem presentan un filtrado de paquetes. Observaremos la cantidad de saltos, y generaremos un comando ping hacia el mismo servidor con la opción r [cantidad de saltos] o R según la plataforma utilizada (Windows o Linux), seteada en base a la cantidad de saltos obtenida con el traceroute. Ejecución: Se utilizó el comando traceroute entre la PC L14 y el servidor filo.uba.ar obteniéndose el siguiente resultado: [alumno@l14 alumno]$ traceroute traceroute to, 30 hops max, 38 byte packets 1 fing1 ( ) ms ms ms ( ) ms * * 3 paps.uba.ar ( ) ms ms ms 4 ffilop-paps.uba.ar ( ) ms ms ms ms ms ms 28

29 Aquí se presentan las trazas capturadas mediante el Ethereal (las tramas no son consecutivas debido a que existe mucho tráfico capturado en esta interfaz que no corresponde a nuestro escenario): Estas dos primeras tramas (6 y 7) muestran la consulta desde el host hacia su servidor DNS sobre la dirección IP asociada a y la correspondiente respuesta. Una vez obtenida esta información se procede a generar un mensaje UDP con TTL=1 hacia un puerto efímero del servidor destino ( Esto se ve reflejado en la trama 8 La trama 44 corresponde al mensaje ICMP de respuesta generado por el primer salto quien al decrementar el TTL descarta el mensaje original. 29

30 Las siguientes dos tramas (45 y 46) indican la pregunta y respuesta acerca del nombre asociado a la IP del primer salto. Esto es así ya que el comando traceroute además de indicar el RTT informa sobre el nombre (si existe) y la IP del salto que generó la respuesta. De esta manera, y siguiendo el mismo procedimiento, se continúan enviando mensajes UDP con TTL incremental hasta llegar al host destino. Una vez que éste recibe el mensaje, envía al origen un ICMP indicando puerto inaccesible. Esto se manifiesta en la trama

31 Ahora realizaremos la misma prueba pero utilizando el comando ping con la opción R para grabar la ruta. La salida obtenida es la siguiente: [alumno@l14 alumno]$ ping -R PING from : 56(124) bytes of data. 64 bytes from : icmp_seq=1 ttl=251 time=51.5 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) De la traza realizada observamos que las direcciones IP de los saltos vienen alojadas en el campo de opciones del encabezado IP. 31

32 Para comparar las diferencias de implementación del traceroute según la plataforma, realizamos un traceroute hacia desde la PC 2. Los resultados obtenidos son: 32

33 Observando los paquetes capturados vemos que los mensajes enviados por la aplicación corresponden a mensajes ICMP echo request y la respuesta final generada por el destino ( es un echo reply Conclusiones: A partir de las experiencias realizadas descubrimos que las plataformas Windows y Linux implementan de distinta forma la herramienta traceroute. La primera envía series de tres mensajes ICMP echo request con TTL incremental hasta recibir una respuesta echo reply por parte del destino; en cambio Linux envía mensajes UDP hacia un puerto efímero con TTL incremental hasta recibir una respuesta ICMP de puerto inaccesible. Por otra parte, al comparar las herramientas ping y traceroute para descubrir una ruta, vimos que la primera restringe a 9 la cantidad de saltos registrados entre la ida y la vuelta, por lo que si el destino se encuentra a mas de 5 saltos el mensaje recibido será de tiempo de respuesta agotado. Esto es una desventaja ya que el traceroute permite un 33

34 máximo de 30 saltos desde el origen hasta el destino. Además la información aportada por el ping comprende solo las direcciones IP de los saltos en tanto que el traceroute además informa del RTT entre cada salto y el origen. Sin embargo esta última utiliza cada respuesta ICMP arrojada por los saltos para armar la ruta mientras que en el ping toda la información sobre las direcciones IP viaja en un solo paquete ICMP. Otra diferencia es que las direcciones brindadas por el ping y el traceroute son diferentes mas allá de que pertenezcan a los mismos equipos. Esto sucede porque en el ping las direcciones IP que colocan los equipos son aquellas pertenecientes a las interfaces por las cuales el paquete es forwardeado, mientras que en el traceroute las direcciones que se muestran son aquellas por las cuales se envían los mensajes ICMP de tiempo excedido: es decir las IP de regreso del comando ping. Lo podemos verificar observando las dos últimas direcciones registradas en el ping dado que estas concuerdan con las arrojadas por el traceroute. 34

35 Escenario IX. Obtención de la ruta que une dos hosts en Internet. Objetivos: Obtener la ruta que une a dos hosts conectados a través de Internet y verificar si ésta se mantiene en ambos sentidos. Desarrollo: Se utilizará el comando traceroute para descubrir la ruta desde la PC 1 en la red ETH A hacia un portal que brinda servicio de traceroute y viceversa. Ejecución: Se utilizó el portal para enviar un comando traceroute hacia la PC 1 cuya IP asignada por el ISP es Los resultados obtenidos fueron: Doing a traceroute to: ' ' ( ) ms ms 3.48 ms ( ) ms ms ms 3 host arnet.net.ar ( ) ms ms ms 4 bel02ra-se tasf.telecom.net.ar ( ) ms ms ms telecom.net.ar ( ) ms ms ms 6 bel01rt-pos1-4-0.tasf.telecom.net.ar ( ) ms ms ms 7 glf01ra-pos tasf.telecom.net.ar ( ) ms ms ms 8 nap-norte-nap2.telintar.net.ar ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms * ms ( ) ms ms ms 13 * * * 14 * * * Se realizó luego el procedimiento inverso mediante el comando traceroute. 35

36 Se repitió la experiencia pero ahora desde el portal servicios.att.net.co. En este caso las trazas fueron las siguientes: Traceroute desde servicios.att.net.co Resultado para : traceroute to ( ) from , 30 hops max, 40 byte packets 1 fw1b.attla.net.co ( ) ms ms ms 2 * * * 3 * gw-isp.attla.net.co ( ) ms ms 4 * gw-dcenter-directa.attla.net.co ( ) ms ms ( ) ms ms ms 6 n54ny32ck.pos10-2.ip.att.net ( ) ms * ms 7 gbr6-p80.n54ny.ip.att.net ( ) ms ms ms 8 * * tbr1-p n54ny.ip.att.net ( ) ms 9 ggr1-p330.n54ny.ip.att.net ( ) ms ms * 10 sl-bb20-nyc-13-1.sprintlink.net ( ) ms ms ms 11 sl-bb27-nyc-6-0.sprintlink.net ( ) ms ms ms 12 sl-gw31-nyc-1-0.sprintlink.net ( ) ms ms ms 13 sl-tiws-2-0.sprintlink.net ( ) ms * ms 14 So grtmiatc1.ri.telefonica-data.net ( ) ms ms ms 15 P11-0-grtbueba1.ri.telefonica-data.net ( ) ms ms ms 16 advance grtbueba1.ri.telefonica-data.net ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms 21 * * * 22 * * * 36

37 Para el traceroute desde la PC1 la salida fue: Conclusiones: Se deduce de las pruebas anteriores que no siempre la ruta desde un host origen hacia uno destino es la misma que la de este último hacia el primero. En el primer caso ambas rutas comprenden los mismos equipos aunque las direcciones IP mostradas no sean las mismas (corresponden a distintas interfaces de un mismo equipo). En el segundo caso la ruta de ida no coincidió con la de vuelta; las direcciones IP que pertenecen a igual salto corresponden a redes distintas (distintos equipos). 37

38 Escenario X. Distribución de carga. Objetivo: Observar, de ser posible el proceso de distribución de carga realizado por un router. Desarrollo: Sabiendo que el equipo que funciona como puerta de enlace de la red a la cual pertenece la PC L14 es capaz de realizar esta tarea, se generarán pings sucesivos (con la opción -t) desde la PC L14 hacia el servidor con la opción r 9 para registrar la ruta completa. Se pretende observar que la dirección IP del primer salto registrado varíe sucesivamente, dado que éste enviará paquetes en forma alternada por todas sus interfaces. Se repetira el procedimiento pero ahora utilizando el comando tracroute. Ejecución: De acuerdo con el desarrollo se obtuvo el siguiente resultado: [alumno@l14 alumno]$ ping -R PING from : 56(124) bytes of data. 64 bytes from : icmp_seq=1 ttl=251 time=51.5 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=2 ttl=251 time=97.1 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=3 ttl=251 time=76.3 ms RR: l14.fi.uba.ar ( ) 38

39 odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=4 ttl=251 time=83.0 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=5 ttl=251 time=49.6 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=6 ttl=251 time=144 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=7 ttl=251 time=109 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) 39

40 ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=8 ttl=251 time=27.5 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=9 ttl=251 time=26.1 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=10 ttl=251 time=20.2 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=11 ttl=251 time=49.4 ms RR: l14.fi.uba.ar ( ) odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) 64 bytes from : icmp_seq=12 ttl=251 time=20.5 ms RR: l14.fi.uba.ar ( )

41 odonto.uba.ar ( ) paps-ffilop.uba.ar ( ) ffilo1.filo.uba.ar ( ) ffilop-paps.uba.ar ( ) paps.uba.ar ( ) --- jaguar.filo.uba.ar ping statistics packets transmitted, 12 received, 0% loss, time 11107ms rtt min/avg/max/mdev = /62.930/ / ms Utilizando el commando traceroute se obtuvo: [alumno@l14 alumno]$ traceroute traceroute to, 30 hops max, 38 byte packets 1 fing1 ( ) ms ms ms ( ) ms * * 3 paps.uba.ar ( ) ms ms ms 4 ffilop-paps.uba.ar ( ) ms ms ms ms ms ms [alumno@l14 alumno]$ traceroute traceroute to, 30 hops max, 38 byte packets 1 fing1 ( ) ms ms ms ( ) ms ( ) ms ( ) ms 3 paps.uba.ar ( ) ms ms ms 4 ffilop-paps.uba.ar ( ) ms ms ms ms ms ms [alumno@l14 alumno]$ traceroute traceroute to, 30 hops max, 38 byte packets 1 fing1 ( ) ms ms ms ( ) ms ( ) ms ( ) ms 3 paps.uba.ar ( ) ms ms ms 4 ffilop-paps.uba.ar ( ) ms ms ms ms ms ms Conclusiones: Vemos que el primer salto desde la PC L14 hacia el servidor filo.uba.ar alterna consecutivamente entre 4 direcciones distintas en el caso del ping y 3 para el traceroute. Esto nos hace pensar que el equipo que funciona como puerta de enlace realiza la tarea de distribución de cargas; es decir que envía cada paquete por una interfaz de salida distinta mas allá de que alguna de ellas esté más congestionada que otra. 41