Troubleshooting Network Connectivity Using MTR (My Traceroute)

When experiencing packet loss, latency, or intermittent connectivity issues, running an MTR (My Traceroute) test helps identify where the problem lies along the network path.

This guide explains how to perform MTR tests from Windows, Linux, and macOS, and how to interpret the results for both outbound (your device → server) and inbound (server → your device) connectivity.

What is MTR?

MTR combines the functionality of ping and traceroute. It continuously measures latency and packet loss across every hop (router) between your device and the destination, allowing you to pinpoint where degradation occurs.

Before You Begin

• Identify the server IP or hostname you want to test.

• Run the test for at least 300 packets (~5 minutes).

• Perform tests in both directions if possible (from your side and from the server).

• Note that some routers, ISPs, and firewalls rate-limit ICMP (the protocol used by MTR). This can cause false packet loss readings at intermediate hops — explained further below.

Running MTR on Windows

Step 1: Install WinMTR

1. Download WinMTR.

2. Extract and open the program (no installation needed).

Step 2: Run the Test

1. Enter your server IP or hostname in the Host field.

2. Click Start and let it run until around 300 packets are reached (~5 minutes).

3. Click Stop when done.

Step 3: Export the Results

1. Click Export Text or Export HTML.

2. Save the file and attach it to your support ticket.

Running MTR on Linux / macOS

Step 1: Install MTR

If MTR isn’t installed, run one of the following commands:

# Debian / Ubuntu
sudo apt install mtr

# CentOS / AlmaLinux / Rocky
sudo yum install mtr

# macOS (via Homebrew)
brew install mtr

Step 2: Run the Test

Replace <target> with the server’s IP or hostname:

mtr -rwzbc300 <target>

Flags explained:

• -r – Report mode (shows final results after test)

• -w – Wide output (for better readability)

• -z – Show both hostnames and IPs

• -b – Include both IP and hostname

• -c300 – Send 300 packets (~5 minutes)

Step 3: Copy the Results

When complete, copy the full output and include it in your support ticket.

Running MTR from the Server (Reverse Test)

Sometimes, packet loss or latency occurs in only one direction.
To confirm, run a reverse MTR from the server back to your own public IP address:

mtr -rwzbc300 <your-public-ip>

*Note: If you’re behind a firewall, temporarily allow ICMP (ping) replies so the test can complete.

Understanding MTR Results

Each MTR line represents a router (hop) between your system and the destination. MTR shows how long it takes to reach each hop and whether packets are being dropped.

Interpreting Packet Loss

1. Ignore isolated loss on early hops

Many routers rate-limit ICMP responses but still forward traffic normally.
Example:

Host                                Loss%   Avg
1  router.local                      40%     1.2
2  core01.isp.net                     0%     2.4
3  rackzar.net                        0%     3.1

Loss on hop 1 is harmless — the router simply prioritised forwarding traffic over replying to ICMP.

2. Continuous loss indicates a problem

If packet loss starts at a certain hop and continues for all subsequent hops, the issue likely lies at or beyond that point.

5  transit1.isp.net                  0%
6  edge01.dc.rackzar.net            18%
7  server.rackzar.net               18%

Loss appears from hop 6 onward — likely a congestion or routing issue on that link.

3. High latency on a single hop

If latency spikes on one hop but recovers on the next, that hop is likely just deprioritising ICMP responses, not actually causing slowness.

4. Intermittent loss

If loss varies between runs, it may be caused by temporary congestion or rate-limiting. Run multiple tests to confirm consistency.

Common Scenarios

Submitting Results

Please send both:

• Outbound MTR: from your local device to the server

• Inbound MTR: from the server to your public IP

Attach both outputs or exported files to your support ticket. This helps our engineers determine whether the issue lies locally, with your ISP, or upstream in our network.

Quick Reference Commands

Tip

Packet loss that continues through to the destination indicates a real problem.
Loss appearing on a single intermediate hop is usually just ICMP rate-limiting and not a cause for concern.