Analisis de un traceroute a Alemania

Fecha: 8 al 11 de abril del 2020 (durante la cuarentena)

Escenario

Durante la cuarentena intercambiaba mensajes con mi amigo y colega Damián, que vive en Heidelberg (Alemania) para

ver como estaba la situación acá y allá, etc...cuando (salvando las distancias) la manzana me golpeó la cabeza y se me

ocurrió pedirle la IP pública y seguir la traza, lo que me permitió trabajar en este laboratorio y tener algo que estudiar.

Dentro de los datos interesantes que obtuve al realizar esta prueba, fue caer en la cuenta de que estaba utilizando dos cables

(fibras ópticas) submarinas: una para llegar a New York, y otra para cruzar de oeste a este el Altlántico hasta llegar a Alemania.

Esto me llevó a sacar mis libros de QoS para buscar estimaciones de latencia por propagación en un medio físico (ver punto 5.).

También esta prueba me llevó a las clases de CCNA donde explicaba que una traza es engañosa, no siempre vemos por donde

realmente viaja el tráfico sino por donde vuelven los retornos de nuestro paquete “muerto” en tránsito (ver punto 7.).

Recordemos que una traza envía uno o varios paquetes ICMP (solicitud de eco en Windows) o UDP (traceroute Linux) con TTL=1,

luego TTL=2, TTL=3, etc, y cada router decrementa este valor cuando reenvía el paquete al próximo salto, y cada router que recibe

un paquete con TTL=1 debera descartarlo y enviar un mensaje ICMP de tiempo expirado en tránsito, con esto obtenemos la IP de

cada router que nos “mató el paquete”.

1.- Ejecución del traceroute:

La prueba la realicé desde una instalación “seria”, utilizando una conexión de internet “seria” y con una máquina Linux con una

versión UDP de traceroute, aquí sólo vemos los retornos ICMP de tiempo expirado en tránsito.

- En los saltos 6, 13, 16 a 21 representados con * * * podemos suponer que el router “mata” el paquete (por TTL) y no le interesa

o no tiene ordenes de avisarnos.

- En el salto 5 vemos 3 routers que pueden ser balanceadores que envían las tres respuestas de paquete expirado realizando tal

vez balanceo tipo round robin (ver punto 8.)

- En el salto 8 asumo que es el último equipo en Argentina y comienza el viaje por la fibra Sur-Norte, podemos ver la diferencia de

latencia luego de este salto. Tengamos en cuenta que hasta este equipo llegamos desde varios ISP diferentes y entramos también

en un “cuello de botella” de 1.6 Tbps (si, Tera).

- En el salto 9 asumo que por la latencia llega al otro lado de la fibra mas adelante se realiza una estimación grosera de la misma.

- En los saltos 12 a 14 asumo que es el cruce del Atlántico oeste-este y tenemos un salto ciego en el paquete 13.

- En los saltos 14 a 22 ya nos encontramos en Alemania viajando desde Frankfurt a Heidelberg.

root@ernesto:~$ traceroute 176.199.208.104

traceroute to 176.199.208.104 (176.199.208.104), 30 hops max, 60 byte packets

1 192.168.1.1 (192.168.17.1) 0.274 ms 0.286 ms 0.324 ms (mi propio gateway)

2 host237.181-10-139.telecom.net.ar (181.10.139.237) 0.315 ms 0.301 ms 0.309 ms

3 host65.186-108-25.telecom.net.ar (186.108.25.65) 1.284 ms 1.372 ms 1.423 ms

4 host28.181-89-51.telecom.net.ar (181.89.51.28) 0.912 ms 0.815 ms 0.825 ms

5 181.88.66.220 0.963 ms 181.88.66.66 1.088 ms 181.88.66.126 0.801 ms (aquí vemos un posible balanceo de carga, ver en Wireshark

6 * * * que llegan en distinto orden según la latencia)

7 host125.181-89-2.telecom.net.ar (181.89.2.125) 12.152 ms (aquí vemos un posible balanceo de carga)

host63.181-96-120.telecom.net.ar (181.96.120.63) 6.240 ms 4.512 ms

8 ae6.baires5.bai.seabone.net (185.70.203.32) 16.629 ms 16.601 ms 16.619 ms (TI Sparkle Seabone, Las Toninas, Argentina)

9 ae25.ashburn2.ash.seabone.net (195.22.206.87) 181.072 ms (TI Sparkle Seabone, Ashburn, USA)(aquí vemos un posible balanceo de carga

ae26.ashburn2.ash.seabone.net (195.22.206.103) 160.286 ms 156.616 ms ver que es un paquete el primero y dos paquetes el segundo)

10 upc.ashburn2.ash.seabone.net (195.22.206.57) 164.212 ms 153.313 ms 161.325 ms (posible redirect dentro de la misma subred)

