when to increase bandwidth

[d.higginbotham]

Looking at T1 WAN link bandwidth usage reports, what are the criteria for time to increase bandwidth? When can I justify to the boss that it is time to add another T1?

[jroyster]

decent rule of thumb is if it is consitently over 70% for extended peiods of time - say 15 minutes.

all depends on what the applications are and the expected response times and if there is QoS on the link.

Also if you are getting drops on the interface over 1% it is really congested.

[d.higginbotham]

Thanks for the response. I am seeing above 50% for hours at a time several days out of the month and peaks above 60% on these days for several minutes at a time. The primary apps are CAD and MS Office with a smattering of html based apps like timesheets at the end if the month. I am doing no QOS filtering because not much other the primary apps is running over this link. I am getting complaints from the users so expectation is not being met.

How do I check the percentage of drops on the interface. Please excuse my ignorance and thanks again for the help.

[dgahm]

What apps are running across the link? Are you supporting voice? What QOS is being applied? What does the utilization look like during your peak periods? Are your users satisfied with network performance?

In general, it's time to add bandwidth when your critical applications are not performing adequately. That is a weasel word answer, but there really is no simple, one size fits all rule. You may have a lot of non-critical traffic filling the pipe, but if your QOS is protecting the important stuff it may be perfectly acceptable to routinely discard packets.

Another piece of the equation is cost. If the link is across town and T1s are cheap it might make sense to add bandwidth rather than spend a lot of effort managing congestion. On the other hand, if the link is across the country you would want to be sure you are using the bandwidth as effectively as possible before opening the checkbook to add more.

[d.higginbotham]

Thanks for the response. Yeah that is kind of a weasel word answere but I understand. It's like everything else we do, the answer is almost certainly, "It depends". The link is regional but I am getting no metro discounts on rates. The primary apps are CAD and MS Office files, some html based apps for timesheets, proj. mgt. etc, usually end of month jam but I accept that part of it as monthly anomaly. I am not doing any QOS filtering because traffic other than the primary apps is relatively light. The users are complaining, and it's getting louder. I am seeing peaks reaching above 60% with several hours at a time during the day above 50%, several days out of the month. There is some politics here, of course. The business has already approved the expense but the corp IT director is saying not needed. His first criteria was several sustained minutes above 50% = look at new circuit. His most recent criteria is 90% peaks. But like I said he has a thing about one of the users who has been most vocal about the latency. So..... I am trying to get a feel for when other people decide it is time to increase bandwidth. Would you increase bandwidth given this scenario?

[dgahm]

A good reference book is Top-Down Network Design , Priscilla Oppenheimer, ISBN 1578700698, Cisco Press, 1998. On page 37, optimum average network utilization for a WAN link is given as 70%. By that criteria you are not even hitting the sweet spot yet.

What are you using to monitor utilization? Are those 5 minute averages?

Your challenge is to understand what is happening when the users are complaining. Perhaps there are overloaded servers that are responding poorly, or duplex mismatches in your LAN, or errors are your WAN link causing packet re-transmission, or the router config is not optimum, or perhaps you do need more bandwidth.

To start with you should check for network induced errors. At a time when network traffic is low, do some large continuous pings from a user workstation across the WAN to a server. Use ping -t -l 1500 X.X.X.X to send 1500 byte packets continuously. Let this run for 10-15 minutes. You might check different servers, and use different workstations. Sweep pings from the router on the LAN are also useful for detecting errors, as the router can blast more packets. Are you seeing any errors on your switch and router interfaces?

If the network is clean, enlist the aid of your complaining user. All complaining users love it when you ask them to call you when the network is slow. The best tool to use is a Sniffer on the same LAN as the user, but if you don't have one there are other methods. Set the load-interval on your serial interfaces to 30 seconds from the default 5 minutes. What does the utilization show interface sX/X look like when the user is slow? If it is low have the user ping the server that he is working with. How do the ping times compare with times when the network is fast? If the pings are fast, the server is probably the culprit. A Sniffer on the same LAN as the server will confirm server response time issues.

If the pipe is full when the user is complaining, you need to identify the load. The Sniffer is great, but you can use Net Flow or IP accounting to tell you. If the culprit is a large file transfer, you may need to implement QOS to control that in favor of other apps.

You said you have no QOS. Are you using FIFO queuing or weighted fair? I would strongly suggest using weighted fair queuing. Fair queue does a great job of protecting small packet interactive sessions against big packet file transfers. It is also easy to turn on.

[d.higginbotham]

That's a lot to consider. I just got back in town from a vacation please excuse the delayed response. I will order this book today thanks much for the tip. Thanks again for the suggestions. I will start working on that ASAP. I hope you won't mind if respond back sometime later if (read when) I have more questions. Thanks again for your time and your response.

[dgahm]

Happy to help out -- though rating points given by using the pulldown menu are always appreciated.

Have Fun!