To deal with loops in switched networks, the Spanning Tree Protocol was developed. For a description of how STP works, see the Wikipedia page on the subject; in short, it disables certain ports on certain switches to break loops. So far so good.
When using VLANs, there are several alternatives:
- Use a Common Spanning Tree: i.e. use the same topology for all VLANs.
- Use Per Vlan Spanning Tree: i.e. run a separate STP instance for each VLAN.
- Use Multiple Spanning Tree: This is the IEEE standard and is a compromise.
In MST, VLANs can be mapped to instances. All VLANs mapped to the same instance share the same Spanning Tree. This allows some flexibility by using multiple instances, without the CPU problems of running a single instance for each and every VLAN.
This diagram uses only 2 VLANs: a data VLAN, drawn in blue, and a management VLAN, in red. The data VLAN is used to connect the Left and Right switch together, along with the attached servers. The management VLAN is only used to manage the switches.
When implementing this on Cisco switches (I tried it on Catalyst 3750s), everything works as expected. The two servers can talk to each other, both switches are manageable.
When implementing this on HP ProCurve switches (I tried it on 5400s, 2610s and 2810s), this does not work: Depending on the MAC-addresses of the switches, either the servers cannot talk to each other or one of both switches is disconnected from the management station…
This simple setup uses a single MST region with the following instance mapping:
- VLAN management (red) to instance 1
- VLAN data (blue) to instance 2
In my test-lab, the Management switch had the lowest MAC-address, so it became the root bridge. Both switches Left and Right happily joined the party and decided that the blue trunk between them was redundant and should be put into a blocking state, thereby cutting the connection between both servers:
RIGHT# show spanning-tree instance 2 Port Type Cost Priority Role State Bridge ----- --------- --------- -------- ---------- ---------- ------------- <...> 20 100/1000T 200000 128 Root Forwarding 001db3-xxxxxx <...> Trk1 100/1000T 20000 128 Alternate Blocking 001db3-yyyyyy
The problem seems to be that HP does not take the VLAN assignments into account when calculating the MST topology, which was the whole purpose of developing MST over STP. After 4 months of mailing to/from HP Support, I finally got that confirmed:
> Am I correct if I summarize it as follows:
> MSTP does not take the VLAN-assignments into account when calculating its spanning-tree.
> Therefore, all VLANs should be allowed on redundant links.
> Does HP ProCurve consider this a bug? Or is this expected behaviour?
Your statement about MSTP is correct. I mean MSTP function is create a loop-free connection between switches. It is mainly a configuration of Ports.
Clearly, HP does not consider this a bug. Strangely enough, Cisco will work just fine in this scenario…
I re-checked this with ProCurve’s EMEA Technical consultant. Some quotes from his reply:
If Cisco works as you say, it must do a check for all VLANs within the instance and that could make sense. On the practical side, you’re responsible for the VLAN configuration. If you understand well what is the primary link and what is/are backup links, and if you configure the right VLAN On it, that should work.
That is true as well with PVST.
In your example, we could say that STP does not make sense because there is no loop by VLAN Construction.
But the thing is that PVST will detect it but not MSTP (at least on ProCurve) which does not care about VLANs.
This confirms what I already said: ProCurve’s implementation assumes that all VLANs are allowed on all ports. If this assumption is not correct (as in the fairly simple example above), MST might converge “wrong”.
For those interested: I just retried this on our lab-setup. The config is not completely the same as described above, but very similar. Here are the (gzipped) outputs of “show tech all” for the three switches. I also did a “show spanning-tree instance 1” to demonstrate the problem.