Resumen de las prácticas: ¿Qué hemos aprendido sobre las redes?

Ahora que el curso llega a su fin, no estaría de más realizar un breve repaso para recordar todo lo que hemos aprendido en las prácticas de la asignatura Redes de Ordenadores. En cada una de ellas el conocimiento que adquirimos fue:

• Práctica 1

Esta primera práctica nos permitió establecer nuestro primer contacto con la estructura de las redes: los diferentes niveles de TCP/IP y su función en la comunicación de datos. También nos familiarizamos con el Monitor de Red (Wireshark) para interpretar el funcionamiento de los protocolos Ethernet, ARP e IP, realizando capturas de paquetes y analizándolos. Por último conocimos cómo funcionaba el direccionamiento IP, la utilidad de las máscaras de subred y fuimos conociendo la topología de la red del laboratorio.

• Práctica 2

La segunda práctica fue la más extensa de las 3. Tras habernos familiarizado con el Monitor de Red en la práctica anterior, nos adentramos en el funcionamiento del protocolo ICMP, viendo el formato de sus mensajes y los distintos tipos de los mismos que existen. Podía tratarse de mensajes de información o de error, ocasionados por diversos motivos. Nosotros nos centramos en unos cuantos de ellos, aprendiendo al mismo tiempo cómo funcionaba la fragmentación de los paquetes IP. Finalmente, en el anexo de la práctica, fuimos capaces de conocer las rutas que siguen los paquetes desde su origen hasta que llegan a su destino, valiéndonos para ello de diversas herramientas web, a las que podemos acceder a través de algunos de los enlaces de este blog.

• Práctica 3

La última de las prácticas nos sirvió para conocer los protocolos presentes en el nivel de transporte de TCP/IP: TCP y UDP. La práctica se basó en el estudio de ambos protocolos, cada uno orientado a un tipo de aplicaciones, mediante la realización de diversos ejercicios en los que aprendimos otro término importante en las redes: los puertos.

Una vez realizada esta recopilación de los conocimientos adquiridos (obviamente no se han nombrado todos ni se han detallado, porque si no la entrada sería muy extensa), sólo queda decir que hemos aprendido cosas que la mayoría desconocíamos, por lo menos yo, y que resultan muy interesantes al explicarnos el funcionamiento de este mundo (virtual) al que solemos dedicar gran parte de nuestro tiempo sin pararnos a pensar en el gran trabajo interno que supone.

Gracias a todos los que hayáis seguido este blog y feliz verano!!!

P.D. Cuando acaben los exámenes, claro está ;)

Práctica 3 - Anexo ejercicio 7

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

 

C:\ftp 172.20.41.241

Connectado 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 Type set to I

ftp> put p3.txt

200 PORT command 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.

 

En primer lugar ejecutamos el comando:

route add 172.20.41.241 mask 255.255.255.255 172.20.43.231

y después el resto de comandos anteriores

De esta forma obtenemos en el Monitor de red lo siguiente:

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.

En el primer extremo el valor de MSS es 1460 bytes mientras que en el segundo es de 460. Por tanto el valor negociado de MSS en la conexión ftp es 460. Ahora bien, finalmente la MSS debe ser de 360 debido a que en una red intermedia sólo se llega a ese valor.

 

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?

Sí, un paquete.  La máquina que envía este mensaje es 172.20.43.231, máquina a partir de la cual con el valor de MSS previamente negociado no pueden seguir su recorrido los segmentos TCP.

 

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?

Este mensaje hace que los paquetes se envíen con un tamaño de 360 bytes de datos, ya que la MTU de la siguiente red que sigue a la máquina emisora del mensaje ICMP es de 400 (360+20+20). Si no se hubiese producido ese mensaje de error los paquetes TCP tendrían el tamaño establecido por la MSS negociada en conexión, 460 bytes.

 

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

Sí, tenemos 3 mensajes de retransmisión de TCP para que se vuelvan a reenviar los paquetes enviados con el anterior valor de MSS, antes de que se produjese el error de destino inalcanzable y cambiase a 360.

 

e) ¿Fragmenta IP algún paquete TCP?

No, IP no fragmenta ningún paquete TCP, sino que los forma inicialmente de manera que ajusten su tamaño al máximo permitido en las redes que van a atravesar.

Práctica 3 - Ejercicio 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.

Tendremos un mensaje ICMP “Fragmentation Needed”, de tipo 3 y código 4.

 

b. Indica la MTU del camino de camino completo.

