Cisco MQC (Modular QoS CLI): The Operator's Walkthrough

The Modular QoS CLI (MQC) is the Cisco command framework for configuring QoS on IOS, IOS XE, and IOS XR routers and Layer 3 switches. It replaced the legacy QoS commands (CAR, custom queueing, priority queueing) with a clean three-construct model: classify, then describe what to do with each class, then apply the policy to an interface. Once you understand MQC, every Cisco QoS feature you will ever encounter follows the same pattern.

This article walks through the three MQC constructs (class-map, policy-map, service-policy), the most common match conditions and actions, where to apply policies (input vs output), the verification commands, and the patterns that production deployments use repeatedly. If you are studying for CCNP, configuring QoS on a Cisco device for the first time, or just trying to remember whether bandwidth statements add up to 100 percent, this is the operator's walkthrough.

Why MQC Exists

Before MQC, every QoS feature in Cisco IOS had its own configuration syntax. Committed Access Rate (CAR) had a flat command for rate limiting. Custom queueing had its own command set. Priority queueing was different again. Adding a new feature meant learning a new syntax.

MQC unified all of this. The three constructs - class-map for classification, policy-map for action, service-policy for application - cover every QoS feature: marking, queueing, policing, shaping, WRED, NBAR, application-aware policy, all using the same grammar. New features (QoS for SD-WAN, AppQoE, AVC) ship as new actions inside policy-map; the surrounding structure does not change.

The three-construct model also makes QoS configurations easy to reason about. You read a service-policy statement, find the policy-map it references, find the class-maps it references, and you have the full classification and action tree. No global lookups, no implicit interactions.

The Three MQC Constructs

The flow: traffic arrives at an interface. If a service-policy is configured for that direction, MQC walks the policy-map. The policy-map iterates through its classes; the first matching class-map wins. The actions specified for that class apply.

class-map: Defining Classification

A class-map answers "what counts as this kind of traffic?" The match conditions are the heart of QoS classification:

The two modifiers:

• match-any (default): packet matches if any single condition matches
• match-all: packet matches only if every condition matches

Examples:

! Match incoming DSCP EF (voice)
class-map match-any VOICE
 match dscp ef

! Match incoming RTP audio (NBAR-based)
class-map match-any VOICE-NBAR
 match protocol rtp audio

! Match Salesforce traffic by IP prefix
class-map match-any SALESFORCE
 match access-group name ACL-SALESFORCE
ip access-list extended ACL-SALESFORCE
 permit tcp any host 13.108.0.1 eq 443

! Match Office 365 (NBAR2 AVC)
class-map match-any OFFICE-365
 match application office-365-mail
 match application office-365-skype
 match application office-365-web

NBAR (Network-Based Application Recognition) and its successor NBAR2 are critical for modern QoS. They identify applications by deep packet inspection, not just port numbers, which means they catch SaaS apps that share ports (everything is HTTPS now) and apps that use dynamic ports.

policy-map: Defining Actions

A policy-map says "for traffic matched by this class-map, do this." Actions split into four families:

A complete marking policy:

policy-map MARK-INGRESS
 class VOICE
  set dscp ef
 class VIDEO
  set dscp af41
 class TRANSACTIONAL
  set dscp af21
 class SCAVENGER
  set dscp cs1
 class class-default
  set dscp default

A complete queueing policy (LLQ for voice, CBWFQ for everything else):

policy-map WAN-EGRESS
 class VOICE
  priority percent 10                  ! Strict-priority queue, capped at 10%
 class VIDEO
  bandwidth percent 30                 ! Guaranteed 30%
 class TRANSACTIONAL
  bandwidth percent 25                 ! Guaranteed 25%
  random-detect dscp-based             ! WRED for graceful degradation
 class SCAVENGER
  bandwidth percent 1                  ! Tiny guarantee
 class class-default
  bandwidth percent 34                 ! Remainder
  random-detect

The bandwidth percentages must sum to no more than 100. The priority statement implicitly counts against the total. class-default is implicit if you do not declare it; the configuration above is explicit for clarity.

A combined marking+queueing policy in one policy-map:

policy-map ALL-IN-ONE
 class VOICE
  set dscp ef
  priority percent 10
 class VIDEO
  set dscp af41
  bandwidth percent 30

This works for output policies. Input policies typically only mark or police - you cannot meaningfully queue traffic that is arriving.

service-policy: Applying to an Interface

The service-policy command attaches a policy-map to an interface, in either direction:

interface GigabitEthernet0/0/1
 service-policy input MARK-INGRESS    ! Mark on the way in
 service-policy output WAN-EGRESS     ! Queue/shape on the way out

An interface can have one input and one output service-policy. To do multiple things on the same direction, combine them into one policy-map (see ALL-IN-ONE above).

Hierarchical policies (a policy that itself references another policy) are supported via service-policy inside a class:

policy-map CHILD-WAN-EGRESS
 class VOICE
  priority percent 30
 class class-default
  fair-queue

policy-map PARENT-SHAPER
 class class-default
  shape average 50000000               ! Shape to 50 Mbps
  service-policy CHILD-WAN-EGRESS      ! Apply child queueing policy

interface GigabitEthernet0/0/1
 service-policy output PARENT-SHAPER

This is the standard pattern for branch WAN edges where you have a 1 Gbps physical interface but a contracted 50 Mbps WAN service. The parent shapes to 50 Mbps; the child does LLQ within that shaped pipe.

Input vs Output: Where to Apply What

The standard pattern in production:

• Access port input: classify untrusted traffic and re-mark to BE; trust traffic from IP phones via conditional trust.
• Distribution / core inputs: trust the markings (no input service-policy or one that just verifies).
• WAN egress: the queueing policy that does LLQ + CBWFQ + shaping.
• WAN input: usually no QoS - the carrier already shaped traffic to fit your contract.

Verification Commands

Once a policy is applied, the standard verification chain:

! Show the policy-map definition
Router# show policy-map WAN-EGRESS

! Show the policy applied to a specific interface, with hit counts
Router# show policy-map interface GigabitEthernet0/0/1
 GigabitEthernet0/0/1
  Service-policy output: WAN-EGRESS
    Class-map: VOICE (match-any)
      1234567 packets, 198351264 bytes
      30 second offered rate 8000 bps, drop rate 0 bps
      Match: dscp ef (46)
      Priority: 10% (10000 kbps), burst bytes 250000, b/w exceed drops: 0
        Conform: 1234567 packets / 198351264 bytes
        Exceed:  0 packets / 0 bytes
    Class-map: VIDEO
      ...

! Show class-map definition
Router# show class-map VOICE

The most useful column: drop counters per class. If your "Conform" packets are increasing but "Exceed" or queue drops are also growing, the class is bandwidth-starved. If everything is "Conform" with zero drops, the policy is healthy.

Common Production Patterns

Three patterns cover most production QoS deployments:

1. Edge marking + WAN queueing. Access ports classify and mark traffic to standardized DSCP values. WAN edge applies an output policy with LLQ for voice and CBWFQ for everything else. Internal devices trust DSCP. This is the dominant enterprise pattern.

2. Hierarchical shaping for sub-rate WAN handoffs. Physical interface is faster than the contracted WAN rate. Parent policy shapes to the contracted rate; child does LLQ + CBWFQ within the shaped pipe. Prevents the carrier from policing your traffic.

3. NBAR-based ingress marking for mid-network insertion. A WAN edge that needs to classify traffic the application servers did not mark. NBAR2 + AVC identifies the application via DPI; an input service-policy marks the DSCP. Subsequent hops trust the marking.

Operational Tips

• Verify show policy-map interface after every change. Counters should make sense; if a class has zero hits, the class-map is wrong.
• Always declare class class-default explicitly. The implicit default works but the explicit version is clearer for the next operator reading your config.
• Bandwidth percentages should sum to 100 or less. Cisco will accept configs that exceed 100 (with a warning) but the behavior is unpredictable.
• Priority class with priority percent X auto-polices to X percent. The priority bare keyword is unbounded; avoid it on production WAN.
• WRED requires bandwidth allocation. Add random-detect only inside classes that have bandwidth declared.
• For platform-specific behavior (ASR vs ISR vs Catalyst), always check the QoS configuration guide for that release. Some features have hardware vs software limitations.

Summary

MQC's three constructs (class-map, policy-map, service-policy) cover every QoS feature on Cisco IOS, IOS XE, and IOS XR. Once you understand the pattern, every new QoS feature - AVC, NBAR2, app-aware steering, WRED, hierarchical shaping - fits the same grammar. Define classification once; describe actions per class; apply to interfaces.

The dominant production patterns are edge marking + WAN queueing, hierarchical shaping for sub-rate WAN handoffs, and NBAR-based mid-network marking. Master the three constructs, the verification chain, and the trust-boundary discipline. Bookmark this article alongside the QoS cluster pillar as your day-to-day MQC reference.