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

Apartado a) Finaliza la captura e indica qué máquina 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)
La máquina es la puerta de enlace predeterminada (Cisco 1720), según podemos ver en la captura de pantalla.
IP --> 172.20.43.230
MAC -->00:07:0e:8c:8c:ff

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

c:\>ping -i 2 -n 1 10.3.7.0

Apartado b) Finaliza la captura y determina qué máquina envía ahora el mensaje "ICMP Time to Live exceeded 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)
Ahora el mensaje lo envía la máquina Cisco 2513.
IP --> 10.4.2.5
MAC --> 00:07:0e:8c:8c:ff
Ambas direcciones no pertenecen a la misma máquina. La IP es la del Cisco 2513 y la MAC es la de la puerta de enlace predeterminada.

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

Apartado 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?
Tipo --> 11
Código --> 0
Lo que ocurre es que, en el trayecto hacia el destino, el TTL del datagrama llega a 0 y, por tanto, la trama se destruye. En realidad lo que pasa es que esa máquina destino no existe y el paquete va saltanto entre routers (en este caso, los Linux) buscándola hasta que muere.
La subred sería la que está ubicada entre el Linux 1 y el Linux 2.

Apartado 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)?
No. Tarda más en el caso en que el ping tiene un TTL de 160 saltos.

Cuestión 4. Mensaje ICMP "Redirect"

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

c:\>route delete 10.4.2.1

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:
Apartado a) ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos... (tipo, código y tamaño)

Datagrama número	Tipo ICMP	Código ICMP	Tamaño del paquete ICMP	Origen IP	Destino IP
1	Tipo 8	Código 0	32 bytes de datos (74 del paquete total	172.20.43.218	10.4.2.1
2	Tipo 5	Código 1	28 bytes de datos (70 del paquete total	172.20.43.230	172.20.42.218
3	Tipo 0	Código 0	32 bytes de datos (74 del paquete total	10.4.2.1	172.20.43.218

Apartado 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).



Apartado c) ¿Observas los mismos datagramas en el Monitor de Red con respecto a los que se comentan en la explicación teórica del Redirect? ¿Por qué puede suceder esto?
No. Aparecen todos excepto el que se envía de router a router. Esto sucede porque en la red de este laboratorio hay un switch cuya tarea, además de unir los diferentes elementos de red, es la de filtrar pr MAC, con lo cual no podemos ver ese datagrama.

Apartado 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 qué casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

Datagrama número	Tipo ICMP	Código ICMP	Origen Mac	Origen IP	¿Representan al mismo interfaz?
1	Tipo 8	Código 0	00:0a:5e:76:8c:4c	172.20.43.218	Sí
2	Tipo 5	Código 1	00:07:0e:8c:8c:ff	172.20.43.230	Sí
3	Tipo 0	Código 0	00:d0:ba:e0:6a:3d	10.4.2.1	No

Para saber si las IP estaban asociadas a las MAC hemos utilizado tanto el comando ipconfig como el comando arp -a y así poder hacer las asociaciones. A continuación vemos las imágenes obtenidas:


Apartado e) ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?
El Cisco 1720, es decir, la puerta de enlace predeterminada.

Apartado 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 la dirección de la puerta de enlace alternativa, es decir, al dirección óptima a la que deberá mandar el paquete nuestro PC siempre que quiera ir a ese destino.
También transporta parte de los datos que se enviaron en el paquete original para que el PC sepa qué mensaje provocó el error y porqué

Apartado 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?

	Identificación	TTL	Checksum
Original	0x0603 (1539)	128	0x50cb
Redirect	0x0603 (1539)	127	0x51cb

Como podemos observar, el campo TTL disminuye una unidad por el salto del router que hay en la red.
El campo Checksum (Header Checksum concretamente) cambia en un único número, lo que es lógico debido a que, de toda la cabecera anterior, únicamente cambia un valor del TTL.

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

¿Por qué 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

En base a los paquetes capturados, indicar:
Apartado 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)
Comenzamos por las IPs:
172.20.43.218 --> Es nuestra propia IP
10.3.7.0 --> Es la IP de la máquina destino. Corresponde a la máquina Linux 1.
10.4.2.5 --> Es una de las IPs del router Cisco 2513.

En cuanto a las direcciones MAC, tenemos las siguientes:
00:0A:5E:76:8C:4C --> Es la dirección MAC de nuestro ordenador.
00:07:0E:8C:8C:FF --> Es la dirección MAC del router Cisco 1720.

