MTR Network Diagnostics

Diagnose network issues by combining traceroute and ping into one powerful tool

What is MTR?

MTR (My Traceroute) is a network diagnostic tool that combines the functionality of traceroute and ping into a single, powerful utility. It continuously sends packets and provides real-time statistics about each hop between your server and a destination.

Real-Time Data

Continuously updates statistics

Full Path View

Shows every hop to destination

Latency Tracking

Identifies slow network segments

When to Use MTR

Use MTR when you experience slow connections, packet loss, or intermittent connectivity issues. It helps identify whether the problem is on your server, your ISP, or somewhere in between.

Installation

Ubuntu / Debian

sudo apt update && sudo apt install mtr -y

CentOS / RHEL / AlmaLinux

sudo dnf install mtr -y

Fedora

sudo dnf install mtr -y

Arch Linux

sudo pacman -S mtr

Basic Usage

Interactive Mode (Default)

Run MTR in interactive mode to see real-time updates. Press q to quit.

mtr google.com

Report Mode (For Support Tickets)

Generate a report after a set number of packets. This is the best format for sharing with support teams.

mtr -r -c 100 google.com

-r = Report mode (non-interactive)
-c 100 = Send 100 packets before generating report

Wide Report (Show IP Addresses)

Include full hostnames and IP addresses in the report.

mtr -r -w -c 100 google.com

Test Both Directions

Network issues can occur in either direction. Always run MTR from both ends:

# From your VPS to your location
mtr -r -w -c 100 YOUR_HOME_IP

# From your location to your VPS
mtr -r -w -c 100 YOUR_VPS_IP

Reading MTR Results

Example MTR Output

HOST: vps.example.com           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                    0.0%   100    0.5   0.6   0.4   1.2   0.1
  2.|-- isp-router.net             0.0%   100    1.2   1.4   1.0   3.5   0.3
  3.|-- core-router.isp.net        0.0%   100    5.3   5.8   4.9  12.1   0.8
  4.|-- peer-exchange.net          2.0%   100   15.2  16.1  14.8  25.3   1.2
  5.|-- destination-dc.net         0.0%   100   18.4  18.9  17.2  28.7   1.5
  6.|-- target-server.com          0.0%   100   19.1  19.5  18.0  30.2   1.8

Loss%

Percentage of packets lost at each hop. 0-1% is normal. 1-5% may indicate congestion. >5% is problematic.

Snt (Sent)

Number of packets sent. More packets give more accurate statistics. Use at least 100 for reports.

Last / Avg / Best / Wrst

Latency in milliseconds. Avg is most useful. Large gaps between Best and Wrst indicate instability.

StDev (Standard Deviation)

Measures consistency. Low StDev = stable connection. High StDev = variable latency (jitter).

Key Interpretation Tips

•Packet loss at intermediate hops only is often normal - some routers deprioritize ICMP packets. Only worry if loss continues to the final destination.
•Latency should increase gradually as packets travel further. A sudden large jump indicates a slow link.
•Look at the final hop - this represents actual connectivity to your destination. Issues here are the most relevant.
•Stars (***) at a hop mean that router does not respond to probes - this is often normal and not a problem.

Common Issues & What They Mean

Packet Loss at Final Destination

If loss occurs at the final hop, there is a real connectivity problem. This could be:

Server firewall blocking ICMP
Server resource exhaustion
Network interface issues
DDoS attack or high traffic

High Latency Jump at Specific Hop

A sudden increase in latency (e.g., 20ms → 150ms) indicates:

Geographic distance (crossing continents)
Congested link at that hop
Poor peering between networks

High Standard Deviation (Jitter)

Large StDev values indicate inconsistent network performance:

Network congestion during peak hours
Overloaded router or switch
Wireless interference (if applicable)

Loss at Middle Hops Only

If packet loss appears at intermediate hops but NOT at the final destination, this is usually not a problem:

Routers often rate-limit ICMP responses
Some networks deprioritize diagnostic traffic
Focus on the final destination statistics

Best Practices

When Submitting MTR to Support

1
Run from both directions
From your VPS to your location AND from your location to the VPS
2
Use at least 100 packets
More data points = more accurate diagnosis
3
Include timestamps
Note when the test was run to correlate with issue timing
4
Test during the problem
Run MTR when you are experiencing the issue, not after it resolves

Complete Command for Support Tickets

Use this command to generate a comprehensive report suitable for a support ticket:

# Generate timestamped report
echo "=== MTR Report - $(date) ===" && mtr -r -w -c 100 TARGET_IP

Tip: Replace TARGET_IP with the destination you are having trouble reaching, or your home IP when testing from your VPS.

Need Help Interpreting Results?

If you are experiencing persistent network issues, open a support ticket at clientarea.ramnode.com and include your MTR reports from both directions.