Storm Control Blocking Legitimate Broadcast Traffic
Presenting Symptom
Broadcast traffic such as ARP requests is being dropped on a switch port, causing hosts to fail to communicate across VLANs.
Network Context
A small branch office network with a Cisco Catalyst 2960 switch running IOS 15.0. The switch has storm-control configured on access ports to prevent broadcast storms. Recently, after a network change, legitimate broadcast traffic (e.g., ARP) is being blocked on a port connecting a workstation to the network, preventing the workstation from reaching the default gateway.
Diagnostic Steps
Check interface status and storm-control configuration
show storm-control interface gigabitEthernet 0/1Interface Gi0/1 Filter State: Active Broadcast: 500 pps (current), 1000 pps (max) Multicast: 500 pps (current), 1000 pps (max) Action: Shutdown
If the filter state is 'Active' and the current broadcast rate is near or above the configured threshold, storm-control may be dropping traffic. Note the action (shutdown or trap) to understand the behavior.
Check interface counters for dropped packets
show interface gigabitEthernet 0/1 | include broadcast|dropped Broadcast: 1500 packets
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 1500 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
0 output packets, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped outIf the broadcast count is high but the input rate is low, it may indicate that storm-control is dropping packets. However, the interface counters do not show storm-control drops directly; use 'show storm-control' to see drop counts.
Check storm-control drop counters
show storm-control gigabitEthernet 0/1 historyInterface Gi0/1 Broadcast: 500 pps (current), 1000 pps (max) Multicast: 500 pps (current), 1000 pps (max) Action: Shutdown Broadcast drop count: 200 Multicast drop count: 0
If the broadcast drop count is increasing, storm-control is actively dropping broadcast packets. This confirms that legitimate traffic is being blocked.
Check the current broadcast rate on the interface
show interface gigabitEthernet 0/1 | include rate5 minute input rate 1000 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec
Compare the input packet rate to the storm-control threshold. If the rate is below the threshold but drops are occurring, the threshold might be set too low for normal broadcast traffic.
Root Cause
The storm-control broadcast threshold on interface Gi0/1 is set too low (500 pps max) for the normal broadcast traffic in the network. The workstation generates ARP requests and other broadcasts that exceed this threshold, causing storm-control to drop the traffic. The action is set to 'shutdown', but in this case, the port is not shut down; instead, the traffic is being filtered (dropped) because the action is 'shutdown' only when the threshold is exceeded for a sustained period? Actually, the default action is to filter (drop) excess traffic, not shutdown. The output shows 'Action: Shutdown' which means the port will be errdisabled if the threshold is exceeded. However, the symptom indicates traffic is being dropped, not the port being shut down. So the root cause is that the broadcast threshold is too low, causing storm-control to drop legitimate broadcast packets.
Resolution
Verification
After applying the fix, verify that storm-control is no longer dropping broadcast traffic: ``` show storm-control gigabitEthernet 0/1 ``` Expected output: ``` Interface Gi0/1 Filter State: Inactive Broadcast: 200 pps (current), 2000 pps (max) Multicast: 500 pps (current), 1000 pps (max) Action: Trap Broadcast drop count: 200 (no longer incrementing) ``` Also verify that the workstation can now communicate: ``` ping 192.168.1.1 ``` Should succeed.
Prevention
["Set storm-control thresholds based on the normal broadcast traffic baseline for each port. Use the 'show storm-control' history to monitor typical rates.","Use the 'trap' action instead of 'shutdown' to avoid port errdisable; this allows monitoring without service disruption.","Implement storm-control only on ports where broadcast storms are a realistic threat, such as access ports connecting to end devices, and avoid overly restrictive thresholds."]
CCNA Exam Relevance
On the CCNA 200-301 exam, storm-control appears in the 'Security Fundamentals' section. Questions may present a scenario where a switch port is dropping traffic and ask to identify the cause (storm-control) and the corrective action. Expect multiple-choice questions about storm-control configuration, thresholds (percentage or PPS), and actions (shutdown, trap). The key fact: storm-control monitors broadcast, multicast, or unicast traffic and can drop or shut down the port when a threshold is exceeded.
Exam Tips
Remember that storm-control thresholds can be configured as a percentage of bandwidth or as packets per second (PPS). The default action is to filter (drop) excess traffic, not shutdown.
Be aware that 'show storm-control' displays the current rate and threshold; 'show storm-control history' shows drop counts.
In exam scenarios, if a port is dropping traffic but not errdisabled, check storm-control first. The fix is to increase the threshold or change the action.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions