Cisco QoS Exam Certification Guide: MQC, QPM, and AutoQoS

This chapter is from the book

Cisco QOS Exam Certification Guide (IP Telephony Self-Study), 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Cisco QOS Exam Certification Guide (IP Telephony Self-Study), 2nd Edition

Learn More Buy

Cisco Modular QoS CLI

Back in the mid 1980s, Cisco Systems got its start by building and selling routers. As time went on, Cisco kept adding more and more features to its router software, called Cisco IOS Software, including some QoS features.

Each feature could be configured using the Cisco command-line interface (CLI), but in most cases, each QoS tool used a totally different set of commands than the other tools. At the same time, the networks in which the routers and switches were installed started to have more stringent QoS requirements, causing Cisco customers to need to use multiple QoS tools. As a result, the task of figuring out what to do with the various QoS tools, how to configure them, and how to monitor the success of those tools in the network was a bit daunting.

The Cisco Modular QoS CLI (MQC) helped resolve these problems by defining a common set of configuration commands to configure most QoS features in a router or switch. After hearing the term MQC for the first time, many people think that Cisco has created a totally new CLI, different from IOS configuration mode, to configure QoS. In reality, MQC defines a new set of configuration commands—commands that are typed in using the same IOS CLI, in configuration mode.

As time goes on, and as Cisco creates new IOS releases for both routers and switches, all QoS tools will use MQC. In fact, almost all the tools covered by the current QoS exam use MQC.

You can identify an MQC-based tool because the name of the tool starts with the phrase "class-based" (commonly noted as "CB"). These tools include CB Marking, CB Weighted Fair Queuing (CBWFQ), CB Policing, CB Shaping, and CB Header Compression. Most QoS tools need to perform classification functions; all MQC supporting tools use the same commands for classification. The person configuring the router needs to learn only one set of commands for classification for all these MQC-based tools, which reduces effort and reduces mistakes.

The Mechanics of MQC

MQC separates the classification function of a QoS tool from the action (the per-hop behavior, or PHB) that the QoS tool wants to perform. To do so, there are three major commands with MQC, with several subordinate commands:

• The class-map command defines the matching parameters for classifying packets into service classes.

• Because different tools create different PHBs, the PHB actions (marking, queuing, and so on) are configured under a policy-map command.

• Because MQC operates on packets that either enter or exit an interface, the policy map needs to be enabled on an interface by using a service-policy command.

Figure 3-1 shows the general flow of commands.

Figure 3-1 MQC Commands and Their Correlation

In Figure 3-1, the network's QoS policy calls for two service classes. (The actual types of packets that are placed into each class are not shown, just to keep the focus on the general flow of how the main commands work together.) Classifying packets into two classes calls for the use of two class-map commands. Each class-map command would be followed by a match subcommand, which defines the actual parameters that are compared to packet header contents to match packets for classification.

For each class, some QoS action (PHB) needs to be applied—the configuration for these actions is made under the policy-map command. Under a single policy map, multiple classes are referenced, in this case, the two classes myclass1 and myclass2. Inside the single policy called mypolicy, under each of the two classes myclass1 and myclass2, you can configure separate QoS actions. For instance, you could apply different marking to packets in class myclass1 and myclass2 at this point. Finally, when the service-policy command is applied to an interface, the QoS features are enabled.

Classification Using Class Maps

Almost every QoS tool uses classification to some degree. To put one packet into a different queue than another packet, IOS must somehow differentiate between the two packets. To perform header compression on Real-Time Transport Protocol (RTP) packets, but not on other packets, IOS must determine which packets have RTP headers. To shape data traffic going into a Frame Relay network so that the voice traffic gets enough bandwidth, IOS must differentiate between Voice over IP (VoIP) and data packets. If an IOS QoS feature needs to treat two packets differently, it must use classification.

MQC-based tools classify packets using the match subcommand inside an MQC class map. Several examples in this section point out some of the key features of class maps. Table 3-2 lists the match command options available for Cisco IOS Software Release 12.2(15)T, which is covered by the current QoS exam.

Table 3-2 match Configuration Command Reference for MQC Tools

MQC Example 1: Voice and Everything Else

The first example (Example 3-1) shows the basic flow of the commands. Two class maps are used—one that matches voice packets, and one that matches everything else. Note that class map names are case sensitive, as are policy maps.

