Practica 3 de Redes de Ordenadores (6/6)

Cuestion 6

Cambiamos la ruta por la cual nos conectamos a la maquina Linux 1. Para ello hacemos lo siguente:

Route delete 172.20.41.241
Route ad 172.20.41 172.20.43.231

C:\ftp 172.20.41.241
Usuario: alumnos
Pass: alumnos
bin
put p3.txt
quit

Al intentar enviar el archivo, manda un paquete de 460 bytes. Despues recibe un error con el nuevo tamaño del MTU para que la maquina vuelva a enviar nuevos paquetes con ese nuevo tamaño. Despues de que empiecen a llegar bien los paquetes, se envian cada vez mas.

Practica 3 de Redes de Ordenadores (5/6)

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?

Se obtienen varios intentos de conexión y posteriormente un error desconocido en la consola de comandos.

Practica 3 de Redes de Ordenadores (4/6)

Cuestión 4

Utiliza el programa rexec para ejecutar el comando ‘cat p3.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 máximo de segmento es de 1460 bytes. Este es el tamaño que se negocia, pero el servidor contesta diciendo que el tamaño máximo debe ser 460 bytes.

Practica 3 de Redes de Ordenadores (3/6)

Cuestión 3

Utiliza el programa rexec para ejecutar el comando ‘cat ifconfig.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 ha fragmentado los segmentos ya que el bit “don’t fragment” esta activado. Esto ocurre porque el protocolo TCP exige cierta seguridad en la transmisión de los datos.

El tamaño máximo es de 1460 bytes.

Practica 3 de Redes de Ordenadores (2/6)

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

Aparentemente, si que hay una estructura similar a la de la figura 6 en cuanto a las conexiones que se establecen.

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

El puerto local es el 1127 y el puerto del servidor el 512.

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

Los valores de ventana más grandes los tienen las tramas de conexión/desconexión.

Practica 3 de Redes de Ordenadores (1/6)

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

Aparece una trama con el protocolo echo, cuyo contenido es la palabra hola.

En el caso del daytime, aparece daytime request y en el interior de la trama, la misma palabra. Acto seguido aparece la respuesta con la fecha y la hora actuales.

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

Si que se produce fragmentación IP. El tamaño de los fragmentos es de 1480 bytes

Practica 2 de Redes de Ordenadores (7/7)

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.

Se necesitan reservar por lo menos 3 bit, porque con 2, solo podríamos hacer 4 subredes. Estas son las diferentes subredes que se pueden crear con 3 bit. Para este caso sólo nos quedamos con las 6 subredes que nos interesan.

145.65.0.0 11111111.11111111.000 00000.00000000

145.65.32.0 11111111.11111111.001 00000.00000000

145.65.64.0 11111111.11111111.010 00000.00000000

145.65.96.0 11111111.11111111.011 00000.00000000

145.65.128.0 11111111.11111111.100 00000.00000000

145.65.160.0 11111111.11111111.101 00000.00000000

145.65.192.0 11111111.11111111.110 00000.00000000

145.65.224.0 11111111.11111111.111 00000.00000000

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.

Para formar 4 subredes, usamos los 2 primeros bits a 0 en la siguiente mascara:

11111111.11111111.11111110.00000000

Asi podremos crear 4 nuevas subredes con las siguientes combinaciones 00, 01, 10, 11

Practica 2 de Redes de Ordenadores (6/7)

Cuestión 6. Mensaje ICMP “Fragment Reassembly Time Exceeded”

En esta cuestión se analizará el mensaje ICMP tipo 11 código 1. Para ello, se va a intentar “saturar” a una determinada máquina del laboratorio enviándole un número elevado de peticiones Ping. Este elevado número de peticiones puede producir un error si la máquina destino tiene que realizar un reensamblado excesivo de de paquetes en un tiempo limitado.

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 maquina 10.3.7.0 que es el Linux 1 cuya MAC es 00:07:0E:8C:8C:FF

6.b. ¿Por qué crees que pueden proceder de esa máquina y no de otra?

Porque la MAC es de la puerta de enlace predeterminada del laboratorio.

Practica 2 de Redes de Ordenadores (5/7)

Cuestión 5. Mensaje ICMP “Time Exceeded”

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)

IP: 172.20.43.230

MAC: 00:07:0E:8C:8C:FF

La maquina es el 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)

IP: 10.4.2.5

MAC: 00:07:0E:8C:8C:FF

