Práctica 2

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

Al usar el comando ping aparecen dos tipos de mensajes diferentes: “echo request” y “echo reply”. Cada uno de ellos aparece tantas veces como mensajes echo se hayan enviado mediante el comando ping. Si, por ejemplo, enviamos 3 mensajes echo con el ping (ping -n 3 xxx.xxx.xxx.xxx), aparecerán 6 mensajes ICMP: 3 mensajes “echo request” y otros tres de “echo reply”.

Los mensajes echo request son de tipo 8, mientras que los mensajes echo reply son de tipo 0. En cuanto al código, ambos son código cero.

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?

• ECHO REPLY – MUESTRA PRIMERO MAC PUERTA ENLACE
• 
• ECHO REQUEST – MUESTRA PRIMERO MAC PC ALUMNO
• 

En nuestro ejemplo realizado en el laboratorio obtenemos la IP y MAC de nuestra máquina como origen de la ICMP request y destino de la reply. La dirección IP y MAC de destino de la request y la fuente de la reply coincide con la puerta de enlace del laboratorio. Hemos comprobado esta correspondencia mendiante el comando “arp -a”. En caso de que hiciésemos el ping a una máquina externa a nuestra red, obtendríamos como IP fuente del mensaje de reply la dirección de la máquina remota con la que nos hemos comunicado, pero como fuente MAC aparecería la dirección física de nuestra puerta de enlace, ya que es ella quien nos envía el mensaje. En este caso no ocurre esto porque las dos máquinas son la misma.

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 captura total realizada con el wireshark contiene 74 bytes, dividos como aparece en la siguiente tabla:

La cabecera para ICMP tendrá 8 bytes, resultado obtenido conociendo el total de datos capturados y los distintos tamaños de cabeceras ethernet, ip y el tamaño de los datos ICMP.

En el mensaje ping se han transportado 32 bytes de información (esta cantidad de de datos ICMP enviados y recibidos puede ser variada mediante la inclusión del comando <-l>)

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?

En total hay 4 fragmentos de datagramas IP lanzados al medio. Dos corresponden a la petición y los otros dos a la respuesta. En el monitor de red aparecen identificados de dos maneras. En el primer fragmento aparece clasificado como protocolo ICMP, ya que contiene tanto cabecera IP como cabecera ICMP. En el segundo fragmento, tanto de petición como de respuesta, aparece como protocolo IP ya que no tiene la cabecera ICMP. Esta cabecera se queda en el primer fragmento al truncar, ya que se considera parte de los datos de IP.

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

Cada datagrama orginal se ha dividio en dos:

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	DIRECCION	FLAGS	FRAG. OFFSET	IDENTIFICACION
1	ICMP	REQUEST	0X02 (more fragments)	0	0×9471 (38001)
2	IP	REQUEST	0X00	1480	0×9471 (38001)
3	ICMP	REPLY	0X02 (more fragments)	0	0×9471 (38001)
4	IP	REPLY	0X00	1480	0×9471 (38001)

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?

Ahora se visualizan solo los fragmentos que contienen la cabecera ICMP, es decir, los primeros de cada paso. Esto sucede porque los fragmentos truncados correspondientes a la última parte de la información carecen de la cabecera ICMP, que sólo se envía en el primer fragmento.

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

IDENTIFICACION: Identifica al datagrama original

FLAGS: Identifica que trozo es del datagrama original

FRAGMENT OFSSET: Apartir de donde se ha recortado el datagrama enviado

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

La MTU de la red corresponderá al numero de fragmen ofsset 1480 mas la cabecera. Por lo tanto la MTU de la red será de 1500

MTU=1500

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

request: 172.20.43.216

reply: 172.20.43.195

DATAGRAMA Nº	PROTOCOLO	DIRECCION	FLAGS	FRAG. OFFSET	IDENTIFICACION
1	ICMP	REQUEST	0X02	0	0X4343
2	IP	REQUEST	0X02	1480	0X4343
3	IP	REQUEST	0X00	2960	0X4343
4	ICMP	REPLY	0X02	0	0X805C
5	IP	REPLY	0X02	1480	0X805C
6	IP	REPLY	0X00	2960	0X805C

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

DATAGRAMA Nº	PROTOCOLO	DIRECCION	FLAGS	FRAG. OFFSET	IDENTIFICACION
1	ICMP	REQUEST	0×02	0	0×88ce
2	IP	REQUEST	0×00	1480	0×88ce
3	IP	REPLY	0×00	1440	0×0069
4	IP	REPLY	0×02	960	0×0069
5	IP	REPLY	0×02	480	0×0069
6	ICMP	REPLY	0×02	0	0×0069

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

• Cuando nuestro datagrama pasa por una red con MTU menor que la nuestra, el datagrama original es divido en los fragmentos necesarios para pasar por la nueva red. Nos son devueltos con el tamañana a la que esta ultima red los ha dejado. El reensamblado se realizará en nuestra maquina.

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.

• Cuando hacemos un ping hacia C:\>ping –n 1 –l 2000 172.20.43.230, el datagrama original se divide en dos, dos para mensaje request y dos para mensaje reply. Esto no sucede en todas las subre4des atravesadas, ya que cuando hacemos ping a C:\>ping –n 1 –l 1600 10.3.7.0, el mensaje reuest se divide en dos, pero recibimos de vuelta u mensajes reply. En una de las subredes, la MTU era menor y el mensaje a sido subdividido.

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?

• Nuestro mensaje atravesará 3 subredes hasta llegar a la maquina 10.3.7.0.

3.a. Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen?

La maquina que responde C:\>ping -n 1 –l 1000 -f 10.3.7.0 es la 10.4.2.5 router Cisco 2513. La MAC que nos responde es la 00:07:0e:8c:8c:ff .

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

Como en el anterior apartado, la maquina con ip 10.4.2.5 router Cisco 2513 es la que devuelve el mensaje de “fragmentation needed”

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)

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

DATAGRAMA		TIPO Y CODIGO ICMP	TAMAÑO PAQUETE ICMP	ORIGEN IP	DESTINO IP
1		REQUEST/CODE:0	60 bytes	172.20.43.216	10.4.2.1
2		REDIRECT/CODE:1	54 bytes	172.20.43.230	172.20.43.216
3		REPLY/CODE:0	60 bytes	10.4.2.1	172.20.43.216

Segunda Práctica. Punto 4b

Grafico del envio y recepción de mensajes de redirect:

Segunda Práctica. Punto 4c

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?

Al cometer el error de direccionamiento, se generarán 4 mensajes ICMP. Nosotros solo veremos tres, hay un switch en medio que impide que se pueda visualizar el mensaje “echo” copiado por el router, que se envía a destino.

Segunda Práctica. Punto 4d

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	TIPO Y CODIGO ICMP	ORIGEN MAC	DESTINO MAC	ORIGEN IP	DESTINO IP
1	REQUEST CODE:0	00:0a:5e:76:fe:38	00:07:0b:8c:8c:ff	172.20.43.216	10.4.2.1
2	REDIRECT CODE:1	00:07:0b:8c:8c:ff	00:0a:5e:76:fe:38	172.20.43.230	172.20.43.216
3	REPLY CODE:0	00:d0:ba:e0:6a:3d	00:0a:5e:76:fe:38	10.4.2.1	172.20.43.216

En la primera trama “echo request” nuestro ordenador (172.20.43.216) trata de comunicarse con el destino 10.4.2.1. Sin embargo con esta petición no recibe la dirección física MAC del 10.4.2.1, sino del ordenador 172.20.43.230, que es un paso intermedio. En esta trama podemos comprobar que las direcciones no hacen referencia al mismo interfaz

Es este ordenador (el 172.20.43.230) quien nos manda la trama de “redirect” a nuestro PC en el segundo paso. Finalmente el ordenador de destino 10.4.2.1 nos responde con la trama “echo reply”.

Segunda Práctica. Punto 4e

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

El router 172.20.43.230 es el que genera el mensaje ICMP REdirect to Host, enviando a su vez la petición de ping al destino.

Segunda Práctica. Punto 4f

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?

• Dentro del mensaje ICMP redirect, recibiremos en el campo GATEWAY ADRESS: 172.20.43.231, que será la nueva puerta de acceso que deberemos utilizar.

• Además se encuentra el propio Request enviado en primer lugar. Además el mensaje Redirect añade el tipo 4 code 1 (redirect for host)

Segunda Práctica. Punto 4g

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?

MENSAJE ICMP ECHO REQUEST

• IDENTIFICATION: 0×9939 (39225)
• TIME TO LIVE: 128
• CHEKSUM: 0×495c (CORRECT)

En el datagrama original, estos datos se encuentran dentro de la cabecera IP

MENSAJE ICMP REDIRECT

• IDENTIFICATION: 0×9939 (39225)
• TIME TO LIVE: 127
• CHEKSUM: 0×495c (inCORRECT, SHOULD BE 0xf3ff)

En el datagrama Redirect, encontramos el mensaje original, dentro del apartado de datos (ICMP)

En cuanto al dato de TTL (time to live), ha disminuido en una unidad (el salto producido en el router que nos ha contestado con el error de redirección).

En la cabecera IP del mensaje ICMP Redirect, podemos observar que su TTL es de 255. Fijando un número de saltos mayor, se asegura la recepción correcta del error en la maquina de origen del mensaje ICMP Request.

Cuestión 5. Práctica 2

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

Segunda Práctica. Punto 5a

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)

La máquina que devuelve el mensaje de ICMP Time-to-live exceeded es la 172.20.43.230 con MAC 00:07:0e:8c:8c:ff.

Dentro de la topología del laboratorio esta maquina es la “puerta de enlace predeterminada”

Segunda Práctica. Punto 5b

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 esta ocasión, la máquina que devuelve el mensaje de ICMP Time-to-live exceeded es la 10.4.2.5 con la MAC 00:07:0e:8c:8c:ff que es la de la puerta de enlace. En el apartado anterior, recibiamos IP y Mac de la puerta de enlace. Al forzar el ping con dos saltos, recibimos la IP de una maquina de otra subred, pero la mac será siempre la de nuestra puerta de enlace.

Segunda Práctica. Punto 5c

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?

MENSAJE ICMP TIME-TO-LIVE EXCEEDED

• TYPE: 11 (Time -to-live exceeded)
• CODE: 0 (Time -to-live exceeded in transit)

Al aumentar a 50 el TTL, el mensaje salata de una maquina a otra dentro de un bucle creado en esa subred, debido a que no puede encontrar la maquina de destino.

El bucle entre maquinas se genera en la subred:

SUBRED 10.3.255.255

Segunda Práctica. Apartado 5d

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

En este caso obtenemos la misma respuesta, un mensaje de error de tiempo excedido de la misma máquina. La diferencia se encuentra en el tiempo que ha tardado en aparecer el mensaje. En este segundo caso el tiempo ha sido mucho mayor ya que el paquete ha tenido que dar muchos más saltos hasta que se ha agotado su tiempo de vida.