11 us-was03a-rd1-ae-11-0.aorta.net (84.116.130.166) 245.578 ms 244.860 ms 250.587 ms (Liberty Global Infrastructure, Washington, DC, USA)

12 us-nyc01b-rd2-ae-5-0.aorta.net (84.116.146.141) 251.676 ms 251.677 ms 248.087 ms (Liberty Global Infrastructure, New York, NY, USA)

13 * * * (cruce Atlántico Oeste-Este)

14 de-fra04d-rc1-ae-56-0.aorta.net (84.116.132.5) 245.928 ms 248.784 ms 248.438 ms (Liberty Global Infrastructure, Frankfurt, Germany)

15 84.116.191.222 (84.116.191.222) 247.836 ms 248.408 ms 248.035 ms (Liberty Global Infrastructure, Frankfurt, Germany)

16 * * *

17 * * *

18 * * *

19 * * *

20 * * *

21 * * *

22 * ip-176-199-208-104.hsi06.unitymediagroup.de (176.199.208.104) 352.484 ms * (Unity Media Group/Vodaphone ,Heidelberg, Germany)

root@ernesto:~$

2.- Análisis con Wireshark

Como se mencionaba antes, en estas capturas vemos el aviso de los paquetes “muertos” en tránsito, que generalmente son tres

por cada salto, para facilitar la lectura diferenciamos el orden de llegada con el número de salto X_Y donde X es el salto e Y el orden

de llegada en inclusive con distintos colores para discriminar mejor. Suerte !

Salto Orden de llegada en Wireshark

| |

#1 1 0.000000000 192.168.1.1 192.168.1.243 ICMP 70 Time-to-live exceeded

2 0.000028449 192.168.1.1 192.168.1.243 ICMP 70 Time-to-live exceeded

3 0.000072869 192.168.1.1 192.168.1.243 ICMP 70 Time-to-live exceeded

#2 4 0.000102245 181.10.139.237 192.168.1.243 ICMP 70 Time-to-live exceeded

5 0.000109497 181.10.139.237 192.168.1.243 ICMP 70 Time-to-live exceeded

6 0.000116825 181.10.139.237 192.168.1.243 ICMP 70 Time-to-live exceeded

#4 7 0.000745658 181.89.51.28 192.168.1.243 ICMP 110 Time-to-live exceeded

8 0.000749346 181.89.51.28 192.168.1.243 ICMP 110 Time-to-live exceeded

9 0.000769074 181.89.51.28 192.168.1.243 ICMP 110 Time-to-live exceeded

#5_1 10 0.000914623 181.88.66.220 192.168.1.243 ICMP 110 Time-to-live exceeded (posible balanceo de carga)

#3 11 0.001098574 186.108.25.65 192.168.1.243 ICMP 70 Time-to-live exceeded

12 0.001193342 186.108.25.65 192.168.1.243 ICMP 70 Time-to-live exceeded

13 0.001250758 186.108.25.65 192.168.1.243 ICMP 70 Time-to-live exceeded

#5_ 3 14 0.001659189 181.88.66.126 192.168.1.243 ICMP 110 Time-to-live exceeded (posible balanceo de carga)

#5_ 2 15 0.001936135 181.88.66.66 192.168.1.243 ICMP 110 Time-to-live exceeded (posible balanceo de carga)

#7_2 16 0.175200212 181.96.120.63 192.168.1.243 ICMP 110 Time-to-live exceeded

#7_3 17 0.176921685 181.96.120.63 192.168.1.243 ICMP 110 Time-to-live exceeded

#7_1 18 0.182826901 181.89.2.125 192.168.1.243 ICMP 110 Time-to-live exceeded

#8 19 0.187302950 185.70.203.32 192.168.1.243 ICMP 70 Time-to-live exceeded (Las Toninas, Argentina)

20 0.187324372 185.70.203.32 192.168.1.243 ICMP 70 Time-to-live exceeded (posible balanceo de carga)

21 0.187327618 185.70.203.32 192.168.1.243 ICMP 70 Time-to-live exceeded |

#9_1 22 0.351786319 195.22.206.87 192.168.1.243 ICMP 70 Time-to-live exceeded (Ashburn, VA, USA, primer paquete)

#10 23 0.369515565 195.22.206.57 192.168.1.243 ICMP 70 Time-to-live exceeded

#9_2 24 0.372804244 195.22.206.103 192.168.1.243 ICMP 70 Time-to-live exceeded (Ashburn, VA, USA, segundo paquete)

#9_3 25 0.376463801 195.22.206.103 192.168.1.243 ICMP 70 Time-to-live exceeded (Ashburn, VA, USA, tercer paquete)

#10 26 0.377533594 195.22.206.57 192.168.1.243 ICMP 70 Time-to-live exceeded

#10 27 0.380407233 195.22.206.57 192.168.1.243 ICMP 70 Time-to-live exceeded

