¿Qué muestra Traceroute? Cómo leer los resultados

Traceroute parece más seguro de lo que realmente es. El resultado llega como líneas ordenadas y numeradas, pero esas líneas son observaciones de una serie de sondas, no un mapa perfecto de Internet.

Traceroute muestra los saltos de capa 3 que responden entre un origen y un destino, junto con muestras del tiempo de ida y vuelta desde el origen a cada salto. No garantiza que todos los enrutadores sean visibles, ni mide el retraso entre dos saltos vecinos ni prueba la pérdida de paquetes. Una respuesta en blanco puede significar simplemente que un dispositivo decidió no responder a la sonda.

Lo que realmente muestra traceroute

Un traceroute clásico intenta revelar el camino, una respuesta a la vez. Por cada salto visible, puede informar un número de salto, una dirección IP, un nombre de host opcional y una o más muestras de tiempo de ida y vuelta. el modelo de medición de traceroute del IETF los identifica como campos de resultados comunes.

La palabra clave es que responden. Una fila representa una interfaz que respondió a una sonda, no necesariamente un enrutador físico completo y ciertamente no todos los dispositivos que manejaron el tráfico. Dos direcciones en el mismo número de salto pueden ser respondedores alternativos en una ruta con equilibrio de carga. Es posible que una fila faltante todavía esté reenviando paquetes perfectamente.

Por lo tanto, Traceroute se lee mejor como una observación de ruta desde una fuente, en un momento, utilizando un método de sonda. Ejecútelo más tarde, desde un VPN, o desde otra red y el resultado puede cambiar. Ese es un comportamiento de enrutamiento normal, no automáticamente una falla.

El pequeño truco TTL detrás de cada salto

El mecanismo es inteligente. En IPv4, cada paquete reenviado lleva un valor de tiempo de vida, generalmente tratado como un límite de saltos. Un enrutador lo reduce antes de reenviar. Cuando el valor caduca, ese enrutador puede devolver un mensaje de tiempo ICMP excedido en lugar de pasar el paquete hacia adelante.

Traceroute primero envía una o más sondas con TTL 1. Caducan en el primer salto enrutado. El siguiente conjunto usa TTL 2 y puede llegar un salto más. El proceso continúa hasta que el destino responde o la herramienta alcanza su máximo configurado. IPv6 utiliza un campo llamado literalmente Límite de saltos, pero la idea del descubrimiento es similar. Los detalles del protocolo están documentados en RFC 5388 y el especificación IPv6.

La respuesta del destino depende de la implementación. Un trazado tradicional basado en UDP suele terminar cuando el destino informa de que el puerto elegido no es accesible. En Windows, tracert utiliza sondas ICMP Echo y termina cuando el destino responde. También existen variantes basadas en TCP. Por eso dos programas traceroute pueden recorrer la misma ruta básica enviando tipos de sondas distintos.

Cómo leer una línea de salida

Considere una línea típica de Windows con un número de salto, tres tiempos y una dirección. Las columnas son sencillas cuando no se les exige más información de la que pueden ofrecer.

Los tres valores intermedios merecen especial atención: son tres intentos separados. Microsoft los describe como mediciones de ida y vuelta desde su dispositivo hasta ese salto en su documentación tracert. No son tres etapas de un viaje de paquete, y no son un resumen mínimo/promedio/máximo ya preparado.

Un RTT también incluye la ruta de respuesta y el tiempo de procesamiento en el dispositivo que responde. El enrutamiento de Internet puede ser asimétrico, por lo que la respuesta puede regresar por una ruta diferente. RFC 9198 explica por qué esta medición de tiempos ICMP no estima de forma reproducible el retardo de una aplicación. Trate la cifra como una muestra de extremo a extremo entre el origen y quien responde, no como un cronómetro sobre un cable entre dos routers.

Los asteriscos son silencio, no un veredicto

Un asterisco significa que la sonda no recibió una respuesta antes de su tiempo de espera. Eso es todo lo que significa por sí solo. El enrutador puede filtrar ese tipo de sonda, limitar la velocidad de las respuestas ICMP, restar prioridad a las respuestas del plano de control o enviar una respuesta que se pierde en el camino de regreso.

