Traceroute: que es y como diagnosticar problemas de red │ sys4net

Traceroute (llamado tracert en Windows) es una herramienta de diagnóstico de red que muestra la ruta completa que siguen los paquetes de datos desde tu equipo hasta un servidor de destino, identificando cada router (hop o salto) intermedio y midiendo la latencia en cada uno. Es la herramienta estándar para responder la pregunta "¿en qué punto exacto de internet ocurre el problema de conectividad o latencia?". Mientras que ping solo mide si el destino responde y en cuánto tiempo, traceroute revela toda la cadena de routers intermedios y permite localizar con precisión dónde comienza una degradación o pérdida de conectividad.

Qué es traceroute y cómo funciona internamente

Traceroute fue diseñado por Van Jacobson en 1987 y se ha convertido en una de las herramientas de diagnóstico de red más usadas del mundo. Su funcionamiento se basa en un campo de la cabecera IP llamado TTL (Time To Live), que en el contexto de IP no es tiempo sino un contador de saltos.

El mecanismo del TTL en IP

Cada paquete IP tiene un campo TTL que indica el número máximo de routers que puede atravesar antes de ser descartado. Cada router que recibe el paquete reduce el TTL en 1. Cuando un router recibe un paquete con TTL=1, lo descarta y envía de vuelta al origen un mensaje ICMP "Time Exceeded" informando de que el paquete fue descartado en ese punto. Esto es exactamente lo que traceroute necesita para mapear la ruta.

El proceso de traceroute paso a paso

Cuando ejecutas traceroute sys4net.com, la herramienta envía una serie de paquetes con valores de TTL incrementales:

TTL=1: traceroute envía 3 paquetes con TTL=1. El primer router los descarta y responde con ICMP "Time Exceeded". Traceroute registra la IP del router y la latencia de cada uno de los 3 paquetes.
TTL=2: envía 3 paquetes con TTL=2. El primer router reduce el TTL a 1 y los reenvía; el segundo router los descarta y responde. Traceroute registra el segundo router.
TTL=3, 4, 5...: el proceso continúa hasta que los paquetes llegan al destino final, que responde con ICMP "Echo Reply" (si usa ICMP) o con un mensaje de puerto inalcanzable (si usa UDP).

El resultado es una lista de todos los routers en la ruta, con sus IPs (y nombres si están configurados en el DNS inverso) y las tres mediciones de latencia de cada uno.

Los tres protocolos que puede usar traceroute

Protocolo	Sistema operativo	Puerto destino	Ventajas	Inconvenientes
UDP (por defecto)	Linux, macOS	33434+ (incrementa en cada salto)	Funciona en la mayoría de redes; menos bloqueado que ICMP en algunos firewalls	Algunos firewalls bloquean UDP en puertos altos
ICMP (con -I)	Linux, macOS, Windows (tracert)	Echo Request (como ping)	Más compatible con firewalls y routers; Windows lo usa por defecto	Algunos firewalls corporativos bloquean ICMP
TCP (con -T)	Linux (tcptraceroute)	80 o 443 (configurable)	Atraviesa firewalls que bloquean ICMP y UDP; útil para diagnosticar acceso a servicios específicos	Requiere privilegios de root en Linux; no disponible en todos los sistemas

Cómo usar traceroute: comandos en todos los sistemas operativos

Linux y macOS

# Uso básico:
traceroute sys4net.com
traceroute 195.234.56.78

# Especificar el número máximo de saltos (por defecto 30):
traceroute -m 20 sys4net.com

# Usar ICMP en lugar de UDP (como tracert en Windows):
traceroute -I sys4net.com

# Usar TCP hacia el puerto 80 (para diagnosticar acceso HTTP):
traceroute -T -p 80 sys4net.com
# Requiere privilegios de root o sudo:
sudo traceroute -T -p 443 sys4net.com

# No resolver nombres DNS (más rápido, muestra solo IPs):
traceroute -n sys4net.com

# Especificar el tamaño del paquete (por defecto 60 bytes):
traceroute -l 1480 sys4net.com

# Especificar el número de intentos por salto (por defecto 3):
traceroute -q 5 sys4net.com

# Traceroute con IPv6:
traceroute6 sys4net.com
traceroute -6 sys4net.com

# Especificar la interfaz de red de origen:
traceroute -i eth0 sys4net.com

