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)
¿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 (…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)
Petición:
Dirección IP origen: 172.20.43.200
Dirección IP destino: 10.3.7.0
Dirección MAC origen: 00:0a:5e:77:04:3a
Dirección MAC destino: 00:07:0e:8c:8c:ff
Respuesta:
Dirección IP origen:10.4.2.5
Dirección IP destino: 172.20.43.200
Dirección MAC origen: 00:07:0e:8c:8c:ff
Dirección MAC destino: 00:0a:5e:77:04:3a
Equipos involucrados:
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)
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?
Observamos 4 paquetes fragmentados, 2 paquetes identificados con el protocolo ICMP, tanto de petición ‘echo request’, como de respuesta ‘echo reply’, y otros 2 paquetes de protocolo IP, en los cuales, aparece en la columna “info”, ‘Fragmented IP protocol’.
2.b. ¿En cuántos fragmentos se ha “dividido” el datagrama original?
El datagrama original se divide en 2 fragmentos, uno de protocolo ICMP y otro de protocolo IP; para la petición (ICMP y IP request) y para la respuesta (ICMP y IP reply).Esto se debe, a que, el datagrama original supera los 1500bytes que caben en Ethernet.
Cab. IP
Cab. ICMP
Datos puros
20
8
2000
Primer Fragmento
Cab. IP
Cab. ICMP
Datos puros
20
8
1472
Segundo Fragmento
Cab. IP
Datos puros
20
528
Como podemos observar el primer fragmento se completa con los 1500bytes, mientras que el segundo fragmento, se llena de residuos, esto se puede comprobar con las imágenes aportadas en el punto 2a.
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.
Flag 0x01 --> nos indica que existen más fragmentos
Datagrama nº
Protocolo
Dirección
Flags
Frag. Offset
Identificación
232
ICMP
petición
0x01
0
14018
233
IP
petición
0x00
1480
14018
234
ICMP
respuesta
0x01
0
14018
235
IP
respuesta
0x00
1480
14018
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?
Solo visualizamos la primera parte fragmentada (ICMP) de la petición y de la respuesta.
2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?
Identificación --> para saber que las diferentes partes corresponden a un mismo paquete
Flags --> nos indica si necesitamos alguna parte más
Frag. Offset --> nos indica cual es la posición del último dato enviado del fragmento anterior
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):
Inicia el programa Monitor de Red en modo captura. A continuación ejecuta el comando:
C:\>ping -n 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)
Aparecen dos: solicitud y respuesta
Para la solicitud, tipo 8 y código 0.
Para la respuesta, tipo 0 y código 0.
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?
Sí, hacen referencia a la misma máquina ya que la petición la enviamos al router que hace de puerta de enlace por defecto. Si esto no fuera así y hiciéramos el ping a una máquina fuera de nuestra red local, la dirección IP origen y MAC origen no coincidirían.