Pertenece al router Cisco 2513, pero las direcciones no coinciden. Esta vez el paquete ha llegado a una maquina mas, al tener un tiempo de vida mayor.

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

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?

Aparecen 2 errores. El primer error que aparece es de tipo 3 (destination unreachable) y código 1 (host unreachable) y el segundo error es de tipo 11 (time to live exceded) y de código 0 (time to live exceded in transit).

El error nos indica que la máquina está en otra red y que es imposible alcanzar a esa máquina.

La ip que nos envía el primer error es 172.25.40.65

Practica 2 de Redes de Ordenadores (4/7)

Cuestión 4. Mensaje ICMP “Redirect”

Inicia el Monitor de Red. A continuación ejecutar los comandos:

C:\>route delete 10.4.2.1 (si ya ha sido borrada la ruta, avisa con un error)

C:\>ping -n 1 10.4.2.1

En base a los paquetes capturados, filtra sólo los datagramas que contengan tu dirección IP y contesta a las siguientes preguntas:

4.a. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos (tipo, código y tamaño)

Datagrama nº	Tipo y código ICMP	Tamaño del paquete ICMP	Origen IP	Destino IP
144	8 / 0	32 bytes	172.20.43.211	10.4.2.1
145	5 / 1 y 8 / 0		172.20.43.230	172.20.43.211
146	0 / 0	32 bytes	10.4.2.1	172.20.43.211

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 que casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

Datagrama nº	Tipo y código ICMP	Origen MAC	Origen IP	¿Mismo interfaz?
144	8 / 0	00:0A:5E:76:FF:BC	172.20.43.211	SI
145	5 / 1 y 8 / 0	00:07:0E:8C:8C:FF	172.20.43.230	SI
146	0 / 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?

La maquina que envía ese mensaje es la 172.20.43.230.

4.d. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect?

Dentro del ICMP, aparece el protocolo IP y el ICMP de nuevo, que contiene información acerca del request que se lanzó al principio.

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 Cheksum del datagrama transportado por el Redirect?

Si analizamos los datos contenidos en esos paquetes, vemos que el paquete que tiene el mensaje Redirect, tiene en su interior, su propio identificador como paquete y el paquete que enviamos. Lo que coincide es el identificador del paquete request con el interno del Redirect, como es lógico.

El TTL original es de 128 y el que contiene el paquete de Redirect es de 127 ya que ha pasado por el primer router agotando en 1 ese tiempo.

Practica 2 de Redes de Ordenadores (3/7)

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)

Origen: 00:0a:5e:76:ff:bc – 172.20.43.211 – Mi Pc

Destino: 00:07:0e:8c:8c:ff – 10.3.7.0 – Linux 1

Origen: 00:07:0e:8c:8c:ff – 10.4.2.5 – Serial 1

Destino: 00:0a:5e:76:ff:bc – 172.20.43.211

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 maquina de la red que envía ese mensaje es la que tiene por dirección ip 10.4.2.5 y es el router cisco 2513

Practica 2 de Redes de Ordenadores (2/7)

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

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?

Origen Destino Prot Info

172.20.43.211 172.20.43.230 ICMP Echo (ping) request

172.20.43.211 172.20.43.230 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=3b7a)

172.20.43.230 172.20.43.211 ICMP Echo (ping) reply

172.20.43.230 172.20.43.211 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=3b7a)

2.b. ¿En cuántos fragmentos se ha “dividido” el datagrama original?

Como se puede ver en los datos anteriores, se ha dividido en dos fragmentos, tanto el request como el reply.

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º	Protocolo	Dirección	Flags	Frag. offset	Identificación
76	ICMP	Request	0x01	0	0x3b7a
77	IP	Request	0x00	1480	0x3b7a
78	ICMP	Reply	0x01	0	0x3b7a
79	IP	Reply	0x00	1480	0x3b7a

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?

Si introducimos el filtro, únicamente vemos los de ese protocolo, pero los fragmentos ip ya no aparecen.

2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?

Para poder identificar a que paquete original pertenece ese fragmento.

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º	Protocolo	Dirección	Flags	Frag. offset	Identificación
47	ICMP	Request	0x01	0	0x4235
48	IP	Request	0x00	1480	0x4235
65	IP	Reply	0x00	1440	0x009a
70	IP	Reply	0x01	960	0x009a
75	IP	Reply	0x01	480	0x009a
82	ICMP	Reply	0x01	0	0x009a