Esta guía le enseñará a usar MTR (My Traceroute) y Traceroute para diagnosticar problemas de conectividad de red, identificar puntos de latencia y analizar la calidad de su conexión.
📋 Requisitos previos
- Un servidor VPS con acceso root o sudo
- Una conexión SSH activa
- Ubuntu/Debian (los comandos están adaptados a estas distribuciones)
🔧 Instalación
Instalar Traceroute (herramienta básica)
Bash# On Ubuntu/Debian sudo apt update sudo apt install traceroute -y
Instalar MTR (herramienta avanzada)
MTR combina las funcionalidades de ping y traceroute en una sola herramienta potente.
Bash# On Ubuntu/Debian sudo apt update sudo apt install mtr-tiny -y # For the full version with graphical interface (optional) sudo apt install mtr -y
Verificar la instalación
Bash# Verify that traceroute is installed traceroute --version # Verify that MTR is installed mtr --version
🛠️ Uso de Traceroute
Comando básico
Bash# Traceroute to a destination traceroute google.com # Traceroute to an IP traceroute 8.8.8.8 # Limit the number of hops (default 30) traceroute -m 20 google.com # Specify timeout in seconds traceroute -w 5 google.com
Opciones útiles
Bash# Use UDP (default) traceroute -U google.com # Use TCP (more reliable) traceroute -T google.com # Use ICMP (like ping) traceroute -I google.com # Don't resolve DNS names (faster) traceroute -n google.com
Ejemplo de salida
traceroute to google.com (142.250.185.14), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.123 ms 0.089 ms 0.067 ms
2 192.168.1.1 (192.168.1.1) 5.234 ms 5.189 ms 5.145 ms
3 * * *
4 8.8.8.8 (8.8.8.8) 12.456 ms 12.389 ms 12.334 ms
...
🚀 Uso de MTR (Recomendado)
MTR es más potente porque envía paquetes de forma continua y calcula estadísticas en tiempo real.
Comando básico
Bash# MTR in interactive mode (recommended) mtr google.com # MTR with report (non-interactive) mtr --report google.com # MTR with 10 test packets mtr --report --report-cycles 10 google.com # MTR to an IP mtr --report 8.8.8.8
Opciones avanzadas
Bash# Specify the number of packets to send mtr --report --report-cycles 50 google.com # Use TCP instead of ICMP mtr --tcp --port 80 google.com # Use UDP mtr --udp --port 53 8.8.8.8 # Don't resolve DNS names mtr --no-dns google.com # Interval between packets (in seconds) mtr --interval 2 google.com # Packet size (in bytes) mtr --psize 64 google.com
Modo interactivo de MTR
Cuando lanza mtr sin la opción --report, entra en modo interactivo:
- d : Mostrar/ocultar estadísticas detalladas
- n : Activar/desactivar modo DNS (resolución de nombres)
- r : Restablecer estadísticas
- s : Cambiar tamaño de paquete
- j : Cambiar intervalo entre paquetes
- q : Salir de MTR
📊 Interpretación de resultados
Latencia normal
- < 50 ms : Excelente, red local o muy cercana
- 50-100 ms : Buena, conexión regional
- 100-200 ms : Aceptable, conexión intercontinental
- > 200 ms : Alta, puede causar problemas
Pérdida de paquetes
- 0% : Perfecta
- < 1% : Normal para una conexión a Internet
- 1-5% : Aceptable pero puede causar problemas
- > 5% : Problemática, requiere investigación
Significado de los asteriscos (*)
En traceroute, un * significa:
- Un solo * en lugar de un tiempo : El router no respondió a ese paquete concreto
- Tres * consecutivos : El router no respondió en absoluto (timeout o filtro de firewall)
🎯 Casos de uso
Diagnosticar latencia alta
Bash# Test to Google DNS mtr --report --report-cycles 30 8.8.8.8 # Test to Cloudflare DNS mtr --report --report-cycles 30 1.1.1.1 # Identify the problematic hop mtr --report --report-cycles 50 your-domain.com
Diagnosticar pérdida de paquetes
Bash# Test with TCP to bypass ICMP filters mtr --tcp --port 443 --report --report-cycles 50 google.com # Test to a specific server mtr --report --report-cycles 100 your-server.com
Prueba desde su VPS hacia su ubicación
Bash# Test to your public IP address # Get your public IP first curl ifconfig.me # Then test from your VPS mtr --report --report-cycles 30 YOUR_PUBLIC_IP
🔍 Solución de problemas frecuentes
Problema: latencia alta en un salto concreto
Si ve latencia alta en un salto intermedio:
Bash# Test with different protocols mtr --tcp --port 443 --report google.com mtr --udp --port 53 --report 8.8.8.8 mtr --report google.com
Importante: La latencia alta en un salto intermedio puede ser normal si ese router no responde rápidamente a las solicitudes de diagnóstico, pero la latencia final sigue siendo buena.
Problema: pérdida de paquetes significativa
Si ve una pérdida de paquetes elevada:
Bash# Test with more packets to confirm mtr --report --report-cycles 100 destination.com # Test with TCP if ICMP is filtered mtr --tcp --port 80 --report --report-cycles 50 destination.com
Advertencia: Si la pérdida de paquetes aparece en todos los saltos, el problema probablemente está en su VPS o en su conexión local. Si aparece solo en un salto concreto, el problema está en la red entre su VPS y el destino.
Problema: timeouts repetidos
Bash# Increase timeout mtr --timeout 10 --report destination.com # Test with different protocols mtr --tcp --port 443 --timeout 10 --report destination.com
📝 Comandos útiles
Script de diagnóstico completo
Cree un script para probar varios destinos:
Bash#!/bin/bash echo "=== MTR Test to Google DNS ===" mtr --report --report-cycles 30 8.8.8.8 echo -e "\n=== MTR Test to Cloudflare DNS ===" mtr --report --report-cycles 30 1.1.1.1 echo -e "\n=== MTR Test to your domain ===" mtr --report --report-cycles 30 your-domain.com
Guardar resultados
Bash# Save report to a file mtr --report --report-cycles 30 google.com > mtr-report-$(date +%Y%m%d).txt # With CSV format mtr --report --report-cycles 30 --csv google.com > mtr-report.csv
✅ Buenas prácticas
- Use MTR en lugar de traceroute: MTR ofrece estadísticas más completas
- Pruebe varios destinos: compare resultados con distintos servidores
- Ejecute varias pruebas: las redes pueden variar; ejecute pruebas en distintos momentos
- Use TCP si ICMP está filtrado: algunos routers filtran ICMP pero no TCP
- Interprete los resultados correctamente: la latencia alta en un salto intermedio no siempre es un problema si la latencia final es buena
🆘 Solución de problemas
MTR no se muestra correctamente
Bash# If MTR doesn't work in interactive mode, use report mode mtr --report destination.com # Check MTR version mtr --version
Error "mtr: command not found"
Bash# Reinstall MTR sudo apt update sudo apt install mtr-tiny -y # Or install the full version sudo apt install mtr -y
Todos los resultados muestran asteriscos
Si todos los saltos muestran *, puede significar:
Bash# Your firewall is blocking ICMP # Test with TCP instead mtr --tcp --port 443 --report destination.com # Check firewall rules sudo ufw status sudo iptables -L
📚 Recursos adicionales
❓ Preguntas frecuentes
P: ¿Cuál es la diferencia entre Traceroute y MTR?
R: Traceroute envía unos pocos paquetes y muestra los resultados. MTR envía paquetes de forma continua y calcula estadísticas en tiempo real, lo cual es más útil para el diagnóstico.
P: ¿Por qué algunos saltos muestran asteriscos?
R: Significa que el router no respondió. Puede deberse a un filtro de firewall, la configuración del router o simplemente a que el router no responde a solicitudes de diagnóstico.
P: ¿Debo preocuparme por la latencia alta en un salto intermedio?
R: No necesariamente. Si la latencia final al destino es buena, la latencia alta en un salto intermedio puede ser normal. Lo que realmente importa es la latencia final.
P: ¿Cómo interpreto la pérdida de paquetes en MTR?
R: Una pérdida de paquetes < 1% es normal. Entre 1-5%, es aceptable pero puede causar problemas. Por encima del 5%, es problemática y requiere investigación.