Modular QoS CLI: Configuration of QoS on Cisco Routers

Modular QoS CLI Configuration of QoS on Cisco Routers

Modular QoS CLI (MQC) is the Cisco implementation for configuration of QoS on its routers. Prior to the implementation of MQC on Cisco routers, all configurations were performed at the interface level for QoS policies. In the event that the router had a large number of networking interfaces, this configuration was often cumbersome and time-consuming. With MQC, the actual QoS policy has been decoupled from the interface on which it is applied. Therefore, multiple policies can be configured and do not take effect until they are applied to an interface. The modular QoS CLI implements a simple architecture to configure QoS by the definition of the following:

Step 1.	Identify the interesting traffic (classification) that will map to a traffic class using the configuration of class maps – Interesting traffic definition can be defined to match based on many properties of an IP or an MPLS packet. However, refer to the documentation for the particular product as well as the IOS version prior to implementation and configuration of QoS policy using MQC. In the class map, the interesting traffic is defined using match commands under the class-map configuration. Figure 13-10 outlines the basic options available as well as the configuration procedure on a GSR chassis with 12.0 version of code. Note that the options available on the router might vary depending on the type of chassis and the revision of IOS that you are running on router.   Figure 13-10. Identify Interesting Traffic Note that a large number of options are available under the match keyword for the class-map configuration. The most commonly used ones have been shown in Figure 13-9. Refer to the documentation pertaining to your particular chassis as well as the IOS version for more information on options available at Cisco.com. Note that the not keyword can be used in conjunction with most options available under the interesting traffic definition.
Step 2.	Define the QoS policy to be applied per class using policy maps – The QoS policy applied per class is defined as the PHB for that specific class. This usually includes the functions of congestion management, congestion avoidance, and traffic shaping and policing on a per class basis. It will also define if the specified class requires preferential treatment as in the case of LLQ. Therefore, this is often where you will find the police, shape, priority, bandwidth, and random-detect commands per class. Figure 13-11 illustrates the configuration pertaining to the implementation of a QoS policy using policy maps and outlines the configuration options available for each class under the policy-map configuration.   Figure 13-11. Configure Policy With random-detection, the queue can be configured to selectively drop packets to avoid the queue from filling up leading to tail-drop scenarios. Therefore, the minimum threshold at which the selective drop begins and the maximum threshold before the tail drop are to be configured along with the drop probability denominator, which defines the ratio of packets to be dropped at the maximum threshold. Note that the smaller the drop probability denominator, the more aggressive the congestion avoidance scheme. The most common variables are that the bandwidth command needs to be configured prior to random-detect configuration, as well as random-detect cannot be performed on an LLQ as defined by the priority command mentioned earlier. Hence, random-detection can be done based on Precedence values or DSCP values, and drops can be done selectively or more aggressively based on the Precedence or DSCP values. Policing is the process of identifying if traffic conforms to a certain profile. Traffic not conforming to the profile can be either reconfigured (lowered in priority and class) and transmitted or simply dropped. The important difference between traffic shaping and policing is that packets are not dropped that do not match a traffic profile. In shaping, out-of-profile packets are queued and perhaps re-marked and sent at a later time interval. The shaping can be performed using peak or average rates and usually forms a single token bucket model, but, in some higher end routers manufactured by Cisco, the dual token bucket model is used in which a separate bucket is maintained for tokens matching the committed burst rate and the excess burst rates. The key item to note is that shaping is always performed on egress and not on ingress whereas policing can be performed on ingress as well.
Step 3.	Apply PHB QoS policy per interface using service-policy commands – This final step in the MQC structure involves the application of a QoS policy on an interface (policy map) using the service-policy command. The PHB can be defined either on input or output and can map to different PHBs in either operation. The configuration step is identified in Figure 13-12.   Figure 13-12. Applying Policy to an Interface In this section, you were provided an overview of the configurations possible with the Cisco MQC architecture. For more information on configuration of classification, marking, congestion management, congestion avoidance, traffic shaping, and policing, visit the Cisco online documentation at http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/index.htm.