QoS – Quality of Service Overview

1. What Is QoS and Why Is It Needed?

Quality of Service (QoS) is a set of techniques that allows network devices to manage traffic in a way that prioritises some flows over others, ensuring that latency-sensitive and business-critical applications receive the network resources they need — even when the network is congested.

By default, every packet on a network is treated equally — a principle called best-effort delivery. This is fine when bandwidth is plentiful, but when a link becomes congested, a large file transfer can just as easily delay a VoIP call or a video conference. QoS solves this by identifying different types of traffic, assigning them priority levels, and using queuing and scheduling techniques to ensure each type gets the treatment it needs.

1.1 The Four QoS Characteristics of Network Traffic

Characteristic	Definition	Affected Applications	Typical Requirement
Bandwidth	The rate at which data can be transmitted over a link (bits per second)	Video streaming, file transfer, backup	Minimum guaranteed bandwidth allocation
Delay (Latency)	The time a packet takes to travel from source to destination	VoIP, video conferencing, online gaming	VoIP: one-way delay <150 ms (ITU G.114)
Jitter	Variation in the delay between consecutive packets of the same flow; packets arrive at uneven intervals	VoIP, real-time video	VoIP: jitter <30 ms; mitigated with playout buffers
Packet Loss	Percentage of packets dropped in transit — typically due to congestion causing queue overflow	VoIP, video streaming, any TCP application	VoIP: <1% packet loss; TCP tolerates loss but retransmits (adding delay)

1.2 Why Congestion Happens

Congestion occurs whenever the input rate exceeds the output rate on an interface — for example, when multiple high-speed LAN interfaces funnel traffic onto a lower-speed WAN link. The router must buffer excess packets in a queue. If the queue fills, packets are dropped. QoS determines which packets are queued, which are dropped, and in what order packets are transmitted.

Congestion Scenario	Example	QoS Solution
Speed mismatch	1 Gbps LAN feeding a 10 Mbps WAN link	Queue and schedule packets on the WAN egress interface
Bursty traffic	Backup job floods the link, starving VoIP calls	Police backup traffic; guarantee bandwidth for VoIP
Mixed traffic types	Video conferencing, email, and bulk file transfer share a link	Classify and queue traffic into priority classes

2. The Three QoS Models

There are three fundamental models for implementing QoS in a network. They represent a spectrum from no QoS at all to per-flow guaranteed service, and differ in complexity, scalability, and the guarantees they can provide.

Model	Full Name	How It Works	Guarantees	Scalability	Typical Use
Best-Effort	Best-Effort (no QoS)	All packets treated equally — first in, first out (FIFO). No classification, no prioritisation.	None — no guarantees of bandwidth, delay, or loss	Maximum — no per-flow state	Simple networks, internet-at-large, non-critical traffic
IntServ	Integrated Services	Applications signal the network in advance using RSVP (Resource Reservation Protocol) to reserve bandwidth along a path for each individual flow before sending traffic.	Hard guarantees per flow — the reserved bandwidth is held for the duration of the flow	Poor — each router must maintain per-flow state; does not scale beyond small networks	Lab environments, legacy multimedia applications, small networks with strict per-flow guarantees
DiffServ	Differentiated Services	Traffic is classified and marked at the network edge (usually with a DSCP value in the IP header). Interior routers forward packets based on the mark — no per-flow state needed at the core.	Relative guarantees — marked traffic receives better service than unmarked, but no absolute bandwidth guarantee per flow	Excellent — core routers only read a single field in the IP header; scales to internet scale	Enterprise networks, service provider networks, internet — the dominant QoS model in use today

2.1 Best-Effort in Detail

Best-effort is the default behaviour of IP networks. Routers use a simple FIFO (First In, First Out) queue — packets are forwarded in the order they arrive. When congestion occurs, tail-drop removes the most recently arrived packets. There is no differentiation between a VoIP packet and a large file-transfer packet — both wait in the same queue and face the same drop probability.

2.2 IntServ in Detail

IntServ (RFC 1633) uses RSVP (RFC 2205) as its signalling protocol. Before sending a flow, the application sends RSVP PATH messages toward the destination; the destination responds with RESV messages back toward the source, reserving resources at each hop. Every router in the path must support RSVP and maintain per-flow reservation state. The two IntServ service classes are:

IntServ Class	Description
Guaranteed Service	Strict bandwidth and delay guarantees — suitable for applications with zero tolerance for delay variation (e.g., hard real-time audio)
Controlled Load	Best-effort service during lightly loaded conditions — approximately equivalent to an unloaded network; suitable for adaptive applications

2.3 DiffServ in Detail

DiffServ (RFC 2474, RFC 2475) is the model used in virtually all modern enterprise and service provider networks. Instead of per-flow signalling, DiffServ uses a 6-bit DSCP (Differentiated Services Code Point) field in the IP header ToS byte to mark packets at the edge. Core routers implement Per-Hop Behaviours (PHBs) — forwarding policies triggered by the DSCP value — without needing to know anything about individual flows.

PHB Name	DSCP Value	Description	Typical Use
Default (BE)	DSCP 0 (000000)	Best-effort — no special treatment	Internet traffic, bulk data
EF (Expedited Forwarding)	DSCP 46 (101110)	Lowest latency, lowest jitter, lowest loss — treated as if the link is never congested for this traffic class	VoIP RTP media streams
AF (Assured Forwarding)	AF11–AF43 (DSCP 10–38)	Four classes (AF1x–AF4x), each with three drop precedences (1=low, 2=medium, 3=high drop probability under congestion)	Video conferencing (AF41), transactional data (AF21), bulk data (AF11)
CS (Class Selector)	CS1–CS7 (DSCP 8, 16, 24, 32, 40, 48, 56)	Backward compatible with IP Precedence (3 most significant bits); CS7 reserved for network control	Network control (CS6/CS7), call signalling (CS3)

3. QoS Marking Fields

Before traffic can be treated differently, it must be marked — a value is written into a field in the packet or frame header that downstream devices use to identify the class of traffic and apply the appropriate forwarding policy.

Marking Field	Location	Bits	Values	Notes
DSCP (Differentiated Services Code Point)	IP header — ToS byte (bits 7–2)	6 bits	0–63 (64 possible values)	Primary QoS mark in DiffServ; carried end-to-end across the network
IP Precedence	IP header — ToS byte (bits 7–5)	3 bits	0–7	Legacy marking; superseded by DSCP; values 6 and 7 reserved for internetwork/network control
CoS (Class of Service / 802.1p)	802.1Q VLAN tag in Ethernet frame header	3 bits (PCP field)	0–7	Layer 2 marking — only present on 802.1Q-tagged frames between switches; stripped at Layer 3 boundaries; must be re-marked to DSCP
MPLS EXP / TC	MPLS label stack entry	3 bits	0–7	Used in MPLS networks for QoS marking — mapped from DSCP at MPLS ingress

See QoS Marking (DSCP & CoS) for the full DSCP value table, AF class/drop precedence breakdown, and CoS-to-DSCP mapping.

4. The QoS Pipeline – Six Steps

QoS is best understood as a pipeline — a sequence of processing steps that each packet may pass through as it traverses a network device. Not every step applies to every packet or every interface, but understanding the full pipeline is essential for designing and troubleshooting QoS.

Step	Function	Question It Answers	Cisco IOS Tool
1. Classify	Identify and categorise each packet by its traffic type (VoIP, video, data, management, scavenger)	"What kind of traffic is this?"	class-map (ACL, DSCP match, NBAR)
2. Mark	Write a QoS value into the packet/frame header so downstream devices can classify without deep inspection	"How should downstream devices treat this packet?"	set dscp, set ip precedence, set cos
3. Queue	Place packets into appropriate output queues based on their class; higher-priority queues are served first	"Which queue does this packet wait in?"	CBWFQ class queues, LLQ priority queue
4. Schedule	Determine the order in which packets from different queues are dequeued and sent onto the outbound link	"When does this packet get transmitted?"	CBWFQ scheduler, LLQ (strict priority)
5. Police	Enforce a traffic rate contract — packets that exceed the contracted rate are immediately dropped or re-marked (no buffering)	"Is this traffic within its allowed rate? Drop or re-mark if not."	police (rate, burst, actions: drop, transmit, set-dscp)
6. Shape	Smooth traffic to stay within a rate limit by buffering excess packets and releasing them at the shaped rate (delays rather than drops)	"Is this traffic within its shaped rate? Buffer excess packets."	shape average, shape peak

5. Step 1 – Classify

Classification is the process of identifying what type of traffic a packet belongs to. Everything else in the QoS pipeline depends on accurate classification — you cannot prioritise VoIP if you cannot reliably identify VoIP packets.

Classification Method	What It Inspects	Accuracy	Performance Impact
DSCP / IP Precedence	Pre-existing mark in the IP header ToS byte	Relies on upstream device having marked correctly — trust-based	Very low — single field read
CoS (802.1p)	3-bit PCP field in 802.1Q VLAN tag	Layer 2 only — stripped at routed boundaries	Very low
ACL-based	Source/destination IP, port number, protocol	Good for well-known port numbers (e.g., UDP 5060 = SIP, TCP 443 = HTTPS)	Low to moderate
NBAR (Network-Based Application Recognition)	Deep packet inspection — application signatures including dynamic ports, payload patterns, and protocol behaviours	High — identifies applications that use dynamic or non-standard ports (e.g., Skype, BitTorrent, YouTube)	Higher CPU — use NBAR2 (Protocol Discovery) on supported platforms

Trust boundaries define where in the network classification marks are accepted as legitimate. Marks applied by end-user devices (PCs, laptops) are generally not trusted — they could self-mark their traffic as high priority. The trust boundary is typically placed at the first network device under IT control: the access switch port or the router interface connected to a verified IP phone.

Device	Trust Level	Typical Policy
IP Phone (Cisco)	Trusted — hardware device under IT control	Trust CoS/DSCP marks from the IP phone
PC connected through IP phone	Untrusted	Re-mark PC traffic to DSCP 0 (best-effort) at the switch port
Access switch (connected to users)	Partially trusted — only for specific device types	Trust CoS from Cisco IP phones; remark everything else
Distribution / core switch	Trusted — only internal traffic present	Trust DSCP marks set by access layer

6. Step 2 – Mark

Marking writes a QoS value into the packet or frame header so that all downstream devices in the path can classify the traffic instantly without performing deep inspection. Marking should be done as close to the traffic source as possible — at the trust boundary — so the mark is carried through the network from that point forward.

The best practice for enterprise networks is to mark traffic with DSCP at the access layer and carry that mark end-to-end through the campus, WAN, and data centre. Layer 2 CoS is used within the switched campus but must be mapped to DSCP at routing boundaries (Layer 3 hops strip the 802.1Q tag and its CoS value).

Traffic Type	Recommended DSCP	DSCP Value	Recommended CoS
VoIP RTP (voice media)	EF (Expedited Forwarding)	46	5
VoIP signalling (SIP, H.323)	CS3	24	3
Video conferencing (interactive)	AF41	34	4
Streaming video	AF31 or CS4	26 or 32	4
Critical data (transactional)	AF21	18	2
Bulk data (email, FTP)	AF11	10	1
Scavenger (P2P, non-business)	CS1	8	1
Network control (routing protocols, SNMP)	CS6	48	7
Best-effort (everything else)	Default / BE	0	0

7. Step 3 & 4 – Queue and Schedule

Queuing is the process of placing packets into different output queues based on their traffic class when an interface is congested. Scheduling determines the order in which packets from different queues are dequeued and transmitted. Together they control which traffic gets bandwidth and which waits.

7.1 Common Queuing Mechanisms

Mechanism	How It Works	Strength	Weakness
FIFO (First In, First Out)	Single queue — packets transmitted in arrival order	Zero overhead; no configuration needed	No prioritisation — bursty traffic starves latency-sensitive applications
WFQ (Weighted Fair Queuing)	Automatically creates per-flow queues; lower-bandwidth flows get proportionally more service	Fair without configuration; protects small flows	Does not support explicit priority or bandwidth guarantees; no control over specific application classes
CBWFQ (Class-Based WFQ)	Administrator defines traffic classes and assigns minimum bandwidth guarantees to each; excess bandwidth shared among all classes proportionally	Explicit, configurable bandwidth guarantees per class; MQC-compatible	Does not provide strict priority — all queues served round-robin with weights; latency-sensitive traffic still queues behind other traffic
LLQ (Low Latency Queuing)	CBWFQ + a strict priority queue. The priority queue is always serviced first (emptied) before any CBWFQ queues are served — guaranteeing minimum delay for the priority class	Provides strict low-latency, low-jitter service for VoIP — the gold standard for voice QoS	Priority queue can starve lower classes if not rate-limited (must police the priority queue)

LLQ is the recommended queuing mechanism for networks carrying VoIP. Voice is placed in the strict priority queue (using the priority command); all other classes use CBWFQ bandwidth guarantees. See QoS Queuing (CBWFQ & LLQ) and the CBWFQ & LLQ Lab for full configuration detail.

7.2 Congestion Avoidance – WRED

WRED (Weighted Random Early Detection) is a congestion-avoidance mechanism that proactively drops packets from lower-priority flows before the queue fills completely. By randomly dropping packets from lower-DSCP-marked flows when queue depth exceeds a threshold, WRED causes TCP flows to throttle their sending rate early — preventing tail-drop that would affect all traffic equally. WRED is applied within a CBWFQ queue to differentiate drop probabilities based on DSCP/IP Precedence.

8. Step 5 – Police

Traffic policing enforces a rate limit on a traffic class by measuring the incoming (or outgoing) rate and taking an action when the traffic exceeds a defined Committed Information Rate (CIR). Policing does not buffer excess packets — it acts immediately.

Policing Parameter	Definition
CIR (Committed Information Rate)	The contracted average rate the traffic class is allowed to use (bits per second)
Bc (Committed Burst)	The maximum number of bits that can be sent in a single burst at line rate before the policer starts dropping. Calculated as: Bc = CIR × Tc (interval, typically 1/8 second)
Be (Excess Burst)	Additional burst allowed in two-rate policing (CIR + PIR models) — packets in excess of CIR but within Be are marked, not dropped
Conform action	What to do with packets within CIR (within rate) — typically transmit
Exceed action	What to do with packets above CIR but within excess burst — typically drop or set-dscp-transmit (re-mark to lower priority)
Violate action	What to do with packets beyond all burst limits — typically drop

Policing is typically applied:

Where Applied	Common Use Case
Inbound (ingress)	ISP policing customer traffic to enforce service contract; enterprise policing inbound traffic from a branch or the internet
Outbound (egress)	Limiting a specific application class (e.g., scavenger traffic) to prevent it consuming too much WAN bandwidth

See QoS Policing & Shaping and the Traffic Policing & Shaping Lab for detailed configuration.

9. Step 6 – Shape

Traffic shaping smooths a traffic flow to conform to a target rate by buffering excess packets and releasing them at a steady rate, rather than dropping them immediately as policing does. Shaping adds delay but avoids packet loss caused by exceeding a rate limit.

Feature	Traffic Policing	Traffic Shaping
Excess packets	Dropped (or re-marked) immediately	Buffered and released at shaped rate
Introduces delay?	No — packets either pass or are dropped instantly	Yes — buffered packets experience additional delay
Introduces jitter?	No	Yes — delay variation from bursty shaped releases
Packet loss?	Yes — non-conforming packets dropped	Minimal — only if shaping buffer itself fills
Typical application	ISP enforcement; inbound rate limiting; scavenger traffic control	Egress shaping to match a slower WAN CIR; preventing ISP policing drops at the WAN edge
Direction	Inbound or outbound	Outbound only (shaping buffers are on output queues)
Cisco command	`police` (in policy-map class)	`shape average` or `shape peak`

Key use case for shaping: Your ISP provides a 100 Mbps physical link but your contracted CIR is only 20 Mbps. Without shaping, your router sends at line rate (100 Mbps) and the ISP's policer drops everything above 20 Mbps — causing packet loss and TCP retransmits. By configuring shaping at 20 Mbps on the WAN egress interface, you buffer excess traffic locally and transmit it smoothly within the contracted rate, avoiding the ISP policer entirely.

