Modular QoS CLI

The Modular QoS CLI is a method wherein traffic is segregated into categories and then policies are applied onto them. These policies are then applied on the ingress or egress ports. The MQC model is a more modern way of applying QoS policies on a device. Prior to the MQC model was the CLI method. The CLI method was error prone and tedious to configure thus scalability was a major issue. The MQC model can be broken down by the classification of traffic (using class maps), the definition of policies on the classified traffic (using policy maps) and the application of these policies on interfaces (service policy). This simplifies the implementation and configuration of QoS. The breaking down of the QoS commands into modules helps us use and reuse these modules in multiple combinations.

MQC features

Comprehensive L2 and L3 markings

Complete set of capabilities to classify and mark traffic based on any Layer 2 or Layer 3 QoS field

LLQ

Offers a complete queuing solution, with bandwidth-bounded priority queuing and CBWFQ.

NBAR

Intelligently classifies Layer 4 through Layer 7 protocols, including Citrix, HTTP-URLs, SAP

Single rate policer

Highly versatile policer that allows for packet re-marking (Layer 2 and Layer 3) or dropping policies to control traffic at the network edges/aggregation points.

Two rate policer

Extending the features of the single-rate policer, the two-rate policer makes the feature more intuitive to use by supporting both a Committed Information Rate (CIR) and Peak Information Rate (PIR) (average and peak rates), and allows duplication of the CIR/PIR service of Frame-Relay in the pure IP domain. Conforms to RFC-2698.

WRED

Provides active queue management to optimize Transmission Control Protocol (TCP), and rate-adaptive flows. Can be used in conjunction with CBWFQ, while being DiffServ-Compliant. Using WRED aids in implementing the Assured Forwarding (AF) behavior and maximizes network throughput in congestion scenarios.

ECN

A feature of WRED, ECN notifies TCP hosts about congestion in the network and requests a slow down. ECN offers a more efficient way to indicate congestion to end-systems, compared to packet drops.

Class-based QoS MIB

For all features within the MQC feature, this MIB offers monitoring of various counters, and is the most comprehensive QoS monitoring infrastructure in the industry.

Configuration

Configuring QoS is a simple three step process and consists of defining and the applying the following

1. Class-map - The first step in the MQC model is to identify the traffic or classify the packets. Many methods like MAC addresses, IP addresses, ACLs, IP Precedence values, DSCP values and NBAR can be used.

2. Policy-map - Now that traffic has been classified, what to do with the classified traffic is decided in this step. The traffic can be marked, queued, dropped, policed, or shaped.

3. Service policy - The service policy helps us apply the policies on marked traffic in the ingress or egress ports. This is applied under the interface itself and the keywords input and output define if it is ingress or egress.

As an example lets classify all rtp audio traffic exiting interface serial 0/2/0 and give it a prioritized bandwidth of 200 kbps.

Class-map match-any Voice-traffic /Defining the class map with the name of Voice-traffic/

Match protocol rtp audio /Using NBAR to match only RTP audio/

Policy-map RTP-Only /Defining a policy-map named RTP-Only/

Class Voice-traffic /Defining a policy for class Voice-traffic/

Priority 200 /Giving a prioritized bandwidth of 200 kbps/

Int serial 0/2/0 /Entering serial 0/2/0’s configuration for applying the policy/

Service-policy output RTP-Only /applying the policy on the egress of the serial interface/

Configuring the MQC model is as simple as that. Now let’s look a little deeper into the different configuration options we have and what we could apply depending on the scenario at hand.

class-map match any/all/not <Name of class-map>

This command is used to define the class map name and how it functions. In the case that the match any statement is used if traffic flowing matches any one of the statements configured under the class-map it is classified under this class map. Using the match-all statement implies that the traffic flowing through has to match every one of the match statements configured under it to be classified under this class default match-all. Match all is the default if no match statement is configured. Simply put the match any is like a Boolean or operation and the match all is a Boolean and operation. Traffic is classified under the match not statement if it does not match any of the criteria mentioned in the match statements. There are various kinds of criteria based on which traffic can be classified as shown below.

match access-group <Number>

This statement is used to match a previously defined access list.

match class-map

Used to match traffic matched by another class-map. You can have multiple class-maps nested to segregate traffic more granularly.

match cos/dscp <number>

Used to match traffic that has already been classified with either a CoS or DSCP value

match destination-mac

Matches traffic based on the destination mac address

match fr-dlci

Matches traffic with the specified frame relay dlci.

