These days, Quality of Service (QoS) can be configured relatively easy. If we’re using the APIC-EM as a network controller to manage our routers and switches, we can simply point and click our way through the EasyQoS utility and have a very robust QoS configuration applied to our devices. Even at the command line interface (CLI) of a router a switch, we could invoke the power of AutoQoS VoIP (to optimize QoS settings for voice traffic, or (just on routers) AutoQoS for the Enterprise (to discover network traffic patterns and create a customized QoS configuration to reflect our network’s specific characteristics).
However, what if you need to make an adjustment to such dynamically generated QoS settings? If you examine the underpinnings of any of these QoS automation tools, you’ll see they all use the same approach to configure most (of not all) of their QoS settings. This approach is called Modular QoS CLI, or MQC for short. So, even if you intend to use automated QoS tools for the bulk of your configurations, I still posit you need to have an understanding of the MQC approach to QoS configuration, in the event you need to modify, or simply better understand, one of your autogenerated QoS configurations.
That’s the goal of this blog post, to give you a better understanding of the 3-step process involved in configuring QoS using MQC. Also, this post will equip you with collection of verification and troubleshooting commands.
The main reason knowledge of MQC is critical for network professionals is that MQC is the way we configure almost all of our QoS features (with the rare exception of something like a Link Fragmentation and Interleaving (LFI) configuration, which does not use MQC). Consider some of the QoS features that can be configured using the MQC approach:
Now that we have a basic understanding of some of the QoS features configurable with MQC, let’s go through an example where we actually use MQC to configure a router with a collection of these features.
The first thing to understand about MQC is that it’s performed in three distinct steps:
This example illustrates a sample configuration using these three steps:
HQ-ROUTER#conf term
Enter configuration commands, one per line. End with CNTL/Z.
HQ-ROUTER(config)#class-map match-any EMAIL
HQ-ROUTER(config-cmap)#match protocol exchange
HQ-ROUTER(config-cmap)#match protocol pop3
HQ-ROUTER(config-cmap)#match protocol smtp
HQ-ROUTER(config-cmap)#match protocol imap
HQ-ROUTER(config-cmap)#exit
HQ-ROUTER(config)#
The above Class Map name of EMAIL is case-sensitive, and I personally use the practice of capitalizing the names of all Class Maps and Policy Maps I create. That lets mean quickly spot things in the configuration I’ve named, as opposed to some Cisco IOS keyword. Also, notice the use of the match-any option. This tells the Class Map that a packet will be classified into this Class Map if it meets any of the matching criteria. By default, a Class Map uses the Boolean logic of match-all, meaning that in order to be classified in a Class Map, a packet would have to match each of the specified criterion. In this example, however, a variety of e-mail packet types are classified into this one Class Map. Also, note the protocol keyword used as part of the match command. That keyword uses NBAR to recognize the signature of the specified protocol.
HQ-ROUTER(config)#class-map VOICE
HQ-ROUTER(config-cmap)#match protocol rtp audio
HQ-ROUTER(config-cmap)#exit
HQ-ROUTER(config)#
In our second Class Map, we’re classifying voice over IP (VoIP) traffic. Notice the absence of the match-any or match-all qualifier in the class-map command. As mentioned previously, the default logic is match-all. However, since we have only one match criterion in this Class Map, there’s no need to specify any alternate logic. Finally, notice the keyword of audio in the match command. This qualifier helps us categorize just VoIP traffic into the VOICE class, since video streams also use Real-Time Protocol (RTP).
HQ-ROUTER(config)#class-map match-any WEB
HQ-ROUTER(config-cmap)#match protocol http
HQ-ROUTER(config-cmap)#match protocol secure-http
HQ-ROUTER(config-cmap)#exit
HQ-ROUTER(config)#
In our third Class Map, we’re categorizing both HTTP and HTTP traffic into the WEB Class Map.
HQ-ROUTER(config)#class-map SCAVENGER
HQ-ROUTER(config-cmap)#match protocol bittorrent
HQ-ROUTER(config-cmap)#exit
Although BitTorrent is used for many legitimate purposes, let’s assume that in this example, we’ve had issues with employees illegally downloading movies using BitTorrent, and we want to restrict it’s bandwidth.
HQ-ROUTER(config)#policy-map DEMO
HQ-ROUTER(config-pmap)#class EMAIL
HQ-ROUTER(config-pmap-c)#bandwidth 512
HQ-ROUTER(config-pmap-c)#random-detect dscp-based
HQ-ROUTER(config-pmap-c)#random-detect ecn
HQ-ROUTER(config-pmap-c)#exit
We begin by creating a Policy Map named DEMO. From there, we use the class command to enter policy-map-class configuration mode for the Class Maps we configured in Step #1. First, we go into policy-map-class configuration mode for the EMAIL Class Map. The bandwidth command (which enables the CB-WFQ queuing feature) uses kbps as its unit of measure, and here’s what the bandwidth 512 command is saying: "Give this class of traffic at least 512 kbps of bandwidth if it needs that much, and give it more if it needs more, and more is available." The random-detect dscp-based command enables WRED, and tells WRED to make its packet dropping decisions based on packets’ DSCP values, as opposed to IP Precedence values. Note that the random-detect command cannot be given to a class of traffic until you first apply the bandwidth command to the traffic class. The random-detect ecn command is then used to enable WRED’s Explicit Congestion Notification feature.
HQ-ROUTER(config-pmap)#class VOICE
HQ-ROUTER(config-pmap-c)#priority 256
HQ-ROUTER(config-pmap-c)#exit
Next, we enter policy-map-class configuration mode for the VOICE class of traffic. The priority 256 command (which enables the LLQ queuing feature) is saying: "Give this class of traffic 256 kbps of bandwidth, but no more, and send packets in this class ahead of other packets."
HQ-ROUTER(config-pmap)#class WEB
HQ-ROUTER(config-pmap-c)#bandwidth 768
HQ-ROUTER(config-pmap-c)#random-detect dscp-based
HQ-ROUTER(config-pmap-c)#random-detect ecn
HQ-ROUTER(config-pmap-c)#exit
Next, we configure CB-WFW for the WEB class of traffic, using the same basic commands (with the exception of bandwidth amount) as we used for the EMAIL traffic class.
HQ-ROUTER(config-pmap)#class SCAVENGER
HQ-ROUTER(config-pmap-c)#police 128000
HQ-ROUTER(config-pmap-c-police)#exit
HQ-ROUTER(config-pmap-c)#exit
HQ-ROUTER(config-pmap)#exit
Finally, we use the police 128000 command on the SCAVENGER traffic class (i.e. the traffic class containing the BitTorrent traffic). Interestingly, the units of measure for the police and shape commands is bps, as opposed to kbps used by CB-WFQ and LLQ. This command says: "Drop any traffic in the SCAVENGER class that exceeds 128 kbps of bandwidth."
Step 3: Apply the Policy Map
HQ-ROUTER(config)#int gig 0/1
HQ-ROUTER(config-if)#service-policy output DEMO
HQ-ROUTER(config-if)#end
HQ-ROUTER#
While we can get fancy, and do things like nesting one Policy Map inside another, we commonly (as is this example) apply a Policy Map to an interface. Here, we’re applying the Policy Map named DEMO to packets leaving (i.e. coming out of) interface Gig 0/1.
Let’s consider the three primary commands used to verify and troubleshoot an MQC configuration:
This command displays information about the Class Maps configured on the router, along with information about what traffic types are classified in each Class Map. Here’s the output from our example:
HQ-ROUTER#show class-map
Class Map match-any class-default (id 0)
Match any
Class Map match-any EMAIL (id 1)
Match protocol exchange
Match protocol pop3
Match protocol smtp
Match protocol imap
Class Map match-any WEB (id 3)
Match protocol http
Match protocol secure-http
Class Map match-all VOICE (id 2)
Match protocol rtp audio
Class Map match-all SCAVENGER (id 4)
Match protocol bittorrent
HQ-ROUTER#
Notice that the output also shows us the class-default Class Map, which we have by default. You can think of this as a “catch all” Class Map, meaning that if you don’t explicitly classify a packet into a Class Map you create, it will be classified into the class-default Class Map.
This command shows what policies (i.e. specific QoS features and settings) are applied to our Class Maps. Here’s the output from our example:
HQ-ROUTER#show policy-map
Policy Map DEMO
Class EMAIL
bandwidth 512 (kbps)
packet-based wred, exponential weight 9
random-detect ecn
dscp min-threshold max-threshold mark-probablity
----------------------------------------------------------
default (0) - - 1/10
Class VOICE
priority 256 (kbps)
Class WEB
bandwidth 768 (kbps)
packet-based wred, exponential weight 9
random-detect ecn
dscp min-threshold max-threshold mark-probablity
----------------------------------------------------------
default (0) - - 1/10
Class SCAVENGER
police cir 128000 bc 4000
conform-action transmit
exceed-action drop
HQ-ROUTER#
This is my favorite QoS verification command, because it shows us the combined information we saw in the two previous show commands. Also, it gives us counts for how many packets and how many Bytes have been classified by each Class Map. Here’s the output from our example:
HQ-ROUTER#show policy-map interface gig 0/1
GigabitEthernet0/1
Service-policy output: DEMO
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Class-map: EMAIL (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol exchange
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol pop3
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol imap
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 512 kbps
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0 packets
dscp Transmitted ECN Random drop Tail drop Minimum Maximum Mark
pkts/bytes marked pkts/bytes pkts/bytes thresh thresh prob
Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol rtp audio
Priority: 256 kbps, burst bytes 6400, b/w exceed drops: 0
Class-map: WEB (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol http
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol secure-http
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 768 kbps
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0 packets
dscp Transmitted ECN Random drop Tail drop Minimum Maximum Mark
pkts/bytes marked pkts/bytes pkts/bytes thresh thresh prob
Class-map: SCAVENGER (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol bittorrent
police:
cir 128000 bps, bc 4000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
HQ-ROUTER#
While an in-depth study of each QoS feature mentioned in this post would fill an entire course, the goal of this post was to introduce you to the 3-step MQC process and to give you a passing familiarity with many of the QoS mechanisms configurable with MQC. Equipped with this knowledge, my hope is that you’re now better able to interpret the auto-generated QoS configs you encounter.
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945
50% Complete
Please submit your information below to receive updates from Kevin Wallace Training: