MQC — Modular QoS CLI Basics

Network links do not have infinite capacity. When more traffic arrives at an interface than it can transmit simultaneously, packets must wait in a queue — and without any management of that queue, every packet waits equally regardless of whether it carries a latency-sensitive voice call or a background software update. Quality of Service (QoS) is the set of mechanisms that let a router or switch treat different types of traffic differently: giving voice calls guaranteed bandwidth and priority delivery, marking business-critical application traffic so it receives preferential treatment across the WAN, and policing or shaping bulk data so it cannot crowd out other services. For a conceptual overview see QoS Overview.

Cisco's Modular QoS CLI (MQC) is the unified framework for configuring all QoS functions on IOS and IOS-XE. Before MQC, Cisco had dozens of separate, incompatible QoS commands — each feature had its own CLI syntax, its own apply mechanism, and its own quirks. MQC replaced all of that with a clean three-step model that is the same regardless of which QoS action you are configuring: classify traffic with class-map, define actions with policy-map, and apply to an interface with service-policy. Understanding this framework is foundational — every QoS feature on Cisco IOS, from DSCP marking to LLQ priority queuing to traffic policing, is configured through these three constructs.

This lab also covers the QoS toolset used inside policy-maps: set (marking), bandwidth (minimum guarantee), priority (LLQ — strict priority for voice), police (rate limiting with conform/exceed/violate actions), and queue-limit (tail-drop tuning). The complete verification workflow using show policy-map interface and interpreting its counters is covered in detail. For MQC applied to protecting the router control plane, see Control Plane Policing (CoPP) — which uses the identical three-step MQC framework. For classification using extended ACLs referenced in class-maps, see Extended ACL Configuration. For voice VLAN configuration on access switches that feeds traffic into MQC QoS policies, see Voice VLAN Configuration.

1. QoS Fundamentals — Why QoS and When It Applies

When QoS Takes Effect

QoS mechanisms only activate when a link is congested — when more traffic is arriving than the interface can transmit. On an uncongested interface, all traffic is forwarded immediately and QoS queuing has no observable effect. This is important to understand: testing a QoS policy on a lightly loaded lab link may show no differentiation because there is no competition for bandwidth. QoS is specifically about managing the competition for a bottleneck resource.

QoS Actions — The Four Tools

QoS Tool	What It Does	MQC Command	When to Use
Classification	Identify which traffic class a packet belongs to — by DSCP, ACL, NBAR protocol, CoS, or ingress interface. The foundation all other QoS tools depend on	`class-map`	Always — every QoS policy starts with classification
Marking	Set or rewrite the packet's QoS marking — DSCP value in the IP header, CoS in the 802.1Q tag, MPLS EXP bits. Marking at the trust boundary propagates QoS intent hop-to-hop across the network	`set dscp`, `set cos`	At the network edge (ingress to the WAN or campus core) to remark untrusted or mis-marked traffic
Queuing / Scheduling	Determine the order in which queued packets are transmitted during congestion. Priority queuing (LLQ) serves the voice queue first before all others. CBWFQ assigns minimum bandwidth guarantees per class. Remaining bandwidth is shared proportionally	`priority`, `bandwidth`, `fair-queue`	On egress interfaces where congestion occurs — typically WAN uplinks and slower access ports. See QoS Queuing
Policing / Shaping	Rate-limit traffic to a specified bandwidth. Policing drops or re-marks excess packets immediately (no delay). Shaping buffers excess packets and smooths the output rate (adds delay but no drops). Policing is used for enforcement; shaping is used before a policed link to avoid drops	`police`, `shape`	Policing: at ingress to enforce traffic contracts or at egress to rate-limit a class. Shaping: on egress to match a service provider's committed rate. See QoS Policing & Shaping

DSCP — Differentiated Services Code Point

DSCP is a 6-bit field in the IP header's Type of Service (ToS) byte that carries per-hop QoS intent. Every IP router along the path can read the DSCP value and apply its local QoS policy accordingly. DSCP values are expressed either as decimal numbers (0–63) or as mnemonics. The key values to know are shown in the table below — these are the values you will use in class-map match dscp and set dscp commands throughout this lab.

DSCP Mnemonic	Decimal Value	Binary	Traffic Type	Queuing Treatment
EF (Expedited Forwarding)	46	101110	VoIP RTP — voice bearer streams	LLQ strict priority — never waits in queue
CS3 (Class Selector 3)	24	011000	VoIP signalling (SIP, H.323, SCCP)	High-priority queue — guaranteed bandwidth
AF41 (Assured Forwarding 4,1)	34	100010	Interactive video — videoconferencing	High-bandwidth guarantee, low drop probability
AF31 (Assured Forwarding 3,1)	26	011010	Business-critical applications (ERP, CRM)	Medium bandwidth guarantee
AF21 (Assured Forwarding 2,1)	18	010010	Transactional data (database queries)	Lower bandwidth guarantee
AF11 (Assured Forwarding 1,1)	10	001010	Bulk data (file transfers, backups)	Best-effort with minimum guarantee
CS1 (Class Selector 1)	8	001000	Scavenger / low-priority (peer-to-peer)	Below best-effort — used only when link is idle
BE / DF (Best Effort / Default)	0	000000	General internet traffic, unclassified	Default queue — no guarantees

The Trust Boundary

The trust boundary is the point in the network where DSCP markings are trusted and propagated as-is versus where they are re-marked or ignored. Traffic from end-user PCs is generally not trusted — a user could manually set DSCP EF on their file-download traffic to get priority treatment. The trust boundary is typically placed at the first network device the IT team controls: the access switch (for campus) or the WAN router (for branch). At the trust boundary, a marking policy (MQC with set dscp) is applied to remark traffic based on its actual type — regardless of whatever DSCP value the end device set.

2. The MQC Three-Step Framework

  ┌─────────────────────────────────────────────────────────────────┐
  │                   MQC THREE-STEP MODEL                          │
  │                                                                 │
  │  Step 1: class-map                                              │
  │  ─────────────────                                              │
  │  Define WHAT traffic belongs to this class.                     │
  │  Match criteria: DSCP, ACL, NBAR protocol, CoS, input-intf...   │
  │                                                                 │
  │    class-map match-all VOICE                                    │
  │      match dscp ef                                              │
  │                                                                 │
  │  Step 2: policy-map                                             │
  │  ─────────────────                                              │
  │  Define WHAT TO DO with each classified traffic class.          │
  │  Actions: set, bandwidth, priority, police, shape, drop...      │
  │                                                                 │
  │    policy-map WAN-OUT                                           │
  │      class VOICE                                                │
  │        priority 512      ← LLQ: 512 kbps strict priority        │
  │      class class-default                                        │
  │        fair-queue        ← WFQ for all remaining traffic        │
  │                                                                 │
  │  Step 3: service-policy                                         │
  │  ──────────────────────                                         │
  │  Apply the policy-map to an interface in a direction.           │
  │                                                                 │
  │    interface gi0/1                                              │
  │      service-policy output WAN-OUT                              │
  │                                                                 │
  │  Direction:                                                     │
  │  • output = applied to OUTGOING traffic (most common for QoS)  │
  │  • input  = applied to INCOMING traffic (policing, marking)    │
  └─────────────────────────────────────────────────────────────────┘

  Key Rules:
  • A class-map is just a filter — it does nothing by itself
  • A policy-map is just a list of actions — it does nothing
    until attached to an interface with service-policy
  • One policy-map per interface per direction (input or output)
  • A policy-map can contain up to 256 class entries
  • class-default always exists — catches all traffic NOT
    matched by any named class in the policy-map
  • class-map names and policy-map names are case-sensitive

class-map — Match Types

Match Criterion	Syntax	Matches On	Common Use Case
DSCP value	`match dscp ef` or `match dscp 46`	The 6-bit DSCP field in the IP ToS byte. Multiple values can be listed: `match dscp ef cs3 af41`	Classifying already-marked traffic (downstream of the trust boundary)
IP Precedence	`match ip precedence 5`	The top 3 bits of the IP ToS byte (legacy QoS marking). Precedence 5 = voice, 3 = signalling	Older networks using IP Precedence instead of DSCP
Access Control List	`match access-group name VOICE-ACL`	Traffic matching a named or numbered ACL — source/destination IP, port, protocol	Classifying specific hosts or applications by IP/port when DSCP marking has not yet been applied
NBAR Protocol	`match protocol http`, `match protocol rtp`	Application protocol identified by NBAR2 (Network-Based Application Recognition) deep packet inspection	Classifying applications by protocol signature regardless of port number (e.g., Skype, YouTube, Webex)
CoS (802.1Q)	`match cos 5`	The 3-bit Class of Service field in the 802.1Q VLAN tag. Only present on tagged frames	Campus QoS on trunk ports where Layer 2 CoS carries QoS markings between switches
Input interface	`match input-interface gi0/1`	The interface the packet arrived on (ingress interface at time of classification)	Classifying traffic based on which LAN segment or VLAN it came from

match-all vs match-any

Keyword	Logic	Example
`match-all` (default)	ALL match statements must be true — logical AND. A packet must satisfy every condition to belong to this class	`class-map match-all VOICE-FROM-PHONE` matching both `match dscp ef` AND `match access-group name IP-PHONES` — only voice from known phone subnets
`match-any`	ANY match statement being true is sufficient — logical OR. A packet needs to satisfy only one condition	`class-map match-any REAL-TIME` matching `match dscp ef` OR `match dscp af41` — catches both voice and video in one class

3. Lab Topology

  LAN (10.1.0.0/24)         NetsTuts_R1          WAN (10.0.12.0/30)
                            ┌──────────┐
  IP Phone (10.1.0.10) ────►│          │ Gi0/1 ──────────────────► NetsTuts_R2
  PC-Data  (10.1.0.20) ────►│          │ 10.0.12.1/30                WAN Router
  PC-Bulk  (10.1.0.30) ────►│          │ 1.544 Mbps T1 link
                            │ Gi0/0    │
                            │ 10.1.0.1 │
                            └──────────┘

  WAN interface speed: 1.544 Mbps (T1) — the bottleneck
  LAN interface speed: 1 Gbps (no congestion on LAN side)

  Traffic classes we will configure:
  ┌────────────────────┬─────────┬──────────────────────────────────┐
  │ Class              │ DSCP    │ Action                           │
  ├────────────────────┼─────────┼──────────────────────────────────┤
  │ VOICE              │ EF (46) │ LLQ priority 256 kbps            │
  │ VOICE-SIGNAL       │ CS3(24) │ Bandwidth 64 kbps guaranteed     │
  │ VIDEO              │ AF41(34)│ Bandwidth 512 kbps guaranteed    │
  │ CRITICAL-DATA      │ AF31(26)│ Bandwidth 256 kbps guaranteed    │
  │ BULK-DATA          │ AF11(10)│ Bandwidth 128 kbps guaranteed    │
  │ SCAVENGER          │ CS1 (8) │ Police to 128 kbps — drop excess │
  │ class-default      │   0     │ Fair-queue — remaining bandwidth │
  └────────────────────┴─────────┴──────────────────────────────────┘

  Marking policy (INGRESS on Gi0/0 — trust boundary):
  ┌─────────────────────────┬────────────────────────────────────────┐
  │ Source Traffic          │ Mark As                                │
  ├─────────────────────────┼────────────────────────────────────────┤
  │ IP Phone (10.1.0.10)   │ DSCP EF (46) — trust phone markings   │
  │ Data PC (10.1.0.20)    │ DSCP AF31 (26) — business data        │
  │ Bulk PC (10.1.0.30)    │ DSCP AF11 (10) — bulk data            │
  │ All other traffic       │ DSCP 0 (best effort)                  │
  └─────────────────────────┴────────────────────────────────────────┘

4. Step 1 — Define Traffic Classes with class-map

All class-maps are created in global configuration mode. The names you assign here will be referenced in the policy-map in the next step. Use descriptive names — they appear verbatim in show policy-map interface output and in syslog messages.

Classification Class-Maps (for Queuing Policy)

NetsTuts_R1#conf t

! ── Voice bearer traffic ─────────────────────────────────
! ── match-all is the default but shown explicitly ─────────
NetsTuts_R1(config)#class-map match-all VOICE
NetsTuts_R1(config-cmap)# description VoIP RTP streams - DSCP EF
NetsTuts_R1(config-cmap)# match dscp ef
NetsTuts_R1(config-cmap)#exit

! ── VoIP signalling (SIP, SCCP, H.323 call setup) ────────
NetsTuts_R1(config)#class-map match-all VOICE-SIGNAL
NetsTuts_R1(config-cmap)# description VoIP signalling - DSCP CS3
NetsTuts_R1(config-cmap)# match dscp cs3
NetsTuts_R1(config-cmap)#exit

! ── Interactive video (videoconferencing) ────────────────
NetsTuts_R1(config)#class-map match-all VIDEO
NetsTuts_R1(config-cmap)# description Interactive video - DSCP AF41
NetsTuts_R1(config-cmap)# match dscp af41
NetsTuts_R1(config-cmap)#exit

! ── Business-critical application data ───────────────────
NetsTuts_R1(config)#class-map match-all CRITICAL-DATA
NetsTuts_R1(config-cmap)# description Business apps ERP/CRM - DSCP AF31
NetsTuts_R1(config-cmap)# match dscp af31
NetsTuts_R1(config-cmap)#exit

! ── Bulk / background data transfers ─────────────────────
NetsTuts_R1(config)#class-map match-all BULK-DATA
NetsTuts_R1(config-cmap)# description File transfers backups - DSCP AF11
NetsTuts_R1(config-cmap)# match dscp af11
NetsTuts_R1(config-cmap)#exit

! ── Scavenger — below best-effort (P2P, personal streaming)
NetsTuts_R1(config)#class-map match-all SCAVENGER
NetsTuts_R1(config-cmap)# description Below best-effort - DSCP CS1
NetsTuts_R1(config-cmap)# match dscp cs1
NetsTuts_R1(config-cmap)#exit

Each class-map defines a filter — it has no effect on traffic until it is referenced inside a policy-map. The description command is optional but strongly recommended for documentation. Notice that class-default does not need to be created — it is a built-in class that automatically catches all traffic not matched by any explicitly named class in the policy-map. You never define a class-map named class-default; you only reference it in the policy-map. For ACL-based classification matching specific source IPs (rather than DSCP), see Extended ACL Configuration.

Marking Class-Maps (for Ingress Trust-Boundary Policy)

! ── ACLs to identify traffic sources for ingress marking ──
NetsTuts_R1(config)#ip access-list extended ACL-IP-PHONE
NetsTuts_R1(config-ext-nacl)# permit ip host 10.1.0.10 any
NetsTuts_R1(config-ext-nacl)#exit

NetsTuts_R1(config)#ip access-list extended ACL-DATA-PC
NetsTuts_R1(config-ext-nacl)# permit ip host 10.1.0.20 any
NetsTuts_R1(config-ext-nacl)#exit

NetsTuts_R1(config)#ip access-list extended ACL-BULK-PC
NetsTuts_R1(config-ext-nacl)# permit ip host 10.1.0.30 any
NetsTuts_R1(config-ext-nacl)#exit

! ── Class-maps for ingress marking policy ────────────────
NetsTuts_R1(config)#class-map match-all MARK-VOICE
NetsTuts_R1(config-cmap)# description Ingress: IP Phone traffic to mark EF
NetsTuts_R1(config-cmap)# match access-group name ACL-IP-PHONE
NetsTuts_R1(config-cmap)#exit

NetsTuts_R1(config)#class-map match-all MARK-DATA
NetsTuts_R1(config-cmap)# description Ingress: Data PC to mark AF31
NetsTuts_R1(config-cmap)# match access-group name ACL-DATA-PC
NetsTuts_R1(config-cmap)#exit

NetsTuts_R1(config)#class-map match-all MARK-BULK
NetsTuts_R1(config-cmap)# description Ingress: Bulk PC to mark AF11
NetsTuts_R1(config-cmap)# match access-group name ACL-BULK-PC
NetsTuts_R1(config-cmap)#exit

The ingress marking policy uses ACL-based class-maps to identify traffic by source IP address and then remark it with the correct DSCP value. This is the trust-boundary pattern: on ingress from the LAN, traffic arrives with either no DSCP marking or whatever the end device set. The ingress policy overwrites those markings based on the source — IP phones are trusted and remarked EF, PCs are marked based on their role (data or bulk). After passing through the marking policy, the packets carry the correct DSCP values that the egress queuing policy (applied on Gi0/1) will use to make forwarding decisions.

Verify Class-Maps

NetsTuts_R1#show class-map

 Class Map match-all VOICE (id 1)
   Match dscp ef (46)

 Class Map match-all VOICE-SIGNAL (id 2)
   Match dscp cs3 (24)

 Class Map match-all VIDEO (id 3)
   Match dscp af41 (34)

 Class Map match-all CRITICAL-DATA (id 4)
   Match dscp af31 (26)

 Class Map match-all BULK-DATA (id 5)
   Match dscp af11 (10)

 Class Map match-all SCAVENGER (id 6)
   Match dscp cs1 (8)

 Class Map match-all MARK-VOICE (id 7)
   Match access-group name ACL-IP-PHONE

 Class Map match-all MARK-DATA (id 8)
   Match access-group name ACL-DATA-PC

 Class Map match-all MARK-BULK (id 9)
   Match access-group name ACL-BULK-PC

5. Step 2 — Define Actions with policy-map

Policy-maps reference class-maps and assign an action to each matched class. The order of classes in the policy-map matters for classification — IOS evaluates class entries top to bottom and assigns a packet to the first matching class. Classes are evaluated sequentially; class-default always appears last and catches everything remaining.

Policy-Map 1 — Ingress Marking Policy (LAN Trust Boundary)

! ── Ingress marking policy: remark DSCP at trust boundary ─
! ── Applied INPUT on Gi0/0 (LAN-facing interface) ─────────
NetsTuts_R1(config)#policy-map MARK-INGRESS
NetsTuts_R1(config-pmap)#
NetsTuts_R1(config-pmap)# class MARK-VOICE
NetsTuts_R1(config-pmap-c)#  set dscp ef       ← mark voice EF (46)
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)#
NetsTuts_R1(config-pmap)# class MARK-DATA
NetsTuts_R1(config-pmap-c)#  set dscp af31     ← mark business data AF31 (26)
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)#
NetsTuts_R1(config-pmap)# class MARK-BULK
NetsTuts_R1(config-pmap-c)#  set dscp af11     ← mark bulk data AF11 (10)
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)#
NetsTuts_R1(config-pmap)# class class-default
NetsTuts_R1(config-pmap-c)#  set dscp default  ← remark everything else BE (0)
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)#exit