10. Cisco MQC – Modular QoS CLI

Cisco IOS implements QoS using the Modular QoS CLI (MQC) — a three-object framework consisting of class-maps, policy-maps, and service-policies. MQC provides a consistent, modular way to configure all QoS functions across all Cisco platforms.

MQC Object	Command	Purpose
class-map	`class-map [match-any \| match-all] <name>`	Defines the classification criteria — which traffic belongs to this class (match DSCP, match ACL, match protocol via NBAR, match CoS)
policy-map	`policy-map <name>`	Defines what to do with each classified traffic class — mark, queue (bandwidth/priority), police, shape, or drop
service-policy	`service-policy {input \| output} <name>`	Applies a policy-map to a specific interface in the inbound or outbound direction — activates the QoS policy

10.1 MQC Configuration Example – VoIP LLQ + Data CBWFQ

! ===== Step 1: Define class-maps (classify) =====
! VoIP class — match EF DSCP (voice media)
Router(config)# class-map match-any VOICE
Router(config-cmap)# match dscp ef
Router(config-cmap)# exit

! Video class — match AF41 DSCP (interactive video)
Router(config)# class-map match-any VIDEO
Router(config-cmap)# match dscp af41
Router(config-cmap)# exit

! Critical data class — match AF21
Router(config)# class-map match-any CRITICAL-DATA
Router(config-cmap)# match dscp af21
Router(config-cmap)# exit

! ===== Step 2: Define policy-map (queue + schedule + mark) =====
Router(config)# policy-map WAN-POLICY
Router(config-pmap)# class VOICE
Router(config-pmap-c)#  priority 1000          ! LLQ strict priority queue — 1 Mbps reserved
Router(config-pmap-c)#  exit
Router(config-pmap)# class VIDEO
Router(config-pmap-c)#  bandwidth percent 30   ! CBWFQ — 30% bandwidth guaranteed
Router(config-pmap-c)#  exit
Router(config-pmap)# class CRITICAL-DATA
Router(config-pmap-c)#  bandwidth percent 20   ! CBWFQ — 20% bandwidth guaranteed
Router(config-pmap-c)#  exit
Router(config-pmap)# class class-default
Router(config-pmap-c)#  fair-queue             ! WFQ for remaining best-effort traffic
Router(config-pmap-c)#  exit
Router(config-pmap)# exit

! ===== Step 3: Apply policy to the WAN egress interface =====
Router(config)# interface Serial0/0/0
Router(config-if)# service-policy output WAN-POLICY
Router(config-if)# exit

For full MQC labs, see MQC QoS Basics Lab, CBWFQ & LLQ Lab, and DSCP Marking & Classification Lab.

11. QoS Verification Commands

Command	Output / Purpose
`show policy-map interface <int>`	The most important QoS verification command — shows per-class packet/byte counters, queue depths, drops, and policer conform/exceed/violate counts for all classes applied to an interface
`show policy-map`	Lists all configured policy-maps and their class actions (bandwidth, priority, police, shape)
`show class-map`	Lists all configured class-maps and their match criteria
`show queueing interface <int>`	Shows queue statistics and current queue depths per class on the interface
`show interface <int>`	Output queue drops counter — a non-zero value indicates congestion is occurring and packets are being dropped
`show ip nbar protocol-discovery`	NBAR protocol statistics — shows which applications are consuming bandwidth, useful for traffic baselining before configuring QoS
`show traffic-shape`	Traffic shaping statistics — current rate, queue depth, and shaping burst parameters per shaped interface/class

12. QoS Quick-Reference Summary

QoS Concept	Key Fact
Four QoS characteristics	Bandwidth, Delay (Latency), Jitter, Packet Loss
VoIP one-way delay requirement	<150 ms (ITU G.114)
VoIP jitter requirement	<30 ms
VoIP packet loss requirement	<1%
Three QoS models	Best-Effort, IntServ (RSVP), DiffServ (DSCP)
Dominant QoS model today	DiffServ
DSCP field size	6 bits (64 possible values) in IP header ToS byte
CoS field size	3 bits in 802.1Q VLAN tag (Layer 2 only)
VoIP DSCP recommendation	EF (DSCP 46) for media; CS3 (DSCP 24) for signalling
QoS pipeline steps	Classify → Mark → Queue → Schedule → Police → Shape
Best queuing for VoIP	LLQ (CBWFQ + strict priority queue)
Policing vs shaping	Policing drops excess packets; shaping buffers and delays them
Shaping direction	Outbound only
Policing direction	Inbound or outbound
Cisco MQC objects	class-map (classify) → policy-map (action) → service-policy (apply to interface)
Key verification command	`show policy-map interface <int>`

Test Your Knowledge – QoS Quiz

1. Which QoS characteristic describes the variation in delay between consecutive packets of the same voice or video flow?

A. Bandwidth B. Latency C. Jitter D. Packet loss

Correct answer is C. Jitter is the variation in inter-packet arrival delay for packets of the same flow. While latency is the absolute one-way delay, jitter is the inconsistency in that delay. VoIP is particularly sensitive to jitter because the receiving endpoint plays out audio at a fixed rate — packets arriving unevenly cause audible distortion. VoIP jitter should be kept below 30 ms, and a playout buffer is used to absorb residual jitter.

2. Which QoS model uses RSVP to reserve bandwidth on a per-flow basis along the entire path before traffic is sent?

A. Best-Effort B. IntServ (Integrated Services) C. DiffServ (Differentiated Services) D. MPLS Traffic Engineering

Correct answer is B. IntServ uses RSVP (Resource Reservation Protocol) to signal resource requirements hop-by-hop before a flow begins. Each router along the path reserves the requested bandwidth. This provides hard per-flow guarantees but scales poorly — each router must maintain state for every active flow. IntServ is largely replaced by DiffServ in modern networks.

3. What DSCP value is recommended for VoIP RTP media streams, and what PHB does it correspond to?

A. DSCP 0 — Default (Best Effort) B. DSCP 26 — AF31 C. DSCP 48 — CS6 D. DSCP 46 — EF (Expedited Forwarding)

Correct answer is D. EF (Expedited Forwarding) at DSCP 46 is the standard marking for VoIP RTP media. EF provides the lowest latency, lowest jitter, and lowest loss behaviour of any DiffServ PHB. VoIP signalling (SIP, H.323) uses CS3 (DSCP 24) separately. Remember: EF = voice media = DSCP 46 = CoS 5.

4. What is the correct order of the QoS pipeline steps?

A. Classify → Mark → Queue → Schedule → Police → Shape B. Mark → Classify → Police → Shape → Queue → Schedule C. Queue → Schedule → Classify → Mark → Police → Shape D. Police → Shape → Classify → Mark → Queue → Schedule

Correct answer is A. The logical QoS pipeline is: (1) Classify — identify the traffic type; (2) Mark — write a DSCP/CoS value for downstream devices; (3) Queue — place in the appropriate output queue; (4) Schedule — determine transmission order; (5) Police — enforce rate limits by dropping excess; (6) Shape — smooth traffic by buffering excess. In practice these can overlap, but this is the conceptual ordering for CCNA.

5. What is the key advantage of LLQ over CBWFQ for VoIP traffic?

A. LLQ uses RSVP to pre-reserve bandwidth for each VoIP call B. LLQ provides more bandwidth to VoIP by giving it a 50% share of total link capacity C. LLQ adds a strict priority queue that is always served first, guaranteeing minimum delay and jitter for VoIP — CBWFQ alone cannot guarantee low latency D. LLQ automatically classifies VoIP traffic without requiring a class-map

Correct answer is C. CBWFQ guarantees minimum bandwidth to each class but serves all queues in a weighted round-robin — a voice packet may still wait behind data packets in the scheduler, causing latency and jitter. LLQ adds a strict priority queue (configured with the priority command) that is always dequeued before any CBWFQ queue is served. This eliminates queuing delay for VoIP, keeping latency and jitter within required limits.

6. What is the fundamental difference between traffic policing and traffic shaping?

A. Policing is applied outbound; shaping is applied inbound B. Policing drops or re-marks excess packets immediately; shaping buffers excess packets and releases them smoothly at the target rate C. Policing uses token buckets; shaping uses FIFO queues D. Shaping is used on LAN interfaces; policing is used on WAN interfaces only

Correct answer is B. This is the most important policing vs shaping distinction. Policing is a hard enforcer — excess packets are dropped (or re-marked) immediately with no buffering; this introduces packet loss but no queuing delay. Shaping is a gentle smoothing mechanism — excess packets are buffered in a shaping queue and released at the target rate; this introduces delay but avoids packet loss. Shaping is always outbound; policing can be inbound or outbound.

7. In the Cisco MQC framework, what is the role of the `service-policy` command?

A. It defines the match criteria for classifying traffic into groups B. It defines the QoS actions (bandwidth, priority, police) to apply to each traffic class C. It enables NBAR for deep packet inspection on an interface D. It applies a policy-map to a specific interface in the inbound or outbound direction, activating the QoS policy

Correct answer is D. In Cisco MQC, the three objects work together: class-map defines what traffic belongs to each class (match criteria); policy-map defines what to do with each class (actions: bandwidth, priority, police, shape, set); service-policy is the glue that applies the policy-map to an interface in the input or output direction. Without service-policy, the class-map and policy-map exist but have no effect on actual traffic.

8. Where should the QoS trust boundary be placed in an enterprise network, and why?

A. At the first network device under IT control (access switch or router port) — end-user devices cannot be trusted to mark their own traffic honestly; marks from PCs should be reset to best-effort B. At the WAN edge router — all LAN devices should be trusted to mark their own traffic C. At the internet gateway — ISP routers apply all markings D. There is no trust boundary — all DSCP marks are accepted from all devices

Correct answer is A. End-user devices (PCs, laptops) can self-mark their traffic with any DSCP value — a user could mark a BitTorrent download as EF (VoIP priority) to get preferential treatment. The trust boundary is where IT verifies and re-marks traffic. Cisco IP phones are typically trusted (hardware under IT control); PC traffic passing through the phone's switch port is re-marked to DSCP 0. The access layer switch is the most common trust boundary location.

9. Your router's WAN interface has a 100 Mbps physical connection to the ISP, but your contracted CIR is 20 Mbps. The ISP enforces this with a policer. Without QoS on your router, what happens to traffic bursting above 20 Mbps?

A. The ISP's router stores excess packets and releases them when capacity is available B. The excess traffic is automatically re-routed over an alternative path C. The ISP's policer drops packets exceeding 20 Mbps, causing packet loss and TCP retransmissions — configuring traffic shaping at 20 Mbps on your egress interface would prevent this D. Nothing — the ISP's policer only applies to UDP traffic

Correct answer is C. Without egress shaping, your router sends at the physical line rate (100 Mbps bursts) and the ISP's policer drops everything above 20 Mbps — causing unpredictable packet loss that triggers TCP retransmissions, increasing latency and degrading application performance. By configuring shape average 20000000 (20 Mbps) on your WAN egress interface, excess packets are buffered locally and released at exactly 20 Mbps — the ISP policer never sees a burst above the CIR.

10. You run `show policy-map interface Serial0/0/0` and see that the VOICE class has a large number of drops. What is the most likely cause and fix?

A. The DSCP marking is wrong — change VoIP DSCP from EF to AF41 B. The LLQ priority queue has a policer that is set too low for the actual VoIP bandwidth — the priority command rate-limits the strict priority queue; increase the priority bandwidth value to accommodate all active VoIP calls C. The class-map uses match-any instead of match-all — change to match-all D. Apply a separate service-policy to the inbound direction to re-mark VoIP traffic

Correct answer is B. In LLQ, the priority <kbps> command does two things: (1) places the class in the strict priority queue; (2) also polices that class to the specified rate. If the configured priority bandwidth is lower than the actual VoIP traffic rate (e.g., more calls are active than provisioned for), the built-in policer drops excess VoIP packets. The fix is to increase the priority bandwidth value to match the real VoIP load — calculate required bandwidth as: (codec bandwidth + headers) × number of simultaneous calls.

← Back to Home