13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting

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

---

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

1. 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.
2. 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.
3. 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

1. 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).
2. 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.
3. 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