The set dscp default on class-default in the marking policy is a security best practice — it erases any DSCP values that an untrusted end device may have set on its own traffic. Without this, a user could mark their web-browsing traffic as DSCP EF and potentially receive LLQ priority treatment on the WAN. By explicitly setting class-default to DSCP 0, the router asserts control: only traffic from known, trusted sources (IP phones and designated PCs) carries elevated DSCP markings beyond the trust boundary.

Policy-Map 2 — WAN Egress Queuing Policy (LLQ + CBWFQ)

! ── WAN egress queuing policy ─────────────────────────────
! ── Applied OUTPUT on Gi0/1 (WAN-facing interface, 1.544 Mbps)
! ── Bandwidth budget for named classes:
! ──   VOICE:         256 kbps  (priority)
! ──   VOICE-SIGNAL:   64 kbps  (bandwidth guarantee)
! ──   VIDEO:         512 kbps  (bandwidth guarantee)
! ──   CRITICAL-DATA: 256 kbps  (bandwidth guarantee)
! ──   BULK-DATA:     128 kbps  (bandwidth guarantee)
! ──   Total named:  1216 kbps  (leaving ~328 kbps for class-default)
! ──   WAN total:    1544 kbps
! ─────────────────────────────────────────────────────────

NetsTuts_R1(config)#policy-map WAN-EGRESS
NetsTuts_R1(config-pmap)#

! ── Class 1: Voice — LLQ strict priority ─────────────────
! ── priority guarantees 256 kbps and serves this queue FIRST
! ── before all other classes are served. Must not exceed
! ── the stated kbps or it is policed (default LLQ behaviour)
NetsTuts_R1(config-pmap)# class VOICE
NetsTuts_R1(config-pmap-c)#  priority 256
NetsTuts_R1(config-pmap-c)# exit

! ── Class 2: Voice Signalling — CBWFQ bandwidth guarantee ─
NetsTuts_R1(config-pmap)# class VOICE-SIGNAL
NetsTuts_R1(config-pmap-c)#  bandwidth 64
NetsTuts_R1(config-pmap-c)# exit

! ── Class 3: Video — CBWFQ bandwidth guarantee ───────────
NetsTuts_R1(config-pmap)# class VIDEO
NetsTuts_R1(config-pmap-c)#  bandwidth 512
NetsTuts_R1(config-pmap-c)# exit

! ── Class 4: Critical Data — CBWFQ bandwidth guarantee ───
NetsTuts_R1(config-pmap)# class CRITICAL-DATA
NetsTuts_R1(config-pmap-c)#  bandwidth 256
NetsTuts_R1(config-pmap-c)# exit

! ── Class 5: Bulk Data — CBWFQ minimum guarantee ─────────
NetsTuts_R1(config-pmap)# class BULK-DATA
NetsTuts_R1(config-pmap-c)#  bandwidth 128
NetsTuts_R1(config-pmap-c)# exit

! ── Class 6: Scavenger — policed to 128 kbps max ─────────
! ── Excess packets are DROPPED immediately (not queued) ────
NetsTuts_R1(config-pmap)# class SCAVENGER
NetsTuts_R1(config-pmap-c)#  police rate 128000 bps
NetsTuts_R1(config-pmap-c)#   conform-action transmit
NetsTuts_R1(config-pmap-c)#   exceed-action  drop
NetsTuts_R1(config-pmap-c)#  exit
NetsTuts_R1(config-pmap-c)# exit

! ── Class default — fair-queue for remaining traffic ──────
! ── Remaining bandwidth (~328 kbps) shared fairly ─────────
NetsTuts_R1(config-pmap)# class class-default
NetsTuts_R1(config-pmap-c)#  fair-queue
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)#exit

The WAN-EGRESS policy demonstrates the two main queuing mechanisms in MQC. LLQ (Low Latency Queuing) is configured with the priority command — it creates a strict-priority queue that is always served before any other class. The priority 256 means the voice queue gets up to 256 kbps of strict priority bandwidth; if voice traffic exceeds 256 kbps, the excess is policed (dropped) by default to prevent the strict priority queue from starving other classes. CBWFQ (Class-Based Weighted Fair Queuing) is configured with the bandwidth command — it guarantees each class its specified kbps during congestion. If the link is not congested, a class can use more than its guaranteed bandwidth. If all classes are competing simultaneously, each gets at least its guaranteed allocation. The bandwidth values for all named classes (including the priority class) must not exceed the interface bandwidth — IOS will reject the policy-map if the total exceeds 75% of the interface rate (the remaining 25% is reserved for routing protocols and overhead by default). This limit can be adjusted with max-reserved-bandwidth on the interface.

Policy-Map 3 — Policing Policy (Rate-Limit an Ingress Class)

! ── Optional: ingress policing policy on WAN interface ────
! ── Rate-limits inbound traffic classes from the WAN ───────
! ── This is separate from the egress queuing policy ────────

NetsTuts_R1(config)#policy-map WAN-INGRESS-POLICE
NetsTuts_R1(config-pmap)#

! ── Police all inbound traffic to 1 Mbps ─────────────────
! ── Conform (within rate): transmit with current DSCP ─────
! ── Exceed (burst over rate): remark to lower DSCP ────────
! ── Violate (sustained over rate): drop ──────────────────
NetsTuts_R1(config-pmap)# class class-default
NetsTuts_R1(config-pmap-c)#  police rate 1000000 bps burst 31250 byte
NetsTuts_R1(config-pmap-c)#   conform-action  transmit
NetsTuts_R1(config-pmap-c)#   exceed-action   set-dscp-transmit af12
NetsTuts_R1(config-pmap-c)#   violate-action  drop
NetsTuts_R1(config-pmap-c)#  exit
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)#exit

The police command uses a token-bucket algorithm with three outcomes: conform (packet arrives within the committed rate — tokens available), exceed (packet exceeds the committed rate but within the burst allowance), and violate (packet exceeds even the burst). Each outcome has a configurable action: transmit (forward as-is), drop (discard), or set-dscp-transmit [value] (remark and forward). The exceed-action of set-dscp-transmit af12 implements a dual-rate colour-aware policing pattern — packets that burst slightly above the committed rate are re-marked to a lower drop-preference DSCP value rather than dropped, giving downstream routers the option to drop them first under congestion. The burst size (burst 31250 byte) should typically be set to the rate in bps divided by 8 (converting to bytes per second) multiplied by a target burst duration — for 1 Mbps at 250ms burst: 1,000,000/8 × 0.25 = 31,250 bytes.

6. Step 3 — Apply to Interface with service-policy

The service-policy command is the only step that activates a QoS policy. Until this command is applied, the class-maps and policy-maps exist only as configuration objects — no traffic is affected. Apply the marking policy input on the LAN-facing interface, and the queuing policy output on the WAN-facing interface.

Apply Policies to Interfaces

! ── LAN interface (Gi0/0) — ingress marking at trust boundary
NetsTuts_R1(config)#interface gi0/0
NetsTuts_R1(config-if)# description LAN - Trust Boundary
NetsTuts_R1(config-if)# ip address 10.1.0.1 255.255.255.0
NetsTuts_R1(config-if)# service-policy input MARK-INGRESS
NetsTuts_R1(config-if)# no shutdown
NetsTuts_R1(config-if)#exit

! ── WAN interface (Gi0/1) — egress queuing on the bottleneck
NetsTuts_R1(config)#interface gi0/1
NetsTuts_R1(config-if)# description WAN - 1.544 Mbps T1
NetsTuts_R1(config-if)# ip address 10.0.12.1 255.255.255.252
NetsTuts_R1(config-if)# bandwidth 1544           ← inform IOS of actual speed
NetsTuts_R1(config-if)# service-policy output WAN-EGRESS
NetsTuts_R1(config-if)# no shutdown
NetsTuts_R1(config-if)#exit

! ── Optional: ingress policing on WAN interface ───────────
! ── (uncomment to enable) ─────────────────────────────────
! NetsTuts_R1(config-if)# service-policy input WAN-INGRESS-POLICE

NetsTuts_R1(config)#end

The bandwidth [kbps] interface command is critical for MQC — it tells IOS the actual link speed for calculating bandwidth percentages and validating that total guaranteed bandwidths in the policy-map do not exceed the link capacity. Without it, IOS uses the interface's hardware-reported speed (1 Gbps for a GigabitEthernet port) — and a bandwidth 256 command in the policy-map would be treated as 256 kbps out of 1,000,000 kbps (0.026%), which is meaningless. On a physical serial interface running at T1 speed (1.544 Mbps), bandwidth 1544 ensures IOS correctly validates and scales the QoS policy. This is one of the most common MQC misconfiguration issues on Ethernet interfaces used for WAN connections.

One important rule: only one service-policy per direction per interface. Attempting to apply a second service-policy output to the same interface replaces the first. If you need to apply both a marking and a queuing action on egress, combine them into a single policy-map with a hierarchical policy (parent policy-map containing a child policy-map) — covered in advanced MQC labs.

Verify Service-Policy Application with show running-config

NetsTuts_R1#show running-config | section interface gi0

interface GigabitEthernet0/0
 description LAN - Trust Boundary
 ip address 10.1.0.1 255.255.255.0
 service-policy input MARK-INGRESS

interface GigabitEthernet0/1
 description WAN - 1.544 Mbps T1
 ip address 10.0.12.1 255.255.255.252
 bandwidth 1544
 service-policy output WAN-EGRESS

7. Step 4 — Verify with show policy-map interface

show policy-map interface is the primary QoS verification command. It shows every class in the attached policy, the match criteria, the configured actions, and — most importantly — the packet and byte counters that confirm traffic is being classified and acted upon correctly.

show policy-map interface gi0/1 output — Egress Queuing Policy

NetsTuts_R1#show policy-map interface gi0/1 output

 GigabitEthernet0/1

  Service-policy output: WAN-EGRESS

    Class-map: VOICE (match-all)
      5823 packets, 931680 bytes           ← total matched
      5 minute offered rate 200000 bps     ← current rate
      Match: dscp ef (46)
      Priority: 256 kbps, burst bytes 6400, b/w exceed drops: 0
        Output queue: Conversation 264, High Priority queue,
          16384/1464 (size/max packets), Drops: 0
          (pkts output/bytes output) 5823/931680

    Class-map: VOICE-SIGNAL (match-all)
      142 packets, 15620 bytes
      5 minute offered rate 5000 bps
      Match: dscp cs3 (24)
      Queueing
        Output queue: Conversation 265, High Priority queue,
          0/1000 (size/max packets), Drops: 0
      bandwidth: 64 kbps, (current rate: 5 kbps)

    Class-map: VIDEO (match-all)
      18450 packets, 18450000 bytes
      5 minute offered rate 480000 bps     ← close to 512 kbps guarantee
      Match: dscp af41 (34)
      Queueing
        Output queue: Conversation 266, WFQ queue,
          12/1000 (size/max packets), Drops: 0
      bandwidth: 512 kbps, (current rate: 480 kbps)

    Class-map: CRITICAL-DATA (match-all)
      3271 packets, 4742950 bytes
      5 minute offered rate 150000 bps
      Match: dscp af31 (26)
      Queueing
        Output queue: Conversation 267, WFQ queue,
          0/1000 (size/max packets), Drops: 0
      bandwidth: 256 kbps, (current rate: 150 kbps)

    Class-map: BULK-DATA (match-all)
      890 packets, 1424000 bytes
      5 minute offered rate 60000 bps
      Match: dscp af11 (10)
      Queueing
        Output queue: Conversation 268, WFQ queue,
          5/1000 (size/max packets), Drops: 0
      bandwidth: 128 kbps, (current rate: 60 kbps)

    Class-map: SCAVENGER (match-all)
      2104 packets, 3156000 bytes
      5 minute offered rate 180000 bps     ← exceeds 128 kbps limit
      Match: dscp cs1 (8)
        police:
            rate 128000 bps, burst 4000 byte
          conformed  729 packets, 1093500 bytes; actions:
            transmit
          exceeded  1375 packets, 2062500 bytes; actions:
            drop
          conformed 90000 bps, exceeded 90000 bps

    Class-map: class-default (match-any)
      4510 packets, 3382500 bytes
      5 minute offered rate 120000 bps
      Match: any
        Queueing
        Flow based Fair-queue: Classification hierarchy max flows 256
        Output queue: 0/1000 (size/max packets), Drops: 0

Reading show policy-map interface output is the core QoS verification skill. For each class, the key fields are: packets/bytes (total traffic matched since the policy was applied — confirm traffic is hitting the expected class), 5 minute offered rate (current traffic rate — compare against configured bandwidth or priority), Drops (queue drops or police drops — zero drops in normal operation, non-zero in congestion or policing), and current rate (actual bandwidth being used vs guaranteed bandwidth). For the SCAVENGER class, the police output shows 1375 packets exceeded and were dropped — the scavenger traffic arrived at 180 kbps but was policed to 128 kbps, with the excess 50 kbps worth of packets dropped. This is the expected behaviour confirming the police action is working. See show interfaces for baseline interface statistics that complement QoS output.

show policy-map interface gi0/0 input — Ingress Marking Policy

NetsTuts_R1#show policy-map interface gi0/0 input

 GigabitEthernet0/0

  Service-policy input: MARK-INGRESS

    Class-map: MARK-VOICE (match-all)
      5823 packets, 931680 bytes
      5 minute offered rate 200000 bps
      Match: access-group name ACL-IP-PHONE
      QoS Set
        dscp ef                            ← marked these packets EF
          Packets marked 5823

    Class-map: MARK-DATA (match-all)
      3271 packets, 4742950 bytes
      5 minute offered rate 150000 bps
      Match: access-group name ACL-DATA-PC
      QoS Set
        dscp af31
          Packets marked 3271

    Class-map: MARK-BULK (match-all)
      890 packets, 1424000 bytes
      5 minute offered rate 60000 bps
      Match: access-group name ACL-BULK-PC
      QoS Set
        dscp af11
          Packets marked 890

    Class-map: class-default (match-any)
      312 packets, 124800 bytes
      5 minute offered rate 5000 bps
      Match: any
      QoS Set
        dscp default                       ← overwrite any rogue markings
          Packets marked 312

Additional Verification Commands

! ── Show all policy-maps configured (summary) ─────────────
NetsTuts_R1#show policy-map

  Policy Map MARK-INGRESS
    Class MARK-VOICE
      set dscp ef
    Class MARK-DATA
      set dscp af31
    Class MARK-BULK
      set dscp af11
    Class class-default
      set dscp default

  Policy Map WAN-EGRESS
    Class VOICE
      priority 256 (kbps)
    Class VOICE-SIGNAL
      bandwidth 64 (kbps)
    ...

! ── Show policy-map on a specific interface, both directions
NetsTuts_R1#show policy-map interface gi0/1

! ── Show queue statistics only (no class detail) ──────────
NetsTuts_R1#show queue gi0/1

! ── Reset policy counters (clears packet/byte counts) ─────
NetsTuts_R1#clear counters gi0/1

! ── Show all class-maps defined ───────────────────────────
NetsTuts_R1#show class-map

! ── Confirm a specific packet's DSCP after marking ────────
! ── (debug — only in lab, CPU intensive) ──────────────────
NetsTuts_R1#debug ip packet detail
! ── (stop with:) ──────────────────────────────────────────
NetsTuts_R1#undebug all

8. Common MQC Patterns — Ready-to-Use Configurations

Pattern 1 — Bandwidth Percent (Relative to Interface Speed)

! ── Using bandwidth percent instead of absolute kbps ──────
! ── Useful when deploying the same policy across links ─────
! ── of different speeds (no need to change the policy-map) ─

NetsTuts_R1(config)#policy-map WAN-EGRESS-PERCENT
NetsTuts_R1(config-pmap)# class VOICE
NetsTuts_R1(config-pmap-c)#  priority percent 10     ← 10% of link speed
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)# class VIDEO
NetsTuts_R1(config-pmap-c)#  bandwidth percent 30    ← 30% guaranteed
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)# class CRITICAL-DATA
NetsTuts_R1(config-pmap-c)#  bandwidth percent 20    ← 20% guaranteed
NetsTuts_R1(config-pmap-c)# exit
NetsTuts_R1(config-pmap)# class class-default
NetsTuts_R1(config-pmap-c)#  bandwidth percent 25    ← 25% minimum
NetsTuts_R1(config-pmap-c)# exit
! ── Remaining 15% available for burst/overflow ────────────
NetsTuts_R1(config-pmap)#exit

! ── The same policy-map can now be applied to a 10 Mbps ───
! ── or 100 Mbps interface and the percentages scale ────────
! ── automatically with the configured bandwidth statement ──

Percentage-based bandwidth allocation is the recommended approach for policies that will be deployed on many interfaces of varying speeds. With absolute kbps values, you would need a different policy-map for each link speed. With bandwidth percent, one policy-map works everywhere — IOS calculates the actual kbps from the interface's bandwidth statement. The total of all bandwidth percent values including priority percent must not exceed 100% (or more precisely, 75% for named classes by default, with the remaining 25% reserved for routing protocol overhead and class-default minimum).

Pattern 2 — Policing with Three-Colour Marking

! ── Three-colour policing: conform/exceed/violate ─────────
! ── Used at ISP handoff to enforce contracted CIR/PIR ─────
! ── CIR = Committed Information Rate (always delivered) ───
! ── PIR = Peak Information Rate (delivered if capacity) ───
! ── Excess beyond PIR: dropped ────────────────────────────

NetsTuts_R1(config)#policy-map ISP-HANDOFF-POLICE
NetsTuts_R1(config-pmap)# class class-default
NetsTuts_R1(config-pmap-c)#
NetsTuts_R1(config-pmap-c)#  police rate 1000000 bps   peak-rate 2000000 bps
NetsTuts_R1(config-pmap-c)#                             burst 31250 peak-burst 62500
NetsTuts_R1(config-pmap-c)#   conform-action  transmit                ← within CIR
NetsTuts_R1(config-pmap-c)#   exceed-action   set-dscp-transmit af12  ← CIR

  Pattern 3 — NBAR Application-Based Classification
  ! ── Classify by application protocol using NBAR2 DPI ──────
