Networking Question

Three things: A) Make sure your network guy is watching the bandwidth (at a close interval) via something like mrtg or netflow, and try to figure out if the response times correspond with high bandwidth utilization. If so, consider bucketing or throttling your big traffic users (I'd have to guess email/outlook if your server is remote from your location), but would also keep an eye out for internet or ftp traffic. B) Look at QoS to help either prioritize certain traffic (telnet), or limit the usage of your heavy hitter applications. This can be done by source, destination, network, port, etc. Your network engineer should be able to help here. C) If bandwidth doesn't appear to be the issue, you need to escalate with your provider. If your latency is going to 400+ms and is not related to your usage, then there is no excuse from the provider.

One last thing, are you using the VPN over the t1? If so, why? Is the t1 to the internet (then it would make sense), or is it private? Either way the VPN should not add too much processing or latency to a single t1, but something to watch since you only have a 2811. Again, I don't suspect this, but something to keep in mind.

You need to implement QoS on the router. Create three queues, high, medium and scavenger. Place your telnet application in the high queue, your VPN traffic (any traffic that is destined for the corporate office) into the medium queue, and your internet traffic (everything else) into the scavenger queue. Telnet is not high bandwidth, so allocate the minimum bandwidth (5% or 64k or something like that), 65% to the medium, and the rest to scavenger (or any other numbers that you think are appropriate.) The bandwidth numbers only count when you have congestion, and even if you have congestion, any bandwidth that is not used by the queues can be used by the others if they have exceeded their allocation. If you still have "slowness" with telnet after implementation, you may have to change the "high" queue to a priority queue, but I doubt this since you have a T1. With a priority queue, any traffic in that queue is ALWAYS sent before any other traffic and the bandwidth you allocate to it will ONLY be used for the priority queue. So if you allocate 64K, that bandwidth is always reserved even if you don't have any priority traffic. Priority queues are generally only used for voice traffic where jitter is problem.

Telnet can send one character at a time unless the TCP stack supports the Nagle algorithm and that it is enabled.

for example Windows Sockets applications can disable the Nagle algorithm for their connections by setting the TCP_NODELAY socket option. Also tuning server TCP stacks may help.

You could load WireShark (free packet sniffer) onto one of the PC used for the telnet application and capture a session to see how many characters are being packed into each outbound packet.

This may be "bit bucket delay" if AT&T has you on a frame relay circuit. Are the sites geographically distant? Telnet will drive users crazy if the RTT (Round Trip Time) is over 100mS and frame relay is known for this problem (so is Satellite). If the T-1 is using Frame then look at the CIR (Committed Information Rate), BIR (Burst Information Rate), and any guarantees on the RTT. The config on your Cisco 2811 will indicate if frame is in use on the link to your router. Nonetheless, Frame Relay could be in use further down the link---the providers are very good at using the least cost link and Frame is cheap and very susceptible to over-subscription causing the large discrepancies you see in RTTs. Hold their feet to the fire on any Service Level Agreement in place.

When you say T-1 with VPN through the AT&T network--this sounds as though your traffic is transported across the Internet (else why the VPN?). In case the VPN is in place due to your data travelling across the Internet--you have no control since the Internet has no QOS guarantees, and I would expect slowdowns in the 10 to noon and 1-3 pm local time frames with peaks at 10 am and 2 pm.

Nonetheless, if your users are using a significant portion of the available bandwidth--increase your bandwidth...No free lunch..

Doug Stigall Sys Analyst Digital Machines Corp. Doug@!@noSpam. DMCTX.com

rEmove !@noSpam. to reply

Thank you all for the replies.

Can a 2800 series Cisco router do priority queueing such as high- medium-low? The network guy at our corporate office supposedly implemented QoS but not I'm not sure to what level. I've had conflicting reports as to what he's tried. I'll send him a message to see if I can find out exactly what he tried. I do have one email where he's said that "... policing HTTP to limit it to 20% of the T1 at the serial interface, inbound."

Here's a little more (clearer, hopefully) information on our setup. We have a T1 at our site through AT&T. I believe we're using MPLS and have a VPN connection to the corporate office as well as our sister offices. We also have Citrix for some applications (hosted at the corporate office) and our Exchange servers are hosted at the corporate office. The server we're connecting to via telnet is at the corporate office and is accessed through that VPN connection. I checked with Wire Shark and it doesn't seem like the telnet app is sending one byte at a time. The several times I've had a user say "The telnet app is slow!" I've gone in and checked - bandwidth usage spikes and so does response time. Due to Internet traffic and possibly high Exchange server traffic at that moment.

Our corporate office says we aren't using the full bandwidth of our T1 but I think that we're seeing slow response time because of sudden spikes. I think that policy on HTTP traffic may be the only policy that was put into place and then we had users complain of the telnet app being slow AND Internet traffic being slow. So I'm thinking it's not just HTTP traffic causing the problem.

We have some web tools that show bandwidth usage and another tool that shows response times on the T1 line so I think I'll need to look at both and identify what app(s) are causing response times to go too high.