Practica 3 - Anexo

Anexo

En una ventana de MS-DOS y dentro del directorio raíz empleamos el programa ftp para enviar el fichero C:\p3.txt al servidor 172.20.41.241.

Ejecutamos el comando:
route add 172.20.41.241 mask 255.255.255.255 172.20.43.231

A continuación el resto de comandos:





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.

En el primer extremo el valor de MSS es 1460 bytes mientras que en el segundo es de 460. Por tanto en la conexión TCP se negocia el valor de 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í, uno. La máquina que envía este mensaje es la 172.20.43.231.

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?

Se cambia la MSS de 460 bytes a 360 bytes que es el nuevo valor de la MTU (400) de la sigiente red.

d) ¿Reenvía tu PC algún paquete TCP al servidor?

Reenvía tres paquetes de datos para que se vuelvan a reenviar los paquetes enviados con el anterior valor de MSS.

e) ¿Fragmenta IP algún paquete TCP?

No porque el protocolo TCP tiene activado el bit Don't Fragment.

Practica 3 - Apartado 7

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

Tendremos un mensaje ICMP “Fragmentation Needed”, de tipo 3 y código 4

b. Indica la MTU del camino de camino completo.

La MTU del camino es 500, la menor

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.

Se fragmentará en 4 paquetes:

El primero, el segundo y el tercero tendrá una cabecera de ethernet de14 bytes, una cabecera Ip de 20 bytes,TCP de 20 bytes, más 460 de datos.
El cuarto tendrá una cabecera de ethernet de14 bytes, cabeceras Ip de 20 bytes, TCP de 20 bytes, más 120 de datos.

Practica 3 - Apartado 6

Cuestion 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:
Se fragmentará en 3 paquetes.
El primero tendrá una cabecera Ip de 20 bytes,UDP de 8 bytes, más 472 datos
El segundo y el tercero tendrá cabeceras Ip de 20 bytes, más 480 de datos.
Y el tercero tendrá cabeceras Ip de 20 bytes, más 48 de datos.

TCP:
Se fragmentará en 3 paquetes.
El primero y el segundo tendrá una cabecera Ip de 20 bytes,TCP de 20 bytes, más 460 datos
El tercero tendrá cabeceras Ip de 20 bytes, TCP de 20 bytes, más 80 datos.

Practica 3 - Apartado 5

Cuestion 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 observa como se intenta establecer una sincronía entre ambas maquinas y se observa como la maquina destino, produce un RST, como se observa en la captura esta situación se da tres veces, después de esta tercera vez, se realiza la desconexión ya que no se ha podido establecer una sincronía entre ambas maquinas.

Practica 3 - Apartado 4

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



Los valores de MSS que se negocian son en petición 1460 y en respuesta 460. El tamaño de los fragmentos TCP será por tanto 480(460 + cabecera). La diferencia respecto al apartado anterior es que en este caso la MTU de esta red es menor.

Practica 3 - Apartado 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?



No, IP no ha fragmentado esos fragmentos porque los fragmentos TCP llevan el bit "don't fragment" activado. El tamaño de los paquetes es:

MMS = MTU – Cab IP – Cab TCP = 1500 – 20 – 20 = 1460 Bytes.

Practica 3 - Apartado 2

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

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

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

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

Puerto 7:



Puerto 13:



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

Practica 2 - Cuestion Tracert

Rutas de los paquetes en la red

En este ejercicio se pretende que el alumno descubra la ruta que siguen los paquetes desde un nodo origen a un nodo destino con la información proporcionada 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 Australia (red Telstra.net) hacia la dirección http://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 atraviesan los paquetes son: Melbourne, Sydney, Hong Kong, Maine, alguna ciudad del centro de los EEUU, Hollywood (Florida), Madrid, Valencia y Alicante.

- Realiza una petición de traza desde Rusia hasta la web de http://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 ruta que siguen los paquetes es la siguiente: Novosibirsk, Moscú, Frankfurt, Amsterdam, Nueva York, Chicago, San Jose, Los Angeles, San Diego.

- Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina http://www.argentina.gov.ar/ desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino?

Las ciudades por las que pasa son: Paris, Galicia y Buenos Aires.

Compara los resultados si accedes desde Paris (Eu.org) al diario http://www.clarin.com/. Dibuja los caminos.

Las ciudades por las que pasa son: Paris, Washington, Atlanta, Miami y Buenos Aires.

Practica 2 - Apartado 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)

