1
Diagnostic step 1
Keep the new VLAN offline and reproduce in maintenance window. Capture a continuous packet trace on the router uplink (mirror trunk) while toggling VLAN 20 to see if ARP/LLDP/BC packets flood.
FULL AI ANALYSIS
Managed switch VLAN addition triggers ARP storms and 100% CPU on switch, knocking a /24 offline
Generated Oct 3, 2026, 12:35:03 AM
Analysis summary
Symptoms point to either a VLAN leakage/loop or a switch-level bug that corrupts the MAC/ARP tables when the new VLAN is present. The repeated STP convergence in logs and duplicate MAC table entries suggest traffic is being forwarded in a loop between ports or between the switch and router, producing ARP storms. Alternatively, a firmware bug can corrupt MAC learning when certain VLANs are used, especially on older firmware. Because a reboot temporarily clears state, persistent misconfiguration (trunk/native mismatch) or a race in MAC learning under certain multicast/ARP rates are likely.
Possible causes
STP loop caused by an access port accidentally plugged into another switch or an unmanaged switch creating a L2 loop in VLAN 20.
90%MAC learning corruption or memory leak in the switch firmware triggered by the VLAN ID (switch firmware bug).
80%Trunk port misconfiguration: VLAN 20 not allowed on uplink trunk or mismatched native VLAN, causing frames to be mishandled and flooded.
40%Duplicate VLAN IDs used on the router side (VLAN tag remapping) causing asymmetric routing and ARP churn between L2 and L3 devices.
25%Suggested fixes
2
Diagnostic step 2
On the switch, verify trunk configuration: show interfaces trunk to confirm VLAN 20 is allowed on uplinks and that native VLAN settings match the router. Fix mismatches and re-test.
3
Diagnostic step 3
Enable port isolation / storm-control on affected access ports to limit broadcast/flood rate while debugging, preventing office-wide outage.
4
Diagnostic step 4
Temporarily move one host from VLAN 20 to a spare trunk port directly on the router and test connectivity — isolates switch vs router problem.
5
Diagnostic step 5
Inspect switch STP state per-port (show spanning-tree) and identify any rapid topology changes; if an unexpected downstream device is present, physically isolate it and retest.) If logs continue to show MAC table corruption, roll back to the previous firmware and open a vendor support case (escalate if evidence of memory/MAC table corruption).