MSTP Region Mismatch and an Unprotected Access Port
Two core switches, C1 and C2, are in MSTP region CORP, revision 1. VLAN 10 is mapped to MSTI 1 and VLAN 20 to MSTI 2. C1 is the CIST root and the MSTI 1 root; C2 is the MSTI 2 root. A new access switch A1 was staged with region name CORP, revision 2, and a different VLAN-to-instance table in which VLAN 20 is mapped to MSTI 1. A1 is connected to C1 and C2 by trunk ports. Users in VLAN 20 on A1 report slow convergence, and their traffic crosses to C1 to reach the gateway even though the MSTI 2 root is C2. Separately, an unmanaged switch was plugged into a wall port on A1 in VLAN 30. Shortly afterward the entire Layer 2 domain saw a topology change and a 30-second outage, and the unmanaged switch became the root bridge.
1. Explain why A1's VLAN 20 traffic follows the CIST toward C1 instead of using C2, and state everything that must match to correct it.
Read the worked answer
MSTP builds one region per set of switches that agree on region name, revision, and the VLAN-to-instance mapping. A1 agrees on the name but not the revision or the mapping, so it is a separate region. At the boundary, A1's internal instances are not the same instances as C1's and C2's. A1's MSTI 1, which carries VLAN 20 locally, is mapped onto the CIST of the CORP region. The CIST root is C1, so VLAN 20 traffic from A1 reaches the core through C1. The CORP region's MSTI 2, rooted at C2, is never used for that traffic because A1 has no common instance 2 with the core.
The slow convergence has the same cause: A1 participates in a different spanning tree, so any change on its links is a region-boundary change rather than an internal MSTI change, and it propagates as a CIST topology change.
To fix it, align all three parameters on A1: region name CORP, revision 1, and the exact VLAN-to-instance mapping used by C1 and C2, with VLAN 20 in MSTI 2. Verify with show spanning-tree mstp configuration on A1, C1, and C2, and confirm that all three report the same region and mapping. Then check show spanning-tree bridge to confirm the expected root per instance.
2. What should be enabled on A1's access ports to prevent the unmanaged-switch incident, and how do the protections differ?
Read the worked answer
The wall port is an edge port: it should never receive BPDUs. The unmanaged switch sent superior BPDUs, won the root election, and forced a domain-wide topology change.
Two complementary protections:
- BPDU guard or BPDU block on edge ports. Mark the port as edge and enable BPDU blocking so that if a BPDU arrives, the port is error-disabled or blocked instead of participating in STP. This directly stops an unauthorized switch from injecting topology information.
- Root guard on ports facing other switches where the root bridge must never appear. Root guard keeps a port in a discarding state for root-election purposes if superior BPDUs arrive, preserving the intended root (C1 for the CIST).
Use BPDU guard on user-facing access ports and root guard on distribution-facing ports where a downstream switch should never become root. Also consider loop protection and MAC move limits as secondary controls.
After the fix, verify with show spanning-tree interface on A1 that edge ports are marked and that the errdisabled or blocked state appears when a BPDU is injected. The outage should be limited to the offending port, not the whole Layer 2 domain.