Lesson Overview
Quality of Service (QoS) is a networking technology used to prioritize critical applications, manage network congestion, and improve traffic performance.
This lesson covers QoS fundamentals, bandwidth, latency, jitter, packet loss, traffic classification and marking (DSCP/CoS), queuing, congestion avoidance, policing, and shaping. It also introduces Cisco QoS configuration, verification, and troubleshooting techniques.
Learning Objectives
Understand QoS fundamentals, benefits, and limitations.
Explain QoS packet processing from ingress to egress.
Identify and classify different types of network traffic.
Understand DSCP, CoS, and traffic marking.
Configure and manage QoS trust boundaries.
Explain queuing and congestion management techniques.
Understand traffic policing and rate limiting.
Explain traffic shaping and hierarchical QoS.
Interpret Cisco MQC configurations and policy counters.
Design QoS policies for a 20 Mbps enterprise WAN.
Troubleshoot classification, marking, queuing, policing, shaping, and platform-related QoS issues.
1. QoS Foundations and Purpose
1.1 What Quality of Service Is
Quality of Service (QoS) is a set of mechanisms used to identify important traffic and control how competing traffic shares a constrained network resource. QoS does not create bandwidth. Instead, it decides which packets should receive preferential treatment, guaranteed bandwidth, lower latency, or a controlled rate when demand exceeds available capacity.
A network can run with no visible benefit from QoS while links are uncongested. The value becomes visible when a serialization point, WAN circuit, tunnel, wireless medium, or oversubscribed egress interface cannot transmit all packets immediately. At that moment, packets must wait in queues or be dropped, and QoS determines how that contention is handled.
1.2 Key Network Performance Metrics
Bandwidth, latency, and jitter determine how efficiently and consistently network traffic is delivered. Different applications, such as voice, video conferencing, and file transfers, have different performance requirements.
1. Bandwidth (BW)
Bandwidth is the maximum data-carrying capacity of a network connection, measured in Mbps or Gbps.
Determines how much traffic a link can carry.
Insufficient bandwidth can cause congestion and packet drops.
QoS mechanisms such as CBWFQ allocate bandwidth to critical applications.
2. Latency
Latency is the time required for a packet to travel from source to destination, measured in milliseconds (ms).
High latency affects voice calls, video conferencing, and interactive applications.
Latency includes processing, queuing, transmission, and propagation delays.
QoS mechanisms such as LLQ help reduce congestion-related queuing delay.
3. Jitter
Jitter is the variation in packet delay over time, usually measured in milliseconds (ms).
High jitter causes choppy voice, inconsistent audio, and video freezing.
Common causes include congestion, traffic bursts, and variable queuing delays.
QoS priority queuing helps reduce jitter for real-time applications.
1.2 Why QoS Is Required in Enterprise Networks
Consider an enterprise branch connected to its Data Center through a 20 Mbps WAN connection.
The branch uses the following applications:
Application | Traffic demand | Business requirement |
|---|---|---|
Voice Calls | 2 Mbps | Very low delay and jitter |
Video Conferencing | 6 Mbps | Low delay and adequate bandwidth |
Business Applications | 5 Mbps | Predictable response time |
File Transfers / Backups | 15 Mbps | Best available throughput |
Total | 28 Mbps | WAN capacity: 20 Mbps |
The total traffic demand is greater than the available WAN bandwidth.
Without QoS
When congestion occurs:
Packets arrive faster than the WAN interface can transmit them.
Packets accumulate in output queues.
Queueing delay increases.
Queues may eventually fill, causing packet drops.
Voice and video applications may experience degraded performance.
File transfers may consume a large share of available capacity.
Depending on the hardware and queueing implementation, this can lead to poor performance for critical applications.
With QoS
A network engineer configures traffic classes and applies an appropriate QoS policy.
The policy can:
Provide priority treatment to latency-sensitive voice traffic.
Allocate bandwidth to video and business applications.
Limit the impact of large file transfers.
Control congestion using queuing and shaping.
Drop or remark traffic exceeding configured limits.
Expected Result: During congestion, critical traffic receives appropriate treatment, while less-sensitive traffic uses the available capacity according to the configured policy.
1.3 How Network Congestion Occurs
Congestion occurs when the rate of traffic arriving for transmission exceeds the capacity available at a network interface or another forwarding resource.
Example — Enterprise Branch WAN
1.4 The Four Traffic Problems QoS Tries to Control
|
Problem |
What the user sees |
QoS response |
|
Bandwidth contention |
Slow file transfers, applications competing for the same link |
Class-based bandwidth allocation, shaping, policing |
|
Latency |
Voice delay, interactive applications feel slow |
Priority queuing and congestion reduction |
|
Jitter |
Uneven packet arrival; voice/video quality degrades |
Low-latency queue, stable shaping, avoid deep queues for real-time traffic |
|
Packet loss |
Choppy media, TCP retransmissions, application stalls |
Protect important classes, tune queueing, avoid uncontrolled congestion |
Packet Processing During Congestion
Packets arrive at the router.
The router determines the required outgoing interface.
If packets cannot be transmitted immediately, they may be buffered.
The applicable queueing scheduler determines which buffered packets are transmitted next.
If queue limits are reached, packets may be dropped.
QoS mechanisms influence how packets are classified, scheduled, and discarded.
Important: Queueing behavior depends on the router platform, hardware, QoS configuration, and location of the bottleneck.
1.5 What QoS Can Solve
QoS is most effective when network performance problems are caused by competition for limited bandwidth.
1. Protect Real-Time Traffic
QoS can provide preferential queueing treatment to voice and other latency-sensitive applications.
For example, an LLQ priority class can reduce queueing delay for correctly classified VoIP packets during congestion.
2. Manage Bandwidth Allocation
Class-Based Weighted Fair Queuing (CBWFQ) can allocate a minimum bandwidth guarantee to selected traffic classes during congestion.
Unused bandwidth may be available to other eligible classes depending on the scheduler and configuration.
3. Control Backup and Bulk Traffic
Traffic shaping or policing can limit the impact of large transfers on other applications.
For example, backup traffic can be assigned lower scheduling priority than voice and critical business applications.
4. Improve Application Performance During Congestion
A properly configured QoS policy can reduce congestion-related latency, jitter, and packet drops for prioritized traffic.
5. Control Traffic at Provider Rate Limits
A router may have a 1 Gbps physical interface connected to a provider service limited to 20 Mbps.
Shaping traffic to an appropriate rate can reduce the likelihood of uncontrolled provider-side policing and provide a local queue where application priorities can be enforced.
6. Provide Predictable Traffic Treatment
Consistent classification, marking, and queuing policies across the enterprise help ensure critical traffic receives appropriate treatment at network bottlenecks.
1.6 What QoS Cannot Solve
Understanding the limitations of QoS is essential for enterprise network design.
1. QoS Cannot Increase Physical Bandwidth
If a WAN link provides 20 Mbps, QoS cannot increase its physical or contracted capacity to 30 Mbps.
It can only manage how the available 20 Mbps is shared.
2. QoS Cannot Fix Physical Network Problems
QoS cannot repair:
Damaged fiber or copper cabling.
Faulty transceivers.
Interface hardware failures.
Excessive physical-layer errors.
An unavailable ISP circuit.
These issues require physical or transport-layer troubleshooting.
3. QoS Cannot Eliminate Propagation Delay
Long-distance network connections have unavoidable propagation delay.
QoS can reduce queueing delay, but it cannot eliminate latency caused by geographic distance.
4. QoS Cannot Guarantee Performance When Traffic Demand Is Too High
If real-time or critical traffic alone consumes more bandwidth than the WAN can support, QoS cannot guarantee acceptable performance for every packet.
The network may require more capacity, application optimization, or admission control.
5. QoS Cannot Automatically Fix Application Problems
An application may perform poorly because of:
Server CPU or memory exhaustion.
Slow storage.
Database processing delays.
Application design problems.
DNS failures.
Authentication issues.
QoS cannot resolve these non-network bottlenecks.
6. QoS Cannot Guarantee End-to-End Treatment Without Cooperation
A local QoS policy can control traffic treatment on the device where it is applied.
However, downstream service providers and network devices may remark, ignore, or apply different treatment to DSCP and CoS markings.
End-to-end QoS requires an appropriate design across the relevant network domains.
2. QoS Packet-Processing Model
Figure 2 - Conceptual QoS packet-processing pipeline. Exact hardware order varies by platform, but the operational workflow is consistent.
A practical way to learn QoS is to follow one packet through the network. At ingress the device identifies the packet and may set or validate a marking. The marking is carried downstream, but each device still makes a local forwarding and queueing decision. At egress the packet may enter a specific queue; if the egress resource is congested, the scheduler decides which queue is serviced. A policer may discard or remark traffic that exceeds its rate, while a shaper may hold packets and release them later.
|
Stage |
Question the device answers |
Typical MQC element |
|
Classify |
What traffic is this? |
class-map, ACL, match dscp, match protocol |
|
Mark |
What service class should downstream devices recognize? |
set dscp / set precedence / set qos-group |
|
Trust |
Should I preserve this marking or replace it? |
Ingress policy / platform trust configuration |
|
Queue |
Where should this packet wait if the interface is busy? |
priority, bandwidth, queue-limit |
|
Congestion manages |
Which queue should transmit next? |
LLQ/CBWFQ scheduler |
|
Police |
Should this traffic be allowed above a contracted rate? |
police ... conform/exceed/violate actions |
|
Shape |
Should bursts be buffered and sent at a configured rate? |
shape average ... |
3. Classification
3.1 Purpose of Classification
Classification groups packets into traffic classes so that a later QoS action can be applied consistently. Classification should be stable, unambiguous, and as close as practical to the point where the network can reliably identify the application or endpoint.
3.2 Common Classification Methods
|
Method |
Example |
Strength |
Risk / limitation |
|
DSCP |
match dscp ef |
Fast and scalable after a trusted marking exists |
Wrong if the marking came from an untrusted endpoint |
|
ACL |
match access-group name VOICE-ACL |
Precise for known IP/port patterns |
Applications may use dynamic ports or encryption |
|
IP address / subnet |
Source server subnet |
Simple for fixed application zones |
Does not distinguish multiple apps on the same host |
|
NBAR/application recognition |
match protocol <application> |
Application-aware classification |
Platform/license/signature support varies |
|
CoS / 802.1p |
Layer-2 frame priority |
Useful on trunks and campus switching |
Exists only on tagged L2 frames and may be rewritten |
|
Interface / VLAN / QoS-group |
Classify by ingress context |
Useful in service-provider or hierarchical designs |
Can be too broad if many applications share the same context |
3.3 MQC Classification Example - ACL Based
|
ip access-list extended ACL-VOICE-RTP permit udp 10.10.10.0 0.0.0.255 any range 16384 32767 ! class-map match-any CM-VOICE match access-group name ACL-VOICE-RTP ! policy-map MARK-IN class CM-VOICE set dscp ef class class-default set dscp default ! interface GigabitEthernet0/0 description LAN-facing interface
service-policy input MARK-IN |
Read the configuration in three steps: the ACL identifies the candidate traffic, the class-map gives the match a reusable class name, and the policy-map defines the action. The service-policy statement is what activates the policy on an interface and direction. Without the service-policy, the class-map and policy-map exist only in the configuration database.
3.4 Classification Using Existing DSCP Markings
|
class-map match-any VOICE match dscp ef class-map match-any VIDEO match dscp af41 class-map match-any CRITICAL-DATA match dscp af31 class-map match-any BACKUP
match dscp cs1 |
|
Troubleshooting clue — When a class counter remains at zero, do not start by changing queue bandwidth. First prove that the traffic actually matches the class. Use show policy-map interface, show access-lists, packet capture, and source/destination/DSCP validation. |
3.5 match-all vs match-any
A match-any class matches when any one configured criterion is true. A match-all class requires all configured match criteria to be true. Misunderstanding this behavior is a common reason for empty classes.
|
class-map match-all CRITICAL-FROM-APP-SERVERS match dscp af31
match access-group name APP-SERVERS |
The class above requires both conditions. A packet marked AF31 from another source does not match, and traffic from APP-SERVERS that is marked differently also does not match.
4. Marking and DSCP
QoS marking is the process of assigning or modifying values in packet headers so network devices can identify traffic classes and apply the appropriate forwarding treatment.
In enterprise networks, applications have different performance requirements. Voice traffic requires low latency and jitter, while video conferencing needs sufficient bandwidth and predictable delivery. File transfers and backups generally tolerate more delay.
Instead of inspecting every packet deeply at every network hop, routers and switches can use QoS markings to classify packets efficiently.
QoS marking commonly uses two fields:
DSCP (Differentiated Services Code Point): A 6-bit field in the IP header used for Layer 3 QoS classification.
CoS (Class of Service): A 3-bit Priority Code Point (PCP) field in an IEEE 802.1Q VLAN tag used for Layer 2 traffic prioritization.
4.1 Why Mark Packets?
Classification can be expensive or difficult to repeat at every hop. Marking creates a compact signal that downstream devices can use for consistent per-hop behavior. The most common Layer-3 marking is DSCP in the IPv4/IPv6 Differentiated Services field.
Important: Marking a packet does not automatically reserve bandwidth or guarantee priority. The forwarding devices must have QoS policies that recognize and act on the markings.
4.2 DSCP Structure
DSCP uses the upper six bits of the 8-bit Differentiated Services field. The remaining two bits are used for Explicit Congestion Notification (ECN). DSCP therefore ranges from 0 to 63. The value represents a codepoint, not a universal priority number. Devices map codepoints to local forwarding behavior according to policy.
|
Important — A higher decimal DSCP value does not automatically mean a packet receives better service. EF 46, CS6 48, and CS7 56 have different intended uses. The configured queueing policy determines actual treatment. |
|
Traffic class |
DSCP name |
Decimal |
Binary (6-bit) |
Typical training use |
|
Best Effort |
CS0 / Default |
0 |
000000 |
General data with no special treatment |
|
Scavenger / low priority |
CS1 |
8 |
001000 |
Backup, bulk, non-critical transfers |
|
Assured Forwarding 2 |
AF21 |
18 |
010010 |
Example transactional class |
|
Critical data |
AF31 |
26 |
011010 |
Business-critical applications |
|
Interactive video |
AF41 |
34 |
100010 |
Interactive video |
|
Voice bearer |
EF |
46 |
101110 |
Low-latency voice RTP |
|
Network control |
CS6 |
48 |
110000 |
Routing / network control by design |
The DSCP field is part of the 8-bit Differentiated Services (DS) field in IPv4 and IPv6.
The DS field consists of:
6 bits for DSCP.
2 bits for Explicit Congestion Notification (ECN).
4.4 Assured Forwarding (AF) Codepoints
AF codepoints are written AFxy. x identifies the forwarding class (1 through 4), while y represents the drop precedence within that class (1 through 3). The decimal value can be calculated as 8x + 2y.
For example, AF41 = (8 x 4) + (2 x 1) = 34.
The AF model is useful when a network wants several queues or service levels and may use different drop behavior within a class. Whether a platform implements multiple drop precedences with WRED or another mechanism depends on the device and policy.
4.5 IP Precedence - Legacy, but Still Operationally Important
IP Precedence is the older Layer-3 QoS marking carried in the three most-significant bits of the IPv4 Type-of-Service / modern Differentiated Services field. It provides only eight values (0-7), so it is much less granular than the 6-bit DSCP field. DSCP largely superseded IP Precedence, but precedence remains important because legacy WAN designs, existing policies, troubleshooting output, WRED profiles, and migration projects still expose it.
Do not treat the precedence number as a universal end-to-end priority. It is a marking. Each device maps the marking to local queues, policers, drop profiles, or other behaviors. Values 6 and 7 are conventionally reserved for network-control traffic and should not be assigned to ordinary user applications.
|
Prec. |
Bits |
Legacy Name |
DSCP Class Selector |
DSCP Decimal |
Operational Guidance |
|
0 |
000 |
Routine |
CS0 |
0 |
Best effort / default |
|
1 |
001 |
Priority |
CS1 |
8 |
Often used for low-priority/scavenger classes in modern designs |
|
2 |
010 |
Immediate |
CS2 |
16 |
Legacy service class |
|
3 |
011 |
Flash |
CS3 |
24 |
Legacy service class; many signaling designs use CS3 |
|
4 |
100 |
Flash Override |
CS4 |
32 |
Legacy high service class |
|
5 |
101 |
Critical |
CS5 |
40 |
Legacy high service class; EF also has upper bits 101 |
|
6 |
110 |
Internetwork Control |
CS6 |
48 |
Reserve for network-control/routing traffic |
|
7 |
111 |
Network Control |
CS7 |
56 |
Reserve for network-control traffic |
4.6 Relationship Between IP Precedence and DSCP
DSCP is a superset of IP Precedence. The first three bits of a DSCP value occupy the same high-order bit positions used by legacy precedence. Class Selector codepoints preserve the legacy mapping by setting the lower three DSCP bits to 000: CSn = precedence n x 8. For example, precedence 5 maps directly to CS5 (binary 101000, decimal 40).
|
Advanced CCNP point - A precedence match can be broader than a DSCP match. EF is binary 101110 (decimal 46), so its three high-order bits are 101, the same legacy precedence group as precedence 5. AF31 is binary 011010 (decimal 26), whose three high-order bits are 011 (precedence 3). A legacy precedence-based policy can therefore group multiple modern DSCP codepoints together and lose DSCP granularity. |
Common migration and interpretation examples:
- If a class-map uses match ip precedence 5, verify whether the intent was specifically voice/EF or all packets whose upper three QoS bits equal 101.
- If a device remarks traffic from precedence 5 to DSCP EF, the policy is converting a coarse legacy class into a specific modern PHB.
- If a provider hands off only IP Precedence while the enterprise uses DSCP, define and document an explicit DSCP-to-precedence and precedence-to-DSCP mapping at the boundary.
- When troubleshooting packet captures, read all six DSCP bits first. Do not infer the exact DSCP from precedence alone.
Cisco MQC examples:
|
class-map match-any LEGACY-PREC5 match ip precedence 5 ! policy-map NORMALIZE-LEGACY-QOS class LEGACY-PREC5 set dscp ef class class-default set dscp default ! ! Mark with legacy precedence when interoperability requires it policy-map LEGACY-EDGE-MARK class CRITICAL-LEGACY
set precedence 3 |
|
IPv4/IPv6 command nuance - On current IOS XE documentation, match ip precedence is IPv4-specific, while match precedence can classify IPv4 and IPv6. The set precedence and set ip precedence forms are documented as equivalent for marking the outer Layer-3 header. Always confirm support on the exact platform/release. |
4.7 Marking Example
|
policy-map MARK-APPLICATIONS class CM-VOICE set dscp ef class CM-VIDEO set dscp af41 class CM-ERP set dscp af31 class CM-BACKUP set dscp cs1 class class-default
set dscp default |
4.8 Verification of Marking
|
show policy-map interface GigabitEthernet0/0 input show class-map show policy-map MARK-APPLICATIONS show access-lists
! Packet capture / analyzer: ! Verify the IPv4/IPv6 DS field after the marking point.
! Do not assume a counter increment proves the mark survives downstream. |
5. QoS Trust Boundaries
A trust boundary defines where the enterprise accepts QoS markings from connected devices.
Consider an IP phone connected to a Cisco access switch, with a computer connected through the phone.
The switch may trust the phone's approved voice markings while validating or remarking traffic from the attached computer.
Recommended Approach
Trusted Devices
Managed IP phones with controlled QoS configurations.
Approved network infrastructure devices.
Authorized voice or video infrastructure.
Untrusted Devices
General user computers.
Guest devices.
Unknown endpoint equipment.
Devices capable of marking traffic without authorization.
Why Trust Boundaries Matter
Without an appropriate trust boundary, a user could mark large file transfers as EF and cause them to compete for the same priority queue used by legitimate voice traffic.
A good marking policy should classify or validate traffic as close to the source as practical.
5.1 What Is a Trust Boundary?
The trust boundary is the point where the network decides whether an incoming QoS marking is credible. Traffic arriving before the trust boundary is untrusted; the device should classify or remark it according to enterprise policy. Traffic after the trust boundary can normally be forwarded using the established marking unless another policy intentionally changes it.
5.2 Placement Examples
|
Endpoint type |
Recommended policy idea |
Reason |
|
Managed IP phone |
Trust or validate voice markings at the access port; remark PC traffic separately |
The organization controls the phone configuration and can limit the trusted source |
|
Employee PC |
Do not blindly trust all DSCP values; classify/remark by policy |
Users or applications can set DSCP locally |
|
Video endpoint / telepresence |
Trust only when managed and verified; otherwise remark |
Real-time media benefits from consistent marking but can consume significant bandwidth |
|
Server farm |
Mark at server, access switch, or first routed hop based on ownership and application knowledge |
Application classification is often easiest close to the source |
|
Internet / partner edge |
Usually reclassify or map to internal classes |
External markings may not match enterprise policy |
5.3 Trust Boundary Failure Modes
- Trusting every endpoint allows a workstation to mark bulk traffic EF and compete with voice.
- Remarking everything to DSCP 0 destroys the end-to-end QoS model and causes all traffic to fall into class-default downstream.
- Applying a marking policy in the wrong direction can leave traffic unchanged even though the configuration appears correct.
- A tunnel, firewall, WAN provider, or security device may copy, reset, or rewrite markings; verify at multiple points rather than only at the source.
|
Best practice — Define a written marking policy and enforce it at a controlled boundary. Trust only devices or interfaces that the organization controls and has verified. |
6. Queuing and Congestion Management
Queuing and Congestion Management are Quality of Service (QoS) mechanisms that control how packets are buffered, scheduled, and transmitted when multiple traffic flows compete for limited network bandwidth.
In enterprise networks, routers and switches may receive packets faster than their outgoing interfaces can transmit them. When this occurs, packets must wait in output queues before transmission.
Without appropriate congestion management, business-critical applications such as voice, video conferencing, and interactive business services may experience excessive delay, jitter, and packet loss.
Cisco QoS provides several queuing mechanisms to manage traffic according to application requirements.
Why Queuing Is Important
Prioritizes latency-sensitive applications.
Allocates bandwidth among different traffic classes.
Prevents bulk traffic from monopolizing limited network capacity.
Reduces congestion-related latency and jitter for selected traffic.
Supports predictable application performance.
Allows unused bandwidth to be shared where supported.
Helps control packet drops during congestion.
Key principle: Queuing does not increase available bandwidth. It determines which packets are transmitted first and how competing traffic classes share the available capacity.
6.1 When Queuing Matters
Queues matter when an egress resource is congested. If packets arrive more slowly than the interface can transmit them, packets usually leave immediately and queue statistics may remain near zero. A useful lab must deliberately create congestion; otherwise LLQ and CBWFQ behavior cannot be observed.
6.2 LLQ and CBWFQ
Low Latency Queuing (LLQ) adds a strict priority queue to class-based weighted fair queuing. Real-time traffic such as voice is serviced ahead of non-priority queues during congestion, but the priority class is bounded so that it cannot starve all other traffic. CBWFQ classes receive configured bandwidth guarantees when congestion exists; unused capacity can normally be used by other classes according to platform scheduling behavior.
|
QoS action |
Purpose |
Typical class |
|
priority percent 15 |
Create a low-latency priority queue; 15% example reservation/limit context |
Voice EF |
|
bandwidth percent 25 |
Guarantee a share during congestion |
Video AF41 |
|
bandwidth percent 25 |
Guarantee a share during congestion |
Critical data AF31 |
|
fair-queue / default scheduler |
Share remaining capacity among best-effort flows |
class-default |
|
queue-limit |
Control how deep a queue may become before tail drop |
Platform / class specific |
6.3 Example WAN Child Policy
|
policy-map WAN-CHILD class VOICE priority percent 15 class VIDEO bandwidth percent 25 class CRITICAL-DATA bandwidth percent 25 class BACKUP police cir 2000000 conform-action transmit exceed-action drop class class-default
fair-queue |
This policy expresses business intent. Voice receives a low-latency queue, video and critical data receive bandwidth guarantees, backup is rate-limited, and all unmatched traffic uses class-default. The exact scheduler implementation is platform dependent, but the troubleshooting logic remains the same: verify class matches, offered rate, queue depth, and drops.
6.4 Congestion Management vs Congestion Avoidance
Congestion Management and Congestion Avoidance are two important Quality of Service (QoS) mechanisms used to control network traffic when available bandwidth becomes limited.
Although both mechanisms address network congestion, they perform different functions.
Congestion Management: Determines how packets are queued, scheduled, and transmitted when multiple traffic classes compete for bandwidth.
Congestion Avoidance: Attempts to prevent excessive queue buildup by selectively dropping packets or marking congestion before queues become full.
Key difference: Congestion Management determines which packets are transmitted next, while Congestion Avoidance determines when packets should be dropped or congestion-signaled to control queue growth.
6.4.1 Congestion Management
What Is Congestion Management?
Congestion Management controls how packets are buffered and scheduled for transmission when an outgoing interface cannot immediately forward all arriving traffic.
Its primary objective is to allocate available bandwidth according to application requirements and configured QoS priorities.
How Congestion Management Works
Packets arrive at the network device.
The router classifies traffic into configured QoS classes.
Packets are assigned to appropriate output queues.
The scheduler evaluates priority and bandwidth-allocation rules.
Packets are selected from queues for transmission.
Lower-priority traffic receives service according to the scheduling policy and available capacity.
Common Congestion Management Mechanisms
First-In, First-Out (FIFO)
Transmits packets in the order they arrive, without class-based prioritization.
Weighted Fair Queuing (WFQ)
Provides weighted scheduling among individual traffic flows.
Class-Based Weighted Fair Queuing (CBWFQ)
Allows administrators to define traffic classes and allocate minimum bandwidth guarantees during congestion.
Low Latency Queuing (LLQ)
Combines class-based queuing with strict-priority treatment for latency-sensitive traffic, such as VoIP.
Practical Example
A branch uses a 20 Mbps WAN circuit carrying:
Voice: 2 Mbps
Video: 6 Mbps
Business applications: 5 Mbps
Backup traffic: 15 Mbps
The total demand is 28 Mbps.
With an appropriate LLQ and CBWFQ policy:
Voice receives priority scheduling.
Video receives a minimum bandwidth allocation.
Business applications receive guaranteed bandwidth during congestion.
Backup traffic uses the remaining eligible capacity.
Expected Result: Business-critical traffic receives preferential treatment during congestion, reducing its exposure to excessive queueing delay and packet loss.
6.4.3 Congestion Avoidance
What Is Congestion Avoidance?
Congestion Avoidance uses queue-management techniques to control buffer occupancy and reduce the likelihood of persistent queue overflow.
Instead of waiting until the queue is completely full, supported mechanisms can drop selected packets early or use Explicit Congestion Notification (ECN) to signal congestion.
Its primary objective is to manage queue buildup and encourage congestion-responsive traffic sources, particularly TCP, to reduce their sending rates.
How Congestion Avoidance Works
Packets arrive at an output queue.
The router monitors queue occupancy.
A congestion-avoidance algorithm evaluates configured thresholds.
When queue occupancy increases, selected packets may be dropped or ECN-marked.
Responsive traffic sources react to congestion signals.
The queue can stabilize at a lower occupancy when traffic behavior and available capacity permit.
Common Congestion Avoidance Mechanisms
Tail Drop
Packets are dropped when the queue reaches its capacity. Tail Drop is the conventional overflow behavior, rather than a proactive early-avoidance algorithm.
Random Early Detection (RED)
Uses average queue depth to begin probabilistically dropping packets before the queue becomes full.
Weighted Random Early Detection (WRED)
Extends RED by allowing differentiated drop behavior based on traffic classification, such as DSCP or IP Precedence.
Explicit Congestion Notification (ECN)
Allows supported network devices to signal congestion by marking eligible packets rather than dropping them, provided the endpoints and forwarding path support ECN.
Practical Example
Assume a business application uses TCP and is assigned to a queue that supports WRED.
As average queue occupancy increases:
Below the minimum threshold, WRED normally does not drop packets.
Between the thresholds, WRED introduces probabilistic drops according to the configured profile.
At or above the maximum threshold, WRED applies its maximum-threshold drop behavior.
TCP senders can respond to these drops by reducing their transmission rate.
Expected Result: Queue growth may be controlled before persistent overflow, helping reduce sustained congestion and excessive buffering delay.
6.5 What Queue Counters Mean
|
Counter / symptom |
Interpretation |
Next check |
|
Packets matched increase; no drops |
Traffic is classified and queue is not overflowing |
Confirm congestion actually exists if testing QoS behavior |
|
Total drops increase in a class |
Queue cannot serve all offered traffic under current policy |
Compare offered rate vs bandwidth; check queue limit and downstream bottleneck |
|
Priority drops increase |
Real-time class is exceeding the priority allowance or is misclassified |
Validate call/video load and ensure bulk traffic is not marked EF |
|
class-default dominates traffic |
Many applications are unclassified or markings were lost |
Capture DSCP and inspect trust boundary / class-map logic |
|
Queue stats remain zero during expected congestion |
Policy may not be attached to actual bottleneck or hardware may expose counters differently |
Verify egress interface, subinterface/tunnel, parent policy, platform queue counters |
7. Policing
7.1 Purpose of Policing
Policing enforces a rate. A policer measures traffic against a token-bucket profile. Conforming traffic is transmitted, while excess traffic can be dropped or remarked depending on policy. A policer does not normally hold excess packets for later transmission, so it can introduce loss when bursts exceed the configured allowance.
7.2 Token-Bucket Terms
|
Term |
Meaning |
Operational effect |
|
CIR |
Committed Information Rate |
Average token generation / permitted rate |
|
Bc |
Committed burst size |
Amount of traffic that can be sent in a normal measurement interval using available tokens |
|
Be / peak burst |
Additional burst allowance in two-rate/three-color models where supported |
Allows larger bursts before violate behavior |
|
Conform |
Traffic within the token profile |
Usually transmit |
|
Exceed |
Traffic beyond conform allowance |
Drop, remark, or transmit based on configuration |
|
Violate |
Traffic beyond extended allowance in models that support it |
Commonly drop |
7.3 Policing Configuration Example
|
policy-map LIMIT-BACKUP class BACKUP police cir 2000000 conform-action transmit exceed-action set-dscp-transmit cs1 class class-default pass ! interface GigabitEthernet0/1
service-policy input LIMIT-BACKUP |
The example enforces a 2 Mbps CIR for the BACKUP class. Conforming traffic is transmitted. Excess traffic is not dropped in this example; it is remarked CS1 and transmitted so that downstream QoS can treat it as low priority. On another policy, exceed-action drop could be used instead.
7.4 When to Police
- Enforce an ingress or egress contract.
- Prevent backup or guest traffic from consuming more than its intended share.
- Protect a downstream device or service from an excessive traffic class.
- Remark excess traffic instead of dropping it when the design wants a lower service class for out-of-profile traffic.
7.5 Policing Troubleshooting
|
Symptom |
Likely cause |
What to check |
|
Unexpected drops at low average rate |
Burst size too small for bursty application, microbursts, or rate units misread |
Policer conform/exceed counters, offered load, Bc, application burst profile |
|
No police drops even when load is high |
Class not matching, policy wrong direction/interface, hardware behavior, CIR higher than actual offered rate |
show policy-map interface and traffic generator rate |
|
Traffic is transmitted but gets poor treatment downstream |
Excess traffic is being remarked |
Capture DSCP after the policer; inspect exceed action |
|
TCP throughput collapses |
Policer creates repeated loss and retransmissions |
Consider shaping on egress if the goal is smoothing rather than hard enforcement |
7.6 Policing Deep Dive - How the Device Makes the Decision
A policer is a meter plus an action. It does not ask whether the physical interface is congested. Instead, every packet that matches the class is measured against the configured traffic contract. The device determines whether enough tokens are available for the packet and then applies the configured conform, exceed, and (for three-color designs) violate action. Because a policer normally does not hold packets for later transmission, the rate is enforced by forwarding, remarking, or dropping packets immediately.
Device-level decision sequence:
1. Packet enters the interface and is classified into a QoS class.
2. The policer identifies the applicable meter (for example CIR 2 Mbps, or CIR/PIR for a two-rate policer).
3. Tokens are replenished according to the configured rate. The bucket size controls how much short-term burst can be accepted.
4. The packet length is compared with the tokens currently available.
5. If the packet is in-profile, tokens are removed and the conform action is executed.
6. If the packet exceeds the committed profile, the exceed action is executed; a three-color design may make a further PIR/violate decision.
7. Counters are incremented for conformed, exceeded, and violated traffic. These counters are the primary proof of the policer decision.
|
Important - A policer can drop traffic even when the interface is otherwise idle. This is expected: policing is contract enforcement, not congestion detection. If a 1-Gbps port has a 2-Mbps policer, a 5-Mbps burst can be dropped even though the physical port is nowhere near saturation. |
7.7 CIR, PIR, Bc, Be, Tc, and Token-Bucket Mathematics
The important parameters are easiest to understand as a rate plus a permitted burst. CIR (Committed Information Rate) defines the committed average rate. PIR (Peak Information Rate), when present, defines an upper rate for two-rate policing. Bc is the committed burst allowance; Be is an additional/peak burst allowance depending on policer type and platform. Tc is the conceptual measurement interval.
A useful design relationship is Bc(bits) = CIR(bits/s) x Tc(seconds), or Bc(bytes) = CIR x Tc / 8.
|
Term |
Meaning |
How to Interpret It |
|
CIR |
Committed Information Rate |
Average in-profile rate. Example: 2,000,000 bps. |
|
PIR |
Peak Information Rate |
Upper rate for a two-rate/three-color policy; traffic beyond it can be violated/dropped. |
|
Bc |
Committed Burst |
Token capacity that permits short-term bursts while still treating traffic as committed. |
|
Be |
Excess/Peak Burst |
Additional burst parameter used by some policer modes; exact semantics depend on policer type/platform. |
|
Tc |
Measurement interval (conceptual) |
Time represented by the committed burst: Tc = Bc(bits) / CIR. |
|
Conform |
In-profile result |
Usually transmit without changing service treatment. |
|
Exceed |
Above committed profile |
Drop, remark to a lower DSCP/precedence, or transmit according to the contract. |
|
Violate |
Above peak profile |
Commonly drop or strongly remark in a three-color design. |
Example calculation: for a 2-Mbps CIR and a deliberately chosen 125-ms committed burst interval, Bc = 2,000,000 x 0.125 / 8 = 31,250 bytes. The example is for learning; production burst sizing should follow platform behavior, traffic characteristics, provider contract, and vendor guidance rather than blindly using one interval everywhere.
|
Model |
Meter Inputs |
Possible Colors |
Typical Use |
|
Single-rate, two-color |
CIR + burst |
Conform / Exceed |
Simple hard cap. Excess commonly drops. |
|
Single-rate, three-color |
CIR with committed/excess burst logic |
Conform / Exceed / Violate |
Allows a limited excess burst before the most severe action. |
|
Two-rate, three-color |
CIR + PIR + burst parameters |
Conform / Exceed / Violate |
Useful when committed and peak service levels must be distinguished. |
Representative two-rate three-color configuration:
|
class-map match-any PARTNER-APP match dscp af31 ! policy-map PARTNER-POLICER class PARTNER-APP
police cir 5000000 bc 78125 pir 8000000 be 125000 conform-action transmit exceed-action set-dscp-transmit af11 violate-action drop |
Interpretation: up to the committed profile, traffic remains AF31. Traffic that exceeds the committed profile but remains within the peak profile is downgraded to AF11 and transmitted. Traffic beyond the peak profile is dropped. Exact supported syntax, burst handling, and hierarchical order of operations vary by IOS XE platform, so validate on the target device.
7.9 Policing Use Cases - When It Is the Right Tool
Customer/provider contract enforcement: prevent a tenant, VRF, or customer class from exceeding a purchased rate.
Guest/backup/scavenger traffic: place a hard ceiling on traffic that must never dominate an interface.
Ingress protection: limit a class before it can consume downstream forwarding resources.
Priority-queue protection: platforms often police LLQ/priority traffic so an incorrectly marked real-time class cannot starve all other queues.
Two-rate service contracts: transmit committed traffic, remark excess traffic to a lower service, and drop traffic above a peak threshold.
|
Do not use policing as a substitute for capacity planning - If the business application legitimately needs more sustained bandwidth than the CIR, a policer will repeatedly discard or downgrade it. That is a policy decision, not a congestion-management improvement. |
8. Shaping and Hierarchical QoS
Traffic Shaping is a Quality of Service mechanism that controls the rate at which packets are transmitted through a network interface by buffering excess traffic and scheduling it for later transmission.
In enterprise networks, the physical speed of a router interface may be significantly higher than the bandwidth purchased from a service provider.
For example:
Router physical interface: 1 Gbps
Service provider WAN bandwidth: 20 Mbps
Traffic arriving for WAN transmission: 35 Mbps
Although the router interface operates at 1 Gbps, the service provider may enforce a 20 Mbps bandwidth limit.
Without appropriate traffic shaping, the router can transmit packets toward the provider faster than the contracted service can support, potentially causing provider-side policing, packet drops, and poor application performance.
Traffic shaping allows network engineers to control the transmission rate locally, where they can also apply class-based queuing policies.
Key Functions of Traffic Shaping
Limits the average outgoing traffic rate.
Buffers excess packets instead of immediately discarding them.
Smooths traffic bursts over time.
Helps reduce uncontrolled downstream policing drops.
Creates a local congestion point for QoS scheduling.
Supports integration with CBWFQ and LLQ.
Helps manage traffic on interfaces faster than the contracted service rate.
Important: Shaping introduces buffering and therefore can add latency. If sustained offered traffic exceeds the shaped rate, queues can eventually fill and packets will still be dropped.
Figure 8 - Policing versus shaping. Both use rate measurement concepts, but excess-traffic behavior is fundamentally different.
8.1 Purpose of Shaping
Shaping limits the average transmit rate by buffering excess packets and transmitting them later. It is commonly applied on egress when the physical interface is faster than the actual service rate.
For example, a 1 Gbps Ethernet handoff may provide only a 20 Mbps carrier service. Without shaping, the router may send bursts far above the provider CIR and the provider may police/drop them. A local shaper creates the bottleneck inside the router, where the enterprise can apply intelligent queueing before transmission.
8.2 Hierarchical Policy - Parent Shaper + Child Queuing
Hierarchical Quality of Service (HQoS) allows multiple QoS policies to operate together in a parent-child structure.
A common enterprise design uses:
Parent Policy: Shapes total traffic to the available WAN service rate.
Child Policy: Classifies and schedules traffic within that shaped rate.
This allows a network engineer to control the total WAN transmission rate while protecting critical applications during congestion.
Cisco IOS XE Configuration — Parent Shaper and Child Queuing
The following is a complete HQoS policy example for a 20 Mbps WAN, assuming traffic has already been marked with the appropriate DSCP values.
Step 1 — Create Class Maps
|
configure terminal class-map match-any CM-VOICE |
policy-map PM-WAN-CHILD |
What the child policy does
Voice receives strict-priority service with a configured 2 Mbps priority rate.
Video receives a minimum 6 Mbps allocation during congestion.
Business traffic receives a minimum 5 Mbps allocation during congestion.
Remaining traffic is handled using supported fair-queuing behavior.
The LLQ priority rate is enforced during congestion, helping prevent priority traffic from starving other classes.
Step 3 — Configure Parent Shaping Policy
policy-map PM-WAN-PARENT |
What the parent policy does
Shapes aggregate traffic to a long-term average of 20 Mbps.
Buffers eligible traffic when transmission credits are unavailable.
Uses the child policy to schedule traffic within the shaping constraints.
Step 4 — Apply the Parent Policy to the WAN Interface
interface GigabitEthernet0/0/0 |
Only the parent policy is attached directly to the interface. The child policy is attached beneath the parent using service-policy.
8.3 Packet Behavior in the Hierarchy
1. Packets reach the WAN egress interface and enter the parent class-default.
2. The parent shaper limits the aggregate stream to 20 Mbps.
3. The child policy classifies packets by DSCP while they wait behind the shaped bottleneck.
4. Voice uses the priority queue; video and critical data receive configured bandwidth shares during congestion.
5. Backup traffic is policed to 2 Mbps within its class.
6. Unmatched traffic uses class-default.
7. show policy-map interface should display both parent shaping statistics and nested child-class statistics on platforms that expose them.
8.4 Shaping Troubleshooting
Traffic shaping controls the average transmission rate by buffering packets and scheduling them according to a configured shaping policy.
In enterprise WAN environments, shaping is commonly implemented through Hierarchical QoS (HQoS), where the parent policy controls the aggregate transmission rate and the child policy manages traffic prioritization using LLQ and CBWFQ.
Even when the shaping configuration appears correct, applications may experience latency, packet loss, unexpected throughput limitations, or incorrect traffic prioritization.
Effective shaping troubleshooting requires validating:
Configured shaping rate and service-provider CIR.
Parent and child QoS policy attachment.
Packet classification and DSCP markings.
Shaping queue depth and packet-drop counters.
Actual offered load and transmission rates.
Provider policing and encapsulation overhead.
Platform capabilities and interface health.
8.4.1 Common Shaping Troubleshooting Scenarios
Scenario 1 — Provider Still Reports Traffic Bursts Above CIR
Symptom
The service provider reports that traffic exceeds the Committed Information Rate (CIR), even though shaping is configured on the customer router.
Possible Causes
Shaping rate is configured higher than the provider's CIR.
Parent QoS policy is attached to the wrong interface.
Traffic bypasses the interface where shaping is configured.
Encapsulation overhead causes the provider-measured rate to exceed the configured rate.
Shaper burst behavior exceeds the provider's allowed burst tolerance.
Router and provider use different traffic measurement intervals.
Verification Commands
|
show policy-map interface GigabitEthernet0/0/0 |
What to Verify
Confirm that the parent shaping policy is applied in the output direction.
Verify that the configured shaping rate matches the intended provider service profile.
Confirm that production traffic actually traverses the shaped interface.
Compare router traffic statistics against provider-side measurements.
Validate burst allowances, encapsulation overhead, and measurement intervals.
Expected Result: The router's transmitted traffic conforms to the provider's agreed rate and burst profile, with no unexpected provider policing drops.
Scenario 2 — Large Delay During Heavy Network Traffic
Symptom
Users experience slow application response times or high latency during periods of heavy WAN utilization.
Possible Causes
Shaping buffers contain excessive queued traffic.
Offered load consistently exceeds the shaping rate.
Queue limits allow excessive buffering.
Critical applications are not classified into appropriate queues.
Parent shaping rate is lower than the actual usable service capacity.
Verification Commands
show policy-map interface GigabitEthernet0/0/0 |
What to Verify
Examine the parent shaping rate.
Inspect queue depth and available queue statistics.
Compare offered traffic with the actual transmission rate.
Identify classes responsible for sustained congestion.
Confirm that latency-sensitive traffic receives the intended scheduling treatment.
Expected Result: Queueing delays remain acceptable for critical applications, and traffic is scheduled according to business requirements.
Operational Note: A shaper can be functioning correctly while application latency remains excessive. Shaping controls transmission rate but does not automatically prevent deep buffering.
Scenario 3 — Voice Still Suffers Although the Parent Shaper Works
Symptom
The parent shaping policy operates correctly, but voice calls experience jitter, choppy audio, or packet loss.
Possible Causes
Voice traffic does not match the child QoS class.
LLQ priority allocation is insufficient.
DSCP EF markings are missing or rewritten before egress.
Parent shaping rate is too restrictive.
Unexpected traffic is competing in the priority queue.
Congestion occurs at another network hop.
Verification Commands
show policy-map interface GigabitEthernet0/0/0 |
What to Verify
Confirm that voice packets are classified as DSCP EF.
Verify that the voice class appears under the child policy.
Check that the voice packet counters increase during active calls.
Review priority queue drops and offered traffic rates.
Confirm that the priority allocation is appropriate for the voice load.
Expected Result: Voice traffic matches the correct priority class and experiences minimal congestion-related delay, jitter, and loss.
Scenario 4 — Child Policy Counters Do Not Increment
Symptom
The parent shaping policy is active, but packet counters under the child QoS policy remain at zero.
Possible Causes
Child policy is not correctly attached to the parent policy.
Traffic does not match the configured class maps.
QoS classification is performed using incorrect DSCP values.
Traffic traverses a different interface.
The device does not support the configured hierarchical QoS combination.
Hardware-based QoS statistics are not exposed in the expected counter.
Verification Commands
show policy-map interface GigabitEthernet0/0/0 |
What to Verify
Confirm that
PM-WAN-PARENTis attached to the correct WAN egress interface.Verify that
PM-WAN-CHILDappears beneath the parent shaping class.Confirm that traffic matches the correct DSCP values.
Generate representative traffic and observe class counters.
Check platform-specific QoS hardware statistics if standard counters remain unchanged.
Expected Result: The parent policy and nested child policy appear in the operational output, and the appropriate child class counters increment when matching traffic passes through the interface.
Scenario 5 — Throughput Is Lower Than Expected
Symptom
Applications experience less throughput than expected, even though the configured parent shaping rate appears correct.
Possible Causes
Shaping rate is lower than the intended service rate.
Incorrect shaping units are configured.
Additional traffic policing is applied.
Provider service capacity is lower than expected.
Layer 1 or Layer 2 problems affect transmission.
Encapsulation overhead reduces usable application throughput.
TCP congestion control or endpoint limitations restrict throughput.
Verification Commands
show policy-map interface GigabitEthernet0/0/0 |
What to Verify
Confirm that the shaping rate uses the correct units in bits per second.
Compare the configured shaping rate against the provider's contracted bandwidth.
Examine offered traffic, transmitted traffic, and queue-drop statistics.
Check for additional policing policies.
Verify interface errors and physical connectivity.
Compare measured application throughput against expected protocol and encapsulation overhead.
Expected Result: Traffic throughput is consistent with the available service capacity, QoS allocations, network overhead, and application behavior.
8.5 Shaping Deep Dive - What Happens to Each Packet
A shaper creates an intentional egress bottleneck. Packets that arrive faster than the configured shaping rate are placed in a queue and transmitted later as the scheduler becomes eligible to send them. Unlike policing, shaping normally converts excess rate into delay first; packets are dropped only if the shaping queue/buffer eventually overflows or another queue-management policy drops them.
Device-level shaping sequence:
1. Packet is classified into the parent shaping class (commonly class-default for an aggregate WAN shaper).
2. The scheduler checks whether the class is eligible to transmit under the configured shape rate.
3. If eligible, the packet can be scheduled immediately.
4. If the arrival rate is above the shaping rate, packets remain queued until sufficient shaping credits/tokens are available.
5. When a child policy is nested under the shaper, the child scheduler decides which queued class transmits first (for example LLQ voice before bandwidth classes).
6. If the queue reaches its limit, tail-drop or an active queue-management mechanism can drop packets.
7. The result is a smoother egress stream whose long-term transmit rate stays at or below the configured rate.
|
Why this matters on Ethernet WAN handoffs - A 1-Gbps physical interface connected to a 20-Mbps provider service may never experience local hardware congestion at 30 Mbps. Without an enterprise shaper, the provider policer becomes the real bottleneck and can discard packets before your local LLQ/CBWFQ policy has a chance to control the traffic. A 20-Mbps parent shaper deliberately moves the bottleneck into your router, where your child queues can make the scheduling decision. |
8.6 Shaping Rate, Bursts, Queues, and Delay
The configured shape rate is a maximum service rate for the shaped class. If the offered rate stays below that rate, packets normally experience little or no shaping delay. If offered load exceeds the shape rate, queue depth grows. More buffering can absorb larger bursts but also increases latency; too little buffering can cause drops. This is the classic throughput-versus-delay tradeoff.
Conceptually, Bc and Tc describe how much traffic may be released per shaping interval: Bc(bits) = CIR x Tc. However, modern IOS XE hardware platforms often implement scheduling in hardware and may derive or ignore manually specified burst details differently. Treat the configured rate and observed queue behavior as primary operational evidence, and verify platform documentation before tuning burst values.
|
Traffic Condition |
Queue Behavior |
Transmit Behavior |
Operational Meaning |
|
Offered rate < shape rate |
Little/no shaping queue |
Output follows offered load |
No problem; shaper is not limiting traffic |
|
Offered rate > shape rate for short burst |
Queue grows temporarily |
Output stays near shape rate |
Burst is delayed and later drained |
|
Offered rate > shape rate continuously |
Queue remains populated |
Output capped near shape rate |
Sustained congestion exists inside the shaper |
|
Queue reaches limit |
Queue drops increase |
Output still capped |
Buffer insufficient for offered load/latency target |
9. Interpreting QoS Configurations and Operational Output
9.1 Read MQC in the Correct Order
1. Find the service-policy and determine the exact interface and direction where the policy is active.
2. Open the policy-map and identify each class and its action.
3. Open each class-map and determine the match logic (match-any vs match-all).
4. Follow referenced ACLs, protocols, DSCP values, or nested service policies.
5. Determine whether the policy is a child policy inside a parent shaper.
6. Use show policy-map interface to prove that real packets hit the expected class and to inspect rates, queues, and drops.
7. Validate packet markings before and after the policy with capture or an adjacent device; never assume a set command survives end to end.
9.2 Example - How to Interpret show policy-map interface
|
R1# show policy-map interface GigabitEthernet0/1 GigabitEthernet0/1 Service-policy output: WAN-PARENT
Class-map: class-default (match-any) 125000 packets, 98000000 bytes 30 second offered rate 24500000 bps, drop rate 0 bps Match: any Queueing Traffic Shaping Target/Average Rate 20000000 Service-policy : WAN-CHILD
Class-map: VOICE 12000 packets, 2400000 bytes 30 second offered rate 900000 bps Priority: 15% ... Total drops: 0
Class-map: VIDEO 18000 packets, 14000000 bytes 30 second offered rate 4200000 bps Bandwidth 25% ... Total drops: 0
Class-map: BACKUP 45000 packets, 50000000 bytes police: cir 2000000 bps
conformed ... exceeded ... |
Interpretation: the physical service is oversubscribed because offered load is about 24.5 Mbps while the parent shapes to 20 Mbps. Voice is well below its priority allowance and shows no drops. Video is using several Mbps and is classified correctly. Backup is subject to its 2 Mbps policer. If users still report voice loss, the next step is not to increase the priority queue immediately; verify downstream loss, DSCP preservation, interface errors, and return-path QoS.
9.3 Counters That Matter
|
Counter |
Question it answers |
|
Class packet/byte count |
Is my traffic matching this class? |
|
Offered rate |
How much traffic is entering the class? |
|
Drop rate / total drops |
Is congestion or policing discarding traffic? |
|
Queue depth / queue limit |
Is the queue building and how close is it to the limit? |
|
Policer conform/exceed/violate |
Is traffic inside or outside the rate profile? |
|
Shaper target/actual rate |
Is the parent bottleneck operating at the intended rate? |
|
Interface drops/errors |
Is packet loss occurring outside the QoS class queues? |
9.4 Deep-Dive Method for Interpreting Any QoS Configuration
Do not read a QoS policy from the class-map downward and assume it is active. Interpret MQC from the attachment point inward. The same class-map can exist unused, the same policy-map can be attached in different directions, and a child policy can have a completely different effective rate depending on its parent.
Use this six-pass method:
1. Attachment pass - Find every service-policy statement. Record interface, subinterface/tunnel, input/output direction, and parent policy name.
2. Hierarchy pass - Expand the parent policy. Follow every nested service-policy until you reach leaf classes. Draw the hierarchy on paper if necessary.
3. Classification pass - For every class, resolve match-any/match-all, ACLs, DSCP, precedence, NBAR/application, protocol, VLAN, and nested class-map criteria.
4. Action pass - Identify the actual action: set/remark, priority, bandwidth, fair-queue, random-detect, police, shape, drop, or pass. Separate marking actions from scheduling actions.
5. Rate-math pass - Convert percentages into expected kbps/Mbps using the correct reference rate. For hierarchical designs, verify whether the platform derives rates from the parent shaper or another reference.
6. Operational pass - Use counters and captures to prove the running device behaves as the configuration suggests. Configuration intent without matching counters is not proof.
9.5 Line-by-Line Configuration Interpretation Example
|
ip access-list extended ERP-FLOWS permit tcp 10.10.20.0 0.0.0.255 host 10.30.30.100 eq 443 ! class-map match-any VOICE match dscp ef class-map match-any VIDEO match dscp af41 class-map match-any ERP match access-group name ERP-FLOWS class-map match-any BACKUP match dscp cs1 ! policy-map INGRESS-MARK class ERP set dscp af31 ! policy-map WAN-CHILD class VOICE priority percent 15 class VIDEO bandwidth percent 25 class ERP bandwidth percent 25 class BACKUP police cir 2000000 conform-action transmit exceed-action drop class class-default fair-queue ! policy-map WAN-PARENT class class-default shape average 20000000 service-policy WAN-CHILD ! interface GigabitEthernet0/0/0 service-policy input INGRESS-MARK interface GigabitEthernet0/0/1
service-policy output WAN-PARENT |
|
Configuration Line |
Meaning |
Operational Consequence |
|
service-policy input INGRESS-MARK |
Ingress policy on Gi0/0/0 |
ERP flows are classified by ACL and marked AF31 before later devices/egress policies see them. |
|
service-policy output WAN-PARENT |
Egress parent on Gi0/0/1 |
All outbound WAN traffic enters the parent shaper. |
|
shape average 20000000 |
Parent aggregate ceiling |
Creates a controlled 20-Mbps bottleneck so the child scheduler operates at the service rate. |
|
service-policy WAN-CHILD |
Nested child scheduler |
Traffic waiting behind the shaper is separated into voice/video/ERP/backup/default. |
|
priority percent 15 |
Strict-priority service |
Voice receives low-latency priority treatment, subject to platform/priority policing behavior. |
|
bandwidth percent 25 |
Minimum congestion bandwidth |
Video/ERP receive a guaranteed share during congestion, not a hard maximum. |
|
police cir 2000000 |
Hard rate enforcement |
Backup above 2 Mbps is dropped in this example even if physical link capacity remains. |
|
fair-queue |
Default-class scheduling |
Unmatched traffic remains serviceable rather than being intentionally starved. |
10. Enterprise Use Case - 20 Mbps WAN
10.1 Business Requirement
A branch office has a 20 Mbps WAN service. Employees use IP voice, interactive video, an ERP application, ordinary web/data traffic, and nightly backups. During backup windows, voice becomes choppy and video freezes. The objective is to preserve real-time traffic, guarantee capacity for the ERP application, and prevent backup traffic from dominating the WAN.
10.2 Traffic Policy
|
Class |
DSCP |
Business intent |
Example policy |
|
Voice |
EF 46 |
Lowest latency and jitter; protect during congestion |
LLQ 15% (~3 Mbps of 20 Mbps) |
|
Interactive video |
AF41 34 |
Important real-time media |
Bandwidth 25% (~5 Mbps) |
|
Critical ERP/data |
AF31 26 |
Business-critical transactional traffic |
Bandwidth 25% (~5 Mbps) |
|
Backup / bulk |
CS1 8 |
Use spare capacity but never dominate the link |
Police at 2 Mbps |
|
Best effort |
0 |
General user traffic |
class-default / remaining bandwidth |
10.3 Why Parent Shaping Is Needed
The router may have a 1 Gbps Ethernet interface while the provider delivers only a 20 Mbps service. If the enterprise queues only against the physical interface speed, the router may not see congestion locally because 20-30 Mbps is trivial on a 1 Gbps port. The provider then becomes the real bottleneck and may discard traffic without honoring the enterprise queue design. Shaping the enterprise egress to 20 Mbps moves the congestion point into the router so the child QoS policy can make the intended scheduling decision.
10.4 End-to-End Design Checklist
- Mark voice/video/critical applications close to the trusted source.
- Verify the marking survives access, distribution, WAN edge, tunnel/provider, and remote edge.
- Shape the WAN egress to the contracted rate when the physical handoff is faster than the service.
- Queue voice/video/critical traffic under the shaped parent.
- Rate-limit backup or scavenger traffic so that it cannot consume the entire circuit.
- Apply equivalent reverse-direction policy when traffic patterns require QoS in both directions.
- Measure with real congestion and application probes; QoS cannot be validated from configuration alone.
|
Troubleshooting rule — Change one variable at a time. Preserve pre-change counters, generate a repeatable test flow, clear counters only when necessary, make one controlled change, and compare the result. Randomly increasing priority or queue sizes can hide the actual fault and create new starvation problems. |
Quick knowledge check
1. Which component of latency is most directly affected by QoS?
Answer: Queuing delay. Priority scheduling and congestion management can reduce the time selected packets spend waiting in queues.
2. Why are voice and video applications sensitive to jitter?
Answer: Variable packet arrival times can cause choppy audio, late packets, video freezing, and inconsistent real-time playback.
3. What is the difference between DSCP and CoS?
Answer: DSCP is a 6-bit Layer 3 IP marking. CoS refers to the 3-bit Priority Code Point in an IEEE 802.1Q VLAN tag, with values from 0 through 7.
4. What do CIR, Bc, Be, and Tc represent?
Answer: CIR is the configured committed rate; Bc is committed burst size; Be is an additional burst allowance where supported; Tc is the committed time interval. A common relationship is Tc = Bc / CIR.