5.1 Storm Control & Broadcast/Multicast Suppression

The Architecture and Hazards of Layer 2 Storms

In standard Ethernet networks, switches implement store-and-forward bridging dictated by the IEEE 802.1D standard. When an Ethernet frame enters an ingress switch port, the switch inspects its Layer 2 Media Access Control (MAC) header. If the Destination MAC (DMAC) address is a broadcast address (FF:FF:FF:FF:FF:FF), an unknown unicast address (a destination MAC not currently learned in the switch's local forwarding database), or a multicast address, the switch floods the frame out of every active interface within the frame's VLAN, excluding the ingress port. This fundamental forwarding behavior is referred to collectively as BUM traffic (Broadcast, Unknown Unicast, and Multicast).

Under normal operational conditions, BUM traffic constitutes a minuscule fraction of enterprise network bandwidth, supporting essential control-plane operations such as Address Resolution Protocol (ARP) queries, Dynamic Host Configuration Protocol (DHCP) solicitations, and Neighbor Discovery Protocol (NDP) in IPv6. However, when abnormal network conditions arise, BUM traffic can replicate uncontrollably, precipitating a catastrophic broadcast storm.

Primary Root Causes of Broadcast Storms

1. Physical or Logical Switching Loops: If Spanning Tree Protocol (STP/RSTP/MSTP) is misconfigured, disabled, or suppressed by unmanaged consumer switches or hubs plugged into edge access ports, redundant Layer 2 links create closed loops. Because standard Ethernet frames lack a Time-to-Live (TTL) field or hop-limit counter, every flooded broadcast frame circulates endlessly across redundant switches, multiplying exponentially with each pass.
2. Defective Host Network Interface Cards (NICs): A malfunctioning NIC, corrupted physical transceiver, or faulty device driver can begin transmitting continuous bursts of malformed broadcast or jabber frames at wire speed (often termed a "babbling node").
3. Denial-of-Service (DoS) Attacks and Worm Outbreaks: Malicious software or hostile actors may flood pseudo-random IP addresses or spoofed MAC addresses across a subnet, triggering continuous network-wide ARP broadcasting or MAC table exhaustion.

Network-Wide Degradation

When a broadcast storm develops, link utilization rapidly approaches 100% capacity across physical switch ports and inter-switch trunks. Switch packet buffers become exhausted, leading to tail-drop discards of legitimate unicast data traffic. Crucially, broadcast frames force every connected endpoint on the VLAN to interrupt its host CPU to decode and inspect the Layer 2 payload. In unmitigated storms, host CPUs peg at 100%, management sessions (SSH/SNMP) time out, routing protocol keepalives (OSPF/IS-IS/BGP) drop, and entire campus distribution fabrics become unresponsive.

---

Storm Control Mechanics & Ingress PFE Metering

To safeguard the switched fabric against devastating BUM flooding, Juniper Networks EX and QFX series switches implement Storm Control. Storm control is a hardware-enforced Layer 2 policing mechanism executed directly within the switch's Packet Forwarding Engine (PFE). Rather than waiting for frames to cross the switch backplane or overwhelm egress queues, storm control evaluates traffic rates immediately at the ingress MAC/PHY interface.

+-----------------------------------------------------------------------------------+
|                             Ingress Switch Interface                              |
+-----------------------------------------------------------------------------------+
                                          |
                                          v
                         +---------------------------------+
                         |   PFE Hardware Traffic Meter    |
                         +---------------------------------+
                                    /     |     \
                                   /      |      \
                      Broadcast   /   Multicast   \   Unknown Unicast
                      Frames     /     Frames      \     Frames
                                v         v         v
                         +---------------------------------+
                         |  Compare Rate Against Threshold |
                         +---------------------------------+
                                   /               \
               Traffic <= Threshold                 Traffic > Threshold
                         /                                   \
                        v                                     v
            +------------------------+             +------------------------+
            | Forward Frame across   |             | Action: Drop in PFE    |
            | Backplane / Active FDB |             | Hardware OR Shutdown   |
            +------------------------+             +------------------------+

BUM Traffic Classifications

Storm control allows network administrators to police traffic streams either collectively or independently:

• Broadcast Traffic: Frames destined for the Layer 2 broadcast MAC FF:FF:FF:FF:FF:FF (e.g., ARP requests, DHCP Discovers).
• Multicast Traffic: Frames carrying a multicast destination MAC address (the least significant bit of the first octet is set to 1, such as 01:00:5E:xx:xx:xx for IPv4 or 33:33:xx:xx:xx:xx for IPv6). Junos differentiates between unregistered multicast (multicast streams not currently tracked by IGMP snooping) and registered multicast.
• Unknown Unicast Traffic: Unicast frames whose destination MAC address has not yet been populated in the switch's Ethernet switching table (Filtering Database). When an unknown unicast frame ingresses, standard bridging floods it across all VLAN member ports; storm control meters this stream to prevent unicast flooding attacks from overwhelming links.

---

Junos ELS Storm Control Configuration

In Junos Enhanced Layer 2 Software (ELS) platforms (including the EX2300, EX3400, EX4300, EX4400, EX4600, and QFX5100/5120 series), storm control is configured through reusable profiles under the forwarding-options storm-control-profiles hierarchy. This modular approach contrasts with legacy non-ELS Junos switches (like the EX2200 and EX4200), which applied storm control settings directly under ethernet-switching-options.

Configuration Options for Rate Thresholds

Junos supports two primary metrics for defining storm control thresholds:

1. bandwidth-percentage: Defines the maximum allowable BUM traffic as a percentage (1 to 100) of the interface's current operational link speed. For example, on a 1 Gbps access port, a 10% threshold restricts BUM traffic to 100 Mbps.
2. bandwidth-level: Defines an explicit absolute throughput cap specified in kilobits per second (kbps), with supported limits determined by platform and release.

Defining Storm Control Profiles

Administrators can configure the rate threshold to apply to aggregate BUM traffic using the all keyword, or tailor individual limits for specific streams (broadcast, multicast, unknown-unicast):

[edit]
user@EX4400# set forwarding-options storm-control-profiles SC-ENTERPRISE-EDGE all bandwidth-percentage 10
user@EX4400# set interfaces ge-0/0/1 unit 0 family ethernet-switching recovery-timeout 300

The portable ELS example uses all. Per-stream exclusions and per-stream threshold support vary by switch family. Inspect the profile’s supported options before dividing broadcast, multicast and unknown-unicast into separate meters. Do not assume three independent meters exist merely because the traffic has three names.

Applying Profiles to Interfaces

Once defined, the profile is applied to the logical unit under the interface's family ethernet-switching configuration:

[edit]
user@EX4400# set interfaces ge-0/0/1 unit 0 family ethernet-switching storm-control SC-ENTERPRISE-EDGE
user@EX4400# set interfaces ge-0/0/2 unit 0 family ethernet-switching storm-control SC-ENTERPRISE-EDGE

Junos Default Behavior: Many EX factory configurations apply a default profile with an 80% threshold. Verify the actual configuration and platform: a factory example is not a guarantee that every interface has a profile. Choose thresholds from observed legitimate BUM load; 10% here is an example, not a universal recommendation.

---

Actions on Violation: Hardware Dropping vs. Interface Shutdown

When ingress BUM traffic crosses the threshold defined in the active profile, Junos OS can execute one of two distinct enforcement actions:

Hardware Drop Mechanics

Hardware dropping is the default violation action. Under this mode, the PFE token bucket meters ingress frames. If an endpoint generates 50 Mbps of broadcast traffic on a port configured for a 10 Mbps threshold, the PFE passes 10 Mbps of conforming broadcast frames and discards the excess 40 Mbps directly in hardware. The physical port remains link-up, and legitimate unicast data flows continue uninterrupted.

Interface Shutdown (action-shutdown)

In highly secure or mission-critical environments, a device generating a broadcast storm may indicate a rogue host or an unauthorized bridge. By configuring action-shutdown, the switch disables the port entirely:

[edit forwarding-options storm-control-profiles SC-ENTERPRISE-EDGE]
user@EX4400# set action-shutdown

When the threshold is breached:

1. The PFE flags the violation and alerts the Junos Routing Engine.
2. The switch transitions the physical port state to Down and marks the interface as disabled by storm control.
3. The switch logs a system log (syslog) alert detailing the interface name and violation timestamp.

Recovering from Action-Shutdown

Recovery procedures depend on the platform. Resolve the storm first, then use the documented error-clearing workflow or a configured recovery timer. On the ELS interface in this example, configure automatic recovery under the logical interface family:

[edit]
set interfaces ge-0/0/1 unit 0 family ethernet-switching recovery-timeout 180

The timer is an interface setting, not a child of the storm-control profile. Confirm its supported range and the shutdown condition on the device. Allowing automatic recovery without repairing a loop can repeatedly reconnect the same storm.

---

Operational Verification & Troubleshooting

Network engineers verify storm control operations and diagnose threshold breaches using dedicated Junos operational commands.

Monitoring Configuration, Interface State and Logs

Confirm the profile and its interface attachment before interpreting counters:

show configuration forwarding-options storm-control-profiles
show configuration interfaces ge-0/0/1 | display set
show interfaces ge-0/0/1 extensive
show log messages | match "storm|Storm"

Compare configured bandwidth with the actual link speed. A percentage threshold changes its absolute rate when the port negotiates a different speed. Check whether the profile uses action-shutdown, which traffic classes are excluded, and whether interface recovery-timeout is configured. If a port repeatedly recovers then shuts down again, investigate the source of excess traffic rather than repeatedly clearing the symptom.

Counter availability and command formatting depend on the switch. Use the device’s supported storm-control statistics where available and compare ingress/egress rates with controlled traffic. An interface-level error counter can remain zero when valid frames are dropped by a policy, so physical health does not prove that storm policing is inactive. Log messages can identify a shutdown event even when a generic interface view does not provide per-traffic-class policing counters.

Critical Exam Traps & Operational Caveats

• Trunk Ports vs. Access Ports: Best practice dictates applying restrictive storm control profiles primarily to edge access ports. Applying aggressive storm control profiles to core inter-switch trunk links can inadvertently discard legitimate BUM traffic aggregated from dozens of access switches.
• Unknown Unicast Suppression Pitfall: Suppressing unknown unicast traffic too aggressively (e.g., < 1%) can cause subtle packet loss during asymmetric routing scenarios, where return traffic flows over a path that has not recently refreshed the ingress switch's MAC address table.
• Profile Inheritance: If a profile is modified under forwarding-options storm-control-profiles, after commit, the change affects all interfaces bound to that profile without requiring interface restarts.

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

Official references checked 2026-10-18: Storm profiles, ELS application.