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 Passoword 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 Openning BINARY more data conection for rfc1191.txt
226 Transfer complete
ftp: 48730 bytes sent in 24.28 segundos 2.01 KB/s
ftp> quit
221- You have transfered 48730 bytes in 1 files.
221- Total traffic for this session was 49154 bytes in 1 tranfers.
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
MSS=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?
Sí, hay uno. Lo envía la máquina cuya dirección IP es 172.20.43.231 que corresponde al Cisco 1601.

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?
Cambia la MSS que había de 460 bytes a 360 bytes (la MTU de 500 bytes a 400 bytes).

d) ¿Reenvía tu PC algún paquete TCP al servidor?
Sí. Reenvía tres paquetes de datos (en realidad, envía 1 y espera confirmación, tras lo cual envía otros dos y vuelve a esperar confirmación).

e) ¿Fragmenta IP algún paquete TCP?
No porque el protocolo TCP activa el bit Don't Fragment (de hecho, es por eso que se da el error ICMP gracias al cual sabemos la nueva MSS).

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

1. Número, tipo y código de paquetes ICMP.
2. Indica la MTU del camino de camino completo.
3. 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.

1) En teoría, debería producirse una situación de error provocada por el hecho de no poder fragmentar el segmento por tener el bit 'Don't Fragment' activado (el protocol TCP siempre lo hace). Por tanto, recibiremos un único mensaje ICMP (porque sólo se dará una vez este error en este caso por la configuración de la red) que será de tipo 3 y código 4.
2) La MTU será la más pequeña de todos los valores, es decir, 500 bytes.
3)
Cabecera TCP= 20 bytes
MSS= 500-20-20= 460 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

- Cabecera: 8 bytes --> 1008 bytes al salir del nivel de transporte

• TCP (MSS=500-20-20=460 bytes)

- Cabecera: 20 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?
Básicamente podemos ver tres intentos de conexión (dos paquetes de datos desde la máquina origen por cada uno devuelto). La conexión es fallida porque los ordenadores tienen desactivada esta función.
A continuación podemos ver el intento de conexión en el Monitor de Red junto con el proceso hecho en MS-DOS:

Cuestión 4

Utiliza 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?
Hemos utilizado el fichero RFC1191.txt
Se negocia una MSS de 460 bytes (primero 1460 y luego 460).
El tamaño de los segmentos TCP es 480 bytes (460 de datos y 20 de cabecera TCP).
La diferencia básica es que, en este caso, los segmentos TCP contendrán menos datos.

Cuestión 3

Utiliza el programa rexec para ejecutar el comando 'cat capturaexamen' en el servidor 172.20.43.232 (Linux2). 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?
No (de hecho, podemos ver el byte Don't Fragment activado). No se fragmenta porque TCP ya crea sus segmentos respetando el tamaño de la MTU de IP.
El tamaño máximo de un segmento TCP es, en este caso, 1460 bytes. Esto se puede ver cogiendo la trama de tamaño máximo y restando las distintas cabeceras o bien mirando el campo Maximum Segment Size que está en la pestaña Options del nivel TCP.
Aquí podemos ver una captura del proceso realizado:

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

Emplea el programa rexec para ejecutar el comando 'ls -l' en la máquina con dirección 172.20.43.232 (Linux2). 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 de SYN del servidor con un RST. Esto ocurre porque el servidor trata de autentifiar al cliente, algo que no permite el PC).

La estructura de envío de datos - confirmación de datos es similar a la detallada en el guión de prácticas.
A continuación podemos ver la captura de tramas realizada por el Monitor de Red con la que hemos comprobado esto:

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

El valor de los puertos que se utilizan es:

1. Nuestra máquina: 1102
   
2. Servidor: 512

Cabe destacar que, durante una parte de la conexión (concretamente durante la autentificación), el valor de los puertos es el siguiente:

1. Nuestra máquina: 113
   
2. Servidor: 2090

Esto último ocurre porque, para realizar la operación comentada, se requieren una serie de puertos que aseguren mayor seguridad que los anteriores.

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

Los tamaños que encontramos en las diferentes tramas son, o bien 65535 bytes o bien 5840 bytes. El más grande de los que encontramos es el de 65535 bytes, que además coincide con el máximo posible ya que este campo tiene reservados 2 bytes de tamaño, lo que establece 65536 valores posibles que se mueven en el rango de [0,65535].

Cuestión 1

Udp.exe. Este sencillo programa para MS Windows nos permitirá enviar 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.

Apartado 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 filtro adecuado en el Monitor de Red (direcciones y protocolos)
Antes de nada destacar que nuestro datagrama UDP ha sido mandado al puerto 7.
El filtro utilizado ha sido ip.addr == 10.3.7.0
Analizando la secuencia de paquetes que obtiene el monitor de red, podemos observar que sí aparece un mensaje catalogado como Request y otro como Response.

Finalmente, los puertos que se dan en la conexión son:

• Nuestra máquina: Puerto 1092
• Servidor: Puerto 7
  

Apartado b) Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2 Kbytes). 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 paquetes UDP? Estudia las longitudes del paquete UDP y la 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...)
Tras realizar las operaciones propuestas en el enunciado, nuestro paquete de datos se fragmenta en 2 datagramas de ida, cuya vuelta llega en 5 paquetes. La imagen que describe esto es la que sigue:

A continuación realizaremos el estudio de los paquetes:

• Ida

El primer paquete (el catalogado como ECHO Request) tiene 1514 bytes a nivel de Ethernet, por lo que, sabiendo que la cabecera de Ethernet son 14 bytes y que la del nivel IP son 20 bytes, a nivel de transporte tendremos 1480 bytes, de los cuales 1472 son de datos y los 8 restantes son de cabecera UDP.
El segundo paquete tiene 597 bytes, de los cuales, con los datos antes comentados, sabemos que 577 bytes son de nivel de transporte (todos serán datos ya que la cabecera UDP va en la anterior trama por el hecho de que la fragmentación en este caso está permitida y se realiza a nivel IP).
Por tanto, los datos mandados con el programa udp.exe serán 1472+577=2049 bytes.
Por último, la bandera de "no fragmentación" está desactivada, por lo que sí que se puede dividir el datagrama UDP a nivel IP.

• Vuelta
  

El primero de los datagramas, catalogado como ECHO Response, tiene una longitud de trama de 514 bytes, por lo que, quitando las cabeceras del nivel de Ethernet y de IP, nos quedamos con 480 bytes a nivel de transporte (472 de datos y 8 de cabecera).
Los 3 datagramas siguientes tienen 514 bytes sobre el nivel de Ethernet, que eliminando las cabeceras, se quedan en 480 bytes de datos a nivel de transporte.
El quinto datagrama tiene 171 bytes sobre nivel de Ethernet, que en definitiva son 137 bytes de datos a nivel de transporte.
La cantidad de datos, sumando las distintas cantidades de datos de las diferentes tramas, son 472+480+480+480+137=2049 bytes.
En este caso, el bit 'Don't Fragment' tampoco está activado, permitiendo entonces la división de los segmentos a nivel IP.

¿De qué va la Práctica 3?

En esta tercera práctica de la asignatura se va a estudiar con profundidad el nivel de transporte del protocolo TCP/IP, siendo nuestro principal objetivo el comprender la diferencia entre los dos protocolos principales de este nivel de red: el TCP, cuyas siglas significan Transmission Control Protocol (en castellano, Protocolo de Control de Transmisión), y el UDP, que es el acrónimo de User Datagram Protocol (cuya traducción es Protocolo de Datagramas de Usuario.