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

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.

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.

Al principio lo empieza a transmitir con 460 pero se da cuenta que el nuevo servidor solo permite una MTU DE 400, por lo que luego cambia y nos quedamos con:MSS=360

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. Uno de Destino inalcanzable y lo envía la máquina 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 ?

Pues que ahora solo se podrán enviar paquetes de 400 bytes y MSS de 360 bytes.

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

Si para decirle a 172.20.41.241 que el tamaño de los paquetes no puede ser el que ha indicado y que lo reduzca.

e) ¿Fragmenta IP algún paquete TCP ?

No

Cuestión 7.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.

---

Cuestión 7.b

Indica la MTU del camino de camino completo.

---

La MTU del camino completo es de 500 bytes. Siempre es la menor MTU por donde tiene que pasar cada paquete. En este caso, de B a D hay una MTU de 500.

Cuestión 7.a

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

---

1 paquete, Tipo 3 y Código 4. (Teníamos que haber visto 2 paquetes de error pero en el monitor de red solo se ve 1)

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

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.

---

Sabiendo que tiene que pasar por una MTU de 500 bytes, las cabeceras + los datos tienen que sumar un total de 500 bytes. Veamos que pasa en cada caso:

Para UDP:
Sabemos que UDP si se puede fragmentar. La cabecera de UDP solo se envía la primera vez. Por tanto, tenemos:

Para TCP:
Sabemos que TCP no se puede fragmentar. Hay que enviar siempre la cabecera de IP y de TCP. Por tanto, tenemos:

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?

---

Para realizar la conexión FTP a la maquina de un compañero vamos a MC-DOS e introducimos ftp junto con la IP de tu compañero/a. Ej: ftp 172.20.43.205. Para quitar este comando introducimos “quit”.

FTP es del protocolo TCP y no permite fragmentación. Aparecen peticiones desde mi máquina reiterativamente (3 en concreto y 3 respuestas de su máquina).

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?

---

Ahora el tamaño de los TCP que hay dentro de los fragmentos IP pasan por una MTU de 500 bytes y por tanto el valor de MSS es 460 bytes (20 de cabecera IP y 20 de cabecera TCP).

TCP = 48 bytes
TCP = 44 bytes
TCP = 40 bytes
EXEC = 74 bytes
TCP = 44 bytes
TCP = 60 bytes
TCP = 40 bytes
EXEC = 41 bytes
TCP = 40 bytes
EXEC = 500 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
TCP = 40 bytes
EXEC = 500 bytes
EXEC = 66 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes

CUESTIÓN 3

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

---

Hemos cambiado el comando ‘cat file 1.txt’ por el comando ‘cat capturaexamen’ debido a que no existía el archivo en algunos PC’s

No existen IP fragmentados sino muchos TCP porque este tipo de protocolo no permite la fragmentación.

TCP = 48 bytes
TCP = 48 bytes
TCP = 40 bytes
EXEC = 76 bytes
TCP = 40 bytes
TCP = 60 bytes
TCP = 40 bytes
EXEC = 41 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1500 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1500 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1500 bytes
EXEC = 1500 bytes
TCP = 40 bytes
EXEC = 1022 bytes
TCP = 40 bytes
TCP = 40 bytes
TCP = 40 bytes

Se van enviando TCP hasta un MTU de 1500

Cuestión 2.c

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

---

Ventana del receptor = 5840
Ventana del emisor = 65535

Cuestión 2.b

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

---

Los puertos son:

1211 - grooke-dopp. Puerto local
512 - exec. Puerto del servidor
113 - ident2053

2053 - lot105-ds-udp

Cuestión 2.a

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 autentificar al cliente, algo que no permite el PC).

---

Fijaos como son casi los mismos datagramas que en el esquema de la figura teórica.

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>

Emplear el programa rexec para ejecutar el comando ‘ls –l’ en la maquina 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).

Cuestión 1.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 paquetes 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…)

---

Hemos enviado un texto que nos ha ocupado 2136 bytes, esto se puede ver en el udp.exe. El envío se hace con un UDP de 2144 bytes ya que se suman 8 de cabecera pero es necesaria una fragmentación que tendrá como máximo 500 bytes ya que en algún momento cruza algún enlace con la MTU de 500 bytes. Por tanto se fragmentará en 4 partes:

Cuestión 1.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).

---

Vamos a probar con los dos puertos. El puerto 13 devuelve la fecha del día en que nos encontramos. Primero vamos a probar con el puerto 7 y tenemos lo siguiente:

Y para el puerto 13 tenemos.

Como vemos, en los dos casos hay una pregunta y una respuesta que vemos en el monitor de red.

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.

PRACTICA 3. PROTOCOLOS DE NIVEL DE TRANSPORTE TCP/IP

Los objetivos de la práctica 3 de la asignatura Redes 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.