Hands-On Lab: Configuring Storm Control

This hands-on lab configures storm control thresholds on a switch port to limit broadcast and multicast traffic, simulating a broadcast storm and verifying the switch suppresses excess traffic before it can overwhelm the network.

Storm Control ConfigurationBroadcast SuppressionTraffic Threshold Percentage

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure storm control on a switch port with a broadcast traffic threshold, simulate a broadcast storm exceeding that threshold, and verify the switch suppresses the excess traffic rather than forwarding it unchecked.

Lab Purpose

Spanning Tree, covered extensively earlier in this series, prevents the Layer 2 loops that typically cause broadcast storms, but it offers no protection against a single misbehaving device or NIC that floods broadcast traffic without any loop being present at all. Storm control provides a direct traffic-rate safety net independent of loop prevention.

Lab Topology

Switch1 ---- Gi1/0/8 ---- PC-A (traffic source)

Task 1: Configure Broadcast Storm Control

Configure storm control on Gi1/0/8 to limit broadcast traffic to 20% of available bandwidth.

Task 2: Verify Baseline Configuration

Confirm the storm control threshold is correctly applied.

Task 3: Simulate Normal Broadcast Traffic

Generate a modest amount of broadcast traffic (well under the threshold) and confirm it passes through unaffected.

Task 4: Simulate an Excessive Broadcast Storm

Generate broadcast traffic exceeding the configured 20% threshold and verify the switch suppresses the excess.

Task 5: Verify Suppression Statistics

Check the interface counters confirming storm control action was taken.

Solution and Verification

Switch1(config)# interface gigabitethernet1/0/8
Switch1(config-if)# storm-control broadcast level 20.00

Switch1# show storm-control gigabitethernet1/0/8 broadcast

Interface  Filter State   Level   Current
---------  -------------  ------  -------
Gi1/0/8    Forwarding     20.00%  0.00%
-- Confirms the threshold is applied, with
-- current broadcast traffic well below it

-- Modest broadcast traffic generated,
-- staying under 20% of link bandwidth:

Switch1# show storm-control gigabitethernet1/0/8 broadcast

Interface  Filter State   Level   Current
---------  -------------  ------  -------
Gi1/0/8    Forwarding     20.00%  8.20%
-- Still forwarding normally, current
-- level remains below threshold

-- Simulated broadcast storm exceeding 20%
-- generated from PC-A:

Switch1# show storm-control gigabitethernet1/0/8 broadcast

Interface  Filter State   Level   Current
---------  -------------  ------  -------
Gi1/0/8    Blocking       20.00%  34.50%
-- Filter State changed to "Blocking" --
-- the switch is now actively dropping
-- broadcast traffic above the threshold
-- on this port, rather than forwarding
-- everything it receives

Switch1# show interfaces gigabitethernet1/0/8 counters broadcast

Port          Broadcast
Gi1/0/8       184521
-- The broadcast counter confirms
-- significant broadcast volume was seen
-- and partially suppressed by storm control

Key Takeaway

Storm control operates entirely independently of Spanning Tree and loop detection — it protects against excessive broadcast, multicast, or unicast traffic regardless of the cause, whether a genuine Layer 2 loop, a malfunctioning NIC, or a misbehaving application flooding traffic, making it a useful complementary safeguard even on a topology where STP has already eliminated all loops.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه