Leer un traceroute desde España: rutas, saltos y latencia normal

«Me va con mucho ping» es una queja sin datos. El número que devuelve un test no dice dónde se pierden los milisegundos: puede ser el WiFi de casa, la última milla del operador, el punto donde tu tráfico sale de España o el propio destino. Un traceroute bien hecho reparte esa cifra por tramos, y eso convierte una sensación en un diagnóstico.

Esta guía cubre tres cosas: cuánta latencia es físicamente inevitable desde la Península, cómo capturar una traza que sirva para algo y cómo no caer en los cuatro espejismos clásicos de la herramienta.

El suelo físico: lo que cuesta la distancia

La luz viaja por fibra a unos 200 000 km/s, dos tercios de su velocidad en el vacío, por el índice de refracción del vidrio. Eso son 0,5 ms por cada 100 km en un sentido, es decir 1 ms de ida y vuelta por cada 100 km de fibra. Y la fibra no va en línea recta: sigue carreteras, vías férreas y ductos, así que el recorrido real suele ser entre 1,3 y 1,5 veces la distancia geográfica.

Con esa regla puedes calcular el mínimo absoluto de cualquier ruta antes de medirla. Desde Madrid, aproximando el trazado en 1,4 veces la distancia en línea recta:

• Barcelona, unos 500 km: suelo de unos 7 ms.
• París, unos 1050 km: unos 15 ms.
• Londres, unos 1260 km: unos 18 ms.
• Fráncfort, unos 1420 km: unos 20 ms.
• Ámsterdam, unos 1480 km: unos 21 ms.
• Las Palmas, unos 1780 km por cable submarino: unos 25 ms.
• São Paulo, unos 8400 km: unos 120 ms. Buenos Aires, unos 10 000 km: unos 140 ms. En rutas transatlánticas el factor de trazado depende del cable concreto, así que tómalos como orden de magnitud.

Son suelos, no expectativas. Lo medido siempre es mayor: cada router añade tiempo de proceso y de cola, la ruta rara vez es la más corta y el tramo final dentro del centro de datos también cuenta. Pero el suelo sirve para dos cosas: descartar medidas imposibles —nadie hace Madrid–Fráncfort en 8 ms— y saber cuánto margen queda por optimizar. Si mides 24 ms a Fráncfort, no hay nada que arreglar.

Capturar una traza que sirva

Un traceroute de una sola pasada es casi inútil: tres paquetes por salto no distinguen una pérdida puntual de un problema estructural. Usa una herramienta de traza continua y déjala correr al menos cien ciclos.

1. 1En Linux o macOS, instala mtr (apt install mtr, brew install mtr) y ejecuta sudo mtr -rwbc 100 destino: -r imprime un informe al terminar, -w lo formatea ancho, -b muestra nombre e IP y -c fija el número de ciclos.
2. 2En Windows tienes tracert -d destino para una foto rápida y pathping destino para estadísticas por salto. WinMTR hace el equivalente a mtr.
3. 3Si el resultado se llena de asteriscos, prueba con TCP en lugar de ICMP o UDP: sudo mtr --tcp --port 443 destino, o sudo traceroute -T -p 443 destino en Linux. Muchas redes filtran UDP e ICMP y dejan pasar el 443.
4. 4Antes de mirar nada más, haz ping a tu propio router durante un minuto. Si ahí ya ves decenas de milisegundos con picos, el problema es el WiFi y ninguna traza hacia internet te va a decir nada útil.
5. 5Repite la medida a la hora en que aparece el problema. Una congestión de tarde-noche no existe a las nueve de la mañana.
6. 6Guarda el informe completo, no una captura del último salto: el valor está en la secuencia.

Los cuatro espejismos

• Un salto intermedio lento no es un problema. Ver 180 ms en el salto 6 y 32 ms en el 7 es normal: los routers responden al TTL agotado desde su CPU de control, que trata esos paquetes con la prioridad más baja. Solo cuenta la latencia que se mantiene hasta el final.
• Los asteriscos no son pérdida. Muchos equipos no generan respuesta al TTL agotado o la limitan por tasa. Pérdida real es la que aparece en un salto y en todos los siguientes.
• La ruta de vuelta no se ve. Lo que mides es ida y vuelta, pero la traza solo describe la ida; el retorno puede seguir otro camino por otro operador. Por eso una traza en un solo sentido nunca cierra un diagnóstico entre dos redes.
• MPLS oculta saltos. Dentro de un backbone con MPLS, varios routers pueden aparecer como uno solo o no aparecer, y el número de saltos deja de reflejar la topología real.

Leer los nombres de los saltos

El DNS inverso de los routers de tránsito suele codificar ciudad, tipo de interfaz y velocidad. Abreviaturas y códigos de aeropuerto como mad, bcn, vlc, bio, fra, par, ams o lon sugieren por dónde pasa el paquete; fragmentos como ae12, be100 o 100ge describen la interfaz. Trátalo como una pista, no como una verdad: los nombres se quedan obsoletos y a veces un router llamado par lleva años en otro sitio.

En España conviene tener presente que la interconexión está muy concentrada en Madrid, donde están los principales puntos neutros del país; en Barcelona hay otro punto neutro de ámbito catalán, y poco más fuera de esas dos plazas. Es normal que un paquete que sale de Sevilla o de Bilbao hacia otro operador español pase antes por Madrid, y que una ruta hacia Barcelona suba primero a la capital si tu operador solo intercambia tráfico allí. Ese rodeo añade milisegundos que no dependen ni de tu línea ni de tu configuración.

Aplicarlo a un túnel

Con un túnel activo, la ruta se parte en dos tramos independientes: de ti al nodo, y del nodo al destino. Medir el conjunto sin separarlos es la causa más habitual de conclusiones equivocadas.

1. 1Sin túnel, mtr al destino final. Anota RTT medio y pérdida.
2. 2Con el túnel levantado, mtr a la dirección del nodo. Ese es el coste de llegar al túnel; compáralo con el suelo físico de esa distancia.
3. 3Con el túnel levantado, mtr al destino final.
4. 4Compara: la tercera medida debería parecerse a la segunda más el trayecto del nodo al destino. Si es mucho mayor, el problema está en la salida del nodo, no en tu acceso.
5. 5Si la segunda medida ya está muy por encima del suelo físico, el problema está entre tu operador y el nodo. Ahí sí tiene sentido probar otra ubicación.

Un ejemplo con números redondos: desde Madrid, un nodo en Fráncfort añade unos 20 ms de suelo por pura geografía. Si el destino también está en Alemania, ese rodeo apenas te cuesta nada. Si el destino está en Madrid, pagas el viaje dos veces —ida y vuelta a Alemania— y verás unos 40 ms donde antes había 5. No es un fallo: es la consecuencia de la ruta que has elegido.

Antes de dar por buena cualquier conclusión, descarta que la rareza venga del direccionamiento de tu línea: CGNAT e IPv6 en la fibra española explica por qué la IP de tu router y la que ve internet pueden no coincidir. Y si estás midiendo desde una red ajena, ten en cuenta qué puede estar haciendo ese router con tu tráfico: lo tienes en WiFi que no controlas.

Preguntas frecuentes