Práctica 2. Cuestión 5. Mensaje ICMP “Time Exceeded”

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)

Su IP es 142.20.43.230 y su Mac 00:07:0e:8c:8c:ff. Observando el esquema de la topología de red del laboratorio lo i

dentificamos como 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)

La IP y MAC origen de este mensaje de error son 10.4.2.5 y 00:07:0e:8c:8c:ff respectivamente. No pertenecen a la misma máquina, la MAC es la de mi puerta de enlace que es el Router Cisco 1720 y la dirección IP pertenece a la máquina Cisco 2513. No conozco la Mac de Cisco 2513 porque está fuera de mi red local.

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 mensaje de error tiene asociado tipo 11 (Time to live exceed) y código 0 (Time to live exceed in transit).

Que no se ha encontrado la máquina que pertenece a esa IP en el tiempo indicado (50 saltos). 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.

Práctica 2. 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

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)

Nº Datagrama	Tipo y código ICMP	Tamaño del paquete ICMP	Origen IP	Destino IP
1	8-0 (echo request)	32 bytes	172.20.43.209	10.4.2.1
2	5-1 (redirect)	bytes	172.20.43.230	172.20.43.209
3	0-0 (echo reply)	32 bytes	10.4.2.1	172.20.43.209

4.b.¿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.

Nº Datagrama	Tipo y código ICMP	Origen MAC	Origen IP	¿Representan al mismo interfaz?
1	8-0 (echo request)	00:0a:5e:76:90:9d	172.20.43.209	Si
2	5-1 (redirect)	00:07:0e:8c:8c:ff	172.20.43.230	Si
3	0-0 (echo reply)	00:d0:ba:e0:6a:3d	10.4.2.1	No

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

Cisco 1720, cuya IP es 172.20.43.230. Este router nos informa de que el ping no ha podido llegar a destino, pues el no enlaza con la máquina destino. Este router es la puerta de enlace de mi máquina.

4.d.¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect?

El dato más importante que ofrece es la nueva puerta de enlace (Gateway adress). En nuestro caso es la 172.20.43.231 que corresponde al Cisco 1601. Es la dirección de salida correcta que debe tomar nuestra máquina para una situación igual en el futuro.

4.e.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?

El paquete Redirect por sí solo no coincide con el original, sin embargo, en este paquete de error, está contenido el mensaje que produjo el error. Por tanto el identificador si que coincide, sin embargo TTL (time to live) pasa de 128 a 127 porque el paquete ha dado un salto y por tanto su tiempo de vida disminuye en una unidad. Por último el Cheksum tampoco coincide, siendo en un caso 0xf05b y en el segundo pone que 0xf05b es incorrecto y que debería ser 0x9aff.

Práctica 2. 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)

172.20.43.209/ 00:0a:5e:76:90:9d Nuestro equipo

10.3.7.0/ 00:07:0e:8c:8c:ff Linux 1

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)

Corresponde al Router Cisco 2513 (10.4.2.5).

Práctica 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?

Tenemos dos fragmentos, uno el ICMP y otro el IP fragment. Como el ping tiene 2000 bytes entre cabecera y datos y Ethernet tan sólo soporta 1500 bytes tiene que fragmentar el datagrama.

El primer fragmento ICMP tiene 1500 bytes y el segundo IP tiene 548 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-36	ICMP	172.20.43.230 (petición)	0x01(more fragments)	0	0x37ea (14314)
2-37	IP	172.20.43.230 (petición)	0x00	1480	0x37ea (14314)
3-38	ICMP	172.20.43.209 (respuesta)	0x01(more fragments)	0	0x37ea (14314)
4-39	IP	172.20.43.209 (respuesta)	0x00	1480	0x37ea (14314)

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?

En el campo filter ponemos ip.addr==172.20.43.209 && icmp para filtrar lo que entra y sale de nuestra máquina y para quedarnos con los paquetes ICMP.

Sólo se visualizan los paquetes ICMP y por tanto no ves los 548 bytes correspondientes al IP fragment.

Esto es debido a que los IP fragment no conservan la cabecera ICMP sólo la 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.

El campo Offset indica a partir de dónde se cogen los datos. Esta información será útil para el posterior reensamblado del mensaje. Offset sólo será ‘0’ en el primer fragmento.

2.f. 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)

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

Aparecen desordenados porque el router los ha procesado y nos manda primero el últimpo que le ha llegado

Datagrama nº	Protocolo	Dirección	Flags	Frag. Offset	Identificación
1	ICMP	Petición	0x01(more fragments)	0	0x411b (16667)
2	IP	Petición	0x00	1480	0x411b (16667)
3	IP	Respuesta	0x00	1440	0x009e (158)
4	IP	Respuesta	0x01(more fragments)	960	0x009e (158)
5	IP	Respuesta	0x01(more fragments)	480	0x009e (158)
6	ICMP	Respuesta	0x01(more fragments)	0	0x009e (158)