Prácticas Redes de Ordenadores

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.

b. Indica la MTU del camino de camino completo.

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.

Compártelo

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.

Atendiendo a la fotografía anterior se calcula en los dos casos de la siguiente forma

Nivel de transporte UDP	Nivel de transporte TCP
MSS     = MTU – Cab IP – Cab UDP = 500 – 20-8 = 472 bytes	MSS     = MTU – Cab IP – Cab TCP = 500 –20-20 = 460 bytes
Como enviamos 1000 bytes tenemos 3 paquetes: 1º 472 bytes 2º 472 bytes 3º 62 bytes	Como enviamos 1000 bytes tenemos 3 paquetes: 1º 460 bytes 2º 460 bytes 3º 80 bytes

Compártelo

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.

Vemos en la fotografía como mi ordenador produce una peticion TCP para conectarse y el ordenador al que intento conectar me devuelve un RST. Esto hace que intente conectarse enviando dos paquetes de petición TCP SYN produciendo el mismo resultado.

Compártelo

Cuestión 4

Utiliza el programa rexec para ejecutar el comando ‘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 tamaño de MSS varía de 1460 a 460 debido a las distintas subredes que atraviesa la información. Por otro lado los segmentos TCP transportados son del valor MTU de la red que es en este caso 500 ( Es un valor menor que el del ejemplo anterior)

Compártelo

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?

Como vemos en la imagen, en mi caso no se produce fragmentación debido a que los paquetes TCP recibidos poseen el bit don´t fragment activado.

Los segmentos IP poseen valor 1500 que es el valor de la MTU de la red.

Compártelo

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

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).
Poniendo el filtro ip.addr==172.20.43.200 && !nbns tenemos las siguientes capturas.

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.

Compártelo

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.

Compártelo

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.

Compártelo

Compártelo

Cuestión 5. Mensaje ICMP “Time Exceded”

Dentro del mensaje ICMP Time Exceeded se analizará el de código 0: Time to Live exceeded in Transit(11/0).

En primer lugar, inicia el monitor de red para capturar paquetes IP relacionados con la máquina del alumno y ejecuta el comando:

C:\> ping –i 1 –n 1 10.3.7.0

5.a. Finaliza la captura e indica máquina que envía el mensaje “ICMP Time to Live exceeded in Transit”… ¿Puedes saber su IP y su MAC? (identifica la máquina en la topología del anexo)

C:\>ping -i 1 -n 1 10.3.7.0

Haciendo ping a 10.3.7.0 con 32 bytes de datos:
Respuesta desde 172.20.43.230: El periodo de vida caducó en tránsito.
Estadísticas de ping para 10.3.7.0:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0 (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 0ms, Máximo = 0ms, Media = 0ms

Como podemos ver, la máquina que nos envía el mensaje tiene dirección IP 172.20.43.230 y MAC 00 07 0e 8C 8C FF, que corresponde si lo consultamos en la tipología del anexo al router Cisco 1720.

Inicia de nuevo la captura y ejecuta a continuación el comando:

C:\> ping –i 2 –n 1 10.3.7.0

5.b. Finaliza la captura y determina qué máquina envía ahora el mensaje “ICMP Time to Live

exceded in Transit”… Averigua y anota la IP y la MAC origen de este mensaje de error.

¿Pertenecen ambas direcciones a la misma máquina? (identifica las máquinas en la topología del

anexo)

En este caso la dirección IP origen del error es 10.4.2.5 correspondiente al serial 1 del router Cisco 2513 y la MAC 00 07 0e 8c 8c FF que corresponde al router anterior (Cisco 1720).

Como vemos no corresponden a la misma máquina.

Lo que sucede es que al expresar un tiempo de vida de 2 saltos en el ping (-i 2), el datagrama atraviesa el primer router y el segundo router devuelve el mensaje de error con su IP.

La MAC siempre es la indicada por el router más proximo a tu máquina que expresa la tipología de tu red, esto explica este fenómeno de no concordancia.

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

C:\>ping -i 50 -n 1 10.3.7.12
Haciendo ping a 10.3.7.12 con 32 bytes de datos:
Respuesta desde 10.3.2.0: El periodo de vida caducó en tránsito.
Estadísticas de ping para 10.3.7.12:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0 (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 0ms, Máximo = 0ms, Media = 0ms

5.c. 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?

El tipo asociado es 11 (Time to live exceed) y código 0 (Time to live exceed in transit).

Lo que sucede es que se está produciendo un bucle entre las máquinas 10.3.2.0 y 10.3.7.0 hasta que agotan el TTL y nos envía el router éste mensaje de error.

Estaría ubicada en la subred 10.3.0.0 situada entre esas máquinas.

5.d. Repite el ejercicio pero esta vez eleva el tiempo de vida del paquete a 220. ¿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)?

C:\>ping -i 220 -n 1 10.3.7.12

Haciendo ping a 10.3.7.12 con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.
Estadísticas de ping para 10.3.7.12:
Paquetes: enviados = 1, recibidos = 0, perdidos = 1 (100% perdidos),

En este caso sucede lo mismo que en el anterior solo que tarda más en aparecer el mensaje de error al hacer el ping con una TTL mayor.

Compártelo