Google Maps (Universidad de Alicante)

Ver mapa más grande

Práctica 1.- Introducción a Redes y a TCP/IP sobre Tecnología Ethernet. Cuestión 4.- Sobre TCP/IP.

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.

Vieja.-
11111111 .11111111 .11111110.00000000 (255.255.254.0)

Nueva.-
11111111 .11111111 .11111111.10000000 (255.255.255.128)

El rango de direcciones que puede emplearse para numerar las máquinas es 2^7-2= 126, restamos dos porque el caso en que los 7 bits sean todos igual a 0 es la dirección de la red propiamente dicha y si esta todo a 1 tampoco podemos considerarlo porque es una dirección de Broadcast (difusión).

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

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

En la captura realizada con el monitor de red se puede observar que al coger al azar varios datagramas IP, estos tienen una longitud de 78 bytes.

Figura 4.b.- Captura con el monitor de red de varios datagramas IP de longitud 78 bytes.

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

En el campo de Protocolo de cada datagrama aparecen las siglas NBNS.

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

La clase de dirección asociadA a estos datagramas es B, puesto que la dirección IP está comprendida entre 128.0.0.0 y 191.255.255.255.

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/

Su dirección IP es 217.76.156.115, dicha dirección IP es de clase C.

http://www.ono.es/

Su dirección IP es 62.42.230.18, dicha dirección IP es de clase A.

http://www.ua.es/ (Universidad de Alicante)

Su dirección IP es 193.145.233.8, dicha dirección IP es de clase C.

Práctica 1.- Introducción a Redes y a TCP/IP sobre Tecnología Ethernet. Cuestión 3.- Sobre el protocolo ARP.

Cuestión 3.- Sobre el protocolo ARP.

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.

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?

Intervienen 2 tramas.

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

