Study guide
13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting
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.3 Traffic Policing, Shaping, and Broadcast Rate Limiting
Key Takeaways Explain This Topic AI
Traffic policing enforces bandwidth limits by dropping or re-marking excess packets without buffering, making it ideal for ingress rate limiting despite producing jagged traffic bursts.
Traffic shaping smooths egress traffic by buffering excess packets in queue memory and releasing them at a steady rate, avoiding packet drops at the expense of added latency.
Broadcast, multicast, and unknown-unicast floods can saturate campus links and exhaust switch CPU resources; per-port rate limits cap them in hardware but do not remove the cause.
AOS-CX protects ports from floods with rate-limit {broadcast | multicast | unknown-unicast | icmp} <rate> {kbps | percent | pps} ; traffic above the limit is dropped and the port stays up.
Effective storm isolation combines automated storm suppression with Layer 2 loop prevention protocols (RSTP/MSTP and loop protection) to eliminate the root cause of frame amplification.
Last updated: October 2026
Traffic Policing, Rate Limiting, and Broadcast Storm Control
Quick Summary: While queuing and scheduling manage packet priority during transient congestion, traffic conditioning and storm control enforce strict upper bounds on bandwidth consumption. Unregulated traffic bursts, rogue end-user applications, and Layer 2 broadcast storms caused by bridge loops can overwhelm switch buffers and crash network control planes. By mastering the differences between traffic policing (rate limiting via packet drops) and traffic shaping (rate smoothing via packet buffering), alongside hardware-based broadcast, multicast, and unknown unicast storm control , engineers maintain deterministic performance and protect the campus infrastructure.
Traffic Conditioning Fundamentals: Policing vs. Shaping
Traffic conditioning tools meter network traffic against an administratively configured transmission rate—known as the Committed Information Rate (CIR) —and enforce compliance when traffic exceeds that threshold.
There are two fundamentally different methods of traffic conditioning: Traffic Policing and Traffic Shaping . +-------------------------------------------------------------------------+
- | TRAFFIC POLICING VS. SHAPING |
- | |
- | [ INPUT TRAFFIC ] [ TRAFFIC POLICING ] [ TRAFFIC SHAPING ] |
- | Bursty Drops Excess Buffers Excess |
- | /\ _ ______ |
- | / \ /\ | | / \ |
- | ----/----\/--\-- CIR -------+--+------- CIR --------/--------\--- |
- | / \ | | / \ |
- | / \ / \ / \ |
- | (Jagged / Drops) (Smooth Delay) |
- +-------------------------------------------------------------------------+
- 1. Traffic Policing (Rate Limiting)
Traffic policing meters incoming or outgoing traffic using a mathematical token bucket algorithm . Tokens are deposited into the bucket at the CIR. As packets arrive, the policer checks whether sufficient tokens exist to transmit the packet:
Conforming Traffic: If sufficient tokens exist, the packet conforms to the contract and is forwarded immediately without delay.
Exceeding Traffic: If the token bucket is empty, the packet exceeds the contract. The policer takes an immediate action: it either drops the packet immediately or re-marks the packet to a lower priority (e.g., changing DSCP 46 or AF21 down to DSCP 0 or Scavenger CS1).
Key Characteristics:
No Buffering: Policing does not store packets in memory queues.
Direction: Can be applied to ingress or egress traffic, but is most commonly deployed on ingress access ports to enforce client service-level agreements (SLAs).
Traffic Profile: Because excess packets are abruptly discarded, policing introduces packet loss and TCP retransmissions, resulting in a "sawtooth" or jagged egress traffic profile.
Resource Impact: Consumes minimal switch memory and introduces zero queuing latency for conforming traffic.
2. Traffic Shaping
Traffic shaping meters traffic and buffers excess packets in memory queues, delaying their transmission so that outgoing traffic leaves the interface at a steady, predictable rate:
Conforming Traffic: Forwarded immediately onto the wire.
Exceeding Traffic: Rather than being discarded, excess packets are placed into an egress shaping buffer and scheduled for transmission in subsequent time intervals.
Key Characteristics:
Buffering Required: Shaping relies entirely on packet buffers in switch memory.
Direction: Applied exclusively to egress traffic. A switch cannot shape incoming traffic because incoming packets have already arrived across the physical wire.
Traffic Profile: Produces a smooth, continuous traffic flow without artificial packet loss.
Trade-off: Prevents packet drops at the expense of introducing queuing delay (latency) and jitter . If sustained traffic exceeds the CIR for extended durations, the shaping buffer eventually exhausts and drops packets via tail drop.
Technical Comparison: Policing vs. Shaping
- Parameter Traffic Policing (Rate Limiting) Traffic Shaping
- Primary Mechanism Drops or re-marks non-conforming packets Buffers non-conforming packets in memory
- Supported Direction Ingress and Egress (primarily Ingress) Egress Only
- Packet Loss High (drops excess packets immediately) Very Low (packets buffered, not dropped)
- Delay / Jitter Zero additional delay for conforming traffic Introduces variable queuing delay and jitter
- Memory Consumption Negligible (no buffer required) High (requires dedicated queue buffers)
- Output Profile Jagged, bursty, sawtooth profile Smooth, predictable, continuous profile
- Typical Campus Use Guest Wi-Fi limits, edge port rate limits WAN edge links, sub-rate ISP handoffs
- AOS-CX Rate Limiting Syntax and Application
Aruba AOS-CX switches police traffic with classifier policies, shape egress traffic with qos shape , and cap specific traffic types with rate-limit .
Port Shaping
To smooth all egress traffic on a port below line rate, AOS-CX uses qos shape <rate> [kbps | percent] (for example a 1 Gbps port feeding a 200 Mbps WAN circuit): switch# configure
- switch(config)# interface 1/1/5
- switch(config-if)# description WAN-Handoff-200M
- switch(config-if)# qos shape 200000 kbps
- switch(config-if)# exit
- Advanced Class-Based Policing
For granular control, AOS-CX supports traffic classification policies combining access lists (ACLs), class maps, and policy maps: switch(config)# class ip Scavenger-Class
- switch(config-class-ip)# 10 match tcp any any eq 3724
- switch(config-class-ip)# 20 match udp any any eq 6881
- switch(config-class-ip)# exit
- switch(config)# policy Limit-Scavenger-Policy
- switch(config-policy)# 10 class ip Scavenger-Class action cir kbps 5000 cbs 64000 exceed drop
- switch(config-policy)# exit
- switch(config)# interface 1/1/20
- switch(config-if)# apply policy Limit-Scavenger-Policy in
- Layer 2 Flood Protection with Rate Limits
A Layer 2 Storm occurs when packets flood a local area network, consuming excessive bandwidth and overwhelming device processing capacity. Because Layer 2 Ethernet frames lack a Time-to-Live (TTL) field (unlike Layer 3 IP packets, which decrement TTL at every hop), looped frames circulate indefinitely until a physical link breaks or switch buffers collapse. +-------------------------------------------------------------------------+
- | RATE-LIMIT FLOOD SUPPRESSION |
- | |
- | Traffic Volume |
- | ^ |
- | | Storm Spike (Loop / Malfunctioning NIC) |
- | | /\ |
- | | / \ (DROPPED IN HARDWARE ASIC) |
- | ----+---------/----+---\---------------------------- <-- Storm Threshold|
- | | / \ \ |
- | | ~~~~~/~~~~~~~~\~~~\~~~~~ Legitimate Traffic |
- | | / \ (Forwarded Normally) |
- | 0 +---------------------------------------------> Time |
- +-------------------------------------------------------------------------+
- Storm Categories
Broadcast Storms: Caused by frames addressed to FF:FF:FF:FF:FF:FF (e.g., ARP requests, DHCP Discover messages). Switches must replicate broadcast frames out of every port in the VLAN. When an accidental physical loop is created without Spanning Tree, broadcast frames replicate exponentially, consuming 100% of link bandwidth within seconds.
Multicast Storms: Caused by frames addressed to Layer 2 multicast MAC addresses (e.g., 01:00:5E:xx:xx:xx for IPv4 multicast). Unregistered multicast traffic is flooded to all ports in the VLAN unless IGMP Snooping is active.
Unknown Unicast Storms: Occurs when a unicast frame arrives with a destination MAC address not currently present in the switch's MAC address forwarding table (CAM table). The switch must flood the frame to all ports in the VLAN. A storm can occur during MAC address table overflow attacks or asymmetric routing scenarios.
Rate-Limit Units
AOS-CX accepts kbps , percent , or pps . The two most common choices:
Packets Per Second (pps): The maximum number of frames permitted per second (e.g., 500 pps for broadcast). This is the preferred metric in campus networks because switch control planes are sensitive to the absolute packet rate rather than total byte volume.
Percentage of Interface Bandwidth (%): The maximum percentage of physical line rate permitted (e.g., 1.0% of link capacity). While intuitive, percentage thresholds scale drastically with interface speed: 1% of a 1 Gbps link equals 10 Mbps, whereas 1% of a 10 Gbps uplink equals 100 Mbps—which may still represent hundreds of thousands of broadcast packets per second.
AOS-CX Rate-Limit Configuration and Behavior
Rate limits are enforced in hardware on ingress , separately on each member of a LAG (AOS-CX 10.14 CLI Guide): switch# configure
- switch(config)# interface 1/1/1-1/1/24
- switch(config-if-<1/1/1-1/1/24>)# description User-Access-Ports
- switch(config-if-<1/1/1-1/1/24>)# rate-limit broadcast 1000 pps
- switch(config-if-<1/1/1-1/1/24>)# rate-limit multicast 2000 pps
- switch(config-if-<1/1/1-1/1/24>)# rate-limit unknown-unicast 1000 pps
- switch(config-if-<1/1/1-1/1/24>)# exit
- Alternatively, using percentage thresholds: switch(config)# interface 1/1/1
- switch(config-if)# rate-limit broadcast 1 percent
- Behavior When the Limit Is Exceeded
The hardware drops only the excess frames of that type and keeps forwarding traffic up to the limit, so essential ARP and DHCP still work.
The port stays up . AOS-CX rate-limit has no shutdown action; if you need a port to be disabled for a loop, use loop protection or BPDU guard.
The multicast limit also counts broadcast frames and Layer 2 BPDUs, and when broadcast and multicast limits are both set, broadcast traffic is limited to the lower value. Set multicast limits with care so spanning tree is not starved.
Root Cause Isolation and Storm Mitigation Best Practices
While storm control provides vital automated suppression, it acts as a safety barrier rather than a permanent cure. When storm control triggers, administrators must diagnose and resolve the underlying root cause.
Root Causes of Campus Storms
Physical Layer 2 Bridging Loops: An unmanaged desktop switch plugged into two separate wall jacks, or an accidental patch cable connecting two switch ports together without Spanning Tree Protocol (STP) enabled.
Malfunctioning Network Interface Cards (NICs): A degraded physical NIC or hypervisor virtual bridge entering a "jabber" state and transmitting continuous broadcast packets.
Software Bugs or Worms: Rogue malware scanning the local subnet via mass ARP requests or unconstrained Layer 2 service discovery broadcasts.
Multi-Layer Storm Protection Strategy
Always Enable STP and Protection Features: Storm control drops frames but does not break physical loops. Deploy Rapid Spanning Tree (RSTP / 802.1w) or Multiple Spanning Tree (MSTP / 802.1s), and enable BPDU Guard on all edge ports ( spanning-tree bpdu-guard ).
Deploy Loop Protection ( loop-protect ): On edge switches where unmanaged hubs or switches might discard BPDUs, configure loop-protect so the switch detects its own loop-detection frames and disables the looping port.
Monitor Rate-Limit Counters: show interface <port> qos shows each configured rate limit with forwarded and dropped packet and byte counters. switch# show interface 1/1/1 qos
- Interface 1/1/1 is up
- Admin state is up
- qos trust none (global)
- rate-limit broadcast 1000 pps (1000 actual)
- Forwarded Pkts Dropped Pkts
- Broadcast: 944468 1044