domingo, 27 de abril de 2008

Práctica 2.- Protocolo de Mensajes de control de Internet (ICMP). Cuestión 2.- Sobre la fragmentación de datagramas IP.

Cuestión 2. Sobre la fragmentación de datagramas IP.

Empleando el programa Monitor de Red da la misma forma que en la situación anterior, ejecutamos:

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?


Figura 2.a.1.- "Ping" hacia 172.20.43.230 con 2000 bytes de datos.



Figura 2.a.2.- Captura con paquetes IP e ICMP.

Paquetes 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 de datos ICMP con un tamañao de 1472 bytes, más 8 bytes de cabecera ICMP, más 20 bytes de cabecera IP y más 14 bytes de cabecera ETHERNET, el siguiente fragmento de datos IP con un tamaño de 528 bytes, más 20 bytes de cabecera IP y más 14 bytes de cabecera ETHERNET (en las tramas IP no van incluidos los 8 bytes correspondientes a la cabecera ICMP).

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 172.20.43.230 001 0
2 IP 172.20.43.230 000 1480
3 ICMP 172.20.43.205 001 0
4 IP 172.20.43.205 000 1480



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 únicamente visualizamos dos fragmentos de datagramas, uno para la petición y otro para la respuesta, desaparecen los datagramas fragmentados de tipo IP, esto es debido a que en el proceso de fragmentación solo existe una trama que contiene la cabecera ICMP (la primera de todas), el resto de tramas al no contener dicha cabecera se consideran datos IP y se filtran de manera que no son visualizados.


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.
-Los flags se utilizan para saber si un datagrama está partido y si quedan más bloques o ese es el último.
-El fragment offset se utiliza para el reensamblado e indica la posición a patir de la cual se deben introducir los datos en 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 es de 1500 bytes (el valor de la MTU de una red será siempre el valor de la MTU de la subred más pequeña).


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



Figura 2.g.1.- "Ping" hacia 172.20.43.195 con 3000 bytes de datos.


Datagrama nº Protocolo (IP, ICMP,TCP…) Dirección Flags Frag. offset Identificación


1 ICMP (request) 172.20.43.195 001 0
2 IP 172.20.43.195 001 1480
3 IP 172.20.43.195 000 2960 4 ICMP (reply) 172.20.43.205 001 0 5 IP 172.20.43.205 001 1480 6 IP 172.20.43.205 000 2960



2.h. A continuación, se pretende observar que los datagramas pueden fragmentarse en unidades máspequeñ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):



Figura 2.h.1.- "Ping" hacia 10.3.7.0 con 1600 bytes de datos.

Figura 2.h.2.- Captura con fragmentación.


Datagrama nº Protocolo (IP, ICMP,TCP…) Dirección Flags Frag. offset Identificación
1 ICMP (request) 10.3.7.0 001 0
2 IP 10.3.7.0 000 1480
3 ICMP (reply) 172.20.43.205 001 0
4 IP 172.20.43.205 001 480
5 IP 172.20.43.205 001 960
6 IP 172.20.43.205 000 1440



2.i. En relación a los datos de la pregunta 2.g. 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 con una MTU menor a 1500 bytes y por ello se debe fragmentar en más 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?


Figura 2.h.- Topología de la red del laboratorio.


Cuando realizamos el "ping" atravesamos 3 subredes.

- La 1ª sería la 172.20.43.230 (puerta de enlace con la que salimos al exterior) con una MTU de 1500 bytes.

- La 2ª en atravesar sería la 10.4.2.5 con una MTU también de 1500 bytes.

- Por último atravesamos la 10.3.7.0 (dirección a la que hacemos la petición), está subred tiene una MTU de 500 bytes.


Por lo tanto podemos confirmar que la MTU de la red es de 500 bytes.

lunes, 21 de abril de 2008

Práctica 2.- Protocolo de Mensajes de Control de Internet (ICMP). Cuestión 1.- Sobre mensajes ICMP del "Ping".

Cuestión 1.- Sobre mensajes ICMP del "Ping".

Antes de nada, ejecutamos: c:\pracredes.bat.

Iniciamos el programa Monitor de Red en modo captura. A continuación desde la consola de MS-DOS ejecutamos 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)



1.a.1.- "Ping" con un paquete de 32 bytes de datos a la dirección 172.20.43.230.

Detenemos la captura en el Monitor de Red (filtramos únicamente nuestras tramas) y visualizamos los paquetes capturados.

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


1.a.2.- Captura con el monitor de red, los mensajes que aparecen son dos: el primero de ellos es un "echo (ping) request", tipo: 8 (Solicitud de Eco), código: 0 . El segundo de ellos es un "echo (ping) reply", tipo: 0 (Respuesta de Eco), código: 0.


1.a.3.- SOLICITUD DE ECO.