Si ejecutamos el comando arp-a visualizamos la tabla ARP (memoria caché de 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?

No, en este caso no aparecen secuencias de tramas ARP, ya que al estar guardada en la memoria caché la dirección MAC, no es necesario cargar de nuevo 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?

Ejecutamos el comando "ping" a las direcciones IP de los compañeros 172.20.43.206, 172.20.43.207 y 172.20.43.208. Con esto estamos realizando una petición a cada uno de estos equipos mediante su dirección IP correspondiente. Al observar la memoria caché de ARP observamos que se han guardado las correspondiente direcciones MAC de los puestos a donde realizamos la petición. Esto sucede a que existe una conexión en red local entre estos tres equipos y el mío, si no fuese así lo que aparecería en la memoria caché de ARP sería la dirección MAC de un router que haría de la función de puerta de enlace entre redes.

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?

En primer lugar tendremos que borrar el contenido de la memoria caché de ARP con el comando arp -d . La caché de ARP va aumentando según recibimos los comandos "ping", pudiendo observar tanto la dirección IP como la dirección MAC de lás máquinas que nos están enviando peticiones. Las tramas de ARP que aparecen en el monitor de red son tramas de petición y respuetas entre los equipos que están enviando peticiones a mi ordenador y el mío.


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

Borramos el contenido de la caché ARP con el comando arp -d .

No es extraño que en la memoria caché de ARP aparezca la misma dirección IP y MAC en los tres casos, ya que en el primer caso la petición se la estamos realizando al propio router (puerta de enlace) y en segundo y tercer caso las peticiones se realizan a equipos que están fuera de nuestra red local, para poder salir de nuestra red local tendremos que pasar por la puerta de enlace, de manera que será la dirección de ésta la que quede registrada en la caché ARP.


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

Figura 23.- Conexión de subredes a través de un router. Red simulada. No corresponde al aula L24.

Práctica 1.- Introducción a Redes y a TCP/IP sobre Tecnología Ethernet. Cuestión 2.- Análisis estadístico de una captura de datos.

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

Figura 2.a.1.- "Ping" hacia la dirección 172.20.43.230.

Figura 2.a.2.- "Tracert" hacia 172.20.43.230 (traza de caminos hacia la dirección indicada).

Introducimos en el monitor de red el filtro "eth.addr==FF-FF-FF-FF-FF-FF".

Tramas de difusión=10010

Tramas totales=10428

% tramas de difusión ethernet=tramas de difusión/tramas totales*100=(10010/10428)*100=95,99%

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

Introducimos en el monitor de red el filtro "ip".

La función del filtro "ip" es filtrar las tramas ip existentes en la captura.

Tramas de difusión=10402

Tramas totales=10428

% tramas de difusión ethernet=tramas de difusión/tramas totales*100=(10402/10428)*100=99,75%

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

Introducimos en el monitor de red el filtro "ip.src==172.20.43.205".

Tramas de difusión=789

Tramas totales=10428

% tramas de difusión ethernet=tramas de difusión/tramas totales*100=(789/10428)*100=7,57%

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

Introducimos en el monitor de red el filtro "ip contains "abcd"".

El número de paquetes que contienen "abcd" en su interior es 8. Pertenecen a 4 peticiones con respuesta del comando "ping". El protocolo que aparece es ICMP (práctica II) INTERNET CONTROL MESSAGE PROTOCOL.

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

Introducimos en el monitor de red el filtro "ip.ttl==1".

El número de paquetes que contienen el campo de la cabecera IP "TTL" igual a 1 es 3. La aplicación que los ha generado es ICMP como se puede observar en el protocolo del monitor de red.

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

Introducimos en el monitor de red el filtro "ip contains "aula24". Estas tramas hay que destacar que se crean al buscar en google "aula24".

Aparecen cuatro tramas:

TRAMA 1.- Aplicación: DNS.- (Domain Name System) Sistema de Nombres de Dominio. Conjunto de protocolos y servicios para la identificación/conversión de una dirección de internet expresada en lenguaje natural por una dirección IP.

TRAMA 2.- Aplicación: DNS.- (Domain Name System) Sistema de Nombres de Dominio. Conjunto de protocolos y servicios para la identificación/conversión de una dirección de internet expresada en lenguaje natural por una dirección IP.

TRAMA 3.- Aplicación: HTTP.- (HyperText Transfer Protocol). Protocolo usado para acceder a la Web (WWW). Se encarga de procesar y dar respuestas a las peticiones para visualizar una página web. Además sirve para el envío de información adicional como el envío de formularios con mensajes, etc.

TRAMA 4.- Aplicación: TCP.- (Transmission Control Protocol - Protocolo de Control de Transmisión). Se trata del protocolo más usado de internet, el cual ofrece un servicio fiable, con lo que los paquetes llegan ordenados y sin errores, además de ocuparse también del control de flujo extremo a extremo.

Práctica 1.- Introducción a Redes y a TCP/IP sobre Tecnología Ethernet. Cuestión 1.- Iniciación al mntr. de red. Visualización de protocolos en la red

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…

Enlace para descargar Wireshark: http://www.wireshark.org/download.html

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

Introducimos en el monitor de red el filtro "ip.dst==172.20.43.205" .

La función del filtro "ip.dst" es filtrar las tramas que salen de nuestro equipo (destino). El número "172.20.43.205" es la dirección ip de nuestra máquina (la subred del equipo de nuestro puesto). Para poder obtener la dirección ip de nuestro equipo basta con ejecutar el símbolo de sistema e introducir el comando "ipconfig".

Tramas Adquiridas -> P=9150

Tramas Dirigidas -> D=989

Figura 1.a.- Captura con el monitor de red de las tramas que salen de nuestro equipo.

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

Introducimos en el monitor de red el filtro "ip.src==172.20.43.205".

La función del filtro "ip.src" es filtrar las tramas que entran a nuestro equipo (origen).

Tramas Adquiridas -> P=9150

Tramas Enviadas-> D=1059

Figura 1.b.- Captura con el monitor de red de las tramas que entran a nuestro equipo.

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?

Introducimos en el monitor de red el filtro "ip.addr==172.20.43.205".

La función del filtro "ip.addr" es filtrar las tramas tanto de entrada como de salida, es decir, tanto de origen como destino a nuesto equipo.

Sí que es coherente el valor obtenido con los resultados anteriores, debido a que el resultado obtenido en este apartado tiene que ser igual a la suma de las tramas enviadas y recibidas en los apartados anteriores.

Tramas Adquiridas-> P=9150

Tramas Enviadas y Recibidas-> D=2048 (Valor obtenido del monitor de red)

Figura 1.c.- Captura con el monitor de red de las tramas que entran y salen de nuestro equipo.

989+1059=2048 (Valor calculado correcto al ser igual que el obtenido en el monitor de red)

Práctica 3.- Protocolos de nivel de Transporte TCP/IP. Cuestión 7.-

Cuestión 7.-

En base a la topología que se muestra a continuación:

Considerando que todos los equipos presentes en dicha topología cumplen la RFC 1191. Determina el número de segmentos que se generan al mandar un paquete TCP con 1500 bytes de datos desde la máquina ‘A’ a la máquina ‘E’:

a. Número, tipo y código de paquetes ICMP.

b. Indica la MTU del camino de camino completo.

La MTU del camino completo es la MTU más pequeña de toda la red, la subred que contiene la MTU más pequeña es la que existe entre la máquina B y D que es de 500 bytes.

Figura 7.b.- MTU del camino completo de la red.

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.

Figura 7.c.- Longitud total de cada paquete TCP construido en la fragmentación al mandar un paquete TCP original con 1500 bytes de datos.

Práctica 3.- Protocolos de nivel de Transporte TCP/IP. Cuestión 6.-

Cuestión 6.-

Determinar el número de paquetes UDP que se generan (indicando el formato de los paquetes: cabeceras, etc…), cuando el nivel de transporte envía 1000 bytes de datos en una red Ethernet con una MTU de 500 bytes. Hacer lo mismo considerando que el nivel de transporte utilizado fuera TCP.

Figura 6.a.- Paquetes UDP que se generan cuando el nivel de transporte envía 1000 bytes de datos en una red Ethernet con una MTU de 500 bytes.

Figura 6.b.- Paquetes TCP que se generan cuando el nivel de transporte envía 1000 bytes de datos en una red Ethernet con una MTU de 500 bytes.

Práctica 3.- Protocolos de nivel de Transporte TCP/IP. Cuestión 5.-

Cuestión 5.-

Realiza una conexión FTP a la máquina de un compañero de clase. ¿Qué obtienes en el Monitor de Red al intentar realizar esta conexión?

Realizamos una conexión ftp a la máquina 172.20.43.204, observamos tres intentos de conexión, de hecho en el monitor de red se obsera que se llega a establecer la comunicación, eso es debido al mero de hecho de que ambas máquinas están conectadas en red pero la aplicación ftp esta desactivada y por ello acaba cerrándose (perdiendo) la conexión.

Figura 5.a.- Conexión FTP a la máquina 172.20.43.204.

Figura 5.b.- Captura mediante el monitor de red con tres intentos de conexión FTP a la máquina 172.20.43.204.

Práctica 3.- Protocolos de nivel de Transporte TCP/IP. Cuestión 4.-

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?

En este caso nuestra máquina sigue teniendo una MSS de 1460 bytes (1500-20 (IP)-20(TCP)=1460) pero en el servidor 10.3.7.0 la MSS es más pequeña, en concreto de 460 bytes (MTU de 500 bytes) por lo tanto se negocia y establece la MSS más pequeña que es la de 460. La diferencia con respecto al caso anterior es que ahora las MSS son distintas mientras que en el ejercicio las MSS eran iguales.

Figura 4.a.- Ejecución del comando "cat ifconfig.txt" en el servidor 10.3.7.0 con el programa rexec.

Figura 4.b.- Captura mediante el monitor de red de los segmentos TCP transportados dentro de los paquetes IP.

Práctica 3.- Protocolos de nivel de Transporte en TCP/IP. Cuestión 3.-

Cuestión 3.-

Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 172.20.43.232 (Linux2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño. ¿IP ha fragmentado estos segmentos? ¿Por qué ocurre esto? ¿Cuál es el tamaño de los segmentos TCP?

En TCP no es posible la fragmentación debido a que está activo el Bit Don't Fragment (Práctica II). La MSS de nuestra máquina es de 1460 (es decir MTU=1500 bytes) y la MSS del servidor también es de 1460, por lo tanto como ambas son iguales se negocia que la MSS de la conexión será de 1460 bytes (siempre la MSS que se negocia es la menor entre nuestra máquina y el servidor).

Figura 3.a.- Ejecución del comando "cat ifconfig.txt" en el servidor 172.20.43.232 con el programa rexec.

Figura 3.b.- Captura en el monitor de red de segmentos TCP de gran tamaño.

Traza de rutas desde París (Eu.org) hasta la web www.clarin.com

Traza de rutas desde París (Eu.org) hasta la web del Govierno federal de Argentina (www.argentina.gov.ar).

Traza de rutas desde Rusia hasta la web www.sony.com

Traza de rutas desde Australia (Telstra.net) hasta la web de la Universidad de Alicante (www.ua.es).

Práctica 3.- Protocolos de nivel de Transporte en TCP/IP. Cuestión 2.-

Cuestión 2.

Rexec. Remote Shell es un servicio presente en un S.O. UNIX con TCP/IP que atiende el puerto
TCP 512 en espera de peticiones de ejecución de comandos desde procesos remotos clientes. Utiliza TCP, por lo que trabaja con conexión. Para las prácticas se dispondrá de un programa para MS Windows (rexec.exe) que actúa como cliente. En una sesión de rexec.exe se pide inicialmente un nombre de usuario y password en la máquina servidora, y tras introducir estos, se pueden ejecutar comandos UNIX en dicha máquina. Nos servirá para estudiar una conexión TCP. Dentro de una máquina UNIX, el cliente es un programa de línea de comandos con esta sintaxis básica:

rsh "IP_SERVIDOR""COMANDO_A_EJECUTAR" .

Empleamos el programa rexec para ejecutar el comando ‘ls –l’ en la maquina con dirección 172.20.43.232 (Linux2). Utilizamos para ello el usuario ‘alumnos’ y la clave ‘alumnos’. Con el monitor de red, analizamos y estudiamos 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. Utilizamos para ello el filtro adecuado (direcciones y protocolos).

Figura 2.a.1.- Ejecución del programa Rexec con comando "ls -l" a la máquina 172.20.43.232.

Figura 2.a.2.- Captura mediante el monitor de red de conexión y desconexión TCP.

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

Se solicita el establecimiento de conexión a la máquina 172.20.43.232, nos devuelve la petición aceptada mediante el ACK y nuestra máquina acepta el establecimiento de conexión, se establece la sincronización (es decir, la sesión), posteriormente se produce la autentificación de usuario y contraseña, se envían dos veces las palabras username: alumnos, el servidor confirma que ha recibido los datos y finaliza la conexión (Servidor-Cliente), enviando nuestra máquina un [FIN, ACK] y devolviendonos el servidor un ACK para confirmarnos la finalización de la conexión con un ACK. Se observa que se envían muchos paquetes redundantes debido a utilizar un protocolo tan seguro como es TCP.

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

TRANSMISSION CONTROL PROTOCOL

Puerto Origen: 2831

Puerto Destino: 512

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

Window size: 65535 (Origen) 172.20.43.205

Window size: 5840 (Destino) 172.20.43.232

Práctica 3.- Protocolos de nivel de Transporte en TCP/IP. Cuestión1.-

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.

Figura 1.1.- Ejecución de "pracredes.bat" para cargar la configuración de la red del laboratorio.

Figura 1.2.- Teoría vista en clase sobre Protocolos de nivel de Transporte en TCP/IP.

a. Utilizamos 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 especificamos la dirección IP y el puerto del servidor, colocamos algún texto en la ventana y pulsamos el botón "Envía UDP". Con el monitor de red, analizamos la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo “Texto de prueba”. Utilizamos el filtro adecuado en el Monitor de Red (direcciones y protocolos).

Figura 1.a.1.- Ejecución del programa udp.exe para realizar un envío de datos al puerto 7 (eco).

Figura 1.a.2.- Captura mediante el monitor de red empleando un filtrado "nbns" e "ip.addr" con nuestra dirección ip.

Figura 1.a.3.- Ejecución del programa udp.exe para realizar un envío de datos al puerto 13 (hora y día).

Figura 1.a.4.- Captura mediante el monitor de red empleando un filtrado "nbns" e "ip.addr" con nuestra dirección ip.

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

Figura 1.b.1.- Ejecución del programa udp.exe para realizar un envío de 2786 bytes de datos al puerto 7 (eco).

Figura 1.b.2.- Captura mediante el monitor de red empleando un filtrado "nbns" e "ip.addr" con nuestra dirección ip para comprobar el fragmentado que se realiza en UDP.

Enviamos un total de 2786 bytes, en la llamada envíamos los datos mediante una subred con una MTU de 1500 bytes, de manera que se divide en dos datagramas, el 1º de ellos tiene un tamaño de 1480 bytes menos los 8 bytes de la cabecera UDP, 1472 bytes, el segundo datagrama nos dice que tiene un tamaño total de datos, es decir, descartando los 20 bytes de la cabecera IP de 1314 bytes. 1472+1314=2786 bytes. En la respuesta el paquete se divide en 6 fragmentos, esto es debido a que pasa por una subred con una MTU de 500 bytes, en total tenemos 5 paquetes con un tamaño de 480 bytes (al descartar los 20 bytes de la cabecera IP), 480 bytes x 5=2400 bytes, a estos 2400 bytes habrá que restarles los 8 bytes de la cabecera UDP, tenemos pues 2392 bytes que más los 394 bytes de datos que tiene el último paquete suman los 2786 bytes de datos que enviamos.

Práctica 2.- Cuestión 5.- Mensaje ICMP "Time Exceded"

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)

Figura 5.a.1.- "Ping" hacia 10.3.7.0 con 32 bytes de datos y un TTL=1.

Figura 5.a.2.- Captura del mensaje "Time Exceded".

Enviamos un paquete de 32 bytes de datos a la máquina 10.3.7.0, debido a que le hemos dado como parámetro un tiempo de vida TTL=1, el paquete “morirá” en el primer router que encuentre, que es router 172.20.43.230. También es importante indicar que el analizador nos devuelve dos errores: el 1er error, “Destination unreachable” (efectivamente, el paquete no ha podido llegar a su destino y debido a esto nos aparece este error) , 2º error, “Time-to-live exceded”, al morir el paquete antes de llegar al destino.
Si se puede saber la MAC: 172.20.43.230, debido a que estamos dentro de nuestra subred, el problema estará cuando salgamos de nuestra subred, que en ese caso únicamente podremos saber la ip.

Figura 5.a.3.- Identificación de la máquina dentro de la topología de nuestra red.

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)

