Improve network performance using carefully developed quality-of-service policies.
Quality of Service (QoS) offers administrators the ability to prioritize certain data traffic as it traverses a corporate network. But in order for QoS to work, a great deal of planning and coordination must happen first. If your network is struggling with bandwidth and latency issues, make sure you follow these best-practice guidelines for achieving better bandwidth management using QoS technologies.
Before you begin developing QoS policies, it’s important you perform a network assessment. An assessment will provide valuable information as to the current state of the network and provide a baseline for the types and quantities of data flows being processed today. It’s the fastest and easiest way to identify areas of congestion, network misconfigurations, and any other network issues that might impact the usefulness of an end-to-end QoS deployment. For example, a network assessment may identify outdated or non-enterprise grade network hardware that is not QoS capable. Another common discovery are bottlenecks that can be eased through the use of link aggregation.
Once the network assessment is complete and issues remediated, the next step is to identify what network traffic is considered important to the business, and then categorizing data flows into specific classes. For example, protocols that perform dynamic routing duties should be considered absolutely essential and thus given the highest priority on the network.
Next, you can categorize latency-sensitive data flows such as voice and video conferencing, then standard applications that are considered mission-critical by the organization. This categorization process continues until you reach data streams identified in the network assessment that provide little or no benefit to the organization. General web surfing would be placed in this last category.
While network administrators can assist with identifying applications and data flows, it’s important that the business leaders drive the categorization of applications. Remember, QoS works by providing preferential treatment of one type of data flow at the expense of others. Therefore, it’s the business leadership that should provide insight into the prioritization of applications. Requiring business leaders to organize apps into specific categories based on importance will help to alleviate any political headaches down the road.
It’s also useful to look at data flows that are not critical and could potentially be removed entirely. Instead of using QoS to potentially drop this type of traffic when congestion occurs, it’s often better to eliminate much of this traffic using alternate methods. Whether you implement and enforce end-user network usage policies or rely on technologies such as layer 7 firewalling or content filtering, eliminating the majority of this type of traffic will help to alleviate bandwidth constraints without the need for QoS.
After your data flows have been loosely broken down into categories based on latency requirements and business importance, your next task is to place these applications into one of several classes. A QoS class is the actual policy configuration performed on network switches and routers. While you might be feel inclined to configure a wide range of QoS classes to provide highly defined QoS policies to each data flow type, the opposite approach is actually more effective. Much of the complexity and management overhead involved in a QoS strategy has to do with maintaining each class and the policies to which they are attached. Therefore, the fewer number of classes you create, the easier the deployment and ongoing maintenance will be.
In a QoS implementation, it’s best practice to identify and mark network traffic with a QoS class identifier as close to the source device as possible. In some cases, the application may be able to tag packets for you. Then it’s just a matter of trusting that classification marking. In other cases, you can configure network access switch ports to identify the data (usually using a combination of source/destination addresses and port numbers) and mark it while it’s egressing the switch. Keep in mind that these actions require processing power and R
AM to accomplish. Therefore, make sure to monitor CPU and memory usage on network devices once a QoS deployment is rolled out into production.
Finally, be aware that QoS is a not a one-time setup. Instead, it’s a continuous process that must be closely monitored and audited to ensure it’s working as intended. At a minimum, you should perform an annual network assessment to re-baseline the network hardware/firmware and to spot changes in application usage and data flows. This information can then be used for network upgrades or to re-categorize applications or QoS policies. QoS should be considered as fluid as the data that traverses the network. That’s why it’s so crucial that QoS be monitored and adjusted to adapt to the various changes that arise.
