Deep Dive into Multiple Spanning Tree Protocol (MSTP): Configuration and Troubleshooting

Despite the growing trend towards software-defined networking, network administrators, engineers, and operators still frequently deploy traditional Layer 2 Ethernet Switching to meet the demands of modern networks. Since many of these networks incorporate switches from a variety of vendors (e.g., Cisco, Juniper, Arista, Extreme Networks, etc.), having the skills to ensure seamless interoperability is crucial. Multiple Spanning Tree Protocol (MSTP) plays a key role in achieving this interoperability, ensuring loop-free topologies across devices from different manufacturers while still allowing for load-balancing across different VLANs and ensuring the most efficient use of network paths and resources.

In this post, we’ll dive deep into the configuration and troubleshooting of MSTP on Cisco Catalyst switches, exploring how this protocol can be effectively implemented to interoperate with other vendors' equipment.

What Problem Did MSTP Solve?

Prior to the advent of the Multiple Spanning-Tree Protocol (MSTP), a single Common Spanning-Tree (defined in IEEE 802.1D) instance was used to create a loop-free topology within a single broadcast domain. Originally, 802.1D was designed before the invention of VLANs, so it was natural that all ports on any bridge running Spanning-Tree would be operating within a single broadcast domain.

However, once VLANs were introduced to switches (as well as VLAN Trunks), VLANs - and the hosts placed within them - were now seen as individual groups, worthy of their own unique networking policies rather than as one giant collective whole. Having a single Spanning-Tree within the Layer-2 domain posed a problem, as the election of a single STP Root Bridge would often result in inefficient forwarding paths between hosts. 

Take the topology shown below as an example. Hosts in VLAN-X (Group-1) wishing to communicate with hosts in VLAN-X (Group-2) would need to travel over five distinct inter-switch links. This is because of the blocked port on switch SW-B, even though there is clearly a direct path between these groups (composed of links 1 and 6), which would be more efficient. 

One way to mitigate this problem would be to move the STP Root Bridge from switch SW-F to switch SW-B, but that might result in inefficient paths between hosts in other VLANs. Cisco then introduced the Per-VLAN Spanning-Tree Protocol (PVST) to their switches to solve this problem. 

PVST worked by implementing a unique instance of Spanning-Tree per VLAN, allowing network administrators to tune and influence the shape of individual Spanning-Trees. This solution worked well when a network had a limited number of VLANs (and thus a limited number of Spanning-Tree instances), but in some networks that utilized hundreds (or even thousands) of VLANs all within the same group of switches, PVST would not scale well due to the CPU overhead. Often, switches that supported PVST could only support a maximum of 64 or (at most) 256 Spanning-Tree instances, and even that quantity might impose a heavy load on a switch’s CPU resources. 

Since other vendors could not use Cisco’s PVST protocol, they either devised their own versions of per-VLAN Spanning-Tree or simply stuck with one Common Spanning-Tree instance for all VLANs. Eventually, recognizing the benefits and drawbacks of Cisco’s PVST protocol, the IEEE decided to update the 802.1D standard with the creation of 802.1s - Multiple Spanning-Tree Protocol (MSTP). 

The objectives of MSTP are very simple:

1. Create a Spanning-Tree protocol in which the network operator can create (and tune) individual Spanning-Tree instances to allow for efficient traffic forwarding.

2. Disassociate Spanning-Trees from VLANs, and instead apply groups of VLANs to a Spanning-Tree instance. 

The result is that load-balancing could occur using two or more instances of Spanning-Tree, with each instance supporting one (or several) VLANs. 

How Does MSTP Operate?

In order for two connected switches to successfully implement MSTP, they must be configured with some shared parameters, namely:

1. A common MSTP Region name

2. A common MSTP Revision number

3. A common set of MSTP Instance-to-VLAN mappings

The MSTP Region name is contained within an MSTP Bridge Protocol Data Unit (BPDU), and a receiving switch will not accept the BPDU if its local MSTP Region name differs from the received one. The Region name can be whatever you want…just ensure it’s the same on all switches. 

The MSTP Revision number is a manual indicator of how often the MSTP configuration has been changed or updated. There is nothing dynamic about it, so if you update your MSTP configuration, don’t expect this value to change; you would need to increment it manually. Just as the MSTP Region name is contained in BPDUs, so is the MSTP Revision number, and it needs to match on all switches. Some vendors don’t require configuration of the initial value of this number, and it can be ignored, while other vendors insist that you configure it. To be safe, configure this to be an initial value of “1” and then increment it as needed.

Lastly, the whole point of implementing MSTP is to allow you to create different forwarding paths for different groups of traffic. To accomplish this, VLANs are mapped to MSTP “Instances” which are numbered. By default, all VLANs are mapped to MSTP Instance zero (0), and therefore without configuring any additional MSTP instances, you are left with a single common Spanning-Tree. To accomplish load-balancing (e.g. traffic separation) you would need to configure at least one MSTP instance (giving it a numerical identifier of “1” or higher) and then map one or more VLANs to that new MSTP instance. All VLANs using that Instance would adhere to whatever forwarding path is created by that instance (based on the placement of the Root Bridge for that Instance, plus any modification of path costs, etc.).

