Managing bandwidth needs and consumption is a discipline that has existed since the first 150bps modems connected computer systems together. Today, with multi-gigabit links becoming an everyday reality, we are still facing the same conundrums. Only the number of zeros has changed.
Vess Bakalov, CTO for SevOne Inc., says one thing to remember is that bandwidth and bandwidth management is a means to an end, and not an end in itself. We need adequate performance for our applications and users for the minimum expenditure. To do this effectively, we must first understand what “adequate” means for these users and applications. Only once this often-omitted step is completed can we effectively employ any bandwidth management techniques.
Check out this list of five quick tips on better bandwidth management.
SevOne provides a fast, easy, and scalable network appliance that combines granular performance data from NetFlow, SNMP, VoIP, IP SLA, NBAR and WMI into a single view. This enables IT staff to lower their total cost of ownership, assure service levels and increase productivity.
Click through for five quick tips on keeping a closer eye on your data packets.
Five-minute polling may be alright for much of the infrastructure. It is incredibly inadequate for a critical link carrying latency-sensitive data. A 10-second, 100 percent spike-completely obliterating the SLAs of all critical applications — will be reduced to a 3 percent bump (or even less) on a five-minute polling cycle. Even a 30-second event is going to be reduced to only 10 percent. Being able to poll critical links at high frequencies – 10 seconds or below-will give you the information you need to address transient issues (if you can call an issue lasting 30 seconds transient).
Whether you have sufficient bandwidth or not, what really matters to the majority of today’s applications are the latency and jitter characteristics of the link. With modern queuing technologies, even high bandwidth utilization may not have an adverse impact on the quality of the services provided by the link. Technologies such as Cisco IPSLA and Juniper RPM can help continuously monitor these very important KPIs at very good resolution. Since you can use these technologies to run tests that look like the real applications (HTTP, DNS, specific ports and not just ICMP), the traffic generated by them will be queued and treated as if it is the real thing-giving you a very accurate picture. Monitoring them continuously can help build good baselines and spot deviations immediately.
NetFlow, jFlow, sFlow and all of their brethren have one thing in common-they can help you understand what makes up the traffic causing your bandwidth utilization. Without the need of probes or sniffers, you can quickly and continuously monitor the makeup of the traffic traversing your most critical links. This will allow you to quickly spot bandwidth hogs and wasteful traffic, and give you an understanding of the applications using your network. Having this understanding is critical in deciding how to best prioritize traffic and furthermore to create policies that eliminate wasteful traffic (torrents, inappropriate streaming media, etc.).
Once you have a firm understanding of the traffic on the network, the next logical step is to classify it and prioritize it. This will allow truly important traffic to fly unencumbered even in high bandwidth utilization conditions, while the rest waits for the best effort service. Monitoring the utilization of the queues is key for verifying your configuration (which can often be complex), and for the process of continuous optimization. Baselining the performance of each queue and alerting when anomalies occur before the entire circuit is affected will let you be proactive. Comparing the configuration of the QoS queues with the information derived from NetFlow will ensure that your enterprise applications are always given the level of service they require.
Trending and baselining bring automation and proactive prediction that most other techniques miss. Using highly granular baselines (15 minutes or under) over predictable business intervals (seasons, months, weeks) can allow us to quickly spot deviations from norm before they affect the performance of applications and the quality of the user experience. Trending, on the other hand, lets us predict what may lie in the future, based on granular historical data. Generally, in order to have a meaningful prediction, a significant amount of historical data should be available-about six times the length of the interval we are trying to predict (e.g., for a one-month prediction, we need about six months of historical data). This data must be granular (preferably raw/non-aggregated) so that the statistical analysis can be as sophisticated as possible-accounting for peaks, valleys and repeating patterns.