Figura 5.b.1.- "Ping" hacia 10.3.7.0 con 32 bytes de datos y un TTL=2.

Figura 5.b.2.- Captura del mensaje "Time Exceded".

En este caso hacemos un ping y enviamos nuevamente un paquete de 32 bytes a la máquina 10.3.7.0, en este caso el paquete “muere” en un nivel más arriba dentro de la topología del anexo. En este caso muere en 10.4.2.5. y la MAC será 172.20.43.230. La ip origen es la propia de nuestro equipo 172.20.43.205 y la MAC, la de la puerta de enlace del router con el que salimos de nuestra subred.

Figura 5.b.3.- Identificación de la máquina dentro de la topología de nuestra red.

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?

Figura 5.c.1.- "Ping" hacia 10.3.7.12 con 32 bytes de datos y un TTL=50.

Figura 5.c.2.- Captura del mensaje "Time Exceded" con un TTL=50.

Tipo 11: Tiempo excedido para un datagrama.
Código 0: Red de destino inaccesible.

¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error?

Se esta produciendo un bucle cerrado entre las máquinas Cisco 2513 y LINUX 1.

¿En qué subred estaría ubicada?

Subred 10.3.0.0.

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

Figura 5.d.1.- "Ping" hacia 10.3.7.12 con 32 bytes de datos y un TTL=120.

