A municipal library consortium’s parking-garage switch is overwhelmed by broadcasts from a failing IoT NIC. What feature limits that storm on the access port?
Select an answer to reveal the explanation.
Short Explanation
Storm control is a volume knob on the port—when broadcasts scream past the threshold, the switch starts dropping them so one sick IoT NIC doesn’t take the garage switch down.
Full Explanation
Storm control monitors broadcast, multicast, and/or unknown unicast rates on a port and drops or shuts based on configured thresholds when a faulty NIC or loop generates a storm. On a municipal library parking-garage switch overwhelmed by broadcasts from a failing IoT NIC, storm control with broadcast thresholds is the feature that limits that storm on the access port.
DHCP option 82 insertion on core stacks supplies relay location metadata, not L2 storm limiting. BGP dampening of an IoT prefix on the WAN edge addresses route stability, not access-port broadcasts. RA Guard on trusted router ports filters IPv6 Router Advertisements, not IPv4/L2 broadcast storms from a failing endpoint.
Exam caveat: L2 broadcast storms → storm control on the access interface; do not reach for BGP or RA Guard first.
Operational check: set broadcast storm thresholds on garage access ports, test with a traffic generator or known-bad NIC, confirm suppression/shutdown behavior, and alert on violations for library IoT closets. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services.