La MTU del camino completo es 500, el menor valor presente en las redes que deben atravesar los paquetes para llegar al destino.

 

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.

Práctica 3 - Ejercicio 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.

Usando como nivel de transporte UDP:

Sin embargo, usando como nivel de transporte TCP:

La diferencia como vemos es que en el nivel de transporte TCP se mantiene en todo momento la cabecera TCP en cada segmento, mientras que en UDP, por el hecho de fragmentar, sólo se mantiene la cabecera UDP en el primer fragmento.

Práctica 3 - Ejercicio 5

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

Tras introducir los comandos anteriores que se aprecian en la figura, lo que obtenemos en el Monitor de red es lo siguiente:

Se observan distintos intentos de conexión seguidos de reseteos al no poder establecer la conexión ya que las máquinas tienen esta opción deshabilitada.

Práctica 3 - Ejercicio 4

Utilizamos el programa rexec para ejecutar el comando ‘cat file1.txt’ 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?

La MSS que se negocia entre los extremos tiene un valor de 460 bytes porque, a pesar de que en el extremo inicial podría ser de 1460, en el extremo final sólo puede ser de 460, de modo que se coge el valor más pequeño.

El tamaño de los segmentos TCP transportados dentro de los paquetes IP es en este caso de 460 bytes más 20 bytes de cabecera.

En este caso no tenemos ningún mensaje Destination Unrecheable porque desde un principio se negocia un tamaño de paquetes que servirá para todas las redes que hay que atravesar para llegar al destino.

Práctica 3 - Ejercicio 3

Utilizamos el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 172.20.43.232 (Linux2). La información recibida es de varios miles de bytes y la recibiremos 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 esos segmentos porque los segmentos TCP llevan el bit “don’t fragment” activado, pues los paquetes se conforman con el tamaño máximo permitido para que no sea necesaria la fragmentación. Así pues, el tamaño de los segmentos TCP es de 1460 bytes de datos, más 20 de cabecera TCP.

Práctica 3 - Ejercicio 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 disponemos 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 introducirlos, podemos 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 .

Empleamos el programa rexec para ejecutar el comando ‘ls –l’ en la máquina con dirección 172.20.43.232 (Linux2). Utilizamos para ello el usuario ‘alumnos’ y la clave ‘alumnos’. Con el monitor de red, analizamos y estudiamos 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. Utilizamos para ello el filtro adecuado (direcciones y protocolos).

 

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

Sí son similares las secuencias de conexión y desconexión TCP que obtenemos a las observadas en la figura 6. En primer lugar en la conexión observada en dicha figura tenemos la secuencia SYN-ACK/SYN-ACK y esto mismo observamos en los 3 primeros paquetes que muestra la captura. Y, en cuanto a la desconexión, la figura establece que la secuencia es ACK-FIN-ACK, la cual también encontramos en los 3 últimos paquetes de la captura. Observamos también la respuesta a la solicitud de SYN del servidor con un RST. 

• Comprobamos el valor de los puertos utilizados e indicamos su valor.

El valor del puerto de nuestra máquina es 1105, mientras que el del servidor es 512. Pero estos valores cambian en un determinado momento (durante la autentificación) y sólo durante éste, siendo ahora el puerto de nuestra máquina el 113 y el del servidor 2057. Esto ocurre porque para realizar la autentificación son necesarios unos puertos que otorguen mayor seguridad que los anteriores.

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

La ventana de receptor más grande es la de nuestra máquina, con un valor de 65535 bytes. Sin embargo, el tamaño de la ventana de receptor de la máquina destino es tan sólo de 5840 bytes.

Práctica 3 - Ejercicio 1

Vamos a usar un sencillo programa para MS Windows llamado Udp.exe. que 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) Utilizamos 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 con que especifiquemos 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, analizamos la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo “hola”. Utilizamos el filtro adecuado en el Monitor de Red (direcciones y protocolos).

Este es el resultado obtenido al enviar la palabra “hola” al puerto 7 y filtrar los paquetes en el monitor de red usando el filtro “ip.addr==10.3.7.0 && udp".
Si ahora enviamos esta misma palabra al puerto 13 lo que obtenemos, filtrando igual que en el caso anterior, es:

b) Probamos de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Para ello copiamos parte de un fichero de texto (2,31KB) en la ventana de udp.exe. ¿Se produce fragmentación IP de los paquetes UDP? Estudiamos las longitudes del paquete UDP y las de los paquetes IP que aparecen. Detallamos los paquetes (fragmentados o no) que observamos en el Monitor (indica el valor del identificador, flags, tamaño, etc…).

Sí se produce fragmentación IP de los paquetes UDP. En la ida enviamos un paquete UDP de 2373 bytes que se fragmenta en 2: el UDP de 1500 y un IP de 913 bytes, que tras sumar nos da 2413 bytes a los que hay que restar 20 bytes de cabecera IP por cada uno de forma que obtenemos los 2373 bytes. En la respuesta sucede los mismo, sólo que tenemos más fragmentos IP, en concreto 4 (3 de 500 y uno de 473 bytes) además del UDP de 500. En total suman 2473 pero si restamos 20 bytes por cada cabecera IP (20*5=100) tendremos los 2373 bytes iniciales.

Introducción Práctica 3

El objetivo de esta práctica es profundizar en el funcionamiento de los protocolos de transporte en la arquitectura de red: TCP y UDP. Pretendemos conocer las características del nivel de transporte así como el formato de las estructuras de datos que viajan en este nivel. Para ello implementaremos una aplicación cliente/servidor que incorpora las funciones más típicas que se le pueden exigir a un nivel de transporte TCP/IP.

Práctica 2 - ANEXO 2: Cuestión Tracert. Rutas de los paquetes en la Red.

En este ejercicio se pretende que descubramos la ruta que siguen los paquetes que 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 una nuestra máquina o a cualquier otro nodo mundial.

Accedemos 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.

• Realizamos una petición de traza desde Australia (red de Telstra.net) hacia la dirección 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 recorren los paquetes son:

Melbourne --> Sidney --> Hong Kong --> Maine (lo coherente sería que fuese California) --> Phoenix --> Hollywood --> Madrid --> Valencia --> Alicante

Son atravesados 15 routers como podemos apreciar en la imagen que muestra el recorrido por los mismos que realizan los paquetes.

• Realizamos una petición de traza desde Rusia hasta la web de www.sony.com. Indicamos 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 nos ayudamos de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3. Dibujamos en el mapa el camino de los paquetes.
  
  

• Repetimos el ejercicio, pero esta vez solicitamos la conexión con la web del Gobierno federal de Argentina www.argentina.gov.ar desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino? Comparamos los resultados si accedemos desde Paris (Eu.org) al diario www.clarin.com. Dibujamos los caminos.
  
  
  Accediendo al Gobierno Federal de Argentina la ubicación de los routers es la siguiente:

Puesto que hemos tenido problemas a la hora de conocer el nombre de las ciudades en las que se encontraban los routers debido a la poca precisión de las herramientas con las que contábamos para ello, únicamente hemos podido suponer la trayectoria que debían seguir los paquetes hasta llegar a su destino:

París --> España (Galicia) --> Miami --> Buenos Aires

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

Si ahora accedemos al diario Clarín, la ubicación de los routers que se atraviesan hasta llegar allí desde París es:

En este caso, el proveedor de red que se encarga de encaminar los datos en la mayor parte del camino es Cogentco.

Práctica 2 - Ejercicio 5: Mensaje ICMP "Time Exceded"

Dentro del mensaje Time Exceded analizaremos el de código 0: Time to Live exceeded in Transit (11/0). En primer lugar, iniciamos el Monitor de Red para capturar paquetes IP relacionados con nuestra máquina y ejecutamos el comando:

C:\>ping -i 1 -n 1 10.3.7.0

a) Finalizamos la captura e indicamos la máquina que envía el mensaje "ICMP Time to Live exceeded in Transit"... ¿Puedes saber su IP y su MAC? (identificamos la máquina en la topología del anexo)

IP:172.20.43.230

MAC: 00:07:0e:8c:8c:ff

Estas direcciones se corresponden con el Cisco 1720.

Iniciamos de nuevo la  captura y ejecutamos a continuación el comando:

C:\>ping -i 2 -n 1 10.3.7.0

b) Finalizamos la captura y determinamos qué máquina envía ahora el mensaje "ICMP Time to Live exceded in Transit"... Averiguamos y anotamos la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina? (identificamos las máquinas en la topología del anexo)

IP: 10.4.2.5

MAC: 00:07:0e:8c:8c:ff

Si esta dirección MAC correspondía al Cisco 1720 es fácil deducir que las direcciones que tenemos ahora no corresponden a la misma máquina. Esta nueva IP corresponde al Cisco 2513.

Por último, iniciamos de nuevo la captura y realizamos un ping a la siguiente dirección:

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

c) Finalizamos la captura y observamos el mensaje de error 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?

Tipo 11- Código 0

Lo que ocurre es que dicha máquina no existe y el TTL se agota intentando encontrarla.

Estaría ubicada en la subred que une el Cisco 2513 con el Linux 1 ya que el origen IP de ese datagrama es 10.3.2.0 (Cisco 2513). 

d) Repetimos el ejercicio pero esta vez elevamos el tiempo de vida del paquete a 220 (por limitaciones de la máquina Linux reducimos este TTL a 160 o 150) ¿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)? 

No observamos el mismo resultado con la misma rapidez. En este caso la respuesta ha tardado más ya que le hemos dado más tiempo de vida al paquete para que intente llegar a ese destino.

Como observamos en la imagen el tiempo que tarda en el apartado anterior es 45.940921 - 44.697310 = 1.243611 s, mientras que en este caso tarda 28.269463 - 24.322940 = 3.946523 s.

 

 

Práctica 2 - Ejercicio 4: Mensaje ICMP "Redirect"

Iniciamos el Monitor de Red y a continuación ejecutamos los comandos:

C:\>route delete 10.4.2.1 (si ya ha sido borrada la ruta, nos avisa con un error)

C:\>ping -n 1 10.4.2.1 (antes de contestar confirmamos que en MSDOS el resultado del ping es correcto: paquetes enviados: 1, paquetes recibidos: 1)

En base a los paquetes capturados, filtramos sólo los datagramas que contengan nuestra dirección IP y contestamos a las siguientes preguntas:

a) ¿Cuántos datagramas IP están involucrados en todo el proceso?

b) Dibujamos 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ásquinas involucradas).

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?

No. Observamos sólo 3 mensajes, no 4. El que no observamos es el que se correponde con la copia del mensaje ICMP Request que el Cisco 1720 envía al Cisco 1601. Esto sucede debido al switch presente en la configuración del laboratorio que filtra las direcciones MAC para evitar que uno vea lo que se está lanzando al medio y no tiene como destino su máquina.

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 qué casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

Para saber si las direcciones IP y MAC hacían referencia al mismo interfaz de red hemos usado el comando arp -a para ver las asociaciones de direcciones de cada máquina.

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

El router Cisco 1720.

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

Un campo de 32 bits llamado dirección de Internet del encaminador que contiene la IP de salida correcta para la máquina emisora. Esta información se guardará en la tabla de encaminamiento de nuestra máquina de forma que los próximos mensajes que enviemos a la misma direcciónpasarán por esa IP y no por la puerta prederterminada que no era óptima.

Además, transporta parte del mensaje original que causó el error.

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?

- Datagrama original

Identificación: 0x33c7 (13255) TTL: 128 Cheksum: 0x2313

- ICMP Redirect

Identificación: 0x33c7 (13255) TTL: 127 Cheksum: 0x2413

El campo de identificación sí es el mismo, pero los campos TTL y Cheksum han cambiado de un mensaje a otro. El TTL ha disminuido porque el paquete ha realizado un salto en el router, y el Cheksum ha cambiado en un número porque sólo se ha modificado en una unidad el TTL respecto al resto de campos de la cabecera del mensaje original

Práctica 2 - Ejercicio 3: Mensaje ICMP "Destination Unreachable"

Dentro del mensaje ICMP Destination Unreachable analizaremos el de código 4: Fragmentation Needed and Don't Fragment was Set (3/4). En primer lugar ejecutamos el comando:

C:\>route delete 10.3.7.0   (si la ruta ya ha sido borrada nos avisa con un error)

¿Por qué ejecutar este comando? En MS Windows, con route se odifican 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, ponemos en marcha el Monitor de Red en modo captura y ejecutamos 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, indicamos:

a) Identificamos las direcciones IP/MAC de los paquetes involucrados. ¿A qué equipos pertenecen? (identificamos la máquina con la topología del anexo)

El primer paquete pertenece a nuestra propia máquina, pero el segundo paquete tiene la IP del Cisco 2513 mientras que la MAC es del Cisco 1720. Esto ocurre porque la trama Ethernet sólo llega hasta la puerta de enlace mientras que la IP llega hasta el destino.

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 es el Cisco 2513 a través de la dirección 10.4.2.5 ya que el paquete no llega a su destino, la dirección 10.3.7.0.

Práctica 2 - Ejercicio 2: Sobre la fragmentación de datagramas IP

Empleando el programa Monitor de Red de 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, con lo que ahora estamos enviando 2000 bytes de datos).

a) Filtramos los paquetes en los que esté involucrada nuestra dirección IP. A continuación, describimos 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?

Nota: Ignoramos el primer paquete IP que aparece porque no ha sido enviado a la puerta de enlace con dirección 172.20.43.230.

Tras filtrar, tenemos 2 paquetes ICMP correspondientes a la petición (request) y a la respuesta (reply), y 2 paquetes IP identificados como "fragmented IP protocol". Esta fragmentación (tanto en la petición como en la respuesta) se ha producido porque la MTU de la red es de 1500 bytes y hemos enviado 2000 bytes de datos.

b) ¿En cuántos fragmentos se ha “dividido” el datagrama original?

Cada mensaje (petición y respuesta) se ha dividido en 2 fragmentos: de cada fragmentación obtenemos por una parte los paquetes IP de tamaño 1514 bytes y por otra los paquetes ICMP de tamaño 562 bytes. En total suman 2076 bytes, pero si quitamos los 14 bytes de cabecera Ethernet a cada uno y los 20 bytes de cabecera IP a cada uno también tendremos los 2008 bytes que habíamos enviado.

c) Analizamos la cabecera de cada datagrama IP de los paquetes relacionados con el "ping" anterior. Observamos el campo "identificación", "Flags" y "Fragment offset" de los datagramas. ¿Qué valor tienen 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.

d) ¿Qué ocurre en la visualización de los fragmentos de datagramas si introducimos un filtro para ver únicamente paquetes de "icmp" en el Monitor de Red? ¿Qué fragmentos se visualizan ahora? ¿Por qué puede suceder esto?

Introducimos el filtro "icmp" para visualizar únicamente estos paquetes, de forma que sólo se observan 2: los correspondientes a los primeros fragmentos de la petición y respuesta del ping. Esto es debido a que dichos fragmentos son los que contienen los 8 bytes de la cabecera ICMP, mientras que los segundos fragmentos de cada mensaje ya no los contienen. Por ello no aparecen al filtrar, porque estos paquetes no son considerados ya como paquetes ICMP, sino como paquetes IP.

e) ¿Para qué se pueden emplear los campos "Identificación", "Flags" y "Fragment offset de los datagramas IP?

El campo "Identificación" permite marcar de forma única cada datagrama enviado por una máquina. El campo "Flags" indica el número de fragmentos que faltan para completar el datagrama y la posición en la que se encuentra el mismo. Y el campo "Fragment offset" contiene el índice del fragmento a partir del datagrama original.

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. Es el tamaño máximo de los datagramas que circulan en la red y si algún paquete lo supera es fragmentado tantas veces como sea necesario para ajustarse a ese tamaño máximo. Sabemos que su valor es 1500 porque si observamos el tamaño del primero de los fragmentos (el que se llena al máximo) en los que se ha divido el ping vemos que es de 1514 bytes que, eliminando los 14 de la cabecera de Ethernet nos da los 1500 de MTU.

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

Indicamos el número total de datagramas en la red e identificamos si son de petición o de respuesta (dirección):

h) A continuación, pretendemos 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. Iniciamos el Monitor de Red y capturamos los paquetes IP relacionados con el siguiente comando:

C:\>ping -n 1 -l 1600 10.3.7.0

(antes de contestar confirmamos que en MSDOS el resultado del ping es correcto: paquetes enviados: 1, paquetes recibidos: 1)

Indicamos el número total de datagramas en la red e identificamos si son de petición o de respuesta (dirección):

i) En relación a los datos de la pregunta 2.h. obtenidos del Monitor de Red, contestamos:

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

Porqué en una de las redes que atraviesan los paquetes estos deben fragmentarse al ser la MTU más pequeña que su tamaño y volverán fragmentados ya que el reensamblado sólo se produce en el destino.

Indica en qué 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 qué 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?

El número de fragmentos tanto de petición como de respuesta vendrá determinado por la MTU más pequeña de las subredes que atravesemos. Dado que en este caso es la subred que une el Cisco 2513 con el Linux 1, ésta será la única en la que el número de fragmentos sea igual en la ida que en la vuelta. Mientras, en las subredes que van de los ordenadores del laboratorio al Cisco 1720 y de éste al Cisco 2513, tendremos un determiando número de fragmentos en la petición (dependiendo del número de datos en que se superen los 1500 bytes) y otro número distinto en la respuesta, ya que se dividirán más en la última subred y no se reensamblarán, aunque puedan hacerlo, hasta llegar al destino.

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?

Se atraviesan las 3 subredes que apreciamos en la figura, cuyas MTU's también se indican en la misma: