Anexo

En una ventana de MS-DOS y dentro del directorio raíz emplea el programa ftp para enviar el fichero c:\p3.txt al servidor 172.20.41.241. Para ello, utiliza la siguiente secuencia de comandos:

c:\ftp 172.20.41.241
Conectado a 172.20.41.241
220 Linux1.disc.ua.es FTP server (Version wu-2.4.2-academ(BETA-18-VR12)(1)
Wed Jan 27 22:19:46 CST 1999) ready,
Usuario (172.20.41.241:(none)):alumnos
331 Passoword required for alumnos.
Contraseña:alumnos
230 User alumnos logged in.
ftp> bin
200 Type set to I
ftp> put p3.txt
200 PORT command successful
150 Openning BINARY more data conection for rfc1191.txt
226 Transfer complete
ftp: 48730 bytes sent in 24.28 segundos 2.01 KB/s
ftp> quit
221- You have transfered 48730 bytes in 1 files.
221- Total traffic for this session was 49154 bytes in 1 tranfers.
221- Thank you for using the FTP service on Linux1.disc.ua.es.
221- Goodbye.

a) Determina con el monitor de red qué valor de MSS se ha negociado en la conexión TCP. Para ello visualiza TODOS los paquetes IP intercambiados entre tu PC y el servidor 172.20.41.241
MSS=460 bytes

b) ¿Hay paquetes ICMP "fragmentation needed and the bit don't fragment was set"? Si la respuesta es afirmativa, ¿qué máquina envía el mensaje de error?
Sí, hay uno. Lo envía la máquina cuya dirección IP es 172.20.43.231 que corresponde al Cisco 1601.

c) ¿Cómo afecta este mensaje ICMP al tamaño de los paquetes TCP intercambiados entre tu PC y el servidor 172.20.41.241?
Cambia la MSS que había de 460 bytes a 360 bytes (la MTU de 500 bytes a 400 bytes).

d) ¿Reenvía tu PC algún paquete TCP al servidor?
Sí. Reenvía tres paquetes de datos (en realidad, envía 1 y espera confirmación, tras lo cual envía otros dos y vuelve a esperar confirmación).

e) ¿Fragmenta IP algún paquete TCP?
No porque el protocolo TCP activa el bit Don't Fragment (de hecho, es por eso que se da el error ICMP gracias al cual sabemos la nueva MSS).

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':

1. Número, tipo y código de paquetes ICMP.
2. Indica la MTU del camino de camino completo.
3. 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.

1) En teoría, debería producirse una situación de error provocada por el hecho de no poder fragmentar el segmento por tener el bit 'Don't Fragment' activado (el protocol TCP siempre lo hace). Por tanto, recibiremos un único mensaje ICMP (porque sólo se dará una vez este error en este caso por la configuración de la red) que será de tipo 3 y código 4.
2) La MTU será la más pequeña de todos los valores, es decir, 500 bytes.
3)
Cabecera TCP= 20 bytes
MSS= 500-20-20= 460 bytes

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.

• UDP

- Cabecera: 8 bytes --> 1008 bytes al salir del nivel de transporte

• TCP (MSS=500-20-20=460 bytes)

- Cabecera: 20 bytes

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?
Básicamente podemos ver tres intentos de conexión (dos paquetes de datos desde la máquina origen por cada uno devuelto). La conexión es fallida porque los ordenadores tienen desactivada esta función.
A continuación podemos ver el intento de conexión en el Monitor de Red junto con el proceso hecho en MS-DOS:

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?
Hemos utilizado el fichero RFC1191.txt
Se negocia una MSS de 460 bytes (primero 1460 y luego 460).
El tamaño de los segmentos TCP es 480 bytes (460 de datos y 20 de cabecera TCP).
La diferencia básica es que, en este caso, los segmentos TCP contendrán menos datos.

Cuestión 3

Utiliza el programa rexec para ejecutar el comando 'cat capturaexamen' 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 (de hecho, podemos ver el byte Don't Fragment activado). No se fragmenta porque TCP ya crea sus segmentos respetando el tamaño de la MTU de IP.
El tamaño máximo de un segmento TCP es, en este caso, 1460 bytes. Esto se puede ver cogiendo la trama de tamaño máximo y restando las distintas cabeceras o bien mirando el campo Maximum Segment Size que está en la pestaña Options del nivel TCP.
Aquí podemos ver una captura del proceso realizado:

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

Emplea el programa rexec para ejecutar el comando 'ls -l' en la máquina 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 autentifiar al cliente, algo que no permite el PC).

La estructura de envío de datos - confirmación de datos es similar a la detallada en el guión de prácticas.
A continuación podemos ver la captura de tramas realizada por el Monitor de Red con la que hemos comprobado esto:

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

El valor de los puertos que se utilizan es:

1. Nuestra máquina: 1102
   
2. Servidor: 512

Cabe destacar que, durante una parte de la conexión (concretamente durante la autentificación), el valor de los puertos es el siguiente:

1. Nuestra máquina: 113
   
2. Servidor: 2090

Esto último ocurre porque, para realizar la operación comentada, se requieren una serie de puertos que aseguren mayor seguridad que los anteriores.

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

Los tamaños que encontramos en las diferentes tramas son, o bien 65535 bytes o bien 5840 bytes. El más grande de los que encontramos es el de 65535 bytes, que además coincide con el máximo posible ya que este campo tiene reservados 2 bytes de tamaño, lo que establece 65536 valores posibles que se mueven en el rango de [0,65535].

Cuestión 1

Udp.exe. Este sencillo programa para MS Windows nos permitirá enviar 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.

Apartado 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)
Antes de nada destacar que nuestro datagrama UDP ha sido mandado al puerto 7.
El filtro utilizado ha sido ip.addr == 10.3.7.0
Analizando la secuencia de paquetes que obtiene el monitor de red, podemos observar que sí aparece un mensaje catalogado como Request y otro como Response.

Finalmente, los puertos que se dan en la conexión son:

• Nuestra máquina: Puerto 1092
• Servidor: Puerto 7
  

Apartado b) Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2 Kbytes). 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 la 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...)
Tras realizar las operaciones propuestas en el enunciado, nuestro paquete de datos se fragmenta en 2 datagramas de ida, cuya vuelta llega en 5 paquetes. La imagen que describe esto es la que sigue:

A continuación realizaremos el estudio de los paquetes:

• Ida

El primer paquete (el catalogado como ECHO Request) tiene 1514 bytes a nivel de Ethernet, por lo que, sabiendo que la cabecera de Ethernet son 14 bytes y que la del nivel IP son 20 bytes, a nivel de transporte tendremos 1480 bytes, de los cuales 1472 son de datos y los 8 restantes son de cabecera UDP.
El segundo paquete tiene 597 bytes, de los cuales, con los datos antes comentados, sabemos que 577 bytes son de nivel de transporte (todos serán datos ya que la cabecera UDP va en la anterior trama por el hecho de que la fragmentación en este caso está permitida y se realiza a nivel IP).
Por tanto, los datos mandados con el programa udp.exe serán 1472+577=2049 bytes.
Por último, la bandera de "no fragmentación" está desactivada, por lo que sí que se puede dividir el datagrama UDP a nivel IP.

• Vuelta
  

El primero de los datagramas, catalogado como ECHO Response, tiene una longitud de trama de 514 bytes, por lo que, quitando las cabeceras del nivel de Ethernet y de IP, nos quedamos con 480 bytes a nivel de transporte (472 de datos y 8 de cabecera).
Los 3 datagramas siguientes tienen 514 bytes sobre el nivel de Ethernet, que eliminando las cabeceras, se quedan en 480 bytes de datos a nivel de transporte.
El quinto datagrama tiene 171 bytes sobre nivel de Ethernet, que en definitiva son 137 bytes de datos a nivel de transporte.
La cantidad de datos, sumando las distintas cantidades de datos de las diferentes tramas, son 472+480+480+480+137=2049 bytes.
En este caso, el bit 'Don't Fragment' tampoco está activado, permitiendo entonces la división de los segmentos a nivel IP.

¿De qué va la Práctica 3?

En esta tercera práctica de la asignatura se va a estudiar con profundidad el nivel de transporte del protocolo TCP/IP, siendo nuestro principal objetivo el comprender la diferencia entre los dos protocolos principales de este nivel de red: el TCP, cuyas siglas significan Transmission Control Protocol (en castellano, Protocolo de Control de Transmisión), y el UDP, que es el acrónimo de User Datagram Protocol (cuya traducción es Protocolo de Datagramas de Usuario.

Cuestión Tracert. Rutas de los paquetes en la red

En este ejercicio se pretende que el alumno descubra la ruta que siguen los paquetes que desde un nodo origen a un nodo destino con la información por la herramienta de trazado de rutas. Debido a las limitaciones que posee el comando tracert o traceroute desde la ubicación del laboratorio, vamos a hacer uso de servidores de rutas externos, desde los que calcularemos la ruta a nuestra máquina o a cualquier otro nodo mundial. Accede a la web http://tracert.com/trace_exe.html. Desde este sitio podemos lanzar la petición de traza de rutas desde diferentes servidores de la red.

• Realiza una petición de traza desde Autralia (red de Telstra.net) hacia la dirección www.ua.es. ¿Qué ciudades recorren los paquetes hasta que llegan a la Universidad de Alicante? ¿Cuántos routers son atravesados por paquetes (aproximadamente)?

Las ciudades que recorre el paquete son: Melbourne - Sydney - Hong Kong - Dos routers en Estados Unidos que no podemos localizar correctamente - Miami - Madrid - Valencia - Alicante.
Más o menos, los routers atravesados (fijándonos en los saltos que hay al ejecutar la aplicación) son 15.
Aquí vemos el recorrido proporcionado por la web:

• Realiza una petición de traza desde Rusia hasta la web de www.sony.com. Indica la ubicación de los routers por los que pasan los paquetes hasta que llegan al servidor web. Para traducir las abreviaturas por los nombres de ciudades o aeropuertos ayúdate de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3. Dibuja en el mapa de la Figura 11 el camino de los paquetes.

La ubicación de los routers es la siguiente: Rusia (una ciudad no concretada) - Moscú - Frankfurt - Ámsterdam - Nueva York - San José - Los Ángeles.
La traza realizada por el programa es la que sigue:
El mapa de la ruta es:

• Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierto Federal de Argentina www.argentina.gov.ar desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino? Compara los resultados si accedes desde París (Eu.org) al diario www.clarin.com. Dibuja los caminos.

Para el caso París - Gobierno Federal de Argentina:
La ruta que hemos obtenido es París - Galicia - Argentina
El resultado del programa es el que sigue:El mapa de la ruta es:


Para el caso París - Diario Clarín
La ruta seguida es: París - Estados Unidos (algún lugar indeterminado) - Los Ángeles - Buenos Aires
El resultado del programa es el que sigue:
El mapa de la ruta es:

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

Apartado a) Finaliza la captura e indica qué máquina 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)
La máquina es la puerta de enlace predeterminada (Cisco 1720), según podemos ver en la captura de pantalla.
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

Apartado b) Finaliza la captura y determina qué máquina envía ahora el mensaje "ICMP Time to Live exceeded 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)
Ahora el mensaje lo envía la máquina Cisco 2513.
IP --> 10.4.2.5
MAC --> 00:07:0e:8c:8c:ff
Ambas direcciones no pertenecen a la misma máquina. La IP es la del Cisco 2513 y la MAC es la de la puerta de enlace predeterminada.

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

Apartado 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
Lo que ocurre es que, en el trayecto hacia el destino, el TTL del datagrama llega a 0 y, por tanto, la trama se destruye. En realidad lo que pasa es que esa máquina destino no existe y el paquete va saltanto entre routers (en este caso, los Linux) buscándola hasta que muere.
La subred sería la que está ubicada entre el Linux 1 y el Linux 2.

Apartado 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)?
No. Tarda más en el caso en que el ping tiene un TTL de 160 saltos.

Cuestión 4. Mensaje ICMP "Redirect"

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

c:\>route delete 10.4.2.1

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:
Apartado a) ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos... (tipo, código y tamaño)

Datagrama número	Tipo ICMP	Código ICMP	Tamaño del paquete ICMP	Origen IP	Destino IP
1	Tipo 8	Código 0	32 bytes de datos (74 del paquete total	172.20.43.218	10.4.2.1
2	Tipo 5	Código 1	28 bytes de datos (70 del paquete total	172.20.43.230	172.20.42.218
3	Tipo 0	Código 0	32 bytes de datos (74 del paquete total	10.4.2.1	172.20.43.218

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



Apartado 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. Aparecen todos excepto el que se envía de router a router. Esto sucede porque en la red de este laboratorio hay un switch cuya tarea, además de unir los diferentes elementos de red, es la de filtrar pr MAC, con lo cual no podemos ver ese datagrama.

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

Datagrama número	Tipo ICMP	Código ICMP	Origen Mac	Origen IP	¿Representan al mismo interfaz?
1	Tipo 8	Código 0	00:0a:5e:76:8c:4c	172.20.43.218	Sí
2	Tipo 5	Código 1	00:07:0e:8c:8c:ff	172.20.43.230	Sí
3	Tipo 0	Código 0	00:d0:ba:e0:6a:3d	10.4.2.1	No

Para saber si las IP estaban asociadas a las MAC hemos utilizado tanto el comando ipconfig como el comando arp -a y así poder hacer las asociaciones. A continuación vemos las imágenes obtenidas:


Apartado e) ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?
El Cisco 1720, es decir, la puerta de enlace predeterminada.

Apartado 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 la puerta de enlace alternativa, es decir, al dirección óptima a la que deberá mandar el paquete nuestro PC siempre que quiera ir a ese destino.
También transporta parte de los datos que se enviaron en el paquete original para que el PC sepa qué mensaje provocó el error y porqué

Apartado 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	Checksum
Original	0x0603 (1539)	128	0x50cb
Redirect	0x0603 (1539)	127	0x51cb

Como podemos observar, el campo TTL disminuye una unidad por el salto del router que hay en la red.
El campo Checksum (Header Checksum concretamente) cambia en un único número, lo que es lógico debido a que, de toda la cabecera anterior, únicamente cambia un valor del TTL.

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

¿Por qué 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

En base a los paquetes capturados, indicar:
Apartado 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)
Comenzamos por las IPs:
172.20.43.218 --> Es nuestra propia IP
10.3.7.0 --> Es la IP de la máquina destino. Corresponde a la máquina Linux 1.
10.4.2.5 --> Es una de las IPs del router Cisco 2513.

En cuanto a las direcciones MAC, tenemos las siguientes:
00:0A:5E:76:8C:4C --> Es la dirección MAC de nuestro ordenador.
00:07:0E:8C:8C:FF --> Es la dirección MAC del router Cisco 1720.

Apartado 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)
El mensaje ICMP lo envía la máquina cuya IP es 10.4.2.5.
Esta IP es, de acuerdo con la topología del laboratorio adjunta en la memoria, con uno de los puertos del router Cisco 2513.

Cuestión 2. Sobre la fragmentación de datagramas IP

Empleando el Monitor de Red de la misma forma que en la situación anterior, ejecutar:

c:\>ping -n 1 -l 2000 172.20.43.203

Apartado 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?
El filtro utilizado ha sido ip.dst==172.20.43.218 || ip.src==172.20.43.218
Hay dos fragmentos de ida (request) y dos fragmentos de vuelta (reply). Uno tiene longitud 1514 bytes (1472 bytes de datos en el protocolo ICMP) y el otro 562 bytes (528 bytes de datos en el protocolo ICMP).
El fragmento de mayor tamaño, tanto de request como de reply, aparece identificado como ICMP mientras que el de menor tamaño, tanto de request como de reply, aparece como IP.
Apartado b) ¿En cuántos fragmentos se ha "dividido" el datagrama original?
El datagrama original se ha dividido en dos datagramas diferentes ya que hemos mandado 2008 bytes (2000 bytes de datos ICMP + 8 bytes de cabecera ICMP).

Apartado 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 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 nº	Protocolo	Dirección	Flags	Fragment Offset	Identificación
1	ICMP	Petición	0x02	0	0x028b (651)
2	IP	Petición	0x00	1480	0x028b (651)
3	ICMP	Respuesta	0x02	0	0x028b (651)
4	IP	Respuesta	0x00	1480	0x028b(651)

Apartado 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?
Únicamente se visualiza el primer fragmento de cada paquete (del de ida y del de vuelta). Sucede que el primer fragmento se cataloga como ICMP porque el programa examina el contenido de la trama y, al encontrar la cabecera dentro del datagrama IP, establece que eso es un paquete ICMP.


Apartado e) ¿Para qué se pueden emplear los campos "Identificación", "Flags" y "Fragment Offset" de los datagramas IP?
Identificación --> Para marcar de forma única cada datagrama enviado.
Flags --> Informa sobre si se han acabado los paquetes o quedan más por venir.
Fragment Offset --> Sirve para saber dónde va cada paquete.

Apartado f) En función de los datos anteriores, indica el valor de la MTU de la red.
Para averiguar el valor de la MTU miramos el primero de los fragmentos en los que se ha dividido el paquete enviado con el ping por el hecho de ser el que se llena al máximo. Esta trama tiene una longitud de 1514 bytes, por lo que si eliminamos los 14 bytes pertenecientes a la cabecera del nivel Host-Red, obtenemos que la MTU a nivel IP es 1500 bytes.

Apartado g) Repite el ejercicio lanzando 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 nº	Protocolo	Dirección	Flags	Fragment Offset	Identificación
1	ICMP	Petición	0x02	0	0x123b (4667)
2	IP	Petición	0x02	1480	0x123b (4667)
3	IP	Petición	0x00	2960	0x123b (4667)
4	ICMP	Respuesta	0x02	0	0x1b05 (6917)
5	IP	Respuesta	0x02	1480	0x1b05 (6917)
6	IP	Respuesta	0x00	2960	0x1b05 (6917)

En la siguiente imagen podemos ver esas tramas en el monitor de red:

Apartado 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 nº	Protocolo	Dirección	Flags	Fragment Offset	Identificación
1	ICMP	Petición	0x02	0	0x1292 (4754)
2	IP	Petición	0x00	1480	0x1292 (4754)
3	ICMP	Respuesta	0x02	0	0x0096 (156)
4	IP	Respuesta	0x02	480	0x0096 (156)
5	IP	Respuesta	0x02	960	0x0096 (156)
6	IP	Respuesta	0x00	1440	0x0096 (156)

En la siguiente imagen podemos ver esas tramas en el monitor de red:

Apartado 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 en una de las redes intermedias se separan las tramas en varios fragmentos debido a que la MTU en uno de esos segmentos es menor que en el origen.

Indica en qué 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 qué otra subred no sucede esto.
El número de fragmentos tanto en petición como respuesta sólo es el mismo en el tramo que va desde el Cisco 2513 hasta el Linux 1 ya que es que el tiene la MTU más pequeña de toda la ruta que ha de atravesar el paquete hasta llegar a su destino y, por tanto, es que establece el número de fragmentos en los que quedará dividido el paquete original. Esto no sucede ni en la red que va del laboratorio al Cisco 1720 y la que va de éste al Cisco 2513 porque a la ida tendrán únicamente dos fragmentos (el paquete original, al ser de gran tamaño, se ha de fragmentar una vez) pero en la respuesta tendrán cuatro fragmentos ya que, aunque puedan tener tramas de mayor tamaño, el protocolo establece que si los paquetes llegan fragmentados (y en este caso lo harán por la MTU que hay del Cisco 2513 al Linux 1) no han de ser unidos.

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?
Según el esquema adjunto a la memoria, se atraviesan 3 subredes. En rojo, además, se detallan las MTU de las subredes que se atraviesan.

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

Detener la captura en el Monitor de Red (filtrar únicamente tramas del alumno) y visualizar los paquetes capturados.
Para poder ver únicamente los mensajes pertenencientes a nuestra máquina hemos utilizado el filtro siguiente:
ip.dst==172.20.43.218 || ip.src==172.20.43.218
Cabe destacar que también, como únicamente queremos ver los mensajes ICMP que hay en la red, también podríamos haber utilizado directamente este filtro:
icmp

En base a los paquetes determinar:
Apartado a) ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)
Aparecen 3 (dos de REQUEST y uno de REPLY) mensajes ICMP, aunque en realidad sólo deberían aparecer 2: uno de tipo REQUEST y otro de tipo REPLY. Esto ocurre porque el monitor duplica, al mostrarlo por pantalla, el mensaje REQUEST, pero por la red únicamente hay uno de cada, ya que por cada llamada siempre hay una respuesta.

Los tipos y códigos de los mensajes son los que siguen:

Mensaje	Tipo	Código
Echo_request	8	0
Echo_reply	0	0

Apartado 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?
En este caso sí que son la misma debido a que estamos mandando la petición a la puerta de enlace de la red (es decir, al router que nos da salida a otra red desde la del laboratorio) y, como estamos moviéndonos en una red local, la IP sí que tiene una correspondecia directa con la MAC. Si nos moviéramos fuera de esta red la dirección MAC no haría referencia a la IP de la máquina de destino ya que tendríamos la MAC de la puerta de enlace (por lo del protocolo ARP) y la IP del destino, fuera el que fuera.

Apartado 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.
El tamaño total que obtenemos en una trama catalogada como ICMP es 74 bytes, de acuerdo con lo que nos muestra el Monitor de Red.
Como podemos observar, si nos vamos al apartado de Internet Control Message Protocol (ICMP), podemos observar que como datos tiene 32 bytes y que, con la suma de su propia cabecera (siempre son 8 bytes, aunque se puede comprobar con el Wireshark) tenemos 40 bytes de tamaño total de trama ICMP.
Cabe destacar que los datos de ICMP tienen esa longitud porque este mensaje se ha producido por el comando ping, el cual, como no le hemos especificado la cantidad de datos que queríamos que mandara (simplemente hemos especificado que mandara 1 único paquete), él por defecto manda paquetes de 32 bytes, que son los datos del susodicho protocolo.
Finalmente, para comprender mejor este concepto, adjuntamos el siguiente dibujo que muestra la encapsulación del protocolo ICMP, que se encuentra en el Nivel de Internet de TCP/IP, hasta el nivel físico (Nivel de Host-Red en TCP/IP):

¿De qué va la Práctica 2?

Con la segunda práctica de la asignatura vamos a tratar el llamado Protocolo de Mensajes de Control de Internet (ICMP). Este protocolo tiene como finalidad comunicar los mensajes de error que ocurren en la transmisión de datos por medio de una red.
En esta práctica se realizarán seis ejercicios, que a continuación se describen:

• Con el primer ejercicio nos familiarizaremos con el funcionamiento de este protocolo y con la encapsulación del mismo.
• El segundo ejercicio pretende introducirnos en la fragmentación que realiza el protocolo IP (nivel de Internet) por medio del ICMP.
• En el ejercicio tres forzaremos una situación de error de destino inalcanzable (un error que ocurre cuando la máquina a la que queremos llegar no está operativa) y comprobar el funcionamiento de ICMP en este caso.
• Con el cuarto ejercicio vamos a intentar forzar una situación de redirección, es decir, intentar no ir por una ruta óptima a un destino para ver cómo reacciona ICMP.
• En el quinto ejercicio vamos a provocar una situación en la que un paquete de datos "muera" por la red (su tiempo de vida llegue a cero) para comprobar la reacción de ICMP.
• Por último realizaremos un ejercicio en el que podremos ver la ruta física (ciudades, países e incluso continentes) que sigue un paquete de información desde el origen (nuestra máquina, por ejemplo) hasta su destino.
  

Cuestión 4. Sobre TCP/IP

Apartado a) Sea la dirección de red 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 las máquinas en cada una de las subredes obtenidas en la ampliación.
La máscara de red inicial es 255.255.254.0 (11111111.11111111.11111110.00000000) por lo que si cogemos dos bits más quedará la máscara 255.255.255.128 (11111111.11111111.11111111.10000000). Las diferentes subredes que podremos crear y los respectivos rangos de IPs de máquinas que podremos utilizar serán:

Dirección de subred	Dirección IP primera máquina	Dirección IP última máquina
125.145.64.0	125.145.64.1	125.145.64.127
125.145.64.128	125.145.64.129	125.145.64.254
125.145.65.0	125.145.65.1	125.145.65.127
125.145.65.128	125.145.65.129	125.145.65.254

Cabe destacar que de cada rango de IPs posibles que puede tener una máquina se descartan siempre 2:

• La dirección cuyo octeto final (el primero por la derecha) tenga valor 0 (en decimal) ó 00000000 (en binario) por ser el valor que coincide (y pertenece) a la dirección de subred.
• La dirección cuyo octeto final (el primero por la derecha) tenga valor 255 (en decimal) ó 11111111 (en binario) por ser la dirección de difusión de la subred.
  

Apartado b) Analizar al azar datagramas IP capturados con el monitor de red.

• De los datagramas visualizados, indica cuál es su longitud.

El datagrama escogido, de acuerdo con el campo LONGITUD TOTAL, tiene una longitud de 1443 bytes.

• ¿Qué aparece en el campo de Protocolo de cada datagrama?

Aparece TCP. Este campo nos dice el protocolo al que ha de llegar la información. En este caso, esta trama va dirigida al nivel de transporte del protocolo TCP/IP de la máquina de destino.

• Indica la CLASE de dirección asociada a cada dirección IP fuente o destino.

Como podemos ver, las IPs son:

• IP Origen: 10.8.1.2 --> IP de Clase A
  
• IP Destino: 172.20.43.217 --> IP de Clase B

Apartado c) Empleando el monitor de red, averigua las direcciones IP de los siguientes servidores web:

• http://www.infocampus.es

Para comprobar el resultado hemos realizado un ping a http://www.infocampus.es porque este programa nos devuelve la IP asociada:
La IP, como podemos observar, es 82.194.85.170. Este tipo de dirección lógica es de Clase A.

• http://www.ono.es

Realizando el mismo proceso que en el apartado anterior llegamos a que la IP de esta dirección es 62.42.230.18 y que es de Clase A.

• http://www.ua.es

Finalmente, esta IP no se pudo conseguir de la forma habitual debido a que la conexión hacia el servidor de esta web la realizaba de forma interna por unos ajustes que se habían realizado en el ordenador.
La IP que debería dar (a cualquier persona desde fuera de la Universidad de Alicante) es 193.145.233.8 y esta dirección es de Clase C.