QoS Essentials

QoS Essentials — consolidated study day

This day merges former Days 46, 47 into one CCNA v2.0-aligned segment.

Read straight through; use the practice hub (subnetting / CLI) to drill the verbs Troubleshoot, Diagnose, Configure, and Interpret.

From former Day 46

Source material retained from the previous Day 46 chapter for continuity.

Why QoS

QoS manages contention when interfaces lack enough bits for every flow at once. Voice and interactive video need low delay, jitter, and loss; bulk backups can wait. Without QoS, FIFO drops treat a CEO’s call like a background sync and users hear choppy audio at lunch rush. Place tools where queues form—WAN edges and oversubscribed uplinks—not only on quiet cores.

Congestion is normal at speed mismatches (1 Gbps LAN to 50 Mbps WAN). Queuing and drops happen at the bottleneck—place QoS where queues form, not only on quiet core links that never fill their transmit rings.

QoS cannot invent bandwidth. It allocates what you have according to policy. Chronic overload needs capacity upgrades plus QoS, not markings alone that merely decide who loses first. Reachability problems are routing/ACL issues first; QoS does not create a path.

Exam trap: QoS is for contention and delay/jitter/loss control—not a substitute for routing reachability.

Classification

Classification identifies traffic classes—voice, video, call signaling, critical apps, best effort—using ACLs, NBAR-like matching, or existing marks. You must know what something is before you can treat it specially in a policy-map. Classify early at access so campus devices can trust marks instead of re-matching huge ACLs.

Classify as early as possible (access edge) so the rest of the network can trust marks. Re-classifying at every hop is expensive and error-prone, and it invites inconsistent treatment between buildings. `class-map match-any` versus `match-all` changes whether one match or every match is required.

Policy-maps match classes then set actions (mark, queue, shape). `class-map match-any VOICE` with `match dscp ef` is a classic pattern once marks exist; ACL-based `match access-group` is common before phones mark themselves. A class-map with no later policy action never changes forwarding behavior by itself.

Exam trap: classification without a later action does nothing useful. Matching is only step one of MQC.

Marking

Marking writes a value into the packet—DSCP in IP, CoS in 802.1Q tags—so downstream devices can queue without deep re-classification. EF (46) for voice media and AF41-ish for video are common campus themes you should recognize on the exam. EF (46) for voice media and AF-style marks for video are common PHB catalog entries.

Mark as close to the trust boundary as you can after classification. Remark at WAN edges if SP policies require different values than your internal catalog uses for the same PHB. `set dscp` in a policy-map only helps if downstream queues read those marks under congestion.

`set dscp ef` inside a policy-map class is the IOS idea. Verify with captures or `show policy-map interface` counters that the class is hitting before you blame the WAN provider for ignoring marks. Confirm egress DSCP with a capture or policy-map interface counters after marking.

Exam trap: marking does not prioritize by itself. Queuing policies must read those marks under congestion.

Queuing glance

Queuing schedules which packet leaves next when the interface is congested. FIFO is default and unfair under mix of voice and bulk. Priority queuing, CBWFQ, and LLQ give tools to protect classes with different delay budgets. CBWFQ shares bandwidth; LLQ adds a policed priority lane for delay-sensitive classes.

Software queues activate when the hardware transmit ring fills. Idle links do not show queuing benefits—test under load with a bulk transfer competing against your “voice” stream. Idle Gigabit labs need a shaper or slow link before queuing benefits appear in counters.

Each class can receive a bandwidth share or priority treatment. Remaining capacity goes to class-default. Over-admitting priority traffic starves data—police the priority class so LLQ cannot consume the entire circuit. Over-admitting priority traffic starves data—bound the priority class.

Exam trap: configuring queues without congestion proves little. Use a traffic generator or a bulk transfer while testing voice.

Congestion avoidance

Congestion avoidance drops (or marks ECN) early to slow TCP before buffers explode. WRED is the exam example: weighted random early detection biased by IP precedence/DSCP so scavenger traffic drops sooner than business bulk. On IOS, WRED appears under a class with random-detect themes tied to precedence or DSCP-based drop profiles. WRED early-drops TCP-friendly traffic to avoid tail-drop global synchronization.

Tail drop causes global synchronization—many TCP flows slow at once then ramp together. WRED staggers drops so throughput stays smoother for elastic traffic sharing a congested WAN class. Apply avoidance to elastic data classes, never as a default on EF LLQ voice.

Avoidance tools are for TCP-friendly bulk classes, not for voice in a priority queue. Do not WRED your EF LLQ class as a default idea—voice prefers scheduled priority and controlled admission, not random loss.

Exam trap: congestion avoidance is not the same as congestion management (queuing). Avoidance drops early; management schedules who transmits.

Trust boundaries

A trust boundary is where you decide whether to accept incoming marks or remark. End-user PCs are usually untrusted—they can set DSCP EF on torrents unless you police that behavior at the access switch. Untrusted PCs can spoof EF; remark at the access trust boundary by default.

Trust IP phones (or the access switch that marks for them) and remark at the edge. Uplinks between trusted campus devices may trust DSCP end-to-end inside the AS once the access edge has done its job. Trust phones or the switch that marks for them; learn what the SP honors at handoff.

At SP handoff, learn what the provider trusts. Your EF might become best-effort unless you buy a QoS-enabled circuit and map markings correctly into their class bins. Trusting DSCP everywhere lets users steal LLQ from real voice.

Exam trap: “trust everywhere” lets users steal priority. Place the trust boundary deliberately at the access edge.

DSCP vs CoS

CoS is 3 bits in the 802.1Q header—Layer 2 only, lost when the frame becomes an IP packet on a router. DSCP is 6 bits in the IP header—survives routed hops until something remarks it at a policy edge. CoS lives in 802.1Q and disappears when the packet is routed; DSCP rides in IP end-to-end.

Campus switches may map CoS ↔ DSCP at edges. Design end-to-end on DSCP for routed networks; use CoS where pure L2 QoS exists between switches in the same VLAN domain. Map CoS↔DSCP consistently at campus edges or priority evaporates on the first mismatch.

Voice often CoS 5 / DSCP EF in campus examples. Know that mapping tables must be consistent or priority evaporates at the first mismatch—phone marks CoS 5, uplink strips it, WAN never sees EF. Routed paths need DSCP; CoS-only marking is not enough once tags are stripped.

Exam trap: setting only CoS on a routed path is insufficient once the packet leaves the VLAN tag domain.

Voice QoS themes

Voice media wants LLQ (priority queue), small latency/jitter budget, and usually DSCP EF. Call signaling (often AF31/CS3 themes) needs protection but not necessarily the same priority queue as RTP media. Voice media wants EF plus LLQ; signaling often uses a separate protected bandwidth class.

Separate voice from video when requirements differ. Video can tolerate slightly more delay but needs more bandwidth; treat them as distinct classes so a video burst does not steal the voice priority lane. CAC limits concurrent calls so the priority policer does not clip media under dial storms.

CAC (call admission control) prevents too many calls from entering a priority class and drowning it. QoS without admission still fails when everyone dials at once on a thin WAN during an all-hands meeting. EF without LLQ under congestion leaves voice fighting bulk in the same scheduler.

Exam trap: marking voice EF without a priority/LLQ policy under congestion leaves voice in the same fight as bulk.

show policy-map

`show policy-map` displays configured MQC policies. `show policy-map interface <int>` shows hits, drops, and queuing counters per class on that attachment point—the operational truth during a busy-hour test. `show policy-map interface` is the operational proof of hits, drops, and queue behavior.

Zero packets in a class means classification never matched (wrong mark/ACL) or no congestion/traffic. Drops in class-default during a voice test mean bulk filled the link—check whether voice entered LLQ or stayed unmarked. Attach with `service-policy output` on the real bottleneck; wrong direction yields flat counters.

Attach policies with `service-policy output` on the bottleneck interface (often WAN egress). Input vs output direction mistakes are common lab errors that leave counters flat forever. A policy-map that is never attached does nothing regardless of how complete it looks.

Exam trap: a beautiful policy-map not applied to an interface does nothing. Always verify the service-policy attachment.

Design campus QoS

Campus model: classify/mark at access, trust DSCP in the distribution/core, ensure priority queues on uplinks if oversubscription exists, and align with WAN edge policies so marks still mean something leaving the site. Access switches often remark CoS to DSCP; distribution trusts DSCP on trunks so you do not re-ACL every hop.

Keep class models few—voice, signaling, critical data, best effort—so ops can understand them. Too many classes become unmaintainable and invite mis-maps between teams. Keep few classes so operations can verify them; sprawling models rot into ACL museums.

Coordinate with wireless and WAN teams so a phone roaming from Wi-Fi to wired keeps consistent treatment. One building marking EF while another strips marks creates lottery QoS that is impossible to troubleshoot from MOS scores alone.

Exam trap: campus QoS without a WAN story still fails calls that leave the site. Design end-to-end.

Mis-mark risks

Users or rogue apps marking EF steal priority and delay real voice. Scavenger traffic marked as business-critical inverts intent. Always remark at untrusted edges so only phones and trusted servers keep high marks. Spoofed EF and over-marking “everything critical” both destroy meaningful priority.

Inconsistent maps (AF41 treated as scavenger downstream) cause mystery quality issues. Document the PHB catalog for the network and make WAN and campus teams share one table. Document class→DSCP→queue treatment so wireless and WAN teams stay consistent.

Over-marking too much traffic as “critical” means nothing is critical—priority classes must stay small fractions of the link or LLQ policing will drop real voice along with the impostors. Trusting unknown PC DSCP is both a QoS and security failure mode.

Exam trap: trusting DSCP from unknown PCs is a security and QoS failure mode.

Lab classify

Lab: build class-maps matching ACL or DSCP, a policy-map that sets DSCP and assigns bandwidth/priority, and attach `service-policy output` on a constrained link (shape or slow interface) so queues actually form. Example skeleton: class-map match-all VOICE / match dscp ef; policy-map WAN-EDGE with priority percent 20 under VOICE and bandwidth percent 30 under CRITICAL; then shape average 2000000 on the parent if the circuit is subrate.

Generate bulk traffic and a marked “voice” stream (even if simulated with iperf and DSCP tools). Confirm `show policy-map interface` counters and listen/measure delay if tools allow. If voice counters stay zero, fix classification before tuning bandwidth statements—empty LLQ never protects calls. Mis-classify voice into default once so you feel LLQ miss symptoms in counters.

Intentionally mis-mark and watch voice suffer when LLQ matches the wrong class—reinforces classification accuracy before you trust the design in production. Without a shaper on Gigabit, congestion—and proof—may never appear.

Exam trap: labs on Gigabit without a shaper may never congest; add a shaper to see queuing behavior.

Exam traps

Classification ≠ marking ≠ queuing ≠ shaping/policing. DSCP vs CoS layer differences. Trust boundaries at the edge. EF needs LLQ under congestion or the mark is only a label. Separate classify, mark, queue, shape/police; confuse them and stems become traps.

Policies must attach with service-policy. Congestion avoidance ≠ congestion management. QoS cannot create bandwidth when the circuit is simply too small for the offered load. WRED ≠ LLQ; CoS ≠ DSCP; attachment mistakes nullify perfect class-maps.

Voice media vs signaling classes differ. Overloading priority harms data and eventually voice too when the priority policer starts dropping EF. LLQ/CBWFQ help under contention within limits—they do not invent infinite bandwidth.

Exam trap: “QoS guarantees bandwidth always” is false—LLQ/CBWFQ tools work when the scheduler runs under contention within configured limits.

Checklist

Define classes and PHBs. Place trust boundary. Classify/mark at access. Queue/LLQ at bottlenecks. Align WAN mappings. Verify with `show policy-map interface` under load, not on an idle lab link. Include a rollback: remove service-policy, confirm symptoms return under the same bulk load, then re-apply the known-good policy. Trust, mark, queue/LLQ, WAN map, then verify under load with policy-map interface.

Keep priority traffic bounded. Document DSCP catalog. Remark untrusted edges so user PCs cannot self-promote into EF. Store the PHB table next to the WAN circuit ID so the next engineer shapes to the right rate after an upgrade. Bound priority traffic and remark untrusted edges as standing policy.

Test failure: remove policy and compare call quality under the same bulk load so stakeholders hear why the policy exists. A checklist without a congestion test never proves queuing worked.

Exam trap: checklist without a congestion test never proves queuing.

From former Day 47

Source material retained from the previous Day 47 chapter for continuity.

Policing vs shaping

Policing meters traffic and drops (or remarks) packets that exceed a rate—token bucket out of tokens means discard or markdown. Shaping meters too but buffers excess and releases later to smooth bursts to a target rate without immediate loss.

Police when you must enforce a hard contract immediately (SP ingress, untrusted edge). Shape when you own the buffer delay tradeoff—often on WAN egress toward a slower handoff so you avoid opaque tail drops upstream in the provider cloud. SP ingress and hard contracts often police; enterprise WAN egress often shapes then queues.

Shaping adds delay and jitter while queues hold; policing adds loss. Voice prefers careful LLQ plus mild shaping of aggregate bulk rather than harsh police on EF media that turns every burst into choppy audio. Swap the verbs on a definition stem and you miss the question cold.

Exam trap: shaping delays; policing drops. Do not swap those verbs on definitions.

CBWFQ glance

CBWFQ (Class-Based Weighted Fair Queuing) gives classes configurable bandwidth shares during congestion. Each class-map gets a queue; the scheduler allocates according to `bandwidth` statements when the interface is busy. `bandwidth` / `bandwidth percent` under classes give CBWFQ shares when the link is full.

Unused bandwidth can be shared among other classes depending on platform behavior—configured minimums matter most when the link is full. Class-default often uses fair-queue or best-effort leftovers for scavenger and unmarked traffic. Verify with `show policy-map interface` under load; idle interfaces hide scheduler behavior.

Configure via MQC: class-maps → policy-map with `bandwidth` / `bandwidth percent` → `service-policy output` on the interface. Verify allocations with `show policy-map interface` under a bulk load so the shares become visible in counters. CBWFQ alone lacks a strict voice lane—add LLQ `priority` for that.

Exam trap: CBWFQ alone does not provide a strict priority lane for voice—that is LLQ (`priority`) added to the policy.

LLQ for voice

LLQ adds a priority queue to CBWFQ so voice (and similar) is scheduled ahead of other classes up to a policed rate. Command theme: `priority` or `priority percent` under the voice class in the child policy-map. `priority` / `priority percent` schedule voice first up to an implicit policed ceiling.

The priority class is implicitly policed to stop it from starving data forever. Admit only real EF voice; keep call counts within the bandwidth you reserved or the policer drops legitimate RTP when everyone dials in. Put LLQ on congested WAN egress; campus EF marks die without that hop’s priority queue.

Place LLQ on the congested egress (WAN). Marking EF without LLQ on that hop leaves voice in CBWFQ or default queues with everyone else—and busy-hour call quality collapses. Do not stuff video and bulk into priority or you destroy LLQ’s purpose.

Exam trap: stuffing video and bulk into `priority` destroys the point of LLQ. Priority is for small, delay-sensitive classes.

WRED glance

WRED randomly drops packets from TCP classes before the queue is full, with thresholds that can prefer lower-priority DSCP values for earlier drops. Goal: keep queues shallow and TCP smooth instead of oscillating after tail drop. WRED targets TCP data classes to keep queues shallow before tail drop.

Apply WRED to elastic data classes, not to LLQ voice. Voice hates random loss; it prefers priority scheduling and controlled admission so a single dropped codec packet does not create an audible glitch cascade. Voice wants LLQ and admission, not random early loss on EF media.

Tune min/max thresholds carefully; aggressive WRED on a tiny queue mostly looks like unexplained loss. Verify drops with policy-map interface counters and compare before/after a threshold change. Avoidance is not a substitute for priority scheduling on voice.

Exam trap: WRED is congestion avoidance, not a replacement for LLQ on voice.

End-to-end model

An end-to-end QoS model defines classes, DSCP values, trust points, and treatments from access through WAN to the far site. Every hop that can congest must honor the model or the chain breaks at the weakest link—often the unmarked WAN edge. Every congestable hop must honor the class/DSCP/treatment model or the chain breaks.

Example: phone marks EF → access trusts → campus queues → WAN edge LLQ+shape → SP maps EF → far edge LLQ. One unmarked hop turns EF into lottery traffic and MOS scores tank with no single “broken” router. Sketch that path on paper during troubleshooting so you can spot the hop that strips DSCP. Publish a table ops can implement: class, DSCP, queue, shape/police, attachment points.

