Prácticas de Redes(I.T.T.)

Cuestión 7

mahg2 — Mon, 19 May 2008 08:34:34 +0000

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.

b. Indica la MTU del camino de camino completo.

La MTU es la menor de las 3, es decir, 500.

c. Una vez determinada la MTU del camino, mostrar la longitud total de cada paquete TCP.

Cuestión 6

mahg2 — Mon, 19 May 2008 08:06:50 +0000

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.

Cuestión 5

mahg2 — Mon, 19 May 2008 07:44:53 +0000

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?

En el monitor de red observamos los 3 intentos de conexion hasta que se conecta al final debido a que las máquinas están en red, pero termina perdiéndose la conexión porque tienen el módulo TCP desactivado.

Cuestión 4

mahg2 — Mon, 19 May 2008 07:28:01 +0000

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?

Negocian las MSS de 1460 de nuestra red y la de 460 de la red del servidor, quedandose con la menor de estas, esta es principalmente la mayor diferencia entre este ejercicio y el anterior que tenía las MSS de ambas iguales.

Cuestión 3

mahg2 — Mon, 12 May 2008 09:28:33 +0000

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?

No se han fragmentado los datos, puesto que en TCP/IP los segmentos no pueden fragmentarse, la MSS es de 1460 bytes.

Cuestión 2

mahg2 — Mon, 12 May 2008 09:23:52 +0000

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

Se observa que se realizan las peticiones de sincronización de exec, visualizando también la sincronización positivica de estos (ACK) y nuestra confirmación de nuevo, posteriormente se establece la sincronización, una vez echo esto se produce la autentificación de usuario y contraseña, y se envía dos veces la palabra Username : alumnos, finalmente se envían los datos y se finaliza la sincronización de las dos maquinas (cliente-servidor). Se observa que se envían muchos paquetes redundantes por culpa de emplear un protocolo tan seguro como es TCP.

El tamaño máximo de la ventana del servidor es 5840 bytes mientras que nuestro tamaño máximo de ventana (cliente) es 65535.

El puerto del servidor es el 512 y el del cliente (el mio) es 3875.

Cuestión 1

mahg2 — Mon, 12 May 2008 08:09:15 +0000

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

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

Se observan como los datos se han fragmentado, en nuestra red se han fragmentado en paquetes máximos de 1480 bytes de datos, no observamos las posteriores fragmentaciones en subredes cuyas MTU sean mas pequeñas cuyas banderas e identificadores son 0×02 en el primer paquete y 0×00 en el segundo y como identificador ambos 0x4b8b (19339).

En el caso de la recepción de paquetes observamos que los paquetes han pasado por alguna subred cuya MTU es igual a 500, las banderas del primer paquete 0×02, porque hay mas fragmentos, y del último 0×00 y el identificador es 0x00ae (174).

Hemos realizado el envio de la palabra echo al puerto 7 del pc Linux1, se trata de un envío eco.

Cuestión Tracert

mahg2 — Mon, 28 Apr 2008 07:50:15 +0000

Realiza una petición de traza desde Australia (red de Telstra.net) hacia la dirección www.ua.es. ¿Qué ciudades recorren los paquetes hasta que llegan a la Universidad de Alicante? ¿Cuantos routers son atravesados por paquetes (aproximadamente)?

Como puede observarse en la captura de pantalla un datagrama desde ese servidor de australia hasta el router de la UA pasa por 16 routers, siguiendo el siguiente camino:

Melbourne-Sydney-Los Ángeles- San Jose- Nueva York-Paris-Madrid-Valencia-Alicante(UA)

Realiza una petición de traza desde Rusia hasta la web de www.sony.com. Indica la ubicación de los routers por los que pasan los paquetes hasta que llegan al servidor web.

El datagrama IP desde dicho servidor ruso hasta ww.sony.com viaja por:

Rusia-Londres-NuevaYork(La Guardia)-Chicago-San Jose-Los Ángeles-Sony.com

Como se puede observar a continuación:

5.d.

mahg2 — Mon, 21 Apr 2008 08:24:31 +0000

¿Observas el mismo resultado con la misma rapidez? ¿En cuál de los dos casos ha tardado más la respuesta del ping (en MSDOS)?

Si, se observa el mismo resultado solo que esta vez ha tardado mas tiempo en MSDOS ya que tiene que esperar a que las máquinas 10.3.7.0 y 10.3.2.0 se envíen el mismo paquete mas veces que en el caso del ejercicio anterior.

5.c.

mahg2 — Mon, 21 Apr 2008 08:18:54 +0000

Por último, inicia de nuevo la captura y realiza un ping a la siguiente dirección:

C:\> ping –i 50 –n 1 10.3.7.12

Finaliza la captura y observa el mensaje de error ICMP que aparece en el monitor de red. ¿Qué tipo y código tiene asociado ese mensaje? ¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error? ¿En qué subred estaría ubicada?

Este mensaje es de tipo 11 y código 0, que las máquinas 10.3.2.0 y 10.3.7.0 están enviandose el mensaje echo reply hasta que agotan el TTL que cada envio se reduce en una unidad y la máquina en la que llegamos a TTL=0 envía el mensaje de error. Estaría ubicado en la subred que hay entre esas dos máquinas.