C:\>ping -i 1 -n 1 10.3.7.0

Como podemos ver, la máquina que nos envía el mensaje tiene dirección IP 172.20.43.230 y MAC 00 07 0e 8C 8C FF, que corresponde si lo consultamos en la tipología del anexo al 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)

En este caso la dirección IP origen del error es 10.4.2.5 correspondiente al serial 1 del router Cisco 2513 y la MAC 00 07 0e 8c 8c FF que corresponde al router anterior (Cisco 1720).

Como vemos no corresponden a la misma máquina.

Lo que sucede es que al expresar un tiempo de vida de 2 saltos en el ping (-i 2), el datagrama atraviesa el primer router y el segundo router devuelve el mensaje de error con su IP.

La MAC siempre es la indicada por el router más proximo a tu máquina que expresa la tipología de tu red, esto explica este fenómeno de no concordancia.

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?

El tipo asociado es 11 (Time to live exceed) y código 0 (Time to live exceed in transit).

Lo que sucede es que se está produciendo un bucle entre las máquinas 10.3.2.0 y 10.3.7.0 hasta que agotan el TTL y nos envía el router éste mensaje de error.

Estaría ubicada en la subred 10.3.0.0 situada entre esas máquinas.

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

C:\>ping -i 220 -n 1 10.3.7.12

Haciendo ping a 10.3.7.12 con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.
Estadísticas de ping para 10.3.7.12:
Paquetes: enviados = 1, recibidos = 0, perdidos = 1 (100% perdidos),

En este caso sucede lo mismo que en el anterior solo que tarda más en aparecer el mensaje de error al hacer el ping con una TTL mayor.

Practica 2 - Apartado 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	8 – 0 (echo request)	60 bytes	172.20.43.211	10.4.2.1
2	5 – 1 (redirect)	60 bytes	172.20.43.230	172.20.43.211
3	0 – 0 (echo reply)	60 bytes	10.4.2.1	172.20.43.211

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

Como se puede observar en la imagen de debajo, mi máquina envía por la puerta de enlace predeterminada (172.20.43.230) la petición de echo, después el router envía la misma petición al otro router (Cisco 1601) y un mensaje de error de direccionamiento hacia mi máquina que corregirá el error para la próxima vez. Finalmente el router Cisco 1601 devuelve la petición de echo hacia mi máquina.

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

El datagrama que no observo en mi máquina es la copia de la petición de echo que envía un router a otro. Esto sucede porque el switch direcciona los datagramas entre routers para que mi máquina no los vea.

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	8 – 1 (echo request)	00:0A:5E:76:FF:BC	172.20.43.211	SI
2	5 – 1 (redirect)	00:07:0E:8C:8C:FF	172.20.43.230	SI
3	0 – 0 (echo reply)	00:07:0E:8C:8C:FF	10.4.2.1	NO

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

La puerta de enlace predeterminada de mi máquina (router Cisco 1720).

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 un bloque que contiene la “dirección ip del nuevo router”, que es la dirección de salida correcta que debe tomar nuestra máquina para una situación igual en el futuro.

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?

Los campos que varían son el TTL (de 128 en el echo request a 127 en el redirect) y el Cheksum.

Practica 2 - Apartado 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)

La dirección IP y MAC de la petición de echo corresponde a mi máquina (172.20.43.211 - 00-0A-5E-76-ff-bc). En cambio la dirección IP de respuesta es la de la máquina a la cual enviamos el ping (10.3.7.0 – Linux 1) y la MAC es la correspondiente a nuestra puerta de enlace (00:07:0e:8c:8c:ff – Router Cisco 1720).

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)

Se trata del Router Cisco 2513.

Practica 2 - Apartado 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?

Tenemos dos paquetes ICMP correspondientes a la petición (echo request) y a la respuesta (echo reply) respectivamente. Y otros dos con protocolo IP identificados como fragmented ip protocol, que corresponden a la petición y respuesta de ICMP realizada.

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

Como indicamos anteriormente, se ha divido cada datagrama original en dos fragmentos. El primero de 1514 bytes y el segundo de 512 bytes.

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 nº	Protocolo	Dirección	Flags	Frag. offset	Identificación
1	ICMP	172.20.43.230 (petición)	0×02 (more fragments)	0	0xc75a (51034)
2	IP	172.20.43.230 (petición)	0×00	1480	0xc75a (51034)
3	ICMP	172.20.43.200 (respuesta)	0×02(more fragments)	0	0×0036 (54)
4	IP	172.20.43.200 (respuesta)	0×00	1480	0×0036 (54)

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?

Introduciendo “icmp” en el campo filter solo visualizamos los dos paquetes correspondientes al primer fragmento de la petición y de la respuesta respectivamente.

Esto es debido a que estos primeros fragmentos son los que poseen la cabecera ICMP. Como los siguientes fragmentos no la poseen nos aparecen como protocolo IP.

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

El campo “Identificación” indica cada fragmento al datagrama que le corresponde, el campo “Flags” nos indica el número de fragmentos que nos faltan para completar el datagrama y la posición en la que se encuentra el mismo.

Por último, el campo “Fragment ofsset” identifica en el reensamblado la posición donde debe colocar ese fragmento para recomponer el datagrama original.

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 es 1500 bytes. Es el valor del tamaño máximo de los datagramas que circulan en la red y con el que fragmenta los mismos.

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 nº	Protocolo	Dirección	Flags	Frag. offset	Identificación
1	ICMP	172.20.43.195 (petición)	0×02 (more fragments)	0	0×0344 (830)
2	IP	172.20.43.195 (petición)	0×02(more fragments)	1480	0×0344 (830)
3	IP	172.20.43.195 (petición)	0×00	2960	0×0344 (830)
4	ICMP	172.20.43.200 (respuesta)	0×02(more fragments)	0	0×0092 (146)
5	IP	172.20.43.200 (respuesta)	0×02(more fragments)	1480	0×0092 (146)
6	IP	172.20.43.200 (respuesta)	0×00	2960	0×0092 (146)

La diferencia radica en que al enviar en este caso un paquete de 3000 bytes (más las cabeceras) hay que fragmentar el datagrama en 3 partes en vez de dos.

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)

Datagrama nº	Protocolo	Dirección	Flags	Frag. offset	Identificación
1	ICMP	10.3.7.0 (petición)	0×02 (more fragments)	0	0xb37b (45947)
2	IP	10.3.7.0 (petición)	0×00	1480	0xb37b (45947)
3	ICMP	172.20.43.200 (respuesta)	0×02(more fragments)	0	0×00a1 (161)
4	IP	172.20.43.200 (respuesta)	0×02(more fragments)	480	0×00a1 (161)
5	IP	172.20.43.200 (respuesta)	0×02(more fragments)	960	0×00a1 (161)
6	IP	172.20.43.200 (respuesta)	0×00	1440	0×00a1 (161)

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?

Observamos más fragmentos IP de vuelta que de ida debido a que la red que nos manda la respuesta ICMP posee un MTU menor que desde la que enviamos la petición, por tanto nuestro datagrama enviado vuelve más fragmentado.

Como vemos en la siguiente imagen, en las dos primeras redes que atravesamos (línea verde) tenemos un MTU de 1500 por tanto en ese tramo el número de fragmentos de ida y de vuelta es el mismo para la petición y para la respuesta. Pero en la última red que atravesamos (linux1) al poseer un MTU de 500 bytes poseeremos más fragmentos a la vuelta que a la ida, que es lo que nos ocurre en el ping hecho en el último apartado.

Se puede decir entonces que el MTU de la red es 500 bytes (el más pequeño de todos es el que condiciona los demás).

Practica 2 - Apartado 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)

Al hacer este ping estamos enviando al router Cisco 1720 un paquete ICMP.

Los paquetes capturados son dos. Petición de echo (echo request – Tipo 8 Código 0) que corresponde al ping y respuesta de echo (echo reply – Tipo 0 Código 0) que corresponde a la respuesta de nuestro ping.

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?

Las direcciones IP y MAC origen del mensaje de respuesta echo reply corresponden a la misma máquina, el router Cisco 1720 al que le enviamos el ping ( con IP 172.20.43.230 y MAC 00:07:0E:8C:8C:FF).

Esta coincidencia es debida a que le hemos enviado el ping a una máquina de nuestra propia red. En el caso de mandar un ping hacia fuera la MAC no coincidiría con la IP de respuesta ya que la siempre viene indicada por nuestra puerta de enlace.

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.

La longitud de los paquetes IP enviados es de 60 bytes de los cuales corresponden 20 a la cabecera IP, 8 a la cabecera ICMP y 32 a los datos del ping.

Practica 1- Apartado 4

Cuestión 4. Sobre TCP/IP

4.a 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.

