A petición del amigo Sergio

Pues eso amigos, me siento en la obligación de postear este gran video. Lo siento:

Por cierto. hemos conseguido una nota buenísima en la asignatura de redes. Gracias a todos los que habeis estado siguiendo la publicación de las prácticas. Y es que finalmente, EL RATON NOS AMA!!!!

Práctica 3. 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(Destino inaccesible)
CODIGO	4 (Se necesita fragmentación)
NUEVA MTU	500

b. Indica la MTU del camino completo.

• La MTU será la menor de las MTU del camino recorrido, segun marca la norma RFC 1191. Con anterioriodidad a la aparición de esta norma, se negociaba el tamaño de MSS entre la MTU de la red del emisor y la MTU de la red del destino lo que podría provocar errores si los datos atravesasen redes intermedias con MTU menores. Con la utilización de la norma, el emisor envia 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 este caso, tendremos una MTU=500

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.

tcp	20	20	460
tcp	20	20	460
tcp	20	20	460
tcp	20	20	120

_uacct = “UA-4563784-1″;
urchinTracker();

Práctica 3. 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.

RESULTADO TEÓRICO

UDP	20	8	472
Ip fragment	20	480
Ip fragment	20	48

RESULTADO PRÁCTICO

Como podemos ver en la imagen, el resultado práctico coincide con lo que hemos calculado. Hemos remarcado en la imagen la longitud del último de los tres paquetes, 48 bytes.

Práctica 3. 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?

• El ordenador se conecta al pc del compañero, pero no recibimos ninguna respuesta TCP del pc conectado. El servicio TCP de los ordenadores están deshabilitados. Nuestra maquina realiza tres intentos de conexión al servicio FTP con el mensaje syn, en las tres ocasiones el pc de destino responde con un mensaje de reset y la conexión se debe volver a realizar

Práctica 3. 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?

A simple vista no parece haber demasiada diferencia con respecto al caso anterior:

Pero si nos fijamos en los valores remarcados con un recuadro verde podemos ver que el valor del MSS es 460. En este caso sí que se han fragmentado los segmentos, ajustándose al tamaño de la subred que debe atravesar.

Práctica 3. 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?

• IP no fragmenta los segmentos ya que el protocolo TCP impide la fragmentación como medida de seguridad. Para asegurar el correcto funcionamiento, TCP implementa unos segmentos adecuados a la red donde esté trabajando. Calcula el MSS (máximo tamaño de segmento que corresponde a la MTU-20 bytes – 20 bytes [En nuestro caso MTU=1500----->MSS=1460])

Práctica 3. Cuestión 2c

2c/ Analiza los valores de la ventana del receptor. ¿Cuál es más grande?

• Win se utiliza para informar del número de bytes que el emisor del paquete es capaz de aceptar al recibir.Este valor depende de la porción que queda libre en su buffer de recepción. Si vale 0 indica que no se van a aceptar datos (aunque si los ACK, RST, FIN…).

win=5840

win=0

Práctica 3. Cuestión 2b

2b/ Comprueba el valor de los puertos utilizados. Indica su valor

El puerto local es variable. Comienza a partir de 1024 y a cada aplicación que utilice una conexión le asigna un número creciente. En este caso el valor es de 1367, pero si lo volvieramos a intentar cambiaría. El puerto de servidor, por el contrario, es fijo para cada función. En este caso el valor obtenido es 512 y siempre tomará este valor si repetimos el proceso.

PUERTO LOCAL	PUERTO SERVIDOR
1367	512

Practica 3. Cuestión 2a

2a/ 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).

Figura 6

Estos son los resultados que hemos obtenido:

La parte intermedia no es de fiar y es de esperar que no salga igual que lo que debería salir según la figura 6. Esto es debido a que debido a la aplicación, al navegador o incluso del antivirus o firewall que estemos utilizando, este proceso puede variar en sus pasos intermedios. En este ejemplo podemos ver incluso mensajes [RST] que reinician la conexión.

