Practica 2 apartado 5

Cuestión 5. Mensaje ICMP “Time Exceded”

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)

 

 

La maquina que envia el mensaje de tiempo excedido es el router de la puerta de enlace, en este caso si que podemos saber su direccion Ip y MAC

 

 

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)

 

Podemos observar como ahora no coinciden las direcciones MAC –IP, ya que la direccion ip es la del siguiente punto a partir de la puerta de enlace, mientras que la direccion MAC es la de nmuestra puerta de enlace.

 

 

 

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?

Tipo 11 Codigo 0

 

¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error?

 

Se esta produciendo un bucle cerrado entre las maquinas Cisco 2513 y LINUX 1

 

¿En qué subred estaría ubicada?

 

Subred 10.3.0.0

 

5.d. Repite el ejercicio pero esta vez eleva el tiempo de vida del paquete a 220. ¿Observas el mismo resultado con la misma rapidez?

No

 

¿En cuál de los dos casos ha tardado más la respuesta del ping (en MSDOS)?

 

En este nuevo caso tarda mas la respuesta

Practica 2 apartado 4

Cuestión 4. Mensaje ICMP “Redirect”

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

C:\>route delete 10.4.2.1

C:\>ping -n 1 10.4.2.1

 

 

 

 

 

 

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)

 

 

 

 

Nº data. Tipo y código ICMP Tamaño paquete ICMP         Origen IP        Destino IP

1            tipo 8 código 0          74 bytes                                  172.20.43.207 10.4.2.1

2            tipo5  código 1          70 bytes                                  10.20.43.230   172.20.43.207

3            tipo 0 código 0          74 bytes                                  10.4.2.1           172.20.43.207

 

 

4.b. Dibujar gráficamente el origen y destino de cada datagrama (como se ha realizado en la figura 7, pero incorporando el direccionamiento IP correcto de las máquinas involucradas).

 

 

 

4.c. ¿Observas los mismos datagramas en el Monitor de Red con respecto a los se comentan en la explicación teórica del Redirect? ¿Por qué puede suceder esto?

 

El datagrama que no aparece es la copia del echo que realiza el router uno (puerta de enlace predeterminada 172.20.43.230), esto es debido a que el switch realiza un filtrado por seguridad que consiste en que los mensajes entre routers no puedan ser visualizados por el resto de equipos de la red.

 

 

4.d. ¿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.

 

 

 

Dat. nº             Tipo y código ICMP                 Origen MAC – Origen IP                   ¿mismo interfaz?

1                      Tipo 8 codigo 0(echo request)    00:0a:5e:76:ff:a6    -   172.20.43.207   SI

2                      Tipo 5 codigo 1 (redirect)           00:07:0e:8c:8c:ff   -    172.20.43.230   SI

3                      Tipo 0 codigo 0 (echo reply)      00:d0:ba:eo.6a:3d –     10.4.2.1            SI

 

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

 

El mensaje ICMP redirect es enviado al origen (PC alumno) desde la puerta de enlace predeterminada (172.20.43.230) router cisco 1720

 

4.f. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect? ¿Transporta algún otro tipo de información extra?

 

Contiene un campo de 32 bits llamado direccion de internet del encaminador  que contiene la IP de salida correcta para la maquina emisora, además tambien contiene el encabezado del datagrama que causo el error.

 

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

 

El TTL se modifica siendo en el ping 128 y en el ICM redirect 255, y el cheksum tambien se ve modificado ya que es una suma de control

 

 

 

Practica 2 apartado 3

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

En base a los paquetes capturados, indicar:

 

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)

Paquete           (protocolo/info)         Direccione IP/MAC                                        Equipo

ICMP(ping request)                 Source 172.20.43.207 Destination 10.3.70    PC –LINUX1

               Src: 3com_76:ff:a6 (00:0a:5e:76:ff:a6), Dst: Cisco_8c:8c:ff (00:07:0e:8c:8c:ff)

 

ICMP(destination unreachable)Source 10.4.2.5 Destination 172.20.43.207  cisco 2513 – PC

              Src: Cisco_8c:8c:ff (00:07:0e:8c:8c:ff), Dst: 3com_76:ff:a6 (00:0a:5e:76:ff:a6)

 

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)

CISCO 2513

 

 

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?

Aparecen dos fragmentos tanto para la petición, como para la respuesta

 

 

 

Paquete                       Protocolo                    Info                                        Tamaño

1                      ICMP                          Echo(ping) request                            1514 bytes

2                      IP                                Fragmented ip protocol                       562 bytes

3                      ICMP                          Echo(ping)reply                                1514 bytes

4                      IP                                Fragmented ip protocol                       562 bytes

 

 

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

En dos fragmentos, el primero con un tamaño de 1472bytes de datos icmp, y el siguiente con 528 datos ip

 

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          0 | 0 | 1                    0              0×4dd4

2                      IP                    172.20.43.230           0 | 0 | 0                    1480        0×4dd4

3                      ICMP               172.20.43.207          0 | 0 | 1                     0             0×4dd4

4                      IP                    172.20.43.207           0 | 0 | 0                    1480       0×4dd4

 

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?

 

Que solo visualizamos 1 datagrama para la petición y uno para la respuesta, desaparecen los fragmentados, esto es debido a que cuando se fragmenta solo hay una cabecera icmp situada en el primer fragmento, por lo que en los siguientes fragmentos , los datos son considerados datos ip ya que no se introduce la cabecera icmp

 

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

La identificación se utiliza para saber si los datos pertenecen a un mismo datagrama, es como si le pusiésemos un nombre a todos los pertenecientes al mismo (Datagrama padre).

 

Los flags se utilizan para saber si un datagrama esta partido e indicar el numero de esa partición para saber cuantos quedan o si es el último.

 

Por último el fragment offset, se utiliza para el reensambaldo, ya que indica la posición a patir de la cual deben introducirse los datos de esa trama.

 

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 son 1500 bytes

 

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(request) 172.20.43.195            0 | 0 | 1               0                   0×54ae

2                      IP                    172.20.43.195            0 | 0 | 1               1480             0×54ae

3                      IP                    172.20.43.195            0 | 0 | 0               2960             0×54ae

4                      ICMP(reply)    172.20.43.207            0 | 0 | 1               0                   0×98c8

5                      IP                    172.20.43.207            0 | 0 | 1               1480             0×98c8

6                      IP                    172.20.43.207            0 | 0 | 0               2960             0×98c8

 

 

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

 

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(ping request)                10.3.7.0              0|0|1    0                      0×14aa           

2                      IP(fragmented)                        10.3.7.0              0|0|0    1480                0×14aa

3                      ICMP(pin reply)                      172.20.43.207    0|0|1    0                      0×0059           

4                      IP(fragmented)                        172.20.43.207    0|0|1    480                  0×0059           

5                      IP(fragmented)                        172.20.43.207    0|0|1    960                  0×0059           

6                      IP(fragmented)                        172.20.43.207    0|0|0     1440                0×0059           

 

 

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 hay una subred cuya MTU es menor de 1500 y debe de fragmentarse en mas datagramas.

 

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?

 

 

Atravesamos tres subredes

La primera serìa 172.20.43.230 cuya MTU es de 1500 bytes

La siguiente en atravesar sería 10.4.2.5 con una MTU de 1500 bytes

Y la tercera y última serría la 10.3.7.0 con una MTU de 500 bytes

 

Por tanto podemos dercir que la MTU de la red son 500 bytes.

 

 

 

 

Practica 2 apartado 1

Cuestión 1. Sobre mensajes ICMP del “Ping”

 

Inicia el programa Monitor de Red en modo captura. A continuación ejecuta el comando:

C:\>ping –n 1 172.20.43.230 (…la opción –n especifica el número de peticiones “echo” que se lanzan al medio)

 

Detener la captura en el Monitor de Red (filtrar únicamente tramas del alumno) y visualizar los paquetes

capturados. En base a los paquetes capturados determinar:

 

1.a. ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)

 

 

 

 

 

 

Como podemos observar aparecen dos mensajes icmp uno es un echo request y otro es un echo reply.

 

Los tipos asignados a dichos mensajes son los siguientes:

 

 

Respuesta eco (Echo reply)                 Tipo 0             Código 0

Solicitud eco   (Echo request)              Tipo 8             Código 0

 

  

1.b. Justifica la procedencia de cada dirección MAC e IP. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP “Replay” hacen referencia a la misma máquina o interfaz de red?

 

 

 

Las direcciones MAC e IP origen, hacen referencia a la misma máquina  ya que tanto la dirección MAC como la Ip son las pertenecientes al router del laboratorio sobre el que se ha ejecutado el ping

 

IP        172.20.43.230

MAC   00:07:0E:8C:8C:FF

 

En este caso la la ip coincide con la mac porque la llamada es al router, si ejecutásemos el ping a una dirección fuera del laboratorio, la dirección ip del mensaje sería la de la fuente pero la dirección mac seria la de la puerta de enlace.

 

 

1.c. Justifica la longitud de los paquetes IP. ¿Cuál es el tamaño total del ICMP? ¿Por qué tienen esa longitud?¿Cuántos datos se han transportado en el mensaje “ping”? Dibuja la encapsulación del protocolo ICMP.

 

La longitud total de los paquetes IP son 74 bytes, los cuales se dividen de la siguiente forma

 

| CAB. ETHER.14 bytes | CAB IP 20 bytes | CAB ICMP 8 bytes | DATOS ICMP 32 bytes |

 

Para averiguar los datos de la cabeceras, vamos pinchando en las diferentes líneas de la ventana de información, pudiendo comprobar así, los bytes de la trama total que pertenecen a cada línea, averiguando así el número de bytes de cada cabecera y de los datos.