Les doy la bienvenida a mi blog sobre la asignatura de Redes de Ordenadores impartida por la Universidad de Alicante.
A su derecha podran pinchar en cada una de las 3 prácticas que se han hecho durante el curso, asi como el tutorial sobre el manejo de Traceroute.
Dentro de cada categoria se han dividido los post por cada sesion de clase.
Un saludo.
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?
Como vemos en la imagen se producen tres intentos de conexion fallidos, ya que la máquina destino no tiene habilitado un servidor FTP.
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.
En UDP:
Se generan 3 paquetes.
El primero de los paquetes tendra esta estructura:
[20 bytes de cabecera IP] – [8 bytes cabecera UDP] – [472 bytes de datos]
El segundo paquete tendra esta estructura:
[20 bytes de cabecera IP] – [480 bytes de datos]
El tercer paquete tendrá esta estructura:
[20 bytes de cabecera IP] – [48 bytes de datos]
En TCP:
Se generan 3 paquetes:
El primero de ellos tendrá la siguiente estructura:
[20 bytes de cabecera IP]-[20 bytes de cabecera TCP]-[460 bytes de datos]
El segundo de ellos tendrá la siguiente estructura:
[20 bytes de cabecera IP]-[20 bytes de cabecera TCP]-[460 bytes de datos]
El tercero de ellos tendrá la siguiente estructura:
[20 bytes de cabecera IP]-[20 bytes de cabecera TCP]-[80 bytes de datos]
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’:
Se generaran uno o varios mensajes ICMP (aunque todos iguales) que provienende la máquina C.
500
Paquetes TCP generados:
1.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[460 bytes de datos]
2.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[460 bytes de datos]
3.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[460 bytes de datos]
4.[20 bytes cabecera IP]-[20 bytes cabecera TCP]-[120 bytes de datos]
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).
Como vemos en la imagen en el monitor de redes aparecen dos mensajes ECHO que contienen en su interior la trama UDP que hemos enviado con el programa udp.exe.
Uno de ellos es dirigido a la máquina 10.3.7.0 con nuestro mensaje “holaaa DA” y el otro es dirigido hacia nuestra propia ip con el mismo mensaje retornado.
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…)
He enviado un fichero de texto de 2kb de longitud. Como vemos el paquete llega a su destino fragmentado en 2 fragmentos, debido a que mi red local es de 1500 MTU.
Sin embargo al devolver mi mensaje a mi máquina llegan 6 mensajes, debido a que la red de destino tiene un MTU de 500. El MTU de la red de destino lo podemos averiguar viendo el offset que se ha incluido al fragmentar los paquetes:
Como es obvio, todos excepto el último (con Offset=2400) tiene flags 0×02(más fragmentos).
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>
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 monitorde red, analizar y estudiar la secuencia de paquetes TCP intercambiados en el establecimiento de la conexión entre la máquina del alumno y la 172.20.43.232. Utilizar para ello el filtro adecuado (direcciones y protocolos).
Comprueba las secuencias de conexión-desconexión TCP. ¿Son similares a las que se
detallan en la figura 6? (Puede que observes que el cliente contesta a una solicitud de SYN
del servidor con un RST. Esto ocurre porque el servidor trata de autentificar al cliente, algo
que no permite el PC).
La estructura de conexion-desconexion del servidor es muy similar a la de la figura 6, al menos en la parte inicial y final, es decir, en lo relativo a la conexion y desconexion.
Comprueba el valor de los puertos utilizados. Indica su valor.
Los puertos utilizados en la conexion son:
512 (Exec)
113 (auth)
138 (netbios-dgm)
Analizar los valores de la ventana de receptor. ¿Cuál es más grande?
Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 172.20.43.232
(Linux2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño. ¿IP ha fragmentado estos segmentos? ¿Por qué ocurre esto? ¿Cuál es el tamaño de los segmentos TCP?
No hay segmentacion IP.
El tamaño de los segmentos TCP es de 60 bytes.
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?
Se negocia un MSS de 460, por lo tanto los segmentos TCP tendran ese tamaño.
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?
¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?
El mensaje ICMP Redirect lo envia a mi máquina el router que tenia por defecto mi tabla de rutas.
¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect? ¿Transporta algún otro tipo de información extra?
Si, aporta informacion para actualizar mi tabla de rutas, en concreto me aporta la IP del router que me lleva hasta el destino por el cual he “preguntado” antes, de tal forma que la próxima vez que intente acceder a ese destino, mi máquina sepa cual es la ruta para llegar hasta él.
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?
En el ICMP del mensaje Redirect aparece otro mensaje ICMP dentro. Dentro de ese mensaje podemos ver, de nuevo, los campos identificacion y cheksum:
El TTL ha pasado de 128 en el mensaje original a 255 en el “redirect”.
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
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 me manda el mensaje 172.20.43.230 que es el router cisco 1720, con direccion MAC 00-07-0e-8c-8c-ff.
Inicia de nuevo la captura y ejecuta a continuación el comando:
C:\> ping –i 2 –n 1 10.3.7.0
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)
Como podemos ver en la imagen ahora la direccion que me manda el mensaje TTL Exceeded es la máquina con direccion IP 10.4.2.5 que corresponde al cisco 2513, la MAC del mensaje de error es 00-07-0e-8c-8c-ff que corresponde al Cisco 1720.
Como vemos las direcciones IP y MAC no coinciden, puesto que son de dos máquinas diferentes, debido a que la IP que ha causado el TTL Exceeded esta fuera de nuestra red local, con lo cual no podemos ver su MAC.
La MAC que recibimos es la que corresponde a nuestro router.
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
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?
Es un mensaje TTL Exceeded. El mensaje se ha enviado a la direccion IP 10.3.7.12 que es una máquina que no existe en nuestra red.
El mensaje llega a la direccion 10.3.7.0 (que si existe), y empieza a buscar la máquina, pero al no encontrarla y gastarse su TTL, devuelve un mensaje de error a mi máquina.
La máquina estaria ubicada en la subred 10.3.7.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)?
La respuesta del ping ha sido mayor en este último caso, aunque el resultado es similar, un TTL Exceeded.
Repite el ejercicio lazando una petición de ping con un mayor número de datos y al destino “.195”:
C:\>ping –n 1 –l 3000 172.20.43.195
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):
| Datagrama Nº | Protocolo | Direccion | Flags | Frag. Offset | Identificacion |
| 101 | ICMP | 172.20.43.195 | 0×02 | 0 | 0xa580 |
| 102 | IP | 172.20.43.195 | 0×02 | 1480 | 0xa580 |
| 103 | IP | 172.20.43.195 | 0×00 | 2960 | 0xa580 |
| 104 | ICMP | 172.20.43.203 | 0×02 | 0 | 0×8093 |
| 105 | IP | 172.20.43.203 | 0×02 | 1480 | 0×8093 |
| 106 | IP | 172.20.43.203 | 0×00 | 2960 | 0×8093 |
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 |
| 468 | ICMP | 10.3.7.0 | 0×02 | 0 | 0xd86e |
| 469 | IP | 10.3.7.0 | 0×00 | 1480 | 0xd86e |
| 498 | ICMP | 172.20.43.203 | 0×02 | 0 | 0×0063 |
| 492 | IP | 172.20.43.203 | 0×02 | 480 | 0×0063 |
| 487 | IP | 172.20.43.203 | 0×02 | 960 | 0×0063 |
| 485 | IP | 172.20.43.203 | 0×00 | 1440 | 0×0063 |
En relación a los datos de la pregunta 2.g. obtenidos del Monitor de Red, contesta:
¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)?
Por que el MTU de la red de destino (10.3.7.0) es menor que el de la red de origen.
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.
En la subred de los PC’s de los alumnos el medio de la red es el mismo.(172.20.43.0)
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?
Se atraviesan 3 subredes.
Dentro del mensaje ICMP Destination Unreachable se analizará el de código 4: Fragmentation Needed and
Don’t Fragment was Set (3/4). En primer lugar ejecuta el comando:
C:\>route delete 10.3.7.0 ( si ya ha sido borrada la ruta, avisa con un error)
¿Porqué ejecutar este comando? En MS Windows, con route se modifican las tablas de encaminamiento de
una máquina. Con la opción delete eliminamos un camino o ruta a la dirección especificada. Al eliminarlo,
borramos también cualquier información asociada a esa dirección, incluida la información sobre errores
previos al acceder a ese destino.
A continuación, poner en marcha el Monitor de Red en modo captura y ejecutar el comando ping:
C:\>ping -n 1 –l 1000 -f 10.3.7.0 (…la opción –f impide la fragmentación de los datagramas en la red)
En base a los paquetes capturados, indicar:
Identifica las direcciones IP/MAC de los paquetes IP involucrados. ¿A qué equipos pertenecen?
(identifica la máquina con la topología del anexo)
| Origen | Destino |
| 172.20.43.203(00-0A-5E-77-08-ED) | 10.3.7.0(00-07-0e-8c-8c-ff) |
| Mi PC | Equipo Linux 1 |
¿Qué máquina de la red envía el mensaje ICMP “Fragmentation Needed and Don’t Fragment was
Set” (3/4)? (identifica la máquina con la topología del anexo)
El mensaje “Fragmentation Needed and Don’t Fragment was Set” se manda desde la direccion 10.4.2.5, que corresponde al router Cisco 2513.
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:
| Datagrama Nº | Tipo y Código ICMP | Tamaño paquete ICMP | Origen IP | Destino IP |
| 252 | Echo Request | 74 bytes | 172.20.43.203 | 10.4.2.1 |
| 253 | Redirect(Redirect for host) | 74 bytes | 172.20.43.203 | 172.20.43.203 |
| 254 | Echo Reply | 74 bytes | 10.4.2.1 | 172.20.43.203 |
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).
[HACER DIBUJO]
¿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?
No, en la explicacion teórica tenemos un Echo’ (2) que tiene que circular desde mi puerta de enlace predeterminada hasta el router que conecte con el destino.
Sin embargo ese datagrama no sera visible por mi pc, debido a que los datagramas que circulen entre 2 routers no son visibles para el resto de la red.
¿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 el mismo interfaz? |
| 252 | Echo Request | 172.20.43.203 – 00:0A:5E:77:08:ED | SI |
| 253 | Redirect(Redirect for host) | 172.20.43.203 -00:07:0e:8c:8c:ff | NO |
| 254 | Echo Reply | 10.40.2.1 – 00:d0:ba:e0:6a:3d | SI |
En esta sesion comenzamos con la práctica 2:
PROTOCOLO DE MENSAJES DE CONTROL DE INTERNET (ICMP)
Justifica la longitud de los paquetes IP. ¿Cuál es el tamaño total del ICMP? ¿Por qué tienen esa longitud?¿Cuántos datos se han transportado en el mensaje “ping”? Dibuja la encapsulación del protocolo ICMP?
La longitud total de la trama es 74 bytes, y su composicion es la siguiente:
14 bytes de la cabecera Ethernet
20 bytes de la cabecera IP
8 bytes de la cabecera ICMP
32 bytes de los datos ICMP
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)
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?
Hay paquetes de diferentes tipos:
TCP, HTTP, ICMP, IP
En la columna “info” de los paquetes IP aparece : Fragmented IP protocol
Se ha dividido en 2 fragmentos
¿En cuantos fragmentos se ha “dividido” el datagrama original?
[HACER TABLA CON LA FIGURA ANTERIOR]
¿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?
Solo visualizas los 2 paquetes ICMP (un request y un reply), esto es asi, por que en realidad solo has efectuado dos peticiones ICMP, aunque se haya tenido que fragmentar para no superar el MTU del protocolo Ethernet.
Para ordenar los datagramas y recuperar su forma original.
En función de los datos anteriores, indica el valor de la MTU de la red.
El fragment offset es de 1480, por lo tanto el MTU tiene que ser 1500, debido a la siguiente operacion:
Cabecera IP (20) + ICMP (Datos + Cabecera, 1480) = 1500.
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?
Aparecen las siguientes tramas
En mi cache ARP aparece la direccion IP de quien me ha enviado el “ping”.
C:>arp -a
Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.201 00-0a-5e-76-8f-6f dinámico
172.20.43.230 00-07-0e-8c-8c-ff dinámico
Localiza los paquetes que tengan el campo de la cabecera IP “TTL” igual a 1. Para ello introducimos el filtro “ip.ttl == 1″
¿Cuántos aparecen? 2
¿Qué aplicación puede haberlos generado?
Determinar los paquetes donde aparece la palabra “abcd”.
En este caso introducimos el siguiente filtro en el Wireshark:
ip contains “abcd”
Estado de la direccion arp.
C:>arp -a
Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.230 00-07-0e-8c-8c-ff dinámico
¿Cuántas tramas intervienen en la resolución ARP? 2 tramas
¿Cuál es el estado de la memoria caché de ARP cuando se ejecuta el protocolo ARP?
C:>arp -a
Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.230 00-07-0e-8c-8c-ff dinámico
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, ya no aparecen tramas ARP nuevas al ejecutar el comando ping.
Ejecuta el comando ping con diferentes direcciones IP de los compañeros asistentes a prácticas. ¿Qué ocurre con la memoria caché de ARP?
Se van añadiendo esas direcciones a la memoria caché de ARP.
C:>arp -a
Interfaz: 172.20.43.203 — 0×2
Dirección IP Dirección física Tipo
172.20.43.210 00-0a-5e-77-00-58 dinámico
172.20.43.214 00-0a-5e-76-fe-4b dinámico
172.20.43.230 00-07-0e-8c-8c-ff dinámico
2490 tramas
4009 tramas
7160 tramas
Si sumamos las tramas destino y origen de los aparatados 1.a y 1.b nos salen 6499 tramas, lo cual es coherente con el resultado del apartado 1.c dado que en el momento de capturar los datos del apartado 1.c habia transcurrido algo más de tiempo con lo cual es lógico que aparezcan algunas tramas más.
Tramas de difusion=1273
Tramas totales=1372
Por lo tanto el porcentaje será el siguiente: 1273/1372*100= 92.78%
Si introducimos el filtro: ip.addr==172.20.43.202 nos salen 158 paquetes.
Por lo tanto el porcentaje de paquetes es 158/1372*100= 11.5%
Nos salen 126 paquetes enviados desde mi máquina, con lo cual el porcentaje total será:
126/1372*100=9.18%