Windows (tracert)

# Uso básico (en el Símbolo del sistema o PowerShell):
tracert sys4net.com
tracert 195.234.56.78

# No resolver nombres DNS (más rápido):
tracert -d sys4net.com

# Especificar el número máximo de saltos (por defecto 30):
tracert -h 20 sys4net.com

# Especificar el timeout por salto en milisegundos (por defecto 4000ms):
tracert -w 2000 sys4net.com

# Usar IPv6:
tracert -6 sys4net.com

# Guardar la salida en un archivo (útil para enviar al soporte técnico):
tracert sys4net.com > tracert-resultado.txt

Cómo leer la salida de traceroute: guía completa

La salida de traceroute tiene un formato estándar que es importante saber interpretar correctamente. Aquí un ejemplo real con todos los elementos anotados:

traceroute to sys4net.com (195.234.56.78), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)        1.2 ms   0.9 ms   1.0 ms
 2  10.0.0.1                          5.3 ms   5.1 ms   5.4 ms
 3  * * *
 4  1.2.3.4 (ae-2.r02.mad01.es)      12.1 ms  11.9 ms  12.2 ms
 5  5.6.7.8 (core1.mad.proveedor.com) 12.8 ms  12.5 ms  13.1 ms
 6  * * *
 7  195.234.1.1 (borde.sys4net.com)  13.2 ms  13.0 ms  13.1 ms
 8  195.234.56.78 (sys4net.com)      13.5 ms  13.3 ms  13.4 ms

# Formato de cada línea:
# NÚMERO_SALTO  NOMBRE_O_IP (nombre_dns)  LATENCIA_1  LATENCIA_2  LATENCIA_3
#
# Número de salto: posición del router en la ruta (1 = primer router, tu router doméstico)
# Nombre o IP: la identidad del router. Si tiene DNS inverso, muestra el nombre.
# Tres latencias: resultado de los 3 paquetes enviados a ese salto en milisegundos

Interpretación de cada elemento

Lo que ves en la salida	Significado	¿Indica un problema?
Latencias bajas y consistentes (ej: 12.1 ms, 11.9 ms, 12.2 ms)	El router responde con latencia normal y estable. Sin pérdida de paquetes en ese salto.	No
Asteriscos en uno o varios saltos intermedios (* * *)	El router no responde a los paquetes de traceroute por configuración de firewall, pero sí reenvía el tráfico normal de red.	No necesariamente: si el destino final responde, los asteriscos intermedios son solo routers con ICMP desactivado.
Asteriscos en todos los saltos a partir de un punto	El tráfico llega hasta ese punto y no continúa: puede haber un problema de enrutamiento, el servidor está caído, o hay un firewall bloqueando.	Sí: hay un problema de conectividad a partir de ese punto.
Latencia que aumenta bruscamente en un salto específico (ej: de 15ms a 150ms)	Hay congestion o un problema en ese enlace o en el router de ese salto.	Sí, si la latencia alta se mantiene en todos los saltos siguientes.
Latencia alta en un salto pero baja de nuevo en el siguiente	El router aplica prioridad baja a los paquetes ICMP/traceroute mientras gestiona el tráfico real normalmente. La latencia alta es del router, no del enlace.	No: el tráfico real no sufre esa latencia.
Ruta que da muchos saltos más de lo esperado	El tráfico está tomando un camino subóptimo: puede haber un problema de enrutamiento BGP o una ruta alternativa activa por algún fallo.	Posiblemente: compara con rutas anteriores para ver si es nuevo.
Misma IP apareciendo en varios saltos consecutivos	El router está respondiendo pero no reenvía el tráfico: puede indicar un bucle de enrutamiento.	Sí: bucle de enrutamiento.
Nombre DNS que incluye ciudad o país (ej: mad01, lon02, nyc03)	El tráfico pasa por ese punto geográfico. Útil para entender la ruta geográfica de los paquetes.	No (solo informativo)

La diferencia entre latencia en traceroute y latencia real

Una de las interpretaciones más erróneas de traceroute es asumir que la latencia mostrada para cada salto es la latencia que experimenta el tráfico real. No lo es necesariamente, por dos razones importantes:

Los routers priorizan el tráfico de datos sobre ICMP

Los routers tienen unidades de procesamiento dedicadas para el tráfico de datos de alta velocidad (hardware forwarding) y procesadores de control más lentos para el tráfico de gestión como ICMP. Cuando un router genera la respuesta ICMP "Time Exceeded" para traceroute, lo hace desde el procesador de control, que puede estar bajo carga o tener menor prioridad. Resultado: la latencia que muestra traceroute para ese router puede ser más alta que la latencia real del tráfico de datos que atraviesa el router.

# Ejemplo de este fenómeno:
 4  router-congestionado.isp.com   150.3 ms  148.7 ms  149.1 ms  # Alta latencia ICMP
 5  siguiente-router.isp.com        13.2 ms   12.9 ms   13.0 ms  # Latencia normal

# La latencia del salto 4 es 150ms pero el salto 5 es 13ms.
# Esto indica que el router del salto 4 procesa ICMP lentamente
# pero el tráfico de datos lo pasa a 13ms normalmente.
# La latencia "real" del enlace es ~1ms (diferencia entre salto 4 y 5).
# NO hay ningún problema en el salto 4.

La regla de oro para interpretar la latencia en traceroute

La latencia que importa es la del ÚLTIMO salto (el destino final), no la de los intermedios. Los saltos intermedios con latencia alta pero destino final con latencia normal no indican ningún problema. Solo hay un problema de latencia real cuando la latencia del destino final es alta, o cuando la latencia aumenta en un salto y se mantiene alta en todos los saltos posteriores hasta el final.

Casos de diagnóstico real con traceroute

Caso 1: El servidor no responde (destino inalcanzable)

traceroute to servidor-caido.com (203.0.113.1), 30 hops max
 1  192.168.1.1       1.2 ms   0.9 ms   1.0 ms
 2  10.0.0.1          5.1 ms   5.0 ms   5.2 ms
 3  83.34.1.1        12.3 ms  12.1 ms  12.2 ms
 4  * * *
 5  * * *
 6  * * *
...
30  * * *

# Diagnóstico:
# Los primeros saltos responden normalmente (red local e ISP OK).
# A partir del salto 4, todo son asteriscos.
# Posibles causas:
# - El servidor de destino está caído o desconectado.
# - El firewall del servidor bloquea todo el tráfico entrante.
# - Hay un problema de enrutamiento BGP entre los AS (Autonomous Systems).
# - El servidor existe pero no hay ruta de vuelta hacia tu IP (enrutamiento asimétrico).

# Para confirmar si el servidor está caído vs bloqueado:
ping 203.0.113.1             # ¿Responde ICMP?
curl -I https://servidor-caido.com  # ¿Responde HTTP?
# Si nada responde: probablemente el servidor está caído o sin acceso a internet.

Caso 2: Alta latencia a partir de un salto concreto

traceroute to servidor-lento.com (198.51.100.1), 30 hops max
1 192.168.1.1 1.1 ms 0.9 ms 1.0 ms # Router local: OK
2 10.0.0.1 5.2 ms 5.1 ms 5.3 ms # ISP primer salto: OK
3 83.34.1.1 12.4 ms 12.1 ms 12.3 ms # ISP backbone: OK
4 85.23.4.5 85.3 ms 84.9 ms 85.1 ms # PROBLEMA: latencia sube aquí
5 91.2.3.4 86.1 ms 85.8 ms 86.0 ms # Se mantiene alta
6 198.51.100.1 86.5 ms 86.3 ms 86.4 ms # Destino: latencia alta persistente

# Diagnóstico:
# La latencia aumenta bruscamente en el salto 4 y se mantiene alta hasta el destino.
# El problema está en el enlace entre el salto 3 y el salto 4 (o en el router del salto 4).
# Los ~73ms de latencia añadida en el salto 4 pueden indicar:
# - Saturación de ese enlace de red (congestionado)
# - El enlace pasa por una ruta geográfica larga (ej: del salto 3 en Madrid al salto 4 en Frankfurt)
# - Problema en el equipo de routing del salto 4

# Acción:
# Si el salto 4 pertenece a tu ISP: contactar con su soporte técnico con el traceroute.
# Si pertenece al ISP de destino: contactar con el soporte del servidor de destino.
# Si pertenece a un carrier intermedio (ej: Telia, Cogent): no hay acción directa posible.

Caso 3: Los asteriscos intermedios no son un problema

