Hi, David.
It looks like you may be having some route changes too - I say this just because the time graphs are showing the wrong hop numbers. If you're not seeing a regular route change where the route length changes, then please contact us via email so we can troubleshoot why the hop numbers on the time graphs don't match the trace graph.
Moving on from that ... for the rest of this email, when I say "hop x", I mean the hop number shown on the upper graph.
First off, having "Samples to include" set to only 10 makes it a bit tough to have any vision into hops that don't have their time graphs turned on. Setting it to 500 would probably give a bit better vision on the upper graph, since you're only seeing about 5% loss at the final destination (and at 5% loss, there's a pretty good chance will see some statistical trends if we look at 500 samples, but not much chance if we only look at 10).
Hop 5 is showing packet loss, but as you noted, this isn't translating to downstream hops / routers, or the final destination, so that packet loss doesn't necessarily indicate any problem. This is especially the case because hop 6 looks pretty good (although not perfect).
It looks like there is some router between hop 6 and hop 11 that is the reason for the packet loss (and latency!) at hop 1. Because hop 10 shows this problem, we *know* it's not a problem with hop 11 itself. Based on the information I see here, it could be a problem with hop 7, though, or hop 8 (since hop 8 is showing some packet loss and jitter). You'd have to look at the time graphs for all the hops to find the pattern that matches what you see at the final destination (which it sounds like you've already done).
Since your data is staying on the Easynet network, it's pretty easy to point to their network as the culprit here. The fact that hop 6 looks good and hop 10 does not pretty much eliminates your own network as the problem (I'm assuming that the your own equipment is all before hop 2 or after hop 10).
If you were trying to make a compelling case to your ISP in your situation, you want to show time graphs for 3 hops - the final destination, the first hop showing problems, and the first hop before the one showing problems. Ideally, if hop 9 looks good, you'd want to show them hops 9, 10 and 11 (good, bad, bad). Sometimes, though, you'll find that the "good" hop is also one that has its own packet loss reporting problems (like hop 5 does). Hop 9 looks pretty good in your case, though, since it has 10 consecutive samples of 8ms.
Based on what I see here, this shows problems with Easynet relatively conclusively. I'd want to show hop 9. I'd also want to increase my "Samples to include" to 500 or 1000 (or some other 250+ number that shows a good picture of the problem). I'd also want to focus on a time period that is characteristic of problem periods so the upper graph shows a good summary of the hops for the time in question. I'd also want to tie some other application performance problem to the PingPlotter data. If you have reports of an application problem (say, slow Citrix performance or a dropped VoIP call), you can note that on the time graph by right-clicking and "Create Comment". This correlates the network problems you're feeling with the data in PingPlotter, which makes it harder for your ISP to dismiss that as "It's just traceroute - that doesn't mean anything".
You might also trace the other direction and show that you're seeing packet loss at hop 3 (or whatever the hop is) on all outbound data from the other site.
Here is some reference information you may find useful:
If your ISP says traceroute / PingPlotter isn't a good way to troubleshoot:
http://www.nessoft.com/kb/46If you want to look at some good examples of problems / troubleshooting (some with significant similarities to your problem):
http://www.pingplotter.com/tutorial/VoipTroubleshooting.htmlLet us know if this leaves you with questions.
- Pete
Previous Topic
Index
