Junos Storm Control Configuration for BUM Traffic

A traffic storm happens when broadcast, multicast or unknown unicast frames feed on each other until the LAN is saturated and switches become unresponsive. A single misconfigured NIC, a spanning-tree loop or a server spewing ARP requests can take an entire access closet offline in seconds. Junos storm control stops this by monitoring ingress traffic levels per port and dropping the controlled traffic types when a configured level is exceeded — and it can optionally shut the port down entirely. This article explains the storm control model on EX/QFX switches and how to configure profiles, levels and actions from the CLI.

Storm Control Basics

Storm control rate-limits three BUM traffic classes: broadcast, multicast, and unknown unicast. When the combined (or per-type) traffic exceeds the configured storm control level, the switch drops the excess packets. The factory default on ELS platforms enables storm control on all interfaces at 80 percent of available bandwidth; on MX routers it is disabled by default. A very common mistake is configuring a level higher than the interface bandwidth, which silently disables protection — Junos allows it, so double-check your numbers.

The three classes are worth distinguishing because they fail differently. Broadcast storms are usually a loop or a broken NIC and they multiply fast, because every frame is flooded to every port in the VLAN. Unknown unicast storms appear when the MAC table is incomplete or when the switch is flooded by traffic to addresses it has never learned — a symptom of a MAC table limit or a spanning-tree problem rather than a broken host. Multicast is the one to treat carefully: an unconfigured switch floods multicast like broadcast, so a misbehaving application that joins channels can look exactly like a broadcast storm while actually being legitimate video traffic.

Two ways to express a level exist. The modern method is an explicit bandwidth value in kbps or mbps, which is unambiguous and does not change when you recable a port to a faster speed. The older method is a percent of the port speed, which is convenient but couples your protection threshold to the link rate. On a 1 Gbps access port, 30 percent is 300 Mbps; on a 10 Gbps uplink the same 30 percent becomes 3 Gbps. When a port is upgraded overnight, the percentage silently loosens the protection, which is exactly why Juniper recommends the bandwidth form.

Storm control only ever counts ingress traffic on the port where the level is applied. It is a local, per-interface rate limiter, not a policer on the whole switch, and it does not police frames destined to the Routing Engine. That last point matters: a storm aimed at the control plane is not the problem storm control solves.

Configuration: Storm Control Profile

The modern way is a named profile with an explicit bandwidth level, applied to one interface or to all interfaces:

set ethernet-switching-options storm-control profile SC-LAN level bandwidth 100m
set interfaces xe-0/0/0 unit 0 family ethernet-switching storm-control profile SC-LAN

To apply the profile to every interface instead, use an interface range. This is the pattern for a uniform access layer where every port should be protected identically:

set interfaces interface-range ALL-ACCESS member ge-0/0/[0-23]
set ethernet-switching-options storm-control profile SC-ALL level bandwidth 200m
set interfaces interface-range ALL-ACCESS unit 0 family ethernet-switching storm-control profile SC-ALL

Levels can be configured as a bandwidth value (kbps/mbps) or as a percentage with the older level percent syntax, which Juniper recommends phasing out. You can also enable storm control selectively per traffic type, e.g. broadcast and unknown unicast only, leaving registered multicast alone:

set ethernet-switching-options storm-control profile SC-SELECTIVE level bandwidth 50m
set ethernet-switching-options storm-control profile SC-SELECTIVE
set interfaces ge-0/0/5 unit 0 family ethernet-switching storm-control profile SC-SELECTIVE

On non-ELS platforms the whole feature lives under [edit ethernet-switching-options] with a slightly different profile hierarchy, and there is no interface-range binding in the same way. Confirm which platform generation you are on before pasting a configuration between devices, because an EX4300 running ELS and an older EX4200 running the legacy syntax do not accept the same statements.

For ports that face an IP phone or a wireless access point, a higher level is defensible; for ports facing a hypervisor where a single guest can emit a storm, a lower level with shutdown action is the safer choice.

Port Shutdown and Autorecovery Actions

Instead of only dropping excess packets you can shut down or temporarily disable the interface when the limit is exceeded:

set ethernet-switching-options storm-control profile SC-HARD level bandwidth 50m
set ethernet-switching-options storm-control profile SC-HARD action-shutdown
set interfaces xe-0/0/1 unit 0 family ethernet-switching storm-control profile SC-HARD
set ethernet-switching-options port-error-disable recovery timeout 300

action-shutdown puts the port into an error-disabled state; the recovery timeout brings it back automatically after 300 seconds, which avoids a truck roll for a noisy access port. Without recovery configuration the port stays down until manually cleared — safer for core links, painful for access ports.

The trade-off between the two actions is the central design decision. Dropping excess frames preserves connectivity and lets good traffic through, at the cost of silently discarding frames that a protocol may depend on — a dropped ARP reply looks to the user like an intermittent fault. Shutting the port down is loud: the link goes down, the log records the reason, monitoring pages someone, and the loop is broken immediately. For edge ports where the source of the storm is a single misbehaving device, shutdown with autorecovery is the cleanest fix. For uplinks and server ports where a shutdown removes a whole rack, dropping is usually the lesser evil.

You can also pair the shutdown action with a filter or a log so the event is visible. A shut port with no alert is just an outage nobody understands, so make sure the reason appears in the log and, ideally, in your monitoring platform:

set interfaces xe-0/0/1 descriptions "access port - storm protected"
show log messages | match -i "storm|error-disabled|port-error-disable"

Verification and Platform Notes

show ethernet-switching storm-control
show interfaces xe-0/0/0 extensive | match storm
show interfaces xe-0/0/0 statistics
show ethernet-switching interfaces
show log messages | match STORM

Per-platform behavior matters: on most EX/QFX switches the level applies to the aggregate of the enabled streams per port, while on QFX10000 each stream is measured independently. That means the same numeric level can behave differently on two switches in the same closet, so describe the intent in the change document instead of the number alone.

Storm control on an aggregated Ethernet (AE) interface applies per member interface, not to the bundle as a whole — a 20 kbps limit on a two-member AE triggers only if one member exceeds 20 kbps. On a LAG with four members, the effective bound on the bundle is four times the configured level, which is rarely what the designer intended.

Also disable storm control on FCoE VLAN ports, and remember it does not police flows destined to the Routing Engine. On a port carrying storage or a lossless RoCE fabric, storm control misconfiguration is not a minor knob; dropping frames there causes retransmits or fabric resets that are far worse than the storm you were guarding against. Some platforms let you exclude the multicast class explicitly for exactly this reason.

For the loop-caused storm symptoms, pair this with broadcast storm troubleshooting and MAC flap loop detection. If you are chasing a PFC-driven stall rather than a classic L2 storm, PFC watchdog and storm detection mitigation covers the lossless Ethernet side. The companion article on reading the error fields in show interfaces extensive explains how to interpret the counters you will see after a storm.

Storm Control and Related Loop Protections

Storm control is a rate limiter, not a loop detector. It will not stop a loop from forming; it only limits how much damage the loop can do while it exists. That distinction explains why a well-built access layer uses several features together and why diagnosing a storm means knowing which one acted first.

Spanning Tree, BPDU guard and root guard prevent the loop from forming in the first place by blocking redundant paths and shutting an edge port that suddenly emits BPDUs. Storm control is the backstop for the loop that slipped through — a wiring patch that bypassed the design, a cheap unmanaged switch, or a NIC that has gone into a broadcast loop of its own. MAC limiting and port security, by contrast, bound the size of the MAC table and shut a port when too many addresses appear behind it, which is the right tool for unknown unicast storms caused by table exhaustion.

IGMP snooping deserves a mention in the multicast case. Without snooping, a switch floods multicast like broadcast and a single video stream looks like a storm; with snooping configured and a querier present, only interested ports receive the stream, and the multicast class in storm control becomes a genuine safety net rather than a limiter on ordinary traffic. If you exclude the multicast class from storm control, make sure snooping is actually working first.

show igmp snooping membership
show igmp snooping statistics
show ethernet-switching table

The practical order of operations during an incident is therefore: find out whether the loop still exists (BPDU guard log, STP state, MAC flapping counters), break it if it does, and only then decide whether the storm control level needs revisiting. Turning the meter up while the fault persists just moves the outage from the switch to the users.

A Complete Access-Layer Template

The following is a compact, defensible starting point for an access switch: a moderate level on every edge port, shutdown with autorecovery only where a single device is the likely source, and snooping left in control of multicast.

set ethernet-switching-options storm-control profile SC-EDGE level bandwidth 100m
set ethernet-switching-options storm-control profile SC-SERVER level bandwidth 500m
set ethernet-switching-options storm-control profile SC-SERVER action-shutdown
set ethernet-switching-options port-error-disable recovery timeout 600

set interfaces interface-range EDGE-PORTS member ge-0/0/[0-19]
set interfaces interface-range EDGE-PORTS unit 0 family ethernet-switching storm-control profile SC-EDGE
set interfaces interface-range EDGE-PORTS unit 0 family ethernet-switching port-mode access

set interfaces ge-0/0/20 unit 0 family ethernet-switching storm-control profile SC-SERVER

Note the deliberate asymmetry: the edge range drops excess frames so ordinary clients stay connected, while the server port also shuts down because a hypervisor or a backup agent emitting a storm will keep doing so until the link is taken away. Pair the whole block with BPDU guard on the edge ports and a logging filter that matches the storm message, and the switch stops being the weakest link in the access layer.

Design Guidance and Troubleshooting

• Set a level, always. Relying on the 80 percent default means a storm is allowed to consume most of the link before anything happens; pick a number that reflects what the port is actually for.
• Prefer bandwidth over percent. A link upgrade should not change your protection threshold.
• Log and monitor the event. A silently dropped storm is indistinguishable from an application bug during triage.
• Do not stack shutdown with a short timeout on uplinks. Repeated flaps cause spanning-tree churn across the whole topology.
• Test the threshold. Generate known broadcast traffic on a lab port and confirm both the drop and, if configured, the shutdown plus recovery.

When a port error-disables, the sequence to follow is: check the log line for the reason, confirm a physical or logical loop, clear the condition if the loop is fixed, then clear the interface with clear ethernet-switching port-error or simply wait for the recovery timer. Raising the level to make the symptom disappear is the classic wrong answer — it treats the meter, not the fault.

原文链接：Juniper: Understanding storm control