Direccion de red 01111101.10010001.01000000.0000000 (125.145.64.0)

Máscara 11111111.11111111.11111110.0000000 (255.255.254.0)

Nueva máscara de subred (añadiéndole 2 bits)

11111111.1111111.11111111.10000000 (255.255.255.128)

Vemos ahora las 4 posibles subredes que se forman (en negrita los bits que varían)

1ª subred 01111101.10010001.01000000.00000000 (125.145.64.0)

2ª subred 01111101.10010001.01000000.10000000 (125.145.64.128)

3ª subred 01111101.10010001.01000001.00000000 (125.145.65.0)

4ª subred 01111101.10010001.01000001.10000000 (125.145.65.128)

Expresamos a continuación una tabla con el rango de direcciones IP de las máquinas de cada subred:

Subred	1ª máquina	2ª 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

4.b Analizar al azar varios datagramas IP capturados con el monitor de red.

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

Analizamos distintos datagramas al azar podemos observar la longitud de la cabecera y su tamaño total

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

HTTP

4.c Empleando el monitor de red, averigua las direcciones IP de los siguientes servidores web: (indica a que CLASE de dirección pertenecen).
http://www.infocampus.es

82.194.85.170 ->Clase A

http://www.ono.es

62.42.230.18 –>Clase A

http://www.ua.es

193.145.233.8 –>Clase C

Práctica 1 - Apartado 3

3.a Visualiza la dirección MAC e IP de la máquina de ensayos, ejecutando el siguiente comando en una ventana de MSDOS:

ipconfig /all

Anota los valores que obtienes para saber “quien eres“ en la red local.

Nuestra dirección IP es 172.20.43.214 y nuestra dirección MAC 00-0A-5E-76-FE-4B

A continuación, activa la captura de tramas en el programa monitor de red.

En la máquina del alumno se lanzarán peticiones ‘echo’ a través del programa ping a la dirección IP 172.20.43.230, borrando previamente de la tabla ARP local la entrada asociada a esa dirección IP:

arp –a (Visualiza la tabla ARP)

arp –d (Borra una dirección IP en la tabla ARP)

ping 172.20.43.230 (Muestra la conectividad de la máquina 172.20.43.230)

En el monitor de red detener la captura y visualizarla. Introducir un filtro para visualizar sólo tramas ARP asociadas SÓLO a la máquina del alumno

¿Cuántas tramas intervienen en la resolución ARP?

Para visualizar estas tramas introducimos el filtro à Arp && eth.addr == 00-0A-5E-77-04-3A donde la dirección MAC la obtenemos con el comando ipconfig/all.

Vemos que tenemos solamente 2 tramas ARP asociadas a mi máquina ya que una de elals está duplicada.

¿Cuál es el estado de la memoria caché de ARP cuando se ejecuta el protocolo ARP?



Sin que haya transcurrido mucho tiempo, vuelve a ejecutar el comando ping en la misma máquina y observa la secuencia de tramas ARP. ¿Aparecen las mismas tramas ARP?

En este caso no aparecen tramas ARP, ya que al encontrarse la dirección MAC en memoria cache no es necesario iniciar el protocolo.

3.b Ejecuta el comando ping con diferentes direcciones IP de los compañeros asistentes a prácticas. ¿Qué ocurre con la memoria caché de ARP?





En la memoria caché de ARP se van almacenando las direcciones IP y sus respectivas direcciones físicas de las máquinas a las que voy haciendo ping.

3.c. Borra el contenido de tu caché ARP. A continuación, activa el Monitor de red y pide a tus compañeros del aula más cercanos a ti que te envíen comandos ping. Tú no debes enviar ningún comando. Pasados unos segundos… ¿qué ocurre con tu cache de ARP? ¿Qué tramas de ARP aparecen en la captura del monitor de red?





Me han enviado un ping desde la direccion ip 172.20.43.213. En el monitor solo observamos la respuesta no la petición debido al filtro.

3.d Borra el contenido de tu caché ARP. Ejecutar el comando ping con las siguientes direcciones IP:

172.20.43.230

10.3.7.0

10.4.2.5

¿Qué ocurre con la memoria caché de ARP? ¿Qué diferencia existe con respecto a la cuestión ‘3.b’?

Como vemos, cuando hacemos ping, en la tabla ARP solo aparecen las direcciones IP y MAC de las maquinas internas y de la puerta de enlace (que en este caso es la misma) si hacemos ping a una dirección IP externa.

En este caso se comprueba que solo aparece la dirección IP de la puerta de enlace 172.20.43.230

3.e Describe la secuencia de tramas ARP generadas cuando la máquina 5.1.2.0 ejecuta el comando ‘ping 5.2.2.0′, teniendo en cuenta que las tablas ARP de todas las máquinas están vacías (figura 23).



Comando origen MAC origen IP destino MAC destino IP
Petición arp mac1 5.1.2.0 mac2 5.1.1.0
Respuesta arp mac2 5.1.1.0 mac1 5.1.2.0
Petición arp mac3 5.2.1.0 mac4 5.2.2.0
Respuesta arp mac4 5.2.2.0 mac3 5.2.1.0

Práctica 1 - Apartado 2

Cuestión 2. Análisis estadístico de una captura de datos

A partir de un fichero de captura de tráfico en la red se determinará cierta información que aparece en la misma. Pare ello se necesita generar tráfico para poder obtener un fichero con información capturada. En primer lugar se iniciará el monitor de red y se realizarán las siguientes acciones para generar tráfico:

Conéctate con el navegador a http://www.ua.es

Desde la ventana de MSDOS ejecuta el comando ping 172.20.43.230 que permite comprobar la conectividad en red de una máquina remota.

En la misma ventana ejecutamos ahora el comando tracert 193.145.233.8 que es muy útil para visualizar los saltos que recorren paquetes IP hasta que llegan a su destino.

Por último, introducimos la palabra “aula24” en el buscador GOOGLE.

A continuación, una vez paralizada la captura de datos, guárdala con el nombre LAB24_P2.cap.

Con la captura anterior, debes responder a las siguientes cuestiones:

2.a Calcula el porcentaje de tramas Ethernet de difusión existentes en la captura. (tramas de difusión/tramas totales *100).

Calculamos el número de tramas de difusión con el filtro

eth.addr == FF-FF-FF-FF-FF-FF

tramas totales: 495

trama de difusion: 18

%tramas de difusión Ethernet: (18/495)*100= 3,6 %

2.b Calcula el porcentaje de paquetes IP existentes en la captura.

Mediante el filtro “ip” mostramos los paquetes IP existentes en la captura: 158

%paquetes ip: (158/495)*100== 31,9%

2.c Calcula el porcentaje de paquetes IP enviados por la máquina del alumno.

Mediante el filtro ip.src mostramos los paquetes IP enviados por nuestra máquina: 123

%paquetes ip: (158/495)*100== 24,8%

2.d Indica el número de los paquetes IP que contengan la cadena “abcd” en su interior. ¿Qué aplicación ha podido generar esos datos? (Visualiza el campo “Protocol”)

Con el comando ip contains “abcd” calculamos este tipo de paquetes. En este caso no aparece ninuno

2.e Localiza los paquetes que tengan el campo de la cabecera IP “TTL” igual a 1. ¿Cuántos aparecen? ¿Qué aplicación puede haberlos generado? (Visualiza el campo “Protocol”)

Aparecen 15 paquetes con protocolo ICMP. Están generadas por la aplicación ping.

2.f Determina en cuantos paquetes aparece la cadena “aula24”. ¿A qué aplicación están asociados?

Mediante el filtro ip contains “aula24″ hallaríamos esos paquetes. En este caso 4. Están asociado a la aplicaión google.

Práctica 1 Redes de ordenadores - Apartado 1

Cuestión 1. Iniciación al monitor de red. Visualización general de protocolos en la red- Activar el monitor de red y captura todo tipo de tramas en la red durante unos segundos. Paraliza la captura y visualiza…

1.a Del conjunto de tramas adquiridas filtrar las que estén dirigidas a la máquina del alumno. ¿Cuántas tramas aparecen?

Introduciendo el filtro ip.dst==172.20.43.199 && !nbns aparecen 9 tramas.

1.b Del conjunto de tramas adquiridas filtrar las que proceden de la máquina del alumno. ¿Cuántas tramas visualizas ahora?

Introduciendo el filtro ip.src==172.20.43.199 && !nbns aparecen 30 tramas.

1.c Por último, filtra las tramas cuyo origen o destino sea la máquina del alumno. ¿Qué número de tramas se visualizan? ¿Es coherente este valor con los resultados anteriores?

Introduciendo el filtro ip.dst==172.20.43.199 ip.src==172.20.43.199 && !nbns aparecen 39 tramas. Si es coherente ya que es la suma de los resultados anteriores.