What must match for switches to belong to the same MSTP region? The configuration name, revision number and complete VLAN-to-instance mapping must match on connected MST switches; the mapping is represented in MST BPDUs by a digest.[1] Matching the region name alone is not enough.[1]
The direct answer: name, revision and mapping
Multiple Spanning Tree Protocol (MSTP) groups VLANs into a smaller set of spanning-tree instances so that VLANs sharing a desired topology can share an instance.[1] A region is the scope within which those internal instances operate; matching configurations need an MST-connected path to form one contiguous region.[1]
| Item | What must match? | Practical check |
|---|---|---|
| Configuration name | The same name, not merely a similar label | Compare the exact configured string on both switches.[1] |
| Revision number | The same configured number | Treat it as a matching attribute, not a winner-selection rule.[1] |
| VLAN-to-instance mapping | The complete mapping table | Compare every mapping, not only VLANs currently carried on the uplink.[1] |
| Configuration digest | The derived representation of the mapping | Compare the digest alongside name and revision.[1] |
The digest is not a fourth independent setting you type in. It is computed from the mapping table and carried with the other region attributes.[1] Consequently, equal digests alone do not establish that region names and revision numbers also match.[1]
How an MST BPDU identifies the region
The following is a conceptual process, not a packet capture from an executed lab:
- The switch has a configured name, revision and VLAN-to-instance table.[1]
- It derives a digest from that mapping table.[1]
- Its MST BPDU carries the name, revision and digest rather than transmitting the entire VLAN mapping table.[1]
- The receiving switch compares the advertised region information with its local configuration.[1]
- A mismatch means the neighbor is not in the same region; the connecting segment is treated as a region boundary rather than an internal MST connection.[1]
Inside a region, MST BPDUs carry IST information plus records for the internal MST instances; an MSTI does not send a separate BPDU for every VLAN assigned to it.[1] Instance 0 is the Internal Spanning Tree (IST), and the region interacts with the external spanning-tree topology through the common-tree mechanisms rather than extending each internal MSTI independently across regions.[1]
An unexpected boundary is not automatically a dead link. Separate regions can interoperate, but the assumption of one shared internal instance topology is no longer valid.[1] Diagnose the actual port roles and forwarding behavior instead of assuming that every region mismatch shuts an interface down.
Worked example: the hidden VLAN mapping mismatch
Consider two fictional distribution switches intended to share the region CAMPUS-LAB, revision 7. The example is illustrative, not measured switch output.
| Configuration item | Switch A | Switch B |
|---|---|---|
| Name | CAMPUS-LAB | CAMPUS-LAB |
| Revision | 7 | 7 |
| MST instance 1 | VLANs 10 and 20 | VLANs 10 and 20 |
| MST instance 2 | VLAN 30 | VLANs 30 and 40 |
| Remaining VLANs | Instance 0 | Instance 0 |
The switches do not have the same region configuration: VLAN 40 is mapped differently, even though the name and revision match.[1] Because the digest covers the complete mapping table, excluding VLAN 40 from the connecting trunk does not repair this configuration difference.[1]
Recommended fix: first decide which mapping is intended, then apply that same mapping across the intended region during an approved change. Do not blindly copy whichever configuration happens to have the larger revision number: the MST matching rule requires equal revisions; it does not choose the higher one as an authoritative configuration.[1]
Cisco IOS XE configuration and verification
The following is an illustrative Catalyst-style configuration for a fresh lab, based on Cisco's documented MST configuration workflow; syntax and capabilities must be checked for your platform and release.[2] Do not paste it into an existing production network: changing spanning-tree mode or region membership can alter forwarding paths, and existing mappings require explicit review.[1][2]
First stage the desired region configuration on each intended member:
configure terminal
spanning-tree mst configuration
name CAMPUS-LAB
revision 7
instance 1 vlan 10,20
instance 2 vlan 30
show pending
exit
end
On the documented Catalyst workflow, show pending displays staged changes inside MST configuration mode, and exiting that submode applies them; abort leaves that submode without applying the pending changes.[2] Applying region settings and enabling MST as the operational spanning-tree mode are separate steps.[2]
After reviewing the region configuration, roots, trunks and migration plan, the lab activation command is:
configure terminal
spanning-tree mode mst
end
Use read-only checks on both ends of each intended internal link:
show spanning-tree summary
show spanning-tree mst configuration
show spanning-tree mst configuration digest
show spanning-tree mst
show spanning-tree mst 1
show interfaces trunk
Cisco documents the MST configuration and digest checks as a way to verify the region settings; on Catalyst 9000, compare the standard Digest field rather than the separately displayed Pre-std Digest.[2] The configuration and digest can exist before MST is the operational STP mode, so a matching configuration dump is not by itself proof that MST is active.[2]
My recommended acceptance checklist:
- Confirm every intended member is actually running MST.
- Compare exact names and revision numbers.
- Compare the full VLAN mappings and standard digests.
- Inspect instance 0 and each used MSTI for the intended root and port roles.
- Check that required VLANs exist and are allowed on the intended forwarding trunks.
- Verify end-to-end traffic and a controlled failover before declaring the change complete.
Troubleshooting: same name, different region
| Observation | What to inspect next |
|---|---|
| Same name, different revision | Align the intended revision across the region; equality is required.[1] |
| Same name and revision, different digest | Compare the complete VLAN-to-instance mappings, including VLANs not used on this trunk.[1] |
| Same digest, different names | Compare names and revisions separately; the digest is derived from the mapping.[1] |
| Pending mappings look correct, current digest looks old | Check whether the change remains staged in MST configuration mode.[2] |
| Configuration matches, but MST is not operating | Check the active spanning-tree mode; configuration can be staged before enabling MST.[2] |
| Region matches, but one VLAN has no connectivity | Inspect VLAN existence, trunk permissions and that VLAN's instance forwarding path; VLAN pruning and shared-instance topology can conflict.[1] |
A useful isolation order is mode → name → revision → mapping/digest → instance roles → VLAN forwarding. This is a troubleshooting recommendation, not a protocol state machine.
Common interview pitfalls
“The highest revision wins.” Not for MST region membership: revision is one of the attributes that must match, not a configuration-election mechanism.[1]
“Only VLANs active on this trunk affect the region.” The region check uses the full mapping table, not a per-trunk subset.[1]
“The BPDU sends all the VLAN mappings to fix the neighbor.” The BPDU advertises the digest, name and revision for comparison; it does not carry the complete mapping table for the neighbor to copy.[1]
“Matching regions guarantees VLAN connectivity.” MST computes an instance topology, while VLAN availability on trunks still matters; Cisco documents connectivity failures when individual VLANs are pruned inconsistently with the shared instance topology.[1]
“Every VLAN can independently select a different path within one MSTI.” VLANs mapped to the same instance share its spanning-tree topology; use different instances where a different topology is required.[1]
A concise interview answer
“For connected MST switches to be in the same region, the configuration name, revision number and complete VLAN-to-instance mapping must match.[1]
The BPDU carries a digest of that mapping together with the name and revision, so I compare all three rather than only the region name.[1] If a mismatch creates an unintended boundary, I check the full mapping and operational MST mode before examining roots, port roles and VLAN forwarding.”[1][2]
Optional lab exercise
In an isolated lab, start with two switches using the same region configuration. Record their name, revision, digest and port roles. Change only one VLAN mapping on one switch, commit it, and compare the observations again. Restore the mapping, then repeat by changing only the revision. Write down what changed instead of assuming that a boundary must block the link.
This is a proposed exercise; no switch lab was executed for this article.
Related reading
- STP vs RSTP port states and roles
- STP root bridge election: priority, bridge ID and MAC address
- BPDU Guard vs BPDU Filter vs Root Guard vs Loop Guard
Summary
For MST region membership, remember name + revision + complete mapping, with a digest representing the mapping in BPDUs.[1] Then verify the operational mode and actual forwarding topology rather than stopping at a matching name.[2]
Preparing for a network engineering interview? Practice explaining why an unused VLAN mapping can split a region, then describe the read-only checks you would run before changing anything.
Post a Comment