When a server is unreachable or shows packet loss, the fastest way to get it fixed is to open a support ticket that already contains the data the network team needs. This guide explains what to check first, how to generate an MTR report from Linux, macOS and Windows, and how to add a reverse MTR from the server back to your connection.

Prerequisites

  • Access to the CubePath control panel.
  • The public IP address of the affected server.
  • For the tests: a terminal on Linux or macOS, or a Windows computer where you can run WinMTR.
  • For the reverse MTR: SSH access to the server.

Step 1 - Identifying the type of problem

Network issues usually fall into one of two groups, and each needs different information:

SymptomWhat to do
The server does not respond at all (no SSH, no ping, no web)Try a reboot from the panel (Step 2) before opening a ticket
The server responds but connections are slow, drop, or some locations cannot reach itCollect MTR reports in both directions (Steps 3 to 5)

In every ticket, always include:

  • The server affected (hostname or IP address).
  • When the problem started and whether it is constant or intermittent, with the time zone.
  • Your own public IP address, which you can check at https://ip.cubepath.com/.

Step 2 - Rebooting a server that is not reachable

If the server does not respond at all, the operating system may be hung. You can restart it yourself: in the CubePath control panel, go to the servers section, select the affected server and press Reboot.

Wait a few minutes and test again. If the server is still unreachable after the reboot, open a ticket and mention that you already rebooted it. A server that stays unreachable may also have been blocked by CubePath; in that case support will tell you the reason and how to resolve it.

Step 3 - Running MTR on Linux or macOS

MTR combines ping and traceroute: it sends packets to every hop between you and the server and reports loss and latency per hop, which shows where on the path the problem starts.

Install it on Ubuntu or Debian:

sudo apt install mtr-tiny

On macOS, install it with Homebrew:

brew install mtr

Run a report with 100 packets towards your server, replacing your_server_ip. The options show hostnames and IPs (-b), the autonomous system of each hop (-z) and wide output without truncated names (-w):

mtr -rwbz -c 100 your_server_ip

On macOS, MTR needs raw sockets, so run it with sudo:

sudo mtr -rwbz -c 100 your_server_ip

The test takes about 100 seconds. The result looks like this:

Start: 2026-09-25T10:15:02+0200
HOST: test-client                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    _gateway (192.168.1.1)                        0.0%   100    2.1   2.2   1.7   2.9   0.4
  2. AS???    172.16.30.5                                   0.0%   100    4.1   4.6   3.8   6.0   0.7
  3. AS3257   et-8-0-5.cr2-par11.ip4.gtt.net (89.149.x.x)   0.0%   100   22.4  23.9  21.1  33.8   4.2
  4. AS3257   et-0-0-0-0.cr4-mad5.ip4.gtt.net (89.149.x.x)  0.0%   100   38.7  29.6  26.4  38.7   3.8
  5. AS???    172.16.254.8                                  0.0%   100   26.0  26.9  25.1  34.7   2.8
  6. AS???    your_server_ip                                0.0%   100   26.0  25.9  25.5  26.6   0.3

How to read it:

  • Look at the last line first. If the destination shows 0% loss, the path works end to end.
  • Loss on an intermediate hop that does not continue to the following hops is usually a router limiting its replies to probes, not a real problem.
  • Loss that starts at one hop and continues until the destination points to where the problem is.

If ICMP is filtered somewhere along the path, repeat the test with TCP towards a port that is open on the server, for example SSH on port 22:

mtr -rwbz -c 100 -T -P 22 your_server_ip

Copy the full output as text into the ticket.

Step 4 - Running WinMTR on Windows

On Windows, use WinMTR, a free graphical version of MTR:

  1. Download WinMTR from its official site and extract the ZIP file that matches your Windows version (32-bit or 64-bit).
  2. Run WinMTR.exe from the extracted folder.
  3. In the Host field, enter the IP address of your server.
  4. Click Start and let the test run for at least 10 minutes. Intermittent loss often does not show up in shorter tests.
  5. Click Stop, then Export TEXT to save the results to a file.

Attach the exported file to the ticket. If you cannot install software on the computer, the built-in pathping command gives similar per-hop loss statistics. Run it from Command Prompt:

pathping -n your_server_ip

Step 5 - Running a reverse MTR from the server

Routing on the Internet is often asymmetric: packets from the server back to you can take a different path from the one you tested in Step 3. A reverse MTR, run from the server towards your connection, shows that return path.

First find your own public IP by opening https://ip.cubepath.com/ from the affected computer or network. Then connect to the server over SSH, install MTR if needed (see Step 3) and run the report towards that address, replacing your_public_ip:

mtr -rwbz -c 100 your_public_ip

Add this output to the ticket together with the MTR from Step 3 or 4.

If you cannot reach the server over SSH, send your public IP address in the ticket and the CubePath team will run the reverse trace for you.

Conclusion

A network ticket that includes the affected server, the time of the problem, your public IP and MTR reports in both directions lets the network team locate the fault without a round of follow-up questions. For intermittent problems, run the tests while the issue is happening and repeat them at a time when everything works, so both results can be compared.