The Tuesday Broadcast Storm in IDF-3

Assessment: the filter is the cause, not part of the fix.

• BPDU filter suppresses BPDUs in both directions on that edge port. The unmanaged switch never sees spanning tree, so the desk port is never blocked; the 6300s learn the printer MAC from two directions and flood unknown unicast until the unicast storm saturates the segment. That matches the MAC flapping, the TC bursts and the CPU peak.
• Loop-protect is a per-port safety net: it sends probe PDUs and err-disables a port that receives its own probe back. It is genuinely useful for dumb-switch loops, but it fires only after frames are already circulating, and it acts on one port. It is defense in depth, not a substitute for guarding the edge.
• Running both on one port is contradictory: with the filter suppressing transmission, the guard never sees a BPDU and never err-disables.

What I would configure:

1. Remove spanning-tree bpdu-filter from all user-facing edge ports.
2. Add spanning-tree bpdu-guard on every access port, so a received BPDU err-disables the port and logs the event with the port name.
3. Keep spanning-tree port-type admin-edge for immediate forwarding.
4. Add spanning-tree root-guard on SW2/SW3 ports facing anything that might be a switch, including the cross-link and spare wall ports, so a rogue device cannot win the root election.
5. Keep loop-protect for loops that generate no BPDU at all.
6. Set err-disable auto-recovery to a long delay (300 s or more) so the offending device is investigated rather than silently re-enabled.

Build a timeline first, then confirm causally.

1. show spanning-tree and show spanning-tree detail on SW1/SW2/SW3 - record the topology-change count and compare its rate at 10:00 with the reported voice outages. A TC burst that starts and stops with the outage is the strongest single indicator.
2. show mac-address-table on SW2, repeated every few seconds during the event - the printer's MAC alternating between the uplink and the cross-link proves a loop rather than a single-path failure.
3. show events filtered around 10:00 for STP, MAC-learning and port-state entries - this shows which port started the disturbance before anything else reacted.
4. show interface <desk-port> and per-queue counters - inbound broadcast/multicast rate pinned near line rate on an access port is abnormal.
5. show interface on the trunks for output drops and runts, which distinguishes a storm from a duplex or cabling fault.

Controlled test: err-disable or shut the desk port for one Tuesday cycle. If the TC counter flattens and voice quality is clean, the loop source is confirmed. Then re-enable it with BPDU guard in place and watch for the guard event, which names the port without needing a human to watch counters.

Remove the condition that makes the loop possible.

• Replace the unmanaged switch with a managed 6300-class access switch or with a small Aruba AP-style workgroup device that runs spanning tree, and connect it to SW2 or SW3 with a single uplink. That converts an invisible loop into a normal blocked port.
• If a second cable is unavoidable, ensure the upstream ports carry BPDU guard plus loop-protect, and that only one path is active.
• Put the printer on a documented static IP in VLAN 30 so it is visible in monitoring, and add it to NAE or your NMS so an unknown MAC appearing on two ports raises an alert.
• Add a facilities-facing rule: no unmanaged switching on the production LAN; a separate small managed switch is the approved pattern.
• Finally, reduce the blast radius for next time: enable storm control on user-facing ports so a repeat degrades one port instead of the building, and keep root-guard on all ports that face downstream equipment.