Troubleshoot and resolve a QoS misconfiguration by validating traffic DSCP or CoS marking at the network edge, ensuring those markings are trusted end-to-end and prioritizing that traffic by guaranteeing bandwidth for latency-sensitive traffic, such as VoIP (EF) or video (AF41) on all WAN and uplink ports.
Symptoms
- VoIP calls show jitter above 30 ms, choppy audio, or one-way audio during peak hours.
- Video conferencing drops to audio-only or freezes while large downloads run.
- Interactive apps (RDP, SSH, SaaS) stall while backups or updates are in flight.
- Router queue counters show tail drops on the priority or class-default queue.
- QoS policies applied but 'show policy-map interface' reports zero matched packets.
Common Causes
Markings stripped at a trust boundary
An access switch or WAN edge is set to untrusted, so DSCP values from IP phones or SBCs are rewritten to 0 before the policy ever sees them.
Policy applied on the wrong interface or direction
QoS shaping only helps outbound on the congested link. Applying the policy inbound, or on a LAN interface that never saturates, produces no effect.
Shaper misaligned with real circuit speed
The parent shaper is set to the sold rate instead of ~95% of the measured throughput, so the ISP queues packets before your router can prioritise them.
Overlapping or contradictory class-maps
Two class-maps match the same traffic, or match-any hits a broader ACL first, so voice packets fall into a bulk queue instead of the priority queue.
ISP or underlay ignores DSCP
Public internet and many MPLS underlays remark or ignore DSCP. Without an overlay (SD-WAN, IPsec with pre-classify) prioritisation stops at your WAN edge.
Step-by-Step Fix
- Make sure the link is congested before touching QoS:
QoS won't do a thing until there's contention. Graph the interface utilisation and the queue drops (if you have them) for a minimum of 24 hours using SNMP, NetFlow, or your router's built-in counters. If WAN has never gone above 70% and there are no drops, something else is broken (duplex mismatch, DNS, Wi-Fi). Fix it first. - Map all the traffic classes you have to prioritise:
Export details of the applications, transport, usual ports/signatures, and how they should be treated: EF for VoIP RTP, CS3 for signalling, AF41 for video, AF21 for interactive business applications, default for bulk. Four or five classes are always best. More really is not much better and makes troubleshooting more painful. - Mark and trust traffic at the trusted edge:
Trust as close to the source as possible On access switch, trust CoS/DSCP for IP phones through CDP/LLDP-MED, or, create an ingress policy-map that matches an ACL and sets DSCP. Confirm with the 'show mls qos interface' (or vendor equivalent) command that the trust state is correct. - Build a hierarchical policy on the WAN egress
Create a child policy-map with a priority (LLQ) class for voice, bandwidth-percent classes for video and business traffic, and class-default for the rest. Nest it under a parent shape-average set to about 95% of the true circuit rate. Apply it outbound on the WAN interface, or on the tunnel interface if you use IPsec with qos pre-classify. - Handle the tunnel and ISP reality
On IPsec or GRE, enable qos pre-classify and copy the inner DSCP to the outer header so the shaper sees the original marking. Remember the public internet will not honour your DSCP. If you need end-to-end prioritisation across sites, terminate on an SD-WAN fabric or MPLS class-of-service you control. - Verify with live counters, not assumptions
Generate load and run 'show policy-map interface <wan>' repeatedly. Confirm packets are hitting the correct classes, the priority queue is not exceeding its allocation, and drops are landing in class-default rather than voice. A VoIP test call should now show jitter under 20 ms and zero packet loss. - Document the policy and lock change control
Export the running config, record the DSCP-to-class mapping, and note the shaper rate you calibrated against. QoS is fragile: a firmware upgrade, an ISP speed change, or a new app deployment can silently break it. Schedule a quarterly review.
Common QoS symptoms mapped to likely cause and fix
| Symptom | Likely cause | Fix |
|---|---|---|
| Voice jitter only during backups | No LLQ or LLQ starved | Add priority class for EF, cap at 33% of shaper |
| Policy shows 0 matched packets | Applied on wrong interface or direction | Move policy to WAN egress, verify with show policy-map |
| DSCP arrives as 0 at the WAN router | Access switch not trusting markings | Enable trust dscp / trust device cisco-phone on access ports |
| Drops even when link shows 60% utilisation | Shaper set to line rate, ISP queues instead | Lower shape-average to ~95% of measured throughput |
| Voice fine on LAN, bad across VPN | Outer header not marked, tunnel not pre-classified | Enable qos pre-classify and DSCP copy on the tunnel |
| Two apps compete inside same class | Class-map too broad or overlapping | Split into distinct class-maps, order match rules carefully |
Prevention
- Re-measure WAN throughput after any ISP change and adjust the parent shaper accordingly.
- Standardise DSCP values across sites so a single class-map template works everywhere.
- Alert on queue drops in the priority class, any non-zero value means the LLQ is undersized.
- Test VoIP MOS scores monthly with a synthetic call, not only after user complaints.
FAQ
Will QoS help even if the internet link isn't full?
Not necessarily. QoS only works when an interface queue is filled up. If your WAN is not being used more than around 70% and you are still having voice/video issues, then you will probably need to look elsewhere for the problem: Wi-Fi interference, duplex mismatch, slow DNS lookups, a root DNS problem, or the upstream ISP. Fix that first.
Can you be sure if DSCP markings will be left intact all the way across the public Internet?
Typically not. Few ISPs pass through (honour) DSCP on normal internet transit, so your prioritisation only applies at the WAN edge you own. To allow for class-of-service between sites, you require a service that respects it: MPLS L3VPN with contracted CoS, an SD-WAN overlay, or IPsec tunnels where you are the endpoint owner and re-marking can take place.
How much bandwidth do I need to reserve for the voice priority queue?
In general, keep it to about one-third of the parent shaper and size it for the expected concurrent calls (about 100 kbps per G.711 call including overhead). If you oversize the priority queue, everything else gets starved during load. If you undersize, you get voice drops. Measure actual call volume before going down this route.