match protocol

A versatile and useful command that uses NBAR (Network Based Application Recognition) to deep inspect packets. The match protocol statement can be used to classify traffic based on various protocols like http, rtp, pop3, imap, kazaa, emule.

match not

Used to match all other traffic other than the specified traffic. For example, we can use the match rtp audio statement to match all rtp streams and then we can use the match not dscp 46 statement to match only the unmarked traffic from all the streams. This would help us use a policy map for the unmarked traffic to mark it with an appropriate value.

Policy-map <name>

This command is used to define a new policy map with the specified name. Under the policy map configuration we can have multiple class maps defined. A single policy map can be applied on either the ingress or egress interface using the service-policy command. Thus by having the ability to configure policies for multiple class-maps under the same policy map helps cater to a wide range of traffic types.

class <name>/class-default

Using the keyword class followed by the name of the previously configured class-map allows you to enter into the policy configuration of the specified class and apply specific policies to traffic matched by it. The class-default command is used to apply policies to all other traffic that does not match any of the class-maps configured under the policy-map.

bandwidth

The bandwidth command followed by the bandwidth in kbps or the bandwidth command followed by percentage and a percentage value specify the amount of bandwidth to be allotted to the matched traffic class. Configuring bandwidth means you have enabled CBWFQ (Class Based Weighted Fair Queuing).

police

The police command is used to configure rate policing or token buckets. The token bucket system used depends on the commands used in conjunction with the police keyword. The commands that can be used are conform-action, exceed-action or violate action. The combination of these actions let you remark excess traffic to a lower QoS label or drop the exceeding traffic.

Priority

The priority keyword is used to define a prioritized bandwidth for traffic. It can be in kbps or in a percentage of the interfaces bandwidth just like the bandwidth command explained earlier. Using the priority command sends the classified traffic before the other non-prioritized traffic. This is known as Priority Queuing. When used in conjunction with the bandwidth command (not under the same class) is the same a LLQ (Low Latency Queuing).

random-detect <DSCP Value>

The random-detect keyword is used to randomly detect packets based on the specified DSCP value so they can be dropped later during times of congestion. This is a Cisco proprietary feature known as WRED (Weighted Random Early Detection). It builds upon the older RED (Random Early Detection) mechanism.

set cos/dscp <value>

Used to set the specified cos/dscp value for the traffic classified by the class-map

set qos-group

Used to set a group identifier that can be used to classify packets later.

service-policy

Used to apply another policy map to the current policy-map. This way multiple policy maps can use a common policy map for example.

shape

The shape command is used to configure shaping for the policy-map.

Service-policy

Service-policy is used to apply the configured policy-map settings on the ingress or egress interface using a combination of service-policy and input or output commands. An interface can have only one service policy for the input and one for the output. To configure multiple policies a nested policy map can be used and then applied on the appropriate interface. A service-policy can be applied either on a physical interface or a virtual circuit.

show class-map

show policy-map

show policy-map [name] class [name]

show poilcy-map interface

Sample question

All RTP audio exiting the router needs to be remarked to a DSCP value of 46 and should be given 100 kbps of prioritized bandwidth. All the signaling traffic (H.323, SIP, SCCP, MGCP) needs to marked with a COS Value of 3 and have 20 kbps of bandwidth. E-mail traffic should be given a fixed bandwidth equivalent to 10 percent of the interfaces bandwidth. All peer to peer traffic needs to be marked to DSCP 1 for up to 40 kbps and exceeding traffic should be marked down to best-effort and dropped if it exceeds 80 kbps.

QoS Labels

Well QoS labels intend to place the right packets with the right QoS settings using labels. Prior to QoS there was never any differentiation of packets arriving or leaving a switchport. QoS labels simply mark our different classes of traffic with the appropriate label and thus helps distinguish and differentiate on what happens to the packet. These labels are present in two forms one being the tag control field in a frame header as a layer 2 marking and one being present in the ToS byte of an ip packet header as a layer 3 marking. Layer 2 QoS labels are represented using CoS values and Layer 3 QoS labels are represented using Either IP Precedence or DSCP.

By default routers and switches in a network follow the best-effort model and for Cisco devices this is the default. What I plan on explaining in this blog revolves around the Diff-Serv architecture. The Diff-Serv (or Differentiated Services) model introduces a concept wherein a packet is classified or labeled as it enters the network. This in turn reduces the overhead that would plague core switches if they had to label every packet passing by it. The other benefit of this is that all traffic marked entering the network can be subjected to QoS settings from the start.

