Bandwidth utilization: determining when to upgrade
I recently received a graph showing some utilization above 60% on some of the links for my organization. I seem to remember that a network link is considered saturated at around 40% of its bandwidth; does this sound correct? Is there a rule of thumb to judge these graphs in terms of utilization and determining the need for an upgrade?
Software/Hardware used:
Software/Hardware used:
ASKED:
January 16, 2008 9:36 PM
UPDATED:
January 22, 2008 7:31 PM
Answer Wiki:
It depends on the length of time and how high the link is saturated. Short periods of 60%+ utilization may not be a bad thing and may be usual for your network. However, if the link stays at 60%+ for all of the business day then the link may not be able to burst up to full capacity when that capacity is really needed. Questions to ask yourself include:
Do my users notice when the link is saturated 60+%?
What applications am I running that may experience problems during periods of high utilization?
Am I adding additional applications/users that may cause or see problems due to high utilization?Am I seeing lots of retransmissions or packet loss on the links?
What are my utilization trends? Rising? Constant?
To see all answers submitted to the Answer Wiki: View Answer History.
What is the average utilization on these links and what are they used for? Are people complaining and does the connection seem slow or is it performing satisfactory? Periodic spikes of 60% are not of concern unless it’s sustained. It could just indicate someone transferring files from your server or downloading from the internet (depending on what the link is used for), since these protocols try to use as much bandwidth as possible.
I have a threshold setup on my monitoring software to send me an email alarm if utilization is above 70%. It usually ends up being somebody copying from file shares or downloading from internet.
Are you running QoS on any of these lines?
From my point of view, the main question here is: do your users care? That’s not always easy to answer, so here are some techniques I’ve employed in the past to get a handle on this.
Know the Application
If you are using this link to provide connectivity to the Internet and the saturation occurs during lunch time and after 5pm, that’s a whole different problem from, say, providing connectivity from a branch office to an ERP application hosted at a global data center. The latter is far more important for productivity, and so a slow or congested link there will hit your bottom line faster than delays in surfing on the lunch break.
Measure Application Performance
Once you know the application, set up a response time measurement to see how long basic operations take. As a simple example, you can start with load times of the login page (if it is a web application), and just track that over time. Put this graph up on the same screen as the bandwidth graph to see if the saturation is really affecting performance of the application. There are lots of tools that can do this kind of measurement and graphing.
Know the Traffic
As was mentioned, if you have QoS measures for this link, use them to prioritize the traffic that you care about. Most QoS systems incorporate monitoring software to tell you what the traffic is composed of, but this is also relatively simple to obtain with commonly available tools, such as ntop or pmacct (http://www.pmacct.net/).
If, after taking these steps, or somewhere in the process, you realize there is a problem, consider that bandwidth may be cheaper than further analysis. As with all management decisions, know the cost of doing nothing and the cost of the simplest solution before you open the checkbook.