Práctica 02. Protocolos de Mensajes de Control de Internet (ICMP)

Cuestión 1. Sobre mensajes del ICMP del ping.
Con arreglo al guión de la práctica 02, iniciamos el Monitor de Red Wireshark en modo captura; que detenemos tras ejecutar el comando ping -n 1 172.20.43.230. Anotar que resulta de utilidad esperar a que finalice la ejecución del comando tras la que nos aparecerá información, como la que se recoge en el párrafo Estadísticas de ping dentro de la ventana de MS-DOS, pues habrá que verificar que en paquetes perdidos no se muestre un valor distinto de cero como primer indicativo de que nuestro mensaje echo no se ha perdido por la red. En caso contrario, no capturariamos la información que deseamos para analizar la cuestión planteada a través de los siguientes interrogantes.

También decir que con la opción -n [valor] del comando ping podemos modificar el número de peticiones echo, de cuatro por defecto, por el número que indica el parámetro valor; en este caso, enviamos una sola petición. Luego, en Whireshark Network Analyzer, filtramos aquellas capturas que nos interesan, por lo que validamos el siguiente filtro: ip.src==172.20.43.203 ip.dst==172.20.43.203, con lo que se nos muestran las tramas que el alumno envía y recibe; amén del filtro !nbns con razón de eliminar aquellos paquetes que genera el sistema operativo y así limpiar la ventana en la que se nos facilitan los paquetes capturados:

1.a.¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código).
El Analizador de Protocolos Wireshark nos muestra dos paquetes ICMP que se corresponden a la petición echo request (Type 8, Code 0) transmitido por la máquina origen y a la respuesta a dicha petición, echo reply (Type 0, Code 0), enviada por el router Cisco 1720.El comando ping utiliza un mensaje de petición de echo request (tipo 8) para enviar un datagrama a su destinatario y espera el retorno de un mensaje echo reply (tipo 0) del destinatario.
1.b. Justifica la procedencia de cada dirección MAC e IP. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP 'reply' hacen referencia a la misma máquina o interfaz de red?.
De la información que obtenemos del Capturador se deduce que la trama Ethernet, que porta el mensaje ICMP reply, tiene su origen en MAC 00:07:0E:8C:8C:FF; que se corresponde con el router del laboratorio CISCO 1720. Si continuamos leyendo en la ventana de información del paquete capturado, la IP de dicho mensaje de respuesta a nuestra llamada tiene su origen en IP 172.20.43.230 que pertenece a ese mismo router.

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.
Del Analizador de Protocolos podemos obtener que la longitud total de ambos paquetes es de 74 bytes, de los cuales, los 14 primeros se corresponden a la cabecera de la trama Ethernet; porteador a nivel físico de cualquier paquete de bytes. Los siguientes 20 bytes son del datagrama IP y los restantes 40 bytes pertenecen a su campo de datos, en cuyo interior se transmite el mensaje ICMP. El formato de los mensajes ICMP comienza siempre por tres primeros campos: Type (8 bits o 1 byte), Code (1 byte) y SVT (2 bytes) que suman 4 bytes. Así pues, quedan 36 bytes que se reparten en 2 bytes para el campo Identifier y otros 2 bytes para el campo Sequence Number. Al final, restan 32 bytes para datos del mensaje ICMP.


Cuestión 2. Sobre la fragmentación de datagramas IP.
Ejecutamos ahora el comando ping -n 1 -l 2000 172.20.43.230 con la intención de enviar una única prueba de accesibilidad con un tamaño de 2000 bytes a la dirección IP especificada en el ping.

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?.
Procedemos con la ejecución del filtro ip.src==172.20.43.203 ip.dst==172.20.43.203 && !nbns para poder visualizar los paquetes asociados a nuestra dirección IP que se corresponde con la del filtro.

