Two switching standards, both trying to prevent loops, neither aware the other exists. That is what an MST-to-PVST+ boundary is, and it is one of the most misunderstood corners of Layer 2 - which is a problem, because you meet it every time an MST core touches an access layer that someone left running Rapid-PVST.
Get the boundary right and it is invisible. Get it wrong and you get blocked ports, a "PVST simulation inconsistency" you have never heard of, and a VLAN that mysteriously will not pass traffic across the seam. This article builds a real MST/PVST boundary in a CML lab, shows the CIST, and deliberately triggers the inconsistency so you can recognise it. For the fundamentals, start at the complete spanning tree guide.
Why the boundary exists at all
Rapid-PVST+ runs one spanning tree per VLAN. A hundred VLANs means a hundred independent trees, a hundred sets of BPDUs, and a hundred separate root elections. It is simple to reason about and it does not scale.
MST (802.1s) runs a handful of trees, each carrying many VLANs. You map VLANs to instances, and each instance is one tree. A hundred VLANs might collapse into three instances. Far less BPDU overhead, far less CPU - but you have to design the VLAN-to-instance mapping deliberately.
When these two meet, the MST switch has to present something a PVST switch can understand, and vice versa. The mechanism it uses is the CIST.
The CIST: the tree that speaks to everyone
The Common and Internal Spanning Tree is MST's diplomatic layer. Think of it in two parts:
The crucial simplification: to the outside world, an entire MST region looks like a single switch. All the internal complexity - the instances, the mappings - is hidden. A PVST switch peering with an MST region sees one bridge, and it exchanges ordinary STP BPDUs with it via the CIST.
The lab
Four switches in a square. SW1 and SW2 form an MST region called PINGLABZ. SW3 and SW4 run Rapid-PVST. The boundary therefore runs on two links: SW2-to-SW3 and SW4-to-SW1. SW1 is configured to be the CIST root.
! MST region config, identical on SW1 and SW2
spanning-tree mode mst
spanning-tree mst configuration
name PINGLABZ
revision 1
instance 1 vlan 10
instance 2 vlan 20,99What the MST side sees
SW2#show spanning-tree mst 0
Interface Role Sts Cost Prio.Nbr Type
Et0/0 Root FWD 2000000 128.1 P2p
Et0/1 Desg FWD 2000000 128.2 P2p Bound(PVST)
Et0/2 Desg FWD 2000000 128.3 P2p
Et0/3 Desg FWD 2000000 128.4 P2pLook at Et0/1: Bound(PVST). That is the boundary port, and IOS is telling you exactly what it is - a port where the MST region meets a Rapid-PVST neighbour. This one field is the single most useful thing to check when a boundary misbehaves.
What the PVST side sees
SW3#show spanning-tree vlan 10
Interface Role Sts Cost Prio.Nbr Type
Et0/0 Root FWD 100 128.1 P2p Peer(STP)
Et0/1 Altn BLK 100 128.2 P2p
Et0/2 Desg FWD 100 128.3 P2p EdgePeer(STP) on the port toward the region. SW3 has no idea it is talking to a two-switch MST region carrying three instances. It sees a single STP peer, exactly as designed.
SW1 is the root, and it says so
SW1#show spanning-tree mst 1
##### MST1 vlans mapped: 10
Bridge address aabb.cc00.4d00 priority 4097 (4096 sysid 1)
Root this switch for MST1How the MST region decides two switches belong together
Three things must match exactly for two switches to be in the same MST region:
- The region name.
- The revision number.
- The complete VLAN-to-instance mapping table.
All three are hashed into a single 16-byte digest that switches exchange in their BPDUs. If the digests match, same region. If they differ, different region - and the link between them becomes a boundary, whether you intended it or not.
SW1#show spanning-tree mst configuration digest
Name [PINGLABZ]
Revision 1 Instances configured 3
Digest 0xE05029508B8AC96367E964B97EE7DA9BThis is the diagnostic that solves the most common MST mystery. In the lab, we moved a single VLAN from one instance to another on just one switch:
SW1: Digest 0xE05029508B8AC96367E964B97EE7DA9B
SW2: Digest 0xDA7E3D01C232F1CFDB7F72C25D414BAA <-- differsTwo switches you thought were one region are now two regions, and the link between them stopped being internal and became a boundary. The VLAN mapping only has to differ by one VLAN. When someone reports "MST is behaving strangely after a change", compare the digests first. It is almost always this.
The PVST simulation inconsistency
Now the failure mode that has its own name and that nobody recognises the first time.
MST can only present one view of the tree to the PVST side (through the CIST). But PVST runs a separate tree per VLAN. So there is an inherent tension: what if the PVST region tries to make itself the root for one VLAN but not another? MST has no way to represent that - it only has the CIST to offer.
The MST boundary handles this with a safety check called PVST simulation. If a PVST neighbour advertises a superior BPDU for an individual VLAN - trying to become root of a per-VLAN tree - the boundary port refuses, and blocks. We triggered it by making the PVST switch claim VLAN 10 root:
SW3(config)#spanning-tree vlan 10 priority 0Immediately, on the MST boundary:
SW2#show spanning-tree mst 0
Et0/1 Desg BKN*2000000 128.2 P2p Bound(PVST) *PVST_Inc
SW2#show spanning-tree inconsistentports
Name Interface Inconsistency
-------------------- ------------------------------ ------------------
MST0 Ethernet0/1 PVST Sim. Inconsistent
MST1 Ethernet0/1 PVST Sim. Inconsistent
MST2 Ethernet0/1 PVST Sim. Inconsistent
Number of inconsistent ports (segments) in the system : 3Read that carefully. Desg BKN* - the port is blocked. *PVST_Inc - because of a PVST inconsistency. And it is inconsistent in all three MST instances at once, because the boundary is a single physical port shared by every instance. One VLAN's misbehaviour on the PVST side has just blocked the entire boundary link, for every VLAN.
The rule the boundary enforces: the CIST root must be inside the MST region, or the boundary blocks. A PVST switch is not allowed to win the root election for a VLAN that crosses into MST. Remove spanning-tree vlan 10 priority 0 and the port un-blocks and returns to forwarding.
The design rules that prevent all of this
Troubleshooting checklist
- A VLAN will not pass across the seam? Check for
Bound(PVST)and thenshow spanning-tree inconsistentports. A PVST_Inc blocks the whole link. - Two switches you expected to be one region are not?
show spanning-tree mst configuration digeston both. Different digest = different region. Then diff the name, revision, and VLAN map. - Unexpected blocking after adding a VLAN? You probably added it on one switch's MST map but not the other, splitting the region.
- The PVST side keeps winning root? Lower the priority on an MST switch so the CIST root sits inside the region. The boundary requires it.
- Suboptimal paths? Remember the whole region is one bridge to the outside. The CST cannot see internal paths, so tune costs at the boundary if the external topology chooses badly.
Key takeaways
- MST runs few trees carrying many VLANs; PVST+ runs one tree per VLAN. The CIST is how MST presents a single, PVST-compatible view of the whole region.
- To the outside world, an entire MST region looks like one bridge. That is the CST.
Bound(PVST)marks a boundary port. It is the first thing to check on a misbehaving seam.- Region membership is decided by an exact match of name, revision, and the full VLAN-to-instance map, hashed into a digest. Different digest = different region. Diff the digests to find a split.
- A PVST simulation inconsistency (
*PVST_Inc,Desg BKN*) blocks the entire boundary link, in all instances, when the PVST side tries to become root for a VLAN crossing into MST. - Prevent it by making the MST region the root for every boundary-crossing VLAN.
Next: UDLD, which catches the one physical fault spanning tree cannot see. The full cluster index lives on the spanning tree pillar.
