Hi All,

I loaded ping plotter troubleshoot some connection problems bettween a PA and NJ site. I loaded ping plotter on a workstation in each location and told them to trace to the firewalls of the remote location.

When I see packet loss on either side pingplotter show the loss at the remote site.

10am PA to NJ pingplot shows 10% packet loss near the NJ firewall

10am NJ to PA pingplot shows 10% packet loss near the PA firewall

It is like pingplotter is always blaming the other end of the connection for the problem.

I was hoping to see packet loss at the same hop not on oposite sides.

Any ideas on why I am seeing this mirroring?

Troy

Hi, Troy.

Is there any way you can show a picture of what you're seeing? If you want to email some shots to support@pingplotter.com, we'll post them to this thread and then do some analysis.

It *could* be because the outgoing and returning routes are different (I'm speculating here). If that's the case, then an outgoing route wouldn't show any loss until the return route hit the *bad* router / route. In this case, you'd see results similar to what you're seeing.

So let's say you have hops two firewalls A and Z. The path from one to the other uses A -> C, E, G, K and M -> Z (I'm just picking letters here!), and the path back *might* use exactly the same route, or it might use Z-> M, L, H, F, D, B, A. If you have a problem at router B, then any time router B was involved, there would be packet loss. Router B might *not* be involved, however, when your TTL causes packets to expire at K - in which case the router at K (which is never involved in the return route on the first return route we just talked about) might decide to return through G, E, C, A while the router at M decides to use a router that includes B. Confused? Lots of letters here, but know that any router in the path might decided to use a different return route - and the return route might be causing the problem.

Examples (this is a possible scenario, not the real one!)

Packet makes it all the way to destination:

A -> C, E, G, K, M -> Z -> M, L, H, F, D, (*B* CULPRIT) -> A

Packet only makes it to K (Hop 4) and then returns to tell us about hop 4's latency:

A -> C, E, G, K -> TTL = 0 -> G, E, C -> A

Now, when you start at Z, you get something like this:

Z -> M, L, H, F, D, (*B* CULPRIT!) -> A -> C, E, G, K, M -> Z

When starting at Z, as you go through the route, the earlier hops don't use B because it's further down the route. When starting at B, the remote side makes a decision to use a route that includes B, while none of the closer routers do.

If this is the case, then one way to find which side is really the problem is to trace to a completely different router and see if one of the traces still shows the same packet loss. If so, then this packet loss indicates which router has the problem. Since it's the return route, you'd be able to pick out the likely culprit by taking the data from the side that isn't seeing packet loss (except when tracing to the other side) - and the router that is losing data in a trace from that side to the other is the likely culprit. Wow - this isn't easy when we're working in theory (this the request for data).

So, steps.

Find a target that only loses packets from one of your sides. Then, trace from the side that didn't have packet loss to that target, back to the one that did have packet loss (when going to a third party site). The router that *this* trace shows has packet loss is the likely culprit.

If you send or post some pictures, we can try to put some specifics around this.

- Pete