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?
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%
Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!
