Ciscomania Forums  

Network Capacity Management

This is a discussion on Network Capacity Management within the Routing forums, part of the category; Network Capacity Management - Why Few Do It, but Everyone Should Submitted by michaeljmorris on Wed, 10/24/2007 - 10:45am. I've ...

Reply
 
LinkBack Thread Tools Display Modes
Old 28th October 2007, 05:06 PM   #1
Administrator
 
admin's Avatar
 
Join Date: Jul 2007
Location: New York
Posts: 19
Rep Power: 10
admin has disabled reputation
Default Network Capacity Management

Network Capacity Management - Why Few Do It, but Everyone Should


Submitted by michaeljmorris on Wed, 10/24/2007 - 10:45am. I've been working on global, enterprise networks for over 10 years. During that time I've been exposed to small networks, large networks, dynamic networks built by the military, special purpose networks, the Internet, and so on. In just about every case, these networks shared the same flaw: the lack of a proactive network capacity management program. In the cases where network capacity management was addressed, it was a small attempt, relegated to third-class attention.
However, times are changing. Networks today are becoming critical assets that can differentiate traffic, accelerate applications, and connect critical customers and business partners. Furthermore, enterprise networks are often an open highway for unwanted things - peer-to-peer file trading, Youtube, and gaming all of which costs the company money and contributes nothing. There are large security problems that can be addressed with capacity management. Today, it's more than just "is the network up or down". A proper capacity management program provides the information network managers need to ensure the network is performing as it should.
Like many programs, starting a capacity management program must begin with a policy. The policy documents the goals of the program, it's rules (acceptable bandwidth usage levels, normal network transit delay statistics), and what output the program will provide (reports, alerts, etc). Everyone's policy will be different based on their needs, but it needs to be documented. Think about what you want to do with capacity management, and then document it in the policy.
Most capacity management program, regardless of policy, should include a few broad areas. First, bandwidth capacity, mostly used for WAN circuits, but also applicable to LANs and data centers, is customary. It's also the entry point that most people expect from capacity management. People first want to know how much bandwidth is being used. Device capacity - memory, CPU, buffers, etc - is next. Problems with devices can lead to application problems that are hard to diagnose. Third, is delay management. Network delay, particularly over the WAN, is probably the most impacting factor to applications after packet loss. TCP's acknowledgement process impacts users more and more as delay increases. Automated delay monitoring from every site to the data centers is key. Several tools, including Cisco's integrated IP SLA technology, can do this. Most of the new application acceleration devices on the market will also track delay as they attempt to mitigate its impact on applications.
The two other critical, but newer, areas of capacity management are traffic identification and QoS monitoring. Knowing how much bandwidth is being used is not enough - you must know what is using up the bandwidth. If a circuit is loaded to 95%, but 60% of the bandwidth is Youtube, you probably don't need to buy more bandwidth. However, a traditional bandwidth monitoring tool wouldn't provide this information. You would see an overloaded circuit that needs an upgrade and end up wasting money. Traffic identification tools can show you don't need a circuit upgrade. By far the most ubiquitous traffic identification tool is Cisco's NetFlow (and the IETF IPFIX standard based on NetFlow v9). NetFlow runs on every router so you can see the traffic on every layer-3 interface. There are several good software applications to track and manipulate the NetFlow data, such as NetQoS and Fluke's NetFlow Tracker. Finally, QoS management is required. In the aforementioned Youtube scenario, using 95% of the circuit is fine, provided you have QoS configured to give your VoIP and business applications priority. QoS management tracks queues to ensure critical traffic is not getting dropped. These reports should show not only the drops in each queue, but the utilization in each queue. That way you can see if the VoIP queue is getting close to drops instead of waiting for drops to occur.
__________________
-Admin
www.Ciscomania.net
Offline  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply

« - | - »
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On






1 2 3 4 5 6 7 8 9 10