Cuestión 7. Sobre direccionamiento IP y creación de subredes

1. 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.
   
   Para crear 6 subredes necesitaremos 3 bits más.
   
   IP = 145.65.0.0 = 10010001.01000001.00000000.00000000
   
   Subredes:
   s1: 10010001.01000001.00000000.00000000 = 145.65.0.0
   s2: 10010001.01000001.00100000.00000000 = 145.65.32.0
   s3: 10010001.01000001.01000000.00000000 = 145.65.64.0
   s4: 10010001.01000001.01100000.00000000 = 145.65.96.0
   s5: 10010001.01000001.10000000.00000000 = 145.65.128.0
   s6: 10010001.01000001.10100000.00000000 = 145.65.160.0
   
   Nueva máscara de subred:
   Ponemos a 1 todos los bits que utilizamos en las direcciones IP, los bits que no usamos los ponemos a 0.
   
   11111111.11111111.11100000.00000000 == 255.255.224.0
   
   
2. 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.
   
   Como queremos ampliar en 2 bits la máscara de subred debemos cambiar a 1 los dos primeros bits de la máscara que tengan valor 0.
   
   IP = 125.145.64.0 = 01111101.10010001.01000000.00000000
   Máscara = 255.255.254.0 = 11111111.11111111.11111110.00000000
   
   Ampliamos la máscara en 2 bits.
   Nueva máscara de subred:
   Máscara = 11111111.11111111.11111111.10000000 = 255.255.255.128
   
   Subredes:
   S1: 01111101.10010001.01000000.00000000 = 125.145.64.0
   S2: 01111101.10010001.01000000.10000000 = 125.145.64.128
   S3: 01111101.10010001.01000001.00000000 = 125.145.65.0
   S4: 01111101.10010001.01000001.10000000 = 125.145.65.128
   
   Rango de direcciones IP:
   
   Rango S1:
   Inicio == 125.145.64.1
   Fin == 125.145.64.126
   
   Rango S2:
   Inicio == 125.145.64.129
   Fin == 125.145.64.254
   
   Rango S3:
   Inicio == 125.145.65.1
   Fin == 125.145.65.126
   
   Rango S4:
   Inicio == 125.145.65.129
   Fin == 125.145.65.254
   
   LA dirección IP final de las subredes S1 y S2, termina en 126 y no en 127 como sería lo lógico ya que con 127 la IP tendría todos sus bytes a 1 y eso sería la dirección de Broadcast. Por eso se pone 126, para que no coincida con la dirección de broadcast.
   

Cuestión 6. Mensaje 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 paquetes en un tiempo limitado.
Iniciar el Monitor de Red. A continuación ejecutar el comando "Ping" en varias ventanas 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:

1. ¿De qué máquina proceden los mensajes ICMP "Fragment Reassembly Time Exceeded"?
   
   IP: 10.3.7.0
   MAC: 00:07:0e:8c:8c:ff (172.20.43.230)
   
   La direccion MAC se corresponde con la puerta de enlace de la red
   
   
2. ¿Por qué crees que pueden proceder de esta máquina y no de otra?
   
   Procede de esa máquina porque es la encargada de redireccionar los mensajes que mandemos a la red.

Cuestión 5. Mensaje 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

1. Finaliza la captura e indica que máquina envía el mensaje "ICMP Time to Live exceeded in Transit".... ¿Puedes saber su IP y su MAC?
   
   IP: 172.20.43.230
   MAC: 00:07:0e:8c:8c:ff
   
   Esta dirección corresponde con la máquina que actúa como nuestra puerta de enlace.

Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\>ping -i 2 -n 1 10.3.7.0

2. Finaliza la captura y determina qué máquina envía ahora el mensaje "ICMP Time to Live exceeded in Transit"... Averigua y anota la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina?
   
   IP: 10.4.2.5
   MAC: 00:07:0e:8c:8c:ff
   
   No pertenecen a la misma máquina. La dirección MAC pertenece al router por el cual salimos al exterior de nuestra red y la dirección IP pertenece al siguiente router por el que pasamos debido a que el TTL es 2, por eso el datagrama no avanza mas ya que solo puede dar 2 saltos.

Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\>ping -i 50 -n 1 10.3.7.12

3. 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 de error? ¿En qué subred está ubicada?
   
   Mensaje error
   Tipo: 11
   Codigo: 0
   
   Como la máquina a la que le hemos hecho el ping no existe, el mensaje viaja entre los 2 routers que engloban esa subred hasta que al mensaje se le agote su tiempo de vida (TTL) que en este caso hemos hecho que sea de 50.
   

Cuestión 4. Mensaje 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:

1. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos...(tipo, código y tamaño)
   
   
   Como se puede ver, hemos capturado 3 tramas. En la primera trama hacemos la petición y enviamos el paquete, en la segunda trama la puerta de enlace nos redirecciona y nos dice por donde debemos mandar nuestro paquete y la tercera trama la maquina a la que le hemos hecho la petición nos devuelve la respuesta.
   Aunque veamos 3 tramas en el monitor de red, en verdad son 4 las tramas que se mueven por la red. La trama que no se ve en el monitor de red es la que va desde la puerta de enlace hasta la máquina destino y donde la puerta de enlace redireciona el paquete que hemos enviado y se lo manda directamente a la máquina destino.
   
   
   
2. ¿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 qué casos la dirección IP especifica un interfaz de redque no se corresponde con el mismo interfaz indicado por la MAC.
   


En la tercera trama, las direcciones IP y MAC no están a la misma interfaz porque las máquinas con esas direcciones no están en la misma red local.