Un asterisco entre dos tiempos medidos significa que una de las tres sondas quedó sin respuesta. Tres asteriscos o "Solicitud agotada" significa que ninguna de las sondas de esa fila respondió a tiempo. Si los saltos posteriores (incluido el destino) aún responden, el seguimiento continuó más allá de ese TTL, por lo que la fila silenciosa no demuestra un error de reenvío. El enrutamiento de rutas múltiples significa que es posible que esas sondas posteriores no hayan seguido exactamente la misma secuencia de respuesta. El propio ejemplo de Microsoft muestra filas con tiempo de espera agotado seguidas de una respuesta de destino exitosa.

Este es un mal diagnóstico común en la lectura de traceroute: tratar cada salto silencioso como una pérdida de paquetes. Reenviar tráfico y responder sondas de diagnóstico son trabajos diferentes. Un enrutador puede realizar lo primero mientras rechaza el segundo.

Para investigar pérdidas reales, realice mediciones repetidas. En Windows, PathPing combina la identificación de la ruta con una serie más prolongada de sondas y calcula estadísticas. Aun así, compare las pérdidas notificadas hacia un router intermedio con las de los saltos posteriores antes de concluir que el tráfico reenviado está afectado.

Cómo no culpar al enrutador equivocado

La pregunta útil no es "¿Qué fila tiene el número más grande?" Es “¿Dónde comienza un cambio y persiste hasta llegar al destino?”

La distancia, la congestión, el Wi-Fi, el enrutamiento VPN, las colas y el comportamiento del respondedor pueden cambiar el RTT. Una sola muestra alta es una pista, no una convicción. Busque un patrón repetido que continúe en saltos posteriores y coincida con el síntoma real del usuario.

Traceroute tampoco mide la capacidad de descarga o carga. Si la queja es «la conexión parece lenta en todas partes», una prueba de velocidad de internet comprueba el rendimiento, la latencia y la fluctuación de forma más directa. Las dos herramientas responden a preguntas diferentes.

Lo que traceroute no puede mostrar de manera confiable

Traceroute ofrece una instantánea de la ruta rápida. Leerlo bien significa saber qué omite esa instantánea.

• Es posible que no revele cada salto de Capa 3; Algunos dispositivos nunca responden a las sondas.
• Normalmente no muestra conmutadores de capa 2 transparentes. Esos dispositivos reenvían tramas sin aparecer como saltos de IP.
• Observa la ruta de sondeo directa, mientras que cada respuesta puede tomar una ruta de retorno diferente.
• Puede probar una de varias rutas de igual costo en lugar de todas las rutas posibles.
• No establece porcentajes estables de pérdida de paquetes a partir de un puñado de sondas.
• No puede probar la ruta que tomará cada flujo de aplicaciones, especialmente cuando los protocolos de sondeo difieren.
• Una dirección IP o un nombre de host no es una lectura exacta de la ubicación física.

Utilice la prueba complementaria que responda a la cuestión pendiente. Si un sitio web responde pero un servicio concreto no, una comprobación de puertos con un alcance bien definido puede comprobar determinados puertos TCP públicos desde el nodo de ClockTools. Si los rangos privados o los límites CIDR dificultan interpretar el trazado, la calculadora de subred IP ayuda a separar las partes de red y host.

Tipos de tracert, traceroute y sonda

En Windows, el comando se llama tracert. macOS, Linux, BSD y muchos equipos de red suelen utilizar traceroute. La salida es similar entre plataformas, pero las sondas predeterminadas pueden variar.

En Windows, tracert envía solicitudes ICMP Echo con valores TTL crecientes. El traceroute tradicional de sistemas tipo Unix suele empezar con UDP, aunque las implementaciones y opciones también pueden utilizar ICMP o TCP. Evite afirmar que «traceroute siempre usa UDP» o «siempre usa ICMP»: lo determinan el programa y el método seleccionado.

Para un trazado rápido en Windows sin resolver nombres de host, utilice tracert /d example.com. En un sistema típico macOS o Linux, empiece con traceroute example.com y consulte el manual del sistema para las opciones de protocolo y tiempo de espera. La opción /d puede acelerar el trazado de Windows al omitir la resolución DNS inversa, pero no oculta las direcciones IP de la salida.

El término tracepath suele referirse a una utilidad relacionada de sistemas tipo Unix con una interfaz y un modelo de privilegios distintos. MTR y WinMTR repiten sondas a lo largo del tiempo. PathPing añade estadísticas repetidas después de descubrir la ruta. Elija según necesite una instantánea rápida o una medición sostenida.

Donde encaja ClockTools

Una página de navegador normal no puede abrir las mismas sondas ICMP, UDP o TCP sin formato que un comando de terminal local. Los entornos limitados del navegador y el tiempo de ejecución de ClockTools Cloudflare Worker no exponen el control TTL de paquetes requerido, por lo que ClockTools no inventa una tabla de saltos.

El diagnóstico Trace Route de ClockTools trabaja dentro de ese límite. El protocolo HTTP y el RTT del cliente describen la etapa del navegador a ClockTools. Una solicitud pública independiente HTTP o HTTPS se ejecuta desde el borde ClockTools hasta el destino e informa la accesibilidad, el estado, el tiempo de respuesta, el tipo de contenido y las redirecciones. Es útil para una verificación rápida del sitio web desde afuera hacia adentro, pero no es la tabla de salto local de su computadora portátil.

En la captura, la llamada 1 señala el aviso de limitación y la 2 los datos de respuesta del destino. El ejemplo utiliza example.com, un dominio público de documentación, no un host privado, y generaliza el código del nodo específico de la solicitud.

Utilice una URL pública que sea de su propiedad, que administre o que tenga permiso para probar. Si el objetivo responde rápidamente desde el borde pero se siente lento en su dispositivo, vale la pena verificar el Wi-Fi local, una ruta ISP, un VPN, la carga del dispositivo o el comportamiento del navegador, pero las dos pruebas también se originan desde diferentes puntos de vista y pueden usar diferentes rutas. Si falla tanto desde el borde como localmente, DNS, el alojamiento, el firewall o la disponibilidad del destino se vuelven más plausibles.

Una secuencia práctica de resolución de problemas

Comience con el síntoma, no con el cajón de herramientas.

• ¿Se puede acceder al sitio web desde fuera de su conexión? Ejecute el diagnóstico de ruta ClockTools y observe el estado, las redirecciones y el tiempo de respuesta.
• ¿Es lenta toda su conexión? Compare el rendimiento, el ping y la fluctuación con una prueba de velocidad de Internet.
• ¿Necesita la vista local salto a salto? Ejecute tracert o traceroute en el dispositivo y la red afectados.
• ¿Un servicio falla mientras el host responde? Verifique solo el puerto TCP público autorizado relevante desde el borde ClockTools.
• ¿Apareció una vez un RTT alto o un tiempo de espera? Repita el rastro. El comportamiento persistente en sentido descendente importa más que una sola fila dramática.
• ¿Está comparando direcciones públicas y privadas? ¿Cuál es mi IP? identifica su dirección pública visible, mientras que la calculadora de subred ayuda con los rangos de redes privadas.

Ese orden evita un error común: utilizar un diagnóstico para responder a todas las preguntas de la red. La accesibilidad, la observación de rutas, la pérdida sostenida, el rendimiento y la disponibilidad del servicio están relacionados, pero no son intercambiables.

Comparta los resultados de traceroute de forma segura

Un seguimiento puede exponer direcciones IP públicas y privadas, nombres de host internos, nombres de proveedores, patrones de sincronización y partes del diseño de una red. Antes de colocar el resultado en un foro, ticket, artículo o captura de pantalla, elimine los detalles que el destinatario no necesita.

Oculte los nombres de dispositivos internos, los usuarios incluidos en nombres de host, las direcciones privadas si la topología no importa y las direcciones públicas si no quiere asociarlas a la publicación. Conserve suficiente estructura para entender el problema: suelen bastar los números de salto, la presencia de tiempos de espera agotados y tiempos representativos.

No suponga que tracert /d anonimiza un trazado. Omite la resolución de nombres, pero sigue mostrando las direcciones IP que responden. Recuerde que una estimación de geolocalización IP no es una ubicación física precisa, aunque puede revelar un proveedor o una región amplia.

La mejor lectura de traceroute es modesta. Le indica qué sondas recibieron respuestas, cuánto tiempo tardaron esos viajes de ida y vuelta y dónde puede comenzar un patrón. Se vuelve realmente útil cuando combina esa evidencia con pruebas repetidas y el síntoma que está tratando de explicar.