Figura 5.d.2.- Captura del mensaje "Time Exceded" con un TTL=120.

Al ponerle un tiempo de vida de 120 saltos, el tiempo de respuesta aumenta considerablemente, debido a que tarda más en consumir los 120 saltos que los 50 saltos reflejados anteriormente. Muere en la misma máquina que antes, en: 10.3.2.0.
Como prueba, he vuelto a realizar un ping pero en lugar de indicarle 120 saltos, le he indicado 121, de manera que en vez de morir en la máquina 10.3.2.0, muere en la máquina 10.3.7.0.

Figura 5.d.3.- "Ping" hacia 10.3.7.12 con 32 bytes de datos y un TTL=121.

Figura 5.d.4.- Captura del mensaje "Time Exceded" con un TTL=121.

- El tiempo es mayor en este segundo caso que en el caso anterior, porque el tiempo de vida ha sido aumentado.

*Nota: El TTL se tuvo que modificar a 120 porque con 220 se perdían los paquetes.

Práctica 2.- Cuestión 4.- Mensaje ICMP "Redirect"

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, filtramos únicamente los datagramas que contienen nuestra IP.

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

Datagrama nº Tipo y código ICMP Tamaño del paquete ICMP Origen IP Destino IP

1 tipo 8 código 0 74 bytes 172.20.43.205 - 10.4.2.1
2 tipo5 código 1 70 bytes 172.20.43.230 - 172.20.43.205
3 tipo 0 código 0 74 bytes 10.4.2.1 - 172.20.43.205