#11_1 28 0.461108171 84.116.130.166 192.168.1.243 ICMP 182 Time-to-live exceeded

#11_2 29 0.461793273 84.116.130.166 192.168.1.243 ICMP 182 Time-to-live exceeded

#12_1 30 0.464359567 84.116.146.141 192.168.1.243 ICMP 182 Time-to-live exceeded (New York, USA, primer paquete)

#11_3 31 0.466841908 84.116.130.166 192.168.1.243 ICMP 182 Time-to-live exceeded

#12_2 32 0.467935240 84.116.146.141 192.168.1.243 ICMP 182 Time-to-live exceeded (New York, USA, segundo paquete)

#12_3 33 0.467942766 84.116.146.141 192.168.1.243 ICMP 182 Time-to-live exceeded (New York, USA, tercer paquete)

#14 34 0.618793842 84.116.132.5 192.168.1.243 ICMP 182 Time-to-live exceeded (posiblemente Frankfurt, Germany)

35 0.625308164 84.116.132.5 192.168.1.243 ICMP 182 Time-to-live exceeded

36 0.626032212 84.116.132.5 192.168.1.243 ICMP 182 Time-to-live exceeded

#15 37 0.628275096 84.116.191.222 192.168.1.243 ICMP 182 Time-to-live exceeded (posiblemente Frankfurt, Germany)

38 0.709633050 84.116.191.222 192.168.1.243 ICMP 182 Time-to-live exceeded

39 0.709925777 84.116.191.222 192.168.1.243 ICMP 182 Time-to-live exceeded

#22 40 6.073930196 176.199.208.104 192.168.1.243 ICMP 102 Port unreachable (Heidelberg, Germany)

|

En este último salto vemos que el mensaje ICMP es diferente, ya que es el target y no soporta el traceroute vía UDP.

3.- Detalle de los paquetes involucrados en la fibra sur-norte:

El paquete 1 está como referencia de tiempo, el último salto en Argentina es el 2, los paquetes 3 y 4 ya son equipos en USA.

4.- Detalle de los paquetes involucrados en la fibra oeste-este:

El paquete 1 está como referencia de tiempo, el 2 es el salto en NYC y el 3 en Frankfurt, aunque hubo un salto ciego entre ambos.

5.- Estimación de la longitud de la fibra submarina:

Basado en el libro Cisco QoS Exam Certification Guide, entre los paquetes 10 y 11 vemos una diiferencia de latencia de 170 mseg,

lo que podria llevar a hacer el siguiente cálculo (insisto que grosero) de la estimación de km de fibra recorrido entre Argentina y USA.

No podemos hacer la misma estimación entre USA y Europa ya que tenemos ciertos saltos “ciegos” como el salto 13.

Pero también deberíamos tener en cuenta los siguientes factores:

- Serialization delay (fixed) (el tiempo que demora en convertirse paralelo/serie o serie/paralelo)

- Propagation delay (fixed) (el largo de la fibra siempre es el mismo)

- Queuing delay (variable) (depende del volúmen de tráfico)

- Forwarding/processing delay (variable) (depende del volúmen de tráfico)

- Shaping delay (variable) (depende del volúmen de tráfico)

- Network delay (variable) (depende del volúmen de tráfico)

6.- Detalle de la fibra Sparkle Seabone:

Este tramo de fibra es entre Las Toninas (Buenos Aires) y Ashburn (cerca de Washington), con escalas en Brasil

y Puerto Rico, pueden llegar a ser bifurcaciónes en layer 1 (una cruzada) o 2 (switching), es difícil de determinar.

Fuente: https://www.tisparkle.com/

7.- Como una traza puede llegar a ser “engañosa”:

El primer caso es el ideal, los routers que nos matan el paquete nos avisan por el mismo camino donde llegó:

C:\>tracert 84.0.0.1

Traza a la dirección 84.0.0.1 sobre un máximo de 30 saltos:

1 11 ms 9 ms 8 ms 180.0.0.1 (TTL 64)

2 17 ms 14 ms 15 ms 200.0.0.1 (TTL 63)

3 18 ms 20 ms 16 ms 200.69.0.1 (TTL 62)

4 20 ms 21 ms 19 ms 84.60.0.1 (TTL 61)

El segundo caso, el router del segundo salto recibe nuestro paquete, lo mata y avisa por ICMP, pero tiene

una mejor métrica para llegar a nuestra red a través del router inferior y utiliza la interface 190.0.0.1 que es

la mas cercana (en métrica) al destino (red A):

C:\>tracert 84.0.0.1

Traza a la dirección 84.0.0.1 sobre un máximo de 30 saltos:

1 11 ms 9 ms 8 ms 180.0.0.1 (TTL 64)

