I am having a problem with Terminal Services connection. One of my clients has a Terminal Server which a remote office connects too. They have been getting disconnected from the Terminal Services connection for a few weeks now. I ran pingplotter over several days and noticed some pretty severe packet loss.
http://img50.imageshack.us/img50/9788/671298043rdslktccombh1.png

After tracking for several days and logging disconnect times. When the client recieved packet loss they would get disconnected from their Terminal Services Session. I sent the ISP images of pingplotter results. The ISP had me run several ping and tracerts and send the log to them ping showed zero packet loss over a 45 minute period. Tracert worked without problem as well.

Ping statistics for 67.129.80.43:
Packets: Sent = 1507, Received = 1507, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 89ms, Maximum = 180ms, Average = 94ms

I know packet loss is happening and causing the disconnects from Terminal Services as I temporarily hosted another terminal server on a different ISP and had no disconnection problems. It seems to be the particular route that the information is taking that is causing the problem. Any route involving level3.net seems to cause disconnections. The ISP claims there is no problem with the circuit.

The interesting thing is if I do a Pingplotter from the Server to the clients static ip they have a few high spikes but NO packet loss. The ISP is trying to tell me its my router. Any ideas on further steps I could take before just switching ISP's for the whole organization?
http://img50.imageshack.us/img50/8654/mnsfinalwe8.png

Those images were pretty small, so I couldn't see much detail, but ...

It looks like there's a lot of packet loss at intermediate hops, and a little bit of packet loss at the final destination. The final destination is really the only relevant hop, as far as packet loss goes. If there is no packet loss at the final destination, then any loss at the intermediate hops may hint at problems, but isn't strong enough to prove anything.

We talk about this here:

http://www.nessoft.com/kb/24

If packet loss is occurring at the final destination (and it does look like you're seeing some, although I can't see much because the shots are pretty small), then you look at intermediate hops.

If you send the collected .pp2 data to support@pingplotter.com, we'll take a look at it and see if we can come up with a picture that's a bit more compelling of the problem. Ideally, you'd be able to correlate packet loss at the final destination with a lost connection (so please let us know any documented times of lost connection as well).

The fact that the ping -t results are different than what you're seeing in PingPlotter is a bit odd, but being able to look at the .pp2 data may give us some insight into this as well. We talk about some possible reasons here:

http://www.nessoft.com/kb/37

One thing I'd do is to switch to a different protocol (TCP, to your WTS port, for example) to see if the final destination results change at all.

It actually sounds like you have some pretty good evidence - where a lost connection can be correlated to packet loss. Maybe the pictures you posted just don't show that very well. If that's the case, send us the .pp2 data and a list of disconnects and we'll help you put together a more compelling picture for your ISP.

- Pete

Sent email with log files and thanks for the help.

By the by, I've been seeing issues with level3's transcontinental routes over the past few days. Supposedly they had a fibre cut somewhere (this according to my speakeasy rep) which was resulting in PL.

Not sure if it has cleared up today or not. Not on location where I saw the PL and actually stopping by here to find the remote agent which seems to be missing from downloads.

The remote agent is available on the remote agent documentation page:

http://www.pingplotterpro.com/remote_trace.html

- Pete