MSTP Revision Drift Isolates VLAN 20
A campus runs six EX4650 switches in two 3-member Virtual Chassis, one per building. MSTP uses region name CAMPUS-MSTP, revision 3, MSTI 1 for VLANs 10–19, and MSTI 2 for VLANs 20–29. The core VC has MSTI 2 bridge priority 4096; the access VC has 8192. A replacement EX4650 is staged with a default MSTP configuration, then cabled into the building B VC and adopted. After adoption, VLAN 20 hosts in building B can reach their local IRB but cannot reach building A. show spanning-tree mstp on the replacement shows it is root for MSTI 2 with priority 32768; the core shows 4096. show spanning-tree mstp configuration on the replacement shows the correct region name but revision 0. No interface is err-disabled. The access VC has redundant links to the core VC, and users report intermittent flooding in building B.
1. Explain why the replacement switch became root for MSTI 2 and why local IRB connectivity still works. Why is lowering its bridge priority not the correct fix?
Read the worked answer
MSTP region identity is not just the region name. It is the region name plus revision level plus the VLAN-to-MSTI mapping. The replacement has revision 0, so it forms a different MSTP region even though the name matches. Each region runs its own spanning tree. Inside the replacement's region, the default bridge priority 32768 is the best priority, so it becomes root for MSTI 2. The link between regions is a boundary link, and VLAN 20 traffic is not forwarded consistently across that boundary, which explains why local IRB works but building A is unreachable. Intermittent flooding is consistent with a region boundary and topology change.
Lowering its priority does not fix the region mismatch; it only changes which switch is root inside the wrong region. The correct fix is to make revision 3 and the MSTI mapping identical to the rest of the campus.
2. Provide a safe change sequence to correct the replacement switch, including rollback and verification.
Read the worked answer
Treat this as a potential loop/outage change, not a trivial edit.
- If possible, isolate the replacement's uplinks or shut the boundary port before changing MSTP.
- Apply the correct configuration:
set protocols mstp configuration-name CAMPUS-MSTP
set protocols mstp revision-level 3
set protocols mstp msti 1 vlan 10-19
set protocols mstp msti 2 vlan 20-29
- Use
commit confirmed 5so the switch rolls back if the change breaks management or connectivity. - Verify
show spanning-tree mstp configurationshows revision 3 and the same mapping on all switches. Verifyshow spanning-tree mstpshows the core as root for MSTI 2 and the replacement no longer root. Checkshow spanning-tree mstp interfacefor the expected root and designated roles, andshow ethernet-switching tablefor MAC flapping. - Confirm with
commitonly after VLAN 20 traffic passes between buildings and no flooding is seen.
If the replacement is a VC member, apply the configuration on the VC master; the VC shares one configuration, but confirm no stale member configuration remains.
3. A colleague suggests simply setting the replacement's MSTI 2 priority to 16384. Evaluate that proposal and state the expected result.
Read the worked answer
That proposal changes the wrong variable. Because the replacement is still in a different MSTP region (revision 0), its priority only affects root election inside its own region. It may stop being root there, but it will not merge the two regions or restore a single VLAN 20 spanning tree across buildings. The boundary link will still behave as a region boundary, so connectivity and flooding problems can remain.
After matching revision 3, the priority matters again. At that point the replacement should not be root: the core has 4096 and the access VC has 8192, so the replacement should remain a non-root bridge. If the replacement still wins root after the revision fix, investigate whether its priority was changed or whether the core's MSTI 2 priority is not applied as intended.