Multiple Spanning Tree (MST)

The default spanning tree mode on Cisco Catalyst switches is PVST+ or, on newer models, Rapid PVST+. These protocols result in a direct one-to-one mapping of spanning tree instances to VLANs (hence the term per-VLAN spanning tree). For example, if there exist eight VLANs on a switch, the switch must participate in eight independent spanning trees. This is often undesirable, as the number of actually unique spanning tree topologies is typically less than the number of VLANs (at worst, the two will be equal). Running only a single common spanning tree (CST, which is not supported on Cisco Catalyst switches) would be more efficient, but it does not allow for the design flexibility afforded by PVST.

Multiple Spanning Tree (MST) was created to allow for multiple spanning tree topologies while preserving scalability. MST enables an administrator to map an arbitrary number of VLANs to a single MST instance, resulting in the minimum number of instances needed to satisfy a design. If, for example, you have six VLANs but only two unique layer two topologies, you need only two MST instances.

MST Configuration

The topology below illustrates a common scenario wherein a layer two access switch carries four VLANs and has two uplinks to two distribution switches. Routed SVIs with HSRP have been configured on the distribution switches to provide redundant default gateways for the hosts in all four VLANs.

MST Configuration

We need to configure two MST instances on each of the three switches, both of which will carry two access VLANs. This is done in MST configuration mode. All VLANs are assigned to MST instance 0 by default, so we only need to define a second instance to carry VLANs 20 and 40.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Comments

Hey Jeremy, first - excellent write up. I do have a question about the configuration from existing PSVT+ to MST migration...

During BCMSN studies I've read that going from PVST+ to rapid-PVST did not require you to disable spanning tree features that were built into rapid spanning tree such as port-fast and backbone fast - basically rapid-pvst will use the configs for pvst+.

At the same time this article shows that if backbonefast & portfast is enabled for PSVT+ and you migrate to rapid-pvst, those configs actually get ignored (therefore article shows which features to disable.)

Would it be the same for MST since MST has portfast and backbonefast built in like rapid-pvst?

It's always helpful when using MST to validate the digest on all switches in a region: "show spanning-tree mst configuration mst". If your MST config is identical on all the switches of a region, then the digest must match. This can be really problematic if you have a large number of switches deployed in a region with hundreds or thousands of VLANs in use. Generally, a mismatch in digests indicates the VLAN lists are not matched.

Also important to note that any VLAN assignment to MST regions can include VLANs not found in the tree, but should be prepopulated with the VLANs assigned (including any future expansion).

Nice article and a good explanation on MST, but about the HSRP configuration. I always configure one switch as the master HSRP router. In the example above you have configured asymmetric HSRP routing. This configuration could result in the flooding of unicast traffic.

I ones read an article about this. I found the article again after some research on the internet, maybe it could be useful:

If I remember correctly, MST causes the spanning tree to reset and recalculate, when you add VLANs to it, resulting in the proposal to pre-populate the MST instances. I never had the time to lab it, so a comment on this would be welcome.

regards,
Phil

Jason Faraone (guest)
June 14, 2010 at 3:55 p.m. UTC

Phil, a bit late reading this but I learned the hard way that adding a VLAN will cause a re-calcuation of the MST instance. This caused a bit of downtime for me; I've since changed my configuration so that critical network traffic has its own MST instance.

In my case,

Instance 0 = VLANs that we aren't actually using
Instance 1 = VLANs that we use for everyday use (voice, desktop, etc)
Instance 2 = VLANs that carry critical PLC data for collection