Cuestión 6

Cambiamos la ruta por la cual nos conectamos a la maquina Linux 1. Para ello hacemos lo siguente:
1)Cambiar la ruta para ir a Linux 1
Route delete 172.20.41.241
Route ad 172.20.41 172.20.43.231

2)C.\ftp 172.20.41.241
Usuario: alumnos
Pass: alumnos
bin
put p3.txt
quit

Primero manda un par de paquetes de 460 bytes de tamaño. Al recibir un mensaje de error indicando que el tamaño es demasiado grande y el nuevo tamaño de MTU se mandan de nuevo un par de paquetes teniendo en cuenta el nuevo tamaño de MTU para calcular el tamaño del MSS. Al comprobar que llegan bien los paquetes con ese tamaño cada vez se van mandando mas paquetes de golpe.

Cuestión 5

Realiza un conexción FTP a la máquina de un compañero de clase. ¿Qué obtienes en el monitor de red al intentar realizar la conexión?

Al intentar hacer una conexión FTP a otro ordenador, vemos como se han realizado 3 intentos pero ninguno de ellos ha establecido conexión con el otro ordenador.

Cuestión 4

Utiliza el programa rexec para ejecutar el comando 'cat 1720intf.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 el caso anterior?

Se negocia un tamaño de MSS de 460 bytes (primero 1460 y luego 460).
El tamaño de los segmentos TCP es de 480 bytes (460 de datos y 20 de cabecera).
La diferencia es que ahora hay segmentos de menor tamaño que contienen menos datos.

Cuestión 3

Utilza el programa rexec para ejecutar el comando 'cat 1720intf.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?

TCP no fragmenta los segmentos. No los fragmenta porque TCP ya crea los segmentos respetando el tamaño de su MSS (tamaño máximo de segmentos TCP).
El tamaño máximo de los segmentos TCP es de 1460 una vez que se le han restado los bytes de las cabeceras de IP y TCP de 20 bytes cada una.

Cuestión 2

Rexec.exe Remote Shell es un servicio presente en un S.O.Unix con TCP/IP que atiende al puerto TCP 512 en espera de peticiones de ejecución de comandos desde procesos remotos clientes. Utilza TCP, por lo que trabaja con conexión. Para las prácticas se dispondrá de un proframa para MS Windows (rexec.exe) que actúa como cliente. En una sesión de rexec.exe se pide inicialmenteun nombre de ususario y password en la máquina servidora, y tras introducir estos, se pueden ejecutar comandos UNIX en dicha máquina. Nos servira para estudiar una conexión TCP. Dentro de una máquina UNIX, el cliente es un programa en la línea de comandos con esta sintaxis básica:
rsh
Emplear el programa rexec para ejecutar el comando 'ls -1' en la máquina con dirección 172.20.43.232 (Linux2). Utiliza para ello el usuario "alumnos" y la clave "alumnos". Con el monitor de red, analizar y estudiar la secuencia de paquetes TCP intercambiados en el estableciamiento de la conexión entre la máquina del alumno y la 172.20.43.232. Utilzar para ello el filtro adecuado (direcciones y protocolos).

1. Comprueba las secuencias de conexíon-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).
   
   La estructura de envío de datos - confirmación de datos es similar a la detallada en el guión de prácticas.
   Aquí podemos ver la captura de tramas realizada por el Monitor de Red con la que hemos comprobado esto y la figura 6 de la practica donde se detalla esto.
   
   
   
   
2. Comprueba el valor de los puertos utilizados. Indica su valor.
   
   Puertos:
   
   • PC = 2677
     
   • Servidor = 512
   
   Durante la autentificación, los puertos cambian:
   
   • PC = 3512
     
   • Servidor = 113
   
   Esto último ocurre porque, para realizar la operación comentada, se requieren una serie de puertos que aseguren mayor seguridad que los anteriores.
   
   
3. Analizar los valores de la ventana del receptor. ¿Cuál es más grande?
   
   Las ventanas tienes únicamente dos tamaños: 65535 bytes y 5840 bytes.
   La de mayor tamaño es la 65535 bytes y que además coincide con el máximo posible ya que este campo tiene reservados 2 bytes de tamaño, lo que establece 65536 valores posibles que se mueven en el rango de [0,65535].
   

Cuestión 1

Udp.exe. Este sencillo programa para MS Windows nos permitira enviar y recibir paquetes UDP, especificando tambien su contenido, a un nçumero de puerto y una IP destinos especificados para comprobar el funcionamiento de este protocolo.

1. Utilizar el programa udp.exe para realizar un envío de datos al puerto 7 (echo) o al puerto 13 (hora y dia) del servidor Linux 1 del laboratorio (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).
   
   Hemos mandado el paquete UDP al puerto 7 del servidor Linux 1. Y para ver las tramas en el monitor de red hemos puesto como filtro "ip.addr==10.3.7.0". Una vez puesto el filtro se ve las tramas de petición y respuesta que hemos realizado.
   
   
   
   • Nuestra máquina: puerto 2310
     
   • Servidor: puerto 7
   
   
   
2. Prueba de nuevo Udp.exe, pero enviando un texto mucho mas grande (sobre 2k bytes). Esto se puede hacer copiando parte de algun fichero de texto en la ventana del 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 la imagen podemos ver como el paquete se ha fragmentado en 2 datagramas para la petición y en 6 datagramas para la respuesta.
   
   T1) Flags: 0x01, offset: 0, tamaño 1514
   T2) Flags: 0x00, offset: 1480, tamaño: 987
   T3) Flags: 0x01, offset: 0, tamaño: 514
   T4) Flags: 0x01, offset: 480, tamaño: 514
   T5) Flags: 0x01, offset: 960, tamaño: 514
   T6) Flags: 0x01, offset: 1440, tamaño: 514
   T7) Flags: 0x01, offset: 1920, tamaño: 514
   T8) Flags: 0x00, offset: 2400, tamaño: 67
   

Práctica 3

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

Cuestión 7. Sobre direccionamiento IP y creación de subredes

1. Dada la dirección de clase B 145.65.0.0, se desean 6 subredes. ¿Cuántos bits se tendrán que reservar para crear las subredes? Indica el valor decimal de las subredes, así como el valor de la nueva máscara de subred.
   
   Para crear 6 subredes necesitaremos 3 bits más.
   
   IP = 145.65.0.0 = 10010001.01000001.00000000.00000000
   
   Subredes:
   s1: 10010001.01000001.00000000.00000000 = 145.65.0.0
   s2: 10010001.01000001.00100000.00000000 = 145.65.32.0
   s3: 10010001.01000001.01000000.00000000 = 145.65.64.0
   s4: 10010001.01000001.01100000.00000000 = 145.65.96.0
   s5: 10010001.01000001.10000000.00000000 = 145.65.128.0
   s6: 10010001.01000001.10100000.00000000 = 145.65.160.0
   
   Nueva máscara de subred:
   Ponemos a 1 todos los bits que utilizamos en las direcciones IP, los bits que no usamos los ponemos a 0.
   
   11111111.11111111.11100000.00000000 == 255.255.224.0
   
   
2. 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.
   
   Como queremos ampliar en 2 bits la máscara de subred debemos cambiar a 1 los dos primeros bits de la máscara que tengan valor 0.
   
   IP = 125.145.64.0 = 01111101.10010001.01000000.00000000
   Máscara = 255.255.254.0 = 11111111.11111111.11111110.00000000
   
   Ampliamos la máscara en 2 bits.
   Nueva máscara de subred:
   Máscara = 11111111.11111111.11111111.10000000 = 255.255.255.128
   
   Subredes:
   S1: 01111101.10010001.01000000.00000000 = 125.145.64.0
   S2: 01111101.10010001.01000000.10000000 = 125.145.64.128
   S3: 01111101.10010001.01000001.00000000 = 125.145.65.0
   S4: 01111101.10010001.01000001.10000000 = 125.145.65.128
   
   Rango de direcciones IP:
   
   Rango S1:
   Inicio == 125.145.64.1
   Fin == 125.145.64.126
   
   Rango S2:
   Inicio == 125.145.64.129
   Fin == 125.145.64.254
   
   Rango S3:
   Inicio == 125.145.65.1
   Fin == 125.145.65.126
   
   Rango S4:
   Inicio == 125.145.65.129
   Fin == 125.145.65.254
   
   LA dirección IP final de las subredes S1 y S2, termina en 126 y no en 127 como sería lo lógico ya que con 127 la IP tendría todos sus bytes a 1 y eso sería la dirección de Broadcast. Por eso se pone 126, para que no coincida con la dirección de broadcast.
   

Cuestión 6. Mensaje ICMP "Fragment Reassembly Time Exceeded"

En esta cuestión se analizará el mensaje ICMP tipo 11 código 1. Para ello, se va a intentar "saturar" a una determinada máquina del laboratorio enviándole un número elevado de peticiones Ping. Este elevado número de peticiones puede producir un error si la máquina destino tiene que realizar un reensamblado excesivo de paquetes en un tiempo limitado.
Iniciar el Monitor de Red. A continuación ejecutar el comando "Ping" en varias ventanas de MSDOS, así lograrás mayor número de peticiones:
C:\>ping -n 80 -l 20000 10.3.7.0
Detener la captura y determinar:

1. ¿De qué máquina proceden los mensajes ICMP "Fragment Reassembly Time Exceeded"?
   
   IP: 10.3.7.0
   MAC: 00:07:0e:8c:8c:ff (172.20.43.230)
   
   La direccion MAC se corresponde con la puerta de enlace de la red
   
   
2. ¿Por qué crees que pueden proceder de esta máquina y no de otra?
   
   Procede de esa máquina porque es la encargada de redireccionar los mensajes que mandemos a la red.

Cuestión 5. Mensaje ICMP "Time Exceeded"

Dentro del mensaje ICMP Time Exceeded se analizará el de código 0: Time to Live exceeded in Transit (11/0). En primer lugar, inicia el monitor de red para capturar paquetes IP relacionados con la máquina del alumno y ejecuta el comando:
C:\>ping -i 1 -n 1 10.3.7.0

1. Finaliza la captura e indica que máquina envía el mensaje "ICMP Time to Live exceeded in Transit".... ¿Puedes saber su IP y su MAC?
   
   IP: 172.20.43.230
   MAC: 00:07:0e:8c:8c:ff
   
   Esta dirección corresponde con la máquina que actúa como nuestra puerta de enlace.

Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\>ping -i 2 -n 1 10.3.7.0

2. Finaliza la captura y determina qué máquina envía ahora el mensaje "ICMP Time to Live exceeded in Transit"... Averigua y anota la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina?
   
   IP: 10.4.2.5
   MAC: 00:07:0e:8c:8c:ff
   
   No pertenecen a la misma máquina. La dirección MAC pertenece al router por el cual salimos al exterior de nuestra red y la dirección IP pertenece al siguiente router por el que pasamos debido a que el TTL es 2, por eso el datagrama no avanza mas ya que solo puede dar 2 saltos.

Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\>ping -i 50 -n 1 10.3.7.12

3. 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 de error? ¿En qué subred está ubicada?
   
   Mensaje error
   Tipo: 11
   Codigo: 0
   
   Como la máquina a la que le hemos hecho el ping no existe, el mensaje viaja entre los 2 routers que engloban esa subred hasta que al mensaje se le agote su tiempo de vida (TTL) que en este caso hemos hecho que sea de 50.
   

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:

1. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos...(tipo, código y tamaño)
   
   
   Como se puede ver, hemos capturado 3 tramas. En la primera trama hacemos la petición y enviamos el paquete, en la segunda trama la puerta de enlace nos redirecciona y nos dice por donde debemos mandar nuestro paquete y la tercera trama la maquina a la que le hemos hecho la petición nos devuelve la respuesta.
   Aunque veamos 3 tramas en el monitor de red, en verdad son 4 las tramas que se mueven por la red. La trama que no se ve en el monitor de red es la que va desde la puerta de enlace hasta la máquina destino y donde la puerta de enlace redireciona el paquete que hemos enviado y se lo manda directamente a la máquina destino.
   
   
   
2. ¿Las direcciones MAC e IP de todas las tramas capturadas con el monitor de red hacen referencia al mismo interfaz de red? Indica en qué casos la respuesta es afirmativa y en qué casos la dirección IP especifica un interfaz de redque no se corresponde con el mismo interfaz indicado por la MAC.
   


En la tercera trama, las direcciones IP y MAC no están a la misma interfaz porque las máquinas con esas direcciones no están en la misma red local.


3. ¿Qué máquina o interfaz de red envía el mansaje ICMP Redirect?
   
   Lo manda nuestra puerta de enlace predeterminada con dirección IP 172.20.43.230
   
   
4. ¿Qué dato importante para tu Pc transporta en su interior ese mendaje de Redirect?
   
   El mensaje de Redirect transporta la información del mensaje original que causó el error de redirección.
   
   
   
   
5. Observa los campos "Identifiación", "TTL" y "Checksum" del datagrama que se envió originalmente. A continuación, analiza el contenido del mensaje Redirect. ¿Puedes encontrar la misma informació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?
   
   
   • Datagrama original:
     Identificación: 0x4b7a (19322)
     TTL: 128
     Cheksum: 0x185c [correct]
     
     
   • Datagrama redirect:
     Identificación: 0x4b7a (19322)
     TTL: 127
     Cheksum: 0x185c [incorrect, should be 0xc2ff]
   
   Como podemos observar la información de los 2 datagramas si que es la misma, pero el TTL tiene una unidad menos de valor. Esto se debe a que el mensaje de Redirect al pasar por un router mas que el original, su tiempo de vida disminuye, ya que el "TTL" (tiempo de vida" indica cuantos saltos puede dar un datagrama o lo que es lo mismo, por cuantos routers puede pasar antes de morir.

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 MSWindows, 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 específica. 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:

1. Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen? (indentifica la máquina con la topología del anexo)
   
   
   
   • Trama 1:
     MAC origen: 00:0a:5e:76:ff:89
     IP origen: 172.20.43.220
     MAC destino: 00:07:0e:8c:8c:ff
     IP destino: 10.3.7.0
     
     
   • Trama 2:
     MAC origen: 00:07:0e:8c:8c:ff
     IP origen: 10.4.2.5
     MAC destino: 00:0a:5e:76:ff:89
     IP destino: 172.20.43.220
   
   Como podemos ver la máquina que nos responde no es la misma a la que le hacemos la petición. La dirección que nos manda la trama de respuesta corresponde con uno de los routers cisco del laboratorio por el cual pasa nuestro mensaje.
   
   
2. ¿Qué máquina de la red envía el mensaje ICMP "Fragmentation Needed and Don't Fragment was Set" (3/4)?
   
   Como hemos comentado en el apartado anterior, la maquina que nos responde no es la misma a la que le hemos hecho la petición. Eso se debe a que como no queremos fragmentar el datagrama y el medio al que le hemos hecho la petición es más pequeño que nuestro datagrama, el router en la dirección 10.4.2.5 nos devuelve una trama ICMP donde nos indica que debemos fragmentar el datagrama para poder enviarlo.
   

Cuestión 2. Sobre la fragmentación de datagramas IP (II)

4. ¿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?
   
   Si filtramos solo los paquetes "icmp" solamente vemos 1 fragmento de pedido y otro de respuesta y no 2 de cada como veíamos antes. Esto es debido a que el monitor de red solo reconoce como "icmp" el primer fragmento de cada mensaje ya que este es el que lleva las cabeceras de información.
   
   
5. ¿Para qué se pueden emplear los campos "Identificación", "Flags" y "Fragment Offset" de los datagramas IP?
   
   
   • Identificación: Para marcar de forma única cada datagrama enviado.
     
   • Flags: Informa sobre si hay mas fragmentos del mismo paquete (0x01) o de si es el último (0x00).
     
   • Fragment offset: Sirve para saber donde va cada paquete.
   
   
   
6. A continuacó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 sigiente comando:
   "C:/>ping -n 1 -l 1600 10.3.7.0"
   Indica el número total de datagramas en la red e identifica si son de petición orespuesta.
   
   En este caso nuestro datagrama es de 1600 bytes, pero al ser el medio al que lo mandamos mucho más pequeño, el datagrama se fragmenta es mas partes (4) que cuando atraviesa nuestro medio (2 partes).

DatagramaNº	Protocolo	Dirección	Flags	Frag.offset	Identificación
1	ICMP	petición	0x01	0	25472
2	IP	petición	0x00	1480	25472
3	IP	respuesta	0x00	1440	160
4	IP	respuesta	0x01	960	160
5	IP	respuesta	0x01	480	160
6	ICMP	respuesta	0x01	0	160

Cuestión 2. Sobre la fragmentación de datagramas IP (I)

Empleando el Monitor de Red de la misma forma que en la situación anterior, ejecutar:
C:/>ping -n 1 -l 2000 172.20.43.230 (..la opción -l especifica la cantidad de datos a enviar)

1. 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 estod paquetes (ICMP, IP, HTTP, TCP...)? ¿Qué aparece en la columna "info" del monitor de red?
   
   Aparecen 4 tramas, 2 de pedido y 2 de respuesta. Esto es debido a que el datagrama supera su tamaño máximo de 1500 bytes (con el comando -l hemos hecho un datagrama de 2000 bytes) por eso se ha fragmentado, para poder hacer llegar el mensaje. En cada una de las peticiones la trama de mayor tamaño tiene el protocolo ICMP, esto es debido a que las cabeceras del mensaje se encuentran ahi y reconoce el mensaje como ICMP. En cambio, la otra trama aparece con el protocolo IP debido a que esa trama solo contiene los datos sobrantes que no han cabido en la otra trama.
   
   
2. ¿En cuantos fragmentos se ha "dividido" el datagrama original?
   
   Como hemos comentado en el apartado anterior, el datagrama original de 2000 bytes se ha dividido en 2 fragmentos, una de 1472 bytes y otro de 528.
   
   
3. Analiza la cabecera de cada datagrama IP de los paquetes relacionados con el ping anterior. Observa el campo "identificación", "Flags" y "Fragment Offset" de los datagramas. ¿Qué valor tienen estos campos en los datagramas anteriores? Indica en la columna dirección si son de petición o respuesta. Muestra los datagramas en el orden de aparición del Monitor de Red.

Datagrama Nº	Protocolo	Dirección	Flags	Frag. offset	Identificación
1	ICMP	Petición	0x01	0	21966
2	IP	Petición	0x00	1480	21966
3	ICMP	Respuesta	0x01	0	21966
4	IP	Respuesta	0x00	1480	21966

Cuestión 1. Sobre mensajes ICMP del "Ping"

Inicia el 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. ¿Cuántos y qué tipos de mensajes ICMP aparecen? (Tipo y código)
   
   Para ver solo nuestras tramas, utilizamos el filtro ip.addr==172.20.43.220.
   Aparecen 2 tramas ICMP, una de petición y otra de respuesta. Como podemos ver el mensaje ICMP_request es de Tipo 8, mientras que el mensaje ICMP_reply es de Tipo 0. Además, en ambos casos el código es cero.
   Dependiendo de como sea el mensaje ICMP, el campo Type tendrá un valor distinto.
   
   
   
   
2. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP "Reply" hacen referencia a la misma máquina o interfaz de red?
   
   En este caso si que son la misma ya que estamos mandando la petición a la puerta de enlace de la red (es decir, al router que nos da salida a otra fuera de la del laboratorio) y nos estamos moviendo en la red local del laboratorio. Si el mansaje lo mandaramos fuera de esta red, la dirección MAC no se correspondería con la IP de la máquina a la que hemos mandado el mensaje ya que nosotros recibiríamos la dirección MAC de la puerta de enlace.
   

Práctica 2

Con la segunda práctica de la asignatura vamos a tratar el llamado Protocolo de Mensajes de Control de Internet (ICMP). Este protocolo tiene como finalidad comunicar los mensajes de error que ocurren en la transmisión de datos por medio de una red. Para ello vamos a realizar varios ejercicios relacionados con este protocolo para comprender mejor su funcionamiento.

Cuestión 5. Sobre direccionamiento IP y máscaras de subred (II)

3. Sea una máquina con dirección IP 145.34.23.1 y máscara de subred asociada 255.255.192.0. Determina si los siguientes destinos IP de un datagrama que se envíe a la red serán locales o remotos:
   
   • 145.34.23.9
     
   • 145.21.1.2
     
   • 65.33.123.87
     
   • 145.34.200.34
     
   • 145.34.128.200
   ¿A qué máquina de la red local se enviará la trama Ethernet que transportará al datagrama IP si el destino es remoto?
   
   Para resolver este ejercicio, lo primero que tenemos que hacer es pasar las direcciones IP y la máscara de subred a binario. Una vez hecho esto nos fijamos en la parte de la máscara de subred que valga 1 y la comparamos con nuestra IP quedandonos solo con los bits de la IP que esten en la misma posicion que los bits de la máscara de subred que valgan 1.
   
   Cuando tengamos estos bits, los tendremos que comparar con los mismos bits de las demás IP's y si todos los bits coinciden, la red será local y si no será remota.
   
   Si el destino es remoto, el datagrama se manda a la dirección de la puerta de enlace y esta se encargará de mandarla a su destino.
   
   145.34.23.1 - 10010001001000100001011100000001
   255.255.192.0 - 1111111111111111110000000000000
   
   145.34.23.9
   10010001001000100001011100001001 LOCAL
   
   145.21.1.1
   10010001000101010000000100000010 REMOTO
   
   65.33.123.87
   01000001001000010111101101010111 REMOTO
   
   145.34.200.34
   10010001001000101100100000100010 REMOTO
   
   145.34.128.200
   10010001001000101000000011001000 REMOTO
   

Cuestión 5. Sobre direccionamiento IP y máscaras de subred (I)

1. 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 "PROTOCOL" de cada datagrama?
     
   • Identifica la CLASE de dirección asociada a cada dirección IP fuente o destino.
   
   En la imagen podemos ver las diversas tramas que hemos capturado con el monitor. Hemos remarcado el número de la tramas, la dirección IP de la fuente, la dirección IP destino y el tipo de protocolo. La longitud de la trama habría que buscarla en las opciones de abajo de cada trama.
   
   Para averiguar a que clase pertenece cada IP, si a la clase A (grandes redes), a la clase B (redes medias) o a la clase C (redes pequeñas), tendremos que fijarnos en los 3 primeros dígitos (8 bytes) de cada IP. Si ese número está dentro del rango 0-127, pertenece a la clase A, si está dentro del rango 128-191, pertenece a la clase B y si por el contrario está dentro del rango 192-223, pertenece a la clae C.
   
   
   • Trama 1 (Nº532):
     Longitud de la trama: 48 bytes
     Protocolo TCP
     IP fuente: 209.85.229.139. CLASE C
     IP destino: 172.20.43.220 . CLASE B
     
     
   • Trama 2 (Nº534):
     Longitud de la trama: 831 bytes
     Protocolo HTTP
     IP fuente: 172.20.43.220 . CLASE B
     IP destino: 209.85.229.139. CLASE C
     
     
   • Trama 3 (Nº542):
     Longitud de la trama: 644 bytes
     Protocolo HTTP
     IP fuente: 172.20.43.220. CLASE B
     IP destino: 74.125.6.87 . CLASE A
     
     
   • Trama 1 (Nº543):
     Longitud de la trama: 40 bytes
     Protocolo TCP
     IP fuente: 74.125.6.87 . CLASE A
     IP destino: 172.20.43.220 . CLASE B
   
   
   
2. Empleando el monitor de red, averigua las direcciones IP de los siguientes servidores web, indicando la CLASE de dirección a la que pertenecen (A, B o C).
   
   Una de las formas de averiguar la dirección IP de estos servidores web sería utilizando el monitor de red y capturando las tramas que aparecen cuando accedieramos a esos servicios con nuestro navegador. Entonces solo tendremos que ver a que dirección IP llegan las tramas que salen de nuestra IP o la dirección de las que le llegan.
   
   Otra forma de averiguar la IP y la que hemos seguido, es utilizar la consola para mandar un "ping" a cada una de las direcciones para ver que IP nos responde.
   
   
   • http://ww.ibm.com:
     IP: 129.42.56.216
     CLASE B
     
     
   • http://www.ono.es:
     IP: 62.42.230.18
     CLASE A
     
     
   • http://www.ua.es:
     IP: 193.145.233.8
     CLASE C
     
   
   

Cuestión 4. Sobre el protocolo ARP (II)

2. Ejecuta el comando ping con diferentes direcciones IP de los compañeros asistentes a prácticas. ¿Qué ocurre con la memoria caché de ARP de tu máquina?
   
   Si hacemos ping sobre las direcciones IP de otros ordenadores del laboratorio, estas direcciones se cargan en la memoria caché de ARP.
   
   Como se ve en la imagen hemos cargado en la memoria varias direcciones IP ("172.20.43.218", "172.20.43.210" y "172.20.43.221") utilizando el comando ping.
   
   
3. Borra el contenido de tu caché ARP. A continuación, activa el monitor de red y pide a tus compañeros de aula más cercanos a ti que te envíen comandos ping. Tú no debes enviar ningún comando. Pasados unos segundos...¿Qúe ocurre con tu caché de ARP? ¿Qué tramas de ARP aparecen en la captura del monitor d ered?
   
   Si borramos la tabla de memoria ARP (con el comando arp -d) y luego le hacen ping a mi dirección IP,cuando cargamos la tabla de memoria (con el comando arp -a) vemos que se ha cargado en mi memoria caché de ARP las direcciones que me han hecho un ping. En este caso las direcciones IP son la "172.20.43.219" y "172.20.43.221".
   
   
   En la captura de mi monitor de red se ven las 2 peticiones ARP (pedido y respuesta) que hace cada una de las direcciones IP para averiguar cual es mi máquina y comunicarse con ella.
   
   
   
4. Borra el contenido de tu caché ARP. Ejecutar el comando ping con las sigientes direcciones IP externas a tu red local:
   
   • 172.20.41.241
     
   • 10.3.2.0
     
   • 10.3.7.0
     
   • 10.4.2.5
   ¿Qué ocurre con la memoria caché de ARP en este caso? Especifica cuál es la máquina de tu red local de la que proceden las tramas que transportan los mensajes de respuesta al haber ejecutado el comando ping a los anteriores destinos.
   
   Si le hacemos ping a esas direcciones IP, lo que ocurre en la memoria caché de ARP es que están guardadas las direcciones de los routers por los que debemos pasar para poder acceder a las maquinas externas a nuestra red local a las que perteneces las anteriores direcciones IP. Para llegar a cada una de esas direcciones IP iremos por el camino más rápido, por eso dependiendo de a que punto de la red queramos ir pasaremos por un router u otro.Vemos que para llegar a esas IP debemos pasar por los routers con las siguientes IP: "172.20.43.230", "172.20.43.231" y "172.20.43.232".
   
   
5. 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 vacias.
   
   Como ya se ha dicho anteriormente, en cada red local habrá 2 tramas ARP (pedido y respuesta) por lo que en este ejercicio tendremos 4 tramas ARP en total. También debemos tener en cuenta que la dirección MAC destino de cada una de las tramas ARP de pedido será una dirección MAC 'broadcast'. Esto se hace para ver que máquina responde con la dirección IP con la que queremos comunicarnos.
   
   
   
6. ¿Qué sucedería con el protocolo ARP si, a diferenciade la red representada en la cuestión anterior, tenemos tres segmentos de red y dos routers que los enlazan? En este caso, la máquina con IP 5.1.2.0 realiza un ping a la máquina 5.3.2.0. (Todas las tablas ARP están vacias).
   
   En este caso, como tenemos 3 redes locales tendremos 2 tramas ARP más. Por lo tanto tendremos 6 tramas ARP.
   
   
   

Cuestión 4. Sobre el protocolo ARP (I)

1. Visualiza la dirección MAC e IP de la máquina de ensayos, ejecutando el siguiente comando en una ventana MSDOS:
   "ipconfig/all"
   Anota los valores de IP y MAC que obtienes. Con ellos sabras el direccionamiento IP y MAC de tu PC en la red local.
   
   Como se ve en la imagen nuestra dirección IP y MAC son las sigiuentes:
   
   • IP: "172.20.43.220"
     
   • MAC: "00-0A-5E-76-FF-89"
   
   
   A continuación, activa la captura de tramas en el monitor de red. En la máquina del alumno se lanzarán peticiones 'echo' a traves del comando "ping" a la dirección IP "172.20.43.230", borrando previamente de la tabla ARP local la entrada asocioada a esa dirección IP:
   
   • arp -a (Visualiza la tabla de memoria 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 debes detener la captura y visualizarla. Introduce un filtro para visualizar sólo tramas ARP asociadas a la máquina del alumno...
   
   
   
   • ¿Cuántas tramas Ethernet intervienen en el protocolo ARP?
     
     Solo intervienen 2 tramas Ethernet, la de petición (ARP_request) y la de respuesta (APR_response). También hay que tener en cuenta que este protocolo actúa en red local, es decir, por cada red local que tenga que pasar para llegar a la máquina destino se mandarán 2 tramas más en cada una de las redes.
     
     
     Aquí podemos ver las tramas de petición y respuesta de nuestro PC, así como otras tramas de petición de otros ordenadores del laboratorio.
     
     
   • ¿Cuál es el estado de memoria caché de ARP una vez se ha ejecutado el protocolo ARP para la resolución de una dirección?
     
     Una vez que se ha ejecutado el protocolo ARP, vemos como hay una correspondencia entre la direccion ip, con la cual hemos hecho el ping, y su correspondiente direccion MAC.
     
     
     
     
   • Sin que haya transcurrido mucho tiempo, captura de nuevo tramas captura de nuevo tramas con el monitor de red. Vuelve a ejecutar el comando ping (con la misma IP destino. Paraliza la captura y observa la secuencia de tramas ARP. ¿Aparecen las mismas tramas ARP asociadas con tu máquina?.
     
     Si volvemos a realizar un ping, esta vez no veremos nuestras tramas ya que la direccion IP a la que le hemos hecho el ping ya esta cargada en la memoria virtual, es decir, ya está cargada en la memoria caché del protocolo ARP.
     
   
   

Cuestión 3. Tramas de nivel de enlace (Ethernet)

Analizar la cabezera del nivel de enlace. Para ello, realiza un filtrado para visualizar tramas que procedan de tu máquina.

1. ¿Qué tipo de filtro has empleado?. Indica la dirección MAC de tu máquina.
   
   La dirección MAC es la dirección de nuestra tarjeta de red y sirve para poder identificar las distintas máquinas que hay dentro de una red. Nuestra dirección MAC es 00:0a:5e:76:ff:89.
   
   Como ya hemos hecho en la cuestión anterior para filtrar las tramas que proceden de mi máquina hay que utilizar el siguiente filtro, "eth.src==00:0a:5e:76:ff:89" indicando en este caso que lo que queremos ver son las TRAMAS que proceden de nuestro ordenador. Para ello ponemos en el filtro "eth" en lugar de "ip" y en lugar de poner nuestra dirección IP, hay que poner nuestra dirección MAC.
   
   
2. ¿Con qué otra dirección MAC se comunica la tarjeta de red Ethernet de tu máquina en bastantes ocasiones?¿Sabes identificar el equipo al que pertenece esa otra dirección MAC?
   
   En la imagen podemos ver dos direcciones MAC, nuestra propia dirección MAC (indicada en el apartado anterior) y la dirección MAC con la nos comunicamos. Esta dirección es 00:07:0e:8c:8c:ff que pertenece a uno de los tres routers cisco que hay en el laboratorio de prácticas.
   

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

Para realizar esta cuesstión en primer lugar iniciamos el monitor de red para capturar información y descargamos algún archivo de internet.

1. Calcula el porcentaje de paquetes IP existentes en la captura. (Paquetes IP/Tramas totales*100)
   
   Para este apartado debemos filtrar solo los paquetes IP que son los que nos interesan.
   Como se ve en la captura, tenemos un total de 1696 tramas de las cuales 1642 son tramas IP. Por lo que el porcentaje de tramas IP sera del 96,8%.
   
   
2. Calcula el porcentaje de paquetes IP enviados por el alumno.
   
   En este apartado debemos filtrar con "ip.src==172.20.43.221 && ip" para ver los paquetes que hemos enviado nosotros desde nuestra dirección IP.
   
   Como se ve en la captura solo hemos enviado 565 tramas de las 1696 tramas totales, por lo que si aplicamos el calculo ((565/1696)*100) tenemos que el porcentaje de paquetes IP que hemos enviado es del 33,3%.
   
   
3. Calcula el porcentaje de segmentos TCP recibidos por la maquina del alumno.
   
   En esta ocasión solo nos interesan los paquetes recibidos que contengan el protocolo TCP. Para ello filtramos con "ip.dst==172.20.43.221 && TCP".
   
   Como se ve en la captura, hemos recibido 1079 segmentos TCP de entre todas las tramas totalas. Si ahora hacemos el cálculo ((1079/1696)*100) tenemos que el porcentaje de segmentos TCP recibidos es del 63,6%.
   
   
4. Calcula el porcentaje de paquetes que contengas e protocolo DNS en su interior.
   
   El protocolo DNS (Domain Name System) traduce las direcciones IP y nos da el nombre asociado a esa dirección IP. Nosotros al pedirle permiso al servidor de la eps para conectarnos y podernos descargar ese archivo obtendremos algunas tramas que contengan el DNS de la eps (Escuela Politécnica Superior).
   
   Como podemos ver solo tenemos dos tramas DNS (pedido y respuesta) por loq ue si hacemos el cálculo ((2/1696)*100) obtenemos un porcentaje del 0,12%.
   

Cuestión 1. Iniciación al monitor de red. Visualización general de protocolos en la red

Activa el monitor de red y captura todo tipo de tráfico en la red durante unos segundos. Paraliza la captura y visualiza...

a) Del conjunto de datos adquiridos, filtrar los que estén dirigidos a la máquina del alumno. ¿Cuántas tramas aparecen?

Aplicamos el filtro "ip.dst==172.20.43.221" que hará que solo veamos las tramas dirigidas a nuestra dirección IP.

Como podemos ver nos llegan 383 tramas a nuestro ordenador.

b) Del conjunto de datos adquiridos, filtrar los que procedan de la máquina del alumno. ¿Cuántas tramas visualizas ahora?

Esta vez aplicamos el filtro "ip.src==172.20.43.221" para ver las tramas que manda nuestro ordenador.

Como se puede observar mandamos 365 tramas.

c) Ahora filtra los datos cuyo origen o destino sesa la máquina del alumno. ¿Qué número de tramas se visualizan?¿Es coherente este valor con los resultados anteriores?