! ── (requires ip nbar protocol-discovery on the interface) ─

NetsTuts_R1(config)#class-map match-any STREAMING-VIDEO
NetsTuts_R1(config-cmap)# description Streaming video apps - NBAR
NetsTuts_R1(config-cmap)# match protocol youtube
NetsTuts_R1(config-cmap)# match protocol netflix
NetsTuts_R1(config-cmap)# match protocol attribute category streaming-video
NetsTuts_R1(config-cmap)#exit

NetsTuts_R1(config)#class-map match-any VOIP-APPS
NetsTuts_R1(config-cmap)# description VoIP applications - NBAR
NetsTuts_R1(config-cmap)# match protocol cisco-phone
NetsTuts_R1(config-cmap)# match protocol rtp
NetsTuts_R1(config-cmap)# match protocol sip
NetsTuts_R1(config-cmap)#exit

NetsTuts_R1(config)#class-map match-any BUSINESS-SAAS
NetsTuts_R1(config-cmap)# description Business SaaS - NBAR
NetsTuts_R1(config-cmap)# match protocol attribute category office-suite
NetsTuts_R1(config-cmap)# match protocol salesforce
NetsTuts_R1(config-cmap)# match protocol ms-office-365
NetsTuts_R1(config-cmap)#exit

! ── Enable NBAR protocol discovery on the interface ───────
NetsTuts_R1(config)#interface gi0/0
NetsTuts_R1(config-if)# ip nbar protocol-discovery
NetsTuts_R1(config-if)#exit

! ── Verify NBAR is recognising protocols ──────────────────
NetsTuts_R1#show ip nbar protocol-discovery interface gi0/0 stats byte-count top-n 10

GigabitEthernet0/0
      30 Second Rate              Cumulative Count
      Input        Output         Input            Output
Protocol           bps            bps              Bytes           Bytes
-------------------------------------------------------------------
youtube            0              245000           0               14750000
sip                24000          12000            1440000         720000
rtp                180000         165000           10800000        9900000
http               15000          8000             900000          480000
  
  
    NBAR2 (Network-Based Application Recognition) performs deep
    packet inspection to identify applications by their protocol
    signatures — not just port numbers. This is critical for modern
    applications that use dynamic ports or HTTPS: NBAR can identify
    YouTube traffic on port 443 that a standard ACL would classify
    as generic HTTPS. The match protocol attribute
    category syntax uses NBAR's application categories to
    match a group of related protocols with a single statement —
    category streaming-video matches all known streaming
    video services without listing each one individually. NBAR does
    add some CPU overhead, so its use should be limited to interfaces
    where fine-grained application classification is genuinely
    required and the router has sufficient processing capacity.
  

  Pattern 4 — Queue-Limit and DSCP-Based WRED
  ! ── queue-limit: control max queue depth (prevents bufferbloat)
! ── random-detect: WRED — probabilistic early drop before queue fills

NetsTuts_R1(config)#policy-map WAN-EGRESS-WRED
NetsTuts_R1(config-pmap)#

NetsTuts_R1(config-pmap)# class VOICE
NetsTuts_R1(config-pmap-c)#  priority 256
NetsTuts_R1(config-pmap-c)# exit

NetsTuts_R1(config-pmap)# class CRITICAL-DATA
NetsTuts_R1(config-pmap-c)#  bandwidth 256
NetsTuts_R1(config-pmap-c)#  queue-limit 64 packets   ← max 64 pkts in queue
NetsTuts_R1(config-pmap-c)#  random-detect dscp-based  ← WRED by DSCP value
NetsTuts_R1(config-pmap-c)# exit

NetsTuts_R1(config-pmap)# class BULK-DATA
NetsTuts_R1(config-pmap-c)#  bandwidth 128
NetsTuts_R1(config-pmap-c)#  queue-limit 32 packets   ← smaller queue = faster response
NetsTuts_R1(config-pmap-c)#  random-detect dscp-based
NetsTuts_R1(config-pmap-c)# exit

NetsTuts_R1(config-pmap)# class class-default
NetsTuts_R1(config-pmap-c)#  fair-queue
NetsTuts_R1(config-pmap-c)#  queue-limit 128 packets
NetsTuts_R1(config-pmap-c)# exit

NetsTuts_R1(config-pmap)#exit
  
  
    queue-limit caps the maximum number of packets
    that can wait in a class's queue — when the queue is full,
    new arrivals are tail-dropped. Setting a smaller queue limit
    reduces latency (packets wait less time) but increases drop
    rate during bursts. random-detect dscp-based
    enables WRED (Weighted Random Early Detection) — it starts
    probabilistically dropping packets before the queue is
    completely full, which signals TCP senders to slow down
    before a catastrophic full-queue tail-drop event. WRED is
    most effective for TCP bulk data flows (file transfers,
    database backups) and should not be applied to voice queues
    (which use the priority command and have their own policing).

9. Troubleshooting MQC Policies

Symptom	Diagnosis	Cause and Fix
Policy-map rejected with "bandwidth sum exceeds the interface bandwidth" when applying service-policy	`show policy-map [name]` — review total bandwidth allocations. `show interfaces gi0/1 \| include BW` — check reported interface bandwidth	The total of all `bandwidth` and `priority` allocations in the policy-map exceeds 75% of the interface bandwidth. Either reduce the allocations, increase the `bandwidth` statement on the interface to reflect the actual link speed, or use `max-reserved-bandwidth 100` on the interface to remove the 25% reservation (use with care)
Traffic not matching the expected class — all packets going to class-default	`show policy-map interface gi0/1 output` — check packet counters per class. Zero packets in named classes means classification is failing	Class-map mismatch: the DSCP value on the packets does not match the `match dscp` statement, or the ACL in `match access-group` does not match the traffic. Verify with `show policy-map interface gi0/0 input` — are the marking counters incrementing? If the marking policy counter also shows zero, the ACLs may not match the traffic. Use `debug ip packet detail` briefly to check packet DSCP values
Voice still experiencing delay even with LLQ configured	`show policy-map interface` — check `b/w exceed drops` counter on the VOICE priority class. Check queue depth on other classes	If `b/w exceed drops` is non-zero, voice is sending more than the configured priority rate and the excess is being policed (dropped). Increase the `priority` kbps value to match actual voice traffic volume. Also verify the marking policy (MARK-INGRESS) is correctly marking voice as DSCP EF — if voice is marked incorrectly it will fall into a non-priority class
Scavenger traffic not being policed — still consuming full bandwidth	`show policy-map interface` — check police conformed/exceeded counters. If conformed count equals total packets (no exceeded), the police rate is too high	Police rate configured correctly but the upstream marking policy is not marking scavenger traffic as DSCP CS1. Scavenger traffic marked as DSCP 0 falls into class-default, not the SCAVENGER class. Verify the marking policy is correctly identifying and marking the scavenger traffic sources
Removing or changing a policy-map that is already applied to an interface	IOS does not allow modification of a policy-map that is currently attached to an interface via service-policy	Remove the service-policy from the interface first (`no service-policy output WAN-EGRESS`), make changes to the policy-map, then re-apply (`service-policy output WAN-EGRESS`). This causes a brief interruption in QoS enforcement during the change window. In IOS-XE 16.x and later, some in-service policy changes are permitted
NBAR classification not working — traffic falling to class-default	`show ip nbar protocol-discovery interface [intf]` — verify NBAR is seeing and classifying the protocol traffic	`ip nbar protocol-discovery` not enabled on the interface, NBAR protocol pack out of date (update with `ip nbar protocol-pack [file]`), or the application uses certificate pinning/encryption that prevents DPI classification. As a fallback, use DSCP-based or ACL-based classification

Key Points & Exam Tips

MQC is always three steps: class-map (define what traffic), policy-map (define what to do), service-policy (activate on an interface). Nothing happens to traffic until service-policy is applied. Know this sequence for every QoS question.
class-map match-all vs match-any: match-all (default) requires ALL match statements to be true — logical AND. match-any requires ANY match statement to be true — logical OR. A class-map with a single match statement behaves the same either way.
class-default is always implicitly present in every policy-map and catches all traffic not matched by any named class. You reference it in the policy-map but never create a class-map for it. Forgetting to define an action for class-default means unclassified traffic gets no QoS treatment (forwarded as best-effort with no guarantee).
LLQ vs CBWFQ: priority [kbps] creates a strict-priority (LLQ) queue — always served first, policed if it exceeds the rate. Use for voice (DSCP EF). bandwidth [kbps] creates a CBWFQ queue — guaranteed minimum during congestion, can use more if available. Use for video and data classes. Only one priority class is typically configured per policy-map.
Police vs Shape: police drops (or re-marks) excess packets immediately — no additional delay, but causes packet loss. shape buffers excess packets and smooths the output rate — no drops (unless the shape buffer fills), but adds delay and jitter. Shape is preferred before a policed link; police is used for enforcement. On the exam, know that policing is a two-bucket (conform/exceed) or three-bucket (conform/exceed/violate) token algorithm.
The bandwidth statement on the interface is critical for MQC on Ethernet WAN links. If the interface has bandwidth 1544 (for a T1) but the policy-map uses bandwidth 512, IOS calculates 512/1544 = 33% allocation. If the bandwidth statement is missing or wrong, all percentage and validation calculations are incorrect.
Service-policy direction: input is applied to arriving (ingress) traffic — used for marking and policing. output is applied to departing (egress) traffic — used for queuing and shaping. Queuing policies (priority/bandwidth) only make sense on egress — congestion is an egress phenomenon (too much traffic trying to leave). On the exam, if a question involves voice quality or bandwidth guarantees, the answer typically involves an output service-policy.
show policy-map interface is the verification command. The key fields to check: packet/byte counters per class (confirm classification is working), b/w exceed drops on priority class (LLQ policing drops — should be zero or very low), police conformed/exceeded/violated counters (confirm policing rates), and queue depth (current/max — a full queue indicates sustained congestion).
The trust boundary pattern: ingress marking policy (service-policy input) at the access layer or WAN ingress, followed by DSCP-based classification in the egress queuing policy (service-policy output) at the WAN link. For MQC used to protect the router's own control plane, see Control Plane Policing (CoPP) — the identical three-step MQC framework applied to control-plane instead of an interface.

Next Steps: This lab covers the MQC framework fundamentals. The natural progressions are: DSCP marking and classification in depth — see DSCP Marking & Classification which covers per-hop behaviour (PHB) and the full DSCP value space. For policing and shaping in detail — see Traffic Policing & Shaping which covers dual-rate policing, hierarchical policies, and traffic shaping with shape average. For complete voice QoS with LLQ and the recommended Cisco QoS baseline — see CBWFQ & LLQ Configuration which covers the full voice-ready QoS policy model. For CoPP which uses the identical MQC framework to protect the router CPU, see Control Plane Policing (CoPP). For voice VLANs that feed into QoS policies, see Voice VLAN Configuration. For ACLs used in class-map match criteria, see Extended ACL Configuration.

TEST WHAT YOU LEARNED

1. A network engineer configures a class-map, a policy-map referencing that class-map, and saves the configuration. They observe no change in traffic behaviour. What is the missing step and why does the omission have no effect on traffic?

A. The missing step is enabling QoS globally with the mls qos command. On IOS routers, QoS is disabled by default and the class-map and policy-map are validated but not enforced until QoS is globally enabled B. The missing step is committing the configuration with ip qos commit. MQC configurations are staged and require an explicit commit command to activate, similar to candidate datastore workflows in NETCONF C. The missing step is applying the policy-map to an interface with the service-policy command. In the MQC framework, a class-map is only a traffic filter definition and a policy-map is only a list of actions — neither has any effect on traffic until the policy-map is attached to a specific interface in a specific direction (input or output) using service-policy. The policy activates only on traffic transiting the interface it is applied to, in the specified direction. Without service-policy, the configuration objects exist in memory but intercept no packets D. The missing step is creating a class-default class-map to match all remaining traffic. Without class-default, IOS does not activate the policy-map because it has no catch-all entry and may drop all unmatched traffic by accident

Correct answer is C. This is the most fundamental MQC concept and the most common mistake in QoS configurations. The MQC framework is deliberately modular: class-maps and policy-maps are reusable definitions that can be created and modified independently of any interface. They have zero effect on traffic until explicitly activated on an interface with service-policy [input|output] [policy-map-name]. This design is intentional — it allows you to build and verify complex QoS policies in configuration without affecting live traffic, and then apply them to multiple interfaces simultaneously. The same policy-map can be applied to many interfaces (which is why class-map and policy-map are global objects, not interface-specific objects). Option A describes the behaviour of Catalyst switches using the old MLS QoS framework, not IOS routers using MQC — on routers, MQC does not require global enablement. Option D is incorrect — class-default does not need to be explicitly created; it is implicitly present in every policy-map and IOS activates the policy regardless of whether you define an action for class-default.

2. What is the difference between the `priority` command and the `bandwidth` command in a policy-map class, and why does using `priority` for every class defeat its purpose?

A. priority [kbps] creates a strict-priority (LLQ) queue — packets in this queue are always dequeued and transmitted before any packet in any other queue, regardless of other queues' state. The specified kbps is a policed ceiling: if the priority class sends more than this rate, the excess is dropped immediately (not queued). This guarantees that voice packets never wait behind bulk data. bandwidth [kbps] creates a CBWFQ class — it guarantees the class will receive at least the specified rate during congestion, but packets wait in the class queue for their turn. If the link is uncongested, a bandwidth class can use more than its guaranteed rate. Using priority for every class means every class thinks it gets absolute preferential treatment — but strict priority only has meaning relative to non-priority classes. With all classes at strict priority, the queue scheduler degenerates to a FIFO and the individual kbps limits simply become independent policers, losing the differentiated scheduling advantage B. priority is for Layer 2 CoS-based classes and bandwidth is for Layer 3 DSCP-based classes. Using priority for DSCP-marked traffic causes the router to re-examine the CoS field, which may be absent on routed packets C. The commands are interchangeable — both guarantee the specified bandwidth. The only difference is that priority allows burst above the configured rate while bandwidth strictly enforces the rate as a ceiling. Using both together in the same policy-map causes an error D. priority guarantees bandwidth but allows the class to be preempted by other classes during periods of extremely high congestion. bandwidth provides a non-preemptable hard reservation. The recommendation is to use bandwidth for voice and priority for best-effort to ensure voice is never preempted

Correct answer is A. The strict-priority vs weighted-fair distinction is one of the most tested QoS concepts. LLQ (the priority command) creates a queue with absolute scheduling priority — when the scheduler runs, it always services the priority queue completely before looking at any other queue. This is exactly what voice traffic needs: a voice call generates small packets (typically 60–200 bytes) at a steady rate, and even a few milliseconds of waiting behind a large file transfer causes perceptible jitter and degrades call quality. The policed ceiling on the priority class is equally important: without it, a misbehaving application marking itself as DSCP EF could flood the priority queue and starve all other traffic. The kbps limit in priority 256 means "serve this queue first, but if it tries to use more than 256 kbps, police the excess." The reason not to use priority for every class is that strict priority only works when there is a clear hierarchy — some classes definitely more important than others. With multiple priority classes of the same precedence level, IOS rounds-robins between them (eliminating the strict-priority benefit) or simply applies individual per-class policing without differentiated scheduling. Best practice: one priority class (voice/EF), bandwidth classes for all other named classes, and class-default for remaining traffic.

3. An engineer applies a WAN egress queuing policy to interface Gi0/1. During a lab test with light traffic, they observe that every class shows 0 Drops and approximately equal transmission rates regardless of their bandwidth guarantees. Is this a problem?

A. Yes — this indicates the policy-map is not functioning. The bandwidth guarantees should enforce strict rate limits even when the link is uncongested. Zero drops across all classes means traffic is not being properly classified B. Yes — the policy is only partially working. The priority class should always show higher transmission rates than bandwidth classes even during light load. Equal rates across all classes means the LLQ is not correctly configured C. Yes — 0 Drops always indicates a misconfiguration. A properly functioning QoS policy should show some drops on lower-priority classes to confirm the scheduler is making preferential decisions D. No — this is correct and expected behaviour. MQC queuing policies (bandwidth guarantees, LLQ priority) only activate when the interface is congested — when the total offered traffic exceeds the interface's transmit rate. When the link is lightly loaded, every packet is transmitted immediately regardless of its class, because there are no competing packets waiting in queue. The bandwidth guarantees are minimums, not maximums — a class with bandwidth 64 can use much more than 64 kbps when other classes are idle. 0 Drops confirms there is no congestion, which is good. To observe QoS differentiation in a lab, generate traffic that exceeds the interface rate using traffic generators on multiple classes simultaneously and observe which classes drop and which are protected

Correct answer is D. This is a critical conceptual point that trips up many QoS practitioners and is frequently tested. Queuing algorithms (LLQ, CBWFQ, WFQ) are idle when there is no queue — they only activate at the moment the output queue has more packets waiting than the interface can immediately transmit. A simple mental model: think of a single-lane road. When there are only 5 cars, they all move freely regardless of car type. Traffic management (priority lanes, merge rules) only matters when hundreds of cars are competing for the same lane. Testing a QoS policy correctly requires generating congestion: send traffic from all classes simultaneously at a combined rate exceeding the interface bandwidth. Under those conditions, you will observe the priority class (voice) being served first with near-zero drops, bandwidth classes being served at their guaranteed rates, and class-default or scavenger classes absorbing the drops. The show policy-map interface counters will then show meaningful differentiation. For the police action, however, congestion is not required — policing takes effect whenever a flow exceeds its committed rate regardless of overall interface utilisation, because policing is a rate measure, not a queue measure.

4. What is the purpose of a `set dscp default` action on the `class-default` class in an ingress marking policy, and what security risk does omitting it create?

A. set dscp default on class-default improves performance by pre-marking best-effort traffic so downstream routers do not need to evaluate it. Omitting it causes downstream routers to spend extra processing cycles classifying the unmarked traffic, slightly increasing CPU utilisation on all routers in the path B. set dscp default on class-default erases any DSCP markings that untrusted end devices may have self-applied. End users can configure their operating system, application, or even a USB network adapter to set arbitrary DSCP values on outgoing packets — for example, marking all web-browsing traffic as DSCP EF (46) to self-assign LLQ priority treatment on the WAN. Without set dscp default on class-default, a packet from a user PC marked DSCP EF would pass through the ingress marking policy unmodified (it does not match the MARK-VOICE class because it does not come from the IP phone subnet), exit with DSCP EF still set, and then be classified into the VOICE class at the egress queuing policy — receiving strict-priority LLQ treatment it was not entitled to. By explicitly setting DSCP 0 on all unmatched traffic, the router asserts the trust boundary: only packets from authorised, identified sources carry elevated DSCP markings beyond this point C. set dscp default is required for IOS to correctly process the class-default class — without it, the class-default entry in the policy-map is treated as a no-operation and IOS may not activate the marking policy at all D. set dscp default configures the router to use the IP header's default ToS byte for best-effort traffic rather than the 802.1Q CoS field. This ensures consistent QoS treatment across both Layer 2 and Layer 3 boundaries when the traffic exits from VLAN trunks onto routed interfaces

Correct answer is B. The trust boundary and the security implication of omitting set dscp default on class-default is a very common exam topic and a real production concern. The attack is straightforward: a user on a corporate PC sets DSCP EF on all their outgoing traffic. Their traffic arrives at the router's LAN interface marked EF. The ingress marking policy's MARK-VOICE class uses an ACL matching only the IP phone subnet (10.1.0.10) — the PC's traffic (10.1.0.20) does not match MARK-VOICE, MARK-DATA, or MARK-BULK. It falls to class-default. If class-default has no action or a non-DSCP-modifying action, the EF marking is preserved. The traffic then exits Gi0/0 with DSCP EF intact, enters the WAN-EGRESS queuing policy on Gi0/1, matches the VOICE class (which matches DSCP EF), and receives strict-priority LLQ treatment — potentially starving legitimate voice calls if the scavenger user generates enough traffic. The set dscp default action prevents this by ensuring that everything not explicitly identified and marked gets DSCP 0 (best-effort) at the trust boundary. This is why the trust boundary pattern always includes a class-default marking action in the ingress policy.

5. The `show policy-map interface gi0/1 output` command shows the VOICE class with `b/w exceed drops: 1523`. What does this indicate and how should it be resolved?

A. b/w exceed drops on the VOICE class means the egress WAN interface is dropping voice packets due to general interface congestion — the interface output queue is full. The fix is to upgrade the WAN link to a higher-bandwidth circuit B. b/w exceed drops indicates the VOICE class is receiving less bandwidth than configured — the router is throttling voice below its 256 kbps priority allocation. This is caused by the other classes consuming too much bandwidth, leaving insufficient capacity for voice. Reduce the bandwidth allocations of other classes C. b/w exceed drops: 1523 means the VOICE class (LLQ) is sending traffic at a rate above its configured priority rate (256 kbps), and the built-in LLQ policer is dropping the excess. The LLQ priority command guarantees the class will be served first up to the specified rate, but enforces a policed ceiling — traffic exceeding the rate is dropped immediately to prevent the strict-priority queue from monopolising the entire link and starving all other classes. The resolution is to either increase the priority kbps value if legitimate voice traffic genuinely requires more than 256 kbps (e.g., more concurrent calls than planned), or investigate whether non-voice traffic is being incorrectly marked as DSCP EF and filling the priority queue D. b/w exceed drops is an informational counter that increments whenever the voice class has any packets in the queue — it counts the total number of times the voice class was serviced by the scheduler. A value of 1523 indicates 1523 scheduling cycles occurred, which is normal and not indicative of any problem

Correct answer is C. The b/w exceed drops counter specifically tracks packets that were dropped by the LLQ's internal policer — packets that arrived in the priority queue but exceeded the configured rate ceiling. This is a built-in safety mechanism of LLQ: because the priority queue is always served first (before any other class), an unlimited priority queue could theoretically starve all other traffic. The rate limit prevents this. When b/w exceed drops is non-zero, it means one of two things: (1) there are more concurrent voice calls than the priority bandwidth was sized for (legitimate oversubscription), or (2) non-voice traffic has been incorrectly marked as DSCP EF and is competing for the priority queue. Diagnosing the cause: check the ingress marking policy's counters — is the MARK-VOICE class counting more packets than expected (suggesting mis-marked traffic)? Check the 5-minute offered rate on the VOICE class — is it consistently above 256 kbps? If this is a busy voice deployment, the offered rate tells you how much bandwidth voice actually needs. The fix is either to increase priority 256 to a larger value (after verifying there is remaining budget in the policy), or to tighten the marking policy to prevent mis-marked traffic from entering the priority class.

6. What is the difference between policing and shaping, and in what scenario would you use shaping rather than policing on a WAN egress interface?

A. Policing applies to UDP traffic (connectionless — drops are acceptable) while shaping applies to TCP traffic (connection-oriented — drops cause retransmission and congestion collapse). IOS automatically selects the appropriate mechanism based on the protocol type when you configure the police or shape command B. Policing is applied at ingress (incoming traffic rate-limiting) and shaping is applied at egress (outgoing rate-smoothing). The direction determines which tool to use — policing enforces what comes in, shaping controls what goes out. Both mechanisms drop excess packets; the difference is only the interface direction C. Policing and shaping are functionally identical — both drop excess traffic when a configured rate is exceeded. The only difference is that shaping stores a configuration of the desired rate in NVRAM while policing applies it only to the running configuration. Shaping is preferred for permanent rate limits, policing for temporary ones D. Policing enforces a rate limit by dropping or re-marking excess packets immediately — packets that exceed the committed rate are discarded with no delay. This is efficient (no buffering overhead) but causes packet loss and TCP retransmissions. Shaping enforces a rate limit by buffering excess packets and transmitting them at a smoothed, metered rate — packets are delayed rather than dropped (unless the shape buffer itself overflows). The scenario for shaping: when your organisation's WAN egress interface runs at 10 Mbps but the ISP has contracted you to a CIR of 2 Mbps and polices everything above that at their edge. Without shaping, your router sends bursts to 10 Mbps, the ISP policer drops the burst, TCP retransmits, and effective throughput is lower than 2 Mbps due to retransmit overhead. With shaping at 2 Mbps on the customer router, traffic is metered before it reaches the ISP policer — no drops at the ISP edge, full 2 Mbps utilisation, lower latency than a drop-and-retransmit cycle

Correct answer is D. The policing vs shaping distinction is a classic exam topic. The key operational difference is drop vs delay: policing is instantaneous and stateless (no buffers, just a token bucket and a drop action); shaping maintains a queue to hold excess packets and releases them at the metered rate. Option B is wrong — policing can be applied in either direction (input policing is common for enforcing customer commitments at a service provider edge; output policing is used for scavenger class limiting). The shaping use case in option D is the canonical real-world scenario: a 10 Mbps Ethernet handoff where the service is contracted at 2 Mbps CIR. The customer-side router "shapes" the egress to 2 Mbps, which causes TCP senders to slow down naturally (TCP's congestion window responds to the reduced available bandwidth) without the additional overhead of ISP-side drops and retransmissions. There is a cost: shaping adds latency and jitter because packets wait in the shape buffer. For most data traffic this is acceptable; for voice traffic behind a shaper, additional LLQ within a hierarchical policy-map (a child policy inside the shape class) is used to ensure voice packets are dequeued from the shape buffer immediately rather than waiting behind other shaped traffic. This hierarchical MQC pattern is covered in the upcoming Traffic Shaping vs Policing lab.

7. A policy-map has the following class order: CRITICAL-DATA (match dscp af31), BULK-DATA (match dscp af11), VOICE (match dscp ef). A packet arrives with DSCP EF. Which class does IOS assign it to, and does the order of classes in the policy-map affect the result?

A. IOS assigns the packet to the VOICE class regardless of the order in the policy-map. For DSCP-based class-maps, each class matches a specific, non-overlapping DSCP value — DSCP EF (46) can only match the VOICE class (match dscp ef) because it does not match match dscp af31 or match dscp af11. The class order in the policy-map does not matter when match criteria are mutually exclusive (non-overlapping). Order matters only when classes have overlapping match criteria — for example, two ACL-based classes where a packet's source IP could match both ACLs. In that case, the first matching class in the policy-map wins B. IOS evaluates classes in the order they appear in the policy-map. Since CRITICAL-DATA appears first, IOS checks if the packet matches DSCP AF31. It does not. IOS then checks BULK-DATA (AF11). It does not match. IOS then checks VOICE (EF). It matches. The packet is assigned to VOICE. The result is correct, but the order of evaluation matters — if VOICE appeared first, the packet would also be correctly assigned to VOICE. Order only matters if two classes could match the same packet C. DSCP EF (46) falls numerically between AF41 (34) and CS5 (40), so it does not match any of the named classes and falls to class-default. DSCP matching uses exact value comparison only when the mnemonic used in the match statement is an exact alias for the decimal value D. IOS assigns the packet to class-default because the VOICE class appears last in the policy-map and IOS stops evaluating after finding the first class that does not match (CRITICAL-DATA). The packet would only reach the VOICE class if it were listed first

Correct answer is A. Option B is also correct in its description of IOS's evaluation process (top-down, first match wins) but incorrectly implies that order always matters. The key distinction is whether the match criteria can overlap. DSCP values are discrete and non-overlapping in a well-designed policy: DSCP EF (46) can only match a match dscp ef statement, never match dscp af31 or match dscp af11. So for DSCP-only class-maps, the order is irrelevant — each DSCP value has exactly one matching class. Order becomes critical with ACL-based class-maps: if CLASS-A matches source IP 10.0.0.0/8 and CLASS-B matches source IP 10.1.0.0/16, a packet from 10.1.0.1 matches both. If CLASS-A appears first, the packet is assigned to CLASS-A; if CLASS-B appears first, it goes to CLASS-B. For exam purposes: know that IOS uses first-match-wins, that non-overlapping DSCP matches are order-independent, and that overlapping ACL or protocol matches require careful ordering with the most specific class first (analogous to ACL statement ordering — more specific rules before less specific rules). This is the same concept as ACL ordering covered in Extended ACL Configuration.

8. Why is the `bandwidth [kbps]` interface command important for MQC policies, and what incorrect behaviour occurs if it is set to the wrong value or omitted on a WAN Ethernet interface?

A. The bandwidth interface command determines the physical line speed of the interface. Setting it incorrectly changes the actual interface speed, potentially causing link negotiation failures or autonegotiation mismatches with the connected device B. The bandwidth interface command affects only routing protocol metric calculations (OSPF, EIGRP). It has no effect on MQC policy enforcement — MQC always uses the actual hardware-reported interface speed regardless of the configured bandwidth statement C. The bandwidth [kbps] interface command tells the IOS QoS system the logical speed of the WAN link for two purposes: (1) policy validation — IOS checks that the total of all bandwidth and priority allocations in the policy-map does not exceed 75% of the stated interface bandwidth. If the interface is reported as 1 Gbps (its physical speed) but the actual WAN circuit is 1.544 Mbps, a bandwidth 512 command in the policy-map would be validated as 512/1,000,000 kbps = 0.051% — effectively unlimited. The policy would never reject any configuration, and percentage-based bandwidth allocations would calculate to meaningless values. (2) queue activation — the CBWFQ scheduler uses the interface bandwidth to determine when congestion exists (output rate approaching the stated bandwidth) and when to activate queuing. Without the correct bandwidth statement, the scheduler may not activate queuing at the right utilisation threshold, causing QoS to be ineffective even when the WAN circuit is fully saturated. Set bandwidth to match the actual WAN circuit speed, not the physical port speed D. The bandwidth interface command sets the maximum transmit rate for all traffic regardless of QoS policy — it is a hard rate limiter at the interface level. Setting it to 1544 on a GigabitEthernet interface physically limits the port to 1.544 Mbps output rate, effectively simulating a T1 circuit in a lab environment

Correct answer is C. This is a very common real-world MQC misconfiguration and an important exam point. GigabitEthernet interfaces always auto-negotiate to 1 Gbps (1,000,000 kbps) hardware speed. When a GigabitEthernet port is used as a WAN handoff to an ISP that provides, say, a 10 Mbps service, the physical port runs at 1 Gbps — but the ISP polices everything above 10 Mbps at their edge. Without bandwidth 10000 on the interface, IOS MQC believes the interface is 1 Gbps and: (1) allows policy-map configurations that sum to gigabits of bandwidth guarantees that are meaningless on a 10 Mbps service; (2) never activates the CBWFQ scheduler because the interface utilisation never approaches 1 Gbps (it is capped at 10 Mbps by the ISP policer, which from the router's perspective just looks like normal traffic flow). The QoS policy exists in configuration but never activates, because the router's queue depth never builds up — packets are transmitted at full 1 Gbps to the switch/ISP which then polices them, and the drops happen at the ISP, not at the router queue. Setting bandwidth 10000 causes IOS to start queuing when the output rate approaches 10 Mbps, correctly activating QoS at the right threshold. Option D is incorrect — bandwidth is an informational command that does not physically rate-limit the interface. To physically rate-limit an interface, you would use a traffic shaping policy.

9. What happens to traffic assigned to `class-default` in a WAN-EGRESS policy-map that has `fair-queue` configured for class-default, and how does fair-queue differ from a simple FIFO queue?

A. fair-queue on class-default means all traffic in class-default is dropped — it is a shorthand for drop and is used to discard any traffic that was not explicitly matched by a named class. Traffic that should be forwarded must be explicitly classified into a named class with a bandwidth guarantee B. fair-queue in class-default configures flow-based Weighted Fair Queuing for all unclassified traffic. WFQ divides the remaining link bandwidth (after subtracting bandwidth allocated to named classes and the priority class) among all active traffic flows in class-default, giving each flow approximately equal share. This prevents a single high-volume flow (e.g., a large FTP transfer) from consuming all of the class-default bandwidth and starving other flows within class-default. In contrast, a FIFO queue processes packets strictly in arrival order — the large FTP transfer floods the FIFO and smaller interactive flows wait behind it. WFQ with flow classification ensures the FTP transfer and, say, an interactive web browsing session each get roughly equal throughput from the available class-default bandwidth, without any per-application configuration C. fair-queue in class-default applies DSCP-based differential weighting — higher DSCP values within class-default get proportionally more bandwidth. A packet with DSCP AF11 gets more bandwidth than a packet with DSCP 0, even though both fell to class-default because they were not matched by any named class D. fair-queue converts class-default into a strict-priority queue for the specific traffic flows that appear most frequently. IOS monitors which flows are sending the most packets and promotes them to a faster queue, rewarding active senders with better service. Less frequent flows wait in the standard FIFO portion

Correct answer is B. Flow-based WFQ (the fair-queue command) is an important concept that distinguishes intelligent QoS from naive queue management. WFQ identifies individual traffic flows (typically by the 5-tuple: source IP, destination IP, source port, destination port, protocol) and maintains a separate virtual queue per flow. When the scheduler runs, it services flows in a round-robin fashion weighted by their IP Precedence or DSCP — each active flow gets a fair share. The benefit for class-default is significant: in a typical network, class-default contains a mix of many different flows. Without WFQ, a single large file transfer (generating hundreds of large packets per second) would dominate the FIFO queue and cause latency for many other smaller flows. With WFQ, the file transfer's many packets are spread across one virtual queue that gets one share, while 50 other individual interactive flows each get their own share — the interactive flows experience much lower latency even though they are not individually configured in any named class. This is "fair" in the WFQ sense: each flow gets equal opportunity to transmit regardless of volume. The practical implication: fair-queue on class-default is good practice for WAN interfaces because it provides automatic fairness among unclassified traffic without any per-flow configuration. The alternative (queue-limit with tail-drop) would cause large-flow TCP senders to monopolise the class-default bandwidth.

10. A policy-map is already applied to interface Gi0/1 (`service-policy output WAN-EGRESS`). An engineer needs to add a new class for streaming video with a 200 kbps bandwidth guarantee. What is the correct procedure and what is the risk if done incorrectly?

A. The engineer can directly edit the existing WAN-EGRESS policy-map by entering policy-map WAN-EGRESS and adding the new class. IOS immediately applies the change to the active policy on Gi0/1 without any service interruption or need to remove the service-policy B. The engineer applies a second service-policy to Gi0/1 with a new policy-map that includes only the new video class. IOS automatically merges the two policy-maps into a combined policy. This is the recommended method for incremental policy updates without disrupting existing classes C. The engineer creates a new policy-map WAN-EGRESS-V2 with all existing classes plus the new video class, then removes the old service-policy and applies the new one simultaneously with a single configuration line. IOS processes both commands atomically without any traffic disruption D. On most IOS versions, a policy-map that is currently attached to an interface cannot be directly modified — IOS rejects changes to active policy-maps. The correct procedure is: (1) remove the service-policy from the interface (no service-policy output WAN-EGRESS), (2) create the new class-map for streaming video (class-map match-all STREAMING-VIDEO with match dscp af41), (3) edit the policy-map to add the new class (policy-map WAN-EGRESS → class STREAMING-VIDEO → bandwidth 200), (4) verify the updated policy validates (total bandwidth still within 75% of interface bandwidth), and (5) re-apply the service-policy (service-policy output WAN-EGRESS). The risk of an incorrect procedure is a traffic window without any QoS policy (all traffic treated as best-effort) between step 1 and step 5. On IOS-XE 16.x and later, some in-service policy changes are permitted for specific modification types (adding a class, changing bandwidth values), but removing a class or changing the policy structure still requires the remove-and-reapply procedure. Always verify with show policy-map interface gi0/1 after re-application

Correct answer is D. The inability to modify an active policy-map in-service is a well-known IOS MQC limitation that surprises engineers used to modifying running configurations freely. The technical reason: the policy-map is compiled into hardware forwarding tables when applied to an interface. A mid-configuration change could result in a partially-compiled policy in an inconsistent state. The remove-and-reapply procedure ensures the compiled policy is always atomic and consistent. The operational risk is real: during the window between removing and reapplying the service-policy, the interface operates without any QoS policy. Voice traffic will not get priority queuing; scavenger traffic will not be policed; bandwidth guarantees will not be enforced. For a few seconds in a maintenance window this is acceptable; for a busy production WAN link it should be planned carefully. The recommended practice: prepare the updated policy-map offline (or in a lab), have the remove and reapply commands ready to paste rapidly, and perform the change during a low-traffic maintenance window. On more modern IOS-XE versions (16.6+), additive changes (adding a new class, changing a bandwidth value) can often be made without removing the service-policy first — always test in a lab with the specific IOS-XE version before relying on in-service modification in production.

Back to Home