3. ¿Qué máquina o interfaz de red envía el mansaje ICMP Redirect?
   
   Lo manda nuestra puerta de enlace predeterminada con dirección IP 172.20.43.230
   
   
4. ¿Qué dato importante para tu Pc transporta en su interior ese mendaje de Redirect?
   
   El mensaje de Redirect transporta la información del mensaje original que causó el error de redirección.
   
   
   
   
5. Observa los campos "Identifiación", "TTL" y "Checksum" del datagrama que se envió originalmente. A continuación, analiza el contenido del mensaje Redirect. ¿Puedes encontrar la misma informació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?
   
   
   • Datagrama original:
     Identificación: 0x4b7a (19322)
     TTL: 128
     Cheksum: 0x185c [correct]
     
     
   • Datagrama redirect:
     Identificación: 0x4b7a (19322)
     TTL: 127
     Cheksum: 0x185c [incorrect, should be 0xc2ff]
   
   Como podemos observar la información de los 2 datagramas si que es la misma, pero el TTL tiene una unidad menos de valor. Esto se debe a que el mensaje de Redirect al pasar por un router mas que el original, su tiempo de vida disminuye, ya que el "TTL" (tiempo de vida" indica cuantos saltos puede dar un datagrama o lo que es lo mismo, por cuantos routers puede pasar antes de morir.

Cuestión 3. Mensaje 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 MSWindows, 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 específica. 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:

1. Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen? (indentifica la máquina con la topología del anexo)
   
   
   
   • Trama 1:
     MAC origen: 00:0a:5e:76:ff:89
     IP origen: 172.20.43.220
     MAC destino: 00:07:0e:8c:8c:ff
     IP destino: 10.3.7.0
     
     
   • Trama 2:
     MAC origen: 00:07:0e:8c:8c:ff
     IP origen: 10.4.2.5
     MAC destino: 00:0a:5e:76:ff:89
     IP destino: 172.20.43.220
   
   Como podemos ver la máquina que nos responde no es la misma a la que le hacemos la petición. La dirección que nos manda la trama de respuesta corresponde con uno de los routers cisco del laboratorio por el cual pasa nuestro mensaje.
   
   
2. ¿Qué máquina de la red envía el mensaje ICMP "Fragmentation Needed and Don't Fragment was Set" (3/4)?
   
   Como hemos comentado en el apartado anterior, la maquina que nos responde no es la misma a la que le hemos hecho la petición. Eso se debe a que como no queremos fragmentar el datagrama y el medio al que le hemos hecho la petición es más pequeño que nuestro datagrama, el router en la dirección 10.4.2.5 nos devuelve una trama ICMP donde nos indica que debemos fragmentar el datagrama para poder enviarlo.
   

Cuestión 2. Sobre la fragmentación de datagramas IP (II)

4. ¿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?
   
   Si filtramos solo los paquetes "icmp" solamente vemos 1 fragmento de pedido y otro de respuesta y no 2 de cada como veíamos antes. Esto es debido a que el monitor de red solo reconoce como "icmp" el primer fragmento de cada mensaje ya que este es el que lleva las cabeceras de información.
   
   
5. ¿Para qué se pueden emplear los campos "Identificación", "Flags" y "Fragment Offset" de los datagramas IP?
   
   
   • Identificación: Para marcar de forma única cada datagrama enviado.
     
   • Flags: Informa sobre si hay mas fragmentos del mismo paquete (0x01) o de si es el último (0x00).
     
   • Fragment offset: Sirve para saber donde va cada paquete.
   
   
   
6. A continuacó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 sigiente comando:
   "C:/>ping -n 1 -l 1600 10.3.7.0"
   Indica el número total de datagramas en la red e identifica si son de petición orespuesta.
   
   En este caso nuestro datagrama es de 1600 bytes, pero al ser el medio al que lo mandamos mucho más pequeño, el datagrama se fragmenta es mas partes (4) que cuando atraviesa nuestro medio (2 partes).

DatagramaNº	Protocolo	Dirección	Flags	Frag.offset	Identificación
1	ICMP	petición	0x01	0	25472
2	IP	petición	0x00	1480	25472
3	IP	respuesta	0x00	1440	160
4	IP	respuesta	0x01	960	160
5	IP	respuesta	0x01	480	160
6	ICMP	respuesta	0x01	0	160

Cuestión 2. Sobre la fragmentación de datagramas IP (I)

Empleando el 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)

1. 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 estod paquetes (ICMP, IP, HTTP, TCP...)? ¿Qué aparece en la columna "info" del monitor de red?
   
   Aparecen 4 tramas, 2 de pedido y 2 de respuesta. Esto es debido a que el datagrama supera su tamaño máximo de 1500 bytes (con el comando -l hemos hecho un datagrama de 2000 bytes) por eso se ha fragmentado, para poder hacer llegar el mensaje. En cada una de las peticiones la trama de mayor tamaño tiene el protocolo ICMP, esto es debido a que las cabeceras del mensaje se encuentran ahi y reconoce el mensaje como ICMP. En cambio, la otra trama aparece con el protocolo IP debido a que esa trama solo contiene los datos sobrantes que no han cabido en la otra trama.
   
   
2. ¿En cuantos fragmentos se ha "dividido" el datagrama original?
   
   Como hemos comentado en el apartado anterior, el datagrama original de 2000 bytes se ha dividido en 2 fragmentos, una de 1472 bytes y otro de 528.
   
   
3. 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 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	Petición	0x01	0	21966
2	IP	Petición	0x00	1480	21966
3	ICMP	Respuesta	0x01	0	21966
4	IP	Respuesta	0x00	1480	21966