Write the model in a table: class, DSCP, queue treatment, police/shape notes. Ops teams implement from the table, not from tribal memory after the original designer leaves. QoS on a single router is not end-to-end quality across a multi-hop path.

Exam trap: QoS on only one router in a multi-hop path does not equal end-to-end quality.

WAN QoS

WAN edges are classic bottlenecks: shape to the contracted rate so you queue locally instead of suffering opaque drops in the provider cloud. Apply LLQ/CBWFQ inside the shaper (hierarchical policy themes) so priority still works under the subrate. Parent shape to contract rate; child LLQ/CBWFQ inside the shaped queue on subrate GE handoffs.

Match provider PHBs—some SPs honor only a few classes. Map your EF/AF/BE into their bins explicitly at the handoff and document the mapping in the circuit binder. Map internal EF/AF/BE into provider PHB bins and confirm with egress captures.

VPN overlays may hide inner DSCP unless you copy marks to outer headers. Know that tunnel encapsulation can require remarking or qos pre-classify themes on older designs so the outer header still gets LLQ. A 50 Mbps contract on Gigabit Ethernet still needs a 50 Mbps shaper for local QoS to matter.

Exam trap: a Gigabit Ethernet handoff with a 50 Mbps contract still needs shaping to 50 Mbps for local QoS to matter.

Verification

Verify with `show policy-map interface`, class hit counts, drop counts, and shaping deferred packets. Confirm service-policy direction (output on egress) matches the bottleneck you intend to control. Under load, voice priority transmits should rise without climbing drops while default drops.

Generate congestion deliberately: bulk transfer + synthetic voice class. Voice class should show priority transmits without climbing drops while class-default drops—that contrast is your proof the policy works. DSCP zero leaving the site means classify/mark failed upstream of the WAN policy.

Cross-check markings with a capture before and after the edge. If DSCP is zero leaving the site, classification failed upstream of the WAN policy and LLQ never saw EF. Empty counters mean no match or no traffic—not an “efficient” policy.

Exam trap: empty counters mean no match or no traffic—not proof the policy is “efficient.”

Troubleshooting drops

Drops in LLQ: priority policer exceeded—too many calls or wrong traffic in priority. Drops in CBWFQ class: insufficient bandwidth share or massive burst. Tail drops in class-default: expected under overload—upgrade or reduce scavenger traffic. LLQ drops ⇒ priority policer exceeded; CBWFQ drops ⇒ share too small or burst too big.

Unexpected drops with low utilization: shaping rate set too low, or policer on input too tight. Check hierarchical parents because a child LLQ cannot save you if the parent shape is 2 Mbps on a 100 Mbps need. Low utilization with drops often means parent shaper/policer set too low.

Lossy SP path despite clean local counters: provider not honoring marks, or you failed to shape and got dropped in their cloud. Compare local vs path measurements (TWAMP/IPSLA themes) before rewriting MQC blindly. Check interface CRC/errors before assuming every drop is a QoS bug.

Exam trap: not every drop is a QoS bug—bad cables and CRC errors are physical. Check interface errors first.

Capacity planning

Size WAN links for peak voice concurrent calls × per-call bandwidth plus data headroom. QoS protects quality within the budget; it does not replace an undersized circuit forever when the business doubles headcount. Size for peak concurrent calls × codec bandwidth plus data headroom, not average quiet hours.

Measure utilization percentiles, not only averages. A 40% average link can still spike to congestion every lunch hour and ruin calls while graphs look “fine” on a daily mean. Use percentiles and peaks; averages hide lunch-hour congestion that ruins voice.

Plan class budgets: priority voice ≤ ~33% of link is a common design caution theme so data still moves. Document assumed packet sizes and codec rates so the next engineer can recalculate after a codec change. Chronic 95%+ utilization needs bandwidth first, not “more QoS.”

Exam trap: “add more QoS” is the wrong answer to chronic 95%+ utilization—add bandwidth.

Lab shape

Lab: on a router egress, apply a shaper to a low rate (e.g., 2 Mbps) with a child policy that LLQs a voice class and bandwidth-limits data. Flood data and a marked voice stream through it so the parent queue builds.

