Práctica 3 - Ejercicio 1

Vamos a usar un sencillo programa para MS Windows llamado Udp.exe. que 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.


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 basta con que especifiquemos 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, analizamos la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo “hola”. Utilizamos el filtro adecuado en el Monitor de Red (direcciones y protocolos).

Este es el resultado obtenido al enviar la palabra “hola” al puerto 7 y filtrar los paquetes en el monitor de red usando el filtro “ip.addr==10.3.7.0 && udp".
Si ahora enviamos esta misma palabra al puerto 13 lo que obtenemos, filtrando igual que en el caso anterior, es:

b) Probamos de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Para ello copiamos parte de un fichero de texto (2,31KB) en la ventana de udp.exe. ¿Se produce fragmentación IP de los paquetes UDP? Estudiamos las longitudes del paquete UDP y las de los paquetes IP que aparecen. Detallamos los paquetes (fragmentados o no) que observamos en el Monitor (indica el valor del identificador, flags, tamaño, etc…).

Sí se produce fragmentación IP de los paquetes UDP. En la ida enviamos un paquete UDP de 2373 bytes que se fragmenta en 2: el UDP de 1500 y un IP de 913 bytes, que tras sumar nos da 2413 bytes a los que hay que restar 20 bytes de cabecera IP por cada uno de forma que obtenemos los 2373 bytes. En la respuesta sucede los mismo, sólo que tenemos más fragmentos IP, en concreto 4 (3 de 500 y uno de 473 bytes) además del UDP de 500. En total suman 2473 pero si restamos 20 bytes por cada cabecera IP (20*5=100) tendremos los 2373 bytes iniciales.

Introducción Práctica 3

El objetivo de esta práctica es profundizar en el funcionamiento de los protocolos de transporte en la arquitectura de red: TCP y UDP. Pretendemos conocer las características del nivel de transporte así como el formato de las estructuras de datos que viajan en este nivel. Para ello implementaremos una aplicación cliente/servidor que incorpora las funciones más típicas que se le pueden exigir a un nivel de transporte TCP/IP.

Práctica 2 - ANEXO 2: Cuestión Tracert. Rutas de los paquetes en la Red.

En este ejercicio se pretende que descubramos la ruta que siguen los paquetes que desde un nodo origen a un nodo destino con la información proporcionada por la herramienta de trazado de rutas. Debido a las limitaciones que posee el comando tracert o traceroute desde la ubicación del laboratorio, vamos a hacer uso de servidores de rutas externos, desde los que calcularemos la ruta a una nuestra máquina o a cualquier otro nodo mundial.

Accedemos a la web http://tracert.com/trace_exe.html. Desde este sitio podemos lanzar la petición de traza de rutas desde diferentes servidores de la red.

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

Las ciudades que recorren los paquetes son:

Melbourne --> Sidney --> Hong Kong --> Maine (lo coherente sería que fuese California) --> Phoenix --> Hollywood --> Madrid --> Valencia --> Alicante

Son atravesados 15 routers como podemos apreciar en la imagen que muestra el recorrido por los mismos que realizan los paquetes.

• Realizamos una petición de traza desde Rusia hasta la web de www.sony.com. Indicamos la ubicación de los routers por los que pasan los paquetes hasta que llegan al servidor web.
  Para traducir las abreviaturas por los nombres de ciudades o aeropuertos nos ayudamos de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3. Dibujamos en el mapa el camino de los paquetes.
  
  

• Repetimos el ejercicio, pero esta vez solicitamos la conexión con la web del Gobierno federal de Argentina www.argentina.gov.ar desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino? Comparamos los resultados si accedemos desde Paris (Eu.org) al diario www.clarin.com. Dibujamos los caminos.
  
  
  Accediendo al Gobierno Federal de Argentina la ubicación de los routers es la siguiente:

Puesto que hemos tenido problemas a la hora de conocer el nombre de las ciudades en las que se encontraban los routers debido a la poca precisión de las herramientas con las que contábamos para ello, únicamente hemos podido suponer la trayectoria que debían seguir los paquetes hasta llegar a su destino:

París --> España (Galicia) --> Miami --> Buenos Aires

El proveedor de red que se encarga de encaminar los datos en la mayor parte del camino es Telefónica.

Si ahora accedemos al diario Clarín, la ubicación de los routers que se atraviesan hasta llegar allí desde París es:

En este caso, el proveedor de red que se encarga de encaminar los datos en la mayor parte del camino es Cogentco.