Apartado 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)
El mensaje ICMP lo envía la máquina cuya IP es 10.4.2.5.
Esta IP es, de acuerdo con la topología del laboratorio adjunta en la memoria, con uno de los puertos del router Cisco 2513.

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

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

c:\>ping -n 1 -l 2000 172.20.43.203

Apartado 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?
El filtro utilizado ha sido ip.dst==172.20.43.218 || ip.src==172.20.43.218
Hay dos fragmentos de ida (request) y dos fragmentos de vuelta (reply). Uno tiene longitud 1514 bytes (1472 bytes de datos en el protocolo ICMP) y el otro 562 bytes (528 bytes de datos en el protocolo ICMP).
El fragmento de mayor tamaño, tanto de request como de reply, aparece identificado como ICMP mientras que el de menor tamaño, tanto de request como de reply, aparece como IP.
Apartado b) ¿En cuántos fragmentos se ha "dividido" el datagrama original?
El datagrama original se ha dividido en dos datagramas diferentes ya que hemos mandado 2008 bytes (2000 bytes de datos ICMP + 8 bytes de cabecera ICMP).

Apartado 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 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	Fragment Offset	Identificación
1	ICMP	Petición	0x02	0	0x028b (651)
2	IP	Petición	0x00	1480	0x028b (651)
3	ICMP	Respuesta	0x02	0	0x028b (651)
4	IP	Respuesta	0x00	1480	0x028b(651)

Apartado 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?
Únicamente se visualiza el primer fragmento de cada paquete (del de ida y del de vuelta). Sucede que el primer fragmento se cataloga como ICMP porque el programa examina el contenido de la trama y, al encontrar la cabecera dentro del datagrama IP, establece que eso es un paquete ICMP.


Apartado e) ¿Para qué se pueden emplear los campos "Identificación", "Flags" y "Fragment Offset" de los datagramas IP?
Identificación --> Para marcar de forma única cada datagrama enviado.
Flags --> Informa sobre si se han acabado los paquetes o quedan más por venir.
Fragment Offset --> Sirve para saber dónde va cada paquete.

Apartado f) En función de los datos anteriores, indica el valor de la MTU de la red.
Para averiguar el valor de la MTU miramos el primero de los fragmentos en los que se ha dividido el paquete enviado con el ping por el hecho de ser el que se llena al máximo. Esta trama tiene una longitud de 1514 bytes, por lo que si eliminamos los 14 bytes pertenecientes a la cabecera del nivel Host-Red, obtenemos que la MTU a nivel IP es 1500 bytes.

Apartado g) Repite el ejercicio lanzando 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	Fragment Offset	Identificación
1	ICMP	Petición	0x02	0	0x123b (4667)
2	IP	Petición	0x02	1480	0x123b (4667)
3	IP	Petición	0x00	2960	0x123b (4667)
4	ICMP	Respuesta	0x02	0	0x1b05 (6917)
5	IP	Respuesta	0x02	1480	0x1b05 (6917)
6	IP	Respuesta	0x00	2960	0x1b05 (6917)

En la siguiente imagen podemos ver esas tramas en el monitor de red:

Apartado 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

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	Fragment Offset	Identificación
1	ICMP	Petición	0x02	0	0x1292 (4754)
2	IP	Petición	0x00	1480	0x1292 (4754)
3	ICMP	Respuesta	0x02	0	0x0096 (156)
4	IP	Respuesta	0x02	480	0x0096 (156)
5	IP	Respuesta	0x02	960	0x0096 (156)
6	IP	Respuesta	0x00	1440	0x0096 (156)

En la siguiente imagen podemos ver esas tramas en el monitor de red:

Apartado i) En relación a los datos de la pregunta 2.h. obtenidos del Monitor de Red, contesta: ¿Por qué se observan más fragmentos IP de "vuelta" (respuesta) que de "ida" (petición)?
Porque en una de las redes intermedias se separan las tramas en varios fragmentos debido a que la MTU en uno de esos segmentos es menor que en el origen.

Indica en qué 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 qué otra subred no sucede esto.
El número de fragmentos tanto en petición como respuesta sólo es el mismo en el tramo que va desde el Cisco 2513 hasta el Linux 1 ya que es que el tiene la MTU más pequeña de toda la ruta que ha de atravesar el paquete hasta llegar a su destino y, por tanto, es que establece el número de fragmentos en los que quedará dividido el paquete original. Esto no sucede ni en la red que va del laboratorio al Cisco 1720 y la que va de éste al Cisco 2513 porque a la ida tendrán únicamente dos fragmentos (el paquete original, al ser de gran tamaño, se ha de fragmentar una vez) pero en la respuesta tendrán cuatro fragmentos ya que, aunque puedan tener tramas de mayor tamaño, el protocolo establece que si los paquetes llegan fragmentados (y en este caso lo harán por la MTU que hay del Cisco 2513 al Linux 1) no han de ser unidos.

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?
Según el esquema adjunto a la memoria, se atraviesan 3 subredes. En rojo, además, se detallan las MTU de las subredes que se atraviesan.

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

