CCNP 350-401 ENCOR QoS Policy: Cisco MQC Configuration, Verification, and Exam Strategy

1. Why QoS Policy Matters for ENCOR and Real Networks

QoS only wakes up when things get crowded. If a link’s got plenty of breathing room and nothing’s backing packets up into a queue, those packets usually just fly out as fast as the interface can push them. But once bandwidth gets tight, the network has to make some uncomfortable calls: who gets served first, who gets a protected slice, and who gets pushed to the side. That’s the whole game.

For CCNP 350-401 ENCOR, the exam isn’t really testing whether you can parrot a few DSCP numbers. It wants to know if you understand what happens to packets in motion: how traffic gets identified, how markings get stamped or rewritten, how queues are handled, why shaping and policing are not twins, and how to tell whether a policy is actually doing work. QoS doesn’t conjure bandwidth out of thin air. It just decides how to live with the shortage.

2. DiffServ Fundamentals, DSCP, and CoS

In Cisco enterprise networks, DiffServ is the QoS model you keep running into. IntServ and RSVP try to reserve resources per flow—very tidy, very exact, and not exactly built for sprawling campus, branch, and WAN networks. DiffServ scales by grouping traffic into classes and assigning each class a Per-Hop Behavior, or PHB.

At Layer 3, the big marker is DSCP, a 6-bit value in the IP header’s DS field. At Layer 2 on 802.1Q trunks, the one that matters is CoS, also called 802.1p PCP, a 3-bit field tucked into the VLAN tag. It’s easy to mix those two up. Don’t. DSCP lives at the IP layer and usually makes it through routed hops; CoS only exists on tagged Ethernet frames, so it drops away at routed boundaries unless something maps it across.

Common PHBs and design conventions:

• EF is the standardized Expedited Forwarding PHB, commonly used for voice bearer traffic.
• AFxy values are Assured Forwarding classes, where x is the forwarding class and y is the drop precedence. For example, AF41, AF42, and AF43 are the same AF4 class with increasing drop preference.
• CSx values are class selectors, often used by enterprise designs for control, signaling, or scavenger traffic.
• BE or DSCP 0 is best effort.

Some mappings are just Cisco-flavored conventions, not laws etched into the universe. Voice signaling is often CS3, interactive video often lands on AF41, scavenger traffic often gets CS1. Useful. Not sacred.

DSCP and Common Enterprise Use

Marking is a label. Queuing is a behavior. A packet marked EF only gets special treatment if the downstream boxes actually trust that label and do something with it.

3. MQC Deep Dive: How Cisco QoS Policies Are Built

Cisco Modular QoS CLI, or MQC, tends to follow the same little ritual every time:

1. Create a class-map to identify traffic
2. Create a policy-map to define actions
3. Apply the policy with service-policy
4. Verify counters and queue behavior

Two matching rules matter for ENCOR:

• Within a class-map, logic depends on match-all versus match-any.
• Within a policy-map, classes are evaluated top-down; first matching class wins, and unmatched traffic falls into class-default.

So yes, “first match wins” is true—but only at the policy-map level. Inside the class-map, the real trick is how the match statements combine. Tiny distinction. Very exam-worthy.

Direction matters too. Ingress policies are where classification, marking, and policing usually happen. Egress is where queueing, scheduling, shaping, and the rest of the congestion drama tend to live. And of course, platform reality intrudes: Catalyst, ISR, and ASR boxes don’t all support the same behaviors in the same direction.

4. Classification, Trust Boundaries, and Campus-to-WAN Marking

Classification can lean on ACLs, DSCP, CoS, interface trust, or NBAR/NBAR2 application recognition. In production, the least fragile approach is usually to classify near the source and then trust—or normalize—markings as traffic moves along.

A trust boundary is not optional fluff; it’s the line between order and chaos. On a Cisco campus access port with an IP phone and a daisy-chained PC, a common pattern is to trust the phone and ignore the PC. In plain English: the switch believes the phone, not the workstation hanging off it. That usually means accepting the phone’s CoS/DSCP markings while rewriting or discarding whatever the PC tries to claim. This depends on things like Cisco phone detection, CDP or LLDP-MED, and commands such as mls qos trust cos, mls qos trust dscp, or mls qos trust device cisco-phone on supported Catalyst platforms.

Voice VLANs definitely help—they separate phone traffic and make phone-related trust behavior possible—but a voice VLAN by itself doesn’t magically turn QoS on. The packets still need markings and queue placement downstream. Otherwise it’s just a VLAN with ambitions.

