Planning and Implementing Quality of Service Policies
The process of creating Quality of Service (QoS) policies can be broken down into three steps:
- Step 1: Identify network traffic, baseline behavior, and service-level requirements
- Step 2: Divide traffic into application classes
- Step 3: Define QoS policies for the application class to meet service-level requirementsStep 1: Identify network traffic, baseline behavior, and service-level requirementsPerform a network audit using the QoS historical views to identify traffic types and volumes. LiveNX provides this functionality through the monitoring graphs. Then, perform a business review on the priorities and specific requirements for the discovered traffic.
Step 2: Divide traffic into application classes
Traffic can be divided into classes based on the identified traffic and the business requirements. The Cisco baseline model, which consists of 11 classes, is designed to provide granularity for various class types with different service requirements. Each type of class may have unique QoS requirements that must be configured and monitored. For initial QoS deployment, a smaller 4- or 5-class model can be used to simplify the process. The model can easily be expanded over time as additional applications and requirements arise.
Step 3: Define QoS policies for the application class to meet service-level requirements
QoS policies should be designed from high-level requirements to meet specific objectives. Once the requirements are understood, they can be translated to QoS best practices for the various application types.
- Some best practices include using DSCP markings and marking the packets as close to the source of the traffic as possible.
- Recreational or Scavenger traffic should be policed as close to the source as possible to prevent unnecessary bandwidth usage ifit exceeds a certain threshold.
- Critical applications should be ensured through class definitions to meet service level agreements.
- A majority of the traffic will be classified as default, so enough bandwidth should be provided to support this type of traffic.
- Real-time traffic should use priority queues and be assigned adequate bandwidth. However, you should limit the overall priorityqueue to 33% of the available bandwidth to prevent starving other application traffic.
- The total bandwidth allocation for classes other than default should not exceed 75% of a link’s capacity, to account for Layer 2overhead and Best Effort traffic.
WAN Link Shaping
QoS polices for WAN aggregators typically configure various queuing, marking, shaping, policing, and link fragmentation settings. In most cases, there is a link-speed mismatch between the internal network speed and the external WAN link speed. In such cases, the best method is to use a hierarchical policy where the QoS policy is shaped to the link capacity of the WAN.
Creating a hierarchical WAN link-shaping policy involves creating a high-level (parent) shaping policy and then associating it with a lower-level (child) policy that actually defines the classes. In the following image, the high-level parent shaping policy basically consists of a class default that has an average shaping value set to the link capacity. A standard 11-class base child policy is then associated using the hierarchical policy dialog box, or by simply dragging the child policy onto the class default of the parent.
When applied to an interface, this policy forces the interface to shape all outgoing traffic to the class default shaping. Once shaped, the lower level QoS policy enforces the bandwidth requirements based on the shaped value and not the raw interface speed itself.
The easiest way to set up a hierarchical policy is to use the template-creation wizard built into the LiveNX software to guide you through the process of automatically creating a hierarchical policy.
VoIP QoS Policy Creation
A voice call tends to be classified as RTP protocol; unfortunately, there are many other applications that also use RTP. One of the ways to classify voice traffic managed by Cisco Call Manager, Cisco Call Manger Express, and Asterisk Call Manager, is to use a custom NBAR classification.
Select Manage NBAR from the QoS device right-click context menu.
- Select Manage NBAR from the QoS device right-click context menu.
- Manage Ports dialog will popup. On the Manage Application Recognition (NBAR) tab, click Create Custom Protocol.
- This will bring up a dialog box in which the name, protocol type, and port information can be entered.
When completed, the command ip nbar custom voip udp 13960 16304 will be issued to the device. Once the custom protocol is created, it is available for use by the NBAR engine and will show up in the monitoring graphs.
On the Manage QoS Settings screen, create a class for the VoIP traffic using the newly-created NBAR VoIP protocol.
4. Create a policy based on the Cisco 11-class model using the template wizard. The class can use the VoIP class created in the previous step, and the various QoS settings can be configured.
5. On the Marking tab for the Voice class, set the DSCP marking to 46 (EF) to differentiate the traffic.
6. Set up the voice class as a priority queue and reserve bandwidth based on the requirements for voice traffic. Policing and header compression for RTP traffic can also be enabled if desired.
7. Create a separate class for the voice signaling protocols. The image below shows a voice signaling class with NBAR-based matches for SIP, Skinny, and H.323 protocols. The queue type can be set up as class-based queuing, and bandwidth allocation can be determined from the system baseline. When marking voice signaling, the DSCP value should be set to CS3.