ANEXO

En una ventana de MS-DOS y dentro del directorio raíz emplea el programa ftp para enviar el fichero C:\p3.txt al servidor 172.20.41.241. Para ello, utiliza la siguiente secuencia de comandos:

C:\ftp 172.20.41.241
Conectado a 172.20.41.241
220 Linux1.disc.ua.es FTP server (Version wu-2.4.2-academ[BETA-18-vr12] (1)
Wed Jan 27 22:19:46 CST 1999) ready.
Usuario (172.20.41.241: none)): alumnos
331 Password required for alumnos.
Contraseña: alumnos
230 User alumnos logged in
ftp> bin
200 Tipe set to I
ftp> put p3.txt
200 PORT comand successful.
150 Opening BINARY mode data connection for rfc1191.txt
226 Transfer complete.
ftp: 48730 bytes sent in 24.28 segundos 2.01 KB/s
ftp> quit
221-You have transferred 48730 bytes in 1 files.
221-Total traffic for this session was 49154 bytes in 1 transfers.
221-Thank you for using the FTP service on Linux1.disc.ua.es.
221-Goodbye.

a) Determina con el monitor de red qué valor de MSS se ha negociado en la conexión TCP. Para ello visualiza TODOS los paquetes IP intercambiados entre tu PC y el servidor 172.20.41.241.

Hay dos valores de MSS (1460 bytes y 460 bytes), finalmente se escoge un valor de MSS de 460 bytes.

b) ¿Hay paquetes ICMP "fragmentation needed and the bit don't fragment was set"? Si la respuesta es afirmativa. ¿Qué máquina envía el mensaje de error?

Si, hay un paquete ICMP Destination Unreachable (Fragmentation Needed).
La máquina que envía el error es la 172.20.43.231.

c) ¿Cómo afecta este mensaje ICMP al tamaño de los paquetes TCP intercambiados entre tu PC y el servidor 172.20.41.241?

Disminuye el valor de MSS y por tanto el tamaño de los paquetes. El nuevo valor de MSS es de 360 bytes.

d) ¿Reenvía tu PC algún paquete TCP al servidor?

Si. para indicarle que debe reducir el tamaño de los paquetes


e) ¿Fragmenta IP algún paquete TCP?

No, IP no fragmenta ningún paquete TCP

Cuestión 7

En base a la topología que se muestra a continuación:

Considerando que todos los equipos presentes en dicha topología cumplen la RFC 1191. Determina el número de segmentos que se generan al mandar un paquete TCP con 1500 bytes de datos desde la máquina 'A' a la máquina 'E':

a. Número, tipo y código de paquetes ICMP.

El recorrido elegido provoca la aparición de un mensaje ICMP 'Destination unreachable, fragment needed', este mensaje es de tipo 3 y código 4.

b. Indica la MTU del camino completo.

La MTU del camino completo es la misma que la del tramo con menor MTU, por tanto, la MTU tiene un valor de 500 (B-D).

c. Una vez determinada la MTU del camino, mostrar la longitud total de cada paquete TCP construido en la fragmentación al mandar un paquete TCP original con 1500 bytes de datos. Indicar la estructura (cabeceras incluidas) de la trama Ethernet en la que se encapsulan los paquetes.

Paquete 1 --> Cab. Ethernet=14 bytes; Cab. IP=20 bytes; Cab. TCP=20 bytes; Datos=460 bytes
Paquete 2 --> Cab. Ethernet=14 bytes; Cab. IP=20 bytes; Cab. TCP=20 bytes; Datos=460 bytes
Paquete 3 --> Cab. Ethernet=14 bytes; Cab. IP=20 bytes; Cab. TCP=20 bytes; Datos=460 bytes
Paquete 4 --> Cab. Ethernet=14 bytes; Cab. IP=20 bytes; Cab. TCP=20 bytes; Datos=120 bytes

Cuestión 6

