Slow Terminal network traffic over VPN

The "on occasion" is very vague. I also have users at 5 remote offices (2 WAN's (384kbs no guarentee) and 3 56K lines) that telnet to our unix server. That complain about lag "on occasion".

What to watch for is the specific "times".
I have found that the "LAG" is tied directly into how busy the server is. If there are lots users generating reports (as we have in the morning) you will notice some lag.
The more processing the server is doing the slower its response time will be. Even on the LAN.

It could be your connection because there is no such thng a "guarenteed".
If you have access to the remote computers you could create a simple batch file that pings the server every 30 minutes and see when this is happening. This may help to confirm if its the server load.

What is the average pig time??
I have a 35ms average response time from my cable connection to my server on the net on the servers 128k connection. Which is normal for me.

And as bm stated, encrypting the data will increase the time somewhat. Our WAN's and 56k dont use encrytion so I cant recommend a particular one. But changing the level of encryption might help. Especially if the computers are doing the encryption.

Also one other question would be is it all the computers at the site or just one? If its only one, it could be tied to what ever else the user is doing on their computer.

Lars,

Whats the latency between your clients and the server? I doubt that the VPN tunnel would have any impact on latency when dealing with telnet. Telnet is very light in terms of bandwidth usage (and hence stressing an encryption CPU).

As stated above, telnet does not initiate a new session per keypress. One tcp connection is initiated on initial startup. However each keypress is individualy sent across the wire, and requires acknowledging. If it is a Cisco router, there is a service that you can enable to "help" speed up applications like telnet, and this is called "nagle" (nagle algorithm). You can enable this by typing "service nagle" under global config, however I am not sure if this will actually achieve what you want. For more info look at: http://www.cisco.com/en/US/products/sw/iosswrel/ps1826/products_configuration_guide_chapter09186a00800d9b69.html

It basically packages lots of keypresses up and sends them in one packet.

I would more inclined to look at the server CPU etc at the times the service is slow. Or(and/Or) look at the latency at this time (i.e. do a ping). if the RTT is more than 100ms then users will notice a lot (in my experience)..

Bandwidth with telnet will do very little.

Best regards (and luck)

j3ggs

Just in case, check that the output from the following is the same on both ends of the VPN:

show crypto ipsec sa | include mtu

If it's not the same, then you have three options - one is to set the router with the larger MTU to have the smaller MTU on its outgoing interface (eg in BVI 1 ; ip mtu 1492), second is to use a route-map that clears the df bit, eg I use ACL 130 to define traffic for one VPN where one is DSL bridge mode, the other is DSL PPPoE:

route-map clear-df-bit permit 130
 set ip df 0
interface Ethernet 0
 ip policy route-map clear-df-bit

The third is to use the most excellent DF bit override from Cisco:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087ae1.html

I don't think this is your problem but it's definitely worth a check.