Each MSTP instance contains its own STP Root Bridge and a forwarding/blocking path based on the placement of that Root Bridge. To implement traffic load-balancing, you have three options, as seen in the example figures below.

1. Use separate STP Root Bridges so that the Root Bridge for MSTP Instance-X is different from the Root Bridge for MSTP Instance-Y:⁠

   

2. Manually adjust MSTP path costs per-instance, raising or lowering the cost of individual links for individual MSTP instances:

   

3. Manually adjust MSTP port priorities per instance:

How to Configure MSTP

On Cisco switches, MSTP configuration is done in two steps:

1. Configure your MSTP parameters such as the Region name, Revision number, and Instance-to-VLAN mappings.

2. Enable the MSTP “mode” of operation (PVST or Rapid PVST is likely the default mode of Spanning-Tree running your Cisco switches).

Step 1: Configuring MSTP Parameters

Below is a configuration example of MSTP Parameters. In this example, the MSTP Region name is “INE” and the Revision number is “1”.

While still within “spanning-tree mst configuration” mode, you can issue the “show current” and “show pending” commands to display the current operation and configuration of Spanning-Tree, as well as view what will be applied upon exiting from this mode.

In the below example, the output of “show current” displays an empty field for the MST Region name and a Revision value of “0”:

The output of “show pending” can be used to verify what the applied MSTP configuration will be after exiting from the “(config-mst)” mode:

If you’ve made a mistake in your pending MSTP configuration, and you want to delete it and restart from scratch, issue the “abort” command:

Below is an example of creating a single MSTP instance (Instance 1) and allocating VLANs 50-100 to this instance. Also, this can be pre-configured even if the VLANs don’t yet exist on the switch. Notice that all other VLANs that have not been manually mapped to a new Instance will remain in Instance 0:

Step 2: Enabling MSTP Mode

Once your MSTP configuration is finished and matches on all relevant switches, switch over to operating in MSTP mode: 

The command “show spanning-tree summary” can be used to verify the current operational mode of Spanning-Tree on the switch:

How to Monitor MSTP

Once you’ve configured MSTP on your switches, the next logical question is how do I verify it’s working?

Each MSTP instance contains its own MSTP Root Bridge, as well as Root Ports, Designated Ports, and Blocking Ports dependent on the placement of that Instance’s Root Bridge. All of these items can be monitored and verified through the output of the “show spanning-tree mst” command. This output will display the information related to the Instance 0 tree first (called the Internal Spanning-Tree or IST”), followed by trees associated with any other manually configured MST instances (technically called the “MSTI’s”).

How to Troubleshoot MSTP

Switchports running MSTP are categorized as either MSTP “Internal” ports or MSTP “Boundary” ports. An “Internal” port is either a port connected to a device that does not implement the Spanning-Tree Protocol (such as a router, firewall, or end host device), or a port that is connected to another switch running MSTP. This detail can be seen with the command “show spanning-tree mst interface”, as shown below:

A “Boundary” port is one that has received a non-MSTP BPDU (so by inference this only applies to Root Ports and Blocking Ports), or an MSTP BPDU. If an MSTP BPDU has been received but the receiving port displays as “Boundary” this means something about that MSTP BPDU conflicts with the MSTP configuration on the local switch. That being said, ports displaying as “Boundary” are the most common cause for alarm when troubleshooting MSTP.

Below we can see a simple topology of three switches, all of which have been configured for MSTP: 

Switch SW3 is displaying some Boundary ports, and we need to determine why:

In this case, the three ports shown in the topology should be MSTP Internal ports, not Boundary ports. The most common reason for this discrepancy is a simple MSTP misconfiguration on one or more switches. The output below shows that the MSTP Region name on SW3 (which should have been “INE”) was misconfigured as “Cisco”, which is causing this issue. The same issue could also be caused by a mismatch between the MSTP Revision number, or the MSTP Instance to VLAN mappings:

Conclusion

MSTP offers a robust and scalable solution for managing Layer-2 networks, particularly in multi-vendor environments where interoperability is key. By supporting multiple spanning-tree instances, MSTP allows for both loop-free topologies and effective traffic load-balancing, making it a preferred protocol for complex VLAN setups. Correct configuration, monitoring, and troubleshooting of MSTP are essential for maximizing its benefits, as demonstrated by the need for consistent region names, revision numbers, and instance-to-VLAN mappings. 

Further Learning

For more information on implementing and troubleshooting MSTP on Cisco and other vendors’ platforms, be sure to check out the following INE courses that include detailed video tutorials, quizzes, and hands-on labs: 

• Load Balancing with the Multiple Spanning Tree Protocol (MSTP)

• Rapid Spanning-Tree and MST

• Implementing Arista EOS for Cisco Engineers

Whether you're just beginning your journey into Networking, or you’re already an experienced engineer, INE's training will equip you with the real-world skills needed to implement MSTP in the multi-vendor Ethernet networks of today and tomorrow.