Práctica 3 Cuestión 7

Práctica 3
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’:

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

Se genera un mensaje de error ICMP >> Tipo: 3 (destino inaccesible) | Código: 4 (se necesita fragmentación)

b. Indica la MTU del camino de camino completo.

Según la norma RFC 1191, la MTU será la menor de las MTU del camino recorrido. Par averiguar esto, el emisor envía dos o tres paquetes tcp, investigando las MTU intermedias. Si se reciben mensajes de error ICMP se cambiará la forma de actuación respecto al tamaño futuro de los paquetes TCP. En esta topología, una vez realizados los envíos de prueba y recorrido todo el camino tendremos una MTU=500 bytes.

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.

Trama CAB. Ethernet CAB. IP CAB. TCP DATOS

1 14 20 20 460

2 14 20 20 460

3 14 20 20 460

4 14 20 20 120

Práctica 3 Cuestión 6

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.

Para calcular el número de paquetes UDP primero debemos conocer el MSS, que es el tamaño máximo de los datos de aplicación que el nivel de transporte acepta para evitar la fragmentación que, evidentemente, dependerá del valor de la MTU.

MSS = MTU – Cab IP – Cab UDP MSS = MTU – Cab IP – Cab UDP

500 – 20-8 = 472 bytes 500 –20-20 = 460 bytes

Datagrama Datagrama

1 472 Bytes 1 460 Bytes

2 472 Bytes 2 460 Bytes

3 64 Bytes 3 460 Bytes

4 20 Bytes

Práctica 3 Cuestión 5

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?

Lo hacemos mediante MS DOS escribiendo:

C:\>ftp 172.20.43.201

Conectado a 172.20.43.201.

Conexión cerrada por el host remoto.

Es debido a que el Windows tiene las opciones FTP deshabilitadas y parece que se quede colgado intentado conectar con las maquinas de mis compañeros. Se conecta físicamente pero no consigue una comunicación TCP.

En el capturador podemos observar como se realizan 3 peticiones de SYN y se nos devuelven 3 RST/ACK, solicitando un reconexión.

Práctica 3 Cuestión 4

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?

En este caso tampoco se produce una fragmentación debido al estrechamiento de la subred aunque ahora la MSS vale 460 (ya que la MTU es de 500 Bytes).

Práctica 3 Cuestión 3 b)

¿Cuál es el tamaño de los segmentos TCP?

Hay de varios tamaños, de 60 bytes, de 62 bytes, de 70 bytes, de 74 bytes y de 54 bytes.

Práctica 3 Cuestión 3 b)

¿Por qué ocurre esto?

TCP impide la fragmentación, crea los segmento de tamaño adecuado a la red, calcula el MSS. Los segmento tienen una estructura de datos TCP.

Práctica 3 Cuestión 3 a)

¿IP ha fragmentado estos segmentos?

No ha fragmentado.

Práctica 3 Cuestión 3

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.

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

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

Si nos fijamos en las secuencias de conexión desconexión TCP con la máquina 172.20.43.232 tenemos el siguiente diagrama.

Vemos como dice el enunciado que en la transmisión de datos nuestra máquina contesta a una solicitud de SYN del servidor con un RST (Restart - Solicita un reinicio de la conexión y se usa cuando ha habido un problema en la secuencia de bytes, cuando falla un intento de iniciar conexión opara rechazar paquetes no válidos). Esto es debido a que el servidor trata de identificarnos, pero nuestra máquina no le deja.

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

Básicamente utiliza el 1467 salvo para la orden RST ACK y su SYN anterior en los que emplea el 2692.

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

La más grande es de tamaño 64986 y corresponden a la parte de liberar conexión aproximadamente.

Introducción Práctica 3

En esta práctica profundizaremos en ele funcionamiento de los protocolos de transporte en la arquitectura de red. Conoceremos las características y el formato de las estructuras de datos de el nivel de transporte.

Por último se implementará una aplicación cliente/servidor que incorpore las funciones más típicas xigibles a un nivel de transporte TCP/IP.

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

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

Estas son las tramas capturadas, se puede apreciar en la imagen como al enviar datos al puerto 7 lo que recibimos es una repuesta de eco que contiene los mismos datos que enviamos. Si hubiéramos enviado los mismos datos hacia el puerto 13 habríamos recibido la información de el día y la hora.

b. Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Esto se uede hacer copiando parte de algún fichero de texto en la ventana de udp.exe. ¿Se produce ragmentació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 el identificador, flags, tamaño, etc…)

Como se puede ver en la captura, enviando un texto de aproximadamente 2 Kilobytes solamente tenemos un paquete fragmentado con un identifiacador 0xa0ff (41215), un fragment offset de 1480 y con 784 bytes de datos.