Hands-On Lab: Configuring Basic QoS with Class-Based Marking and Queuing

This hands-on lab configures a class-map and policy-map to classify voice traffic, marks it with DSCP EF, applies a priority queue guaranteeing bandwidth for it, and verifies both the marking and queuing behavior take effect on the outbound interface.

QoS Class-Map Policy-MapDSCP MarkingPriority Queuing Configuration

~3 min read · Updated Sep 23, 2026

Lab Objective

Configure a class-map matching voice traffic by protocol, mark it with DSCP EF using a policy-map, apply a second policy-map implementing a strict priority queue for that traffic, and verify both the marking and the queuing statistics.

Lab Purpose

Understanding the Modular QoS CLI (MQC) pattern — class-map defines what to match, policy-map defines what to do, service-policy applies it to an interface — is foundational to virtually every QoS configuration, discussed earlier in this series regarding QoS fundamentals.

Lab Topology

R1 ---- Gi0/1 ---- WAN link toward remote site

Voice traffic identified by RTP protocol range,
generated by an IP phone on the LAN side

Task 1: Create a Class-Map Matching Voice Traffic

Create a class-map matching RTP protocol traffic.

Task 2: Create a Marking Policy-Map

Create a policy-map that sets DSCP EF for traffic matching the voice class-map.

Task 3: Apply the Marking Policy Inbound

Apply the marking policy-map to the LAN-facing interface, inbound.

Task 4: Create a Queuing Policy-Map with Priority

Create a second policy-map applying strict priority queuing to the voice class, with a bandwidth guarantee, and default handling for all other traffic.

Task 5: Apply the Queuing Policy Outbound

Apply the queuing policy-map to the WAN-facing interface, outbound.

Task 6: Generate Traffic and Verify Marking and Queuing

Generate voice traffic and confirm both DSCP marking and priority queue statistics.

Solution and Verification

R1(config)# class-map match-all VOICE-TRAFFIC
R1(config-cmap)# match protocol rtp

R1(config)# policy-map MARK-VOICE
R1(config-pmap)# class VOICE-TRAFFIC
R1(config-pmap-c)# set dscp ef

R1(config)# interface gigabitethernet0/0
R1(config-if)# service-policy input MARK-VOICE

R1(config)# policy-map QUEUE-POLICY
R1(config-pmap)# class VOICE-TRAFFIC
R1(config-pmap-c)# priority 128
R1(config-pmap)# class class-default
R1(config-pmap-c)# fair-queue

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output QUEUE-POLICY

IPPhone> [generates an active RTP call]

R1# show policy-map interface gigabitethernet0/0

  Service-policy input: MARK-VOICE
    Class-map: VOICE-TRAFFIC (match-all)
      842 packets, 67360 bytes
      QoS Set
        dscp ef
          Packets marked 842

R1# show policy-map interface gigabitethernet0/1

  Service-policy output: QUEUE-POLICY
    Class-map: VOICE-TRAFFIC (match-all)
      Queueing
      Strict Priority
      Bandwidth 128 (kbps) Burst 3200 (Bytes)
      (pkts matched/bytes matched) 842/67360
      (total drops) 0
-- Zero drops confirms the voice traffic is
-- being serviced immediately by the strict
-- priority queue, exactly as designed

Key Takeaway

The MQC three-step pattern (class-map, policy-map, service-policy) separates classification from action from application — this separation is what allows the same class-map (VOICE-TRAFFIC) to be reused across two entirely different policy-maps in this lab, one for marking and one for queuing, without redefining the matching criteria twice.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring HSRP for IPv6

This hands-on lab configures HSRP for IPv6 between two routers, demonstrating the option to use an automatically generated link-local virtual address rather than manually assigning one, and verifies failover behavior mirrors the IPv4 HSRP lab covered earlier in this series.

Continue

Hands-On Lab: Configuring SVI Autostate Exclude

This hands-on lab configures SVI autostate exclude on a monitoring port within a VLAN, preventing that single inactive port from incorrectly bringing down the SVI for an entire VLAN that still has other active member ports.

Continue

Hands-On Lab: Configuring Private VLANs (PVLANs)

This hands-on lab configures a full Private VLAN structure with a primary VLAN and both isolated and community secondary VLANs, demonstrating fine-grained Layer 2 isolation within a single IP subnet beyond what the simple protected-port feature from an earlier lab can achieve.

Continue

Hands-On Lab: Configuring VLAN Access Control Lists (VACLs)

This hands-on lab configures a VLAN Access Control List using a VLAN access-map to filter traffic within a single VLAN at Layer 2, something a standard router-applied ACL cannot achieve since traffic never leaves the VLAN to reach a routed interface.

Continue

Hands-On Lab: Configuring Storm Control

This hands-on lab configures storm control thresholds on a switch port to limit broadcast and multicast traffic, simulating a broadcast storm and verifying the switch suppresses excess traffic before it can overwhelm the network.

Continue

Hands-On Lab: Configuring PVLAN Edge (Protected Ports)

This hands-on lab configures PVLAN Edge (protected ports) on two access ports within the same VLAN, isolating them from each other at Layer 2 while both retain normal connectivity to an uplink port, demonstrating a lightweight isolation feature that requires no separate VLAN.

Continue