Storm Control & Traffic Shaping — Protecting Switches from Broadcast, Multicast & Unicast Floods

A broadcast storm is one of the most destructive events that can occur in a switched network — and one of the easiest to trigger accidentally. A single misconfigured host continuously broadcasting ARP requests, a looping network interface card (NIC), or a Spanning Tree failure can generate millions of frames per second. Every switch in the broadcast domain forwards these frames out every port in the VLAN, consuming 100% of available bandwidth within milliseconds. Routers, servers, and all connected devices are overwhelmed processing frames they did not request. The network collapses.

Cisco Catalyst switches provide storm control as a hardware-level safeguard: a configurable threshold on each port that monitors the rate of broadcast, multicast, and unknown unicast traffic. When the rate exceeds the threshold, the switch either drops the excess frames (filter action) or shuts the port down (shutdown action) — stopping the storm at its source before it propagates through the network. Storm control operates in hardware at line rate with no performance impact on normal traffic below the threshold.

This lab also covers traffic shaping and traffic policing concepts — the QoS mechanisms used on router interfaces to control bandwidth consumption in the WAN direction. While storm control protects against unexpected traffic bursts at Layer 2, traffic shaping and policing provide deliberate rate-limiting at Layer 3 for Service Level Agreement (SLA) enforcement, congestion management, and cost control on metered links. For the broader QoS framework that shaping fits into see MQC (Modular QoS CLI) Basics and DSCP Marking & Classification. For related Layer 2 security hardening alongside storm control see Private VLANs and DHCP Snooping.

1. Core Concepts — Storms, Storm Control, and Traffic Shaping

What Causes a Network Storm?

  THREE TYPES OF STORMS STORM CONTROL PROTECTS AGAINST:

  ┌──────────────────────────────────────────────────────────────────────┐
  │  BROADCAST STORM                                                     │
  │  Source: ARP floods, looping NICs, STP failure, DHCP storms,        │
  │          broadcast-based malware (NetBIOS, smurf amplification)      │
  │  Behaviour: Frame sent to FF:FF:FF:FF:FF:FF — every switch in the   │
  │             broadcast domain forwards it out every port in the VLAN  │
  │  Impact: Saturates every port, every device processes every frame    │
  │          CPU utilisation spikes to 100% across all hosts             │
  │  Detection: storm-control broadcast level [rising] [falling]         │
  └──────────────────────────────────────────────────────────────────────┘

  ┌──────────────────────────────────────────────────────────────────────┐
  │  MULTICAST STORM                                                     │
  │  Source: Misconfigured multicast applications, mDNS floods,         │
  │          IGMP snooping disabled (all multicast treated as broadcast) │
  │  Behaviour: Frame sent to 01:xx:xx:xx:xx:xx — flooded to all ports  │
  │             in VLAN when IGMP snooping is not controlling it         │
  │  Impact: Similar to broadcast — all ports flooded with unwanted      │
  │          multicast, high CPU on hosts receiving unwanted streams     │
  │  Detection: storm-control multicast level [rising] [falling]         │
  └──────────────────────────────────────────────────────────────────────┘

  ┌──────────────────────────────────────────────────────────────────────┐
  │  UNKNOWN UNICAST (FLOODING) STORM                                   │
  │  Source: MAC table overflow attack (filling MAC table with fake      │
  │          MACs forces all unicast to flood), link flapping causing    │
  │          MAC table aging, asymmetric routing causing unknown DA      │
  │  Behaviour: Frame with unknown destination MAC is flooded to all     │
  │             ports in the VLAN — same as broadcast from switch's POV  │
  │  Impact: Confidential unicast traffic visible on all ports (security │
  │          risk), bandwidth saturation, CPU impact                     │
  │  Detection: storm-control unicast level [rising] [falling]           │
  └──────────────────────────────────────────────────────────────────────┘

Storm Control — How It Works

  MEASUREMENT WINDOW:
    Storm control measures traffic over a 1-second hardware window.
    Within each 1-second interval, the switch counts the number of
    broadcast/multicast/unicast frames received on the port.

  THRESHOLD COMPARISON:
    At the end of each window, the measured rate is compared to the
    configured rising threshold.

    If rate > rising threshold  → ACTION triggered (drop or shutdown)
    If rate < falling threshold → Storm cleared (port re-enabled)

  RISING vs FALLING THRESHOLDS:
    Rising threshold:  the level at which storm control activates
    Falling threshold: the level at which storm control deactivates
                       (hysteresis — prevents rapid on/off cycling)

    If only rising threshold is specified, falling = rising (no hysteresis)

  THRESHOLD UNITS (three measurement methods):
    Percentage:  % of the port's configured bandwidth
                 storm-control broadcast level 20    (20% of port BW)
    BPS:         bits per second absolute value
                 storm-control broadcast level bps 1000000    (1 Mbps)
    PPS:         packets per second (frames per second)
                 storm-control broadcast level pps 1000       (1000 pps)

  ACTIONS (what happens when threshold is exceeded):
    Default (no action configured): drop excess frames silently
    shutdown:   err-disable the port (must be manually re-enabled
                or auto-recovery configured)
    trap:       send SNMP trap — log the event but continue forwarding
                (no traffic drop)
    shutdown + trap: err-disable AND send SNMP trap

Traffic Shaping vs Traffic Policing — Key Distinctions

Feature	Traffic Policing	Traffic Shaping
Action on excess traffic	Drop or re-mark immediately — no buffering	Buffer (queue) excess traffic, release when rate falls below limit
Burst handling	Bursts above the rate are dropped immediately — hard enforcement	Bursts are absorbed into the queue — smoothed output rate
Latency impact	No added latency (drop/forward decision is immediate)	Adds latency — buffered packets wait in queue
Typical use	ISP ingress policing, access layer enforcement, protecting against abuse	WAN egress rate limiting, conforming to committed information rate (CIR)
IOS mechanism	`police rate [bps] burst [bytes]` in policy-map	`shape average [bps]` in policy-map
Direction	Both ingress and egress	Egress only (you cannot shape incoming traffic)
Token bucket	Single token bucket — tokens not accumulated beyond burst	Dual token bucket (Bc + Be) — committed + excess burst
Storm control relationship	Storm control is ingress policing at Layer 2 (hardware-level)	Shaping is Layer 3 software-based egress queuing

Storm Control vs QoS Policing: Storm control is a Layer 2 hardware mechanism specifically for protecting against unexpected traffic floods. It operates on individual switch ports in hardware at line rate. QoS traffic policing (via MQC policy-maps) is a more flexible Layer 3 software mechanism for enforcing rate limits on specific traffic classes defined by DSCP, ACL, or protocol. Both can be applied simultaneously — storm control as the first line of defence against floods, and QoS policing for fine-grained rate enforcement on classified traffic.

2. Lab Topology

                   ┌──────────────────────────────────────────────────┐
                   │           NetsTuts_SW1 (Catalyst 3560/3750)      │
                   │                                                  │
  Gi0/1 ──── R1   │  Gi0/1  UPLINK — Promiscuous / Trusted uplink    │
  (Trusted)        │         No storm control (or high threshold)     │
                   │                                                  │
  Fa0/1 ── PC-A   │  Fa0/1  ACCESS — User workstation (VLAN 10)      │
  VLAN 10          │         Storm control: broadcast 20%, MC 10%     │
                   │         Action: shutdown + trap                  │
  Fa0/2 ── PC-B   │  Fa0/2  ACCESS — User workstation (VLAN 10)      │
  VLAN 10          │         Same storm control policy as Fa0/1       │
                   │                                                  │
  Fa0/3 ── SRV    │  Fa0/3  ACCESS — Server port (VLAN 20)           │
  VLAN 20          │         Storm control: broadcast 10%, MC 5%      │
                   │         Action: shutdown (strict)                │
  Fa0/4 ── IoT    │  Fa0/4  ACCESS — IoT / High-risk device (VLAN 30)│
  VLAN 30          │         Storm control: broadcast 5%, MC 3%,      │
                   │         unicast 10% (tightest policy)            │
                   │         Action: shutdown + trap                  │
  Fa0/5 ── SFP    │  Fa0/5  TRUNK — Inter-switch uplink              │
  (Trunk)          │         Storm control: broadcast 30% (relaxed    │
                   │         threshold for aggregated trunk traffic)  │
                   └──────────────────────────────────────────────────┘

  Storm Control Policies:
    User access ports  (Fa0/1, Fa0/2): moderate thresholds, action=shutdown+trap
    Server ports       (Fa0/3):        strict thresholds,   action=shutdown
    IoT / risk ports   (Fa0/4):        tightest thresholds, all three storm types
    Trunk uplinks      (Fa0/5):        relaxed thresholds,  no shutdown
    Trusted uplinks    (Gi0/1):        no storm control (or very high threshold)

3. Step 1 — Baseline Verification Before Configuration

Check Default Storm Control State

! ── By default, storm control is DISABLED on all ports ──────────
NetsTuts_SW1#show storm-control
Interface  Filter State   Upper  Lower  Current
---------  -------------  -----  -----  -------
! ── Empty output — no storm control configured anywhere ──────────

! ── Check a specific interface ───────────────────────────────────
NetsTuts_SW1#show storm-control FastEthernet0/1
Interface  Filter State   Upper  Lower  Current
---------  -------------  -----  -----  -------
Fa0/1      Forwarding      0.00%  0.00%    0.00%  broadcast
Fa0/1      Forwarding      0.00%  0.00%    0.00%  multicast
Fa0/1      Forwarding      0.00%  0.00%    0.00%  unicast

! ── 0.00% / 0.00% = storm control disabled (no threshold set) ────
! ── "Forwarding" = normal forwarding state ────────────────────────

! ── Check interface counters before making changes ───────────────
NetsTuts_SW1#show interfaces FastEthernet0/1
FastEthernet0/1 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0c1a.2b3c.0001
  ...
  5 minute input rate 1234000 bits/sec, 145 packets/sec
  5 minute output rate 456000 bits/sec, 87 packets/sec
     123456 packets input, 98765432 bytes, 0 no buffer
     Received 5432 broadcasts (2134 multicasts)    ← current broadcast count
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     0 packets output, 0 bytes, 0 underruns

! ── Note existing broadcast count as baseline ────────────────────

The baseline check is important for two reasons: (1) it confirms the current traffic profile on each port so you can set appropriate thresholds (a threshold of 20% is meaningless if the port currently runs 25% broadcast in normal operation), and (2) it establishes a reference point for before/after comparison. The show interfaces broadcast counter gives a cumulative count — use the 5-minute rate from show interfaces to understand the current traffic mix before setting thresholds.

Understand the Port Bandwidth for Threshold Calculation

! ── Check interface bandwidth (used as base for % thresholds) ────
NetsTuts_SW1#show interfaces FastEthernet0/1 | include BW
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
! ── BW = 100 Mbps for FastEthernet
! ── 20% threshold = 20% of 100 Mbps = 20 Mbps broadcast allowed

NetsTuts_SW1#show interfaces GigabitEthernet0/1 | include BW
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
! ── BW = 1 Gbps for GigabitEthernet
! ── 20% threshold = 20% of 1000 Mbps = 200 Mbps broadcast allowed

The percentage threshold is calculated against the interface's configured bandwidth, not the physical line rate. On a 100 Mbps FastEthernet port, a 20% broadcast threshold allows up to 20 Mbps of broadcast traffic before the action triggers. On a 1 Gbps GigabitEthernet port with the same 20% threshold, the allowed broadcast rate is 200 Mbps — 10x more in absolute terms. For high-speed ports where an absolute limit is more meaningful than a percentage, use the bps or pps threshold format instead.

4. Step 2 — Configure Storm Control on User Access Ports

Fa0/1 and Fa0/2 — User Workstation Ports (VLAN 10)

! ══════════════════════════════════════════════════
! Fa0/1 — User workstation port, moderate policy
! ══════════════════════════════════════════════════
NetsTuts_SW1(config)#interface FastEthernet0/1
NetsTuts_SW1(config-if)#description PC-A-VLAN10-Storm-Control

! ── Broadcast: rising 20%, falling 10% (hysteresis) ─────────────
NetsTuts_SW1(config-if)#storm-control broadcast level 20 10
!                                               ^^  ^^
!                                        rising  falling threshold

! ── Multicast: rising 10%, falling 5% ───────────────────────────
NetsTuts_SW1(config-if)#storm-control multicast level 10 5

! ── Action: shutdown the port + send SNMP trap ───────────────────
NetsTuts_SW1(config-if)#storm-control action shutdown
NetsTuts_SW1(config-if)#storm-control action trap
NetsTuts_SW1(config-if)#exit

! ══════════════════════════════════════════════════
! Fa0/2 — Apply same policy (or use range command)
! ══════════════════════════════════════════════════
NetsTuts_SW1(config)#interface FastEthernet0/2
NetsTuts_SW1(config-if)#description PC-B-VLAN10-Storm-Control
NetsTuts_SW1(config-if)#storm-control broadcast level 20 10
NetsTuts_SW1(config-if)#storm-control multicast level 10 5
NetsTuts_SW1(config-if)#storm-control action shutdown
NetsTuts_SW1(config-if)#storm-control action trap
NetsTuts_SW1(config-if)#exit

! ── Apply to a range of ports simultaneously ─────────────────────
NetsTuts_SW1(config)#interface range FastEthernet0/1 - 2
NetsTuts_SW1(config-if-range)#storm-control broadcast level 20 10
NetsTuts_SW1(config-if-range)#storm-control multicast level 10 5
NetsTuts_SW1(config-if-range)#storm-control action shutdown
NetsTuts_SW1(config-if-range)#storm-control action trap
NetsTuts_SW1(config-if-range)#exit

The rising/falling threshold pair (20/10 for broadcast) creates hysteresis — once a storm drives the port to shutdown, the port does not re-enable until the broadcast rate drops below 10%. Without a falling threshold (configuring just level 20), the falling threshold equals the rising threshold (20/20), which can cause rapid oscillation: the port shuts down when broadcast exceeds 20%, the shutdown stops the storm, the rate immediately drops below 20%, the port re-enables, broadcasts resume, rate exceeds 20% again, port shuts down again. The falling threshold prevents this flapping by requiring the rate to drop significantly before re-enabling.

Alternative Threshold Formats — BPS and PPS

! ── BPS format — absolute bits per second ────────────────────────
NetsTuts_SW1(config)#interface FastEthernet0/1
NetsTuts_SW1(config-if)#storm-control broadcast level bps 10000000 5000000
!                                               ^^      rising       falling
!                                           10 Mbps rising, 5 Mbps falling

! ── PPS format — packets (frames) per second ─────────────────────
NetsTuts_SW1(config-if)#storm-control broadcast level pps 1000 500
!                                               ^^    1000 pps rising, 500 pps falling

! ── Common use cases for each format:
! Percentage: Simple relative limits — good for mixed-speed ports
!             and when you want "20% of whatever bandwidth the port has"
! BPS:        Absolute rate limits — good for high-speed GigE/10GigE
!             ports where percentage produces very high absolute values
!             (20% of 10Gbps = 2Gbps broadcast — probably too much)
! PPS:        Frame count limits — good for protecting CPU-bound
!             devices (routers, firewalls) that process frames in
!             hardware at a maximum packets-per-second rate

5. Step 3 — Configure Storm Control on Server and IoT Ports

Fa0/3 — Server Port (VLAN 20) — Strict Policy

! ── Server ports should have tighter thresholds ──────────────────
! ── Servers rarely generate legitimate broadcast storms ───────────
NetsTuts_SW1(config)#interface FastEthernet0/3
NetsTuts_SW1(config-if)#description Server-VLAN20-Strict
NetsTuts_SW1(config-if)#storm-control broadcast level 10 5
NetsTuts_SW1(config-if)#storm-control multicast level 5 2
! ── Action: shutdown only (no SNMP trap to reduce noise on servers
!    that may generate moderate multicast for heartbeat traffic) ───
NetsTuts_SW1(config-if)#storm-control action shutdown
NetsTuts_SW1(config-if)#exit

Fa0/4 — IoT / High-Risk Device Port (VLAN 30) — Tightest Policy

! ── IoT devices are high-risk storm sources — malware, loops, ────
! ── misconfigured firmware can generate floods quickly ────────────
NetsTuts_SW1(config)#interface FastEthernet0/4
NetsTuts_SW1(config-if)#description IoT-VLAN30-Tight-Policy

! ── All three storm types protected ──────────────────────────────
NetsTuts_SW1(config-if)#storm-control broadcast level 5 2
NetsTuts_SW1(config-if)#storm-control multicast level 3 1
NetsTuts_SW1(config-if)#storm-control unicast level 10 5

! ── Unicast flooding protection is important for IoT ─────────────
! ── IoT malware often uses MAC table flooding as an attack vector ─
! ── (fills MAC table → all unicast floods → traffic interception) ─

NetsTuts_SW1(config-if)#storm-control action shutdown
NetsTuts_SW1(config-if)#storm-control action trap
NetsTuts_SW1(config-if)#exit

Unknown unicast storm control (the unicast keyword) is the most underused of the three types. Unknown unicast flooding occurs when the destination MAC is not in the switch's MAC address table — the switch floods the frame to all ports in the VLAN. A MAC address table overflow attack deliberately sends frames with thousands of spoofed source MAC addresses, filling the MAC table (typically 8,000–32,000 entries) until it overflows. Once full, the switch cannot learn new MACs and starts flooding all unicast traffic — turning the switch into a hub. An attacker connected to any port in the VLAN can then capture all traffic intended for other devices. Unknown unicast storm control detects and stops this attack by rate-limiting the flooding rate. For direct MAC address-based port protection see Port Security & Sticky MAC.

Fa0/5 — Inter-Switch Trunk — Relaxed Policy

! ── Trunk ports carry aggregated traffic from many VLANs ─────────
! ── Normal broadcast rates are higher on trunks — relax threshold ─
! ── Shutdown action is NOT appropriate for trunk uplinks ──────────
! ── (shutting down a trunk brings down the entire connected segment)
NetsTuts_SW1(config)#interface FastEthernet0/5
NetsTuts_SW1(config-if)#description Trunk-to-SW2-Storm-Relaxed
NetsTuts_SW1(config-if)#storm-control broadcast level 30 20
NetsTuts_SW1(config-if)#storm-control multicast level 20 10
! ── Action: trap only — log the event but DO NOT shut down trunk ──
NetsTuts_SW1(config-if)#storm-control action trap
NetsTuts_SW1(config-if)#exit

Configuring storm-control action shutdown on a trunk uplink is a classic misconfiguration. A legitimate traffic burst (large file transfer, video multicast, backup job) could trigger the threshold and shut down the trunk port, disconnecting all downstream switches. On trunk ports, use trap only — or apply storm control without any action (drops excess silently). If the upstream trunk is truly experiencing a storm-level broadcast event, the root cause is almost always a loop (STP failure) or a connected device — address the root cause rather than shutting the trunk.

6. Step 4 — err-disable and Auto-Recovery Configuration

When storm control triggers the shutdown action, the port enters err-disable state — it is effectively shut down by the system and will not return to service until manually re-enabled (or until auto-recovery is configured). Understanding err-disable is critical for production deployments.

What Happens When Storm Control Triggers Shutdown

! ── Console message when storm control shuts a port down ─────────
%STORM_CONTROL-3-SHUTDOWN: A packet storm was detected on Fa0/1.
  The interface has been disabled.
%LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
  changed state to down

! ── The port is now in err-disable state ─────────────────────────
NetsTuts_SW1#show interfaces FastEthernet0/1
FastEthernet0/1 is err-disabled     ← ❌ err-disable state

NetsTuts_SW1#show interfaces FastEthernet0/1 status
Port      Name               Status       Vlan  Duplex  Speed  Type
Fa0/1     PC-A-VLAN10        err-disabled 10    auto    auto   10/100BaseTX

! ── Verify err-disable reason ────────────────────────────────────
NetsTuts_SW1#show errdisable recovery
ErrDisable Reason                     Timer Status
-----------------                     --------------
arp-inspection                        Disabled
bpduguard                             Disabled
channel-misconfig (STP)               Disabled
dhcp-rate-limit                       Disabled
dtp-flap                              Disabled
l2ptguard                             Disabled
link-flap                             Disabled
pagp-flap                             Disabled
psecure-violation                     Disabled
security-violation                    Disabled
storm-control                         Disabled    ← currently disabled
udld                                  Disabled
vmps                                  Disabled
...
Timer interval: 300 seconds

Manual Recovery — Re-enable the Port

! ── Manual re-enable: shut → no shut ─────────────────────────────
NetsTuts_SW1(config)#interface FastEthernet0/1
NetsTuts_SW1(config-if)#shutdown
NetsTuts_SW1(config-if)#no shutdown
NetsTuts_SW1(config-if)#exit

! ── Verify port is back up ───────────────────────────────────────
NetsTuts_SW1#show interfaces FastEthernet0/1 status
Port      Name               Status       Vlan  Duplex  Speed
Fa0/1     PC-A-VLAN10        connected    10    a-full  100
! ── Port is operational again ────────────────────────────────────

! ── If the storm source is still active, the port will immediately
! ── go back into err-disable when the threshold is exceeded again ─

Automatic err-disable Recovery

! ── Enable automatic recovery for storm-control err-disable ──────
! ── After the timer expires, the port automatically tries to come up
NetsTuts_SW1(config)#errdisable recovery cause storm-control
NetsTuts_SW1(config)#errdisable recovery interval 60
!                                                   ^^
!                             recovery attempt after 60 seconds (default 300)

! ── Verify auto-recovery is configured ───────────────────────────
NetsTuts_SW1#show errdisable recovery
ErrDisable Reason                     Timer Status
-----------------                     --------------
storm-control                         Enabled   ← ✓ now enabled
...
Timer interval: 60 seconds

! ── Recommended approach for access ports:
!    - Enable auto-recovery so a storm source (e.g., infected PC)
!      causes a brief outage rather than permanent shutdown
!    - The port comes back after 60 seconds
!    - If the storm is still happening, it shuts down again
!    - SNMP trap alerts the NOC to investigate
!
! ── NOT recommended for server ports:
!    - Servers should be manually investigated before re-enabling
!    - A misconfigured server generating a storm should be fixed,
!      not automatically re-enabled every 60 seconds

The decision to use auto-recovery versus manual recovery depends on the port type and the operational environment. For user workstation ports, auto-recovery with a short interval (60 seconds) balances protection against storms with user productivity — the port comes back automatically if the brief storm was caused by a transient condition (ARP flood during boot, etc.). For server, infrastructure, and IoT ports, manual recovery is preferred — forcing an administrator to investigate the root cause before the port returns to service.

7. Traffic Shaping & Policing on Router Interfaces (MQC)

While storm control operates at Layer 2 on switch ports, traffic shaping and policing operate at Layer 3 on router interfaces — typically on WAN-facing links where bandwidth is limited and must be managed carefully. Both use the Modular QoS CLI (MQC) framework: define a class-map to classify traffic, a policy-map to apply the rate action, and a service-policy to attach it to an interface.

Traffic Shaping — Smooth Egress Rate

! ══════════════════════════════════════════════════════
! Scenario: WAN link is 10 Mbps committed (CIR) but
! physical interface is 100 Mbps FastEthernet.
! Shape egress to 10 Mbps to avoid dropping at the ISP.
! ══════════════════════════════════════════════════════

! ── Step 1: Define a class-map for traffic to be shaped ──────────
NetsTuts_R1(config)#class-map match-any ALL-TRAFFIC
NetsTuts_R1(config-cmap)#match any
NetsTuts_R1(config-cmap)#exit

! ── Step 2: Create a policy-map with shape average ───────────────
NetsTuts_R1(config)#policy-map SHAPE-TO-10MBPS
NetsTuts_R1(config-pmap)#class ALL-TRAFFIC
NetsTuts_R1(config-pmap-c)#shape average 10000000
!                                         ^^^^^^^^
!                              10,000,000 bps = 10 Mbps
!                              (value is always in bits per second)
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

! ── Step 3: Apply to WAN interface (egress direction) ────────────
NetsTuts_R1(config)#interface Serial0/0/0
NetsTuts_R1(config-if)#description WAN-Link-to-ISP
NetsTuts_R1(config-if)#service-policy output SHAPE-TO-10MBPS
NetsTuts_R1(config-if)#exit