Detener la captura en el Monitor de Red (filtrar únicamente tramas del alumno) y visualizar los paquetes capturados.
Para poder ver únicamente los mensajes pertenencientes a nuestra máquina hemos utilizado el filtro siguiente:
ip.dst==172.20.43.218 || ip.src==172.20.43.218
Cabe destacar que también, como únicamente queremos ver los mensajes ICMP que hay en la red, también podríamos haber utilizado directamente este filtro:
icmp

En base a los paquetes determinar:
Apartado a) ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)
Aparecen 3 (dos de REQUEST y uno de REPLY) mensajes ICMP, aunque en realidad sólo deberían aparecer 2: uno de tipo REQUEST y otro de tipo REPLY. Esto ocurre porque el monitor duplica, al mostrarlo por pantalla, el mensaje REQUEST, pero por la red únicamente hay uno de cada, ya que por cada llamada siempre hay una respuesta.

Los tipos y códigos de los mensajes son los que siguen:

Mensaje	Tipo	Código
Echo_request	8	0
Echo_reply	0	0

Apartado 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?
En este caso sí que son la misma debido a que estamos mandando la petición a la puerta de enlace de la red (es decir, al router que nos da salida a otra red desde la del laboratorio) y, como estamos moviéndonos en una red local, la IP sí que tiene una correspondecia directa con la MAC. Si nos moviéramos fuera de esta red la dirección MAC no haría referencia a la IP de la máquina de destino ya que tendríamos la MAC de la puerta de enlace (por lo del protocolo ARP) y la IP del destino, fuera el que fuera.

Apartado 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.
El tamaño total que obtenemos en una trama catalogada como ICMP es 74 bytes, de acuerdo con lo que nos muestra el Monitor de Red.
Como podemos observar, si nos vamos al apartado de Internet Control Message Protocol (ICMP), podemos observar que como datos tiene 32 bytes y que, con la suma de su propia cabecera (siempre son 8 bytes, aunque se puede comprobar con el Wireshark) tenemos 40 bytes de tamaño total de trama ICMP.
Cabe destacar que los datos de ICMP tienen esa longitud porque este mensaje se ha producido por el comando ping, el cual, como no le hemos especificado la cantidad de datos que queríamos que mandara (simplemente hemos especificado que mandara 1 único paquete), él por defecto manda paquetes de 32 bytes, que son los datos del susodicho protocolo.
Finalmente, para comprender mejor este concepto, adjuntamos el siguiente dibujo que muestra la encapsulación del protocolo ICMP, que se encuentra en el Nivel de Internet de TCP/IP, hasta el nivel físico (Nivel de Host-Red en TCP/IP):

¿De qué va la Práctica 2?

Con la segunda práctica de la asignatura vamos a tratar el llamado Protocolo de Mensajes de Control de Internet (ICMP). Este protocolo tiene como finalidad comunicar los mensajes de error que ocurren en la transmisión de datos por medio de una red.
En esta práctica se realizarán seis ejercicios, que a continuación se describen:

• Con el primer ejercicio nos familiarizaremos con el funcionamiento de este protocolo y con la encapsulación del mismo.
• El segundo ejercicio pretende introducirnos en la fragmentación que realiza el protocolo IP (nivel de Internet) por medio del ICMP.
• En el ejercicio tres forzaremos una situación de error de destino inalcanzable (un error que ocurre cuando la máquina a la que queremos llegar no está operativa) y comprobar el funcionamiento de ICMP en este caso.
• Con el cuarto ejercicio vamos a intentar forzar una situación de redirección, es decir, intentar no ir por una ruta óptima a un destino para ver cómo reacciona ICMP.
• En el quinto ejercicio vamos a provocar una situación en la que un paquete de datos "muera" por la red (su tiempo de vida llegue a cero) para comprobar la reacción de ICMP.
• Por último realizaremos un ejercicio en el que podremos ver la ruta física (ciudades, países e incluso continentes) que sigue un paquete de información desde el origen (nuestra máquina, por ejemplo) hasta su destino.