miércoles, 25 de marzo de 2009

Cuestión 3

Mensaje ICMP "Destination Unreachable


Dentro del mensaje ICMP Destination Unreachable se analizará el de código 4: Fragmentation Needed an 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)


¿Por qué ejecutar este comando? En MS Windows, con route se modifican las tablas de encaminamiendo 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)


IP --> 172.20.43.202 / MAC --> 00:0A:5A:76:FF:2A IP y MAC de mi equipo (PCs de los alumnos)


IP --> 10.3.7.0 (Linux 1) / MAC --> 00:07:0E:8C:8C:FF MAC perteneciente a la máquina con IP 172.20.43.230 (CISCO 1720)


IP --> 10.4.2.5 (CISCO 2513) / MAC --> 00:07:0E:8C:8C:FF MAC perteneciente a la máquina con IP 172.20.43.230 (CISCO 1720)



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)


La máquina que envía el mensaje de error es la que tiene la IP 172.20.43.230 (Cisco 1720)

lunes, 23 de marzo de 2009

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?




Para filtrar los paquetes en los que está involucrada mi dirección IP aplico el filtro ip.src==172.20.43.202 ip.dst==172.20.43.202 && !nbns, siendo 172.20.43.202 mi dirección IP.

El primer paquete de la petición (request) o de la respuesta (reply) está identificado con el protocolo IP y en la columna "info" aparece el mensaje "Fragmented IP protocol".


El segundo paquete de las peticiones (request) o de la respuesta (reply) está identificado con el protocolo ICMP y en la columna "info" aparece el mensaje "Echo (ping) request" o "Echo (ping) reply", según el caso.


2.b. ¿En cuántos fragmentos se ha "dividido" el datagrama original?

Tal y como se puede apreciar en la captura del Monitor de Red, el datagrama original se ha dividido en 2 fragmentos.


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 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 el el Monitor de Red.



2.d. ¿Qué ocurre en la visualización de los fragmentos de datagramas si introduces un filtro para ver únicamente paquetes "icmp" en el Monitor de Red? ¿qué fragmentos visualizas ahora? ¿por qué puede suceder esto?


Ahora solo se visualizan 2 fragmentos de datagramas, uno de petición y otro de respuesta.

Esto sucede porque al ser los datagramas muy largos (contienen muchos datos) se fragmentan en 2 datagramas y solo uno de ellos contiene la cabecera del protocolo 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éramos 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 lanzando 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):



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

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




2.i. En relación a los datos de la pregunta 2.g. obtenidos en el Monitor de Red, contesta:

¿Por qué se observan más fragmentos IP de "vuelta" (respuesta) que de "ida" (petición)?

Porque para llegar a la IP de destino, los paquetes atraviesan una subred cuya MTU es de 500 bytes, por ello se deben fragmentar más para poder llegar al destino.

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.


En las subredes cuya MTU es de 1500 bytes, el número de fragmentos que circulan por el medio es el mismo tanto en la petición como en la respuesta. Pero en la subred que tiene una MTU de 500 bytes el número de fragmentos que circulan por el medio es mayor cuando existe comunicación desde una subred con MTU mayor.

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?


La trayectoria de los datagramas, está resaltada en la figura adjunta, la trayectoria resaltada en rojo son las subredes con MTU de 1500 bytes, y la resaltada en azul es la que tiene una MTU de 500 bytes.

Se observa que se atraviesan 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 sería la 10.3.7.0 con una MTU de 500 bytes

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

sábado, 14 de marzo de 2009

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 las tramas del alumno) y visualizar los paquetes capturados. En base a los paquetes capturados deteterminar:



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

Para filtrar únicamente las tramas pertenecientes a mi ordenador introduzco el siguiente filtro: ip.src==172.20.43.202 ip.dst==172.20.43.202 && !nbns, siendo 172.20.43.202 mi dirección IP.

Obtengo 2 tramas, la de petición (request) y la de respuesta (reply), que son de los siguientes tipos:

Request: Tipo=8; Código=0
Reply: Tipo=0; Código=0

Un mensaje ICMP de tipo 8 significa que es una solicitud de Eco, mientras que cuando un mensaje ICMP es de tipo 0 quiere decir que es una respuesta de Eco.


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

Las direcciones de origen del mensaje ICMP "Reply" son:

IP=172.20.43.230
MAC=00:07:0E:8C:8C:FF

Las cuales se corresponden con la máquina a la que hemos enviado el comando ping.


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 la trama es de 74 bytes de los que los 14 primeros bytes pertenecen a la cabecera Ethernet, los siguientes 20 bytes son de la cabecera IP, 8 bytes pertenecen a la cabecera ICMP y los 32 bytes restantes son de datos (se puede apreciar en la captura de MSDOS que el ping se hace con 32 bytes).


Encapsulación del protocolo ICMP

martes, 10 de marzo de 2009

Práctica 2: Protocolo de Mensajes de Control de Internet (ICMP)


El objetivo de la práctica 2 de la asignatura Redes de Ordenadores (Teleco UA) es profundizar el en funcinamiento del protocolo de mensajes de control y error ICMP. También se analizarán en detalle diferentes campos de la cabecera del datagrama IP.

El alumno adquirirá conocimientos acerca de los diferentes mensajes ICMP y su utilidad a la hora de controlar una red de ordenadores. En la realización de la práctica se abordarán distintas situaciones de error en el funcionamiento de una red de datagramas basada en el protocolo IP y se evaluará de forma práctica los tiempos de respuesta de la red.