Ambos datagramas IP, asociados a la petición echo como a su respuesta, están fragmentados en dos paquetes cada uno. Así que suman entre los dos 4 paquetes fragmentados. Sendos echo, request y reply, quedan identificados por un paquete de protocolo ICMP y que están encapsulados en sus correspondientes paquetes de protocolo IP, en cuya columna info se lee la siguiente información: Fragmented IP Protocol (proto=ICMP 0x01, off=0) [Reassembled in #].
2.b.¿En cuantos fragmentos se ha "dividido" el datagrama original?

Las dos primeras filas se corresponden con el datagrama IP original; así pues, se ha divido en dos fragmentos; al igual que el datagrama IP que llega a la máquina fuente desde la Puerta de Enlace.
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 depetición o respuesta. Muestra los datagramas en el orden de aparición del Monitor de Red.

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?.
Tan sólo se muestran los paquetes correspondientes a las echo, petición y respuesta; sin que aparezca paquete alguno con el protocolo IP, pues; como se vio en la figuras anteriores, para esos paquetes no existe contenido ICMP, que es el que predeterminamos mediante el filtro para que el Analizador de Protocolos muestre todos los paquetes con información ICMP.
2.e. ¿Para qué se pueden emplear los campos "Identificación", "Flags" y "Fragment offset" de los
datagramas IP?.
El campo Identification nos identifica el fragmento. Todos los paquetes fragmentados que pertenecen a un mismo encapsulado presentarán la misma Identification que, en el paquete de envío original es 0x05b1 (1457), se está asociado al datagrama IP padre. El campo Flags nos señala si el paquete indicado está fragmentado y en cuantos trozos, que este caso aparece 0x02 (More Fragments). Y en el campo Fragment Offset se nos indica a partir de que byte hay que ensamblar el fragmento que pertenece al mismo datagrama.
2.f. En función de los datos anteriores, indica el valor de la MTU de la red.
El parámetro MTU hace referencia a la cantidad máxima de bytes que contiene la trama; en este caso, es de 1500 bytes, de los cuales 20 pertenecen a la cabecera y 1480 a los datos.
2.g. Repite el ejercicio lazando una petición de ping con un mayor número de datos y al destino ".195":
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):


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 Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):




Cuestión 3. Mensaje ICMP "Destination Unreachable".
Analizaremos ahora la información que se nos presenta en el mensaje ICMP cuando el datagrama IP no alcanza su destino. Ejecutar el comando route delete 10.3.7.0 en MS-DOS. Con ello, modificamos las tablas de encaminamiento de nuestra máquina y borramos cualquier vínculo anterior a la dirección IP especificada. A continuación activamos el Monitor de Red y ejecutamos el comando ping -n 1 -l 1000 -f 10.3.7.0. Indicar que la opción -f de MS-DOS impide la fragmentación del datagrama con ocasión del ping lanzado. Detenemos la captura y ...

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 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 1.
Cuestión 4. Mensaje ICMP 'Redirect'.
Este mensaje ICMP de tipo 5 es enviado por un router que detecta que el datagrama IP que recibe no ha empleado una ruta óptima. Para realizar la siguiente cuestión, primero, borraremos cualquier vínculo con la dirección IP 10.4.2.1; para que los mensajes ICMP a recibir no se correspondan a anteriores conexiones y, segundo, remitiremos una petición echo a esa misma dirección IP. Todo ello lo realizamos en MS-DOS mediante los comandos route delete 10.4.2.1 y ping -n 1 10.4.2.1; respectivamente. Una vez confirmado que el resultado ping es correcto en MS-DOS, procedemos a la captura de paquetes aplicando el siguiente filtro ip.src==172.20.43.203 ip.dst==172.20.43.203 && !nbns.

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

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

4.c. ¿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?.
En la figura se pueden observar cuatro direccionamientos que se corresponden con los cuatro mensajes que realmente se producen con este redireccionamiento: 1. ICMP request (de máquina origen a router 1), 2. ICMP redirect (de router 1 a máquina origen), 3. ICMP copy (de router 1 a router 2) y 4. ICMP reply (de máquina destino a máquina origen). Sin embargo, en el Monitor de Red no se nos mostrará el mensaje 3 entre routers porque el switch realiza un filtrado por seguridad y los paquetes en los que no interviene nuestra máquina no se muestran en el Analizador de Protocolos.
4.d. ¿Las direcciones MAC e IP de todas las tramas capturadas con el Monitor de Red hacen referencia almismo 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.
Si nos fijamos en el cuadro de la pregunta 4.a. y lo cotejamos con la figura de la pregunta 4.b. podremos afirmar que, en todos los casos, las direcciones MAC e IP coinciden para la máquina fuente; mientras que: en el ICMP request la MAC destino pertenece al router 1 y la IP destino a la máquina que deseamos hacer llegar el datagrama lanzado con ocasión de la petición echo, en el ICMP redirect coinciden sendas MACs e IPs y en el ICMP reply el datagrama IP de la máquina destino es enviado en el interior de la trama Ethernet con la MAC del router 2.
4.e. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?.
Este mensaje ICMP de redireccionamiento es enviado por el router 1 o encaminador que detecta que la ruta que toma el ICMP request no es la adecuada y de esta manera informa a la máquina fuente de la petición echo que debe actualizar su tabla de encaminamiento, con lo que dicha máquina incorpora una puerta de enlace alternativa; que se corresponde con el router 2, para hacer llegar los próximos datagramas con el destino especificado en la dirección IP.
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?.
Si, en el Analizador de Protocolos Whireshark, abrimos la información que alberga Internet Control Message Protocol (ICMP) podremos leer la puerta de enlace alternativa que debe incorporar la máquina fuente a su tabla de rutas. Se corresponde con la dirección IP 172.20.43.231 del router 2: Cisco 1601, que está codificada en 4 bytes.
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?.
De la información que se arroja en el Monitor de Red podemos leer del primer mensaje ICMP request que: el tiempo máximo de tránsito TTL es de 128, el contador de tiempo Cheksum es de 0x415c [correct] y la Indetification es 0x0702 (1794). Del segundo mensaje ICMP redirect obtenemos información del datagrama IP que se envía del router 1 a la máquina fuente y que en su campo de datos contiene el ICMP Type 5 Code 1, que informa de la anomalía y que, además, posee la dirección IP del nuevo router y el encabezado del datagrama IP causante del error. Como información de éste último datagrama se muestra un TTL de 127; descontando en una unidad el tiempo de tránsito del paquete enviado, un Cheksum de 0x415c [incorrect] y una Identification de 0x0702 (1794), que coincide con la del datagrama inicial. Y en el datagrama IP padre de este segundo mensaje ICMP redirect aparece un TTL de 255, un Cheksum de 0x0a16 [correct] y una Identification 0x01d5(469).

Cuestión 5. Mensaje ICMP 'Time Exceded'.
Un mensaje ICMP del Type 11 y Code 0 nos informa de que el tiempo máximo de tránstito TTL (Time To Live) para un datagrama que circula por la red ha excedido, debido a rutas circulares o bucles de enrutamiento. Por consiguiente, el mensaje debe ser eliminado para que no recorra indefinidamente los routers; lo que daría pie a una congestión de la red. Ese tiempo de vida puede ser modificado con la opción -i . El parámetro se corresponde al número de encaminadores que el mensaje podrá emplear para alcanzar su destino y que por defecto es de 128. En este caso será de 1, lo que significa que el datagrama que generamos con la petición echo podrá atravesar un único router. Así pues, procedemos al envío de nuestra única petición echo mediante el comando ping -i 1 -n 1 10.3.7.0

5.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 1).

Del Analizador de Protocolos podemos deducir que la máquina que envía el mensaje ICMP tiene por IP 172.20.43.230, cuya MAC es 00:07:0E:8C:8C:FF. Ambas señas de identidad pertenecen a la misma máquina, que no es otra que nuestra Puerta de Enlace: Router Cisco 1720.
Realizamos el mismo ejercicio, pero incrementando el TTL a 2; para lo que ejecutaremos ahora el comando 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 1).
Del Monitor de Red Wireshark podemos deducir que la MAC origen 00:07:0E:8C:8C:FF se corresponde con la misma máquina que en el apartado anterior: Cisco 1720. Sin embargo, la trama Ethernet que nos llega engloba a un datagrama IP que ha sido enviado por otra máquina de dirección IP origen 10.4.2.5 y que pertenece al siguiente y único encaminador Cisco 2513 al que ha podido llegar nuestra petición echo antes de alcanzar su destino dada la opción del comando ping -i 2. Repetimos ejercicio aumentando aún más el tiempo de tránsito hasta 50 a otra dirección IP: 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?.


Auxiliados por nuestro Analizador de Protocolos, podemos saber el tipo y el código del mensaje ICMP. En este caso continúa siendo de las mismas características que en apartados anteriores: Type 11 Code 0. La dirección MAC pertenece a la misma Puerta de Enlace del laboratorio, pero la dirección IP 10.3.2.0 está asociada a la máquina Linux 1, lo que hace pensar que se ha producido un bucle en el enrutamiento de la petición echo. Respecto a la subred de la máquina con IP 10.3.7.12 a la que intentamos lanzar una petición echo no se encuentra ubicada en la topología de red dibujada en el Anexo 1. En cambio, la máquina Linux 1 queda ubicada en la subred 10.3.0.0/16.
De nuevo, enviamos un echo a ésta última dirección, pero aumentando ese tiempo TTL hasta 160.
5.d. ¿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)?.

Desde la ventana de MS-DOS no se notifica diferencia alguna de los tiempos aproximados de ída y vuelta, pero tiene lógica si se deduce que la petición echo con un TTL mayor invierte también mayor tiempo en responder. Sendos resultados son similares, pero; si nos fijamos en la información Time since reference or first frame, que se nos ofrece en el apartado de Frame del Analizador de Protocolos, en el primer caso aparece un resultado de 7.500996 segundos y, en el segundo caso, es de 13.177065 segundos; lo que parece corroborar nuestra deducción.