Práctica 3.Cuestión 7

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.

Se genera un mensaje de error ICMP

TIPO	3
CODIGO	4
NUMERO	1

 

 

b. Indica la MTU del camino de camino completo.

Según la norma RFC 1191, la MTU será la menor de las MTU del camino recorrido. Par averiguar esto, el emisor envía dos o tres paquetes tcp, investigando las MTU intermedias. Si se reciben mensajes de error ICMP se cambiará la forma de actuación respecto al tamaño futuro de los paquetes TCP. En esta topología, una vez realizados los envíos de prueba y recorrido todo el camino tendremos una MTU=500 bytes.

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.

CABECERA ETHERNET (BYTES)	CABECERA IP (BYTES)	Cabecera TCP (BYTES)	Datos (BYTES)
14	20	20	460
14	20	20	460
14	20	20	460
14	20	20	120

Práctica 3: Cuestión 3

 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?

 

Al realizar lo que se pide en el enunciado de la práctica vemos que no nos sale nada en el programa rexec, y esto se debe a que han eliminado el archivo file1.txt. Seguidamente buscamos otro introduciendo -ls donde nos aparecen los archivos existentes en el servidor y cogemos ifconig.txt con tiene un tamaño parecido a file1.txt. A continuación ejecutamos el comando ‘cat ifconfig.txt’ en el servidor 172.20.43.232 como se puede ver en la siguiente figura.

 

 

 

y observando la imagen de la captura se puede ver que no existe fragmentación ya que

TCP no permite la fragmentación de los datagramas. TCP lo divide en segmentos, calculando previamente la MSS y la MTU en la que sigue la siguiente estructura:

 

 MTU = CABECERA IP + CABECERA TCP + DATOS

 

Práctica 3:Cuestión 1

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

Como se puede ver en la imagen, el procedimiento de transporte UDP del envío de una palabra es el mismo que una ejecución ping. Se realiza una petición eco con la palabra a enviar a la máquina destino y esta devuelve la misma palabra como respuesta a esa petición.

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

En este apartado he copiado y pegado una parte del texto introductorio del enunciado de la práctica.

Se ha realizado el envío a través del puerto 7 y se puede ver que se ha producido una petición echo( request) y 1 paquete IP, el cual es parte de la fragmentación del archivo original. Y como respuesta, se puede ver que se ha recibido una respuesta echo (response) y 5 paquetes IP. Esto se debe a la diferencia de MTU de la red que envía la petición y de la que la recibe.

 

Práctica 3. Cuestión 6

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.

MTU = 500 bytes

En UDP envía 3 paquetes uno con 472 bytes de datos en el que aparte de la cabecera IP envía la cabecera UDP, otro con 480 bytes de datos mas la cabecera IP y un tercero de 56 bytes de datos mas la cabecera IP.

 

Paquete 1. Cabecera IP =20 bytes; Cabecera UDP = 8 bytes; Datos = 472 bytes

Paquete 2. Cabecera IP =20 bytes; Datos = 480 bytes;

Paquete 3. Cabecera IP =20 bytes; Datos = 56 bytes;

 

En TCP envía 3 paquetes en los cuales todos tienen cabecera IP y TCP. Envía dos paquetes de 472 bytes de datos y un tercero de 60

Paquete 1. Cabecera IP =20 bytes Cabecera TCP = 20 bytes Datos = 460 bytes

Paquete 2. Cabecera IP =20 bytes Cabecera TCP = 20 bytes Datos = 460 bytes

Paquete 3. Cabecera IP =20 bytes Cabecera TCP = 20 bytes Datos = 60 bytes

Práctica 3. Cuestión 5

 

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?

Como se puede observar en la siguiente figura para realizar la conexión FTP se introduce en MS-DOS el siguiente comando:

C:\ > ftp 172.20.43.208

 

Ahora observamos la captura y se puede ver como la maquina con la que realizamos la conexión FTP realiza tres intentos de conexión al servicio FTP con el flag SYN. A continuación de cada petición de conexión, la máquina del compañero (destino) responde con un mensaje RST (reset) y finalmente no se establece conexión.

 

Práctica 3: Cuestión 2

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

Como se puede ver en la imagen de la captura si que cumple las secuencias mostradas en la figura 6. Observamos como en primer lugar se realiza el establecimiento de la conexión, donde el ordenador del alumno lanza el primer segmento con flag SYN donde solicita el establecimiento de una conexión. Después se produce una apertura simultánea con dos procesos TCP en la máquina servidor 172.20.43.232 y se envía un único segmento SYN+ACK estableciéndose una única conexión. Seguidamente el ordenador del alumno o cliente envía el tercer segmento con el flag ACK donde se confirma la recepción del segundo segmento con flag ACK.

Después del establecimiento de la conexión se ve como se efectúa la transmisión de datos entre la máquina del alumno y el servidor y en esta parte se produce la autentificación del cliente por parte del servidor donde el cliente contesta a una solicitud de SYN del servidor con un RST.

Para finalizar se puede ver como la máquina cliente envía un segmento con dos procesos, uno de flag ACK y otro de tipo FIN con el que se finaliza la conexión.

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

Los puertos utilizados en la conexión son los siguientes:

Puerto 3230

Puerto 512

El segmento en el que se realiza la autentificación del cliente por parte del servidor se propaga por los puertos 113 y 2631.

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

Los valores de ventana son los siguientes:

Para receptor 172.20.43.232 (servidor) Window size: 65535

Para receptor 172.20.43.198 (cliente) Window size: 5840

Práctica 2.Cuestión 5

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)

 

Su direcciones IP y MAC se pueden obtener con Wireshark .

IP = 172.20.43.230

MAC = 00:07:0e:8c:8c:ff

 

 

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

 

Aunque la IP no sea la misma, la dirección MAC si que lo  es, por tanto se trata de la misma máquina que en el caso anterior.

 

 

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?

 

 

Como se muestra en la figura siguiente se trata de un error ICMP de tipo 11 y código 0.

 

Lo que sucede es que el TTL se iguala a 0 y por tanto el datagrama se elimina de la red.
El mensaje de error viene de la subred marcada en la siguiente imagen:

 

 

 

 

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

 

Al repetir el ping con TTL=220  en la ventana de MSDOS aparece que el paquete se ha perdido, seguidamente se cambia a 120 y tarda considerablemente  más que el apartado anterior.

Práctica 2. Cuestión 4

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

(antes de contestar debes confirmar que en MSDOS el resultado del Ping es correcto: paquetes enviados:1 , paquetes recibidos:1, sino debes repetir los dos comandos anteriores y el proceso de captura en el Monitor de Red)

 

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
1	Tipo= 8;Código= 0;	74	172.20.43.209	10.4.2.1
2	Tipo= 5;Código= 1;	70	172.20.43.230	172.20.43.209
3	Tipo= 0;Código= 0;	74	10.4.2.1	172.20.43.209

 

 

4.b. Dibujar gráficamente el origen y destino de cada datagrama (como se ha realizado en la figura 7, pero incorporando el direccionamiento IP correcto de las máquinas involucradas).

 

4.c. ¿Observas los mismos datagramas en el Monitor de Red con respecto a los que se comentan en la explicación teórica del Redirect? ¿Por qué puede suceder esto?

 

No es como en teoría. Falta el datagrama IP (2) que va desde la puerta de enlace por defecto del laboratorio 172.20.43.230 hasta la máquina 172.20.43.231(de router a router). Esto se debe a que se realiza un filtrado que consiste en que los mensajes entre routers no pueden visualizarse por seguridad.

 

4.d. ¿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	¿representan al mismo interfaz?
1	Tipo 8; Código 0;	00:0a:5e:76:90:9d	172.20.43.209	Si
2	Tipo 5; Código 1;	00:07:0e:8c:8c:ff	172.20.43.230	Si
3	Tipo 0; Código 0;	00:d0:ba:eo.6a:3d	10.4.2.1	No

 

 

4.e. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?

 

El mensaje Redirect lo envía la máquina configurada como puerta de enlace predeterminada del laboratorio de prácticas que se identifica en la toppologia del anexo como router cisco 1720 con IP 172.20.43.230.

 

4.f. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect? ¿Transporta algún otro tipo de información extra?

 

Transporta la dirección de internet del encaminador que  informa a la máquina origen que actualice su tabla de encaminamiento y contiene la IP de salida correcta.

 

 

4.g. 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?

 

                       

 

	Identificación	TTL	Cheksum
Datagrama Original	0×99d0	128	0×465c (correct)
Mensaje Redirect	0×99d0	255	0×465c (incorrect, should be 0xf0ff)

 

Sí, se puede encontrar el mismo identificador. El campo TTL en el datagrama original es de 128 y en el Mensaje Redirect se ha incrementado a 255.Para finalizar en el campo cheksum se puede ver que pasa de un estado correcto en el Datagrama Original a un estado incorrecto en el Mensaje Redirect.

 

 

 

 

Práctica2. Cuestión 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)

 

 

Como se puede apreciar en la imagen de la captura nos aparecen dos tramas de protocolo ICMP.

DIRECCION IP/MAC	EQUIPO	INFO
10.3.7.0 (00:07:0e:8c:8c:ff)	LINUX 1	Echo (ping) request
10.4.2.5(00:07:0e:8c:8c:ff)	CISCO 2513	Destination unreachable (Fragmentation needed

 

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)

 

Si se observa la imagen del apartado anterior de la captura se puede ver que la máquina que envía este mensaje es la 10.4.2.5 y  buscando en la información que nos proporciona wireshark podemos ver su MAC(00:07:0e:8c:8c:ff) y que se trata la máquina del anexo CISCO 2513.

Práctica 2. Cuestión 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

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

 

 

Los paquetes que podemos visualizar en la captura son de tipo IP e ICMP. Dos tramas de tipo ICMP para el ‘ping’(solicitud y respuesta eco) y dos tramas de tipo IP para la fragmentación del ‘ping’.

 

¿qué aparece en la columna ‘info” del Monitor de Red?

 

La columna info se encuentra situada en el lado derecho de la pantalla de wireshark y nos muestra lo que se ve en la siguiente figura:

 

2.b. ¿En cuantos fragmentos se ha “dividido” el datagrama original?

Como se puede apreciar en la figura anterior, el datagrama se ha dividido en dos.

 

2.c. Analiza la cabecera de cada datagrama IP de los paquetes relacionados con el “ping” interior. 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	FLAGS	FRAGMENT OFFSET	DIRECCIÓN		IDENTIFICACIÓN
1	IP	0×02	0	172.20.43.230		0×045b
2	ICMP(request)	0×00	1480	172.20.43.230		0×045b
3	IP	0×02	0	172.20.43.209		0×045b
4	ICMP(reply)	0×00	1480	172.20.43.209		0×045b

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?

 

 

 

En la imagen de la captura se puede ver que se visualizan 2 tramas, 1 datagrama de la petición ping y  otro de  la respuesta ping, el filtro a quitado las tramas de los fragmentos, esto se debe a que al fragmentarse el ping solo hay una cabecera icmp situada en el primer fragmento, y en los siguientes fragmentos los datos son considerados como ip ya que no tienen datos de cabecera icmp.

 

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

El campo identificación se emplea para saber si los datos pertenecen a una misma trama de un datagrama.

 

El campo flags se emplea para saber si un datagrama está dividido en particiones e indica el numero de esa partición y cuantos hay.

 

El campo fragment offset, se utiliza para la unión de las particiones, porque indica la posición a partir de la que se deben introducir los datos de esa trama.

 

2.f. En función de los datos anteriores, indica el valor de la MTU de la red.

 

El valor de la MTU de la red son 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):

 

 

DATAGRAMA	PROTOCOLO	FLAGS	FRAGMENT OFFSET	DIRECCIÓN	IDENTIFICACIÓN
1	IP	0×02	0	172.20.43.195	0×0665
2	IP	0×02	1480	172.20.43.195	0×0665
3	ICMP(request)	0×00	2960	172.20.43.195	0×0665
4	IP	0×02	0	172.20.43.209	0×7ce8
5	IP	0×02	1480	172.20.43.209	0×7ce8
6	ICMP(reply)	0×00	2960	172.20.43.209	0×7ce8

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

 

Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):

 

DATAGRAMA	PROTOCOLO	FLAGS	FRAGMENT OFFSET	DIRECCIÓN	IDENTIFICACIÓN
1	IP	0×02	0	10.3.7.0	0×05b3
2	ICMP(request)	0×00	1480	10.3.7.0	0×0058
3	IP	0×02	1440	172.20.43.209	0×0058
4	IP	0×02	960	172.20.43.209	0×0058
5	IP	0×02	480	172.20.43.209	0×0058
6	ICMP(reply)	0×00	0	172.20.43.209	0×0058

2.i. En relación a los datos de la pregunta 2.h. obtenidos del Monitor de Red, contesta:

¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)?

Porque hay una subred cuya MTU es menor de 1500 y debido a esto los fragmentos del ping con protocolo IP (vuelta) deben de ser más pequeños y fragmentarse en mas datagramas.

 

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?