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.