Layer 2: Class of Service (CoS)

Class of Service

The 802.1q frame headers present in layer 2 frames contain a byte Tag Control Information field that carries the CoS value in the three most significant bits. These three bits are used to represent values in the ranges of 0 to 7. A CoS value of 0 represents the lowest priority and 7 that of the highest priority.

Binary	Decimal	Use
000	0	Best Effort
001	1	Priority
010	2	Excellent Effort
011	3	Critical Applications
100	4	Video
101	5	Voice
110	6	Internetwork Control
111	7	Network Control

Layer 3: IP Precedence and DSCP

IP Precedence

Was the old layer 3 form of marking it took 3 bits from the ToS byte and therefore a representation of 8 values could be used to mark packets. This was the military standard and was initially used to provide QoS labeling for layer 3 ip packets. They too have values ranging from 0 to 7 and are prioritized in the increasing order.

Binary	Decimal	Use
000	0	Routine or Best Effort
001	1	Priority
010	2	Immediate
011	3	Flash
100	4	Flash Override
101	5	Critical
110	6	Internet
111	7	Network

DSCP

Today most modern switches including Cisco’s use DSCP markings for its QoS Labeling. DSCP makes use of 6 bits instead of 3 from the ToS byte. These 6 bits are used to represent DSCP values and range from 0 to 63. The 64 different values that can be represented by DSCP allows it more granularity over the traffic and allows for all traffic in the network to be labeled uniquely. This in turn offers separate QoS policies to be implemented on the uniquely classified traffic. DSCP markings can be classified into many types like the Default PHB, Class selector, Assured Forwarding and Expedited Forwarding.

Default PHB

The Default PHB has a binary value of 000000. It is used to mark traffic as best effort or basically no QoS.

Class selector

DSCP is backward compatible with IP Precedence values. A certain range of values present in the DSCP range are reserved for backwards compatibility with the older method of ip precedence. The first three bits in the case of the DSCP values are the same as that of ip precedence. The next three bits are 0’s just as in the case of ip precedence (these bits are not used). They are of the form ‘XXX000’. Thus if a packet comes in with an IP Precedence value it has a DSCP equivalent. These equivalent DSCP values are called the Class Selector (CS) values. This can be inferred from the table below.

Binary	IP Precedence	DSCP
000000	0	Default (0)
001000	1	CS1 (8)
010000	2	CS2 (16)
011000	3	CS3 (24)
100000	4	CS4 (32)
101000	5	CS5 (40)
110000	6	CS6 (48)
111000	7	CS7 (56)

Assured Forwarding

DSCP also introduces something known as Assured Forwarding (AF). The Assured Forwarding values are represented using two properties, drop probability and Class. The drop probability characteristic of the marked packet indicates the chances of the packet being dropped during a state of congestion as compared to other traffic in the same class. The drop probability characteristic can have one of three values namely Low Drop probability, Medium Drop probability, High Drop probability. The Class characteristic defines that if congestion does occur traffic in the higher classes is given a higher priority than the traffic in lower classes. The classes are divided into four Class 1 to Class 4. Class 4 being the highest priority and class 1 being given the lowest priority.

The AF values can be deciphered using a simple formula.

AFxy where x stands for the class and why stands for the drop probability.

	Class 1	Class 2	Class 3	Class 4
Low Drop	AF11 (DSCP 10)	AF21 (DSCP 18)	AF31 (DSCP 26)	AF41 (DSCP 34)
Medium Drop	AF12 (DSCP 12)	AF22 (DSCP 20)	AF32 (DSCP 28)	AF42 (DSCP 36)
High Drop	AF13 (DSCP 14)	AF23 (DSCP 22)	AF33 (DSCP 30)	AF43 (DSCP 38)

Expedited Forwarding

Expedited Forwarding (EF) has a binary value of 101110 or a decimal value of 46. The expedited forwarding PHB is used on traffic that has characteristics like low delay, low loss and low jitter.  The EF marking is generally used with voice traffic because of the characteristics just mentioned.

The QoS maps

A Cisco layer 2 or layer 3 switch sees a frame/packet as it is and does not make any change to it by default, the packet is sent out of the egress interface without any markings applied on it. This is because by default QoS is disabled as you can see from the screenshot below.

Even though the output shows QoS ip packet DSCP rewrite is enabled it really doesn’t rewrite anything until and unless QoS is enabled. QoS is enabled using the command mls qos.  