Sí podemos ver sin embargo que coincide tanto en la parte inicial como en la final. Al inicio nuestra máquina envía un [SYN] y la máquina de destino responde con un [SYN, ACK], respondiendo a su vez nuesttra máquina con un [ACK]. Para acabar la conexión podemos ver que nuestra máquina manda el [FIN] y es respondida por el destino con un [ACK].

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

Práctica 3. Cuestión 1b

1b/ 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 el envio, el mensaje UDP se ha fragmentado en dos mensajes IP FRAGMENT mas un mensaje ECHO REQUEST que contiene la cabecera UDP. Mientras que el mensaje ECHO REPLY, vuelve a nuestra maquina dividida en 6 IP FRAGMENT mas un mensaje ECHO REPLY con cabecera UDP.

• A partir de los datos podemos deducir que la MTU de nuestra subred es de 1500 bytes. Pero el tamaño mínimo de MTU en las subredes que ha atravesado nuestro mensaje es de 500 bytes.

DATAGRAMA	PROTOCOLO	DIRECCIÓN	FLAGS	OFFSET	IDENTIFY
1	ECHO	REQUEST	0×02	0	0×6a53
2	IP	REQUEST	0×02	1480	0×6a53
3	IP	REQUEST	0×00	2960	0×6a53
4	ECHO	REPLY	0×02	0	0×009c
5	IP	REPLY	0×02	480	0×009c
6	IP	REPLY	0×02	960	0×009c
7	IP	REPLY	0×02	1440	0×009c
8	IP	REPLY	0×02	1920	0×009c
9	IP	REPLY	0×02	2400	0×009c
10	IP	REPLY	0×00	2880	0×009c

Práctica 3. Cuestión 1a

1a/ 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).

ENVIO DATOS AL PUERTO 7 echo

ENVIO DATOS AL PUERTO 13 daytime

Práctica 3. Protocolos de nivel de transporte TCP/IP

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.

Segunda Práctica. – Anexo 2: Rutas de los paquetes

• Desde Australia a la Universidad de Alicante:

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

Mediante la aplicación disponible en http://tracert.com/trace_exe.html, analizamos todas las redes que atraviesa el paquete hasta llegar a su destino. Los resultados obtenidos son los siguientes:

Según la aplicación, el paquete atravesará alrededor de 26 routers por todo el mundo en su camino desde Australia hasta Alicante. Estos son los saltos geográficos que daría el paquete:

1. Partiría de Melbourne (Australia)

2. Se movería hasta Sydney (Australia)

3. Llegaría hasta Hong Kong (China)

4. Cruzaría el pacífico hasta Los Ángeles (Estados Unidos)

5. Seguiría por California en San José (Estados Unidos)

6. Iría de costa a costa hasta Nueva York (Estados Unidos)

7. Cruzaría el Atlántico hasta París (Francia)

8. Entraría en la península y llegaría a Madrid

9. Se movería hasta Valencia

10. A través de la redirirs llegaría a Alicante

En el siguiente mapamundi podemos ver esta información de manera gráfica:

• Desde Rusia a California (sede de Sony):

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.

Estas direcciones nos indican los siguientes saltos en la red mundial de los paquetes:

1. Partirían del servidor en Novosibirsk (Rusia)

2. Viajarían al oeste hasta Moscú (Rusia)

3. Atravesarían Europa hasta Londres (Reino Unido)

4. Cruzarían el océano hasta Nueva York (Estados Unidos)

5. Se moverían hasta Chicago (Estados Unidos)

6. Llegarían a la costa oeste hasta San José (Estados Unidos)

7. Alcanzarían su destino en Los Ángeles (Estados Unidos)

De modo gráfico esta sería la ruta:

Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno 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 Paris (Eu.org) al diario www.clarin.com . Dibuja los caminos.

Desde París hasta el gobierno Argentino obtenemos los siguientes resultados:

1. Salen de París (Francia)

