QoS Best Practices: DSCP Marking, Queuing, and Policing

Overview

QoS without a plan creates more problems than it solves. Misconfigured queues starve critical traffic, incorrect DSCP markings defeat the entire policy, and policing at the wrong point drops legitimate bursts. Done correctly, QoS ensures voice calls are clear, critical applications get consistent throughput, and a large file transfer cannot overwhelm a WAN link. This guide covers the RFC 4594 marking standard, Cisco MQC configuration, queuing design, and end-to-end validation.

1.2 — Mark at the Trust Boundary

Mark DSCP as close to the source as possible, and re-mark (police) at the network edge. Never trust markings from untrusted endpoints.

• Phones and UC endpoints — mark their own traffic (EF for RTP, CS3 for signaling). Trust these markings at the access switch.
• PCs and servers — do not trust. Re-classify at the access switch or distribution layer based on ACL or NBAR.
• WAN provider hand-off — re-mark to provider's DSCP scheme at the CE router. Many providers only honour CS and EF.

Part 2 — MQC Configuration

Cisco Modular QoS CLI (MQC) uses three objects: class-map (match traffic), policy-map (define actions), service-policy (apply to interface).

Step 1 — Class Maps

# Match by DSCP — most reliable method at distribution/WAN layer
R1(config)# class-map match-any VOICE
R1(config-cmap)#  match dscp ef
R1(config)# class-map match-any VOICE-SIGNALING
R1(config-cmap)#  match dscp cs3
R1(config)# class-map match-any VIDEO-CONF
R1(config-cmap)#  match dscp af41
R1(config)# class-map match-any CRITICAL-DATA
R1(config-cmap)#  match dscp af21 af22 af23
R1(config)# class-map match-any BULK
R1(config-cmap)#  match dscp af11 af12 af13
R1(config)# class-map match-any SCAVENGER
R1(config-cmap)#  match dscp cs1

# Match by NBAR (application recognition) at ingress/trust boundary
R1(config)# class-map match-any WEBEX-MATCH
R1(config-cmap)#  match protocol attribute business-relevance business-relevant
R1(config-cmap)#  match protocol webex-media

Step 2 — Policy Map with LLQ and CBWFQ

R1(config)# policy-map WAN-EGRESS-QOS
# LLQ — strict priority for voice. Never exceed 33% of link for LLQ total
R1(config-pmap)#  class VOICE
R1(config-pmap-c)#   priority percent 10
R1(config-pmap-c)#   police rate percent 10
R1(config-pmap)#  class VOICE-SIGNALING
R1(config-pmap-c)#   priority percent 5

# CBWFQ — guaranteed minimum bandwidth per class
R1(config-pmap)#  class VIDEO-CONF
R1(config-pmap-c)#   bandwidth percent 30
R1(config-pmap-c)#   fair-queue
R1(config-pmap)#  class CRITICAL-DATA
R1(config-pmap-c)#   bandwidth percent 25
R1(config-pmap)#  class BULK
R1(config-pmap-c)#   bandwidth percent 10
R1(config-pmap-c)#   fair-queue
R1(config-pmap)#  class SCAVENGER
R1(config-pmap-c)#   bandwidth percent 1
# class-default gets all remaining bandwidth
R1(config-pmap)#  class class-default
R1(config-pmap-c)#   fair-queue
R1(config-pmap-c)#   random-detect dscp-based

Step 3 — Apply to Interface

# Apply egress QoS on WAN-facing interface
R1(config)# interface Serial0/0/0
R1(config-if)#  service-policy output WAN-EGRESS-QOS

# For shaping (smooth traffic before queuing) — wrap QoS inside a shaper
R1(config)# policy-map WAN-SHAPER
R1(config-pmap)#  class class-default
R1(config-pmap-c)#   shape average 10000000
R1(config-pmap-c)#   service-policy WAN-EGRESS-QOS
R1(config)# interface GigabitEthernet0/0
R1(config-if)#  service-policy output WAN-SHAPER

Part 3 — Policing vs Shaping

| | Policing | Shaping | |---|---|---| | Mechanism | Drops or re-marks excess traffic | Buffers and delays excess traffic | | Use case | Ingress rate enforcement, provider hand-off | Egress smoothing before WAN | | Impact on latency | None (drops, no delay) | Adds delay (buffering) | | Best for | Enforcing customer SLAs, ingress on untrusted links | Matching CE speed to provider CIR |

Always shape before queuing on WAN interfaces — shaping ensures the queuing policy operates at the correct rate. Without shaping, the interface sends at line rate and the provider drops excess, defeating your queuing policy.

Part 4 — Verification and Troubleshooting

# Check queue statistics — most important QoS command
R1# show policy-map interface Serial0/0/0
# Look for: drops in priority queue = voice is being over-provisioned
#           drops in class-default = congestion on default queue
#           queue depth > 0 consistently = link is congested

# Verify DSCP markings on actual traffic
R1# show policy-map interface GigabitEthernet0/0 input

# Check NBAR protocol discovery
R1# show ip nbar protocol-discovery interface GigabitEthernet0/0 stats packet-count top-n 10

# Verify class-map is matching expected traffic
R1# show class-map VOICE

# Check shaper status
R1# show traffic-shape statistics
R1# show traffic-shape queue

QoS Hardening Checklist

• DSCP marking follows RFC 4594 — EF for voice, AF41 for video, AF2x for critical data
• Marking occurs at the trust boundary — access switches remark PC traffic, trust phone markings
• LLQ voice queue does not exceed 33% of total link bandwidth
• Shaping is configured on WAN interfaces before the queuing policy
• Scavenger class (CS1) exists and is capped at 1% — prevents P2P from consuming WAN
• WRED (random-detect) is enabled on best-effort and bulk queues to reduce TCP global synchronization
• QoS policy is verified with show policy-map interface during peak hours
• No QoS is applied on internal LAN interfaces faster than 1Gbps — line rate is sufficient