MTR Reports - Network Diagnostics

Quick Fix

Generate and send an MTR report

# Install MTR
# Ubuntu/Debian
sudo apt install mtr
# macOS
brew install mtr

# Run for 100 packets (takes ~2 minutes)
mtr -c 100 <target_host> > mtr-report.txt

Then send us the mtr-report.txt file.

Windows: Download WinMTR or use WSL with the Linux instructions above.

Run it in the RIGHT direction

If you cannot reach your Euronodes server, run MTR against your VM's own public IP, from the machine that cannot reach it (your home/office PC, or another server). That is the path that is actually broken, so that is the path we need to see.

# Diagnosing "I cannot reach my server":
# run this FROM the affected machine, TARGET = your VM's public IP
mtr -c 100 <your_vm_public_ip> > mtr-report.txt

Running MTR from inside the VM out to 8.8.8.8 only tests the VM's general outbound connectivity. It does not show us the inbound path that is failing, so it is rarely the report we need first.

Install MTR

Installation

Linux/Mac:

# Ubuntu/Debian
sudo apt install mtr

# macOS
brew install mtr

Windows: Download from WinMTR or use WSL with Linux instructions above.

Generate MTR Report

Run MTR

# Run for 100 packets (takes ~2 minutes)
mtr -c 100 <target_host> > mtr-report.txt

# Diagnosing reachability to your server?
# <target_host> = your VM's public IP, run from the affected source machine.
mtr -c 100 <your_vm_public_ip> > mtr-report.txt

# Only testing general outbound connectivity from inside the VM?
# Then a public target like 8.8.8.8 is fine.
mtr -c 100 8.8.8.8 > mtr-report.txt

Then send us the mtr-report.txt file.

Also Test with TCP

ICMP loss can be fake - confirm with TCP

Many routers along the path rate-limit ICMP (the protocol plain MTR and ping use). When they do, MTR reports packet loss and high StDev (jitter) at those hops even though real traffic is passing fine. This is one of the most common causes of a "scary looking" MTR report that turns out to be harmless.

Always back up an ICMP report with a TCP run aimed at the actual service port your traffic uses (443 for HTTPS, 80 for HTTP, 22 for SSH, and so on). TCP to the real port reflects what your application actually experiences.

Linux/Mac:

# TCP MTR to port 443 (HTTPS). Change the port to match your service.
sudo mtr --tcp --port 443 -c 100 <target> > mtr-tcp-report.txt

Windows: In WinMTR (or a TCP-capable build), configure it to use TCP on the relevant port instead of the default ICMP mode.

If ICMP shows loss but the TCP run to your service port is clean, the "loss" is almost certainly ICMP rate-limiting, not a real problem. Send us both reports so we can compare.

What MTR Shows

Don't Use Ping

Ping is unreliable for diagnosing network issues. Instead, use MTR (My Traceroute) to send us detailed network diagnostics.

Why MTR is Better

MTR shows: - Packet loss at each hop - Latency variations - Route path to destination - Jitter and consistency issues

This gives us much more information than ping to diagnose your network problems.