Cuestión Tracert. "Rutas de los paquetes en la red (3)"

Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina

http://www.argentina.gov.ar/ desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino? Compara los resultados si accedes desde Paris (Eu.org) al diario http://www.clarin.com/ Dibuja los caminos.

---

Desde http://www.argentina.org.ar/ a Paris (Eu.org). Con proveedor la mayor parte del tiempo Telefonica. (GE5-0-0-0-grtwaseq2.red.telefonica-wholesale.net)
1- París (Francia)
2-París (Francia)
3- París (Francia)
4- París (Francia)
5-París (Francia)
6-París (Francia)
7-Oeste, Galicia (España)
8- Oeste, Galicia (España)
9-Miami (EE.UU)
10-Brasil
11-Argentina
12-Alem, Buenos Aires (Argentina)
13- Alem, Buenos Aires (Argentina)
14-Distrito Federal, Buenos Aires (Argentina)
15- Distrito Federal, Buenos Aires (Argentina)

Puede que algún was que aparece sea de Washington DC!!!

Ahora desde http://www.clarin.com/ hasta Paris para compararlos.
1- París (Francia)
2- París (Francia)
3- París (Francia)
4- París (Francia)
5- Washington DC (EE.UU)
6- Washington DC (EE.UU)
7- Atlanta (EE.UU)
8- Charlotte (EE.UU)
9- Charlotte (EE.UU)
10- Miami (EE.UU)
11- Miami (EE.UU)
12- Miami (EE.UU)
13- Distrito Federal, Buenos Aires (Argentina)
14- Distrito Federal, Buenos Aires (Argentina)
15- Distrito Federal, Buenos Aires (Argentina)

Cuestión Tracert. "Rutas de los paquetes en la red (2)"

Realiza una petición de traza desde Rusia hasta la web de www.sony.com Indica 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 ayúdate de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3

---

Desde Rusia hasta la web de www.sony.com. è IP = 64.37.182.61
1-Novosibirsk (Rusia)
2-Novosibirsk (Rusia)
3-Novosibirsk (Rusia)
4-Novosibirsk (Rusia)
5-Moscow City (Rusia)
6-Frankfurt Am Main (Alemania)
7-Frankfurt Am Main (Alemania)
8-Amsterdam (Holanda)
9-Amsterdam (Holanda)
10-La Guardia, Nueva York (EE.UU)
11-Chicago (EE.UU)
12-San José (EE.UU)
13-San José (EE.UU)
14-Los Ángeles (EE.UU)
15-Los Ángeles (EE.UU)
16-San Diego, California
17-San Diego, California
18-San Diego, California

Cuestión Tracert. "Rutas de los paquetes en la red"

En este ejercicio se pretende que el alumno descubra 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.
Accede 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.

• Realiza 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? ¿Cuantos routers son atravesados por paquetes (aproximadamente)?

---

Para ir de Australia hacia la dirección ww.ua.es:
1-Melbourne (Australia)
2- Melbourne (Australia)
3- Sydney (Australia)
4- Sydney (Australia)
5- Sydney (Australia)
6-(Distrito Central) Hong Kong
7-(Distrito Central) Hong Kong
8-(Distrito Central) Hong Kong
9- Maine (EE.UU)
10-Kansas (EE.UU)
11- Miami (EE.UU)
12- Madrid (España)
13- Valencia (España)
14- Alicante (España)

Para realizar este estudio hemos tenido que utilizar la página: http://www.geoiptool.com

Anexo 2 "Herramientas de rutas de paquetes – Tracert / Traceroute"

Una de las curiosidades más llamativas de la red es saber la ruta que siguen los paquetes o datagramas hasta que llegan a su destino. Por ejemplo, si realizamos una petición de acceso a Japón, los paquetes, salen de Alicante, pasando por Valencia, Madrid, ¿y luego? ¿pasarán por París o Londres … Traceroute es una herramienta de diagnóstico de redes que permite visualizar la ruta de los paquetes que se dirigen desde un equipo a otro. Con esta herramienta se obtiene además una estadística o latencia de red de esos paquetes, lo que viene a ser una estimación de la distancia a la que están los extremos de la comunicación. El comando se denomina traceroute en UNIX y linux, mientras que en Windows recibe el nombre de tracert.