Example 3-1 Basic Classification with Two Class Maps

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#!
R3(config)#class-map voip-rtp
R3(config-cmap)#match ip rtp 16384 16383
R3(config-cmap)#class-map all-else
R3(config-cmap)#match any
R3(config-cmap)#policy-map voip-and-be
R3(config-pmap)#class voip-rtp
R3(config-pmap-c)#! Several options in here; CB Marking shown with the set command
R3(config-pmap-c)#set ip DSCP EF
R3(config-pmap-c)#class all-else
R3(config-pmap-c)#set ip dscp default
R3(config-pmap-c)#interface fa 0/0
R3(config-if)#service-policy input voip-and-be
R3(config-if)#end
R3#
R3#show running-config
Building configuration...
!Portions removed to save space?
ip cef
!
class-map match-all voip-rtp
 match ip rtp 16384 16383 
class-map match-all all-else
 match any
!
!
policy-map voip-and-be
 class voip-rtp
  set dscp EF
 class all-else
  set dscp default
!
interface Fastethernet0/0
 description connected to SW2, where Server1 is connected
 ip address 192.168.3.253 255.255.255.0
 service-policy input voip-and-be

First, focus on the command prompts in Example 3-1. Note that the class-map command moves the CLI into class map configuration mode, with the prompt R3(config-cmap). The policy-map command moves the CLI into policy map configuration mode, and the class command that follows (not class-map, but just class) moves the CLI into an additional subconfiguration mode that has no specific name.

Next, examine the match commands. The match ip rtp command matches only the even-numbered ports in this same UDP port range and does not match the odd-numbered ports used by the Real-Time Control Protocol (RTCP) voice-signaling protocol. (VoIP payload uses only the even port numbers.) Therefore, the match ip rtp command matches all VoIP payload. The other match command in class-map all-else, match any does exactly that—it matches anything. So, one class map matches VoIP payload, and the other matches any traffic.

A little later in this chapter, you will read more about the actions (PHBs) that can be taken inside a policy map. For this example, CB Marking, using the set command, is shown. Continuing down the configuration, examine the policy-map set commands. The first command sets a Differentiated Services Code Point (DSCP) of EF (expedited forwarding) for all traffic that matches class-map voip-rtp. The other set command, which follows the class all-else command, sets a DSCP of Default for traffic that matches the class-default class-map. In other words, the policy map sets DSCP EF for packets that match one class, and DSCP Default, using the keyword default, for the other class.

Finally, the service-policy command enables CB Marking for ingress packets with the service-policy input voip-and-be interface subcommand. When enabled, IOS applies the policy map classes in the order they appear in the policy-map command. In this example, for instance, the voip-rtp class is used to examine the packet first; if a match appears, the packet is marked with DSCP EF. After the packet has been matched and marked, it exits the policy map. If no match occurs, only then is the next class, all-else, used to examine the packet.

MQC Example 2: Matching ACLs and Using class-default

Example 3-1 could have been done more efficiently using the class-default class, which is a class inside every policy map, at the end of the policy map. If a packet is examined by a policy map and it does not match any of the explicitly defined classes, the packet is considered to match class-default. Example 3-2 shows another configuration, this time with class-default in use.

Example 3-2 Class Maps Matching Voice, ACL 101, and Using class-default

R3#show running-config
Building configuration...
!Portions removed to save space?
ip cef
!
class-map match-all voip-rtp
 match ip rtp 16384 16383 
class-map match-all class2
 match access-group 101
!
!
policy-map voip-101-be
 class voip-rtp
  set dscp EF
 class class2
  set dscp AF11
 class class-default
  description this class matches everything else by default
  set dscp BE
!
interface Fastethernet0/0
 description connected to SW2, where Server1 is connected
 ip address 192.168.3.253 255.255.255.0
 service-policy input voip-101-be
!
access-list 101 permit tcp any any eq 23
access-list 101 permit tcp any eq 23 any

This example uses the same class-map voip-rtp command, which matches voice payload packets. A new class-map class2 command defines a new class, matching packets that are permitted by ACL 101. In this case, ACL 101 matches Telnet packets.

policy-map voice-101-be refers to the two explicitly defined class maps, as well as the default class map called class-default. The router processes the policy map logic in the order shown in the configuration, always placing class class-default at the end of the policy map. With an implied match any included in the class-default class, all packets that have not already matched classes voip-rtp or class2 will end up matching class-default.

Example 3: Matching Opposites with match not

MQC includes a feature to enable you to match packets that do not meet the specified criteria. For instance, Example 3-2 included a class (class2) that matched packets permitted by ACL 101. If you wanted instead to match all packets that did not match ACL 101 with a permit action, you could use the match not command. Example 3-3 duplicates Example 3-2, but with the match not command in use.

Example 3-3 Class Maps Matching Voice, ACL 101, and Using class-default

R3#show running-config
Building configuration...
!Portions removed to save space?
ip cef
!
class-map match-all voip-rtp
 match ip rtp 16384 16383 
