How-To Run MTR for Network Diagnostics

Introduction

MTR is a network diagnostic tool that combines traceroute and ping into a single continuous output. Instead of a one-time snapshot, it sends packets repeatedly and aggregates latency and packet loss statistics at each hop in the path — giving you a live view of where a network problem is occurring and how severe it is.

When you're troubleshooting connectivity to a Crusoe VM — slow SSH, dropped training jobs, intermittent API timeouts — MTR is the fastest way to determine whether the issue is on the Crusoe side, your ISP, or somewhere in between. It's also the primary tool Crusoe Support will ask for when investigating network path issues, so running it early saves a round-trip.

Prerequisites

MacOS

• Sudo Access
• Homebrew Installed
• MTR Installed: brew install mtr

Linux

• Sudo Access (Full Access Preferred, Install Packages Minimum)
• MTR Installed:
  • Debian and derivatives: sudo apt install mtr
  • RedHat and derivatives: sudo dnf install mtr

Windows

• WinMTR Installed

Instructions

1. Run MTR

Linux / MacOS

• Open a terminal window
• Run sudo mtr <destination> where <destination> is a hostname or IP address.
• Run mtr --help or man mtr for more options.

Windows

• Open a command prompt
• Run winmtr <destination>
• Run winmtr --help to get more help.

Example

You are trying to SSH to your VM and it is timing out. Run sudo mtr <your vm public ip> to see if there is packet loss along the route or to eliminate that as a cause. The output below is representative of MTR output — your actual output will look different.

Example 1: Normal Network Pathing

MTR output that shows normal network pathing — all hops respond, final destination shows 0% packet loss:

Start: 2026-06-16T10:30:00-0700
HOST: local-machine                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- local-router.example.net        0.0%   120    2.6   2.3   1.5   4.3   0.4
  2.|-- _gateway                        0.0%   120    1.9   2.4   1.4   4.6   0.8
  3.|-- ae30-984.bar1.sf1.level3.net    0.0%   120    2.2   2.6   1.4   3.7   0.4
  4.|-- 4.7.8.1                         0.0%   119    3.2   4.8   1.7  35.2   5.3
  5.|-- ae2.3602.edge1.sj1.lumen.tech   0.8%   119    5.9   9.0   5.3  42.2   4.9
  6.|-- 173.194.120.58                  0.0%   119    6.7   6.5   5.4   7.7   0.4
  7.|-- 192.178.87.165                  0.0%   119    7.6   8.7   7.2  27.1   2.2
  8.|-- 142.251.224.175                 0.0%   119    6.6   7.0   5.9   7.8   0.4
  9.|-- dns.google                      0.0%   119    4.9   4.8   3.3   5.5   0.4

Example 2: Normal Pathing with Intermediate-Hop Packet Loss

MTR output that is also showing normal network pathing but may look troubling. Notice that intermediate hops show high packet loss (84.2% at hop 5, 73.5% at hop 7, 84.7% at hop 11), but the final destination (hop 21) shows 0% loss — the path is healthy:

Start: 2026-06-16T10:35:00-0700
HOST: local-machine                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- local-router.example.net             0.0%   395    2.2   2.0   0.6   2.7   0.4
  2.|-- _gateway                             0.0%   395    2.5   2.1   0.8   5.8   0.4
  3.|-- ae30-984.bar1.sf1.level3.net         0.0%   395    1.9   2.2   0.9   4.0   0.4
  4.|-- 4.7.8.1                              0.0%   395    2.7   3.8   1.6  19.8   2.4
  5.|-- ae2.3605.edge9.sj1.lumen.tech       84.2%   394    9.3   8.6   5.2  42.5   5.4
  6.|-- sjo-b23-link.ip.twelve99.net         0.0%   394    6.6   6.8   5.5  29.6   1.7
  7.|-- palo-bb4-link.ip.twelve99.net       73.5%   394    8.7   8.6   6.2  17.5   1.2
  8.|-- den-bb2-link.ip.twelve99.net         0.0%   394   30.0  30.6  28.8  72.2   2.5
  9.|-- kanc-bb2-link.ip.twelve99.net       28.8%   394  150.1 150.2 148.6 162.1   0.9
 10.|-- chi-bb2-link.ip.twelve99.net         1.3%   394  147.6 148.1 146.7 158.7   0.7
 11.|-- ewr-bb2-link.ip.twelve99.net        84.7%   394   71.4  71.5  70.3  72.4   0.4
 12.|-- ldn-bb2-link.ip.twelve99.net         0.8%   394  139.0 138.6 137.6 140.0   0.4
 13.|-- dln-b3-link.ip.twelve99.net          0.0%   394  150.3 150.2 149.0 160.7   0.9
 14.|-- (Waiting for reply)                  —      —     —     —     —     —     —
 15.|-- dln-b4-link.ip.twelve99.net          0.0%   394  148.1 148.1 147.0 152.7   0.5
 16.|-- cust-ic.example.net                  0.0%   394  151.1 150.9 150.0 156.9   0.5
 17.|-- 91.106.221.137                       0.0%   394  180.7 180.8 179.9 182.0   0.4
 18.|-- (Waiting for reply)                  —      —     —     —     —     —     —
 19.|-- (Waiting for reply)                  —      —     —     —     —     —     —
 20.|-- (Waiting for reply)                  —      —     —     —     —     —     —
 21.|-- 216.86.170.132                       0.0%   394  172.6 173.4 171.4 313.0   7.1

Example 3: Bad Network Pathing

MTR output that shows bad pathing — 87% packet loss at hop 5, followed by "(Waiting for reply)" at hop 6. The path is broken, and packets are not reaching the destination:

Start: 2026-06-16T10:40:00-0700
HOST: local-machine                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- local-router.example.net        0.0%    47    2.7   2.4   1.4   3.7   0.4
  2.|-- _gateway                        0.0%    47    2.4   2.4   1.7   2.9   0.2
  3.|-- ae30-984.bar1.sf1.level3.net    0.0%    47    3.8   2.6   1.5   3.8   0.5
  4.|-- 4.7.8.1                         0.0%    47    2.9   3.8   2.4  15.5   2.2
  5.|-- ae2.3605.edge9.sj1.lumen.tech  87.0%    47   14.2  10.1   7.0  14.2   2.6
  6.|-- (Waiting for reply)              —      —     —     —     —     —     —

Understanding MTR Output

• It is normal for routers to limit ICMP responses in order to prioritize regular traffic. It is not uncommon for one hop in the chain to show packet loss. The important thing is that the final hop (the destination host) shows 0% packet loss (see Example 2 above).
• A bad path will have high packet loss at one hop and will either stop there (the destination host is offline) or the subsequent hops will also show high packet loss, including the final hop (the destination host). MTR allows you to determine where the packet loss is first occurring in this instance (see Example 3 above).
• Columns explained:
  • Packets
    1. Loss% — Shows the amount of packet loss at that hop.
    2. Sent — Shows the number of packets sent.
  • Pings (times are in milliseconds)
    1. Last — Last response time.
    2. Avg — The average response time.
    3. Best — The fastest response time.
    4. Wrst — The slowest response time.
    5. StDev — This shows the ping "jitter", or how much it varies from the average. Lower is better, as it means the connection is more stable.

Additional Resources

• Checking Network Connections to VMs
• Homebrew
• WinMTR