Funcionamiento
El funcionamiento del comando es sencillo. Se basa en un error ICMP TTL excedido en tránsito.
Recordamos de la práctica 2 que el campo TTL sirve para que un paquete no permanezca en la red de forma indefinida (por ejemplo, debido a la existencia en la red de un bucle cerrado en la ruta).

Ejemplo de ejecución del comando “tracert” en Windows:
http://www.google.com "C:\>tracert www.google.com"
Traza a la dirección www.google.com [216.239.59.147]
sobre un máximo de 30 saltos:
1 52 ms 59 ms 59 ms 192.168.153.1
2 55 ms 59 ms 47 ms 210.Red-81-46-52.staticIP.rima-tde.net [81.46.52.210]
3 78 ms 83 ms 83 ms 29.Red-81-46-5.staticIP.rima-tde.net [81.46.5.29]
4 * * * Tiempo de espera agotado para esta solicitud.
5 80 ms 83 ms 83 ms GE4-0-0-0-grtmadrr1.red.telefonica-wholesale.net [213.140.51.9]
6 113 ms 119 ms 107 ms So6-0-0-0-grtlontl1.red.telefonica-wholesale.net [213.140.38.26]
7 197 ms 119 ms 119 ms 195.66.226.125
8 114 ms 131 ms 119 ms 72.14.238.246
9 138 ms 143 ms 143 ms 216.239.49.254
10 138 ms 131 ms 131 ms 216.239.48.158
11 138 ms 131 ms 155 ms 216.239.49.126
12 138 ms 131 ms 143 ms 216.239.59.147

Tracert funciona enviando mensajes ICMP de solicitud de eco con distintos TTL; Traceroute, en cambio, envía mensajes UDP. El campo TTL de la cabecera IP de los paquetes es un número entero que se decrece en cada nodo por el que pasa el paquete. De esta forma, cuando el campo TTL llega al valor 0 ya no se reenviará más, sino que el nodo que lo esté manejando en ese momento lo descartará. Lo que hacen los comandos de traza de rutas es mandar paquetes a la red de forma que el primer paquete posea un valor TTL=1, el segundo un TTL=2, etc. De esta forma, el primer paquete será eliminado en el primer nodo al que llegue (ya que éste nodo decrementará el valor TTL, valiendo cero). Cuando un nodo elimina un paquete, envía al emisor un mensaje de error indicando la incidencia. Tracert usa esta respuesta para averiguar la dirección IP del nodo que desechó el paquete, que será el primer nodo de la red. La segunda vez que se manda un paquete, el TTL vale 2, por lo que pasará el primer nodo y llegará al segundo, donde será descartado, devolviendo de nuevo un mensaje de error. Esto se hace de forma sucesiva hasta que el paquete llega a su destino.