2. Saltarían hasta Washington (Estados Unidos)

3. Volverían a Europa hasta Madrid

4. Saltarían definitivamente a Buenos Aires (Argentina)

Podemos ver que la mayor parte del camino el proveedor de red encargado de las conexiones es Telefónica, sobre todo en los saltos que se dan al llegar a España antes de ir a Argentina.

Comparemos con lo que ocurre al tratar de acceder a la web del diario argentino clarín:

1. Salimos de París (Francia)

2. Saltamos hasta Washington (Estados Unidos)

3. Nos movemos hasta el oeste, Phoenix (Estados Unidos)

4. Llegamos hasta Buenos Aires (Argentina)

Como vemos, la gran diferencia es que esta vez no volvemos a España antes de ir a Argentina, y todos los saltos que antes se daban en España ahora se dan en Estados Unidos:

Esta ha sido la información obtenida sobre la ruta de los paquetes:

Cursos sobre redes de computadores

Aqui os podreis bajar unos documentos creados para el Master Oficial de Software Libre de la UOC (Universitat oberta de catalunya-http://www.uoc.edu/).

Curso redes de computadores

Aspectos avanzados de seguridad en redes

Sistema operativo LINUX basico

Segunda Práctica. Anexo

Aqui presentamos el video que hemos producido, sobre el tema del trazador de rutas.

Segunda Práctica. Apartado 5d

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

En este caso obtenemos la misma respuesta, un mensaje de error de tiempo excedido de la misma máquina. La diferencia se encuentra en el tiempo que ha tardado en aparecer el mensaje. En este segundo caso el tiempo ha sido mucho mayor ya que el paquete ha tenido que dar muchos más saltos hasta que se ha agotado su tiempo de vida.

Segunda Práctica. Punto 5c

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?

MENSAJE ICMP TIME-TO-LIVE EXCEEDED

• TYPE: 11 (Time -to-live exceeded)
• CODE: 0 (Time -to-live exceeded in transit)

Al aumentar a 50 el TTL, el mensaje salata de una maquina a otra dentro de un bucle creado en esa subred, debido a que no puede encontrar la maquina de destino.

El bucle entre maquinas se genera en la subred:

SUBRED 10.3.255.255

Segunda Práctica. Punto 5b

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 esta ocasión, la máquina que devuelve el mensaje de ICMP Time-to-live exceeded es la 10.4.2.5 con la MAC 00:07:0e:8c:8c:ff que es la de la puerta de enlace. En el apartado anterior, recibiamos IP y Mac de la puerta de enlace. Al forzar el ping con dos saltos, recibimos la IP de una maquina de otra subred, pero la mac será siempre la de nuestra puerta de enlace.

Segunda Práctica. Punto 5a

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)

La máquina que devuelve el mensaje de ICMP Time-to-live exceeded es la 172.20.43.230 con MAC 00:07:0e:8c:8c:ff.

Dentro de la topología del laboratorio esta maquina es la “puerta de enlace predeterminada”

Cuestión 5. Práctica 2

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

Segunda Práctica. Punto 4g

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?

MENSAJE ICMP ECHO REQUEST

• IDENTIFICATION: 0×9939 (39225)
• TIME TO LIVE: 128
• CHEKSUM: 0×495c (CORRECT)

En el datagrama original, estos datos se encuentran dentro de la cabecera IP

MENSAJE ICMP REDIRECT

• IDENTIFICATION: 0×9939 (39225)
• TIME TO LIVE: 127
• CHEKSUM: 0×495c (inCORRECT, SHOULD BE 0xf3ff)

En el datagrama Redirect, encontramos el mensaje original, dentro del apartado de datos (ICMP)

En cuanto al dato de TTL (time to live), ha disminuido en una unidad (el salto producido en el router que nos ha contestado con el error de redirección).

En la cabecera IP del mensaje ICMP Redirect, podemos observar que su TTL es de 255. Fijando un número de saltos mayor, se asegura la recepción correcta del error en la maquina de origen del mensaje ICMP Request.

Segunda Práctica. Punto 4f

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?

• Dentro del mensaje ICMP redirect, recibiremos en el campo GATEWAY ADRESS: 172.20.43.231, que será la nueva puerta de acceso que deberemos utilizar.

• Además se encuentra el propio Request enviado en primer lugar. Además el mensaje Redirect añade el tipo 4 code 1 (redirect for host)

Segunda Práctica. Punto 4e

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

El router 172.20.43.230 es el que genera el mensaje ICMP REdirect to Host, enviando a su vez la petición de ping al destino.

Segunda Práctica. Punto 4d

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	TIPO Y CODIGO ICMP	ORIGEN MAC	DESTINO MAC	ORIGEN IP	DESTINO IP
1	REQUEST CODE:0	00:0a:5e:76:fe:38	00:07:0b:8c:8c:ff	172.20.43.216	10.4.2.1
2	REDIRECT CODE:1	00:07:0b:8c:8c:ff	00:0a:5e:76:fe:38	172.20.43.230	172.20.43.216
3	REPLY CODE:0	00:d0:ba:e0:6a:3d	00:0a:5e:76:fe:38	10.4.2.1	172.20.43.216

En la primera trama “echo request” nuestro ordenador (172.20.43.216) trata de comunicarse con el destino 10.4.2.1. Sin embargo con esta petición no recibe la dirección física MAC del 10.4.2.1, sino del ordenador 172.20.43.230, que es un paso intermedio. En esta trama podemos comprobar que las direcciones no hacen referencia al mismo interfaz

Es este ordenador (el 172.20.43.230) quien nos manda la trama de “redirect” a nuestro PC en el segundo paso. Finalmente el ordenador de destino 10.4.2.1 nos responde con la trama “echo reply”.

Segunda Práctica. Punto 4c

4.c. ¿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?

Al cometer el error de direccionamiento, se generarán 4 mensajes ICMP. Nosotros solo veremos tres, hay un switch en medio que impide que se pueda visualizar el mensaje “echo” copiado por el router, que se envía a destino.

Segunda Práctica. Punto 4b

Grafico del envio y recepción de mensajes de redirect:

Segunda Práctica. Punto 4a

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

DATAGRAMA		TIPO Y CODIGO ICMP	TAMAÑO PAQUETE ICMP	ORIGEN IP	DESTINO IP
1		REQUEST/CODE:0	60 bytes	172.20.43.216	10.4.2.1
2		REDIRECT/CODE:1	54 bytes	172.20.43.230	172.20.43.216
3		REPLY/CODE:0	60 bytes	10.4.2.1	172.20.43.216

Segunda Práctica. Punto 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)

Segunda Práctica. Puto 3b

3.b. ¿Qué máquina de la red envía el mensaje ICMP “Fragmentation Needed and Don’t Fragment was Set” (3/4)?

Como en el anterior apartado, la maquina con ip 10.4.2.5 router Cisco 2513 es la que devuelve el mensaje de “fragmentation needed”

Segunda práctica. Punto 3a

3.a. Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen?

La maquina que responde C:\>ping -n 1 –l 1000 -f 10.3.7.0 es la 10.4.2.5 router Cisco 2513. La MAC que nos responde es la 00:07:0e:8c:8c:ff .

Segunda Práctica. Punto 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)

Segunda práctica. Punto 2i

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

• Cuando nuestro datagrama pasa por una red con MTU menor que la nuestra, el datagrama original es divido en los fragmentos necesarios para pasar por la nueva red. Nos son devueltos con el tamañana a la que esta ultima red los ha dejado. El reensamblado se realizará en nuestra maquina.

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.

• Cuando hacemos un ping hacia C:\>ping –n 1 –l 2000 172.20.43.230, el datagrama original se divide en dos, dos para mensaje request y dos para mensaje reply. Esto no sucede en todas las subre4des atravesadas, ya que cuando hacemos ping a C:\>ping –n 1 –l 1600 10.3.7.0, el mensaje reuest se divide en dos, pero recibimos de vuelta u mensajes reply. En una de las subredes, la MTU era menor y el mensaje a sido subdividido.

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?

• Nuestro mensaje atravesará 3 subredes hasta llegar a la maquina 10.3.7.0.

Segunda práctica. Punto 2h

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

DATAGRAMA Nº	PROTOCOLO	DIRECCION	FLAGS	FRAG. OFFSET	IDENTIFICACION
1	ICMP	REQUEST	0×02	0	0×88ce
2	IP	REQUEST	0×00	1480	0×88ce
3	IP	REPLY	0×00	1440	0×0069
4	IP	REPLY	0×02	960	0×0069
5	IP	REPLY	0×02	480	0×0069
6	ICMP	REPLY	0×02	0	0×0069

Segunda Práctica. Punto 2g

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

request: 172.20.43.216

reply: 172.20.43.195

DATAGRAMA Nº	PROTOCOLO	DIRECCION	FLAGS	FRAG. OFFSET	IDENTIFICACION
1	ICMP	REQUEST	0X02	0	0X4343
2	IP	REQUEST	0X02	1480	0X4343
3	IP	REQUEST	0X00	2960	0X4343
4	ICMP	REPLY	0X02	0	0X805C
5	IP	REPLY	0X02	1480	0X805C
6	IP	REPLY	0X00	2960	0X805C

Segunda práctica. Punto 2f

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

La MTU de la red corresponderá al numero de fragmen ofsset 1480 mas la cabecera. Por lo tanto la MTU de la red será de 1500

MTU=1500

Segunda práctica. Punto 2e

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

IDENTIFICACION: Identifica al datagrama original

FLAGS: Identifica que trozo es del datagrama original

FRAGMENT OFSSET: Apartir de donde se ha recortado el datagrama enviado

Segunda práctica. Punto 2d

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?

Ahora se visualizan solo los fragmentos que contienen la cabecera ICMP, es decir, los primeros de cada paso. Esto sucede porque los fragmentos truncados correspondientes a la última parte de la información carecen de la cabecera ICMP, que sólo se envía en el primer fragmento.

Segunda práctica. Punto 2c

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	DIRECCION	FLAGS	FRAG. OFFSET	IDENTIFICACION
1	ICMP	REQUEST	0X02 (more fragments)	0	0×9471 (38001)
2	IP	REQUEST	0X00	1480	0×9471 (38001)
3	ICMP	REPLY	0X02 (more fragments)	0	0×9471 (38001)
4	IP	REPLY	0X00	1480	0×9471 (38001)

Segunda práctica. Punto 2b

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

Cada datagrama orginal se ha dividio en dos:

Segunda práctica. Punto 2a

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?

En total hay 4 fragmentos de datagramas IP lanzados al medio. Dos corresponden a la petición y los otros dos a la respuesta. En el monitor de red aparecen identificados de dos maneras. En el primer fragmento aparece clasificado como protocolo ICMP, ya que contiene tanto cabecera IP como cabecera ICMP. En el segundo fragmento, tanto de petición como de respuesta, aparece como protocolo IP ya que no tiene la cabecera ICMP. Esta cabecera se queda en el primer fragmento al truncar, ya que se considera parte de los datos de IP.

Segunda Práctica. Punto 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)

Segunda Práctica. Punto 1c

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 captura total realizada con el wireshark contiene 74 bytes, dividos como aparece en la siguiente tabla:

La cabecera para ICMP tendrá 8 bytes, resultado obtenido conociendo el total de datos capturados y los distintos tamaños de cabeceras ethernet, ip y el tamaño de los datos ICMP.

En el mensaje ping se han transportado 32 bytes de información (esta cantidad de de datos ICMP enviados y recibidos puede ser variada mediante la inclusión del comando <-l>)

Segunda Práctica. Punto 1b

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?

