I might be misunderstanding what you're using for a trace target here, but routers should generally *not* be targets for PingPlotter. Since you never actually send application data to routers (just through routers, based on the routing tables of providers), the data you collect by targetting a router is generally discounted (with reason) by anyone you might send troubleshooting data to. You really want to target a final destination that you're using, and look for packet loss and latency patterns there.



The pattern you describe here can often be correlated with a problem in the *return* route. Unfortunately, the internet protocols we have available to us today don't give us an opportunity to investigate the return route. Each router along the way has its own routing table to determine which route it sends packets down. In *many* instances, the decisions made by an intermediate router will return packets on a route different than the final destination will. When this occurs, you'll often see situations similar to what you are. An additional complication in this, however, is that sometimes organizational standards set up ICMP priorities such that a router (or group of routers) will drop packets - sometimes on purpose, sometimes because of priority issues. It's relatively difficult to say exactly what is causing this without tracing the return route from the router in question.

Since this is only occuring when you target one of the oscillating IP addresses, you should probably just ignore that data and move back to tracing the final destination. Internal routers often respond poorly to ICMP requests, even when they pass data through just fine.



I suspect that you're tracing from you back to your clients. Although this can often be extremely useful as a technique, at many other times, you have to trace directly from the PC experiencing problems out to the target they're having problems with.

One technique our customers like you have had significant success with is to have their customer run PingPlotter for the course of a day. If their customer experience outages, go to PingPlotter and add a comment by right-clicking the period in the time graph where they experienced the outage, and entering a comment like "lost connection here". The 3 hour graph works pretty well for this as it only shows 3 hours and gives them enough detail to pick the right time period if they don't create a comment immediately.

If they experience outages during the day, at the end of the day (or at some period), have them save the data in PingPlotter, and then email the resultant .pp2 file to you (it's already compressed, so no need to .zip it up first unless you have email filter reasons for doing so). Once you get the file, you can try to correlate packet loss or latency numbers with their noted outages, and try and determine which hop is causing the problem. In an enourmous number of cases similar cases (a vast majority), you'll see that the problem exists in their network, in their connection to the internet, or someplace *very* close to this point. The information from PingPlotter will help you pinpoint which hop, and from there you can make suggestions about contacting their ISP, checking for excessive bandwidth usage on their network (see here for a discussion on that), replacing some piece of internal hardware, or some other action, depending on where their problem originates.

- Pete