Otras aplicaciones
Existen otras aplicaciones como “VisualRoute” que se basan en Traceroute / Tracert para obtener una información gráfica de la ruta que siguen los paquetes desde el origen hasta su destino. En estos casos, se emplea la información generada por la orden Traceroute / Tracert junto con la información de los nodos obtenida de bases de datos públicas como RIPE (foro colaborativo de redes IP).
En Internet existen una serie de lugares que proporcionan servidores de traceroute, y que nos informan de los resultados de la ejecución de una orden traceroute desde ese host hasta el nuestro u otro que se especifique. A estos servidores se les suelen llamar Looking Glass. Esto es de gran ayuda a la hora de realizar mapas de caminos para los paquetes desde cualquier ubicación del mundo. En el sitio web de traceroute (http://www.traceroute.org) se encuentran recogidos algunos de los sitios web que ofrecen la posibilidad de realizar trazas al sitio que se les indique.

De la información que obtenemos de los programas de rutas hay que tener en cuenta lo siguiente:
* Cada proveedor de red puede tener su propio sistema de código de máquinas.
* Los routers pueden describir en su nombre la topología o infraestructura en la que están ubicados (T1, T3, FDDI, ATM, HSSI, ETH, etc…).
* Los códigos de nombres de los routers suelen tener 3 letras, como el código del aeropuerto más cercano. (Base de datos de código de aeropuertos:

(http://www.airportcitycodes.com/codewisecodes.aspx).
* Los nombres de los routers también pueden incluir la dirección IP, una abreviatura especial, o seguir un código de nombres ya extendido como los que se encuentran en la siguiente web: (http://www.sarangworld.com/TRACEROUTE/showdb-2.php3)

Cuestión 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)?

---

El resultado es el mismo que en el caso anterior.
En el de 150 porque hay mayor tiempo de vida y puede saltar más veces entre los routers.
Hemos introducido 150 porque 220 es excesivo para el router Linux al que enviamos la petición.

Cuestión 5.c

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?

---

Dentro del mensaje de error que es de tipo 11 y código 0 está el mensaje de petición (que tiene tipo 8 y código 0). Se queda con IP: 10.3.2.0 que es la salida de CISCO 2513 ya que se van pasando la información sin éxito (ya que no existe tal IP) de CISCO 2513 a Linux 1.

Cuestión 5.b

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)

---

IP y MAC del mensaje de error:
IP = 10.4.2.5
MAC = 00:07:0e:8c:8c:ff
La MAC es la misma que antes porque es donde queremos dirigirnos:
La IP corresponde a Serial 1 del ruter CISCO 2513

Cuestión 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)

---

Mensaje “ICMP Time t olive exceded in transit”
IP: 172.20.43.230
MAC: 00:07: 0e:8c:8c:ff
Tipo: 11
Código: 0

Código 0. Time to Live exceeded in Transit. Este mensaje ICMP es enviado al origen por un router cuando el valor del campo TTL (Tme to live) en la cabecera IP de un
datagrama toma el valor 0.
Como no hay TTL no envía redirect porque se queda en el Ruter CISCO 1720 que es nuestra puerta de enlace

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

Cuestión 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?

---

Datagrama original:
Identificación: 0x0a7c (2684)
Cheksum: 0x4c5f
TTL: 128

Datagrama Redirect:
Identificación: 0x0a7c (2684)
Cheksum: 0x4d5f
TTL: 127

Como a atravesado un router el TTL decrementa una unidad (de 128 a 127). Cheksum es una suma de control y suma todos los valores del campo de la cabecera. Aquí observamos como varía en una letra.

0x4c5f

0x4d5f

Cuestión 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?

---

Nos avisa de la ruta que deberemos seguir para encontrar el destino que hemos pedido con un menaje de redirección porque la puerta de enlace establecida recibe directamente la petición ping (172.20.43.230). Contiene la misma información solo que con una cabecera distinta y, de hecho, nos aparece como que dentro del mensaje de redirección hay otro ICMP que es la información que hay que transmitir (todos los mensajes de error transportan dentro otro datagrama ICMP que es el causante del error).

Cuestión 4.e

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

---

El router CISCO 1720

Cuestión 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.

---

Cuestión 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?

---

No. Porque la información que se envía desde la maquina Cisco 1720 a la cisco 1601 no se ve porque es interna entre la red del laboratorio y nosotros no podemos verla. Sería el punto 2 del dibujo de la figura 7 de la práctica.

Cuestión 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).

---

1. Suponemos que el PC 1 envía el datagrama IP que tiene como destino el PC 2 al router 1. La decisión de encaminamiento es coherente puesto que el router 1 está definido como puerta de enlace por defecto en esta máquina.
2. El router 1 percibe que la interfaz de salida para el mensaje es la misma por la que se recibió el datagrama procedente del PC 1. Emite el mensaje al PC 2 como si procediera del PC 1, es decir, la dirección IP origen del mensaje es la del PC 1.
3. A su vez, el router 1 emite un error de redirección ICMP hacia el PC 1, informándole que actualice su tabla de encaminamiento y que envíe directamente los próximos datagramas con ese mismo destino al router 2 sin pasar por el router 1.
4. Por último, el destino final (PC 2) responde a través del router 2 al emisor del mensaje original.

Cuestión 4.a

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

---

3 Datagramas que tienen las siguientes características:

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)
Para borrar de la tabla de rutas.
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 debesrepetir 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:

Cuestión 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)

---

La CISCO 2513

Cuestión 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)

---

Están involucradas las IP y MAC de mi máquina que son las siguientes:
IP:172.20.43.205
Mi MAC: 00:0a:5e:76:ff:99

