Troubleshooting Slowness & Packet drops – WinMTR / MTR vs Pathping vs traceroute
by
mo 
Whenever there is slowness issue to be investigated, the first thing to be usually checked is packet drops or high latency along the path, tools like traceroute (or tracert on windows) and nping are usually enough to draw a map of the traffic path and in some cases are enough to find out at which hop of the path we start to see a huge difference in a packet’s RTT (Round Trip Time) like the below example:
|
|
|
While there is no slowness issue in this traceroute, it’s very clear at which hop exactly the traffic travelled through to WAN |
At hop #4, we see a huge difference in the packet RTT if we compare it to hop #3, the packet RTT is up by almost 700%, so this has to be the hop in which the traffic has hit the WAN and therefore hop#3 is the WAN router, you get the idea?
What is WinMTR?
While the traditional traceroute may be more than adequate for a lot of cases, there are sometimes when additional proof is needed to confirm the root cause of the problem.
Basically, WinMTR is a tool that does two things:
1)A basic traceroute.
2)After the basic traceroute is done, WinMTR keeps on pinging every hop along the path until it’s stopped.
This way we can observe which hop exactly is causing most packet loss.
WinMTR vs pathping vs traceroute
While the traditional traceroute can be enough to find where we can see packet drops, in most cases we will need to obtain more accurate results, this is where WinMTR and pathping come through to save the day.
WinMTR & pathping actually are built upon the traditional traceroute but both tools take it a step further:
-WinMTR & pathping carry out a traditional traceroute to the destination IP.
-Both tools ping all the hops along the path with a high number of packets in a rapid succession in order to find out where exactly packet drops are being observed.
There is an issue with pathping though which is a limitation by design: pathping stops the traceroute if it receives no response from any hop along the path, which can be normal if a certain network device is not configured to send out ICMP TTL exceeded packets… This is where WinMTR steps in, it continues the traceroute anyways and tests all the hops until it reaches the destination (if it can reach it).
Comparing the output of WinMTR & pathping
To compare the output of WinMTR & pathping, we need first to do a traceroute to the destination IP because what both tools actually do is to first carry out a normal traceroute and then build up their results by checking the hops revealed along the path.
It’s important to note that the way both WinMTR & pathping execute their traceroute will reveal a huge difference in the way they work:
traceroute
|
tracert -d 57.66.190.19 |
|
The traceroute shows a total of 11 hops needed to reach the destination, it’s important to note that there is no response from hop #10 |
The output below is generated from tests to an IP where packet drops were being observed by users using a certain ISP.
Pathping
|
Tracing route to 57.66.190.19 over a maximum of 30 hops: |
|
In the output from pathping, there are only 9 hops but hop #10 is missing |
WinMTR
|
—————————————————————————————— |
|
Checking with WinMTR reveals 10 hops, which matches the number of hops discovered by a regular traceroute |
As mentioned earlier, the problem with pathping is that it doesn’t check the entire path when a hop does not respond with an ICMP TTL expired during transit, this is clearly seen in the results above… Both WinMTR and traceroute continue to the destination 57.66.190.18 while pathping stops at 10.234.7.22.
In the tests above, we can finally conclude that the packet drops are first seen on hop #4 with IP 80.150.168.114
Conclusion
For troubleshooting issues related slowness and packet drops, it’s best to use a tool like WinMTR for Windows or simply MTR for linux, both tools combine the functionality of traceroute & ping in a much more sophisticated way:
-Normal traceroute to destination
-Ping every hop along the path for an indefinite amount of time (by default)…
The result is a reliable measure of how good the connection is to each hop along the path.
Recent Comments