Elastic Compute Service:Use MTR to analyze network links

Windows

WinMTR requires no installation. Download and run it directly:

1. Download WinMTR from the WinMTR official website.

2. Decompress the package and double-click WinMTR.exe to start it.

   

Loss%

Non-zero loss at a hop does not always mean there is a network problem. Two common causes:

1. ICMP throttling by the carrier — The carrier deprioritizes ICMP probes for security or performance reasons, causing apparent packet loss that does not affect actual traffic.

2. A real network exception — Packets are genuinely dropped at that hop.

To tell the difference, check the hops that follow:

• No loss on subsequent hops — The loss at this hop is caused by ICMP throttling. No action needed. (See hop 2 in the sample output.)

• Loss on all subsequent hops — A real network exception at this hop is dropping packets. Investigate and contact the responsible carrier. (See hop 6 in the sample output.)

• Loss on some subsequent hops, with varying rates — Both ICMP throttling and a network exception may be present. Use the loss rate of the last few affected hops as the reference value. In the sample output, hops 6–9 show loss, with hop 9 at 30.3% — use hop 9's rate as the reference.

Avg and StDev

Avg reflects overall latency at a hop, but a single Avg value can be misleading when StDev is high. For example, if some packets have 25 ms latency and others have 350 ms, the Avg might fall in a normal range while actual performance is inconsistent.

Use both values together:

• High StDev — The Avg alone is unreliable. Examine Best and Wrst to assess the actual range of latency at this hop.

• Low StDev — The Avg accurately reflects the latency at this hop.

There is no fixed threshold for "high" or "low" StDev — it is always relative to the other latency values at the same hop. For example, a StDev of 25 ms is high when Avg is 30 ms, but not high when Avg is 325 ms.

Latency spikes

Spike starting at a hop — If latency increases sharply at a hop and remains elevated on subsequent hops, a network exception likely occurred at that hop. (In the sample output, latency spiked starting at hop 6.) A latency spike alone does not confirm packet loss — run a reverse path test to confirm.

Spike confined to a single hop — If latency is high at a hop but drops back to normal on the next hop, ICMP throttling at that hop is the most likely cause. In the sample output, hop 9 has 30.3% loss and a latency spike, but subsequent hops return to normal levels.

Misconfigured destination host

All packets are lost at the final hop.

ICMP is likely blocked by the destination server's security policies (firewall rules or iptables). Check the security policies on the destination server.

ICMP throttling at the destination

Packet loss is high at the last few hops.

The destination server's firewall, iptables rules, or a carrier throttling policy is blocking ICMP responses. Check the destination server's security policies or run a reverse path test to isolate the cause.

Routing loop

Packets loop through the same hops repeatedly after a certain point and never reach the destination.

In the example, a routing loop starts at hop 5. This is usually caused by a misconfigured route on a carrier node. Contact the carrier to resolve the issue.

Node interruption

Packets stop receiving responses after passing through a hop. The Loss%, Last, Avg, and Best fields show no statistics.

In the example, no responses are returned after hop 4. This typically indicates the node is down. Run a reverse path test to confirm, then contact the carrier responsible for that node.