🔍 Perform an MTR/Traceroute Diagnostic

This guide will teach you how to use MTR (My Traceroute) and Traceroute to diagnose network connectivity issues, identify latency points, and analyze the quality of your network connection.

📋 Prerequisites

• A VeryyCloud VPS server with root or sudo access
• An active SSH connection
• Ubuntu/Debian (commands are adapted for these distributions)

🔧 Installation

Installing Traceroute (basic tool)

# On Ubuntu/Debian
sudo apt update
sudo apt install traceroute -y

Installing MTR (advanced tool)

MTR combines the functionality of ping and traceroute into a single powerful tool.

# 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

Verifying the installation

# Verify that traceroute is installed
traceroute --version

# Verify that MTR is installed
mtr --version

🛠️ Using Traceroute

Basic command

# 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 the timeout in seconds
traceroute -w 5 google.com

Useful options

# 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

Example output

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
 ...

🚀 Using MTR (recommended)

MTR is more powerful because it continuously sends packets and calculates real-time statistics.

Basic command

# 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

Advanced options

# 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

MTR interactive mode

When you run mtr without the --report option, you enter interactive mode:

📊 Interpreting results

Normal latency

Packet loss

Meaning of asterisks (*)

In traceroute, a * means:

• A single * instead of a time: The router did not respond to that specific packet
• **Three consecutive ***: The router did not respond at all (timeout or firewall filter)

🎯 Use cases

High latency diagnosis

# 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

Packet loss diagnosis

# 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

Test from your VPS to your location

# 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

🔍 Diagnosing common problems

Problem: High latency on a specific hop

If you see high latency on an intermediate hop:

# Test with different protocols
mtr --tcp --port 443 --report google.com
mtr --udp --port 53 --report 8.8.8.8
mtr --report google.com

Important: High latency on an intermediate hop can be normal if that router doesn't respond quickly to diagnostic requests, but the final latency remains good.

Problem: Significant packet loss

If you see high packet loss:

# 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

Warning: If packet loss appears on all hops, the problem is probably on your VPS or your local connection. If it only appears on a specific hop, the problem is on the network between your VPS and the destination.

Problem: Repeated timeouts

# Increase the timeout
mtr --timeout 10 --report destination.com

# Test with different protocols
mtr --tcp --port 443 --timeout 10 --report destination.com

📝 Useful commands

Complete diagnostic script

Create a script to test multiple destinations:

#!/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

Save the results

# Save the 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

✅ Best practices

• Use MTR rather than traceroute: MTR provides more complete statistics
• Test multiple destinations: Compare results to different servers
• Run multiple tests: Networks can vary, run several tests at different times
• Use TCP if ICMP is filtered: Some routers filter ICMP but not TCP
• Interpret results correctly: High latency on an intermediate hop is not always a problem if the final latency is good

🆘 Troubleshooting

MTR doesn't display correctly

# 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"

# Reinstall MTR
sudo apt update
sudo apt install mtr-tiny -y

# Or install the full version
sudo apt install mtr -y

Results show all asterisks

If all hops show *, this can mean:

# 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

❓ Frequently Asked Questions

Q: What is the difference between Traceroute and MTR? A: Traceroute sends a few packets and displays the results. MTR sends packets continuously and calculates real-time statistics, which is more useful for diagnostics.

Q: Why do some hops show asterisks? A: This means the router did not respond. This can be due to a firewall filter, router configuration, or simply that the router does not respond to diagnostic requests.

Q: Should I worry about high latency on an intermediate hop? A: Not necessarily. If the final latency to the destination is good, high latency on an intermediate hop can be normal. It's the final latency that really matters.

Q: How do I interpret packet loss in MTR? A: Packet loss < 1% is normal. Between 1-5%, it's acceptable but can cause problems. Above 5%, it's problematic and requires investigation.