Cuestión 7 - Teórica

7.a Dada la dirección de clase B 145.65.0.0, se desean 6 subredes. ¿Cuántos bits se tendrán que reservar para crear las subredes? Indica el valor decimal de las subredes, así como el valor de la nueva máscara de subred.
Se necesitan reservar 3 bit, porque con 2 solo podríamos dividirla en 4 subredes. Esto es debido a la siguiente relación: 2^n. por lo que para los 3 bits que poseemos estas serían las subredes posibles.

145.65.0.0 - 11111111.11111111.000 00000.00000000
145.65.32.0 - 11111111.11111111.001 00000.00000000
145.65.64.0 - 11111111.11111111.010 00000.00000000
145.65.96.0 - 11111111.11111111.011 00000.00000000
145.65.128.0 - 11111111.11111111.100 00000.00000000
145.65.160.0 - 11111111.11111111.101 00000.00000000
145.65.192.0 - 11111111.11111111.110 00000.00000000
145.65.224.0 - 11111111.11111111.111 00000.00000000

De estas 8 subredes podemos elegir las 6 que más nos interesen.

7.b Sea la dirección de red IP 125.145.64.0 con máscara asociada 255.255.254.0. Ampliar la máscara de subred en dos bits, indicando el nuevo valor. Determina el rango de direcciones IP que puede emplearse para numerar máquinas en cada una de las subredes obtenidas en la ampliación.


125.145.64.0 – 11111101.10010001.01000000.00000000

255.255.254.0 – 11111111.11111111.11111110.00000000

11111111.11111111.1111111X.X0000000
Solo podemos modificar los valores determinados con las X, siendo las posibilidades:

A - 0.0 que corresponde con la IP: 125.145.64.0
B - 0.1 que corresponde con la IP: 125.145.64.128
C - 1.0 que corresponde con la IP: 125.145.65.0
D - 1.0 que corresponde con la IP: 125.145.65.128

Rango de IP’s para las subredes teniendo en cuenta la que debemos de guardar para la denominación de las propia subred, y de la dirección de “broadcast”

A:
125.145.64.1
125.145.64.126
B:
125.145.64.129
125.145.64.254
C:
125.145.65.1
125.145.65.126
D:
125.145.65.129
125.145.65.254

Cuestión 6 - ICMP “Fragment Reassembly Time Exceeded”

En esta cuestión se analizará el mensaje ICMP tipo 11 código 1. Para ello, se va a intentar “saturar” a una determinada máquina del laboratorio enviándole un número elevado de peticiones Ping. Este elevado número de peticiones puede producir un error si la máquina destino tiene que realizar un reensamblado excesivo de de paquetes en un tiempo limitado. Iniciar el programa monitor de red. A continuación ejecutar el comando “Ping” en varias ventanas (en paralelo) de MSDOS, así lograrás mayor número de peticiones:
C:\>ping -n 80 -l 20000 10.3.7.0 Detener la captura y determinar:
6.a. ¿De que máquina proceden los mensajes ICMP “Fragment Reassembly Time Exceded”? (identifica la máquina en la topología del anexo)


Como bien se puede observar en la ilustración superior el elemento de Red que nos envia el mensaje es:

La dirección IP - 10.3.7.0 que en la topología es la Máquina Linux 1

6.b. ¿Por qué crees que pueden proceder de esa máquina y no de otra?

Por que se trata de esta máquina la que intenta recomponer los paquetes y al no tener capacidad para ello envía este mensaje de error.

Cuestión 5 - ICMP “Time Exceeded”

Dentro del mensaje ICMP Time Exceeded se analizará el de código 0: Time to Live exceeded in Transit (11/0). En primer lugar, inicia el monitor de red para capturar paquetes IP relacionados con la máquina del alumno y ejecuta el comando:
C:\> ping –i 1 –n 1 10.3.7.0
5.a. Finaliza la captura e indica máquina que envía el mensaje “ICMP Time to Live exceeded in Transit”… ¿Puedes saber su IP y su MAC? (identifica la máquina en la topología del anexo)

Dentro del paquete podemos ver gracias al protocolo Ethernet las MAC que han tomado parte y las direcciones IP gracias a su protocolo y podemos saber gracias a esto que son:

El router Cisco_8c:8c:ff - 172.20.43.230

Inicia de nuevo la captura y ejecuta a continuación el comando:

C:\> ping –i 2 –n 1 10.3.7.0

5.b. Finaliza la captura y determina qué máquina envía ahora el mensaje “ICMP Time to Live exceded in Transit”… Averigua y anota la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina? (identifica las máquinas en la topología del anexo)

Responde el Cisco_8c:8c:ff – 10.4.2.5

No responde la misma Máquina y eso lo podemos ver en la dirección IP desde donde se responde. Que posea la misma MAC que en el apartado anterior quiere decir que el ultimo mensaje que se ha enviado ha sido desde esa dirección, pero no ha sido ella quien lo ha enviado. Esto es por que le hemos añadido más posibles saltos al paquete ping.

Por último, inicia de nuevo la captura y realiza un ping a la siguiente dirección:

C:\> ping –i 50 –n 1 10.3.7.12

5.c. Finaliza la captura y observa el mensaje de error ICMP que aparece en el monitor de red. ¿Qué tipo y código tiene asociado ese mensaje? ¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error? ¿En qué subred estaría ubicada?

Aquí tenemos una ilustración con los mensajes que nos reenvian.

Este paquete tiene Tipo 11 con Código 0.

Creo que lo que está sucediendo es que esa dirección esta en una red que está ubicada bajo un gran número de putos intermedios y que nuestra petición de ping no es capaz de resolverlo. Ya que está limitada a un tiempo de vida de 50.

Cuestión 4 - ICMP "Redirect"

Inicia el Monitor de Red. A continuación ejecutar los comandos:

C:\>route delete 10.4.2.1 (si ya ha sido borrada la ruta, avisa con un error)

C:\>ping -n 1 10.4.2.1

(antes de contestar debes confirmar que en MSDOS el resultado del Ping es correcto: paquetes enviados:1 , paquetes recibidos:1, sino debes repetir los dos comandos anteriores y el proceso de captura en el Monitor de Red)

En base a los paquetes capturados, filtra sólo los datagramas que contengan tu dirección IP y contesta a las siguientes preguntas:

4.a. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos…(tipo, código y tamaño)

Datagrama nº	Tipo y código ICMP	Tamaño del paquete ICMP	Origen IP Destino IP
1	Type: 8 Code: 0	32 Bytes	172.20.43.200 - 10.4.2.1
2	Type: 5 Code: 1 Type: 8 Code: 0	-	172.20.43.230 - 172.20.43.207
3	Type: 0 Code: 0	32 Bytes	10.4.2.1 – 172.20.43.200

4.b. ¿Las direcciones MAC e IP de todas las tramas capturadas con el Monitor de Red hacen referencia al mismo interfaz de red? Indica en qué casos la respuesta es afirmativa y en que casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

*Según la tabla de ARP esta MAC correspondería a la dirección 172.20.43.231

De todas formas en esta comunicación faltaría un paquete que sería el de la copia "petición ICMP" que es el paquete que se reenvia.

4.c. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?

Nos responde el router que corresponde a nuestra puerta de enlace predeterminado.

4.d. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect?

Type: 5 (Redirect)

Code: 1 (Redirect for host)

Gateway address: 172.20.43.231 (172.20.43.231)

Finalmente el dato más importante es el último que te dice la nueva dirección que debe de tomar los paquetes.

4.e. Observa los campos “Identificación”, “TTL” y “Cheksum” del datagrama que se envió originalmente. A continuación, analiza el contenido del mensaje Redirect. ¿Puedes encontrar la misma identificación dentro de los datos (no cabecera) del mensaje ICMP Redirect? ¿Qué ocurre con los campos TTL y Cheksum del datagrama transportado por el Redirect?

Si, podemos encontrar los mismo campos pero vemos como se han visto modificados el Time To Live reduciendose en este caso si pudieramos ver el paquete que en el apartado b hemos dicho que se suprimía veríamos como el TTL se ha reducido en uno. Las sucesivas respuestas desde el Router 1 y desde la máquina final se ve como tanto el Cheksum y el TTL son totalmente distintos entre ellos.

Cuestión 3 - ICMP “Destination Unreachable”

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)

¿Porqué 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)

Ilustración de la captura realizada

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)

En el envio del paquete ping, como observamos en la imagen superior con fuente la máquina del alumno, con destino a la dirección 10.3.7.0 perteneciente a la máquina Linux .

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)

Pero a la máquina del alumno le devuelve un error la dirección IP 10.4.2.5 perteneciente al router Cisco 2513. Esto significa que este Router devuelve a la máquina de usuario una mensaje diciendo la longitud MTU del siguiente nodo de la red es 500, el del paquete sin posibilidad de fragmentación que mandamos era de 1000, por lo que no se puede entregar al siguiente tramo de red, por lo que se nos devuelve este error.

Cuestión 2 - Fragmentación 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?

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