Se envía a 10.3.7.0 pero se queda en 10.4.2.5 porque la subred del CISCO 2513 A Linux 1 tiene un MTU de 500 bytes y yo envio 1000 y lo obligo a que no se pueda fragmentar.
IP: 10.4.2.5MAC: 00:07:0e:8c:8c:ff

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)
Dibujo7
¿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)

Cuestión 2.i

En relación a los datos de la pregunta 2.h. obtenidos del Monitor de Red, contesta:
¿Por qué se observan más fragmentos IP de “vuelta” (respuesta) que de “ida” (petición)?

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.

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?

---

Porque al volver pasa por una red que tiene menor MTU

La subred del laboratorio en la que el número de fragmentos que circulan por el medio es el mismo tanto en la petición como en la respuesta es la 10.4.2.4/30, mientras que la subred en la que no sucede esto es la 10.3.0.0/16

"Se atraviesan 3 subredes"

Cuestión 2.h

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
(antes de contestar debes confirmar que en MSDOS el resultado del ping es correcto: paquetes enviados:1 , paquetes recibidos:1)
Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):

---

Cuestión 2.g

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

---

Al principio vemos que el mensaje se pierde, por lo que continuamos hasta conseguir que lo reciba

Cuestión 2.f

En función de los datos anteriores, indica el valor de la MTU de la red.

---

Para IP, la MTU es de 1500 bytes. La MTU es la cabida máxima de bytes para cada nivel en una red.

Cuestión 2.e

¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?

---

Fragment offset es la máxima cabida de datos en un datagrama IP

Flags

Cuestión 2.d

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

---

Que se ven solamente dos datagramas en de envío y el de respuesta ya que la fragmentación se produce en el nivel IP

Cuestión 1.c

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

---

La cabecera de cada datagrama IP es de 20 bytes.

Puede que aparezcan antes los datagramas con protocolo IP que los ICMP. Esto se debe a un fallo del monitor porque deben llegar antes los ICMP. Además hay una doble petición que también se debe a un fallo en el monitor, por lo que el datagrama 49 y 50 es una replica de los datagramas 47 y 48.

Cuestión 2.b

¿En cuántos fragmentos se ha “dividido” el datagrama original?

---

En 2

Cuestión 2.a

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…)? Sabemos el origen y destino de la petición i respuesta que hemos hecho con el “ping”. ¿qué aparece en la columna ‘info” del Monitor de Red?

---

Empleando: por ejemplo : ip.src == 172.20.43.205 ip.dst == 172.20.43.205 cojo todos los paquetes con mi dirección IP y si no queremos que salgan los nbns añadimos “&&!nbns” como bien se explica en la Práctica 1.

CUESTIÓN 2. Fragmentación de datagramas IP

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)

Cuestión 1.c

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.

---

El tamaño de ICMP es de 32 bytes

Cuestión 1.b

Justifica la procedencia de cada dirección MAC e IP. ¿Crees que las direcciones IP origen y MAC origen del mensaje ICMP “Replay” hacen referencia a la misma máquina o interfaz de red?

---

Si nos fijamos en los dibujos anteriores vemos que en la petición tiene como fuente (src): la dirección IP: 172.20.43.205, con MAC: 00:0a:5e:76:ff:99 y como destino (dst) la dirección IP: 172.20.43.230, con MAC: 00:07:0e:8c:8c:ff. Entonces en la respuesta la fuente y el destino son contrarios lo que corrobora que hace referencia a la misma máquina o interfaz de red.

Cuestión 1.a

¿Cuántos y qué tipos de mensajes ICMP aparecen? (tipo y código)

---

Deberían de aparecer dos mensajes ICMP, uno de petición y otro de respuesta a esta petición, En este caso, debido al monitor y como ya vimos en la práctica pasada aparecen dos mensajes de petición y uno de respuesta. En los dibujos se ve el tipo y código de cada uno de ellos. En los dos de petición que son iguales son de tipo 8 y código 0 y en el mensaje de respuesta es de tipo 0 y código 0. Si nos vamos a la tabla que hay en el enunciado de la práctica sabremos que significa cada valor.
Tipo 8: Solicitud de eco
Tipo 0: Respuesta de eco
Código 0: Red de destino inaccesible