Determinar el número de paquetes UDP que se generan (indicando el formato de los paquetes: cabeceras, etc...), cuando el nivel de transporte envía 1000 bytes de datos en una red Ethernet con MTU de 500 bytes. Hacer lo mismo considerando que el nivel de transporte utilizado fuera TCP.



UDP



Paquete 1 --> Cabecera IP=20 bytes; Cabecera UDP=8 bytes; Datos=472 bytes

Paquete 2 --> Cabecera IP=20 bytes; Datos=480 bytes

Paquete 3 --> Cabecera IP=20 bytes; Datos=48 bytes





TCP



Paquete 1 --> Cabecera IP=20 bytes; Cabecera TCP=20 bytes; Datos=460 bytes

Paquete 2 --> Cabecera IP=20 bytes; Cabecera TCP=20 bytes; Datos=460 bytes

Paquete 3 --> Cabecera IP=20 bytes; Cabecera TCP=20 bytes; Datos=80 bytes

Cuestión 5

Realiza una conexión FTP a la máquina de un compañero de clase. ¿Qué obtienes en el Monitor de Red al intentar realizar esta conexión?

Se observan 3 solicitudes de establecimiento de conexión (SYN) con la máquina de mi compañero sin éxito, por cada solicitud de conexión se ve un mensaje RST el cual sirve para solicitar un reinicio de la conexión. La no consecución de la conexión se debe a que el servicio TCP está deshabilitado en los ordenadores.

Cuestión 4

Utiliza el programa rexec para ejecutar el comando 'cat capturaexamen' en el servidor 10.3.7.0. ¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?

En los extremos de la comunicación se negocian valores de MSS de 460 bytes y 1460 bytes, resultando finalmente una MSS de 460 bytes.

El tamaño de los segmentos TCP es de 480 bytes.

La diferencia con el caso anterior es que los paquetes contienen menos datos y por tanto se necesitan más paquetes para transportar la misma información.

Cuestión 3

