Hands-On Lab: Configuring Multiple Spanning Tree (MST)

This hands-on lab configures MST across two switches, mapping multiple VLANs into a single spanning-tree instance rather than running a separate instance per VLAN as PVST+ does, and verifies the resulting reduction in the number of independent spanning-tree calculations.

MST ConfigurationMST Region and Instance MappingReduced STP Overhead

~4 min read · Updated Sep 23, 2026

Lab Objective

Configure MST on two switches with matching region parameters, map several VLANs into a single MST instance, and verify both switches agree on the resulting topology while running far fewer independent spanning-tree calculations than PVST+ would require for the same VLANs.

Lab Purpose

PVST+ and Rapid PVST+, covered extensively earlier in this series, run one completely independent spanning-tree instance per VLAN. On a switch with hundreds of VLANs, this consumes significant CPU and memory for topology calculations that are often functionally identical across many VLANs sharing the same physical links. MST solves this by mapping multiple VLANs onto a much smaller number of actual spanning-tree instances.

Lab Topology

Switch1 ---- Gi1/0/1 ---- Switch2

VLANs 10, 20, 30, 40, 50 exist on both
switches, all sharing the same physical
topology and therefore not needing separate
independent spanning-tree calculations

Task 1: Configure the MST Region Parameters

Configure matching MST region name and revision number on both switches, a prerequisite for them to be considered part of the same MST region.

Task 2: Map VLANs to an MST Instance

Map VLANs 10 through 50 into MST instance 1 on both switches.

Task 3: Enable MST Mode

Change the spanning-tree mode to MST on both switches.

Task 4: Verify Both Switches Agree on the Region

Confirm both switches show identical region information, a requirement for them to be treated as the same MST region.

Task 5: Verify a Single Instance Governs All Mapped VLANs

Confirm the port roles and states for MST instance 1 apply uniformly across all five VLANs mapped to it, rather than each VLAN calculating independently.

Solution and Verification

Switch1(config)# spanning-tree mst configuration
Switch1(config-mst)# name REGION1
Switch1(config-mst)# revision 1
Switch1(config-mst)# instance 1 vlan 10-50

Switch2(config)# spanning-tree mst configuration
Switch2(config-mst)# name REGION1
Switch2(config-mst)# revision 1
Switch2(config-mst)# instance 1 vlan 10-50

-- The name, revision, and VLAN-to-instance
-- mapping must match EXACTLY between switches
-- for them to be considered the same MST
-- region -- even a minor mismatch causes
-- switches to be treated as separate regions

Switch1(config)# spanning-tree mode mst
Switch2(config)# spanning-tree mode mst

Switch1# show spanning-tree mst configuration

Name      [REGION1]
Revision  1    Instances configured 2

Instance  Vlans mapped
--------  -----------------------
0         1-9,51-4094
1         10-50

Switch2# show spanning-tree mst configuration

Name      [REGION1]
Revision  1    Instances configured 2

Instance  Vlans mapped
--------  -----------------------
0         1-9,51-4094
1         10-50
-- Identical output on both switches confirms
-- they agree on the region -- Instance 0
-- (the mandatory default, called IST) exists
-- automatically for any VLANs not explicitly
-- mapped elsewhere

Switch1# show spanning-tree mst 1

##### MST1    vlans mapped:   10-50
Bridge   address 00aa.bb00.1111  priority 32769
Root     this switch for MST1

Interface        Role Sts Cost      Prio.Nbr  Type
Gi1/0/1           Desg FWD 20000     128.1     P2p
-- This single MST1 calculation and port
-- role governs all 41 VLANs (10-50) mapped
-- to it -- PVST+ would have required 41
-- separate, independent spanning-tree
-- calculations to achieve the same result

Key Takeaway

MST's core efficiency gain comes from decoupling the number of spanning-tree instances from the number of VLANs — multiple VLANs sharing an identical topology can be mapped to a single instance, and every switch intending to participate in the same MST region must have byte-for-byte matching region configuration (name, revision, and VLAN-to-instance mapping), since even a trivial mismatch causes switches to be treated as separate regions with their own independent boundary calculations.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring Layer 3 EtherChannel

This hands-on lab configures a routed EtherChannel between two Layer 3 switches, bundling two physical links into a single logical routed interface rather than a switched trunk, and verifies OSPF forms a single neighbor relationship across the bundle rather than one per physical link.

Continue

Hands-On Lab: Configuring LACP Fast Rate

This hands-on lab configures LACPDU fast rate on an EtherChannel bundle, reducing the interval between LACP control packets to accelerate detection of a failed member link compared to the default slow rate.

Continue

Hands-On Lab: Configuring EtherChannel Load-Balancing Methods

This hands-on lab configures and compares different EtherChannel load-balancing algorithms, verifying how the choice of hashing input affects whether traffic is actually distributed evenly across bundled links or concentrated onto a single member link.

Continue

Hands-On Lab: Interconnecting MST and Rapid PVST+ Regions

This hands-on lab connects an MST region to a switch still running Rapid PVST+, verifying MST's built-in interoperability correctly represents the PVST+ switch's per-VLAN topology at the region boundary without requiring every switch in the network to migrate simultaneously.

Continue

Hands-On Lab: Configuring Voice VLAN

This hands-on lab configures a voice VLAN on an access switch port, allowing an IP phone and an attached PC to share a single physical port while remaining on separate VLANs, with the phone's traffic automatically tagged and the PC's traffic left untagged.

Continue

Hands-On Lab: Configuring GLBP Weighting for Load Balancing Control

This hands-on lab configures GLBP weighting tied to interface tracking, allowing the proportion of clients each forwarder serves to shift automatically based on a router's own health rather than always splitting load evenly, refining the basic GLBP configuration covered earlier in this series.

Continue