NBAR matching such as match protocol rtp audio can be handy, though platform support and encryption can make it flaky. For tunnels and overlays, the classification may need to happen before encapsulation buries the headers. On GRE/IPsec-style designs, qos pre-classify is the classic move to keep the inner headers visible long enough to matter.

5. Queueing, LLQ, CBWFQ, and Bandwidth Math

Classic FIFO and software WFQ still matter conceptually, but on modern Cisco gear, QoS often lives in hardware queues or platform-specific schedulers. For ENCOR, the big names are CBWFQ and LLQ.

CBWFQ gives classes a minimum bandwidth guarantee during congestion. That guarantee is not some mystical end-to-end reservation, and if nobody is fighting for bandwidth, it barely gets a chance to show off. Commands like bandwidth, bandwidth percent, and bandwidth remaining percent are related, but not interchangeable:

• bandwidth = explicit kbps guarantee
• bandwidth percent = percentage of interface or parent bandwidth
• bandwidth remaining percent = percentage of bandwidth left after priority and fixed allocations are accounted for

LLQ adds a strict-priority queue for delay-sensitive traffic like voice bearer. In Cisco MQC, the priority or priority percent command creates that queue and also caps how much priority bandwidth it can consume during congestion. Think of it as a bounded fast lane. Go past the allowance and, usually, the excess gets policed and dropped. Useful. Dangerous if oversized. Absolutely worth sizing carefully.

Signaling traffic usually doesn’t belong in LLQ. It wants dependable treatment, not the full VIP velvet rope.

And one subtle thing people forget: queueing can happen even when the physical interface itself looks underfed. A parent shaper can intentionally create a software queue below line rate. That’s basically the point of hierarchical QoS on many WAN edges. Slightly sneaky, very effective.

6. Policing, Shaping, WRED, and Token Bucket Behavior

Policing enforces a rate immediately. Conforming packets go through; excess packets get dropped or remarked based on the configured action. Shaping does something gentler—it buffers excess traffic and sends it later at the configured rate, trading loss for delay. Not the same beast at all.

Both lean on token bucket ideas. The common terms are:

• CIR: committed information rate
• Bc: committed burst size
• Be: excess burst size
• Tc: measurement interval, roughly Bc/CIR

Policers can be single-rate or two-rate, two-color or three-color. In the simple version, traffic is either conform or exceed. In the fancier version, you may also see violate. But don’t go waving around violate counters unless the platform and policer model actually support them. Otherwise it’s just theoretical confetti.

WRED is a congestion-avoidance trick that starts dropping packets probabilistically before the queue is full. Its main job is to keep TCP from sliding into ugly tail-drop behavior and global synchronization problems. Usually it belongs, if anywhere, on TCP-friendly traffic—not voice bearer, not LLQ. Some enterprise designs ignore it completely; others use it sparingly. Platform support is all over the map.

7. HQoS, Tunnels, and Provider Handoffs

Hierarchical QoS is basically parent-and-child policy design. The parent shapes traffic to a provider handoff or tunnel rate. The child decides how traffic gets sorted inside that shaped envelope. Very common on MPLS, Internet VPN, DMVPN, and other branch WAN setups.

Why shape at the edge? Because providers may police or shape at the contracted rate themselves, and if your router sprays bursts above that limit, the drops happen somewhere you can’t see and can’t really argue with. Shape to the contract first. Then layer LLQ and CBWFQ inside it.

With tunnels and encryption, QoS design has to think about inner versus outer headers, whether DSCP is copied or rewritten, and whether the underlay respects the outer marking at all. That’s why pre-classification and platform documentation matter so much. The details are annoyingly specific, and yes, they matter.

8. Corrected Configuration Examples

Note: exact syntax and supported actions vary by IOS XE release and platform.

Example 1: Access-Layer Classification and Marking

class-map match-any VOICE match dscp ef match protocol rtp audio policy-map MARK-EDGE class VOICE set dscp ef class class-default set dscp default interface GigabitEthernet1/0/10 service-policy input MARK-EDGE

This example uses the right MQC syntax: match dscp ef. The NBAR match depends on platform support. The intent is straightforward: catch voice on ingress and normalize the marking so downstream devices can trust it without squinting.

Example 2: WAN HQoS with LLQ and CBWFQ

interface GigabitEthernet0/0/1

That’s the classic branch play: shape the parent to the provider rate, give voice the fast lane, reserve bandwidth for important classes, and keep scavenger traffic on a short leash. The fair-queue behavior under class-default is platform-dependent, especially on hardware-switched platforms.

9. Verification and Troubleshooting Workflow

The quickest way to untangle QoS is to work it in order:

1. Confirm the class matches. Use show policy-map interface and check packet counters.
2. Confirm the marking. Validate DSCP or CoS with packet capture, SPAN, or platform counters.
3. Confirm congestion or shaping exists. No congestion often means little visible queue activity.
4. Inspect queue drops and rates. Determine whether loss is from a policer, queue-limit tail drop, or WRED.
5. Validate downstream trust. A marked packet is useless if the next hop ignores or rewrites it.
6. Check platform support. Accepted syntax does not always mean the ASIC or forwarding path behaves the way you expect.

Useful commands vary by platform:

• Routers/ISR/ASR: show policy-map interface, show platform hardware qfp active feature qos interface
• Catalyst switches: router-style commands may be limited; hardware queue inspection is often platform-specific, including command variants that display active switch QoS state and queue statistics
• Legacy Catalyst environments: show mls qos commands may appear, but they are not universal on modern platforms

Common failure patterns:

• Policy matches nothing: wrong ACL, wrong DSCP, unsupported NBAR signature, wrong interface, or wrong direction
• Marked traffic not prioritized: no congestion, no downstream trust, or no DSCP-to-queue mapping in hardware
• Voice still drops: LLQ undersized, too many calls, provider rate lower than expected, or persistent link underprovisioning
• Carrier drops despite local policy: parent shaper too high, DSCP not preserved across the handoff, or provider QoS policy differs from enterprise assumptions

10. Platform Caveats, Security, and Design Rules

Catalyst switches, ISR routers, and ASR routers do not implement QoS identically. Routers often expose queueing behavior more clearly through MQC and QFP counters. Switches may map MQC abstractions into fixed ASIC queues, thresholds, and buffer pools. So a policy can be perfectly sensible in theory and still get handled a little differently by the hardware underneath.

Security matters too. Untrusted endpoints can spoof DSCP values to try to steal priority treatment. That’s exactly why trust boundaries exist. Guest, BYOD, and unmanaged segments should usually be remarked to default or explicitly policed. And keep control-plane protection separate in your head: data-plane QoS and CoPP are related, but they’re not the same beast.

Here are the practical design rules I’ve found tend to hold up:

• Trust close to the source only when the source is known and controlled.
• Use LLQ for voice bearer, not for every “important” application.
• Do not over-allocate class percentages; the math must fit inside the parent or interface bandwidth.
• Shape to provider rates on constrained WAN handoffs.
• Standardize DSCP values across campus, WAN, wireless, and cloud edge boundaries.
• Remember that QoS manages pain; it does not erase chronic oversubscription.

11. ENCOR Exam Traps and Rapid Review

These are the traps I’d keep an eye out for on ENCOR:

• No congestion, no meaningful queue decision. A policy may be active yet appear quiet.
• Marking is not scheduling. DSCP labels traffic; queueing determines treatment.
• Ingress versus egress matters. Queueing and shaping are usually egress behaviors.
• LLQ is bounded. priority creates strict priority with a configured bandwidth allowance during congestion.
• Policing is not shaping. Policing drops or remarks now; shaping buffers and sends later.
• Class-default is often the hidden answer. Unmatched traffic always goes somewhere.
• CoS and DSCP are different domains. CoS is Layer 2 on tagged Ethernet; DSCP is Layer 3.

Mini scenarios worth practicing:

• A packet enters an untrusted access port marked EF by a PC. Should the switch trust it? Usually no.
• A WAN policy marks voice EF on input, but voice still sounds bad. Why? Maybe the output queue policy is missing, or there is no downstream trust.
• A branch shapes to 50 Mbps and still shows queueing when the physical interface is 1 Gbps. Why? The parent shaper is creating the queue by design.

ENCOR memorization grid: EF = common voice bearer, CS3 = common signaling convention, AF41 = common interactive video convention, CS1 = common scavenger convention, ingress = classify/mark/police, egress = queue/shape/schedule.

12. Final Takeaways

If you only keep a few things in your head, make it these:

• DiffServ is the scalable enterprise model.
• MQC is class-map, policy-map, service-policy, verify.
• match dscp is the standard MQC syntax, not match ip dscp.
• Within a class-map, match-all and match-any define logic; within a policy-map, first matching class wins.
• LLQ is strict priority with a bounded allowance during congestion.
• CBWFQ guarantees bandwidth only when contention exists.
• Policing enforces; shaping paces.
• Trust boundaries and platform behavior determine whether markings actually matter.

For exam prep and actual operations, build a lab, force some congestion, and watch the counters change. That’s where QoS stops sounding abstract and starts looking like packet behavior you can explain without bluffing.