To fix QoS misconfiguration, verify that traffic is classified with the correct DSCP or CoS markings, confirm the policy-map is applied inbound or outbound on the right interface, match queue bandwidth to real link speed, and trust markings end-to-end across every switch and WAN hop.
Symptoms
- VoIP calls suffer jitter, one-way audio, or choppy speech during peak hours.
- Video conferencing freezes while large file transfers saturate the uplink.
- Ping to gateway shows latency spikes above 100 ms under load.
- show policy-map interface reports drops in the priority or class-default queue.
- Business apps time out even though the speed test shows plenty of bandwidth.
Common Causes
Wrong classification or missing markings
ACLs or NBAR rules miss the actual traffic, so packets fall into class-default. Endpoints may also strip DSCP values before they reach the WAN edge.
Policy applied to the wrong interface or direction
QoS shapes traffic leaving a link. Applying the policy inbound, or on the LAN side of a slow WAN, produces no shaping effect on the real bottleneck.
Queue bandwidth exceeds real link capacity
Shapers configured for the physical port speed instead of the ISP's committed rate cause buffer bloat at the provider, defeating prioritization entirely.
Trust boundary broken between devices
A switch or firewall in the path rewrites or clears DSCP because it does not trust the upstream marking, collapsing all classes into best-effort.
Overlapping or conflicting policies
Legacy class-maps, auto-QoS, and manual policies compete on the same interface. Match order and priority reservations then produce unexpected drops.
Step-by-Step Fix
- Measure the problem before touching config
Run continuous ping and traceroute to a reliable target during a live call. Capture latency, jitter, and loss. Note the exact times issues occur and correlate them with interface utilization graphs. Without a baseline you cannot prove a QoS change helped. - Confirm where the real bottleneck sits
QoS only helps at the congested link, almost always the WAN uplink. Check interface counters for output drops and utilization near saturation. If drops occur on a gigabit LAN port, the fix is capacity or duplex, not queueing. - Inspect current classification and markings
On Cisco, run show policy-map interface and show mls qos interface statistics to see class hits and DSCP counters. Use Wireshark on a mirrored port to confirm VoIP packets actually carry EF (DSCP 46) and video carries AF41. If markings are missing, fix them at the source or remark at the trust boundary. - Rebuild classification with explicit match rules
Create class-maps that match by DSCP where possible, and fall back to ACL or NBAR for unmarked traffic. Keep classes small and named by intent: VOICE, INTERACTIVE_VIDEO, SIGNALING, BUSINESS, SCAVENGER, default. Avoid match-any where a specific match will do. - Shape to the real ISP rate, then queue inside
On the WAN edge, apply a parent policy that shapes to roughly 95 percent of the committed upload rate. Nest a child policy with priority for voice, bandwidth guarantees for video and business, and a scavenger class for bulk. Shaping below line rate is what actually moves congestion onto your router where queueing works. - Apply the policy in the correct direction
Attach the shaping policy outbound on the WAN interface. For campus switches, mark and trust ingress on access ports where phones and endpoints connect, then trust throughout the core. Recheck show policy-map interface for non-zero class hits. - Verify end-to-end trust and remarking
Trace a test call hop by hop. Any device that clears DSCP breaks the plan. On access switches use mls qos trust dscp on trusted uplinks and configure device trust for IP phones. Remark at the trust boundary rather than everywhere. - Retest under load and iterate
Generate synthetic load with iperf while running a real call. Compare jitter, loss, and MOS against your baseline. Adjust priority reservations if the voice queue is starving other classes or if class-default is still dropping business traffic.
Common QoS symptoms mapped to likely cause and first fix
| Symptom | Likely cause | First action |
|---|---|---|
| Jitter on VoIP during uploads | No shaping on WAN uplink | Add parent shaper below ISP rate |
| Voice packets in class-default | Classification misses SIP or RTP | Match by DSCP EF and correct ACL |
| Policy shows zero class hits | Applied on wrong interface or direction | Move policy outbound on WAN |
| High drops in priority queue | Priority reservation too small | Increase priority bandwidth or police source |
| DSCP cleared mid-path | Trust boundary broken | Enable trust dscp on uplinks |
| Video fine on LAN, poor over WAN | LAN not the bottleneck | Focus policy on WAN egress |
Prevention
- Document DSCP values per application and share the map with server and voice teams.
- Review QoS counters monthly; rising drops in class-default signal shifting traffic mix.
- Update policies whenever ISP bandwidth changes so the shaper always matches reality.
- Test QoS after every firmware upgrade; auto-QoS defaults can silently return.
FAQ
Does QoS help if my internet connection is fast enough?
QoS only matters when a link is congested. On an uncontended fiber uplink, packets rarely queue, so priorities have little effect. The moment a backup, cloud sync, or large upload fills the pipe, QoS decides which traffic waits. Configure it even on fast links so peaks do not disrupt voice and video.
Should I trust DSCP markings from user devices?
Generally no. Untrusted endpoints can mark their own traffic as high priority and starve real business apps. Set a trust boundary at the access switch: trust markings from managed IP phones and conferencing appliances, and remark or clear DSCP from everything else before it reaches the core.
Why does my policy-map show class hits but users still complain?
Hits prove classification works, not that queueing is effective. Check for output drops on the egress interface and confirm you are shaping below the ISP's actual delivered rate. If the provider queues packets upstream, your router never sees the congestion and cannot prioritize. Adjust the shaper and retest.
Contact our network team to review your QoS design and traffic policies.