Study guide
13.2 Queuing Algorithms and Congestion Management
HPE Aruba Networking Certified Associate - Campus Access HPE6-A85
Track your progress as you read
Finished sections get a check mark.
1 Introduction: HPE6-A85 Exam Overview
HPE6-A85 Exam Facts and Current Blueprint
2 Chapter 1: Network Stack Fundamentals
1.1 OSI Reference Model and Encapsulation 1.2 TCP/IP Protocol Suite and IP Headers 1.3 Layer 2 Operation, ARP, and 802.1Q Tagging
3 Chapter 2: Physical Connectivity and Host Addressing
2.1 Ethernet Media and Transceiver Standards 2.2 Power over Ethernet (PoE, PoE+, PoE++) Standards and Budgeting 2.3 LLDP, LLDP-MED, and Voice VLAN Configuration 2.4 Host IP Addressing and DHCP Relay Operations
4 Chapter 3: Network Resiliency and Virtualization
3.1 Virtual Switching Framework (VSF) Architecture and Topologies 3.2 VSF Split Detection, Failover, and Auto-Stacking 3.3 Virtual Switching Extension (VSX) Architecture and Operations 3.4 High-Availability Gateways: VRRP and VSX Active-Gateway
5 Chapter 4: AOS-CX Architecture and Switch Operation
4.1 AOS-CX Hardware Portfolio and State Database Architecture 4.2 Network Analytics Engine (NAE) and Automated Telemetry 4.3 AOS-CX Interface Configuration and Port Control 4.4 Link Aggregation (LAG) and LACP Configuration
6 Chapter 5: Layer 2 Protocols and Spanning Tree
5.1 AOS-CX VLAN Configuration and Native VLAN Handling 5.2 Spanning Tree Protocols: STP, RSTP, and MSTP 5.3 Spanning Tree Protections and Loop Prevention 5.4 MAC Address Table Learning, Aging, and Forwarding
7 Chapter 6: Wireless Fundamentals, Standards, and RF
6.1 IEEE 802.11 Standards and Wi-Fi Generations 6.2 RF Fundamentals, Signal Propagation, and Channel Design 6.3 Aruba Access Point Hardware Portfolio and Suffix Conventions 6.4 WLAN Topologies, BSSID/ESSID, and Roaming Standards
8 Chapter 7: Aruba Wireless Architecture and Management
7.1 AOS 10 Architecture and Aruba Central Integration 7.2 Wireless Forwarding Modes: Bridge vs Tunnel Mode 7.3 Automated RF and Client Optimization: AirMatch and ClientMatch 7.4 Secure Wireless Access: WPA3, SAE, and MPSK Implementation
9 Chapter 8: IP Routing Fundamentals and OSPF
8.1 IP Routing Principles and Packet Forwarding 8.2 OSPFv2 Protocol Mechanics and Adjacency Formation 8.3 OSPF Designated Routers and Multi-Area Deployments 8.4 ECMP, Static Routing, and VRF Isolation
10 Chapter 9: Campus Network Security and Segmentation
9.1 DHCP Snooping and Dynamic ARP Inspection 9.2 Port Security and MAC Address Limiting 9.3 ClearPass Policy Management and RADIUS Change of Authorization 9.4 Dynamic Segmentation, User-Based Tunneling, and Policy Enforcement
11 Chapter 10: Authentication, Authorization, and Accounting
10.1 The AAA Framework and Architecture 10.2 802.1X Authentication and EAP Methods 10.3 MAC Authentication and Captive Portal Onboarding 10.4 Administrative Access Control: RADIUS vs TACACS+
12 Chapter 11: Network Management and Telemetry
11.1 Aruba Central Cloud Architecture and Group Configuration 11.2 Zero-Touch Provisioning (ZTP) and Aruba Activate 11.3 AI Insights and Aruba User Experience Insight (UXI) 11.4 Network Telemetry, Streaming APIs, and SNMP/Syslog
13 Chapter 12: Troubleshooting the Solution
12.1 Structured Troubleshooting Methodologies and Scope Isolation 12.2 AOS-CX Layer 2 and Interface Diagnostic Commands 12.3 Layer 3, IP Services, and End-to-End Diagnostics 12.4 Physical-Layer Troubleshooting 12.5 Troubleshooting Wireless Clients and Network Access
14 Chapter 13: Optimizing Performance: QoS, Baselines, and Comparisons
13.1 Quality of Service (QoS) Classification and Marking 13.2 Queuing Algorithms and Congestion Management 13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting 13.4 Establishing a Performance Baseline 13.5 Comparing Results to the Baseline
15 Chapter 14: Plan the Solution
14.1 Analyzing the Current Environment 14.2 Interpreting an Architect's High-Level Design 14.3 Creating a Low-Level Design 14.4 Preparing for Implementation
16 Chapter 15: Validate and Operate the Solution
15.1 Validating the Solution 15.2 Performing Firmware Updates 15.3 Making Basic Ongoing Configuration Changes 15.4 Maintaining Network Documentation
13.2 Queuing Algorithms and Congestion Management
Key Takeaways Explain This Topic AI
CX 6200 and 6300 ports have 8 egress queues (0-7), while the CX 6400 has 4; the factory-default queue profile maps local priority n to queue n and the factory-default schedule profile uses DWRR with weight 1 on every queue.
First-In First-Out (FIFO) queuing lacks traffic differentiation, while Strict Priority (SP) guarantees immediate transmission for delay-sensitive voice packets but risks starving lower queues if unpoliced.
Deficit Weighted Round Robin (DWRR) dynamically assigns bandwidth shares to queues while accommodating variable-length Ethernet frames through deficit counters, eliminating queue starvation.
Hybrid scheduling combines Strict Priority on high-priority queues (Queue 7 for voice) with DWRR across remaining queues (Queues 0–6) to guarantee delay bounds without neglecting best-effort data.
Congestion avoidance via Weighted Random Early Detection (WRED) prevents TCP global synchronization and bufferbloat by proactively dropping packets based on queue depth thresholds and packet drop precedence.
Last updated: October 2026
Queuing Algorithms and Congestion Management
Quick Summary: In campus switching architectures, congestion occurs when the aggregate volume of ingress traffic directed toward an egress interface exceeds the physical transmission speed of that link (such as multiple 10 Gbps access uplinks converging onto a 10 Gbps aggregation port, or a 10 Gbps server port forwarding traffic toward 1 Gbps edge clients). To prevent indiscriminate packet drops during bursts, switches place packets into hardware egress queues . How these queues are serviced and emptied onto the physical medium is governed by queuing and scheduling algorithms (such as Strict Priority and Deficit Weighted Round Robin) paired with proactive congestion avoidance mechanisms (such as WRED).
AOS-CX Hardware Egress Queuing Architecture
Aruba AOS-CX switches feature dedicated ASIC packet buffers and hardware egress queues. The CX 6200 and 6300 provide 8 queues per port (Queue 0 through Queue 7) ; the CX 6400 provides 4 (AOS-CX 10.14 QoS Guide). +-------------------------------------------------------------------------+
- | AOS-CX EGRESS QUEUING & SCHEDULING PIPELINE |
- | |
- | Ingress Packet -> QoS Trust/Map -> Local Priority (0-7) |
- | | |
- | v |
- | +---------------------------------------+ |
- | | Queue 7: Voice RTP (Strict Pri) |======> [EGRESS] |
- | +---------------------------------------+ | |
- | | Queue 6: Video Conf (DWRR: 30%) | | |
- | +---------------------------------------+ | |
- | | Queue 5: Signaling/Call (DWRR: 20%) | | |
- | +---------------------------------------+ | |
- | | Queue 4: Critical Data (DWRR: 20%) |======> [PORT] |
- | +---------------------------------------+ | |
- | | Queue 3: Standard Data (DWRR: 15%) | | |
- | +---------------------------------------+ | |
- | | Queue 2: Background (DWRR: 10%) | | |
- | +---------------------------------------+ | |
- | | Queue 1: Best Effort (DWRR: 5%) | | |
- | +---------------------------------------+ | |
- | | Queue 0: Scavenger (DWRR: Min) | | |
- | +---------------------------------------+ |
- +-------------------------------------------------------------------------+
- Local Priority Mapping
When a packet ingresses an AOS-CX switch, the forwarding engine determines its Local Priority (an internal value from 0 to 7) based on the port's trust state and mapping tables ( cos-map or dscp-map ). Once the switching fabric forwards the packet toward the target egress port, the switch evaluates the active Queue Profile ( qos queue-profile ) to place the packet into the appropriate hardware egress queue.
On 8-queue platforms the factory-default queue profile maps Local Priority 0–7 directly to Queue 0–7, and the factory-default schedule profile uses DWRR with a weight of 1 on every queue , so no queue is strict priority until you configure one.
Queuing and Scheduling Algorithms
A scheduling algorithm determines the exact mathematical order and frequency with which a switch port's hardware queues transmit packets onto the physical wire.
1. First-In, First-Out (FIFO) Queuing
Mechanism: All arriving packets enter a single queue buffer and are transmitted strictly in the order they arrived, regardless of packet type, CoS tag, or DSCP value.
Limitations: FIFO provides zero traffic differentiation. If a large FTP transfer or video download fills the buffer, time-sensitive VoIP packets arriving behind the bulk data must wait until the entire buffer empties. This induces massive latency and jitter, rendering FIFO completely unsuitable for converged enterprise networks.
2. Strict Priority (SP) Scheduling
Mechanism: Queues are prioritized in strict hierarchical order. The scheduler always inspects the highest-numbered queue (e.g., Queue 7). As long as Queue 7 contains a single packet, it is transmitted immediately. Only when Queue 7 is completely empty does the scheduler inspect Queue 6, and so forth down to Queue 0.
Strengths: Provides the lowest possible latency and jitter. Ideal for real-time voice RTP packets (Queue 7).
The Starvation Hazard: If an unpoliced video stream or denial-of-service flood fills Queue 7, the scheduler continuously services Queue 7 and never visits Queues 0 through 6. All lower-priority queues experience complete packet starvation , causing critical business applications, DNS resolution, and TCP sessions to drop.
3. Deficit Weighted Round Robin (DWRR) Scheduling
To prevent queue starvation while maintaining differentiated service, modern switches implement Deficit Weighted Round Robin (DWRR) .
Weight Allocation: Each queue is assigned a configurable weight representing a percentage of available port bandwidth (e.g., Queue 4 = 30%, Queue 3 = 20%, Queue 2 = 10%).
The Variable Frame Size Challenge: Standard Weighted Round Robin (WRR) assumes fixed-length packets. In Ethernet networks, however, frame sizes vary wildly—from 64-byte TCP ACKs to 1518-byte standard frames and 9000-byte jumbo frames. Under simple WRR, a queue servicing 1500-byte frames receives far more bandwidth than a queue servicing 64-byte frames.
Deficit Counter Mechanics: DWRR resolves this by assigning a quantum (a credit allocation in bytes proportional to the queue's assigned weight). In each round:
The scheduler adds the quantum to the queue's deficit counter .
If the deficit counter exceeds the byte size of the packet waiting at the head of the queue, the packet is transmitted, and its byte length is subtracted from the deficit counter.
If the next packet is larger than the remaining deficit counter, the scheduler leaves the remaining credit intact and moves to the next queue.
In the next round, the queue receives another quantum addition, allowing large frames to be transmitted fairly without over-consuming link capacity.
Result: DWRR ensures predictable bandwidth distribution without starvation, regardless of packet size distributions.
4. Hybrid Scheduling (Strict Priority + DWRR)
The industry-standard best practice for campus access and aggregation switches is a hybrid scheduling model :
Queue 7 (Voice): Configured for Strict Priority (SP) to guarantee immediate, zero-latency forwarding for latency-intolerant VoIP RTP audio.
Queues 0 through 6 (Data & Video): Configured with DWRR weights to distribute remaining bandwidth equitably among video conferencing, database transactions, best-effort traffic, and scavenger streams.
Congestion Avoidance: Tail Drop vs. WRED
When sustained traffic bursts exceed an interface's transmission capacity, egress buffers fill. How the switch manages full or filling buffers determines overall application stability.
Tail Drop and the Threat of TCP Global Synchronization
Under standard Tail Drop , a switch takes no action while buffer space is available. However, once the egress queue buffer reaches 100% capacity, every subsequent arriving packet is dropped indiscriminately , regardless of its flow, importance, or protocol.
- Tail Drop triggers a catastrophic network phenomenon known as TCP Global Synchronization : Throughput
- ^ /\ /\ /\ <-- Simultaneous TCP Ramp-Up (Congestion Avoidance)
- | / \ / \ / \
- | / \ / \ / \
- | ----/------\----/------\----/------\--- <-- 100% Buffer Full (Tail Drop Event)
- | / \ / \ / \
- | / \/ \/ \ <-- Simultaneous TCP Window Collapse (Slow Start)
- +-----------------------------------------> Time
Multiple independent TCP streams share a congested uplink.
When the buffer reaches 100%, Tail Drop discards packets across all active TCP sessions simultaneously.
The endpoints detect packet loss via missing ACKs, assume severe network collapse, and simultaneously throttle their TCP Congestion Window (cwnd) down to 1 MSS (Maximum Segment Size), entering TCP Slow Start.
Link utilization abruptly plunges to near zero.
As packets are acknowledged, all endpoints simultaneously ramp up their window sizes, flooding the buffer again and triggering another round of Tail Drop.
This continuous "sawtooth" oscillation severely degrades campus throughput and causes massive jitter.
Weighted Random Early Detection (WRED)
Weighted Random Early Detection (WRED) solves TCP global synchronization and bufferbloat by dropping packets proactively before the queue buffer exhausts. Drop Probability
- ^
- 100%| +------------------ (100% Drop / Tail Drop)
- | / |
- | / |
- Max| / |
- Drop| / |
- | Marking A (AFx3) / |
- | / / |
- | / Marking B (AFx1) / |
- 0% +---------+------------------+---------+------------------> Average Queue Depth
- ^ ^
- Min Threshold Max Threshold
- (Drops Begin) (Tail Drop Zone)
- How WRED Operates
Average Queue Depth Monitoring: Rather than reacting to instantaneous bursts, WRED calculates an exponentially weighted moving average queue depth.
Minimum Threshold (TH_min): When the average queue depth is below TH_min, all packets are admitted into the buffer (0% drop rate).
Random Proactive Drops: When queue depth rises between TH_min and TH_max, WRED begins dropping a small, randomized percentage of packets. Because the drops are randomized across individual flows, only one or two TCP sessions experience packet loss. Those specific sessions back off their transmission rate, while all other sessions continue transmitting at full speed. This desynchronizes the TCP flows, smoothing aggregate throughput and keeping link utilization near 100%.
Maximum Threshold (TH_max): If congestion continues and queue depth exceeds TH_max, WRED reverts to tail drop (100% drop rate) to protect switch ASIC memory.
Differentiated Drop Precedence: The "Weighted" aspect of WRED means that the switch maintains different threshold curves based on packet markings. Packets with high drop precedence (such as AF43 or AF13) hit a lower TH_min and face higher drop probabilities, while packets with low drop precedence (such as AF41 or AF11) are protected until buffers reach much deeper thresholds.
AOS-CX Queue and Schedule Profile Configuration
Configuring queuing and scheduling on Aruba AOS-CX switches follows a structured two-part hierarchy: defining the Queue Profile (queue structure) and defining the Schedule Profile (servicing behavior).
Step 1: Configuring the Queue Profile
The queue profile defines the number of queues and maps internal Local Priorities (0–7) to hardware queues: switch# configure
- switch(config)# qos queue-profile Campus-Queues
- switch(config-queue)# map queue 0 local-priority 0
- switch(config-queue)# map queue 1 local-priority 1
- switch(config-queue)# map queue 2 local-priority 2
- switch(config-queue)# map queue 3 local-priority 3
- switch(config-queue)# map queue 4 local-priority 4
- switch(config-queue)# map queue 5 local-priority 5
- switch(config-queue)# map queue 6 local-priority 6
- switch(config-queue)# map queue 7 local-priority 7
- switch(config-queue)# exit
- Step 2: Configuring the Schedule Profile
The schedule profile defines how the queues configured in Step 1 are scheduled onto the wire: switch(config)# qos schedule-profile Campus-Schedule
- switch(config-schedule)# strict queue 7
- switch(config-schedule)# dwrr queue 6 weight 25
- switch(config-schedule)# dwrr queue 5 weight 20
- switch(config-schedule)# dwrr queue 4 weight 20
- switch(config-schedule)# dwrr queue 3 weight 15
- switch(config-schedule)# dwrr queue 2 weight 10
- switch(config-schedule)# dwrr queue 1 weight 5
- switch(config-schedule)# dwrr queue 0 weight 5
- switch(config-schedule)# exit
- Step 3: Applying Profiles Globally or to Interfaces
Globally, the queue profile and schedule profile are applied together in one command; on an interface or LAG, only a schedule profile can be applied (AOS-CX 10.14 QoS Guide): switch(config)# apply qos queue-profile Campus-Queues schedule-profile Campus-Schedule
- switch(config)# interface 1/1/48
- switch(config-if)# apply qos schedule-profile Campus-Schedule
- Step 4: Verification and Queue Monitoring
Verify queuing operation and monitor drop counters using the following CLI commands: switch# show qos queue-profile Campus-Queues
Queue Profile : Campus-Queues
- Queue Local Priorities
- ---- ----------------
- 0 0
- 1 1
- 2 2
- 3 3
- 4 4
- 5 5
- 6 6
- 7 7
- switch# show qos schedule-profile Campus-Schedule
- Schedule Profile : Campus-Schedule
- Queue Algorithm Weight / Burst
- ---- --------- --------------
- 7 strict N/A
- 6 dwrr 25
- 5 dwrr 20
- 4 dwrr 20
- 3 dwrr 15
- 2 dwrr 10
- 1 dwrr 5
- 0 dwrr 5
switch# show interface 1/1/48 queues
Interface 1/1/48 (Egress Queues, abbreviated):
- Queue Tx Packets Tx Bytes Drop Packets Drop Bytes
- ---- ------------------ ------------------ ------------------ ------------------
- 7 1842039 217356602 0 0
- 6 4829103 4982390123 120 154320
- 5 1293847 1283749102 0 0
- 1 84920194 102938471928 2490 3819200