Cómo identificar cuellos de botella en la red con traceroute

Un cuello de botella en la red es el punto de una ruta donde empiezan el retardo o la pérdida y ya no desaparecen. Traceroute y mtr pueden encontrarlo, pero la mayor parte de lo que muestran es ruido: routers que responden despacio a las sondas, las descartan o se quedan en silencio, mientras reenvían el tráfico real a la perfección. Esta guía usa trazas reales de nuestros servidores, lanzadas el 7 de octubre de 2026, para mostrar la regla que separa una cosa de la otra, y qué hacer cuando encuentras uno de verdad.

La regla: tiene que durar hasta el destino

Cada línea de una traza es una ida y vuelta independiente, a la que responde un router distinto. Los routers reenvían el tráfico por hardware pero responden a las sondas por software, con baja prioridad, y la mayoría limita cuántas respuestas envía por segundo. Por eso, un salto que parece lento o con pérdidas solo importa si todos los saltos posteriores, hasta el destino, muestran lo mismo. TraceMapper aplica esta misma regla cuando redacta su veredicto sobre una traza: una subida solo cuenta si persiste hasta el destino.

Traza real 1: un 82 % de «pérdida» que no es pérdida

Desde nuestro servidor de Falkenstein, Alemania, hacia un host de prueba de Vultr en Singapur (mtr -rwz -c 60, 60 sondas por salto):

  5. AS1299   hbg-b2-link.ip.twelve99.net                      0.0%    60   11.9  11.7  11.3  12.1   0.2
  6. AS1299   hbg-bb3-link.ip.twelve99.net                    53.3%    60   25.0  25.0  24.7  25.3   0.2
  7. AS1299   ffm-bb1-link.ip.twelve99.net                     0.0%    60   30.2  30.1  29.8  30.5   0.2
  8. AS1299   prs-bb1-link.ip.twelve99.net                     0.0%    60   38.6  38.1  37.7  38.6   0.2
  9. AS1299   mei-b5-link.ip.twelve99.net                      0.0%    60   32.3  32.3  32.0  32.7   0.2
 10. AS1299   sng-b6-link.ip.twelve99.net                      0.0%    60  169.7 178.0 169.5 249.9  16.1
 11. AS1299   sng-b7-link.ip.twelve99.net                      0.0%    60  169.0 169.0 168.0 179.5   2.2
 12. AS1299   sng-b5-link.ip.twelve99.net                     81.7%    60  168.0 190.1 167.6 381.6  64.2
 13. AS1299   constantcompany-ic-379815.ip.twelve99-cust.net   0.0%    60  164.7 165.1 164.7 166.3   0.2
 14. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 15. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 16. AS20473  45.32.98.222.vultrusercontent.com                0.0%    60  172.5 172.3 172.0 172.5   0.1
 17. AS20473  45.32.100.168                                    0.0%    60  164.7 165.5 164.3 175.0   1.8

• El salto 6 pierde el 53 % de las sondas; el salto 7, ninguna. Si los paquetes se perdieran de verdad en el salto 6, todos los saltos posteriores mostrarían también esa pérdida. El router de Hamburgo simplemente raciona sus respuestas.
• El salto 12 pierde el 82 %, con un peor tiempo de 381,6 ms y una desviación estándar de 64,2 ms. El salto inmediatamente siguiente responde a las 60 sondas con una dispersión de 0,2 ms, y el destino también responde a todas. Cifras alarmantes, ningún problema.
• El salto 10 muestra jitter (peor tiempo 249,9 ms, desviación 16,1 ms); el salto 11, casi ninguno. De nuevo son las respuestas del router, no la ruta.
• El salto 9 responde más rápido que el salto 8 (32,3 ms frente a 38,1 ms). La latencia en los saltos intermedios no tiene por qué crecer: cada router se toma su propio tiempo para responder.

Todas las alarmas de esa traza son ruido. El destino, que es a lo que realmente te conectas, respondió al 100 % de las sondas con una media de 165,5 ms.

Traza real 2: una gran subida que es distancia, no un cuello de botella

En la misma traza, el tiempo pasa de 32 ms en el salto 9 a unos 169 ms en los saltos 10 y 11, y se mantiene en ese nivel hasta el destino. Persiste, así que es real. Pero no es un cuello de botella: los nombres de los routers pasan de ciudades europeas (hbg Hamburgo, ffm Fráncfort, prs París) a sng, Singapur. Los 137 ms de más son los cables submarinos entre Europa y Asia; Singapur está a unos 10.000 km de Falkenstein, lo que cuesta al menos 100 ms de ida y vuelta en fibra antes de cualquier enrutamiento.

