Práctica 2 Redes de Ordenadores
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 ver en la imagen de la captura aparecen dos mensajes de protocolo icmp uno es un echo request (solicitud)y otro es un echo reply(respuesta).
Los tipos asignados a dichos mensajes son los siguientes:
|
Solicitud Eco |
Tipo 8 |
Código 0 |
|
Respuesta Eco |
Tipo 0 |
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?
Tanto la dirección IP destino como la MAC destino, hacen referencia a la misma máquina pertenecientes al router sobre el que hemos ejecutado el ping. Al igual que la dirección MAC e IP origen proceden de la máquina del laboratorio que estoy utilizando.
|
IP ORIGEN 172.20.43.209 |
IP DESTINO 172.20.43.230 |
|
MAC ORIGEN 00:0A:5E:76:90:9D |
MAC DESTINO 00:07:0E:8C:8C:FF |
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 de los paquetes IP es 74 bytes, divididos de la siguiente forma:
|
CABECERA ETHERNET= 14 BYTES |
CABECERA IP = 20 BYTES |
CABECERA ICMP = 8 BYTES |
DATOS ICMP = 32 BYTES |
Para hallar los bytes de las cabeceras y datos, 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.
Cuestión 2. Sobre la fragmentación de datagramas IP
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…)?
Los paquetes que podemos visualizar en la captura son de tipo IP e ICMP. Dos tramas de tipo ICMP para el ‘ping’(solicitud y respuesta eco) y dos tramas de tipo IP para la fragmentación del ‘ping’.
¿qué aparece en la columna ‘info” del Monitor de Red?
La columna info se encuentra situada en el lado derecho de la pantalla de wireshark y nos muestra lo que se ve en la siguiente figura:
2.b. ¿En cuantos fragmentos se ha “dividido” el datagrama original?
Como se puede apreciar en la figura anterior, el datagrama se ha dividido en dos.
2.c. Analiza la cabecera de cada datagrama IP de los paquetes relacionados con el “ping” interior. 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 |
PROTOCOLO |
FLAGS |
FRAGMENT OFFSET |
DIRECCIÓN |
|
IDENTIFICACIÓN |
|
1 |
IP |
0×02 |
0 |
172.20.43.230 |
|
0×045b |
|
2 |
ICMP(request) |
0×00 |
1480 |
172.20.43.230 |
|
0×045b |
|
3 |
IP |
0×02 |
0 |
172.20.43.209 |
|
0×045b |
|
4 |
ICMP(reply) |
0×00 |
1480 |
172.20.43.209 |
|
0×045b |
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?
En la imagen de la captura se puede ver que se visualizan 2 tramas, 1 datagrama de la petición ping y otro de la respuesta ping, el filtro a quitado las tramas de los fragmentos, esto se debe a que al fragmentarse el ping solo hay una cabecera icmp situada en el primer fragmento, y en los siguientes fragmentos los datos son considerados como ip ya que no tienen datos de cabecera icmp.
2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?
El campo identificación se emplea para saber si los datos pertenecen a una misma trama de un datagrama.
El campo flags se emplea para saber si un datagrama está dividido en particiones e indica el numero de esa partición y cuantos hay.
El campo fragment offset, se utiliza para la unión de las particiones, porque indica la posición a partir de la que se deben introducir 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 |
PROTOCOLO |
FLAGS |
FRAGMENT OFFSET |
DIRECCIÓN |
IDENTIFICACIÓN |
|
1 |
IP |
0×02 |
0 |
172.20.43.195 |
0×0665 |
|
2 |
IP |
0×02 |
1480 |
172.20.43.195 |
0×0665 |
|
3 |
ICMP(request) |
0×00 |
2960 |
172.20.43.195 |
0×0665 |
|
4 |
IP |
0×02 |
0 |
172.20.43.209 |
0×7ce8 |
|
5 |
IP |
0×02 |
1480 |
172.20.43.209 |
0×7ce8 |
|
6 |
ICMP(reply) |
0×00 |
2960 |
172.20.43.209 |
0×7ce8 |
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 |
PROTOCOLO |
FLAGS |
FRAGMENT OFFSET |
DIRECCIÓN |
IDENTIFICACIÓN |
|
1 |
IP |
0×02 |
0 |
10.3.7.0 |
0×05b3 |
|
2 |
ICMP(request) |
0×00 |
1480 |
10.3.7.0 |
0×0058 |
|
3 |
IP |
0×02 |
1440 |
172.20.43.209 |
0×0058 |
|
4 |
IP |
0×02 |
960 |
172.20.43.209 |
0×0058 |
|
5 |
IP |
0×02 |
480 |
172.20.43.209 |
0×0058 |
|
6 |
ICMP(reply) |
0×00 |
0 |
172.20.43.209 |
0×0058 |
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 debido a esto los fragmentos del ping con protocolo IP (vuelta) deben de ser más pequeños y 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?
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)
Como se puede apreciar en la imagen de la captura nos aparecen dos tramas de protocolo ICMP.
|
DIRECCION IP/MAC |
EQUIPO |
INFO |
|
10.3.7.0 (00:07:0e:8c:8c:ff) |
LINUX 1 |
Echo (ping) request |
|
10.4.2.5(00:07:0e:8c:8c:ff) |
CISCO 2513 |
Destination unreachable (Fragmentation needed |
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)
Si se observa la imagen del apartado anterior de la captura se puede ver que la máquina que envía este mensaje es la 10.4.2.5 y buscando en la información que nos proporciona wireshark podemos ver su MAC(00:07:0e:8c:8c:ff) y que se trata la máquina del anexo CISCO 2513.
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:
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 |
Tipo= 8;Código= 0; |
74 |
172.20.43.209 |
10.4.2.1 |
|
2 |
Tipo= 5;Código= 1; |
70 |
172.20.43.230 |
172.20.43.209 |
|
3 |
Tipo= 0;Código= 0; |
74 |
10.4.2.1 |
172.20.43.209 |
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 que se comentan en la explicación teórica del Redirect? ¿Por qué puede suceder esto?
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)
Su direcciones IP y MAC se pueden obtener con Wireshark .
|
IP = 172.20.43.230 |
MAC = 00:07:0e:8c:8c:ff |
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)
|
IP = 10.4.2.5 |
MAC = 00:07:0e:8c:8c:ff |
Aunque la IP no sea la misma, la dirección MAC si que lo es, por tanto se trata de la misma máquina que en el caso anterior.
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?
Como se muestra en la figura siguiente se trata de un error ICMP de tipo 11 y código 0.
Lo que sucede es que el TTL se iguala a 0 y por tanto el datagrama se elimina de la red.
El mensaje de error viene de la subred marcada en la siguiente imagen:
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? ¿En cuál de los dos casos ha tardado más la respuesta del ping ( en MSDOS)?
Aún no hay comentarios.