Utiliza el programa rexec para ejecutar el comando 'cat ifconfig' en el servidor 172.20.43.232 (Linux 2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño. ¿IP ha fragmentado estos segmentos? ¿Por qué ocurre esto? ¿Cuál es el tamaño de los segmentos TCP?

IP no ha fragmentado estos segmentos porque el protocolo TCP ya se encarga de particionar los datos ajustándose a la MTU de la red. El tamaño de los segmentos TCP es de 1460 bytes.

Cuestión 2

Rexec. Remote Shell es un servicio presente en un S.O. UNIX con TCP/IP que atiende el puerto TCP 512 en espera de peticiones de ejecución de comandos desde procesos remotos clientes. Utiliza TCP, por lo que trabaja con conexión. Para las prácticas se dispondrá de un programa para MS Windows (rexec.exe) que actúa como cliente. En una sesión de rexec.exe se pide inicialmente un nombre de usuario y password en la máquina servidora, y tras introducir estos, se pueden ejecutar comandos UNIX en dicha máquina. Nos servirá para estudiar una conexión TCP. Dentro de una máquina UNIX, el cliente es un programa de línea de comandos con esta sintaxis básica:

rsh [IP SERVIDOR] [COMANDO A EJECUTAR]

Emplear el programa rexec para ejecutar el comando 'ls -l' en la máquina con dirección 172.20.43.232 (Linux 2). Utiliza para ello el usuario 'alumnos' y la clave 'alumnos'. Con el monitor de red, analizar y estudiar la secuencia de paquetes TCP intercambiados en el establecimiento de la conexión entre la máquina del alumno y la 172.20.43.232. Utilizar para ello el filtro adecuado (direcciones y protocolos).

Comprueba las secuencias de conexión-desconexión TCP. ¿Son similares a las que se detallan en la figura 6? (Puede que observes que el cliente contesta a una solicitud SYN del servidor con un RST. Esto ocurre porque el servidor trata de autentificar al cliente, algo que no permite el PC).

Como se puede apreciar comparando la captura del Monitor de Red y la figura 6 (a continuación), las secuencias de conexión-desconexión TCP son muy similares.

Comprueba el valor de los puertos utilizados. Indica su valor.

El puerto utilizado por mi máquina es el 512 y el del servidor el 1415.

Durante la autentificación mi máquina usa el puerto 113 y el servidor el puerto 2325, este cambio se debe a que se requiere una mayor seguridad.

Analizar los valores de la ventana de receptor. ¿Cuál es el más grande?

El valor de la ventana receptora de mi máquina es 5840, sin embargo, el tamaño de la ventana receptora del servidor es de 64813, siendo este último mayor.

Cuestión 1

Udp.exe. Este sencillo programa para MS Windows nos permitirá enviar y recibir paquetes UDP, especificando también su contenido, a un número de puerto y una IP destinos especificados para comprobar el funcionamiento de este protocolo.

a. Utilizar el programa udp.exe para realizar un envío de datos al puerto 7 (eco) o al puerto 13 (hora y día) del servidor Linux1 (10.3.7.0). Para ello basta especificar la dirección IP y el puerto del servidor, colocar algún texto en la ventana y pulsar el botón "Envía UDP". Con el monitor de red, analiza la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo "hola". Utiliza el fitro adecuado en el Monitor de Red (direcciones y protocolos).

He realizado el envío de la palabra "hola" al puerto 7 (eco) del servidor Linux1.

En el monitor de red, introducimos el filtro ip.src==172.20.43.202 ip.dst==17.20.43.202 && !nbns para visualizar solo los paquetes asociados a nuestra máquina.

b. Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Esto se puede hacer copiando parte de algún fichero de texto en la ventana de udp.exe. ¿Se produce fragmentación IP de los paqutes UDP? Estudia las longitudes del paquete UDP y las de los paquetes IP que aparecen. Detalla los paquetes (fragmentados o no) que observas en el Monitor (indica el valor del identificador, flags, tamaño, etc...)

Si que se produce fragmentación IP de los paquetes UDP, se envía un paquete UDP con una longitud de 1292 bytes y aparecen dos paquetes IP de longitud 514 bytes y un paquete UDP de 332 bytes.

Práctica 3

Introducción

Los objetivos de la práctica 3 de la asignatura Redes de Ordenadores (IT. Telecomunicaciones, Especialidad Sonido e Imagen de la Universidad de Alicante) 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.

Cuestión Tracert

Rutas de los paquetes en la red

En este ejercicio se pretende que el alumno descubra la ruta que siguen los paquetes desde un nodo origen a un nodo destino con la información proporcionada por la herramienta de trazado de rutas. Debido a las limitaciones que posee el comando tracert o traceroute desde la ubicación del laboratorio, vamos a hacer uso de servidores de rutas externos, desde los que calcularemos la ruta a nuestra máquina o a cualquier otro nodo mundial.

Accede a la web http://tracert.com/trace_exe.html . Desde este sitio podemos lanzar la petición de traza de rutas desde diferentes servidores de la red.

- Realiza una petición de traza desde Australia (red Telstra.net) hacia la dirección http://www.ua.es/ . ¿Qué ciudades recorren los paquetes hasta que llegan a la Universidad de Alicante? ¿Cuántos routers son atravesados por paquetes (aproximadamente)?

Las ciudades que atraviesan los paquetes son: Melbourne, Sydney, Hong Kong, Maine, alguna ciudad del centro de los EEUU, Hollywood (Florida), Madrid, Valencia y Alicante.

Posiblemente en lugar de pasar los paquetes por Maine, entraran por alguna ciudad de California. Pero al utilizar un programa gratuito GeoIptool las bases de datos no tienen porque estar actualizadas y la ubicación de dicha dirección IP puede haber cambiado de lugar.

Los paquetes atraviesan aproximadamente 15 routers.

- Realiza una petición de traza desde Rusia hasta la web de http://www.sony.com/ . Indica la ubicación de los routers por los que pasan los paquetes hasta que llegan al servidor web. Para traducir las abreviaturas por los nombres de ciudades o aeropuertos ayúdate de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3 .Dibuja en el mapa de la Figura 11 el camino de los paquetes.

Observando las abreviaturas que aparecen en los puntos por los que pasan los paquetes se puede concluir, a excepción de las dos primeras ciudades que las he extraido con la herramienta de localización por IP porque no encontraba la correspondencia con las abreviaturas, que la ruta que siguen los paquetes es la siguiente: Novosibirsk, Moscú, Frankfurt, Amsterdam, Nueva York, Chicago, San Jose, Los Angeles, San Diego.


- Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina http://www.argentina.gov.ar/ desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino?



Las ciudades por las que pasa son: Paris, Galicia y Buenos Aires.

El proveedor que se encarga de encaminar los datos en la mayor parte de los caminos es Telefónica.


Compara los resultados si accedes desde Paris (Eu.org) al diario http://www.clarin.com/. Dibuja los caminos.



Las ciudades por las que pasa son: Paris, Washington, Atlanta, Miami y Buenos Aires.

El proveedor que se encarga de encaminar los datos en la mayor parte de los caminos es Cogentco.

Anexo

Herramientas de rutas de paquetes - Tracert/Traceroute

Una de las curiosidades más llamativas de la red es saber la ruta que siguen los paquetes o datagramas hasta que llegan a su destino.

Traceroute es una herramienta de diagnóstico de redes que permite visualizar la ruta de los paquetes que se dirigen desde un equipo a otro. Con esta herramienta se obtiene además una estadística o latencia de red de esos paquetes, lo que viene a ser una estimación de la distancia a la que están los extremos de comunicación. El comando se denomina traceroute en UNIX y linux, mientras que en Windows recibe el nombre de tracert.

¿Cómo funciona?

El funcionamiento del comando es sencillo. Se basa en un error ICMP TTL excedido en tránsito.

Tracert funciona enviando mensajes ICMP de solicitud de eco con distintos TTL; Traceroute, en cambio, envía mensajes UDP. El campo TTL de la cabecera IP de los paquetes es un número entero que se decrece en cada nodo por el que pasa el paquete. De esta forma, cuando el campo TTL llega al valor 0 ya no se reenviará más, sino que el nodo que lo esté manejando en ese momento lo descartará. Lo que hacen los comandos de traza de rutas es mandar paquetes a la red de forma que el primer paquete posea un valor TTL=1, el segundo un TTL=2, etc. De esta forma, el primer paquete será eliminado en el primer nodo al que llegue (ya que éste nodo decrementará el valor TTL, valiendo cero). Cuando un nodo elimina un paquete, envía al emisor un mensaje de error indicando la incidencia. Tracer usa esta respuesta para averiguar la dirección IP del nodo que desechó el paquete, que será el primer nodo de la red. La segunda vez que se manda un paquete, el TTL vale 2, por lo que pasará el primer nodo y llegará al segundo, donde será descartado, devolviendo de nuevo un mensaje de error. Esto se hace de forma sucesiva hasta que el paquete llega a su destino.

Otras aplicaciones

Existen otras aplicaciones como "Visual Route" que se basan en Traceroute/Tracert para obtener una información gráfica de la ruta que siguen los paquetes desde el origen hasta su destino. En estos casos, se emplea la información generada por la orden Traceroute/Tracert junto con la información de los nodos obtenida de bases de datos públicas como RIPE (foro colaborativo de redes IP).

En Internet existen una serie de lugares que proporcionan servidores de traceroute, y que nos informan de los resultados de la ejecución de una orden traceroute desde ese host hasta el nuestro u otro que se le especifique. A estos servidores se les suelen llamar Looking Glass. Esto es de gran ayuda a la hora de realizar mapas de caminos para los paquetes desde cualquier ubicación del mundo. En el sitio web de traceroute (http://www.traceroute.org/) se encuentran recogidos algunos de los sitios web que ofrecen la posibilidad de realizar trazas al sitio que se les indique.

De la información que obtenemos de los programas de rutas hay que tener en cuenta lo siguiente:

• Cada proveedor de red puede tener su propio sistema de código de máquinas.
• Los routers pueden describir en su nombre la topología o infraestructura en la que están ubicados (T1, T3, FDDI, ATM, HSSI, ETH, ...).
• Los códigos de nombre de los routers suelen tener 3 letras, como el código del aeropuerto más cercano. (Base de datos de código de aeropuertos: http://www.airportcitycodes.com/codewisecodes.aspx
• Los nombres de los routers también pueden incluir la dirección IP, una abreviatura especial, o seguir un código de nombres ya extendido como los que se encuentran en la siguiente web: http://www.sarangworld.com/TRACEROUTE/showdb-2.php3
• Existen también herramientas que a partir de la dirección IP del router nos permite conocer su ubicación como: http://www.geoiptool.com/

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 Transist (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

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.

5.a. Finaliza la captura e indica la 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 máquina que envía el mensaje "ICMP Time to Live exceeded in Transit" es la que tiene la puerta de enlace que usamos en prácticas (router Cisco 1720), su IP es la 172.20.43.230 y su MAC es 00:07:0E:8C:8C:FF. Es lógico que sea esta máquina porque al tener un tiempo de vida (TTL) igual a 1 solo conseguirá atravesar un router.



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 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? (identifica las máquinas en la topología del anexo)




La IP origen de este mensaje de error es la 10.4.2.5 (Cisco 2513) y la MAC 00:07:0E:8C:8C:FF. No pertenecen a la misma máquina, la MAC pertenece a la máquina anterior (la puerta de enlace del laboratorio, Cisco 1720).



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?

Este mensaje tiene asociado el tipo 11 y código 0.

Al intentar conectarse a una máquina que no existe se produce un bucle cerrado entre máquinas Linux 1 y Linux 2 hasta que se agota el tiempo de vida del paquete.

5.d. Repite el ejercicio pero esta vez eleva el tiempo de vida del paquete a 160. ¿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)?


C:\> ping -i 160 -n 1 10.3.7.12

Se observa como en este caso el resultado tarda más en aparecer.

Cuestión 4

Mensaje ICMP "Redirect"

Inicia el Monitor de Red. A continuación ejecuta 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:

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.

4.a. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos... (tipo, código y tamaño)

Hay 3 datagramas IP involucrados en el proceso que se describen a continuación:

- El primero es de tipo 8 y código 0, lo cual quiere decir que es una solicitud de eco. El camino que recorre es desde mi máquina hasta la 10.4.2.1 (a la que he mandado el ping).

- El segundo es de tipo 5 y código 1, y va desde la puerta de enlace 172.20.43.230 a mi máquina 172.20.43.202. El mensaje de tipo 5 quiere decir que es una redirección y al ser de tipo 1 redirecciona datagramas para el host.

- El tercero es de tipo 0 y código 0, por tanto, es una respuesta de eco. El camino que recorre el datagrama es desde la máquina origen 10.4.2.1 hasta la mia 172.20.43.202.

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?

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.

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

La máquina que envía el mensaje ICMP Redirect es la CISCO 1720 (172.20.43.230),, que es la puerta de enlace predeterminada.

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?

Cada mensaje de redireccionamiento contiene un campo de 32 bits llamado dirección de internet del encaminador que contiene la IP de salida correcta para la máquina emisora.

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 mima 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?

Datagrama enviado originalmente:

-Identificación: 0x5314; TTL=128; Cheksum: 0x03ca

Mensaje Redirect:

-Identificación: 0x5314; TTL=127; Cheksum: 0x04ca

La identificación del ambos datagramas es la misma ya que se trata del mismo mensaje.

El TTL del mensaje Redirect es una unidad inferior al original porque ha atravesado un router.

En el campo Cheksum varía un número al haber variado en una unidad el valor del TTL.

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)

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.

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