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?
Obtenemos:
172.20.43.210 172.20.43.230 ICMP Echo (ping) request
172.20.43.210 172.20.43.230 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=74f3)
172.20.43.230 172.20.43.210 ICMP Echo (ping) reply
172.20.43.230 172.20.43.210 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=74f3)
2.b. ¿En cuantos fragmentos se ha “dividido” el datagrama original?
Como podemos observar en el apartado anterior el datagrama original ha sido dividido en el original y en una subdivisión de este.
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 (IP, ICMP,TCP…) | Dirección | Flags | Frag. offset | Identificación |
1 | Icmp | Request | 0X01 | 0 | 0x74f3 (29939) |
2 | Ip | Request | 0x00 | 1480 | 0x74f3 (29939) |
3 | Ìcmp | Reply | 0x01 | 0 | 0x74f3 (29939) |
4 | ip | Reply | 0x00 | 1480 | 0x74f3 (29939) |
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?
Pues que modificamos la visualización, pero no los eliminamos, por lo que en este caso, no veríamos la fragmentación del paquete.
2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?
Para saber si se trata de la continuación de un paquete, o si se trata de su predecesor. La longitud donde debe de empezar el paquete actual, para que tenga sentido con el resto, por ejemplo si es el inicio de un paquete es 0, pero si se trata de una división, nos dice el bit, donde debe de continuar el paquete.
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 nº | Protocolo | Dirección | Flags | Frag. offset | Identificación |
1 | icmp | Request | 0x01 | 0 | 0x7cfe (31998) |
2 | ip | Request | 0x00 | 1480 | 0x7cfe (31998) |
3 | Ip | Reply | 0x00 | 1440 | 0x009f (159) |
4 | Ip | Reply | 0x01 | 960 | 0x009f (159) |
5 | Ip | Reply | 0x01 | 480 | 0x009f (159) |
6 | icmp | reply | 0x01 | 0 | 0x009f (159) |
El motivo por el cual, obtenemos más paquetes de respuesta que de petición es debido a que la ip destino, está integrada en una red con ip de tipo a, lo que nos indica que la longitud de los datagramas es menor. Y por ello se fragmenta.
Como podemos observar, la respuesta del router ha sido enviada al revés, y pese a ello el comando ping no ha dado error, por lo que podemos determinar que nuestro ordenador a recombinado los paquetes (debería de haber dado error, porque la bandera del primer paquete de Reply era 0x00 lo que nos indicaría que no se van a enviar paquetes después de este).
No hay comentarios:
Publicar un comentario