Practicas de Redes 2010

Poner en práctica que la MTU en conexión funciona en el laboratorio.

En el monitor de red observamos como al principio el archivo enviado tiene un MTU de 460 y tras ello de 360, ya que al cambiar el encaminamiento, este nuevo tiene un MTU de 400, por tanto su MSS es de 360.

Al realizar ese cambio de enrutamiento en el monitor de red podemos observar un mensaje de error en el que nos avisa de que la nueva MTU  es de 400.

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 con el ordenador del compañero en ms-dos ponemos ftp y su dirección ip.

Obtenemos seis peticiones de intentar comunicarse sin obtener respuesta, y al fin ya pues deja de intentarlo.

Utiliza el programa rexec para ejecutar el comando cat ifconfig.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?

El valor está presente entre 1460 y 460, ya que al comenzar la MTU es de 1500 bytes y al cambiar el enrutamiento, este nuevo tiene una MTU de 500 bytes.

El tamaño es como mucho 500, la MTU es mucho más pequeña.

La diferencia es el cambio del enrutamiento, ya que la MTU cambia de tamaño siendo primero de 1500 bytes y después 500 bytes. Por tanto, la MSS disminuye a su vez, ya que ésta es la MTU menos los 20 bytes de cabecera del ip y los 20 bytes de cabecera de tcp.

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?

No los ha fragmentado ya que visualizamos  don´t fragment que es lo que tcp tiene activado, esto es debido a que tcp no fragmenta ya  que asi es mucho más seguro, lo cual es su prioridad.

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

El tamaño de MTU es 1500 bytes.

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

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

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

Si son bastante similares.

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

Comienza  utilizando como puerto fuente talnet 1838 y puente destino 512, estos van alternando como ya hemos visto en la teoría. Esto se cumple menos en el envío del rst tanto en el syn como en el ack, siendo en el syn el puerto fuente 3524 y el destino 113 y el ack al contrario.

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

-rw-r–r–    1 alumnos  users       36816 Apr 20 12:02 1720acc.txt

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

Utilizamos dicho programa enviando una fácil frase como “hola” y lo enviamos recibiendo a cambio como respuesta el echo request desde mi ordenador al Linux y echo response desde el Linux al mío.

Si enviamos al puerto 13 nos devuelve la fecha de hoy y la hora.

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

Sí, la petición de echo lo fragmenta dos veces, uno de 1480 bytes y otro de 623 bytes y la respuesta de echo lo fragmenta  cinco veces cuatro de 480 bytes de datos y uno de 183 bytes.