Cuestión 6
Realiza una conexión FTP a la máquina 172.20.41.241, utilizando las rutas:
- route add 172.20.41.241 172.20.43.231 (para añadir nueva puerta enlace)
- route delete 172.20.41.241 (para eliminar)
¿Qué obtienes en el Monitor de Red al intentar realizar esta conexión?
Envio de datos a FTP:
Fin de envio de datos a FTP:
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?
En el monitor de red aparecen 3 intentos de conexión a la ftp que estamos lanzando.
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?
El valor que se negocia para cada extremo es:
Para la máquina que estamos,
Para la máquina Linux 1,
Por lo tanto, el tamaño de los segmentos TCP que se transportaran serán de 460 bytes de datos.
La diferencia fundamental respecto al ejercicio anterior es que en este caso los segmentos TCP contendrán menos datos.
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?
No se ve la fragmentación IP porque esta activado el byte Don’t Fragment.
Esto ocurre porque TCP crea sus segmentos respetando el tamaño máximo de
El tamaño máximo de un segmento TCP es de 1460 bytes. Esto se consigue partiendo de los datos máximos de
Aquí podemos ver una captura de lo comentado anteriormente:
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).
Según la captura que hemos realizado, se puede observar que tiene similitudes con lo que se detalla en la figura 6 de teoría.
Comprueba el valor de los puertos utilizados. Indica su valor.
Los puertos utilizados para los flags ACK son de valor 2170 para el puerto local y 512 para el puerto del servidor.
Los puertos utilizados para los flags SYN son de valor 3621 para el puerto local y 113 para el puerto del servidor.
Analizar los valores de la ventana de receptor. ¿Cuál es más grande?
La ventana de receptor más grande es la 65535.
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).
Realizando en el puerto 7, nos sale el protocolo ECHO:
Realizando en el puerto 13, nos sale el datagrama DAYTIME:
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…)
Cuestión 7. Sobre direccionamiento IP y creación de subredes
7.a Dada la dirección de clase B 145.65.0.0, se desean 6 subredes. ¿Cuántos bits se tendrán que reservar para crear las subredes? Indica el valor decimal de las subredes, así como el valor de la nueva máscara de subred.
Dirección de red 10010001.01000001.00000000.00000000
6 subredes = 3 bits
10010001.01000001.00000000.00000000 145.65.0.0
10010001.01000001.00100000.00000000 145.65.32.0
10010001.01000001.01000000.00000000 145.65.64.0
10010001.01000001.01100000.00000000 145.65.96.0
10010001.01000001.10000000.00000000 145.65.128.0
10010001.01000001.10100000.00000000 145.65.160.0
Nueva máscara subred 11111111.11111111.11100000.00000000 255.255.224.0
7.b Sea la dirección de red IP 125.145.64.0 con máscara asociada 255.255.254.0. Ampliar la máscara de subred en dos bits, indicando el nuevo valor. Determina el rango de direcciones IP que puede emplearse para numerar máquinas en cada una de las subredes obtenidas en la ampliación.
Dirección de red 01010101.10010001.01000000.00000000
Máscara de subred 11111111.11111111.11111110.00000000
Aumentamos en 2 bits la máscara de subred:
01010101.10010001.01000000.00000000 125.145.64.0 1ª subred
Rango = 1ª máquina 125.145.64.1 – Última máquina 125.145.64.126
01010101.10010001.01000000.10000000 125.145.64.128 2ª subred
Rango = 1ª máquina 125.145.64.129 – Última máquina 125.145.64.254
01010101.10010001.01000001.00000000 125.145.65.0 3ª subred
Rango = 1ª máquina 125.145.65.1 – Última máquina 125.145.65.126
01010101.10010001.01000001.10000000 125.145.65.128 4ª subred
Rango = 1ª máquina 125.145.65.129 – Última máquina 125.145.64.254
11111111.11111111.11111111.10000000
Tenemos una nueva máscara de subred 255.255.255.128
Iniciar el programa monitor de red. A continuación ejecutar el comando “Ping” en varias ventanas (en paralelo) de MSDOS, así lograrás mayor número de peticiones:
C:\>ping -n 80 -l 20000 10.3.7.0
Detener la captura y determinar:
6.a. ¿De qué máquina proceden los mensajes ICMP “Fragment Reassembly Time Exceded”? (identifica la máquina en la topología del anexo)
Proceden de la máquina 10.3.7.0.
6.b. ¿Por qué crees que pueden proceder de esa máquina y no de otra?
Porque al mandarle muchas peticiones, la máquina destino no llega a reesamblar.
Capturamos con 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)
Capturamos con 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)
No pertenecen a la misma máquina, aunque tengan la misma MAC, ya que la dirección 10.4.2.5 pilla la dirección MAC del 172.20.43.230.
Capturamos con el comando: C:\> ping –i 50 –n 1 10.3.7.12
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?
Tipo 11 código 0
En la subred 10.3.7.0
4.a. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos…(tipo, código y tamaño)
| Nº Datagrama | Tipo y código ICMP | Tamaño del paquete ICMP | Origen IP | Destino IP |
| 80 | Tipo 8, Código 0 | 32 bytes | 172.20.43.212 | 10.4.2.1 |
| 81 | Tipo 5, Código 1 | | 172.20.43.230 | 172.20.43.212 |
| 82 | Tipo 0, Código 0 | 32 bytes | 10.4.2.1 | 172.20.43.212 |
4.b. ¿Las direcciones MAC e IP de todas las tramas capturadas con el Monitor de Red hacen referencia al mismo interfaz de red? Indica en qué casos la respuesta es afirmativa y en qué casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.
| Nº Datagrama | Tipo y código ICMP | Origen MAC – Origen IP | ¿representan el mismo inferfaz? |
| 80 | Tipo 8, Código 0 | 00:0a:5e:77:07:87 – 172.20.43.212 | Si |
| 81 | Tipo 5, Código 1 | | Si |
| 82 | Tipo 0, Código 0 | 00:d0:ba:e0:6a:3d – 10.4.2.1 | No |
4.c. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?
El 172.20.43.230, porque es la puerta de enlace determinado.
4.d. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect?
La nueva puerta de enlace determinado, que es la 172.20.43.231.
4.e. Observa los campos “Identificación”, “TTL” y “Cheksum” del datagrama que se envió originalmente. A continuación, analiza el contenido del mensaje Redirect. ¿Puedes encontrar la misma identificación dentro de los datos (no cabecera) del mensaje ICMP Redirect? ¿Qué ocurre con los campos TTL y Checksum del datagrama transportado por el Redirect?
Datagrama original:
Contenido del mensaje ICMP Redirect:
Como hemos observado, tanto en la datagrama original como en el contenido del mensaje ICMP Redirect llevan la misma identificación. Pero en la TTL cambia, ya que al cambiar al router 2 (172.20.23.231), se pierde un TTL por el camino (router 1 a router 2).
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)
| Nº Datagrama | IP origen | IP destino | MAC origen | MAC destino |
| 216 | 172.20.43.212 | 10.7.3.0 | 00:0a:5e:77:07:87 | |
| 217 | 10.4.2.5 | 172.20.43.212 | | 00:0a:5e:77:07:87 |
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)
En la topología, observamos que la máquina que hace el envío del mensaje ICMP “Fragmentation Needed and Don't Fragment was Set” es la máquina 10.4.2.5
El 1 es el envio que hace nuestra máquina hacia Cisco 2513, el 2 es el que nos llega desde ese mismo router, y el 3 es el que deberia de llegar al de Linux 1.
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?
2.b. ¿En cuántos fragmentos se ha “dividido” el datagrama original?
Se ha dividivo en dos, en el ICMP contiene los 1480 datos (20 de cabecera IP) y en el IP fragment, los 528 restantes (20 de cabecera), de los 2000 datos totales que hemos enviado mediante la instrucción –l.
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.
| Nº Datagrama | Protocolo | Dirección | Flags | Frag. offset | Identificación |
| 73 | ICMP | Petición | 0x01 | 0 | 0x371e |
| 74 | IP | Petición | 0x00 | 1480 | 0x371e |
| 75 | ICMP | Respuesta | 0x01 | 0 | 0x371e |
| 76 | IP | Respuesta | 0x00 | 1480 | 0x371e |
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?
Visualizamos los dos datagramas ICMP (request y replay), con los 1500 datos.
2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?
La identificación se utiliza para saber si los datos pertenecen a un mismo datagrama.
Los flags se utilizan para identificar si un datagrama tiene particiones e indica el número de esa partición.
El fragment offset se utiliza para indicar la posición para el cual deben escribirse los datos de la trama. Se tambien utiliza para el reensambaldo.
2.f. 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
| Nº Datagrama | Protocolo | Dirección | Flags | Frag. offset | Identificación |
| 69 | ICMP | Petición | 0x01 | 0 | 0x437e |
| 70 | IP | Petición | 0x00 | 1480 | 0x437e |
| 93 | IP | Respuesta | 0x00 | 1440 | 0x00a1 |
| 96 | IP | Respuesta | 0x01 | 960 | 0x00a1 |
| 102 | IP | Respuesta | 0x01 | 480 | 0x00a1 |
| 109 | ICMP | Respuesta | 0x01 | 0 | 0x00a1 |