• ECHO REPLY – MUESTRA PRIMERO MAC PUERTA ENLACE
• 
• ECHO REQUEST – MUESTRA PRIMERO MAC PC ALUMNO
• 

En nuestro ejemplo realizado en el laboratorio obtenemos la IP y MAC de nuestra máquina como origen de la ICMP request y destino de la reply. La dirección IP y MAC de destino de la request y la fuente de la reply coincide con la puerta de enlace del laboratorio. Hemos comprobado esta correspondencia mendiante el comando “arp -a”. En caso de que hiciésemos el ping a una máquina externa a nuestra red, obtendríamos como IP fuente del mensaje de reply la dirección de la máquina remota con la que nos hemos comunicado, pero como fuente MAC aparecería la dirección física de nuestra puerta de enlace, ya que es ella quien nos envía el mensaje. En este caso no ocurre esto porque las dos máquinas son la misma.

Segunda Práctica. Punto 1a

1.a. ¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)

Al usar el comando ping aparecen dos tipos de mensajes diferentes: “echo request” y “echo reply”. Cada uno de ellos aparece tantas veces como mensajes echo se hayan enviado mediante el comando ping. Si, por ejemplo, enviamos 3 mensajes echo con el ping (ping -n 3 xxx.xxx.xxx.xxx), aparecerán 6 mensajes ICMP: 3 mensajes “echo request” y otros tres de “echo reply”.

Los mensajes echo request son de tipo 8, mientras que los mensajes echo reply son de tipo 0. En cuanto al código, ambos son código cero.

Segunda Práctica

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)

Primera práctica. Punto 4c

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

Dirección IP: 217.76.156.115 (Clase C)

• http://www.ono.es

Dirección IP: 62.42.230.18 (Clase A)

• http://www.ua.es

Dirección IP: 193.145.233.8 (Clase C)

Primera práctica. Punto 4b

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

• De los datagramas visualizados, indica cuál es su longitud.
• ¿Qué aparece en el campo de Protocolo de cada datagrama?
• Identifica la CLASE de dirección asociada a cada dirección IP fuente o destino.

Hemos realizado una tabla con el tipo de protocolo, longitud y su clase calculada a partir de la IP:

Protocolo	Longitud	IP	Clase
HTTP	999	80.239.170.200	A (elpais.com)
DNS	160	172.25.40.81	B
HTTP	442	193.145.233.8	C (ua.es)
TCP	40	172.25.32.101	B

Primera práctica. Punto 4a

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.

La máscara normal será 11111111.11111111.11111110.00000000. Si añadimos dos bits quedará 11111111.11111111.11111111.10000000, es decir, 255.255.255.128.

En total tendremos 4 subredes:

• 255.255.254.0
• 255.255.254.128
• 255.255.255.0
• 255.255.255.128

En cada subred tendremos (2^7)-2 direcciones IP disponibles con los siete bits restantes, ya que dos de ellas están reservadas. En total son 126 direcciones posibles por cada subred (504 en total).

Primera práctica. Punto 3e

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

Con este esquema, la secuencia de tramas que resultaría sería la siguiente:

Comando	Origen MAC	Origen IP	Destino MAC	Destino IP
Who is 5.1.1.0?	Mac 1	5.1.2.0	Mac2	5.1.1.0
5.1.1.0 is at mac2	Mac2	5.1.1.0	Mac1	5.1.2.0
Who is 5.2.2.0	Mac3	5.2.1.0	Mac4	5.2.2.0
5.2.2.0 is at mac4	Mac4	5.2.2.0	Mac3	5.2.1.0

En general, podemos dividirlo en dos partes. En la primera el ordenador fuente busca su puerta de enlace para salir al exterior. En la segunda parte es la puerta de enlace del ordenador de destino quien busca a este ordenador mediante una ARP.

Primera práctica. Punto 3d

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

A diferencia del apartado b) donde se cambiaba la memoria caché de ARP, al buscar direcciones externas esta memoria se guarda sólo la dirección de la puerta de enlace al salir al exterior.

