MSTP: Multiple Spanning Tree Protocol Explained (802.1s)

Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) exists to solve a scaling problem that the per-VLAN spanning tree variants created. Rapid-PVST+ runs one independent spanning tree instance per VLAN. That is fine with 10 VLANs. With 500 VLANs it is 500 state machines, 500 sets of BPDUs, and a switch CPU that spends real cycles just maintaining spanning tree. MSTP fixes this by mapping many VLANs onto a small number of spanning tree instances. This post explains how it works, how to configure it on Cisco IOS XE, and the one concept (the region) that trips everyone up.

For the cluster overview, see the Spanning Tree Protocol pillar. For the L2 fundamentals underneath, see the VLAN and L2 switching pillar.

The problem MSTP solves

Spanning tree's job is to build a loop-free topology. But here is the thing: if you have 500 VLANs that all run over the same physical switches and the same physical links, you do not need 500 different loop-free topologies. You need maybe two or three - enough to load-balance traffic across your redundant uplinks, and no more.

MSTP is the middle path. You define a handful of instances, map VLAN ranges to them, and get load balancing across uplinks without paying the per-VLAN tax.

The core concept: MST instances and VLAN mapping

An MST instance (MSTI) is one spanning tree. You decide how many you want and which VLANs belong to each. A typical design:

• Instance 1 - all the "left uplink" VLANs (say VLANs 10, 20, 30)
• Instance 2 - all the "right uplink" VLANs (say VLANs 40, 50, 60)

You make one switch the root for instance 1 and a different switch the root for instance 2. Now instance 1's traffic prefers the left uplink and instance 2's traffic prefers the right uplink. Two instances, full load balancing, regardless of whether you have 6 VLANs or 600.

VLANs not explicitly mapped land in instance 0, the IST (Internal Spanning Tree), which always exists.

The concept that trips everyone up: the MST region

For two switches to share MST instances, they must be in the same MST region. Two switches are in the same region only if all three of these match exactly:

If any one of these differs - even one VLAN mapped to a different instance, even a typo in the name - the two switches are in different regions. They will still interoperate, but they treat each other as a single boundary and exchange only the IST. All your carefully designed per-instance load balancing silently stops at the region boundary.

This is the number one MSTP misconfiguration. A switch added later with a slightly different VLAN-to-instance map becomes its own one-switch region, and nobody notices until traffic takes a strange path.

Configuration on Cisco IOS XE

Switching a Catalyst to MST mode and defining the region:

spanning-tree mode mst
!
spanning-tree mst configuration
 name PINGLABZ-REGION
 revision 1
 instance 1 vlan 10,20,30
 instance 2 vlan 40,50,60
 exit

That config block must be identical on every switch in the region. Same name, same revision, same instance mappings.

Then set the root bridges so the two instances load-balance. On the switch you want as root for instance 1:

spanning-tree mst 1 root primary
spanning-tree mst 2 root secondary

And on the switch you want as root for instance 2, the mirror image:

spanning-tree mst 1 root secondary
spanning-tree mst 2 root primary

Now instance 1 roots on the first switch, instance 2 roots on the second, and the redundant uplinks both carry traffic instead of one sitting idle in blocking.

Verifying the region and the instances

Confirm the region is formed correctly:

SW1# show spanning-tree mst configuration
Name      [PINGLABZ-REGION]
Revision  1     Instances configured 3
Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-9,11-19,21-29,31-39,41-49,51-59,61-4094
1         10,20,30
2         40,50,60
-------------------------------------------------------------------------------

Run this on every switch and compare the output. If the name, revision, or any mapping differs, you have an accidental region boundary.

Then check an instance's topology:

SW1# show spanning-tree mst 1

##### MST1    vlans mapped:   10,20,30
Bridge        address 0050.7989.bbbb  priority  24577 (24576 sysid 1)
Root          this switch for MST1

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------------
Te1/1/1          Desg FWD 2000      128.25   P2p
Te1/1/2          Desg FWD 2000      128.26   P2p

"Root this switch for MST1" confirms the root placement. Cross-check show spanning-tree mst 2 on the other switch to confirm the load-balancing split is real.

The IST and the CIST

Two more terms you will hit in the docs:

• IST (Internal Spanning Tree) - instance 0. It always exists and carries all unmapped VLANs. It is also what represents the whole region to the outside world.
• CIST (Common and Internal Spanning Tree) - the single spanning tree that spans across region boundaries and ties MST regions together with any legacy STP/RSTP switches. From the outside, an entire MST region looks like one big virtual bridge in the CIST.

The practical takeaway: inside a region you think in MST instances; at the boundary the whole region collapses to a single node in the CIST. This is why MSTP interoperates cleanly with older RSTP switches - they just see the region as one RSTP bridge.

MSTP vs Rapid-PVST+: which to run

Common gotchas

Key takeaways

MSTP maps many VLANs onto a few spanning tree instances, giving you load balancing across redundant uplinks without the per-VLAN overhead of Rapid-PVST+. The make-or-break concept is the region: name, revision, and VLAN-to-instance mapping must be byte-identical on every switch, or the switches silently split into separate regions and your load-balancing design stops working. Configure it once, verify with show spanning-tree mst configuration on every switch, and MSTP scales to hundreds of VLANs cleanly.

For the STP cluster, see the Spanning Tree Protocol pillar.