traceroute to sys4net.com (195.234.56.78), 30 hops max
1 192.168.1.1 1.1 ms 0.9 ms 1.0 ms
2 10.0.0.1 5.2 ms 5.1 ms 5.3 ms
3 * * * # Asteriscos: firewall en router 3
4 83.34.1.1 12.4 ms 12.1 ms 12.3 ms
5 * * * # Asteriscos: firewall en router 5
6 * * * # Asteriscos: firewall en router 6
7 195.234.56.78 13.2 ms 13.0 ms 13.1 ms # Destino responde con 13ms

# Diagnóstico:
# Los asteriscos en los saltos 3, 5 y 6 NO son un problema.
# El destino final responde con solo 13ms de latencia.
# Los routers 3, 5 y 6 simplemente tienen configurado que no respondan a ICMP,
# pero sí reenvían el tráfico normalmente.
# TODO ESTÁ BIEN: el sitio web en sys4net.com es accesible con excelente latencia.

Caso 4: Bucle de enrutamiento

traceroute to destino.com (203.0.113.5), 30 hops max
1 192.168.1.1 1.1 ms 0.9 ms 1.0 ms
2 10.0.0.1 5.2 ms 5.1 ms 5.3 ms
3 83.34.1.1 12.4 ms 12.1 ms 12.3 ms
4 91.2.3.4 18.2 ms 18.0 ms 18.1 ms
5 83.34.1.1 12.5 ms 12.3 ms 12.4 ms # Misma IP que el salto 3
6 91.2.3.4 18.3 ms 18.1 ms 18.2 ms # Misma IP que el salto 4
7 83.34.1.1 12.6 ms 12.4 ms 12.5 ms # El bucle continúa
...
30 91.2.3.4 18.5 ms 18.3 ms 18.4 ms

# Diagnóstico:
# Las mismas IPs se repiten cíclicamente: bucle de enrutamiento confirmado.
# Los routers 3 y 4 se están reenviando el tráfico mutuamente en bucle.
# El destino es inalcanzable mientras el bucle persista.
# Causa típica: actualización de tablas de rutas BGP errónea en uno de esos routers.
# Acción: reportar al ISP de los routers afectados; no hay nada que puedas hacer desde tu lado.

MTR: traceroute continuo con estadísticas

MTR (Matt's Traceroute, o My Traceroute en versiones recientes) combina traceroute y ping en una sola herramienta que muestra estadísticas continuas en tiempo real. A diferencia de traceroute que hace una sola medición, MTR envía paquetes continuamente y acumula estadísticas de pérdida de paquetes, latencia mínima, máxima, media y desviación estándar para cada salto.

# Instalar MTR:
# Ubuntu/Debian:
sudo apt install mtr-tiny

# CentOS/AlmaLinux:
sudo dnf install mtr

# macOS con Homebrew:
brew install mtr

# Uso básico de MTR (interfaz interactiva en tiempo real):
mtr sys4net.com

# MTR sin resolución DNS (más rápido):
mtr -n sys4net.com

# MTR con un número fijo de paquetes (no interactivo, útil para informes):
mtr -r -c 100 sys4net.com   # Envía 100 paquetes y muestra el informe final
# -r: modo reporte (no interactivo)
# -c 100: 100 ciclos de paquetes

# MTR usando TCP en el puerto 443 (para diagnosticar acceso HTTPS):
sudo mtr -T -P 443 sys4net.com

# MTR con IPv6:
mtr -6 sys4net.com

# Guardar el informe MTR en un archivo:
mtr -r -c 100 sys4net.com > mtr-informe.txt

# Salida en formato JSON (para procesamiento automatizado):
mtr -r -j sys4net.com

Cómo leer la salida de MTR

My traceroute [v0.95]
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 100 1.2 1.1 0.9 2.1 0.2
2. 10.0.0.1 0.0% 100 5.3 5.2 5.0 6.1 0.2
3. ???
4. ae-2.r02.mad01.es 0.0% 100 12.2 12.1 11.9 13.5 0.3
5. core1.mad.proveedor.com 0.0% 100 12.8 12.6 12.4 14.1 0.4
6. ???
7. 195.234.56.78 0.0% 100 13.5 13.3 13.1 15.2 0.4

# Columnas de MTR:
# Host: IP o nombre DNS del salto
# Loss%: porcentaje de pérdida de paquetes (0.0% = sin pérdida)
# Snt: número total de paquetes enviados a ese salto
# Last: latencia del último paquete en ms
# Avg: latencia media en ms
# Best: latencia mínima observada en ms
# Wrst: latencia máxima observada en ms
# StDev: desviación estándar de la latencia (jitter)

# Los ??? son saltos que no responden (como los asteriscos en traceroute)
# Un Loss% > 0 en saltos intermedios pero 0% en el destino = no hay problema real
# Un Loss% > 0 en el destino final = problema real de pérdida de paquetes

La ventaja de MTR sobre traceroute para identificar pérdida de paquetes

La pérdida de paquetes intermitente es imposible de detectar con un solo traceroute porque traceroute solo envía 3 paquetes por salto. Si hay un 10% de pérdida de paquetes, hay un 73% de probabilidad de que los 3 paquetes pasen sin problema. MTR envía cientos de paquetes y acumula estadísticas reales de pérdida:

# Ejemplo de MTR con pérdida de paquetes detectada:
Host Loss% Snt Last Avg Best Wrst
1. 192.168.1.1 0.0% 200 1.2 1.1 0.9 2.1
2. 10.0.0.1 0.0% 200 5.3 5.2 5.0 6.1
3. 83.34.1.1 0.0% 200 12.2 12.1 11.9 13.5
4. 91.2.3.4 15.0% 200 18.5 18.3 18.1 22.7 # PROBLEMA
5. 198.51.100.1 15.5% 200 18.8 18.6 18.3 23.1 # Se mantiene
6. 195.234.56.78 15.0% 200 19.1 18.9 18.6 23.5 # Hasta el final

# La pérdida del 15% comienza en el salto 4 y se mantiene hasta el destino.
# El problema está en el enlace entre el salto 3 y el salto 4.
# Con un solo traceroute, estos 3 paquetes podrían haber pasado todos sin problema.

Ping: el complemento esencial de traceroute

Ping es más sencillo que traceroute pero complementario: mientras traceroute mapea la ruta, ping mide la latencia y pérdida de paquetes al destino final de forma continua durante un período de tiempo.

# Ping básico (continuo en Linux/macOS, 4 paquetes en Windows):
ping sys4net.com
ping 195.234.56.78

# Especificar el número de paquetes:
ping -c 100 sys4net.com    # Linux/macOS: 100 paquetes
ping -n 100 sys4net.com    # Windows: 100 paquetes

# Ping continuo en Windows (como en Linux):
ping -t sys4net.com        # Windows: continuo hasta Ctrl+C

# Especificar el intervalo entre paquetes (en segundos):
ping -i 0.2 sys4net.com    # Ping cada 200ms (más rápido que el defecto de 1s)

# Ping con paquetes grandes (para detectar problemas de MTU/fragmentación):
ping -s 1400 sys4net.com   # Paquetes de 1400 bytes

# Ping IPv6:
ping6 sys4net.com
ping -6 sys4net.com

# Diagnóstico de pérdida de paquetes con ping extendido:
ping -c 1000 -i 0.1 sys4net.com 2>&1 | tail -5
# Envía 1000 paquetes rápidos y muestra las estadísticas finales

Interpretación de las estadísticas de ping

# Salida típica de ping (Linux):
PING sys4net.com (195.234.56.78) 56(84) bytes of data.
64 bytes from sys4net.com (195.234.56.78): icmp_seq=1 ttl=55 time=13.2 ms
64 bytes from sys4net.com (195.234.56.78): icmp_seq=2 ttl=55 time=13.0 ms
64 bytes from sys4net.com (195.234.56.78): icmp_seq=3 ttl=55 time=13.1 ms
^C
--- sys4net.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.0/13.1/13.2/0.082 ms

# Estadísticas finales:
# 0% packet loss: sin pérdida de paquetes (ideal)
# rtt min/avg/max/mdev:
# min: mejor latencia observada (13.0 ms)
# avg: latencia media (13.1 ms)
# max: peor latencia observada (13.2 ms)
# mdev: desviación estándar / jitter (0.082 ms = muy estable)

# Valores de referencia para latencia:
# < 20 ms: excelente (conexión rápida y cercana geográficamente)
# 20-50 ms: buena (conexión normal dentro del mismo continente)
# 50-100 ms: aceptable (puede haber algo de latencia percibida)
# 100-200 ms: notable (lento, intercontinental o problemas de red)
# > 200 ms: problemático (VoIP y juegos online degradados)

# Un jitter (mdev) alto con latencia media normal indica una conexión inestable:
# Puede causar cortes en VoIP y videollamadas aunque la velocidad sea suficiente.

Herramientas complementarias para diagnóstico de red

pathping (Windows): combinación de tracert y ping

# pathping combina las funcionalidades de tracert y ping en Windows:
# Primero mapea la ruta (como tracert), luego envía paquetes a cada salto durante
# 100 segundos y calcula estadísticas de pérdida y latencia.
pathping sys4net.com
pathping -n sys4net.com    # Sin resolución DNS
pathping -h 20 sys4net.com  # Máximo 20 saltos

ss y netstat: conexiones de red activas

# Ver todas las conexiones TCP activas en el servidor:
ss -tn
ss -tn | grep ESTABLISHED

# Ver los puertos que está escuchando el servidor:
ss -tlnp
ss -tlnp | grep :443   # Solo el puerto 443

# Ver estadísticas de red (útil para detectar retransmisiones):
ss -s                  # Resumen de estadísticas
netstat -s | grep -i "retransmit\|failed"  # Buscar retransmisiones y fallos

iperf3: medir el ancho de banda real

# iperf3 mide el ancho de banda máximo entre dos puntos:
# (Necesita instalarse en ambos extremos)

# En el servidor (modo servidor):
sudo apt install iperf3
iperf3 -s                # Escucha en el puerto 5201 por defecto

# En el cliente (modo cliente):
iperf3 -c servidor.com
iperf3 -c servidor.com -t 30   # Test de 30 segundos
iperf3 -c servidor.com -u      # Test UDP (para medir jitter)
iperf3 -c servidor.com -R      # Test de descarga (inverso)

curl: medir la latencia HTTP desglosada

# curl puede medir el tiempo de cada fase de una conexión HTTP:
curl -o /dev/null -s -w "
DNS lookup:      %{time_namelookup}s
TCP connect:     %{time_connect}s
TLS handshake:   %{time_appconnect}s
Time to first byte: %{time_starttransfer}s
Total:           %{time_total}s
" https://sys4net.com

# Resultado típico:
# DNS lookup:         0.012s   ← Tiempo de resolución DNS
# TCP connect:        0.025s   ← Tiempo de establecer la conexión TCP
# TLS handshake:      0.063s   ← Tiempo del handshake TLS
# Time to first byte: 0.089s   ← Tiempo hasta recibir el primer byte de respuesta
# Total:              0.134s   ← Tiempo total de la solicitud completa

Cómo presentar un traceroute al soporte técnico

Cuando contactas con el soporte técnico de un proveedor de hosting o de tu ISP por un problema de conectividad, un traceroute bien presentado acelera enormemente el diagnóstico. Estas son las buenas prácticas:

Proporciona traceroutes en ambas direcciones (de ti al servidor Y del servidor a ti si tienes acceso SSH al servidor). Los problemas de enrutamiento son frecuentemente asimétricos: la ruta de ida puede ser diferente a la de vuelta.
Incluye la fecha y hora exacta del traceroute: los problemas intermitentes pueden desaparecer entre el momento en que los experimentas y cuando el soporte lo mira.
Proporciona un MTR de 100 ciclos en lugar de un traceroute simple: las estadísticas de pérdida de paquetes dan mucha más información diagnóstica.
Incluye ping extendido (1000 paquetes) para cuantificar la pérdida y el jitter.
Anota qué síntomas experimentas: lentitud en la carga de páginas, desconexiones, imposibilidad de conectar, etc.

# Comando completo para generar un informe de diagnóstico útil para el soporte:
#!/bin/bash
DESTINO="sys4net.com"
FECHA=$(date '+%Y-%m-%d %H:%M:%S')

echo "=== Informe de diagnóstico de red ==="
echo "Fecha: $FECHA"
echo "Destino: $DESTINO"
echo ""
echo "=== Traceroute ==="
traceroute -n $DESTINO
echo ""
echo "=== MTR (100 ciclos) ==="
mtr -r -n -c 100 $DESTINO
echo ""
echo "=== Ping (100 paquetes) ==="
ping -c 100 $DESTINO | tail -5
echo ""
echo "=== DNS ==="
dig +short $DESTINO A
dig +short $DESTINO AAAA

Preguntas frecuentes sobre traceroute

¿Por qué traceroute muestra asteriscos (* * *) en algunos saltos?

Los asteriscos aparecen cuando un router no responde a los paquetes que traceroute usa para identificarlo. Esto puede ocurrir porque el router tiene configurado un firewall que descarta los paquetes ICMP o UDP de traceroute (pero sí reenvía el tráfico normal de datos), porque el router tiene una política de no generar mensajes ICMP "Time Exceeded" para reducir su carga de procesamiento, o porque el router aplica rate limiting a los mensajes ICMP. Los asteriscos en saltos intermedios NO indican necesariamente un problema: si el destino final responde correctamente con buena latencia, los asteriscos intermedios son solo routers que no cooperan con traceroute pero funcionan perfectamente para el tráfico real.

¿Cuál es la diferencia entre traceroute en Linux/macOS y tracert en Windows?

La diferencia principal está en el protocolo que usan por defecto. traceroute en Linux y macOS usa paquetes UDP dirigidos a puertos altos (33434+) por defecto, aunque puede configurarse para usar ICMP con la opción -I. tracert en Windows usa siempre paquetes ICMP Echo Request (como ping). Esta diferencia importa en la práctica porque algunos firewalls bloquean uno u otro protocolo: si traceroute con UDP muestra muchos asteriscos en una ruta que tracert con ICMP muestra completa, es porque hay firewalls que bloquean UDP pero no ICMP en esa ruta. La opción traceroute -I en Linux/macOS produce resultados equivalentes a tracert en Windows.

¿Qué significa que la latencia aumente en un salto y luego baje en el siguiente?

Es el patrón más malinterpretado de traceroute. Cuando la latencia sube bruscamente en un salto (por ejemplo de 15ms a 150ms) pero el siguiente salto vuelve a 16ms, NO hay ningún problema en ese salto. Lo que ocurre es que el router de ese salto procesa los paquetes ICMP de traceroute con baja prioridad (desde su plano de control, más lento) mientras que el tráfico de datos lo procesa con alta prioridad (desde su plano de datos, en hardware). La latencia de 150ms es del procesamiento ICMP del router, no del enlace. El tráfico real sigue fluyendo a 16ms.

¿Puedo usar traceroute para saber si mi servidor tiene problemas de red?

Sí, pero debes hacer traceroute desde fuera hacia tu servidor (no solo desde tu servidor hacia fuera) porque los problemas de red pueden ser asimétricos. Si tienes acceso SSH al servidor, ejecuta traceroute desde el servidor hacia tu IP local o hacia un servidor de referencia conocido. Compara los resultados con traceroute desde tu equipo local hacia el servidor. Si hay pérdida de paquetes en la ruta de ida pero no en la de vuelta (o viceversa), el problema está en un tramo específico de la red. MTR es especialmente útil en este análisis bidireccional.

¿Cuántos saltos (hops) es normal que tenga una ruta en internet?

Una conexión dentro del mismo país suele tener entre 8 y 15 saltos. Una conexión intercontinental (por ejemplo de España a Estados Unidos) puede tener entre 15 y 25 saltos. Más de 25 saltos para cualquier destino es inusual y puede indicar un problema de enrutamiento subóptimo o un bucle parcial. El número de saltos por sí solo no indica latencia: una ruta con 20 saltos bien conectados puede tener menos latencia que una de 10 saltos con un enlace congestionado. Lo que importa es la latencia acumulada hasta el destino final, no el número de saltos.

¿Qué es el jitter y por qué es importante para VoIP y videollamadas?

El jitter es la variación en la latencia de los paquetes: si unos paquetes tardan 15ms y otros tardan 45ms, el jitter es de 30ms. Una latencia alta pero estable (siempre 80ms) es mucho menos problemática para VoIP y videollamadas que una latencia variable (oscilando entre 20ms y 120ms). Los codecs de audio y video de VoIP necesitan que los paquetes lleguen a un ritmo predecible para reproducirlos sin interrupciones. El jitter alto causa cortes, ecos y degradación de audio/video incluso cuando la latencia media parece aceptable. MTR mide el jitter (columna StDev en la salida) para cada salto, lo que lo hace especialmente útil para diagnosticar problemas de VoIP.