1.a.4.- RESPUESTA DE ECO.


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?


  • Dirección IP origen del mensaje ICMP "Request": 172.20.43.205

  • Dirección MAC origen del mensaje ICMP "Request": 00:0a:5e:76:ff:99

  • Dirección IP destino del mensaje ICMP "Request": 172.20.43.230

  • Dirección MAC destino del mensaje ICMP "Request": 00:07:0e:8c:8c:ff
  • Dirección IP origen del mensaje ICMP "Reply": 172.20.43.230

  • Dirección MAC origen del mensaje ICMP "Reply": 00:07:0e:8c:8c:ff

  • Dirección IP destino del mensaje ICMP "Reply": 172.20.43.205
  • Dirección MAC destino del mensaje ICMP "Reply": 00:0a:5e:76:ff:99

Nuestra máquina con dirección ip: 172.20.43.205 y dirección MAC: 00:0a:5e:76:ff:99 envía un paquete de 32 bytes de tamaño a la máquina con dirección ip: 172.20.43.230, esta verifica que el solicitante (es decir, nosotros) pide su dirección ip y dicha máquina emite una respueta. Esta respueta contiene la dirección IP y la dirección MAC: 00:07:0e:8c:8c:ff correspondiente.

Como se observa, el paquete “echo reply ” hace el mismo camino que el “echo request” pero en sentido inverso, es decir, es la respuesta que da el destino al origen al enviar un paquete “echo request”.

También se observa que estamos tratando de nivel local, es decir, que estamos haciendo el ping a una máquina que esta dentro de nuestra red, esto se observa puesto que las MAC de origen y de destino corresponden a la de las dos máquinas, si hubieramos salido al exterior, las MAC se corresponderían con la de las puertas de enlace y no con la de las propias máquinas.


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 de 74 bytes (14 bytes de cabecera ethernet, 20 de cabecera IP, 8 bytes de cabecera ICMP y 32 bytes de datos).

Al lanzarle mediante -n 1 una única petición "echo" al medio, estamos enviando un único paquete de 32 bytes de tamaño de datos, a este tamaño de datos hay que sumarle los 20 bytes de la cabecera ip y otros 8 de la icmp. En total, el tamaño del mensaje "ping" sería de 60 bytes como podemos comprobar en el Monitor de Red, habría que sumarle los 14 bytes de la cabecera ethernet.

1.c.1.- Mensaje ping (datagrama IP).


1.c.2.- Cabecera IP.


1.c.3.- Longitud total del paquete IP.


El tamaño total del ICMP es de 40 bytes en este caso, debido a los 8 de icmp y 32 bytes de la trama de datos.



1.c.4.- Encabezado ICMP (de 8 bytes) y Datos ICMP (32 bytes).

1.c.5.- Encapsulación de protocolo ICMP.

1.c.6.- Esquema general de mensaje ICMP.


1.c.7.- Datagrama de datos.


Redes de Ordenadores


REDES DE ORDENADORES
ING. TÉCNICA DE TELECOMUNICACIÓN. ESP. EN SONIDO E IMAGEN
PROGRAMA DE PRÁCTICAS.-


- Bloque 1: INTRODUCCIÓN A REDES Y A TCP/IP SOBRE TECNLOGÍA ETHERNET.

- Bloque 2: PROTOCOLO DE MENSAJES DE CONTROL DE INTERNET (ICMP).

- Bloque 3: PROTOCOLOS DE NIVEL DE TRANSPORTE EN TCP/IP.

BLOQUE 1:
Introducción a Redes y a TCP/IP sobre tecnología Ethernet.-

La primera práctica de la asignatura Redes pretende introducir al alumno en las redes de computadores de forma práctica. Para ello se realizará el estudio de una Red de Área Local (LAN) que emplea la arquitectura de red TCP/IP. Esta arquitectura de red se ha convertido en un estándar para los sistemas de transmisión de datos actuales y proporciona la tecnología base para multitud de aplicaciones: correo electrónico, servidores WWW, servidores FTP, IRC, comercio electrónico, acceso a bases de datos remotas, tecnología WAP, etc.
Con la realización de esta práctica el alumno debe adquirir conocimientos que le permitan:
• Reconocer los diferentes niveles de la arquitectura TCP/IP y qué funcionalidad tienen en la comunicación de datos.
• Interpretar el funcionamiento de los protocolos Ethernet, ARP e IP en base a la información capturada por el monitor de red.
• Conocer el esquema de direccionamiento empleado por el protocolo IP.
• Realizar la captura de cualquier paquete de datos que se desee, empleando el software del monitor de red y ser capaz de analizarlos.
BLOQUE 2:
Protocolo de Mensajes de Control de Internet (ICMP).-

El objetivo de la práctica 2 de la asignatura Redes es profundizar en el funcionamiento 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.
BLOQUE 3:
Protocolos de nivel de Transporte en TCP/IP.-

Los objetivos de la práctica 3 de la asignatura Redes es profundizar en el funcionamiento de los protocolos de transporte en la arquitectura de red. En particular, se pretende conocer las características del nivel de transporte, así como el formato de las estructuras de datos que circulan en este nivel. Se implementará una aplicación cliente/servidor que incorpore las funciones más típicas exigibles a un nivel de transporte TCP/IP.