class-map match-all not-class2
 description all packets denied by ACL 101 match
 match not access-group 101
!
!
policy-map voip-101-be
 class voip-rtp
  set dscp EF
 class not-class2
  set dscp BE
 class class-default
  description this class matches everything else by default
  set dscp AF11
!
interface Fastethernet0/0
 description connected to SW2, where Server1 is connected
 ip address 192.168.3.253 255.255.255.0
 service-policy input voip-101-be
!
access-list 101 permit tcp any any eq 23
access-list 101 permit tcp any eq 23 any

Both Examples 3-2 and 3-3 end up doing the same thing in this case. With some MQC-based QoS tools, the class-default class has some special characteristics, so you might prefer to explicitly match the Telnet (ACL 101) traffic as in Example 3-2, or you might prefer to explicitly match all other traffic using match not, as in Example 3-3.

Example 4: Matching More Than One Thing

You might have noticed that the class-map commands in the show running-config output all have a parameter called match-all. The syntax of the class-map command is actually class-map [match-all | match-any] class-name, with match-all being the default setting if you do not choose either option.

The match-all and match-any commands tell the router or switch how to process the class map if multiple match commands are used. So far in this chapter, only one match command has been used in each class map. However, IOS allows you to refer to multiple fields inside each packet to match it, and to do so, you simply use multiple match commands.

The match-all and match-any parameters tell IOS whether to match packets that match all the match commands (match-all) or to match packets that match one or more of the match commands (match-any). If you prefer Boolean logic, match-all means that there is a logical AND between each match command with match-all, and a logical OR between each match command with match-any. Example 3-4 shows an example of class maps with match-all and match-any. Note that because the focus of this example is on how the matching logic works, the example does not bother showing a policy-map or a service-policy command.

Example 3-4 Class Maps with match-all and match-any

class-map match-all ex4-1
 match ip rtp 16384 16383
 match precedence 5 
!
class-map match-any ex4-2
 match access-group 102
 match dscp AF21
!
class-map match-all ex4-3
 match dscp 0 
 match dscp 1
!
class-map match-any ex4-4
 match dscp 0 
 match dscp 1
!
class-map match-any ex4-5
 match dscp 0 1 
!

First, examine class-map match-all ex4-1. The packet must be an RTP packet within the stated UDP port number range, plus it must also already have been marked as precedence 5. If either match condition is not true about a particular packet, the packet is not considered to match the class map. So, in this case, voice packets that had not been marked yet would not be part of this class.

Next, examine class-map match-any ex4-2. With match-any logic, packets match this class if they are permitted by ACL 102 (not shown), or if they are marked with DSCP AF21. If your QoS policy defined that packets matching ACL 102 should be treated as if they were marked with AF21, this class map makes sure that any packets that were not correctly marked already are still treated as AF21 traffic.

You can use multiple match commands to match multiple criteria; however, there might be cases in which you want to match multiple marked values, for instance, multiple DSCP values in one class map. The class-map ex4-3, class-map ex4-4, and class-map ex4-5 commands show some of the dangers and possibilities with matching multiple DSCP values; class-map match-all ex4-3 uses match-all logic and lists match commands for two DSCP values (0 and 1). No one single packet can be marked with both DSCP 0 and 1, so no packets could possibly match class-map match-all ex4-3. To correctly match packets that have either DSCP 0 or 1, class-map match-any ex4-4 could be used, because it matches if only one of the match commands conditions are met.

You can, however, use a more convenient method for matching packets based on multiple DSCP, precedence, or CoS values. The class-map ex4-5 command shows how a single match command can be used to match multiple DSCPs. Note the syntax of the match dscp, match precedence, and match cos commands in Table 3-2. With precedence and CoS, you can supply four different values in a single match command; with DSCP, you can supply eight different values. When you supply more than one DSCP, precedence, or CoS value in one match command, IOS uses logic such as match-any, meaning that a packet with any of the stated values matches the condition.

Example 5: Complex Matching with match-class

In most networks, you already have seen enough examples so that you can configure class-map commands effectively. This final example in this section points out one less-obvious way to use class maps by referring to other class maps using the match class command.

Imagine that you want to match based on several things in the headers of a packet; however, the logic you want to use runs something like this:

If condition A and B are true, or if condition C is true, then place packet in this class.

The match-all and match-any keywords do not allow you to just code three match commands and achieve this logic. With the match class class-map-name command, you can achieve this logic, as shown in Example 3-5.

Example 3-5 Complex Matching with match class Command

class-map match-all ex5-1
 match ip rtp 16384 16383
 match precedence 5 
!
class-map match-any ex5-2
 match class ex5-1
 match cos 5

