Trabajo Práctico Nº: 1. Tema: ICMP - Ping

Transcripción

1 Facultad de Ingeniería Trabajo Práctico Nº: 1 Tema: ICMP - Ping (2º cuatrimestre 2007) Docentes: Ing. Marcelo Utard, Ing. Pablo Ronco Alumnos: Bianchi Mariano Pasqualini Adriano Ricci Alejandro Soto Fernando 74824

2 Distintos casos a analizar en el Trabajo Práctico: Caso 1: Interacción de PING con ARP Caso 2: Interacción de PING con ARP a un destino fuera de la red Caso 3: Uso del ping para ver una Fragmentación IP Caso 4: Uso del ping para Descubrimiento del MTU usando el bit DF Caso 5: Ping hacia un destino no conectado Caso 6: Ping hacia un destino no conectado, que durante el ping se conecta Caso 7: Ping desde routers Cisco Caso 8: Uso del comando ping desde Linux Caso 9: Uso del comando ping para la medición del Bit Rate 2

3 Para realizar las pruebas armamos la siguiente maqueta Ethernet / / Router Router /16 Ethernet La maqueta consiste en dos routers Cisco, conectados back-to-back por medio de un cable DTE-DCE para simular un enlace WAN. Cada uno de los routers tiene una interfaz ethernet las cuales están conectadas a las respectivas LAN. El direccionamiento IP es el indicado en la figura, con la particularidad que la interfaz ethernet del Router2 tiene dos direcciones IP (en el router2 se configura la segunda ip como secundaria). Vamos a trabajar desde el host , donde está instalado el software para realizar el análisis de los datos (Ethereal). El segundo host va a tener configurado 3

4 la IP en algunos de los casos y la en otros (pero no ambas). El tercer host se encuentra en otra red, la cual se alcanza a través del enlace WAN, y tiene la dirección de IP Para mostrar el caso 1), realizamos un ping hacia el host Vemos en la captura el ARP request enviado desde la , y como es de esperar la dirección MAC destino es la dirección de Broadcast. Seguidamente se puede observar la respuesta desde hacia la.32, informando su dirección física. Recien luego de recibir la respuesta ARP, es que se envía el ICMP echo request. Para el echo reply vemos que el host.33, no realiza una nueva consulta ARP, sino que aprendió la dirección fisica del.32 con la ARP request enviado al principio por el.32. 4

5 En la siguiente captura podemos observar que los echo request y reply se transmiten directamente entre los dos host (ver dirección física) sin pasar por el router (que está configurado como default gateway en ambos hosts). Esto es de esperar debido a que ambos hosts se encuentran en el mismo segmento de LAN. Distinto sería el caso si el host destino tuviese configurada la IP , por más que esté conectado al mismo switch, pertenece a otra red, y entonces los echo request-reply pasarían por el router2. 5

6 Para mostrar el caso 2), realizamos un ping a un host ubicado en otra LAN (la ). Previamente borramos la tabla de ARP. Y vemos que la consulta ARP (#3) es sobre la dirección física del default gateway ( ). Por otro lado en el echo request (#9) observamos cómo la dirección MAC destino es la del default gateway y la dirección IP destino es la del host de destino (ver detalle). 6

7 Para mostrar el caso 3), y observar el mecanismo de fragmentación, la prueba es un ping de tamaño bytes hacia el host : En las capturas que se muestran a continuación se puede observar claramente que es necesario fragmentar el datagrama IP para poder enviarlo a través de la LAN. Se puede apreciar el flag de more fragments en el primer datagrama IP. Dicho flag va a estar presente en todos los fragmentos menos en el último. Lo mismo ocurre con la respuesta echo-reply desde host de destino. Otro detalle que podemos observar es el valor del campo fragment offset, el cual se puede ver cómo va variando para cada uno de los fragmentos y es indispensable para su reensamblado. Por último notar que el echo reply es enviado luego que el destino ha recibido el último de los fragmentos (igual en la captura sólo vemos los fragmentos enviados que forman el echo request, y luego los recibidos que forman echo reply). 7

8 8

9 9

10 10

11 Para el caso 4), configuramos el MTU para el enlace serial entre los dos routers en 64 bytes. Y hacemos un ping de 128 bytes hacia el host con el bit don t fragment seteado. En la ventana de consola vemos la respuesta desde el router2 que es necesario fragmentar. En la captura vemos que lo que envía el router2 es un ICMP destination unreacheable indicando esto mismo. 11

12 12

13 13

14 Si vamos variando la longitud del campo de datos en el echo request, dejando seteado el don t fragment observamos lo siguiente: Vemos que cuando el campo de datos es mayor que 36 bytes es necesario fragmentar, lo cual es lógico debido a que : 36 bytes de datos + 20 bytes del header IP + 8 bytes del header ICMP = 64 bytes, valor al cual está configurado el MTU del enlace serial. 14

15 Por último, si hacemos un ping de 128 bytes sin especificar don t fragment, hacia el host y analizamos los paquetes en dicho host de destino, vamos a observar como el echo request llega fragmentado y en cambio el echo reply es enviado dentro de un sólo datagrama IP sin fragmentación alguna. Esto último es de esperar debido a que entre el host y el router1 el MTU es de 1500 bytes. 15

16 Caso 5 Ping a un destino desconectado Escenario 1: Tanto el origen como el destino tienen una conexión de area local, el origen conoce la direccion MAC del destino. El destino se encontraba desconectado inicialmente, la captura de tramas se realiza utilizando ethereal en la maquina fuente. Resultados esperables: Se espera observar solo los ICMP echo request. 16

17 Escenario 2: Tanto el origen como el destino tienen una conexión de area local, el origen no conoce la direccion MAC del destino, por lo tanto cada intento de enviar un ICMP echo request se transforma en un intento de resolver la direccion MAC destino mediante una solicitud ARP. El destino se encontraba desconectado inicialmente, la captura de tramas se realiza utilizando ethereal en la maquina fuente. Resultados esperables: Como finalmente los datagramas IP se envían sobre Ethernet, y el próximo salto es directamente la maquina destino (esta pertenece a la misma LAN), la imposibilidad de mapear la dirección IP en MAC inhibe la salida de datagramas IP, y la necesidad de enviarlos dispara en cada oportunidad una solicitud ARP. 17

18 18

19 Caso 6: PING a un destino inicialmente desconectado, luego de la respuesta de tiempo agotado se conectará. Escenario : Ambas maquinas tienen sus interfaces activas y se encuentran en la misma red, corriendo Windows XP. El destino está inicialmente desconectado. Tareas: 1)Se hará ping desde la consola DOS hacia la máquina destino, mientras se registra el tráfico con el ethereal. 2) Sin desactivar el ethereal se conectará el cable de red. Resultados esperables: Mientras esté el destino desconectado esperamos observar las consultas ARP sin respuesta. Luego de conectar el cable de la maquina destino se espera ver además la respuesta ARP, y luego los ICMP echo request-reply. Un detalle que no esperábamos observar, es que al conectar el cable, el host recién conectado (el ) envía varios ARP gratuitos. (ARP gratuito es cuando un host envía un ARP request buscando quien tiene su propia dirección IP). Y el host aprovecha el primero de estos ARP gratuitos para conocer la dirección física del destino. Luego, cuando el destino quiere responder el echo request, antes del echo reply realiza una consulta ARP preguntando la dirección física del origen ( ). Una vez recibida la respuesta ARP (#22 en la captura), sí se observan los pares echo request y echo reply. En la captura se ven tres ARP gratuitos, los dos primeros muy seguidos (ver el tiempo) y el tercero 1 seg después del 2do ARP gratuito. 19

20 20

21 Caso7: Ping desde routers Cisco - Maqueta - Escenario Nos conectamos al router Cisco a través de un cable consola o por medio del protocolo telnet. Nos logueamos en el modo privilegiado del router. - Tareas Realizar el comando ping desde de un router Cisco y entender los resultados y parámetros. - Capturas Si tipeamos el comando ping sin ningún argumento nos aparece un dialogo interactivo para especificar sintaxis apropiadas. Ejemplo: R3NOC#ping Protocol [ip]: Target IP address: Translating " server ( ) [OK] Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: 21

22 Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 196/197/200 ms R3NOC# Descripción de los Campos: Field Protocol [ip]: Target IP address: Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Description Prompts for a supported protocol. Enter appletalk, clns, ip, novell, apollo, vines, decnet, or xns. The default is ip. Prompts for the IP address or host name of the destination node you plan to ping. If you have specified a supported protocol other than IP, enter an appropriate address for that protocol here. The default is none. Number of ping packets that are sent to the destination address. The default is 5. Size of the ping packet (in bytes). Default: 100 bytes. Timeout interval. Default: 2 (seconds). The ping is declared successful only if the ECHO REPLY packet is received before this time interval. Specifies whether or not a series of additional commands appears. The default is no. The interface or IP address of the router to use as a source address for the probes. The router normally picks the IP address of the outbound interface to use. The interface can also be mentioned, but with the correct syntax as shown here: Source address or interface: ethernet 0 Note: This is a partial output of the extended ping command. The interface cannot be written as e0. Specifies the Type of Service (ToS). The requested ToS is placed in each probe, but there is no guarantee that all routers process the ToS. It is the Internet service's quality selection. The default is 0. Specifies whether or not the Don't Fragment (DF) bit is to be set on the ping packet. If yes is specified, the Don't Fragment option does not allow this packet to be fragmented when it has to go through a segment with a smaller maximum transmission unit (MTU), and you 22

23 Validate reply data? [no]: Data pattern [0xABCD] will receive an error message from the device that wanted to fragment the packet. This is useful for determining the smallest MTU in the path to a destination. The default is no. Specifies whether or not to validate the reply data. The default is no. Specifies the data pattern. Different data patterns are used to troubleshoot framing errors and clocking problems on serial lines. The default is [0xABCD]. IP header options. This prompt offers more than one option to be selected. They are: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]:!!!!! Success rate is 100 percent round-trip min/avg/max = Verbose is automatically selected along with any other option. Record is a very useful option because it displays the address(es) of the hops (up to nine) the packet goes through. Loose allows you to influence the path by specifying the address(es) of the hop(s) you want the packet to go through. Strict is used to specify the hop(s) that you want the packet to go through, but no other hop(s) are allowed to be visited. Timestamp is used to measure roundtrip time to particular hosts. The difference between using the Record option of this command and using the traceroute command is that, the Record option of this command not only informs you of the hops that the echo request (ping) went through to get to the destination, but it also informs you of the hops it visited on the return path. With the traceroute command, you do not get information about the path that the echo reply takes. The traceroute command issues prompts for the required fields. Note that the traceroute command places the requested options in each probe. However, there is no guarantee that all routers (or end nodes) process the options. The default is none. Allows you to vary the sizes of the echo packets that are sent. This is used to determine the minimum sizes of the MTUs configured on the nodes along the path to the destination address. Performance problems caused by packet fragmentation is thus reduced. The default is no. Each exclaimation point (!) denotes receipt of a reply. A period (.) denotes that the network server timed out while waiting for a reply. Refer to ping characters for a description of the remaining characters. Percentage of packets successfully echoed back to the router. Anything less than 80 percent is usually considered problematic. Round-trip travel time intervals for the protocol echo packets, including minimum/average/maximum (in milliseconds). 23

24 1/2/4 ms Comando Ping Ip Para testear la conectividad de una red ip se puede usar el comando ping ip en el modo exec privilegiado. ping ip {host-name ip-address} [data [hex-data-pattern] df-bit repeat [repeat-count] size [datagram-size] [source {source-address source-interface} ] [timeout seconds] [validate][verbose] Caracteres del print test 24

25 Caso 8: Uso del comando ping desde Linux ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.219 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.187 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.178 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.167 ms 64 bytes from : icmp_seq=5 ttl=64 time=0.168 ms 64 bytes from : icmp_seq=6 ttl=64 time=0.186 ms ping statistics packets transmitted, 6 received, 0% packet loss, time 4999ms rtt min/avg/max/mdev = 0.167/0.184/0.219/0.019 ms nachosama@nkun:/$ Lo que se verá en la pantalla es un informe mostrando el tamaño en bytes de los paquetes que se están enviando y el tiempo que demoran éstos en retornar. Al final del test se muestra un resumen con las estadísticas de la prueba. El procedimiento ping se invoca de la misma manera tanto en Windows como en Linux aunque difiere en la gramática de sus argumentos. Opciones en Linux: -c count. Para después de enviar (y recibir) count paquetes ECHO_RESPONSE. -d Establece la opción SO_DEBUG en el socket en uso. -f Envío masivo de pings. Envía paquetes a la misma velocidad a la que regresan o cien veces por segundo, lo que sea mayor. Por cada ECHO_REQUEST enviado se escribe un ".", mientras que por cada ECHO_REPLY recibido se escribe un backspace. Esto proporciona una muestra rápida de cuántos paquetes se están perdiendo. Sólo el super-usuario puede utilizar esta opción. Esto puede resultar muy peligroso en una red y debe usarse con precaución. -i wait Espera wait segundos entre el envío de cada paquete. Por defecto se espera un segundo entre el envío de los paquetes. Esta opción es incompatible con la opción -f. -l preload Si se especifica preload, ping envía tantos paquetes tan rápido como le sea posible antes de volver a su comportamiento normal. Sólo el super-usuario puede usar esta opción. -n Sólo salida numérica. No se realiza ningún intento de buscar 25

26 nombres simbólicos para las direcciones del servidor. -p pattern Se pueden especificar un total de 16 bytes "pad" para completar el paquete que se envía. Esto resulta útil para el diagnóstico de problemas de red relacionados con los datos. Por ejemplo, -p ff hará que el paquete enviado se complete en su totalidad con unos. -q Salida muda. No se muestra ninguna información excepto las líneas de resumen al comenzar y al terminar. -R Registro de ruta. Incluye la opción RECORD_ROUTE en el paquete ECHO_REQUEST y muestra el buffer de ruta sobre los paquetes devueltos. Nótese que la cabecera IP tan sólo tiene tamaño suficiente para nueve rutas de este tipo. Muchos servidores ignoran y descartan esta opción. -r Pasa por alto las tablas de encaminamiento y envía datos directamente a un ordenador en una red conectada a la propia. Si el ordenador receptor no está en una red con conexión directa, se devuelve un error. Esta opción se puede usar para hacer ping a un ordenador local a través de un interfaz que carezca de una ruta que pase por él (por ejemplo, después de que el interfaz haya sido anulado por routed(8).) -s packetsize Especifica el número de bytes de datos que se van a enviar. La cantidad por defecto es 56, que pasan a ser 64 bytes de datos ICMP cuando se combinan con los 8 bytes de los datos de la cabecera ICMP. -v Aumenta la longitud de la información del programa en pantalla. Se listan los paquetes ICMP que no sean ECHO_RESPONSE que se reciben. 26

27 Caso 9: Uso del comando ping para la medición del Bit Rate - Maqueta - Escenario1: Vinculo punto a punto sin dispositivos intermedios y sin carga Tenemos un router conectado por un enlace serial de 2Mbps a un carrier que nos brinda el acceso a Inet. Supondremos que detrás del nuestro router no hay carga, o sea no hay una red lan generando trafico. Nosotros estamos conectados al router por cable consola o telnet. Con el programa ping es posible calcular la capacidad del vínculo serial. Para hacer el cálculo hay que tener en cuenta que el round trip time (RTT) es aproximadamente: RTT= TQsender + Ti + Tp(ida) + TQreceiver + Ti + Tp(vuelta) Donde TQ es el tiempo en cola en la interfaz de salida, Tp es el tiempo de propagación, y el Ti el tiempo de inserción. El Tiempo de cpu ha sido despreciado considerando que el router es muy rápido en procesamiento. El Ti último puede escribirse como: L 8 T i = R Donde L es el largo del mensaje (medido en bytes), R la capacidad del vínculo medida en bits por segundo. Ahora bien, si se toman dos muestras de RTT con L diferente pero sobre el mismo vínculo, y desprecian los tiempos en cola o se los considera constantes, la diferencia entre ambos será: 27

28 RTT= 2. Ti + 2. Tp Pero dado que el vínculo es el mismo: Tp 0 y. Entonces: RTT 2. Ti Así se obtiene: L R = 16 RTT Que permite calcular la capacidad del vínculo en función de la diferencia en el tamaño de los mensajes y la diferencia en el RTT. La formula anterior es valida en un caso donde tenemos un enlace punto a punto sin dispositivos intermedios y sin trafico (sin carga). En este modelo es valido considerar que el tiempo en cola es constante. Ejecución del ping Luego de levantar el vínculo serial, se ejecuta ping l 100 n 10 w Donde l especifica el tamaño del mensaje, -n la cantidad de pings a enviar, -w el tiempo de espera antes de dar por perdido la respuesta, medida en milisegundos. Haciendo ping a con 100 bytes de datos: Respuesta desde : bytes=100 tiempo=1193ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Respuesta desde : bytes=100 tiempo=1204ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Respuesta desde : bytes=100 tiempo=1194ms TTL=64 Estadísticas de ping para : Paquetes: enviados = 10, recibidos = 10, perdidos = 0 (0% perdidos), A Tiempos continuación aproximados se ejecuta de ping ida l y 1000 vuelta n en 10 milisegundos: w Mínimo = 1193ms, Máximo = 1204ms, Media = 1194ms 28

29 Haciendo ping a con 1000 bytes de datos: Respuesta desde : bytes=1000 tiempo=8699ms TTL=64 Respuesta desde : bytes=1000 tiempo=8693ms TTL=64 Respuesta desde : bytes=1000 tiempo=8703ms TTL=64 Respuesta desde : bytes=1000 tiempo=8698ms TTL=64 Respuesta desde : bytes=1000 tiempo=8703ms TTL=64 Respuesta desde : bytes=1000 tiempo=8703ms TTL=64 Respuesta desde : bytes=1000 tiempo=8698ms TTL=64 Respuesta desde : bytes=1000 tiempo=8693ms TTL=64 Respuesta desde : bytes=1000 tiempo=8793ms TTL=64 Respuesta desde : bytes=1000 tiempo=8698ms TTL=64 Estadísticas de ping para : Paquetes: enviados = 10, recibidos = 10, perdidos = 0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 8693ms, Máximo = 8793ms, Media = 8708ms Cálculo de la capacidad Para hacer el cálculo de utiliza para el RTT las medias proporcionadas por el ping. 16 L bit R = = = bps 1916bps RTT 8708 ms 1194 ms Conclusiones Obtenemos una capacidad de alrededor de 1916 bps, un 2% menor a la capacidad nominal de conexión del enlace serial. Esta diferencia se debe a que la velocidad de transmisión nominal no es la efectiva, se debe tener en cuenta la característica de señal / ruido de la línea, también se debe tener en cuenta que el cálculo aplicado es una aproximación. 29

30 - Escenario2: Vinculo punto a punto con dispositivos intermedios y sin carga Si tenemos etapas intermediarias, como ser routers o switches en el medio, que es lo típico; estos hacen store & forward. Una forma de analizar este enlace es reemplazarlo por un enlace punto a punto equivalente con un bit rate equivalente o ancho de banda disponible. En este caso aplicando la formula anterior estaríamos calculando un promedio de los bit rates de cada uno de los enlaces. - Escenario3: Vinculo punto a punto y con carga Cuando un vinculo no tiene carga generalmente el tiempo de retardo es el mínimo, el ancho de banda disponible es casi el máximo posible entre esos dos puntos y la perdida de paquetes es casi nula. Si empezamos a cargar la red el ancho de banda disponible empieza a bajar. El retardo aumenta en forma casi proporcional al aumento de la carga. Pero el packet loss se va a mantener muy bajo. Si sigue aumentando la carga llegaremos al punto donde la cola del router empieza a desbordar. En este punto el ancho de banda disponible se estrangula. Es importante entonces el sistema de manejo de colas que estemos empleando. Una forma de medir el tiempo en cola es realizar el mismo procedimiento anterior tirando un par de pings de distinto tamaño como en el caso anterior; calculando así un Rdisponible minuto a minuto. 30

31 Apéndice: El "ping" es una herramienta que se utiliza para probar conectividad. Además colecta estadisticas de performance (Ej el round trip time y el mumero de veces que el servidor remoto falla en responder). Cada vez que el mensaje ICMP echo reply es recibido se muestra el sequence number, el cual se incrementa luego de cada transmisión, round trip time medido en (ms), y el timestamp value que indica la hora de la transmisión. En este caso hay solo un sistema intermedio (IS) (Ej. IP router). Dos clases de mensajes pueden verse ECHO request (sent by the client) y ECHO reply (the response by the server). Los paquetes ICMP son encapsulados en IP para su transmisión por la red. Mensaje ICMP (rosa) y HEADER IP Bit 0 7 Bit 8-15 Bit Bit Version/IHL Type of service Length Identification flags et offset Time To Live(TTL) Protocol CRC Source IP address Destination IP address Type of message Code CRC Quench Data (optional) 31

32 Formato del mensaje Echo request La respuesta al echo request es un mensage ICMP el cual se espera ser recibido en el echo reply. El host debe responder a todos los echo requests con un echo reply conteniendo la misma data reivida en el mensage request Type = 8 Code = 0 Header Checksum Identifier Data ::: Sequence Number El tipo debe ser seteado en 8 El codigo debe ser seteado en 0 El identificador y secuencia pueden ser usados por el cliente para corresponder la respuesta con el pedido que la causa.. Echo reply El echo reply is un mensage ICMP generado en respuesta al echo request y es mandatorio para todos los host y routers a menos de espesificar lo contrario Type = 0 Code = 0 Header Checksum Identifier Data ::: Sequence Number El tipo debe ser seteado en 8 El codigo debe ser seteado en 0 El identificador y secuencia pueden ser usados por el cliente para determinar cual echo requests esta asociado con el echo replies. Los datos recividos por el echo request deben estar enteramente contenidos en el echo reply. 32