The Modular Quality of Service CLI (MQC) Review – Service Policies

November 4, 2015 at 6:52 pm

T8eQ

In part 1 of this series, we examined the class maps that you use to classify traffic you want to make QoS treatments for. In part 2, we took a look at policy maps. These are the structures you use in order to actually make the QoS manipulations with.

But the question remains, how do you assign this QoS policy to an interface in a particular direction. The answer, of course, is service policies. In this post, we examine the service policy step, and ensure we can easily verify a QoS configuration that utilizes the MQC.

Let us walk through a simple example. We will classify a very specific PING using a class map, and then punish it with the drop treatment at a router interface. Let drop ICMP Echo packets sourced from the loopback of R1 at the R2 interface s0/0.

Screenshot 2015-11-04 10.38.34

First – let’s make sure out little topology has full connectivity – a PING to the Loopback0 of R1 will do the trick:

The Modular Quality of Service CLI (MQC) Review – Policy Maps

October 10, 2015 at 4:01 pm

Ant_Keith_QoS

In the first part of the MQC review – we examined class maps. These devices place our traffic into containers that we can assign QoS actions to. In this article, we are going to look at policy maps for assigning those actions.

Here I will create a quick class map, verify the class map, and then enter policy map configuration mode:

R1(config)#class-map match-any CM_ICMP
R1(config-cmap)#match access-group 100
R1(config-cmap)#exit
R1(config)#exit
R1#! The access-list 100 is not shown in this configuration
R1#show class-map
 Class Map match-any class-default (id 0)
   Match any 
 Class Map match-any CM_ICMP (id 1)
   Match access-group  100 
R1#conf t
R1(config)#policy-map PM_ICMP
R1(config-pmap)#?
Policy-map configuration commands:
  class        policy criteria
  description  Policy-Map description
  exit         Exit from policy-map configuration mode
  no           Negate or set default values of a command
  rename       Rename this policy-map
R1(config-pmap)#

As you can see from the above configuration, there is not much going on in policy map configuration mode. We can add a description or rename the policy map but that is about it. The magic happens when we enter policy map class configuration for one of the classes that we configured:

The Modular Quality of Service CLI (MQC) Review – Class Maps

September 23, 2015 at 5:11 pm

Ant_Keith_QoS

The MQC is king when it comes to almost all of our QoS configurations these days. Let’s review the first step – the Class Map step.

The Class Map step is where we take traffic forms and place them into pails. Notice I am avoiding the term bucket because we use that already for another QoS topic :-).

When you are learning your QoS configs, be sure to use context-sensitive help every step of the way. This helps you discover what is possible, and helps you avoid potential pitfalls and gotchas.

Well, let’s fire up Cisco VIRL and examine these important structures in great detail…

iosv-1(config)#class-map ?
WORD           class-map name
match-all      Logical-AND all matching statements under this classmap
match-any    Logical-OR all matching statements under this classmap
type                Configure CPL Class Map

We begin by examining the options after our class-map command to create the class map. Notice we can go right to naming it, or, most importantly, selecting whether we must match ALL of the criteria that follow or ANY of them in order to have the traffic fall within this pail. There is a default here, but I can never remember what it is, so I always pick match-all or match-any. Notice also we can configure a type of class map. This is because the MQC has been extended and called the Modular Policy Framework and can now do more than just QoS for us. Let’s create a match-any class map named CM_TEST.

iosv-1(config)#class-map match-any CM_TEST
iosv-1(config-cmap)#

Now we are in class map configuration mode where we use the match command to match on a ton of options – here are just some:

access-group                   Access group
any                                      Any packets
application                      Application to match
cac                                      Call Admission Control
class-map                        Class map
cos                                      IEEE 802.1Q/ISL class of service/user priority values
destination-address    Destination address
discard-class                  Discard behavior identifier
dscp                                   Match DSCP in IPv4 and IPv6 packets

Note that while we can use QoS to mark traffic, if our traffic is already marked, we can match on the Layer 2 or Layer 3 markings easily in the class map.

Here is the rest of my sample configuration based on these facts:

iosv-1(config-cmap)#match access-group 100
iosv-1(config-cmap)#match protocol icmp

The match access-group 100 matches an ACL (not shown) that specifies traffic we want, and the match protocol ICMP ensures that Network Based Application Recognition (NBAR) is at work to automatically recognize any ICMP traffic.

Remember, thanks to our match any logic, this class map will gather traffic that matches either of these or both!

I hope you enjoyed this review of class maps. Obviously the next post will review our second step of the MQC process – policy maps! Here is where we take action on the traffic that we have matched.

Questions, comments, hate mail? Use the comments below! 🙂