Primera práctica. Punto 3c

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?

Podemos ver en esta imagen que la memoria caché de ARP almacena la dirección del ordenador que ha hecho el ping a nuestra máquina.

Las tramas que intervienen en el proceso son las mismas que en el caso de que sea nuestra máquina la que lance la ARP: la trama de petición y la de respuesta.

Primera práctica. Punto 3b

3.b 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

La memoria caché cambia cada vez que buscamos una IP distinta. Cada vez que lo hacemos se lanza la ARP y se cambia el contenido de la caché con la dirección física que devuelve la última ARP.

Primera práctica. Punto 3a

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.

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)

3.a 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?

Como podemos ver en la imagen, sólo aparecen dos tramas ARP: una de petición y otra de respuesta.

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

Después del ping en la memoria caché del ARP se guarda la correspondencia con la IP y el MAC del ordenador con el que hemos hecho el ping.

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 porque la memoria caché de ARP aún conserva la dirección física MAC.

Primera práctica. Punto 2f

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

Aula24 aparece en 4 tramas de aplicacion navegador web http

Primera práctica. Punto 2e

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

En la captura hay un total de 9 tramas. La aplicación que generas estas tramas es ‘tracert’ (comando tracert 193.145.233.8).

Primera práctica. Punto 2d

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

En la captura hay un total de 8 paquetes Ip que contienen la cadena ‘ACBDE….’. El comando ping es el que genera esta cadena. Envía la cadena y espera la respuesta calculando los tiempos.

Primera práctica. Punto 2c

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

De las 14298 tramas capturadas por el programa, 1206 son tramas Ip con destino nuestro pc. El 8,43 % de las tramas que viajaban por la red del laboratorio, son tramas Ip con destino nuestro pc.

Primera práctica. Punto 2b

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

De las 14298 tramas capturadas por el programa, 14258 son tramas Ip. El 99,72 % de las tramas que viajaban por la red del laboratorio, son tramas Ip.

Primera práctica. Punto 2a

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.

2.a Calcula el porcentaje de tramas Ethernet de difusión existentes en la captura.

Las tramas de difusión son aquellas que se lanzan a la red sin destinatoario preasignado

De las 14298 tramas capturadas por el programa, 13045 son tramas Ethernet de difusión. El 91,23 % de las tramas que viajaban por la red del laboratorio, son tramas de difusión.

Primera práctica. Punto 1c

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?

De las 6673 tramas, 499 tienen por origen o destino nuestro pc. El 7,48 % de las tramas que viajaban por la red del laboratorio, tenían como origen o destino nuestro pc.

Los resultados son coherentes con los resultados obtenidos en los dos apartados anteriores, simplemente obtenemos la suma de las tramas de origen y destino.

Primera práctica. Punto 1b

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

De las 6673 tramas, 436 tienen por origen nuestro pc. El 6,53 % de las tramas que viajaban por la red del laboratorio, tenían como origen nuestro pc.

Primera práctica. Punto 1a

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?

Primero debemos saber cual es la IP de nuestro pc, así podremos filtrar las tramas que le van dirigidas. Abrimos pantalla MS-dos, y pulsamos Ipconfig, nos aparecerá la siguiente información:

Por lo tanto, nuestra Ip es 172.20.43.220. Abrimos wireshark, y en filter añadimos ip.dest==172.20.43.220, así solo visualizaremos las tramas que tengan por destino nuestro ordenador. Obtenemos esta captura:

De las 6673 tramas, 63 tienen por destino nuestro pc. El 0,94 % de las tramas que viajaban por la red del laboratorio, tenían por destino nuestro pc.

Presentación

En este blog, los ingenieros Sergio y Antonio, desarrollaremos todos los puntos de las practicas del curso de redes, de la Ingeniería de Telecomunicaciones.Trataremos punto por punto, los principales aspectos de la asignatura.