Ahora tenemos que filtrar todas las tramas que lleguen y salgan de nuestro ordenador, para ello colocamos el filtro "ip.addr==172.20.43.221".

Ahora tenemos 748 tramas, lo cual es coherente ya que es exactamente la suma de las tramas que salen y de las que llegan de nuestra máquina.

d) A continuación, filtra los datos en los que esté presente el protocolo HTTP. ¿Qué otros protocolos observas en el interior de la trama además del HTTP?

Además del protocolo HTTP, vemos que dentro de la trama también se encuentran los protocolos Internet protocol (IP), Transmision control protocol (TCP) e Hypertext transfer protocol (HTP).

Práctica 1

Con esta práctica intentaremos comprender el funcionamiento básico de una red. Para ello utilizaremos la red local (LAN) del laboratorio y estudiaremos la arquitectura de red TCP/IP.
Durante esta práctica realizaremos cinco ejercicios:

1. Con el primer ejercicio nos iniciaremos en el uso del monitor de red WireShark, con el que podremos ver los paquetes de información que circulan por la red.
   
2. En este ejercicio seguiremos comprobando con el WireShark que protocolos tienen los distintos paquetes de la red.
   
3. En este ejercicio se mirara con más detalle las tramas del nivel de enlace Ethernet.
   
4. En este ejercicio trataremos con más detalle el protocolo ARP, protocolo de gran importancia en la comunición entre máquinas de una red.
   
5. En este ejercicio trataremos el direccionamiento IP y la máscara de subred.
   

Hola Mundo

Hola amigos dentro de poco empezare a subir las cuestiones correspondientes a la Práctica 1 de la asignatura.