Una subida que persiste solo es un cuello de botella si es mayor de lo que explica la distancia, o si varía según la hora del día. Compárala con el mínimo: a razón de 1 ms de ida y vuelta por cada 100 km de fibra, aproximadamente, 137 ms en un salto intercontinental es normal; 137 ms entre dos routers de la misma ciudad, no.

Traza real 3: un salto en Londres que responde en 298 ms

Hacia Sídney, desde el mismo servidor y en el mismo minuto:

  6. AS24940  core7.lon.hetzner.com                         0.0%    60   22.2  22.1  21.7  22.4   0.1
  7. AS???    ???                                          100.0    60    0.0   0.0   0.0   0.0   0.0
  8. AS4637   i-1001.ulhc-core03.telstraglobal.net          6.7%    60  299.7 298.8 297.6 302.2   0.8
  9. AS4637   i-1045.paix-core02.telstraglobal.net          0.0%    60  297.6 298.7 297.6 299.6   0.6
 10. AS1221   bundle-ether6.stl-core30.sydney.telstra.net   0.0%    60  346.6 345.7 344.6 346.7   0.6
 ...
 16. AS20473  108.61.212.117.vultrusercontent.com           0.0%    60  341.4 341.2 340.9 341.5   0.1

El salto 6 es Hetzner en Londres, a 22 ms. En el salto 8 toma el relevo Telstra Global (AS4637), también en Londres según RIPE IPmap, que geolocaliza routers, y aun así ese salto responde en 298 ms. Un paquete no puede tardar 276 ms en cruzar Londres. Lo que ocurre es que la respuesta del router vuelve por otra ruta, mucho más larga. Cada tiempo de un traceroute es una ida y vuelta, y el tramo de vuelta es invisible para ti. La subida que importa aquí es la del destino, 341 ms, frente a un mínimo de 162 ms para los 16.220 km hasta Sídney: es la ruta, no el cable, la que duplica la latencia.

Los patrones de un vistazo

Lo que ves	Qué significa	Qué hacer
Pérdida o retardo en un salto, que desaparece en el siguiente	El router raciona o retrasa sus respuestas	Nada
Pérdida o retardo que empieza en el salto N y dura hasta el destino	Un problema real en el salto N o en el enlace justo anterior	Reúne pruebas (más abajo) y comunícalo a la red a la que pertenece el salto N
Una gran subida que persiste y cuadra con la distancia	Propagación: un océano o un continente	Nada, o acerca el servidor a los usuarios
Una gran subida que la distancia no basta para explicar, o una ciudad muy alejada de la línea directa	Un desvío de enrutamiento	Prueba otro proveedor o tránsito, una CDN, o informa del desvío
Retardo que solo aparece en hora punta, a partir de un salto	Congestión: una cola en ese salto	Traza a distintas horas e informa con marcas de tiempo
Asteriscos hasta el final, pero ping responde	El destino ignora ese tipo de sonda	Vuelve a trazar con -I (ICMP) o -T -p 443 (TCP)
Asteriscos desde el salto N hasta el final, y ping no responde	La ruta se corta ahí, o un firewall lo descarta todo	Prueba el puerto del servicio y traza desde otra ubicación
El problema empieza entre los saltos 1 y 3	Tu propia red o tu línea de acceso	Prueba por cable, sin nada más en marcha, y luego llama a tu proveedor

Localizar el salto

• Los nombres de los routers suelen llevar un código de ciudad o de aeropuerto: nbg Núremberg, nyk Nueva York, hbg Hamburgo, ffm Fráncfort, prs París, lon Londres, sng Singapur, tky Tokio. Ejecuta sin -n para verlos.
• Los números de AS (mtr -z) te dicen a qué red pertenece cada salto. En las trazas anteriores: Hetzner AS24940, Arelion AS1299, Telstra Global AS4637, Telstra AS1221, Vultr AS20473. La congestión suele aparecer en el traspaso entre dos de ellas; consulta cómo funcionan los ASN y el enrutamiento BGP.
• Un mapa hace evidentes los desvíos. TraceMapper sitúa cada salto en uno, con su red y su latencia.

Pruebas para que un proveedor actúe

• Un informe mtr -rwzb -c 100 tomado mientras ocurre el problema, y otro tomado cuando todo va bien, para comparar.
• La misma prueba desde otra ubicación. El mismo host de Nueva Jersey respondió a nuestro servidor de Falkenstein en 86,4 ms y al de Gravelines en 71,7 ms, a través de redes distintas: comparar puntos de observación te dice si el problema sigue a tu conexión o al destino.
• Las dos direcciones, si puedes: pide al otro extremo una traza de vuelta hacia ti.
• La fecha, la hora con su zona horaria, tu dirección IP pública y el destino.

Para leer cada columna de esos informes, consulta cómo leer un informe de mtr; para los comandos de cada sistema, el comando traceroute en Windows, Mac y Linux.