When you observe network connectivity issue from your local system to the server, MTR report will be very useful to know/understand the network path from where we can see where packets are dropping.
You can install mtr on your respective Linux distributions using your default package manager as shown below -
apt install mtr
yum install mtr
Then you can execute below command to capture 50 ping requests and generate MTR report -
mtr -rwc 50 destination_host_ip_or_hostname
On Windows machine you can download the WinMTR utility using below link -
https://sourceforge.net/projects/winmtr/files/latest/download
Extract the zip file and run the utility - Please select the version as per your operating system.
What is MTR?
My Traceroute (MTR) is a tool that combines traceroute and ping, which is another common method for testing network connectivity and speed. In addition to the hops along the network path, MTR shows constantly updating information about the latency and packet loss along the route to the destination. This helps in troubleshooting network issues by allowing you to see what’s happening along the path in real-time.
MTR works by discovering the network path in a similar manner to traceroute, and then regularly sending packets to continue collecting information to provide an updated view into the network’s health and speed.
How to read MTR report?
Below are three examples of how to read and draw conclusions from MTR output.
MTR 1 - ALL CLEAN
This example follows the network path between the starting router and one of our dns cluster named dns4.leapswitch.com. The MTR output does not indicate any problems — it takes 11 hops to reach dns4.leapswitch.com, and none of them indicate any packet loss.
MTR2 - Packet is there or not?
Based on the provided MTR report to "google.com," here is a summary of the packet loss:
- There is no packet loss observed from hop 1 (leapswitch) to hop 4 (143.198.252.82).
- Packet loss appears to occur at hops 2 and 8 (???) with a 100% loss rate.
- Beyond hop 8, there is no further packet loss observed, and the connection to Google's server (maa05s25-in-f14.1e100.net) seems stable.
In summary, there is packet loss detected at hops 2 and 8, but the rest of the route to Google appears to be free of packet loss.
As discussed earlier, MTR works by sending out (as a default) ICMP Echo packets, with an incrementing TTL (Time-To-Live) per packet. When the TTL expires, a router will send back an ICMP Type 11 (Time Exceeded), indicating how many hops there are from point A to point B.
Many network operators set arbitrary limits on the amount of ICMP packets that are allowed to reach the control plane of a router. A packet that exceeds a router's TTL has to be processed by the control plane. To prevent the control plane from being overwhelmed by too many of these packets, a rate limit is put in place, which is why we see all that loss on the intermediary hops, but not the final hop: the control plane rate limits for the routers on the intermediary hops were exceeded, so Type 11 packets were not sent back for the traceroute packets past those limits, but the packets were able to get through to the destination safely.
MTR3 - Actual packet loss
This example shows the network path between the starting from our local router and google's DNS server 8.8.4.4. The output shows packet loss on the last 2 hops.
When you observe packet loss on the last two hops then you should send us the MTR report so that our network team can look into the issue.
It is also advisable to share reverse MTR(MTR report from server to local system IP address). You can take the MTR as mentioned above and forward it to our support email id.