Figura 4.a.1.- "Ping" hacia 10.4.2.1.

Figura 4.a.2.- Captura del mensaje ICMP "Redirect".

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

Figura 4.b.1.- Funcionamiento del mensaje ICMP "Redirect" dentro de la topología de nuestra red.

Inicialmente borramos el camino que va de Mi PC a 10.4.2.1 mediante “route delete 10.4.2.1”. A continuación el ping va a la puerta de enlace 172.20.43.230, la cual envía un echo request redireccionándonos por un camino más corto (el que va de Mi PC directamente ha 10.4.2.1) y seguidamente 10.4.2.1 responde a Mi PC.

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?

El datagrama que no aparece es la copia del echo que realiza el router uno (puerta de enlace predeterminada 172.20.43.230), esto es debido a que el switch realiza un filtrado por seguridad que consiste en que los mensajes entre routers no puedan ser visualizados por el resto de equipos de la red.

4.d. ¿Las direcciones MAC e IP de todas las tramas capturadas con el Monitor de Red hacen referencia al mismo interfaz de red? Indica en qué casos la respuesta es afirmativa y en que casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

Datagrama nº Tipo y código ICMP Origen MAC – Origen IP ¿representan al mismo interfaz?

1 Tipo 8 código 0(echo request) 00:0a:5e:76:ff:99 - 172.20.43.205 Sí
2 Tipo 5 código 1 (redirect) 00:07:0e:8c:8c:ff - 172.20.43.230 Sí
3 Tipo 0 código 0 (echo reply) 00:d0:ba:eo.6a:3d - 10.4.2.1 Sí