2 17 ms 14 ms 15 ms 190.0.0.1 (TTL 62) (vemos hay un TTL de menos porque pasan por el router inferior)

3 18 ms 20 ms 16 ms 200.69.0.1 (TTL 61)

4 20 ms 21 ms 19 ms 84.60.0.1 (TTL 60)

El segundo caso, tanto el router del segundo salto como el del tercer salto reciben nuestro paquete, lo matan

y avisan por ICMP, pero tienen una mejor métrica para llegar a nuestra red a través del router inferior y utilizan

la interface 190.0.0.1 y 200.45.0.1 que son las mas cercanas (en métrica) al destino (red A):

C:\>tracert 84.0.0.1

Traza a la dirección 84.0.0.1 sobre un máximo de 30 saltos:

1 11 ms 9 ms 8 ms 180.0.0.1 (TTL 64)

2 17 ms 14 ms 15 ms 190.0.0.1 (TTL 62) (vemos hay un TTL de menos porque pasan por el router inferior)

3 18 ms 20 ms 16 ms 200.45.0.1 (TTL 62) (aquí el TTL es el esperado)

4 20 ms 21 ms 19 ms 84.60.0.1 (TTL 61) (aquí el TTL es el esperado)

8.- Acerca de los supuestos balanceadores:

Posiblemente exista un balanceo de carga tipo round-robin, o balanceo por paquete, o sea un paquete por cada

enlace, y las respuestas nos lleguen a destiempo, tal como lo indica la siguiente figura.

Puede que en el router de la derecha los paquetes lleguen por ambos enlaces pero se respondan por sólo uno,

esto podria ser balanceo por destino, que es un determinado destino siempre se alcanza por un mismo enlace.

Los paquetes se pintaron de diferentes colores para distinguirse unos de otros.

9.- Detalle del redirect en los saltos 9 y 10:

Cuando analizamos la traza determinamos lo siguiente:

9 ae25.ashburn2.ash.seabone.net (195.22.206.87) 181.072 ms (TI Sparkle Seabone, Ashburn, USA)(aquí vemos un posible balanceo de carga

ae26.ashburn2.ash.seabone.net (195.22.206.103) 160.286 ms 156.616 ms ver que es un paquete el primero y dos paquetes el segundo)

10 upc.ashburn2.ash.seabone.net (195.22.206.57) 164.212 ms 153.313 ms 161.325 ms (posible redirect dentro de la misma subred)

Podemos observar que todos los equipos supuestamente están en la misma subred tratándose de una dirección clase C:

195.22.206.87

195.22.206.103

195.22.206.57

Entonces podemos verificar con un ping con TTL 14 (salto 9) a estas tres IP, y si el salto 10 está en la misma subred se trata de un redirect.

Lo curioso es que si bien lo alcanzamos con el mismo valor TTL, es diferente el valor durante la respuesta del salto 10 (TTL 54 contra TTL 51)

por lo que su tabla de enrutamiento para alcanzar nuestra IP (y por lo tanto la red) de origen es diferente a los equipos del salto 9.

root@ernesto:~$ ping 195.22.206.87 -t 14

PING 195.22.206.87 (195.22.206.87) 56(84) bytes of data.

64 bytes from 195.22.206.87: icmp_seq=1 ttl=54 time=160 ms

64 bytes from 195.22.206.87: icmp_seq=2 ttl=54 time=160 ms

64 bytes from 195.22.206.87: icmp_seq=3 ttl=54 time=160 ms

root@ernesto:~$ ping 195.22.206.103 -t 14

PING 195.22.206.103 (195.22.206.103) 56(84) bytes of data.

64 bytes from 195.22.206.103: icmp_seq=1 ttl=54 time=159 ms

64 bytes from 195.22.206.103: icmp_seq=2 ttl=54 time=159 ms

64 bytes from 195.22.206.103: icmp_seq=3 ttl=54 time=159 ms

root@ernesto:~$ ping 195.22.206.57 -t 14

PING 195.22.206.57 (195.22.206.57) 56(84) bytes of data.

64 bytes from 195.22.206.57: icmp_seq=1 ttl=51 time=161 ms

64 bytes from 195.22.206.57: icmp_seq=2 ttl=51 time=162 ms

64 bytes from 195.22.206.57: icmp_seq=3 ttl=51 time=161 ms

10.- Material utilizado para entender todo esto:

Sobre la historia de los cables submarinos Sobre como se propaga el tráfico en grandes distancias.

y el nodo de internet en Frankfurt.

Net Matters, 30 stories from telegraph cables to data glasses Cisco QOS Exam Certification Guide, 2nd Edition

ISBN: 978-3-89809-144-2 ISBN-10: 1-58720-124-0

Casi todos los caminos conducen a Frankfurt, el core de internet

en Frankfurt en 2006, del libro Net Matters.

(2020) Your route is my route

Rosario, Argentina