Troubleshooting/Reporting Network and Packet Loss Issues

Using MTR to Diagnose Network Issues

If you are experiencing slow speeds, packet loss, or other connection issues with your server, running an MTR (My Traceroute) report is the best first step for diagnosis. MTR combines the functionality of traceroute and ping into a single, powerful tool. It shows the "hops" (routers) your connection takes to its destination and provides continuous statistics on latency (ping) and packet loss for each hop.

This guide will explain why we need two reports, how to run them, and how to interpret the results.

Why We Need Two MTRs (Client-to-Server and Server-to-Client)

A common mistake is to only run an MTR in one direction. Internet traffic is often asymmetric, meaning the path from your local computer to the server is different from the path back to your computer.

An issue (like a congested router) might exist on the return path but not on the path to the server. Without seeing both directions, we only have half the information.

To get a complete picture, our support team requires both reports:

• Client-to-Server: Run from your local computer (e.g., your home or office PC) to your server's IP address.
• Server-to-Client: Run from your server to your local computer's IP address. (You can find your local IP by searching "What is my IP" on Google).

How to Run an MTR

On Windows (using WinMTR)

Windows does not include MTR by default. The easiest way to run one is by using a free tool called WinMTR.

1. Download WinMTR from a trusted source (like the official WinMTR page on SourceForge).
2. Unzip the file and run the WinMTR.exe application (no installation is needed).
3. In the "Host" field, enter the IP address you want to test (e.g., your server's IP for the client-to-server test).
4. Click "Start".
5. Let the MTR run until the "Sent" column shows at least 100 packets. This gives a good statistical sample.
6. Click "Copy Text to clipboard" and paste the full results into your support ticket.
7. Repeat the process, running WinMTR on your server with your home/office IP in the "Host" field.

On Linux (mtr command)

Most Linux distributions have MTR available for installation via their package manager.

1. Install MTR:

# For Debian/Ubuntu
sudo apt-get update && sudo apt-get -y install mtr

# For RHEL/CentOS/AlmaLinux
sudo yum install -y mtr

2. Run the MTR Report:

We need to run the MTR in "report mode" so it sends a specific number of packets and then prints the results. This command sends 100 packets (`-c 100`), uses report mode (`-r`), and disables DNS lookups (`-n`) for a cleaner, faster report.

mtr -r -n -c 100 YOUR_DESTINATION_IP_HERE

After the command finishes (it may take a minute), copy the entire text output and paste it into your support ticket. Remember to run this in both directions (from client-to-server and from server-to-client).

How to Properly Read an MTR Report

An MTR report can look intimidating, but you are primarily looking for two things: Packet Loss (%) and Latency (Avg).

Here is an example report and how to interpret it:

Host                           Loss%   Snt   Last   Avg  Best  Wrst  StDev
1. 192.168.1.1                 0.0%    100    0.8   0.9   0.7   2.1   0.2
2. my-isp-gateway.com          0.0%    100    1.2   1.5   1.0   4.5   0.5
3. some-transit-router.net     15.0%   100   10.5  11.0  10.1  15.0  1.1  <-- (See Note 1)
4. another-router.net           0.0%    100   10.8  11.2  10.5  16.0  0.9
5. 10ge.reliablesite.router     5.0%    100   20.1  22.5  20.0  35.0  3.7  <-- (See Note 2)
6. your-server.com              5.0%    100   20.2  22.6  20.1  36.0  3.8

Interpreting the Results:

• Note 1: "False" Packet Loss (ICMP Rate Limiting)
  Look at hop 3. It shows 15% packet loss, but the very next hop (hop 4) shows 0.0% loss. This is NOT a problem. It is almost always caused by a router's "ICMP Rate Limiting," which deprioritizes or drops MTR/ping packets to protect its own CPU. If the loss does not continue to the next hop, you can safely ignore it.
• Note 2: "Real" Packet Loss
  Look at hop 5. It shows 5% packet loss, and critically, that same 5% loss continues all the way to the final destination (hop 6). This indicates a genuine network problem starting at hop 5. This is the information our support team needs to investigate.
• Loss at the Final Hop
  If you see 0% loss all the way to the second-to-last hop, but significant loss (e.g., 50%+) on the final hop, this often points to a firewall (like Windows Firewall, CSF, or firewalld) on the destination server that is dropping the packets.
• High Latency
  Look at the Avg (average) and Wrst (worst) latency columns. A sudden, large jump in latency (e.g., from 10ms to 80ms) that then stays high for all following hops indicates a point of network congestion or a slower link. This is also useful for diagnostics.

Submitting Your MTRs to Support

To help us diagnose your issue quickly, please include the following in your support ticket:

1. The full text output of the MTR from your Client-to-Server.
2. The full text output of the MTR from your Server-to-Client.
3. The IP address of your client (home/office) and your server.

Important: Before running your tests, please temporarily disable any VPNs you are using, as they will route traffic differently and hide the true network path. We also advise disabling your OS-level firewall (like Windows Firewall or firewalld) during the test, as it can block MTR packets and cause inaccurate results (like 100% loss at the final hop).

If you are unable to access your server to run the MTR, our support department can run the server-side MTR for you. Please provide administrator-level access to your server when you create your ticket.