REDES DE ORDENADORES UNIVERSIDAD DE ALICANTE

.

Prácticas de redes de ordenadores

.
INDUSTORIOUS CLOCK ||| MONO*CRAFTS3.0
olute; height: 11; width: 11;">

Cuestion 2: Sobre la fragmentació de datagramas IP

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

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 ambos casos se ha fragmentado en dos paquetes.


-Los "echo reply" y "echo request" se identifican como IP, y los fragmentos como ICMP.


-Columna 'info' de los fragmentos: "fragmented IP protocol".


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


-En 2


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.




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?



-Sólo aparecen los paquetes con formato ICMP, es decir, los "echo request y reply".


-Esto es así porque los fragmentos se envian con el protocolo IP, mientras que los mensajes de "echo request y reply" utilizan el protocolo de control de errores ICMP


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


-Se pueden utilizar para saber a que paquete corresponde cada fragmento, qué fragmento es y qué tamaño tiene. Con éste último podemos saber el valor de la MTU de una red.


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


-1480 más 34 bytes de cabeceras añadidas=1514


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


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

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




-Porque al enviarlo, el paquete tiene que pasar por una red con una MTU de 1514, por lo que se fragmenta en dos. Pero en el viaje los fragmentos pasan por una subred mas pequeña, y se tienen que fragmentar de nuevo con menor tamaño. Estos son los fragmentos que vuelven.


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

-Las subredes marcadas en rojo tienen la misma MTU. La subred marcada en azul no.


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






- 1: 1514 2: 1514 3: 480

No hay comentarios: