Why? That’s simple: it’s you! Nasty red stuff at hop one usually means something on your end is causing the frowny face. If the final hop is the most important, the first hop is a close second. I sent my PingPlotter graphs and information to our network administrators and they responded that traceroute is not an accurate way of troubleshooting networks.Remember this graph? We identified the captured data was a good snapshot of a possible issue, so let’s dive a little deeper. They say that the first slow hop is the weakest link and invalidates any other data reported. They also say that ICMP traffic (like PingPlotter creates) is low-priority and can't be trusted. They say they can't trust PingPlotter data, so stop sending it to them. These statements have enough truth in them to cause a lot of users to leave a network administrator alone, but are targeted to do this - drive an end-user to stop bringing these results.īoth latency and packet loss (the two things that PingPlotter excels in capturing, measuring and displaying) are additive. This means that a slow connection early in your route will, indeed, add latency at all downstream hops.
The part left off the 'objections' statement you got is that any additional latency or packet loss problems can still be seen - even if your first hop is a modem. If hop 1 adds 150ms and 5% packet loss, you can still see that some other hop (say, hop 7) adds another 100ms of latency and another 10% of packet loss. Is some latency and packet loss at hop 1 does not make the information gathered about hop 7 any less valid. PingPlotter is especially useful here because you can sample enough times to make the differences in packet loss and latency at different hops statistically valid. The difference between 2% and 4% packet loss needs at least 500 samples to be statistically convincing - the stock traceroute utility does 3 samples, while PingPlotter allows you to do thousands or more. In reality, you're shooting for 0% packet loss and a reasonable latency across your entire route. When you see packet loss in your route, you almost certainly want to resolve that problem. If the packet loss appears at a link you know is slow, it still needs to be explained and possibly resolved.
If it appears at some other hop, that needs to be investigated too - just because one of your early hops is slow doesn't make that packet loss reading any less important to solve.
The 'weakest link' isn't the right way to see things.Ī weakest link means that it will be the first thing that breaks and you won't be able to see any information about any other links. With PingPlotter, you certainly see the latency and packet loss characteristics for a weak link, but if there's another link (a bit less weak), you also see the performance characteristics for that link, and any other link.Īs for ICMP accuracy, again this is not entirely wrong. There are certainly routers out there that down-prioritize ICMP traffic under heavy load. However, most of the routers on the internet route ICMP just fine - especially when not under heavy load.
Most routers do prioritize ICMP traffic below HTTP (or, voice traffic, or other kinds), but a well-running network is running below capacity.
0 kommentar(er)