! ── Verify shaping ───────────────────────────────────────────────
NetsTuts_R1#show policy-map interface Serial0/0/0
  Serial0/0/0

  Service-policy output: SHAPE-TO-10MBPS

    Class-map: ALL-TRAFFIC (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any

      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Bit Rate      Limit  bits/int  bits/int    (ms)       (bytes)
           10000000/10000000 18750    12500       0       100        15625
                 ↑
           Shaping to 10 Mbps confirmed

      Packets Matched  : 0
      Bytes Matched    : 0
      Packets Delayed  : 0
      Bytes Delayed    : 0
      Shaping Active   : false

Traffic Policing — Hard Rate Enforcement

! ══════════════════════════════════════════════════════
! Scenario: Police inbound traffic from a customer to
! their contracted 5 Mbps CIR. Traffic above CIR
! is dropped. Traffic above CIR + burst is dropped.
! ══════════════════════════════════════════════════════

! ── Class-map to match the customer's traffic ────────────────────
NetsTuts_R1(config)#class-map match-any CUSTOMER-TRAFFIC
NetsTuts_R1(config-cmap)#match access-group name CUSTOMER-ACL
NetsTuts_R1(config-cmap)#exit

NetsTuts_R1(config)#ip access-list extended CUSTOMER-ACL
NetsTuts_R1(config-ext-nacl)#permit ip 10.10.10.0 0.0.0.255 any
NetsTuts_R1(config-ext-nacl)#exit

! ── Policy-map: police at 5 Mbps CIR, 10 KB burst ────────────────
NetsTuts_R1(config)#policy-map POLICE-5MBPS
NetsTuts_R1(config-pmap)#class CUSTOMER-TRAFFIC
NetsTuts_R1(config-pmap-c)#police rate 5000000 bps burst 10000 byte
!                                       ^^^^^^^       ^^^^^
!                                  5 Mbps CIR     10 KB burst (Bc)
NetsTuts_R1(config-pmap-c)# conform-action transmit
!                              ↑ traffic within CIR: forward
NetsTuts_R1(config-pmap-c)# exceed-action drop
!                              ↑ traffic above CIR: drop
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

! ── Apply inbound (police ingress traffic from customer) ─────────
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#description Customer-Facing-Port
NetsTuts_R1(config-if)#service-policy input POLICE-5MBPS
NetsTuts_R1(config-if)#exit

! ── Verify policing ──────────────────────────────────────────────
NetsTuts_R1#show policy-map interface GigabitEthernet0/1 input
  GigabitEthernet0/1

  Service-policy input: POLICE-5MBPS

    Class-map: CUSTOMER-TRAFFIC (match-any)
      1234567 packets, 987654321 bytes
      5 minute offered rate 6250000 bps, drop rate 1250000 bps
      Match: access-group name CUSTOMER-ACL
        1234567 packets, 987654321 bytes

        police:
              rate  5000000 bps, burst 10000 bytes
            conformed  987654 packets, 617034000 bytes; actions: transmit
            exceeded   246789 packets, 246789000 bytes; actions: drop
            violated         0 packets, 0 bytes;        actions: drop

The policing output shows three traffic categories: conformed (within CIR — forwarded), exceeded (above CIR but within CIR+burst — action configured as drop in this example, but could be re-mark to a lower DSCP for differential treatment), and violated (above CIR+burst — always drop). In service provider environments, the "exceed" action is often configured as

exceed-action set-dscp-transmit
    af11

rather than drop — marking the excess traffic as lower-priority and allowing it through if bandwidth permits, rather than hard-dropping it.

Shaping with Burst — Tc, Bc, Be Parameters

! ── Advanced shaping with explicit burst parameters ──────────────
NetsTuts_R1(config)#policy-map SHAPE-ADVANCED
NetsTuts_R1(config-pmap)#class ALL-TRAFFIC
NetsTuts_R1(config-pmap-c)#shape average 10000000 12500 12500
!                                         ^^^^^^^^^  ^^^   ^^^
!                                   CIR (10 Mbps)  Bc    Be
!                                                 (bytes committed burst)
!                                                        (bytes excess burst)

! ── Token Bucket Model Explained:
!    CIR = 10 Mbps = 10,000,000 bps
!    Tc  = timing interval = Bc/CIR = 12500 / 10000000 = 0.00125s = 1.25ms
!    In each Tc interval, a 'token' of Bc bytes is available to send
!    Unused tokens accumulate up to Bc + Be for burst capability
!
!    Practical result:
!    Normal traffic: smoothly shaped to 10 Mbps average rate
!    Burst allowed:  up to Bc + Be = 25000 bytes in one Tc interval
!                    before shaping kicks back in

NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

8. Step 5 — Full Verification

show storm-control — Primary Verification Command

! ── Show all interfaces with storm control configured ─────────────
NetsTuts_SW1#show storm-control
Interface  Filter State   Upper  Lower  Current
---------  -------------  -----  -----  -------
Fa0/1      Forwarding     20.00% 10.00%   0.31%  broadcast
Fa0/1      Forwarding     10.00%  5.00%   0.08%  multicast
Fa0/2      Forwarding     20.00% 10.00%   0.28%  broadcast
Fa0/2      Forwarding     10.00%  5.00%   0.06%  multicast
Fa0/3      Forwarding     10.00%  5.00%   0.12%  broadcast
Fa0/3      Forwarding      5.00%  2.00%   0.03%  multicast
Fa0/4      Forwarding      5.00%  2.00%   0.09%  broadcast
Fa0/4      Forwarding      3.00%  1.00%   0.02%  multicast
Fa0/4      Forwarding     10.00%  5.00%   0.15%  unicast
Fa0/5      Forwarding     30.00% 20.00%   4.72%  broadcast
Fa0/5      Forwarding     20.00% 10.00%   2.31%  multicast

! ── Field meanings ───────────────────────────────────────────────
! Interface:     the port
! Filter State:  Forwarding = normal, Blocking = storm active
! Upper:         rising threshold (action triggers above this)
! Lower:         falling threshold (action clears below this)
! Current:       current traffic rate as % of port BW (last 1s window)

show storm-control — Specific Interface

! ── Detailed per-interface view ───────────────────────────────────
NetsTuts_SW1#show storm-control FastEthernet0/4
Interface  Filter State   Upper  Lower  Current
---------  -------------  -----  -----  -------
Fa0/4      Forwarding      5.00%  2.00%   0.09%  broadcast
Fa0/4      Forwarding      3.00%  1.00%   0.02%  multicast
Fa0/4      Forwarding     10.00%  5.00%   0.15%  unicast

! ── All three storm types configured and active ───────────────────
! ── Current rates well below thresholds — healthy state ──────────

! ── Verify the action configured ────────────────────────────────
NetsTuts_SW1#show running-config interface FastEthernet0/4
Building configuration...

Current configuration : 198 bytes
!
interface FastEthernet0/4
 description IoT-VLAN30-Tight-Policy
 switchport access vlan 30
 switchport mode access
 storm-control broadcast level 5.00 2.00     ← ✓ broadcast threshold
 storm-control multicast level 3.00 1.00     ← ✓ multicast threshold
 storm-control unicast level 10.00 5.00      ← ✓ unicast threshold
 storm-control action shutdown               ← ✓ shutdown action
 storm-control action trap                   ← ✓ trap action
 spanning-tree portfast
!

Simulating a Storm — Observing the Action

! ── During a broadcast storm, show storm-control changes state ────
NetsTuts_SW1#show storm-control FastEthernet0/1
Interface  Filter State   Upper  Lower  Current
---------  -------------  -----  -----  -------
Fa0/1      Blocking !!    20.00% 10.00%  87.42%  broadcast
!           ^^^^^^^^                    ^^^^^^^
!        Storm active — port is         Current rate 87% — far above
!        in err-disable (if action=shutdown)  the 20% rising threshold
!        or dropping excess (if no action)

! ── Syslog during storm ──────────────────────────────────────────
*Mar  7 2026 09:22:14.001: %STORM_CONTROL-3-SHUTDOWN: A packet storm
  was detected on Fa0/1. The interface has been disabled.
*Mar  7 2026 09:22:14.002: %LINK-3-UPDOWN: Interface FastEthernet0/1,
  changed state to down

! ── Verify port is err-disabled ──────────────────────────────────
NetsTuts_SW1#show interfaces FastEthernet0/1 status
Port    Name                Status       Vlan  Duplex Speed
Fa0/1   PC-A-VLAN10         err-disabled  10    auto   auto

Complete Verification Checklist

Command	What It Confirms	Expected Healthy Output
`show storm-control`	All configured ports, thresholds, current rates, filter state	Filter State = "Forwarding", Current rate well below Upper threshold
`show storm-control [int]`	Per-port thresholds and real-time rate for each traffic type	Upper/Lower show configured values, Current shows live rate
`show interfaces [int] status`	Port operational state — confirms not err-disabled	Status = "connected", not "err-disabled"
`show errdisable recovery`	Auto-recovery configuration for storm-control cause	storm-control row shows Enabled/Disabled based on your policy
`show running-config interface [int]`	Full storm-control configuration including action	All storm-control lines present with correct thresholds and actions
`show interfaces [int]`	Live broadcast/multicast counters to validate threshold sizing	Broadcast rate in normal operation should be well below the rising threshold
`show policy-map interface [int]`	Traffic shaping/policing statistics (router interfaces)	Conformed packets high, exceeded/violated packets low or zero

9. Complete Configuration Reference & Key Points

Full Storm Control Configuration — NetsTuts_SW1

! ════════ COMPLETE STORM CONTROL CONFIGURATION ═══════════════════

interface FastEthernet0/1
 description PC-A-VLAN10-Storm-Control
 switchport mode access
 switchport access vlan 10
 storm-control broadcast level 20.00 10.00
 storm-control multicast level 10.00 5.00
 storm-control action shutdown
 storm-control action trap
!
interface FastEthernet0/2
 description PC-B-VLAN10-Storm-Control
 switchport mode access
 switchport access vlan 10
 storm-control broadcast level 20.00 10.00
 storm-control multicast level 10.00 5.00
 storm-control action shutdown
 storm-control action trap
!
interface FastEthernet0/3
 description Server-VLAN20-Strict
 switchport mode access
 switchport access vlan 20
 storm-control broadcast level 10.00 5.00
 storm-control multicast level 5.00 2.00
 storm-control action shutdown
!
interface FastEthernet0/4
 description IoT-VLAN30-Tight-Policy
 switchport mode access
 switchport access vlan 30
 storm-control broadcast level 5.00 2.00
 storm-control multicast level 3.00 1.00
 storm-control unicast level 10.00 5.00
 storm-control action shutdown
 storm-control action trap
!
interface FastEthernet0/5
 description Trunk-to-SW2-Storm-Relaxed
 switchport trunk encapsulation dot1q
 switchport mode trunk
 storm-control broadcast level 30.00 20.00
 storm-control multicast level 20.00 10.00
 storm-control action trap
!
errdisable recovery cause storm-control
errdisable recovery interval 60

Storm Control Command Reference

Command	Mode	Purpose
`storm-control broadcast level [rising] [falling]`	Interface config	Set broadcast storm threshold as percentage of port bandwidth. Falling threshold optional (hysteresis).
`storm-control multicast level [rising] [falling]`	Interface config	Set multicast storm threshold as percentage.
`storm-control unicast level [rising] [falling]`	Interface config	Set unknown unicast flooding threshold as percentage. Protects against MAC table overflow attacks.
`storm-control broadcast level bps [rising] [falling]`	Interface config	Set broadcast threshold in absolute bits per second — preferred for high-speed ports.
`storm-control broadcast level pps [rising] [falling]`	Interface config	Set broadcast threshold in packets (frames) per second — preferred for CPU-protection scenarios.
`storm-control action shutdown`	Interface config	Err-disable the port when threshold is exceeded. Requires manual recovery or errdisable recovery.
`storm-control action trap`	Interface config	Send SNMP trap when threshold is exceeded. Can be combined with shutdown. Does not drop traffic alone.
`errdisable recovery cause storm-control`	Global config	Enable automatic recovery for storm-control-triggered err-disable. Port re-enables after recovery interval.
`errdisable recovery interval [seconds]`	Global config	Set the auto-recovery timer. Default is 300 seconds. Applies to all errdisable recovery causes.
`show storm-control`	Privileged exec	Show all ports with storm control configured: threshold values, filter state, current rate.
`show storm-control [interface]`	Privileged exec	Show storm control detail for a specific interface.
`show errdisable recovery`	Privileged exec	Show err-disable recovery configuration for all causes and the current recovery interval.

Key Points & Exam Tips

Storm control operates on ingress traffic only. The threshold is measured against traffic received on the port — not transmitted. This makes sense: a storm source generates traffic that enters the switch on a specific port; storm control detects it at ingress and takes action before it floods the rest of the network.
The measurement window is 1 second. Storm control evaluates the traffic rate over a 1-second interval in hardware. The "Current" column in show storm-control shows the rate from the most recently completed 1-second window — it is a snapshot, not a rolling average.
Three traffic types, three separate thresholds. Broadcast, multicast, and unknown unicast storm control are configured independently. You can configure all three on the same port, just multicast and broadcast, or any combination. Not configuring unicast protection leaves MAC table overflow attacks undetected.
Default action (no action command) = filter (drop excess). Without storm-control action shutdown or storm-control action trap, the switch silently drops frames that exceed the threshold. The port stays up — only the excess frames are dropped. This is the least disruptive action but provides no alerting and no automatic port isolation of the storm source. Use storm-control action trap with SNMP and syslog to ensure storm events are visible.
Rising threshold without falling = no hysteresis. If you configure storm-control broadcast level 20 (no falling value), the falling threshold defaults to the rising threshold (20%). This can cause rapid flapping if the storm rate oscillates around 20%. Always configure a falling threshold at roughly half the rising threshold for stability.
Never configure shutdown action on trunk uplinks. A legitimate traffic burst on a trunk (large multicast stream, broadcast from downstream segment) could trigger shutdown and isolate all downstream switches. Use trap only on trunk ports.
Traffic shaping buffers excess traffic; policing drops it. Shaping adds latency (queuing delay) but preserves traffic. Policing enforces hard limits with no queuing. For voice/video traffic that cannot tolerate latency, policing with re-marking is often preferred over shaping. For bulk data where orderly delivery matters, shaping prevents TCP retransmission storms caused by hard drops. See QoS Overview for the broader framework.
Shaping is egress-only; policing can be ingress or egress. You cannot shape incoming traffic (you have no control over the sender's transmission rate). Policing can be applied at ingress (drop excess inbound traffic before it consumes internal resources) or egress (limit outbound rate on a WAN interface).
On the CCNP exam: know the three storm types, the rising/falling threshold concept, the three actions (filter/shutdown/trap — note "filter" is the default, not a configurable keyword), the errdisable recovery mechanism, and the distinction between traffic shaping and policing.

Related Labs: Storm control is one layer of a complete Layer 2 security strategy. Combine it with DHCP Snooping to prevent rogue DHCP servers, and Private VLANs (PVLAN) to restrict intra-VLAN communication in high-risk segments. For preventing rogue switch connections that could trigger STP-based broadcast storms see PortFast & BPDU Guard. For MAC address table security (the root cause of unknown unicast flooding attacks) see MAC Address Table Management. For the broader QoS framework including traffic shaping in service hierarchies see MQC (Modular QoS CLI) Basics, DSCP Marking & Classification, and LLQ for Voice Traffic.

TEST WHAT YOU LEARNED

1. Storm control is configured on Fa0/1 with `storm-control broadcast level 20 10`. The broadcast traffic rate rises to 25% of port bandwidth, then drops back to 15%. Is the port still in storm-control blocking state at 15%? Why or why not?

A. No — as soon as the broadcast rate drops below the rising threshold (20%), storm control immediately clears and the port returns to forwarding B. Yes — the port stays in blocking state indefinitely once triggered; only a manual shutdown / no shutdown clears it regardless of the current rate C. Yes — the port remains in blocking/err-disable state because the rate (15%) has not yet dropped below the falling threshold (10%). The hysteresis window requires the rate to fall below the lower threshold before storm control clears. The port only returns to forwarding once the broadcast rate drops below 10% — not 20% D. No — storm control only applies the rising threshold once per 5-minute interval; subsequent checks use only the falling threshold

Correct answer is C. This question tests the hysteresis (rising/falling threshold) concept. The rising threshold (20%) is the trigger point — when broadcast exceeds 20%, the action fires (filter drops excess, or port enters err-disable if shutdown is configured). The falling threshold (10%) is the clear point — the blocked/filtering state does not clear until the broadcast rate drops below 10%. In this scenario: rate rises to 25% → exceeds 20% rising threshold → action triggered. Rate drops to 15% → 15% is below the rising threshold (20%) but ABOVE the falling threshold (10%) → storm control remains active. The port only clears when the rate drops below 10%. This hysteresis prevents rapid oscillation: without it, a storm source generating traffic just above 20% would cause the port to flap between blocking and forwarding states rapidly (storm triggers at 21%, blocking drops rate to 19%, clears at 19% because no hysteresis, storm immediately rises to 21% again, triggers, repeat). The falling threshold's job is to ensure the storm is truly over before re-enabling forwarding.

2. What is the default action when storm control threshold is exceeded and no `storm-control action` command is configured? How is this different from configuring `storm-control action shutdown`?

A. Default action is to silently filter (drop) the excess frames — traffic exceeding the threshold is discarded but the port stays up and continues forwarding traffic below the threshold. Configuring storm-control action shutdown err-disables the entire port — all traffic stops, including legitimate below-threshold traffic, and the port must be manually re-enabled (or auto-recovery must be configured). The default filter action is less disruptive but provides no alert and does not isolate the storm source; shutdown is more disruptive but completely stops the storm and forces administrative attention B. Default action is to send an SNMP trap — no traffic is dropped or the port shutdown without explicit configuration C. Default action is the same as shutdown — the port automatically enters err-disable when no action is specified D. There is no default action — storm control has no effect unless an action is explicitly configured

Correct answer is A. The default storm control behaviour when no action command is configured is to filter — the switch drops frames that exceed the threshold without taking any other action. The port remains up and operational; legitimate traffic below the threshold continues to flow normally. Only the excess storm traffic is discarded. This is sometimes called "filter mode" or "drop mode." The key differences from shutdown: Filter mode — port stays up, excess traffic dropped, no alert, no operator notification, storm source stays connected (but its excess traffic is blocked). Shutdown mode — entire port goes err-disabled, all traffic stops (both storm and legitimate), syslog message generated, SNMP trap sent (if trap action also configured), storm source is completely isolated from the network. In practice, filter mode is useful for high-speed uplinks where occasional brief broadcast spikes occur and you want rate limiting without service disruption. Shutdown mode is appropriate for access ports where a sustained storm indicates a problem device that should be isolated.

3. An engineer configures `storm-control broadcast level 20 10` on a GigabitEthernet port operating at 1 Gbps. What is the actual broadcast rate (in Mbps) at which the action triggers, and at which it clears?

A. Action triggers at 20 Mbps (absolute), clears at 10 Mbps — the percentage is converted to a fixed value regardless of port speed B. Action triggers at 200 Kbps and clears at 100 Kbps — the percentage is divided by the port speed in Gbps C. Action triggers at 2 Mbps and clears at 1 Mbps — the percentage represents packets per second, not bandwidth D. Action triggers at 200 Mbps (20% of 1000 Mbps) and clears at 100 Mbps (10% of 1000 Mbps). The percentage threshold is calculated against the interface's configured bandwidth. For a 1 Gbps port: 20% × 1000 Mbps = 200 Mbps rising, 10% × 1000 Mbps = 100 Mbps falling. On a 100 Mbps FastEthernet port with the same configuration: 20% × 100 Mbps = 20 Mbps rising, 10 Mbps falling. This is why the BPS format is often more appropriate for high-speed ports — 200 Mbps of broadcast traffic is an enormous amount that would devastate any network, making the 20% threshold effectively useless on a GigE port

Correct answer is D. The percentage threshold in storm control is always relative to the interface's configured bandwidth (the BW value shown in show interfaces | include BW). For a GigabitEthernet interface with BW of 1000 Mbps (1 Gbps): 20% = 200 Mbps absolute broadcast rate. This is the critical insight for choosing between percentage and absolute (BPS/PPS) thresholds. A 20% threshold might be perfectly appropriate on a 100 Mbps access port (20 Mbps broadcast is obviously a storm), but completely inappropriate on a 1 Gbps or 10 Gbps uplink (200 Mbps or 2 Gbps of broadcast would have already collapsed the network before storm control kicks in). For high-speed ports, use BPS: storm-control broadcast level bps 10000000 limits broadcasts to 10 Mbps regardless of the physical port speed. For router CPU protection, use PPS: storm-control broadcast level pps 1000 limits to 1000 broadcast packets per second regardless of packet size or port speed — directly protecting the CPU's packet processing capacity.

4. What is the risk of configuring `storm-control action shutdown` on a trunk uplink, and what is the recommended alternative?

A. No risk — shutdown action is always recommended on all ports including trunks for maximum protection B. A trunk port carries aggregated traffic from multiple VLANs and higher broadcast rates are normal. A legitimate broadcast burst (DHCP, ARP refresh, multicast video stream) or even normal traffic from many downstream hosts could exceed a threshold and trigger shutdown, err-disabling the trunk and disconnecting all downstream switches — causing a major outage. The recommended approach: use storm-control action trap on trunk ports (alerts without dropping service), set a higher threshold to account for aggregated traffic, and investigate alerts rather than automatically isolating trunks C. The risk is minor — shutdown on a trunk only affects VLAN 1, not tagged VLANs D. Storm control cannot be configured on trunk ports — the feature is access-port-only

Correct answer is B. This is a critical operational point. A trunk port's role is to carry the combined traffic of all VLANs from one switch to another. If SW1 has 24 access ports in VLAN 10 and each generates 2% broadcast traffic, the trunk to SW2 carries 48% broadcast from VLAN 10 alone — far above any reasonable threshold. Setting a 20% broadcast threshold on this trunk and adding a shutdown action would immediately err-disable the trunk under normal load, disconnecting all 24 downstream hosts. Additionally, even with an appropriate threshold, a momentary broadcast spike during a legitimate event (network boot, broadcast-heavy application) could trigger the threshold and cause a major outage. The correct approach for trunk ports: (1) Set a high threshold (30-50%) to account for aggregated normal traffic, (2) Use trap-only action so storms are logged without causing outages, (3) Let Spanning Tree (STP/RSTP) handle loop-based storms — STP is specifically designed to detect and break loops, which are the most common cause of true broadcast storms on trunk ports.

5. An engineer discovers that PC-A's port (Fa0/1) is in err-disable state due to storm control. The PC has been replaced with a new one. What steps must be taken to restore connectivity, and how could this be automated for future occurrences?

A. Power cycle the switch — this is the only way to clear err-disable state B. Remove and re-add the storm-control configuration — reconfiguring the feature clears the err-disable state C. Manual recovery: enter interface Fa0/1, issue shutdown then no shutdown — this clears the err-disable state and brings the port back up. To automate future recovery: configure errdisable recovery cause storm-control globally and set an appropriate interval (e.g., errdisable recovery interval 60). With auto-recovery enabled, the switch automatically attempts to re-enable the port after the interval expires. If the storm source is gone, the port comes up normally; if the storm persists, it immediately goes back into err-disable until the root cause is resolved D. The err-disable state clears automatically after 5 minutes with no additional configuration required

Correct answer is C. An err-disabled port does not recover automatically unless errdisable recovery is explicitly configured — it stays err-disabled indefinitely until an administrator manually intervenes. The manual recovery procedure is simple: issue shutdown followed by no shutdown on the interface. This resets the port state from err-disabled to normal operational state. If storm control thresholds are still configured (which they should be), the port will be monitored again from the moment it comes up. The automation option — errdisable recovery — is a global configuration that periodically attempts to bring err-disabled ports back up. The key consideration for recovery interval: too short (e.g., 10 seconds) means a persistent storm source gets disconnected and reconnected rapidly with minimal impact; too long (e.g., 600 seconds) means legitimate devices experience extended outages after a transient storm. The 60–300 second range is typical for access ports. Note that auto-recovery should be combined with SNMP traps so the NOC is notified — otherwise ports silently go down and come back up with no operational visibility into what happened.

6. Why does storm control include protection against unknown unicast flooding, and what attack does unknown unicast storm control defend against?

A. Unknown unicast flooding occurs when a frame's destination MAC is not in the switch's MAC address table — the switch floods it to all ports in the VLAN, just like a broadcast. The MAC table overflow attack deliberately generates thousands of frames with different spoofed source MAC addresses, filling the MAC table (typically 8,000–32,000 entries). Once full, the switch cannot learn new legitimate MACs and begins flooding all unicast traffic. An attacker on any port in the VLAN can then capture traffic intended for other hosts — effectively turning the switch into a hub. Unknown unicast storm control detects when the flooding rate exceeds the threshold and blocks the attack by rate-limiting the flooding traffic or shutting down the attacking port B. Unknown unicast storm control protects against ARP spoofing — it detects spoofed ARP replies flooding the network C. Unknown unicast flooding is prevented by IGMP snooping — storm control's unicast option provides a backup mechanism only D. Unknown unicast flooding only occurs on half-duplex links — modern full-duplex links never generate unknown unicast floods

Correct answer is A. The MAC table overflow attack (also called MAC flooding attack) is a well-known Layer 2 security threat. Tools like macof (part of the dsniff toolkit) can generate 155,000 MAC entries per minute — filling a typical 8,000-entry MAC table in seconds. Once the table overflows, the switch enters a fail-open mode where it floods all unknown unicast frames. An attacker with a packet capture tool (Wireshark) running on their port can now see all traffic in the VLAN — including SSH sessions, FTP credentials, HTTP traffic, and internal server communications. This is a passive eavesdropping attack that bypasses the port isolation that switches normally provide. Unknown unicast storm control adds a rate limit on the flooding rate: storm-control unicast level 10 5 on an IoT port means if more than 10% of port bandwidth is unknown unicast flooding, the port is shut down. Since legitimate unknown unicast flooding (caused by MAC aging or asymmetric routing) is brief and low-rate, this threshold effectively detects MAC flooding attacks (high-rate, sustained flooding) without false-positive shutdown of normal ports. Additional defences against MAC flooding include port security (switchport port-security maximum 1) and 802.1X authentication.

7. What is the fundamental difference between traffic shaping and traffic policing in terms of how they handle traffic that exceeds the configured rate?

A. Shaping drops excess traffic while policing queues it — the opposite of what most engineers assume B. They are functionally identical — both drop excess traffic; the difference is only in which interface direction they apply C. Shaping re-marks excess traffic to a lower DSCP while policing drops it D. Policing drops (or re-marks) excess traffic immediately with no buffering — a hard enforcement mechanism that adds no latency. Shaping queues excess traffic in a buffer and releases it at the configured rate — a smooth enforcement mechanism that adds latency (queuing delay) but avoids packet loss. For TCP traffic, policing's hard drops cause TCP to detect congestion and reduce its window (slow down), then ramp back up, causing a sawtooth throughput pattern. Shaping's queuing absorbs the excess, smoothing the output rate and allowing TCP to maintain a higher sustained throughput without the slow-start retransmissions caused by drops

Correct answer is D. The drop vs buffer distinction is the defining characteristic between policing and shaping. Policing uses a token bucket: tokens accumulate at the CIR rate. When a packet arrives, if there are enough tokens, it is forwarded (conformed) and tokens are consumed. If there are insufficient tokens, the packet is either dropped (exceed/violate action) or re-marked to a lower DSCP. No queuing occurs — the decision is instantaneous. The advantage: no added latency. The disadvantage: TCP interprets dropped packets as congestion signals and reduces its sending rate, causing throughput oscillation. Shaping uses a dual token bucket with a shaping queue: when traffic exceeds the CIR, excess packets go into a FIFO queue instead of being dropped. The queue drains at the CIR rate. This smooths the output — the sender's TCP sees no drops, maintains its window, and achieves near-CIR throughput without oscillation. The disadvantage: queuing adds latency (which varies with queue depth). For real-time applications (VoIP, video conferencing), this latency variation (jitter) is more damaging than an occasional drop. Best practice: use shaping for bulk TCP data flows where throughput matters, use policing with DSCP re-marking for mixed traffic, and use LLQ (priority queueing) to ensure real-time traffic bypasses all shaping queues.

8. A network has a storm-control configuration with only a rising threshold of 20% on an access port: `storm-control broadcast level 20`. The broadcast storm generates 25% broadcast traffic. Storm control activates and suppresses the traffic to 18%. Two seconds later the traffic rises to 22% again. What happens and why?

A. The port remains in storm suppression permanently until manually cleared — once activated it stays active until reset B. When only a rising threshold is configured, the falling threshold defaults to equal the rising threshold (20%). When storm control suppresses traffic to 18%, the rate is now below both the rising (20%) and falling (20%) thresholds — storm control clears. Traffic immediately rises to 22%, exceeds the 20% rising threshold again, storm control activates again. This rapid on/off cycle (flapping) continues indefinitely as long as the storm source generates traffic around the threshold. This is why configuring a falling threshold below the rising threshold (e.g., level 20 10) is important — the 10% falling threshold prevents premature clearing C. The port enters err-disable after the second activation — storm control counts activations and shuts down after two triggers D. Storm control uses an exponential backoff — the second activation raises the threshold to 40% automatically

Correct answer is B. This scenario demonstrates exactly why the falling threshold exists and why omitting it is a configuration mistake. When storm-control broadcast level 20 is configured without a falling threshold, IOS sets the falling threshold equal to the rising threshold (both at 20%). The behaviour becomes a rapid oscillation: traffic at 25% → exceeds 20% rising → storm control activates (drops excess, or shuts port). Traffic suppressed to 18% → below 20% falling → storm control deactivates. Traffic source immediately rises to 22% (nothing is stopping the source from generating traffic) → exceeds 20% rising → storm control activates again. This can cycle many times per second if the storm control is filtering (not shutdown mode), causing inconsistent forwarding behaviour that is difficult to diagnose. With a falling threshold of 10% (level 20 10): traffic drops to 18% → above 10% falling → storm control stays active. Traffic continues to be suppressed until it drops below 10%, at which point the storm is genuinely over. The hysteresis provides stability by requiring a meaningful reduction in storm traffic before clearing — not just dropping below the activation threshold.

9. A router egress interface is configured with both traffic shaping (10 Mbps) and DSCP-based priority queuing (LLQ) for VoIP traffic. VoIP traffic arrives at 2 Mbps, bulk data at 15 Mbps. How does the combined configuration handle both traffic types?

A. The shaping applies first: total output is limited to 10 Mbps. VoIP and data compete equally in the 10 Mbps shaped stream — VoIP gets 2 Mbps and data gets 8 Mbps proportionally B. Shaping and LLQ cannot be combined — LLQ requires policing to work correctly C. LLQ (strict priority) processes VoIP traffic first within the shaped 10 Mbps limit. VoIP (2 Mbps) is dequeued from the priority queue first, before any data traffic. The remaining 8 Mbps of shaped bandwidth is available for bulk data. Since data arrives at 15 Mbps but only 8 Mbps is available, the excess 7 Mbps is queued in the shaping buffer and released at the data's share of the shaped rate. VoIP experiences no additional shaping latency (it's in the priority queue), while data experiences the shaping delay. Total output stays at 10 Mbps D. The shaping limit (10 Mbps) applies to bulk data only — VoIP traffic bypasses the shaping mechanism entirely and is sent at line rate regardless of the shaping policy

Correct answer is C. This scenario demonstrates the interaction between traffic shaping and LLQ (Low-Latency Queuing), which is the standard QoS design for WAN interfaces carrying both VoIP and data. The shaping mechanism creates an overall 10 Mbps transmission rate limit for the interface. Within this 10 Mbps shaped output, LLQ provides a strict priority mechanism: the priority queue (VoIP) is always serviced first before other queues. Since VoIP requires 2 Mbps and the priority queue guarantees it gets serviced first, VoIP traffic experiences no additional queuing delay beyond the base shaping interval (typically a few milliseconds). The remaining 8 Mbps is available for bulk data classes, which are served from their respective queues after the priority queue is empty. The 15 Mbps of incoming data must be shaped to 8 Mbps — excess 7 Mbps is buffered in the shaping queue. This design is common in enterprise WAN deployments: shape all traffic to the CIR (avoiding ISP drops), then use LLQ to ensure VoIP gets its share without competing with data bursts. The critical constraint is that the priority queue bandwidth (2 Mbps VoIP) must never exceed the total shaped rate (10 Mbps) — if VoIP were to burst to 12 Mbps, it would starve data traffic completely.

10. `show storm-control FastEthernet0/3` shows Filter State = "Blocking" and Current = "0.00%". The port appears to be up in `show interfaces status`. What does this seemingly contradictory state indicate?

A. A hardware bug — storm control should not show Blocking when the current rate is 0%. Reload the switch to clear B. The port is in err-disable state — show interfaces status always shows "up" even for err-disabled ports C. Storm control is in "filter" mode (no action command configured) — Blocking means excess frames are being dropped but the port is still forwarding traffic below the threshold, which is now 0% D. This indicates the storm is still technically active (Filter State = Blocking) but the current measurement window shows 0% traffic. This happens when: the storm source stopped generating traffic (e.g., the offending device was disconnected or powered off) but the rate has not yet dropped below the falling threshold in storm control's internal state machine, OR the action is filter mode (not shutdown) so the port is still forwarding — the Blocking state means excess frames are being dropped but frames below the threshold are forwarded (hence port shows "connected"). The rate will clear to Forwarding state once the next measurement window confirms the rate is below the falling threshold

Correct answer is D. This is a nuanced state that causes confusion. The storm-control Filter State and the interface operational state are independent. "Blocking" in Filter State means storm control's suppression mechanism is active — it is currently filtering (dropping) traffic that exceeds the threshold. "0.00% current" means the most recently completed 1-second measurement window showed zero storm traffic. The apparent contradiction resolves when you understand the timing: storm control's state machine uses hysteresis — it transitions from Blocking to Forwarding only when the current rate drops below the falling threshold and stays there. If the storm source just disconnected, the last measurement window might show 0% (source is gone) but storm control's state hasn't transitioned yet — it needs to confirm the low rate is sustained. If no action shutdown is configured (filter mode), the port remains "connected" in show interfaces status because the physical port is still up — only the excess storm traffic is being dropped, not all traffic. In shutdown mode, the port would show "err-disabled." The correct next step: monitor show storm-control over the next few seconds — if the rate stays at 0%, the Filter State should transition to Forwarding within the next measurement cycle. If it stays in Blocking indefinitely, the storm may still be active at sub-threshold levels.

Back to Home