In the previous discussion on QoS, the mechanisms to implement QoS were identified. In this part of the series MQC will be defined along with the advantages over its predecessors.
Modular QoS CLI
Modular Quality of Service (QoS) command-Line Interface (CLI), or MQC, provides a modular approach to the configuration of quality of service (QoS) mechanisms. MQC is a three-level hierarchical policer that extends the traffic policing functionality by allowing the configuration of traffic policing at three levels of policy map hierarchies; a primary level, a secondary level, and a tertiary level. Traffic policing may be configured at any or all of these levels, depending on the needs of your network. Configuring traffic policing in a three-level hierarchical structure provides a high degree of granularity for traffic policing.
Legacy configurations, such as committed access rate (CAR), required entire configurations to be repeated between interfaces and were very time consuming to configure. One of the many benefits of MQC is the reusability of the configuration. MQC allows the same QoS policy to be applied to multiple interfaces.
The three steps involved in implementing a QoS policy, using MQC are as follows:
- Configure classification by using the class-map commands (Who)
- Configure traffic policy using a policy-map (What)
- Attach the traffic policy to traffic by using service-policy (where)
Classification
Network traffic classification organizes traffic into user defined traffic classes, based on specific traffic match criteria. The result of these groups of network traffic is to subject them to specific QoS treatments. The QoS treatments might include faster forwarding or reduced probability of traffic being dropped due to lack of buffering resources.
These classifications can be associated with a variety of match criteria such as the IP precedence value, differentiated services code point (DSCP) value, class of service (CoS) value, source and destination MAC address, or protocol type values.
Classifying network traffic allows for an easier way to identify different kinds of traffic , organize the various kinds of network traffic into traffic classes, and treat some types of traffic differently than others.
Class Maps
A Traffic class contains three major elements
- A Case Sensitive name
- Match Commands
- Command to evaluate match commands
Map Classes have two modes
- Match All – This is the default, and acts as a logical AND. All conditions have to be met to bind a packet to this class
- Match Any – At least one condition has to be met to bind the packet.
Configuration of a Class Map
class-map {match-all | match-any] class-map-name
match condition
Class Map Example 1
Router(config)#class-map match-all match-ftp
Router(config-cmap)#match access-group 101
Router(config-cmap)#exit
Router(config)#class-map match-all match-www
Router(config-cmap)#match access-group 102
Class Map Example 2
Router(config)#class-map match-fr (remember match-all is the default)
Router(config-cmap)#match fr-dlci 500
Class Map Example 3
Router(config)#class-map match-any cisco
Router(config-cmap)#match protocol ip
Router(config-cmap)#match qos-group 2
Router(config-cmap)#match access-group 101
In my next post on QoS we will explore step 2 in creating a fully defined QoS configuration as shown in the diagram above – Policy Maps.
Author: Paul Stryer
References
- Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
- End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh
- DiffServ – The Scalable End-To-End QoS Model
- Integrated Services Architecture
- Definition of the Differentiated Services Field
- An Architecture for Differentiated Services
- Requirements for IP Version 4 Routers
- An Expedited Forwarding PHB (Per-Hop Behavior)



Very good explanation of QoS topics!