Well it’s 2018, and i have the same grumble. Indeed the HP solution is dangerous as it designates a port that can’t actually carry the traffic for the vlans which the instance is configured for. In my opinion very stupid.

I think replacing the switches may be the way to go!

The point I was trying to raise, obviously with the wrong example, is that HP’s MSTP implementation considers using ports which are not carrying the VLANs of the instance. In my opinion, Cisco’s implementation of MSTP does “the right thing” by ignoring ports that don’t carry the VLANs of the instance. I say “the right thing”, because this is the behavior I usually want and I can’t find a situation where HP’s default would be more appropriate.

Yes, I know I can change the port priority, but that would mean that for every VLAN-change I do, I also need to re-calculate the MSTP-topology by hand to verify that this particular change won’t cause a disconnection when STP looses a link somewhere.

I’m relatively new in spanning tree as my topologies until now were so streight forward that I could not appreciate the Spanningtree protocol that much (like too much reading, an annoyingly habbit of vendors using different solutions etc.) From what I’ve found and tested until now,
I have to agree with Simon and Molina…

MSTP, in all configuration examples that I have seen and configs I tried, just asks for one or more MST instances (using only the standard default instance would defeat the whole purpose of using MST over RST) with designated primary (priotiy 0) roots and backup (priority 2) roots. The only problem with RST is that Cisco does not properly seems to be using this standardized protocol if not used with either its proprietary PVST+ or MST, meaning that in mixed network environments MST is your only available choice.

Maybee in your eyes the Cisco way of MST is better, and perhaps it realy is as I can’t yet realy judge on that. Personally I would prefer a resiliant switch hierarchy of which I can fully predict with certainty what wil happen if a switch goes down, or a trunk (ether-channel in cisco language) goes wasted.

I’m sure that you can come up with a more difficult networklayout, but the question is: where and when do you actually need such a difficult layout that the suggested solution by Simon and Molina would actually no longer work. It seems to me anyway that it’s a less error prone solution then to specifically deny certain VLAN’s on a link to make sure that the spanningtree follows what you would expect. I mean, what if a underqualified collegue – or worse, some visiting group of accountant bloaks with their personal el-cheapo switches accidentally decides to create a loop. That’s what Spanningtree is all about in the first place.

For your example you would create an instance for the management vlan that has a priority of 0 for the management switch and >0 for the other two. Then create another instance for the data vlan and set left as 0 and right as 8192 (or vice versa) and management as default (32768). Job done!

I have two trunked switches that I wish to terminate redundant data center drops into. I forbid the DC drop VLAN from the trunk, but…well, obviously you know what happens as your management/data config above exactly mirrors my issue.

I got quite the surprise when I plugged it together and my trunk was blocked! Time to set the cost/priority to ensure it’s never blocked and to put the DC drop vlan into the trunk as it’s virtually there (in STP terms) anyway.

I updated the post to include the “show tech all” output, which includes the configuration and pretty much every show-command available.

If I understand you correctly, you propose to split the MST-region into two separate regions? In the situation explained above, this will indeed solve the issue. However, the original problem we had with a customer was much more complex; simply splitting the region was not possible.

Feel free to review and correct my configuration, preferably without splitting the MST-region.