Cuestión 3.1
– 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).
Filtramos los mensajes de control y todas las tramas que no tengan como destinatario o fuente nuestra IP. Solo quedan dos tramas pertenecientes a un ECHO y a un ICMP.
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…)
Aparecen tres datagramas en el monitor de red, el ECHO (UDP), el ICMP y el IP que es el fragmentado, ya que el texto tenía 2000 Bytes y el MTU de la red es de 1500 Bytes.
Datagrama IP: El fragmentado tiene el bit de “Don’t fragment ” a 0, ya que sino no se hubiese podido fragmentar, y el de “More fragments“ a 1. Longitud total de 1500 Bytes (1480 de datos).
ECHO: Contiene la información que no cabía en el primer datagrama IP. Tiene todos los bits de Flags a 0. Longitud total de 828 Bytes.
Cuestión 3.2
– 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).
Figura 6
En el orden de las secuencias se puede ver como enviamos un SYN y se nos devuelve un ACK/SYN (Establecer conexión bidireccional).
Se produce un error por CHECKSUM incorrecto, ya que tiene ese bit activado y no el de GOOD CHECKSUM. Es un error que se corrige gracias a la redundancia del TCP.
Se la maquina Linux nos envía una ACK y una SYN y le devolvemos un RST/ACK para solicitar que se restablezca la nueva conexión.
Finalmente enviamos un FIN/ACK y se nos devuelve un ACK con lo que la conexión queda finalizada.
• Comprueba el valor de los puertos utilizados. Indica su valor.
Puerto del Servidor (fijo): 512
Puerto Local (variable): 3632
• Analizar los valores de la ventana de receptor. ¿Cuál es más grande?
Los mayores son un TCP ACK y un EXEC que tiene de ventana 65535 Bytes
Cuestión 3.3
– 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?
TCP no permite la fragmentación de los datagramas. Esto se arregla con la segmentación, calculando la MSS y la MTU.
MMS = MTU – Cab IP – Cab TCP = 1500 – 20 – 20 = 1460 Bytes.
Cuestión 3.4
– 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).
Cuestión 3.5
– 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?
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.
Cuestión 3.6
– 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.
MSS = MTU – Cab IP – Cab UDP MSS = MTU – Cab IP – Cab UDP
= 500 – 20 – 8 = 500 – 20 – 20
= 472 Bytes de datos = 460 Bytes de datos
Datagrama Datagrama
1 472 Bytes 1 460 Bytes
2 472 Bytes 2 460 Bytes
3 64 Bytes 3 460 Bytes
4 20 Bytes
Cuestión 3.7
– 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.
Cuestión 2.1
Cuestión 1. Sobre mensajes ICMP del “Ping”
Inicia el programa Monitor de Red en modo captura. A continuación ejecuta el comando:
C:\>ping –n 1 172.20.43.230 (…la opción –n especifica el número de peticiones “echo” que se lanzan al medio)
Detener la captura en el Monitor de Red (filtrar únicamente tramas del alumno) y visualizar los paquetes capturados. En base a los paquetes capturados determinar:
1.a. ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)
Aparecen 2 mensajes de ICMP, el “Echo Request” y el “Echo Reply”
Dentro de la información de ICMP podemos ver el tipo, código, y datos entre otros.
Tipo Codigo
Echo Request: 8 0
Echo Reply: 0 0
1.b. Justifica la procedencia de cada dirección MAC e IP. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP “Replay” hacen referencia a la misma máquina o interfaz de red?
Sí que coinciden, IP (172.20.43.230), MAC (00:07:0E:8C:8C:FF), ya que la petición de ping se hace al router. Sí el ping se hiciera al exterior de red, aparecería la MAC de antes (de la puerta de enlace), pero la IP sería a la que llamamos.
1.c. Justifica la longitud de los paquetes IP. ¿Cuál es el tamaño total del ICMP? ¿Por qué tienen esa longitud?¿Cuántos datos se han transportado en el mensaje “ping”? Dibuja la encapsulación del protocolo ICMP.
Cabecera Ethernet 14 Bytes
Cabecera IP 20 Bytes
Cabecera ICMP 8 Bytes
Datos ICMP 32 Bytes |
Total 74 Bytes
Cuestión 2.2
Cuestión 2. Sobre la fragmentación de datagramas IP
Empleando el programa Monitor de Red de la misma forma que en la situación anterior, ejecutar: C:\>ping –n 1 –l 2000 172.20.43.230 (…la opción –l especifica la cantidad de datos a enviar)
2.a. Filtra los paquetes en los que esté involucrada tu dirección IP. A continuación, describe el número total de fragmentos correspondientes al datagrama IP lanzado al medio, tanto en la petición de ping como en la respuesta. ¿Cómo están identificados en el Monitor de Red todos estos paquetes (ICMP, IP, HTTP, TCP…)? ¿qué aparece en la columna ‘info” del Monitor de Red?
Hay dos ICMP (los correspondientes a los Echos) y dos IP, que son los correspondientes al segundo fragmento, por ser solo un datagrama de datos (no un ICMP).
2.b. ¿En cuantos fragmentos se ha “dividido” el datagrama original?
En dos, ya que 2000 > a la MTU de nuestra Ethernet de 1500.
2.c. Analiza la cabecera de cada datagrama IP de los paquetes relacionados con el “ping” anterior. Observa el campo “identificación”, “Flags” y “Fragment offset” de los datagramas. ¿Qué valor tienen en estos campos en los datagramas anteriores? Indica en la columna “dirección” si son de petición o respuesta. Muestra los datagramas en el orden de aparición del Monitor de Red.
Datagrama Protocolo Dirección Flags Frag. Offset Identificación
1 65 ICMP P. Enlace 1 0 35989
2 66 IP P. Enlace 0 1480 35989
3 67 ICMP Mi Pc 1 0 35989
4 68 IP Mi Pc 0 1480 35989
Flags se refiere a que si que quedan fragmentos (1, si que quedan, 0 no)
2.d. ¿Qué ocurre en la visualización de los fragmentos de datagramas si introduces un filtro para ver únicamente paquetes de “icmp” en el Monitor de Red? ¿qué fragmentos visualizas ahora? ¿por qué puede suceder esto?
Solo los datagramas 65 y 67 son ICMP, los otros dos son IP.
2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?
Identificación: es un número único que asigna el emisor para ayudar a reensamblar un datagrama fragmentado. Los fragmentos de un datagrama tendrán el mismo número de identificación.
Flags: controlan la fragmentación.
Fragment Offset: Se usa en datagramas fragmentados para ayudar al reensamblado de todo el datagrama.
2.f. En función de los datos anteriores, indica el valor de la MTU de la red.
El tamaño total del datagrama 65 (que se fragmento por estar lleno de información), es 1500 bytes
2.g. Repite el ejercicio lazando una petición de ping con un mayor número de datos y al destino “.195”: C:\>ping –n 1 –l 3000 172.20.43.195
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):
2.h. A continuación, se pretende observar que los datagramas pueden fragmentarse en unidades más pequeñas si tienen que atravesar redes en las que la MTU es menor a la red inicial en la que se lanzaron los paquetes originales. Inicia el Monitor de Red y captura los paquetes IP relacionados con el siguiente comando:
C:\>ping –n 1 –l 1600 10.3.7.0
(antes de contestar debes confirmar que en MSDOS el resultado del ping es correcto: paquetes enviados:1 , paquetes recibidos:1)
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):
2.i. En relación a los datos de la pregunta 2.g. obtenidos del Monitor de Red, contesta: ¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)? Indica en que subred del laboratorio el número de fragmentos que circulan por el medio es el mismo tanto en la petición como en la respuesta. Deduce en que otra subred no sucede esto. Señala (en la topología del laboratorio adjunta), la MTU de cada una de las subredes por las que circulan los datagramas que salen de tu máquina hacia la dirección 10.3.7.0. ¿Cuántas subredes se atraviesan?
La razón por la que hay más fragmentos de IP de vuelta es por qué al fragmentar en un punto, se crean varios Echo Request. Al llegar al destino, este devuelve tantos Echo Replys como Requests le hayan llegado, y por las limitaciones del protocolo no se vuelven a juntar en uno solo (donde el MTU ya sea más grande), ya que solo se pueden reensablar en origen.
172.20.43.230 MTU = 1500 Bytes
10.4.2.5 MTU = 1500 Bytes
10.3.7.0 MTU = 500 bytes
Por tanto se atraviesan 3 subredes.
Cuestión 2.3
Cuestión 3. Mensaje ICMP “Destination Unreachable”
Dentro del mensaje ICMP Destination Unreachable se analizará el de código 4: Fragmentation Needed and Don’t Fragment was Set (3/4). En primer lugar ejecuta el comando:
C:\>route delete 10.3.7.0 ( si ya ha sido borrada la ruta, avisa con un error)
¿Porqué ejecutar este comando? En MS Windows, con route se modifican las tablas de encaminamiento de una máquina. Con la opción delete eliminamos un camino o ruta a la dirección especificada. Al eliminarlo, borramos también cualquier información asociada a esa dirección, incluida la información sobre errores previos al acceder a ese destino.
A continuación, poner en marcha el Monitor de Red en modo captura y ejecutar el comando ping:
C:\>ping -n 1 –l 1000 -f 10.3.7.0 (…la opción –f impide la fragmentación de los datagramas en la red)
En base a los paquetes capturados, indicar:
3.a. Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen? (identifica la máquina con la topología del anexo)
Si filtramos las tramas de control y los datagramas ICMP, aparecen 2 tramas
172.20.43.201 la dirección del equipo en el que estoy trabajando.
10.4.2.5 pertenece a Cisco 2513
10.3.7.0 pertenece a Linux 1
3.b. ¿Qué máquina de la red envía el mensaje ICMP “Fragmentation Needed and Don’t Fragment was Set” (3/4)? (identifica la máquina con la topología del anexo)
La máquina con dirección IP 10.4.2.5, que pertenece a Cisco 2513
Redes de Ordenadores UA by Barrawein 