- No se puede saber la dirección MAC fuera de nuestra red de enlace.

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

La puerta de enlace predeterminada (172.20.43.230).

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

Contiene un campo de 32 bits llamado dirección de internet del encaminador que contiene la dirección IP de salida correcta de la máquina correcta, además de contener el encabezado del datagrama que causó el error "Redirect".

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 siendo en el echo "ping" request 128 y en el mensaje ICMP "Redirect" 255, el Cheksum también se ve modificado debido a que es una suma de control.

Práctica 2.- Cuestión 3.- Mensaje ICMP "Destination Unreachable"

Cuestión 3.- Mensaje ICMP "Destination Unreachable"

Dentro del mensaje ICMP Destination Unreachable se analizará el de código 4: Fragmentation Needed andDon'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)

Figura 3.a.1.- "Ping" a la dirección 10.3.7.0 con 1000 bytes de datos (sin fragmentación).

Figura 3.a.2.- Captura del mensaje ICMP "Destination Unreachable".

Lo que comprobamos es que el "ping" que hemos enviado sigue la trayectoria indicada en el esquema de la parte inferior con una línea en negrita, esto significa que el analizador nos ha devuelto un error del tipo “Destination Unreachable”, que significa que a partir de algún punto de la red no va ha poder pasar porque la red es más pequeña y no soporta los 1000 bytes enviados (sin fragmentarlos) debido a que cuando hemos hecho la llamada con el ping le hemos añadido el parámetro –f que lo que hace es que impide la fragmentación. Nos responde la máquina 10.4.2.5, la dirección MAC es 172.20.43.230 y la dirección IP es 10.4.2.5 (Cisco 1720) y (Cisco 2513).

Figura 3.a.3.- Captura del mensaje de petición ICMP Echo (ping) request.

Figura 3.a.4.- Captura del mensaje de respuesta "Destination Unreachable".

Figura 3.a.5.- Ruta hacia la petición 10.3.7.0.

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)

CISCO 2513.