In class-map match-any ex5-1, the class map looks for VoIP RTP traffic that has been marked with precedence 5. Both the RTP designation and precedence 5 must be true to match the conditions in this class map. The class-map match-any ex5-2 command uses match-any logic, so either match command's conditions can be met to classify a packet into class-map ex5-2. Interestingly, class-map ex5-2 uses the match class ex5-1 command, which of course refers to the first class map, which uses match-all logic. In effect, the logic is the following:

Match packets with RTP protocol, UDP ports between 16384 and 32767, AND marked with precedence 5

or

Packets with CoS 5

You will see many more examples of how to use the MQC class-map and match commands in later chapters. Next, you will read a little more about the policy-map and service-policy commands.

Performing QoS Actions (PHBs) Using policy-map Commands

MQC uses a three-step approach:

1. class-map commands classify packets into service classes.

2. policy-map commands define PHB actions.

3. service-policy interface subcommands enable the logic of a policy map on an interface.

As shown in Example 3-1, the policy-map command refers to class maps using the class command. Example 3-6 repeats an excerpt from Example 3-1, with specific commands highlighted.

Example 3-6 Basic Flow of policy-map Commands

class-map match-all voip-rtp
 match ip rtp 16384 16383 
class-map match-all all-else
 match any
!
!
policy-map voip-and-be
 class voip-rtp
! (any action can be configured here; CB Marking is shown)
  set dscp EF
 class all-else
! (any action can be configured here; CB Marking is shown)
  set dscp default
!
interface Fastethernet0/0
 description connected to SW2, where Server1 is connected
 ip address 192.168.3.253 255.255.255.0
 service-policy input voip-and-be

Policy maps rely on the classification logic in class-map commands to treat packets differently. In Example 3-6, the policy-map voip-and-be command includes two class subcommands—class voip-rtp and class all-else. Underneath the class commands, you can configure many different commands that define a PHB or action to be taken against packets in that class. (Upcoming Table 3-3 lists the action or PHB subcommands available underneath a class command.) In this example, the set command is used, which means that marking is the action taken on packets in each class.

The service-policy input voip-and-be interface subcommand enables the policy map on the Fastethernet0/0 interface for incoming packets.

Table 3-3 lists the various MQC subcommands available in Cisco IOS Software for defining actions to be taken. Chapters 4 through 9 describe each of these options in more detail, including the meaning of the parameters of the commands.

Table 3-3 Action (PHB) Subcommands Inside a Policy Map

Enabling a Policy Map Using service-policy

You have already seen the service-policy command in use in several examples. This short section points out a few of the important features of the service-policy command.

The full syntax of the command is service-policy {input | output} policy-map-name. Note that the curly brackets mean that you must choose either input or output—you cannot leave that parameter off the command. In effect, service-policy tells the router or switch to perform the logic in the policy map for packets either entering (input) or exiting (output) the interface.

Some actions might not be supported in both the input and output directions. For instance, in a router, CBWFQ can be performed only on packets exiting the interface. So, you can configure the policy map with bandwidth subcommands, with no problems. When you try to enable the policy map with the service-policy input command, the router will give you an error message and not add the service-policy command to the configuration.

Finally, some features require that Cisco Express Forwarding (CEF) switching be enabled before the action can work. If CEF has not been enabled with the ip cef global command, you can still configure a policy map for an action. However, when you try to enable it with the service-policy command, the router will tell you that CEF switching is required.

Each interface can have at most two service-policy commands—one for input packets and one for output.

show Commands for MQC

MQC configuration commands provide the wonderful advantage of a set of standard commands for configuring QoS. Cisco also standardized show commands for MQC-based tools as well, with three commands providing all the information for any MQC configuration.

The show class-map class-map-name command lists configuration information about the class map listed in the command, and the show class-map command lists information about all class maps. Similarly, the show policy-map policy-map-name command lists configuration information about a specific policy map, and the show policy-map command lists information about all policy maps. The same general information can be seen with a show running-config command.

The one command that shows counters and performance information is the show policy-map interface interface-name [input | output] command. The output differs based on the PHBs that have been configured; for instance, it shows queuing statistics when CBWFQ has been configured, shows marking statistics when CB Marking has been configured, and so on. In some of the examples in this chapter, a policy map was enabled on interface Fastethernet 0/0. So, the show policy-map interface fastethernet0/0 command shows statistics for any policy maps enabled with the service-policy command in either direction. Alternatively, the show policy-map interface fastethernet0/0 input command lists statistics only for any policy maps enabled for input packets on interface Fastethernet0/0.

MQC helps Cisco router and switch engineers easily configure and monitor QoS features and with better results. Next, you will read about QoS Policy Manager, which is a network management tool that also helps engineers configure and monitor QoS tools.