In today’s complex network environments, it’s increasingly common to find equipment from multiple vendors coexisting. While this offers flexibility, it can also introduce challenges, particularly when dealing with fundamental protocols like Spanning Tree Protocol (STP). I recently encountered a classic interoperability issue between Fortinet FortiSwitches and Cisco Catalyst switches that highlights the importance of understanding STP variations.

The Interoperability Challenge: MST vs. PVST+

Our network utilized FortiSwitches running Multiple Spanning Tree Protocol (MST, IEEE 802.1s) and Cisco Catalyst switches running Per-VLAN Spanning Tree Plus (PVST+, Cisco proprietary). Both protocols aim to prevent network loops by intelligently blocking redundant paths, but they achieve this in different ways.

• PVST+ runs a separate instance of STP for each VLAN, allowing for VLAN-specific load balancing.
• MST maps multiple VLANs to a limited number of spanning tree instances (MSTIs) within an MST region. This is more efficient for larger networks as it reduces the CPU overhead compared to PVST+. MST also has a single Internal Spanning Tree (IST) instance (instance 0) that interacts with the outside world.

The core of the problem lies in how these different STP implementations communicate, especially regarding Bridge Protocol Data Units (BPDUs).

The Real-World Incident: The Plant Outage

We experienced frequent network outages at a manufacturing plant, requiring switch reboots. The issue was traced to a misconfiguration on the trunk links connecting the FortiSwitches and Cisco devices. Specifically, VLAN 1 was not being explicitly allowed on these trunk ports.

Why was this critical?

In a mixed MST and PVST+ environment, the Common Spanning Tree (CST), which is represented by MST’s Internal Spanning Tree (IST, instance 0), relies on the native VLAN (typically VLAN 1) to exchange BPDUs with PVST+ domains. MST uses untagged BPDUs on VLAN 1 for this communication.

Because VLAN 1 was absent from the trunks, the MST and PVST+ domains were essentially isolated from each other. Each segment operated under the false premise that it was the root of the spanning tree, leading to a “split-brain” scenario. This created a chaotic environment with broadcast storms, MAC address table instability, and ultimately, network collapse.

Understanding MST Regions and Interaction with PVST+

The Cisco documentation on “Understand the Multiple Spanning Tree Protocol (802.1s)” provides excellent insight into this. Key takeaways relevant to our issue include:

• MST Region Boundaries: An MST region is defined by a common configuration (name, revision number, and VLAN-to-instance mapping). If switches have differing configurations, they form separate regions, or a boundary exists.
• IST and External Interaction: The IST instance (instance 0) is responsible for interacting with any external STP domain, including PVST+. It essentially represents the entire MST region as a single virtual bridge to the outside world.
• BPDU Exchange: Inside an MST region, bridges exchange MST BPDUs containing information for the IST and all MSTIs. However, at the boundary with a PVST+ network, the MST region replicates the IST BPDU on all VLANs to simulate a PVST+ neighbor, ensuring that PVST+ switches receive BPDUs for each of their VLAN instances.

The Solution

The fix was surprisingly simple yet fundamental: we explicitly configured the trunk links between the FortiSwitches and Cisco switches to allow VLAN 1.

Once VLAN 1 was permitted on the trunks, the IST BPDUs could traverse the link, enabling the MST and PVST+ domains to communicate correctly. A single root bridge was elected, and the spanning tree topology converged, bringing stability back to the plant network.

This incident underscores a crucial point in network design: understanding how different STP implementations interact is paramount. While powerful, MST requires careful configuration, especially when interoperating with PVST+. Ensuring that VLAN 1 (or your designated native VLAN for CST communication) is properly trunked is a foundational step to avoid such outages.

The positive feedback from the on-site LAN support staff was a testament to the impact of resolving this critical interoperability challenge. It reinforces the need for thorough planning and validation in mixed-vendor environments.