The switch only processes packets based on the DSCP value and not the CoS or IP Precedence values. Whether a packet comes in with a CoS value or an IP Precedence value at the end of the day it needs to be converted to an equivalent DSCP value for the switch to process it. Using maps this can be achieved. A map is basically a table used by a switch to convert QoS markings from one form into another (DSCP in our case). There are three maps I would like to discuss in this post and I have listed them below along with their maps to equivalent DSCP values.

CoS-to-DSCP map

IP-Precedence-to-DSCP map

DSCP-to-DSCP-mutation table

If the particular switch is at the boundary of a set of networking devices it may require a conversion of DSCP values to other sets of DSCP values and this can be attained by using the above DSCP mutation table.

The classification process

Traffic entering the switch needs to be trusted based on the CoS/IP Precedence/DSCP values. There are multiple methods to achieve this and they have been listed below:

MLS QoS Trust CoS

This command is used to classify IP or non-IP traffic entering into the switchport. It initially checks if the incoming packet has a CoS label. If the packet has a CoS value attached to it the CoS-toDSCP map is used to generate an equivalent DSCP value. If the packet doesn’t have a CoS value associated with it the default port CoS is applied and the CoS-to-DSCP map is then used to generate an equivalent DSCP value

MLS QoS Trust DSCP

This command is used to trust IP traffic only. If the DSCP-to-DSCP-mutation table has been modified the DSCP value present in the incoming packet will be modified according to the mutation table. If the packet comes in with no predefined DSCP value the packet is checked to see if it has a CoS label assigned. If it does then the CoS from the packet is used to generate a DSCP value using the CoS-to-DSCP map. If the packet does not have a CoS value or a DSCP value assigned to it. The packet is assigned a default CoS value and the CoS-to-DSCP map is used to generate an equivalent DSCP value.

MLS QoS Trust IP Precedence

This command is used to trust IP traffic entering the switchport. An IP-Precedence-to-DSCP map is used to generate an equivalent DSCP value. If the packet comes in with no predefined IP Precedence value the packet is checked to see if it has a CoS label assigned. If it does then the CoS from the packet is used to generate a DSCP value using the CoS-to-DSCP map. If the packet does not have a CoS value or a DSCP value assigned to it. The packet is assigned a default CoS value and the CoS-to-DSCP map is used to generate an equivalent DSCP value.

Alternatively ACLs can also be used to match packets and assign CoS or DSCP values.

Trust device cisco-phone/ cisco-softphone/cts/ip-camera

When a Cisco ip phone sends packets out it sends them with a default CoS value of 5. When this packet enters a switch this CoS value is either accepted or remarked depending on the configuration present on the switch. Any two cisco devices present come to know of each other using cdp. When a Cisco switch is connected to a Cisco ip phone (or similar devices) cdp can be utilized to detect if the device connected is indeed a Cisco ip phone.

Using the command MLS QoS Trust device Cisco phone Utilizes CDP to detect if the device connected is a cisco ip phone or not. If the detected device is a cisco phone the CoS values are trusted. If the device is not a cisco ip phone the packets are remarked to a CoS of 0. This mechanism is used to prevent devices capable of 802.3p tagging from marking its own packets with a higher CoS value, thus prioritizing its own traffic above the others.

The default CoS value can be set on the switchport by using the command MLS QoS cos <value> command and the CoS values of the packet can be overwritten to the default values using the MLS QoS cos override command.

These settings can be verified by issuing the show mls qos interface <type> <port>

As an example I will configure interface fa 1/0/1 of a 3750 switch with the following QoS settings:

1. Trust the CoS values entering the switch
2. Trust the CoS markings if the device is of type cisco-phone
3. Set the default CoS value to 3
4. Force all traffic to use the default CoS value

Below are packet captures using wireshark that show the before and after of configuring the above commands

Before

After

If you notice the before image it indicates that the packets were being sent out with a DSCP value of EF. This is because the frame comes in with a CoS value of 5 this is tagged by the phone itself. As it enters the switch it is converted into an equivalent value present using the CoS-DSCP map. However QoS has not been enabled and this conversion does not take place therefore it is left at the value of EF. If QoS was enabled the CoS-DSCP map would equate to a value of CS5 (DSCP 40) as shown in the screenshot below

The after screenshot indicates that the converted value is CS3 (DSCP 24) which can be calculated using the CoS-DSCP mapping table. This proves the override command and the CoS to DSCP translation taking effect.