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