How accurate is PingPlotter Really ??

Anthro

Expert Member
Joined
Jun 13, 2006
Messages
4,485
Reaction score
1,757
Location
Jesus Loves YOU.
Had an interesting scenario today.
Pingplotter was indicating 20+% packet loss to the gateway within the LAN at a client site, and also some loss to other points in the path.
I was there to try and prove that the issue is on their Internet or Infrastructure (alongside their IT person who we asked to be present)
Doing a standard ping to those same IP's produced zero loss, and their IT guy waved this in my face as being "CMD is more reliable at these kind of things"
Why the difference in resultset ?
 
Havent used Pingplotter, but I think a fair assumption is it uses ICMP.
These are the same as your tests so my first suggestion would be to see what is different from your device making the request than the device where pingplotter resides.
possibly there are resource constraints on that server, there could be an interface issue such as duplex mismatch, congestion, drops or errors etc
 

Got this example from their website:

1580487453432.png

"First off, the final destination (hop 16) shows 9% packet loss. There's a problem someplace in the route, but we need to determine where....

Hop 4 shows 5% packet loss. Hop 5 doesn't show packet loss, though, so you know that the problem in hop 16 isn't because of hop 4. Hop 4 is likely just a router using a different CPU path for TTL=0 packets than it does for routing data through.

Hop 9, however, shows 9% packet loss, and this packet loss is carried on through to the final destination. This is a huge indication of where the problem lies.

Now, all we know from this is that the problem happens after hop 8. We don't know if it actually happens because of CPU overloading in hop 9, a router problem in hop 9 (or even on the exit side of hop 8), or if it's the connection between hop 8 and 9. A little bit more troubleshooting is needed for this.

Digging deeper, we can see (from the domain names) that hop 8 is in the rr.com domain, while hop 9 is in the alter.net domain. Also, the IP addresses show decidedly different ranges. This is a strong clue that it's actually the connection between hop 8 and 9 that's causing the problem. It's likely that there's not enough bandwidth between those two locations"


I quickly did a packet capture of both, so if you look at their capture, you will see a lot more requests from my internal IP to google dns each with a different TTL value, once the TTL value reaches 0 it obviously gets discarded, and TTL is reduced by 1 every hop...

(Oh, and if they do suspect something is wrong PingPlotter could help identify if there is an issue, but you would need to dig a little deeper to proof anything. Packet capture is a good start)

CMD.JPG


Because it sends ICMP packets out and starting with a TTL of 1 the reply of that TTL form a router will be used to indicate "packet loss" at a certain hop if not all of them comes back.
Basically means you need to use more tools check for real packet loss...


1580878591455.png

You can also do that yourself, want to test hop 5, set the TTL to 5 and that router should respond with a TTL expired....

You can set your TTL to whatever if you want to test TTL 0 replies from a router... but again, not getting a TTL expired back is not an indication of an issue.

1580879244448.png
 
Last edited:
icmp is generally at the bottom of things to respond to on busy devices... but, it can indicate an overloaded/faulty device/interface.
 
Top
Sign up to the MyBroadband newsletter
X