Intermittent VLAN 20 Outages After a Second Uplink Is Re-enabled
A three-floor office refurbishment left access switches AS1 and AS2 each dual-homed to core switches C1 and C2, forming a square of 802.1Q trunks running Rapid STP. VLANs are 10 (voice), 20 (data), 30 (guest) and 99 (in-band management); the design intent is that C1 is root for VLANs 10 and 20 and C2 for VLAN 30. After the cabling team reconnected the second uplink AS2–C2 that had been patched but administratively shut down, users in VLAN 20 on AS1 report 3–8 second freezes several times an hour, the broadcast rate on C1 rises sharply, and C1 syslog repeats topology-change messages naming VLAN 99. 'Show spanning-tree' on AS1 lists Gi0/1 as Root/Forwarding and Gi0/2 as Altn/Blocking for VLAN 20, which looks correct on paper. A quick audit finds that C1's trunk to AS1 uses native VLAN 1, while AS1's side of the same trunk was changed to native VLAN 99 during the refurbishment.
1. Explain how the native VLAN mismatch produces outages even though the spanning-tree output shows a correct blocking port.
Read the worked answer
On an 802.1Q trunk, untagged frames are classified into the port's native VLAN. C1 sends its untagged BPDUs for VLAN 1 into the link; AS1 receives them and, because its native VLAN is 99, files them under VLAN 99. AS1's own untagged BPDUs go the other way and land in VLAN 1 on C1.
The consequence is that for the native VLANs the two switches are not talking about the same spanning-tree instance on that segment. Each side can believe it is designated and forwarding, so the physical square is unblocked for one of those VLANs and a broadcast loop exists. The loop only lasts while the topology-change machinery is churning, which is why users see multi-second freezes rather than a permanent outage.
Two further effects explain the rest of the evidence. First, the repeated topology-change notifications: any port changing state flushes MAC tables, and the flapping caused by inconsistent BPDUs re-triggers them, so the management VLAN 99 appears in the log because that is where the untagged BPDUs are being counted. Second, the broadcast rate on C1 rises because looped broadcasts are being replicated until the next topology event breaks the path.
So 'Gi0/2 is blocking' is not proof of health - the blocking decision is per VLAN, and the VLANs on which the switches disagree are exactly the ones not shown in the quick check.
2. Give the configuration changes you would make, in the order you would make them, and say what is cutover-safe.
Read the worked answer
- Pick one dedicated, unused native VLAN for every trunk - conventionally a black-hole VLAN that carries no user traffic and has no Layer 3 interface. Agree the value, then change it on both ends of each trunk in the same window, because the mismatch itself is the fault.
- Tag every service VLAN explicitly and prune the allowed list so only VLANs actually needed cross each trunk; VLAN 1 must not be an allowed user VLAN anywhere.
- Re-assert root placement deterministically: 'spanning-tree vlan 10,20 root primary' on C1 and 'root secondary' on C2, mirrored for VLAN 30. Do not leave root election to MAC-address tie-breaks.
- Protect the edge: PortFast plus BPDU guard on access ports facing PCs and phones, and root guard on the C1/C2 ports facing access switches, so a rogue or misconfigured access switch cannot become root.
- Keep loop guard and storm control on the inter-switch links to contain a future unidirectional failure.
Ordering matters: fix the native VLAN first because it is the active fault, then prune, then harden. The native-VLAN change is brief and disruptive on the affected trunk; the pruning and guard changes can be staged off-peak. Re-check the topology after each step rather than bundling everything, so you know which change fixed what.
3. How would you verify the fix and what would you monitor for the next week?
Read the worked answer
Verify per VLAN rather than per switch.
- Trunk consistency: check the trunk status on both ends and confirm the native VLAN and allowed lists match. Look specifically for a native-VLAN mismatch warning and for inconsistent-port entries in the spanning-tree output; both should be empty after the change.
- Topology stability: confirm the expected root bridge and the expected blocking port for each VLAN from two different switches, and confirm the root port and designated port roles agree at both ends of every inter-switch link.
- Topology-change count: record the counter, then re-read it an hour later with no planned changes. A non-zero increment with a quiet network means something is still flapping - find it with interface state-change counters before blaming spanning-tree configuration.
- Loop evidence: broadcast and multicast rate on the cores should be flat and low; port utilisation should not show the sawtooth of replicated frames.
For the following week, monitor interface up/down events, topology-change counts, broadcast rate on C1 and C2, and CPU on the access switches. Add a syslog alert on topology change outside business hours and on any BPDU received on an edge port. Finally, write the native VLAN and root placement decisions into the build standard, because the next refurbishment will otherwise reintroduce exactly this fault.