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.