Practica 2 - Cuestion Tracert

Rutas de los paquetes en la red

En este ejercicio se pretende que el alumno descubra la ruta que siguen los paquetes desde un nodo origen a un nodo destino con la información proporcionada por la herramienta de trazado de rutas. Debido a las limitaciones que posee el comando tracert o traceroute desde la ubicación del laboratorio, vamos a hacer uso de servidores de rutas externos, desde los que calcularemos la ruta a nuestra máquina o a cualquier otro nodo mundial.

Accede a la web http://tracert.com/trace_exe.html . Desde este sitio podemos lanzar la petición de traza de rutas desde diferentes servidores de la red.

- Realiza una petición de traza desde Australia (red Telstra.net) hacia la dirección http://www.ua.es/ . ¿Qué ciudades recorren los paquetes hasta que llegan a la Universidad de Alicante? ¿Cuántos routers son atravesados por paquetes (aproximadamente)?

Las ciudades que atraviesan los paquetes son: Melbourne, Sydney, Hong Kong, Maine, alguna ciudad del centro de los EEUU, Hollywood (Florida), Madrid, Valencia y Alicante.

- Realiza una petición de traza desde Rusia hasta la web de http://www.sony.com/ . Indica la ubicación de los routers por los que pasan los paquetes hasta que llegan al servidor web. Para traducir las abreviaturas por los nombres de ciudades o aeropuertos ayúdate de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3 .Dibuja en el mapa de la Figura 11 el camino de los paquetes.

La ruta que siguen los paquetes es la siguiente: Novosibirsk, Moscú, Frankfurt, Amsterdam, Nueva York, Chicago, San Jose, Los Angeles, San Diego.

- Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina http://www.argentina.gov.ar/ desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino?

Las ciudades por las que pasa son: Paris, Galicia y Buenos Aires.

Compara los resultados si accedes desde Paris (Eu.org) al diario http://www.clarin.com/. Dibuja los caminos.

Las ciudades por las que pasa son: Paris, Washington, Atlanta, Miami y Buenos Aires.

Practica 2 - Apartado 5

Cuestión 5. Mensaje ICMP “Time Exceded”

Dentro del mensaje ICMP Time Exceeded se analizará el de código 0: Time to Live exceeded in Transit(11/0).

En primer lugar, inicia el monitor de red para capturar paquetes IP relacionados con la máquina del alumno y ejecuta el comando:

C:\> ping –i 1 –n 1 10.3.7.0

5.a. Finaliza la captura e indica máquina que envía el mensaje “ICMP Time to Live exceeded in Transit”… ¿Puedes saber su IP y su MAC? (identifica la máquina en la topología del anexo)

C:\>ping -i 1 -n 1 10.3.7.0

Como podemos ver, la máquina que nos envía el mensaje tiene dirección IP 172.20.43.230 y MAC 00 07 0e 8C 8C FF, que corresponde si lo consultamos en la tipología del anexo al router Cisco 1720.

Inicia de nuevo la captura y ejecuta a continuación el comando:

C:\> ping –i 2 –n 1 10.3.7.0

5.b. Finaliza la captura y determina qué máquina envía ahora el mensaje “ICMP Time to Live exceded in Transit”… Averigua y anota la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina? (identifica las máquinas en la topología del anexo)

En este caso la dirección IP origen del error es 10.4.2.5 correspondiente al serial 1 del router Cisco 2513 y la MAC 00 07 0e 8c 8c FF que corresponde al router anterior (Cisco 1720).

Como vemos no corresponden a la misma máquina.

Lo que sucede es que al expresar un tiempo de vida de 2 saltos en el ping (-i 2), el datagrama atraviesa el primer router y el segundo router devuelve el mensaje de error con su IP.

La MAC siempre es la indicada por el router más proximo a tu máquina que expresa la tipología de tu red, esto explica este fenómeno de no concordancia.

Por último, inicia de nuevo la captura y realiza un ping a la siguiente dirección:

C:\> ping –i 50 –n 1 10.3.7.12

5.c. Finaliza la captura y observa el mensaje de error ICMP que aparece en el monitor de red. ¿Qué tipo y código tiene asociado ese mensaje? ¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error? ¿En qué subred estaría ubicada?

El tipo asociado es 11 (Time to live exceed) y código 0 (Time to live exceed in transit).

Lo que sucede es que se está produciendo un bucle entre las máquinas 10.3.2.0 y 10.3.7.0 hasta que agotan el TTL y nos envía el router éste mensaje de error.

Estaría ubicada en la subred 10.3.0.0 situada entre esas máquinas.

5.d. Repite el ejercicio pero esta vez eleva el tiempo de vida del paquete a 220. ¿Observas el mismo resultado con la misma rapidez? ¿En cuál de los dos casos ha tardado más la respuesta del ping (en MSDOS)?

C:\>ping -i 220 -n 1 10.3.7.12

Haciendo ping a 10.3.7.12 con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.
Estadísticas de ping para 10.3.7.12:
Paquetes: enviados = 1, recibidos = 0, perdidos = 1 (100% perdidos),

En este caso sucede lo mismo que en el anterior solo que tarda más en aparecer el mensaje de error al hacer el ping con una TTL mayor.

Practica 2 - Apartado 4

Cuestión 4. Mensaje ICMP “Redirect”

Inicia el Monitor de Red. A continuación ejecutar los comandos:

C:\>route delete 10.4.2.1 (si ya ha sido borrada la ruta, avisa con un error)

C:\>ping -n 1 10.4.2.1

(antes de contestar debes confirmar que en MSDOS el resultado del Ping es correcto: paquetes enviados:1 , paquetes recibidos:1, sino debes repetir los dos comandos anteriores y el proceso de captura en el Monitor de Red)

En base a los paquetes capturados, filtra sólo los datagramas que contengan tu dirección IP y contesta a las siguientes preguntas:

4.a. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos…(tipo, código y tamaño)

Datagrama nº	Tipo y código ICMP	Tamaño del paquete ICMP	Origen IP	Destino IP
1	8 – 0 (echo request)	60 bytes	172.20.43.211	10.4.2.1
2	5 – 1 (redirect)	60 bytes	172.20.43.230	172.20.43.211
3	0 – 0 (echo reply)	60 bytes	10.4.2.1	172.20.43.211

4.b. Dibujar gráficamente el origen y destino de cada datagrama (como se ha realizado en la figura 7, pero incorporando el direccionamiento IP correcto de las máquinas involucradas).

Como se puede observar en la imagen de debajo, mi máquina envía por la puerta de enlace predeterminada (172.20.43.230) la petición de echo, después el router envía la misma petición al otro router (Cisco 1601) y un mensaje de error de direccionamiento hacia mi máquina que corregirá el error para la próxima vez. Finalmente el router Cisco 1601 devuelve la petición de echo hacia mi máquina.

¿Observas los mismos datagramas en el Monitor de Red con respecto a los se comentan en la explicación teórica del Redirect? ¿Por qué puede suceder esto?

El datagrama que no observo en mi máquina es la copia de la petición de echo que envía un router a otro. Esto sucede porque el switch direcciona los datagramas entre routers para que mi máquina no los vea.

4.d. ¿Las direcciones MAC e IP de todas las tramas capturadas con el Monitor de Red hacen referencia al mismo interfaz de red? Indica en qué casos la respuesta es afirmativa y en que casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

Datagrama nº	Tipo y código ICMP	Origen MAC	Origen IP	¿Representan al mismo interfaz?
1	8 – 1 (echo request)	00:0A:5E:76:FF:BC	172.20.43.211	SI
2	5 – 1 (redirect)	00:07:0E:8C:8C:FF	172.20.43.230	SI
3	0 – 0 (echo reply)	00:07:0E:8C:8C:FF	10.4.2.1	NO

4.e. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?

La puerta de enlace predeterminada de mi máquina (router Cisco 1720).

4.f. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect? ¿Transporta algún otro tipo de información extra?

Transporta un bloque que contiene la “dirección ip del nuevo router”, que es la dirección de salida correcta que debe tomar nuestra máquina para una situación igual en el futuro.

4.g. Observa los campos “Identificación”, “TTL” y “Cheksum” del datagrama que se envió originalmente. A continuación, analiza el contenido del mensaje Redirect. ¿Puedes encontrar la misma identificación dentro de los datos (no cabecera) del mensaje ICMP Redirect? ¿Qué ocurre con los campos TTL y Cheksum del datagrama transportado por el Redirect?

Los campos que varían son el TTL (de 128 en el echo request a 127 en el redirect) y el Cheksum.

Practica 2 - Apartado 3

Cuestión 3. Mensaje ICMP “Destination Unreachable”

Dentro del mensaje ICMP Destination Unreachable se analizará el de código 4: Fragmentation Needed and Don’t Fragment was Set (3/4).

En primer lugar ejecuta el comando:

C:\>route delete 10.3.7.0 ( si ya ha sido borrada la ruta, avisa con un error)

¿Porqué ejecutar este comando? En MS Windows, con route se modifican las tablas de encaminamiento de una máquina. Con la opción delete eliminamos un camino o ruta a la dirección especificada. Al eliminarlo, borramos también cualquier información asociada a esa dirección, incluida la información sobre errores previos al acceder a ese destino.

A continuación, poner en marcha el Monitor de Red en modo captura y ejecutar el comando ping:

C:\>ping -n 1 –l 1000 -f 10.3.7.0 (…la opción –f impide la fragmentación de los datagramas en la red)
En base a los paquetes capturados, indicar:

3.a. Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen? (identifica la máquina con la topología del anexo)

La dirección IP y MAC de la petición de echo corresponde a mi máquina (172.20.43.211 - 00-0A-5E-76-ff-bc). En cambio la dirección IP de respuesta es la de la máquina a la cual enviamos el ping (10.3.7.0 – Linux 1) y la MAC es la correspondiente a nuestra puerta de enlace (00:07:0e:8c:8c:ff – Router Cisco 1720).

3.b. ¿Qué máquina de la red envía el mensaje ICMP “Fragmentation Needed and Don’t Fragment was Set” (3/4)? (identifica la máquina con la topología del anexo)

Se trata del Router Cisco 2513.

Practica 2 - Apartado 2

Cuestión 2. Sobre la fragmentación de datagramas IP

Empleando el programa Monitor de Red de la misma forma que en la situación anterior, ejecutar:

C:\>ping –n 1 –l 2000 172.20.43.230 (…la opción –l especifica la cantidad de datos a enviar)

2.a. Filtra los paquetes en los que esté involucrada tu dirección IP. A continuación, describe el número total de fragmentos correspondientes al datagrama IP lanzado al medio, tanto en la petición de ping como en la respuesta. ¿Cómo están identificados en el Monitor de Red todos estos paquetes (ICMP, IP, HTTP, TCP…)? ¿qué aparece en la columna ‘info” del Monitor de Red?

Tenemos dos paquetes ICMP correspondientes a la petición (echo request) y a la respuesta (echo reply) respectivamente. Y otros dos con protocolo IP identificados como fragmented ip protocol, que corresponden a la petición y respuesta de ICMP realizada.

2.b. ¿En cuantos fragmentos se ha “dividido” el datagrama original?

Como indicamos anteriormente, se ha divido cada datagrama original en dos fragmentos. El primero de 1514 bytes y el segundo de 512 bytes.

2.c. Analiza la cabecera de cada datagrama IP de los paquetes relacionados con el “ping” anterior. Observa el campo “identificación”, “Flags” y “Fragment offset” de los datagramas. ¿Qué valor tienen en estos campos en los datagramas anteriores? Indica en la columna “dirección” si son de petición o respuesta. Muestra los datagramas en el orden de aparición del Monitor de Red.

Datagrama nº	Protocolo	Dirección	Flags	Frag. offset	Identificación
1	ICMP	172.20.43.230 (petición)	0×02 (more fragments)	0	0xc75a (51034)
2	IP	172.20.43.230 (petición)	0×00	1480	0xc75a (51034)
3	ICMP	172.20.43.200 (respuesta)	0×02(more fragments)	0	0×0036 (54)
4	IP	172.20.43.200 (respuesta)	0×00	1480	0×0036 (54)

2.d. ¿Qué ocurre en la visualización de los fragmentos de datagramas si introduces un filtro para ver únicamente paquetes de “icmp” en el Monitor de Red? ¿qué fragmentos visualizas ahora? ¿por qué puede suceder esto?

Introduciendo “icmp” en el campo filter solo visualizamos los dos paquetes correspondientes al primer fragmento de la petición y de la respuesta respectivamente.

Esto es debido a que estos primeros fragmentos son los que poseen la cabecera ICMP. Como los siguientes fragmentos no la poseen nos aparecen como protocolo IP.

2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?

El campo “Identificación” indica cada fragmento al datagrama que le corresponde, el campo “Flags” nos indica el número de fragmentos que nos faltan para completar el datagrama y la posición en la que se encuentra el mismo.

Por último, el campo “Fragment ofsset” identifica en el reensamblado la posición donde debe colocar ese fragmento para recomponer el datagrama original.

2.f. En función de los datos anteriores, indica el valor de la MTU de la red.

El valor de la MTU de la red es 1500 bytes. Es el valor del tamaño máximo de los datagramas que circulan en la red y con el que fragmenta los mismos.

2.g. Repite el ejercicio lazando una petición de ping con un mayor número de datos y al destino “.195”:

C:\>ping –n 1 –l 3000 172.20.43.195

Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):

Datagrama nº	Protocolo	Dirección	Flags	Frag. offset	Identificación
1	ICMP	172.20.43.195 (petición)	0×02 (more fragments)	0	0×0344 (830)
2	IP	172.20.43.195 (petición)	0×02(more fragments)	1480	0×0344 (830)
3	IP	172.20.43.195 (petición)	0×00	2960	0×0344 (830)
4	ICMP	172.20.43.200 (respuesta)	0×02(more fragments)	0	0×0092 (146)
5	IP	172.20.43.200 (respuesta)	0×02(more fragments)	1480	0×0092 (146)
6	IP	172.20.43.200 (respuesta)	0×00	2960	0×0092 (146)

La diferencia radica en que al enviar en este caso un paquete de 3000 bytes (más las cabeceras) hay que fragmentar el datagrama en 3 partes en vez de dos.

2.h. A continuación, se pretende observar que los datagramas pueden fragmentarse en unidades más pequeñas si tienen que atravesar redes en las que la MTU es menor a la red inicial en la que se lanzaron los paquetes originales. Inicia el Monitor de Red y captura los paquetes IP relacionados con el siguiente comando:

C:\>ping –n 1 –l 1600 10.3.7.0

(antes de contestar debes confirmar que en MSDOS el resultado del ping es correcto: paquetes enviados:1 , paquetes recibidos:1)

Datagrama nº	Protocolo	Dirección	Flags	Frag. offset	Identificación
1	ICMP	10.3.7.0 (petición)	0×02 (more fragments)	0	0xb37b (45947)
2	IP	10.3.7.0 (petición)	0×00	1480	0xb37b (45947)
3	ICMP	172.20.43.200 (respuesta)	0×02(more fragments)	0	0×00a1 (161)
4	IP	172.20.43.200 (respuesta)	0×02(more fragments)	480	0×00a1 (161)
5	IP	172.20.43.200 (respuesta)	0×02(more fragments)	960	0×00a1 (161)
6	IP	172.20.43.200 (respuesta)	0×00	1440	0×00a1 (161)

2.i. En relación a los datos de la pregunta 2.g. obtenidos del Monitor de Red, contesta:

¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)?

Indica en que subred del laboratorio el número de fragmentos que circulan por el medio es el mismo tanto en la petición como en la respuesta. Deduce en que otra subred no sucede esto. Señala (en la topología del laboratorio adjunta), la MTU de cada una de las subredes por las que circulan los datagramas que salen de tu máquina hacia la dirección 10.3.7.0. ¿Cuántas subredes se atraviesan?

Observamos más fragmentos IP de vuelta que de ida debido a que la red que nos manda la respuesta ICMP posee un MTU menor que desde la que enviamos la petición, por tanto nuestro datagrama enviado vuelve más fragmentado.

Como vemos en la siguiente imagen, en las dos primeras redes que atravesamos (línea verde) tenemos un MTU de 1500 por tanto en ese tramo el número de fragmentos de ida y de vuelta es el mismo para la petición y para la respuesta. Pero en la última red que atravesamos (linux1) al poseer un MTU de 500 bytes poseeremos más fragmentos a la vuelta que a la ida, que es lo que nos ocurre en el ping hecho en el último apartado.

Se puede decir entonces que el MTU de la red es 500 bytes (el más pequeño de todos es el que condiciona los demás).

Practica 2 - Apartado 1

Cuestión 1. Sobre mensajes ICMP del “Ping”

Inicia el programa Monitor de Red en modo captura. A continuación ejecuta el comando:

C:\>ping –n 1 172.20.43.230 (…la opción –n especifica el número de peticiones “echo” que se lanzan al medio)

Detener la captura en el Monitor de Red (filtrar únicamente tramas del alumno) y visualizar los paquetes capturados. En base a los paquetes capturados determinar:

1.a. ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)

Al hacer este ping estamos enviando al router Cisco 1720 un paquete ICMP.

Los paquetes capturados son dos. Petición de echo (echo request – Tipo 8 Código 0) que corresponde al ping y respuesta de echo (echo reply – Tipo 0 Código 0) que corresponde a la respuesta de nuestro ping.

1.b. Justifica la procedencia de cada dirección MAC e IP. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP “Replay” hacen referencia a la misma máquina o interfaz de red?

Las direcciones IP y MAC origen del mensaje de respuesta echo reply corresponden a la misma máquina, el router Cisco 1720 al que le enviamos el ping ( con IP 172.20.43.230 y MAC 00:07:0E:8C:8C:FF).

Esta coincidencia es debida a que le hemos enviado el ping a una máquina de nuestra propia red. En el caso de mandar un ping hacia fuera la MAC no coincidiría con la IP de respuesta ya que la siempre viene indicada por nuestra puerta de enlace.

1.c. Justifica la longitud de los paquetes IP. ¿Cuál es el tamaño total del ICMP? ¿Por qué tienen esa longitud?¿Cuántos datos se han transportado en el mensaje “ping”? Dibuja la encapsulación del protocolo ICMP.

La longitud de los paquetes IP enviados es de 60 bytes de los cuales corresponden 20 a la cabecera IP, 8 a la cabecera ICMP y 32 a los datos del ping.