> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # MST and PVST+ Interoperation: The Boundary, the CIST, and the Gotchas - URL: https://www.pinglabz.com/mst-pvst-interoperation/ - Published: 2026-07-12T08:25:25.000Z - Updated: 2026-08-24T09:42:54.000Z - Description: An MST core touching a Rapid-PVST access layer is one of the most misunderstood seams in Layer 2. Build the boundary in a CML lab, see the CIST at work, and deliberately trigger the PVST simulation inconsistency so you can recognize it. - Author: Jaime - Tags: STP, VLAN, Labs, CCIE, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/spanning-tree-protocol/). ## 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: IST (Internal Spanning Tree) This is MST instance 0\. Every VLAN not explicitly mapped elsewhere lives here. It is the tree that operates *inside* the region. CST (Common Spanning Tree) The single tree that connects the whole network - every MST region and every legacy STP/PVST switch - as if each region were one giant bridge. 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,99 ``` ### What 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 P2p ``` Look 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 neighbor. 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 Edge ``` `Peer(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 MST1 ``` ## How the MST region decides two switches belong together Three things must match *exactly* for two switches to be in the same MST region: 1. The **region name**. 2. The **revision number**. 3. 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 0xE05029508B8AC96367E964B97EE7DA9B ``` This 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 <-- differs ``` Two 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 neighbor 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 0 ``` Immediately, 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 : 3 ``` Read 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 1 **Make the MST region the root for every VLAN that crosses the boundary.** Set the CIST root and the relevant instance roots to a low priority on an MST switch. This is what stops PVST simulation inconsistencies before they start. 2 **Keep the region config byte-identical.** Name, revision, VLAN-to-instance map - copy-paste it, do not retype it. One typo makes a switch its own region. 3 **Map every VLAN deliberately.** Any VLAN you do not explicitly map lands in instance 0 (the IST). Forgetting to map a new VLAN is a classic way to get it following the wrong tree. 4 **Migrate one side fully, not halfway.** The boundary is a fine permanent state, but if you are converting an access layer to MST, do a whole switch at a time, matching the core's region config. ## Troubleshooting checklist 1. **A VLAN will not pass across the seam?** Check for `Bound(PVST)` and then `show spanning-tree inconsistentports`. A PVST\_Inc blocks the whole link. 2. **Two switches you expected to be one region are not?** `show spanning-tree mst configuration digest` on both. Different digest = different region. Then diff the name, revision, and VLAN map. 3. **Unexpected blocking after adding a VLAN?** You probably added it on one switch's MST map but not the other, splitting the region. 4. **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. 5. **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](https://www.pinglabz.com/udld-unidirectional-link-detection/), which catches the one physical fault spanning tree cannot see. The full cluster index lives on the [spanning tree pillar](https://www.pinglabz.com/spanning-tree-protocol/).