lunes, 20 de abril de 2009

Practica 2 - Apartado 2

Cuestión 2. Sobre la fragmentación 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 (…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?

Tenemos dos paquetes ICMP correspondientes a la petición (echo request) y a la respuesta (echo reply) respectivamente. Y otros dos con protocolo IP identificados como fragmented ip protocol, que corresponden a la petición y respuesta de ICMP realizada.

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

Como indicamos anteriormente, se ha divido cada datagrama original en dos fragmentos. El primero de 1514 bytes y el segundo de 512 bytes.

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

Dirección

Flags

Frag. offset

Identificación

1

ICMP

172.20.43.230 (petición)

0×02 (more fragments)

0

0xc75a (51034)

2

IP

172.20.43.230 (petición)

0×00

1480

0xc75a (51034)

3

ICMP

172.20.43.200 (respuesta)

0×02(more fragments)

0

0×0036 (54)

4

IP

172.20.43.200 (respuesta)

0×00

1480

0×0036 (54)

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?

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?

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. En función de los datos anteriores, indica el valor de la MTU de la red.

El valor de la MTU de la red es 1500 bytes. Es el valor del tamaño máximo de los datagramas que circulan en la red y con el que fragmenta los mismos.

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

Datagrama nº

Protocolo

Dirección

Flags

Frag. offset

Identificación

1

ICMP

172.20.43.195 (petición)

0×02 (more fragments)

0

0×0344 (830)

2

IP

172.20.43.195 (petición)

0×02(more fragments)

1480

0×0344 (830)

3

IP

172.20.43.195 (petición)

0×00

2960

0×0344 (830)

4

ICMP

172.20.43.200 (respuesta)

0×02(more fragments)

0

0×0092 (146)

5

IP

172.20.43.200 (respuesta)

0×02(more fragments)

1480

0×0092 (146)

6

IP

172.20.43.200 (respuesta)

0×00

2960

0×0092 (146)


La diferencia radica en que al enviar en este caso un paquete de 3000 bytes (más las cabeceras) hay que fragmentar el datagrama en 3 partes en vez de dos.

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

(antes de contestar debes confirmar que en MSDOS el resultado del ping es correcto: paquetes enviados:1 , paquetes recibidos:1)



Datagrama nº

Protocolo

Dirección

Flags

Frag. offset

Identificación

1

ICMP

10.3.7.0 (petición)

0×02 (more fragments)

0

0xb37b (45947)

2

IP

10.3.7.0 (petición)

0×00

1480

0xb37b (45947)

3

ICMP

172.20.43.200 (respuesta)

0×02(more fragments)

0

0×00a1 (161)

4

IP

172.20.43.200 (respuesta)

0×02(more fragments)

480

0×00a1 (161)

5

IP

172.20.43.200 (respuesta)

0×02(more fragments)

960

0×00a1 (161)

6

IP

172.20.43.200 (respuesta)

0×00

1440

0×00a1 (161)

2.i. En relación a los datos de la pregunta 2.g. obtenidos del Monitor de Red, contesta:

¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)?

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

Observamos más fragmentos IP de vuelta que de ida debido a que la red que nos manda la respuesta ICMP posee un MTU menor que desde la que enviamos la petición, por tanto nuestro datagrama enviado vuelve más fragmentado.

Como vemos en la siguiente imagen, en las dos primeras redes que atravesamos (línea verde) tenemos un MTU de 1500 por tanto en ese tramo el número de fragmentos de ida y de vuelta es el mismo para la petición y para la respuesta. Pero en la última red que atravesamos (linux1) al poseer un MTU de 500 bytes poseeremos más fragmentos a la vuelta que a la ida, que es lo que nos ocurre en el ping hecho en el último apartado.

Se puede decir entonces que el MTU de la red es 500 bytes (el más pequeño de todos es el que condiciona los demás).

No hay comentarios:

Publicar un comentario