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 uso de ping enviamos un paquete ICMP al router cisco (172.20.43.230) del laboratorio.
Aparecen 2 tipos de mensajes ICMP: La Petición de echo (echo request - tipo 8 y código 0) correspondiente al ping y la Respuesta de echo (echo reply - tipo 0 y código 0) que corresponde a la respuesta de nuestro ping.
1.b. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP "Reply" 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, al router Cisco 1720 del laboratorio 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. En este caso, la MAC sería de nuestra puerta de enlace y la IP de la máquina de fuera.
Inicia el programa Monitor de Red en modo captura. A continuación ejecuta el comando:
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?
| Datagrama | Protocolo | Info | Tamaño |
| 1 | ICMP | Echo(ping) request | 1514 bytes |
| 2 | IP | Fragmented ip protocol | 562 bytes |
| 3 | ICMP | Echo(ping) reply | 1514 bytes |
| 4 | IP | Fragmented ip protocol | 562 bytes |
2.b. ¿En cuantos fragmentos se ha “dividido” el datagrama original?
Como se puede apreciar en la figura anterior, el datagrama se ha dividido en dos fragmentos. El primero de 1514 bytes y el segundo de 512 bytes, ya que 2000 es mayor a la MTU de nuestra Ethernet de 1500.
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.
Aparecen dos fragmentos tanto para la petición, como para la respuesta.
| Datagrama | Protocolo | Dirección | Flags | Frag. offset | Identificación |
| 1 | ICMP | 172.20.43.230 | 0.0.1 | 0 | 0x7a35 |
| 2 | IP | 172.20.43.230 | 0.0.0 | 1480 | 0x7a35 |
| 3 | ICMP | 172.20.43.215 | 0.0.1 | 0 | 0x7a35 |
| 4 | IP | 172.20.43.215 | 0.0.0 | 1480 | 0x7a35 |
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?
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?
Para la fragmentación.
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. 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):
| Datagrama | Protocolo | Dirección | Flags | Frag. offset | Identificación |
| 1 | ICMP (ping request) | 10.3.7.0 | 0.0.1 | 0 | 0x8230 |
| 2 | IP (fragmented) | 10.3.7.0 | 0.0.0 | 1480 | 0x8230 |
| 3 | ICMP (ping reply) | 172.20.43.215 | 0.0.1 | 0 | 0x009b |
| 4 | IP (fragmented) | 172.20.43.215 | 0.0.1 | 480 | 0x009b |
| 5 | IP (fragmented) | 172.20.43.215 | 0.0.1 | 960 | 0x009b |
| 6 | IP (fragmented) | 172.20.43.215 | 0.0.0 | 1440 | 0x009b |
| Datagrama | Tipo y Código ICMP | Tamaño del paquete ICMP | Origen IP | Destino IP |
| 1 | 8 – 0 (echo request) | 60 bytes | 172.20.43.215 | 10.4.2.1 |
| 2 | 5 – 1 (redirect) | 60 bytes | 172.20.43.230 | 172.20.43.215 |
| 3 | 0 – 0 (echo reply) | 60 bytes | 10.4.2.1 | 172.20.43.215 |
| Datagrama | Tipo y Código ICMP | Origen MAC | Origen IP | ¿Representan al mismo interfaz? |
| 1 | 8 – 0 (echo request) | 00:0A:5E:76:8F:7B | 172.20.43.215 | 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 |