Confirm shaping stats (delayed packets) and that voice class drops stay near zero while default drops rise. Remove LLQ and repeat to feel the difference in delay and loss on the “voice” stream. Remove `priority` and repeat to feel unprotected EF under the same bulk load.

Change shape rate upward and watch drops fall—ties QoS labs to capacity intuition and shows why an upgraded circuit plus the same policy still needs a shape-rate update. Wrong interface or wrong direction yields flat shaper counters and confusion.

Exam trap: shaping on the wrong direction (input vs output) or wrong interface yields flat counters and confusion.

Exam compare police/shape

Compare on exams: both meter with token buckets; police drops/remarks excess; shape queues excess; shape adds delay; police enforces hard caps; SP edges often police; enterprise WAN egress often shapes then queues. Keywords: buffer/smooth → shape; drop excess/enforce contract → police; priority voice → LLQ.

Keywords: “smooth traffic” / “buffer” → shape. “Drop excess” / “enforce contract” → police. “Priority voice” → LLQ, not a policer alone that merely rate-limits without scheduling preference. Nested parent shape + child LLQ/CBWFQ is the subrate-circuit architecture answer.

Nested designs: parent shape, child LLQ/CBWFQ is a frequent architecture answer for “match the subrate circuit” while protecting voice inside the shaped pipe. Shaping never “speeds up” traffic—it delays excess to fit the rate.

Exam trap: saying shaping “speeds up” traffic is wrong—it delays excess to fit a rate.

Tools and counters

Tools: `show policy-map interface`, `show interface` for tx load and drops, IP SLA/jitter probes, packet captures for DSCP, and NMS graphs for utilization across the busy hour—not only overnight baselines. Prefer class-aware policy-map counters over aggregate interface drop totals for root cause.

Watch offered rate versus drop rate per class. A class with high offers and high drops needs more share, admission control, or less input; counters tell you which lever to pull. Baseline before changes; retest the same call-plus-bulk script afterward.

Baseline before changes. After a QoS change, compare the same call test and bulk transfer. Subjective “sounds better” plus counters beats vibes alone when you justify the change to management. High offer plus high drop means more share, admission control, or less input—not random toggles.

Exam trap: interface total drops lump everything—use class-aware counters for QoS root cause.

Design review

Review checklist: class model documented, trust boundary set, marks consistent, LLQ for voice, CBWFQ for data, shape to WAN rate, SP mapping known, verification under load done, capacity adequate for peak calls. Review marks, trust, LLQ, CBWFQ, WAN shape rate, SP map, load verification, and capacity together.

Kill unused classes and wild ACL matches that classify “everything critical.” Simpler policies survive staff turnover and make `show policy-map interface` readable during an outage. Delete unused “everything critical” classes that make nothing critical under congestion.

Revisit after codec changes, new UCaaS providers, or circuit upgrades—old shape rates become silent bottlenecks that look like random call quality regressions. Marking without queuing at the bottleneck fails design review despite pretty diagrams.

Exam trap: a design that marks but never queues at the bottleneck fails review even if diagrams look pretty.

Capstone QoS

Capstone story: campus marks voice EF and data AF/BE; WAN edge shapes to circuit rate with LLQ for EF and CBWFQ for data; far site mirrors treatment; monitoring watches class drops and call MOS/jitter across the busy hour. Capstone: campus mark EF/AF/BE; WAN shape + LLQ + CBWFQ; far side mirrors; monitor class drops.

Tie Day 46 concepts (classify/mark/trust) to Day 47 tools (police/shape/LLQ/WRED). Be able to sketch the policy-map hierarchy on a whiteboard cold—parent shape, child priority + bandwidth classes, class-default. If you can draw parent shape with child LLQ and CBWFQ from memory, you are exam-ready for the WAN QoS stems. Sketch parent shape and child priority/bandwidth/`class-default` on a whiteboard cold.

If calls fail: verify marks, LLQ hits, shape rate, SP path, and capacity before rewriting the whole MQC. Systematic checks beat random `priority` toggles that never get verified under load. Answers that only say “enable QoS” without mark + LLQ + shape at the bottleneck are incomplete.

Exam trap: capstone answers that only say “enable QoS” without naming mark + LLQ + shape at the bottleneck are incomplete.