Comments on: HP ProCurve: MST misbehaves /2008/06/03/hp-procurve-mst-misbehaves A collection of note-to-self's Sun, 24 Mar 2019 23:04:45 +0000 hourly 1 By: Jimbo /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-261420 Thu, 05 Apr 2018 12:31:23 +0000 oh… and for what it’s worth i paired mine with an old 3com in the lab, and the 3com did what we wanted and took the vlans into account.

By: Jimbo /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-261419 Thu, 05 Apr 2018 12:18:48 +0000 Hi Niobos,

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!

By: Niobos /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-54520 Mon, 20 Feb 2012 07:53:11 +0000 I’m not going to go into this again…

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.

By: Reinder /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-54452 Sun, 19 Feb 2012 16:54:48 +0000 Hi Niobos,

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.

By: Niobos /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-10418 Fri, 01 Apr 2011 19:00:09 +0000 Simon,
As I already replied to Molina above, your comment provides a workaround for this specific situation, not a solution. I can easily design a more complex example where there is no “right root” to choose.

By: Simon /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-10404 Fri, 01 Apr 2011 16:20:41 +0000 Looking at your posted configs there appears to be a glaring error. All switches are operating in the same MST instance with the same root priority! You are leaving MST to decide for itself what you intended. With MST you have to think about what you want your trees to look like and manually create them via different root priorities.

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!

By: Scott /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-2029 Fri, 28 May 2010 05:18:53 +0000 Arrrgh! I wish I had known/thought to look for this BEFORE I bought two Procurve switches. All my past experience was with Ciscos and I’d assumed the same behavior was configurable, even if not default.

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.

By: Niobos /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-1738 Thu, 19 Nov 2009 17:52:07 +0000 Molina,
Thank you for the response, but your comment does not provide a solution, but a workaround. I can easily draw a more complex topology where “choose the root right” is not possible.

By: Molina /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-1737 Thu, 19 Nov 2009 13:27:59 +0000 I seems that root of the problem is that you should configure the stp root of each instance. On the topology above, you need to define the management switch as the root of instance 1, and choose between the two switches, left and right, to be the root of instance 2. I can do it just seting the priority of each instance.

By: Niobos /2008/06/03/hp-procurve-mst-misbehaves/comment-page-1#comment-1128 Sat, 21 Feb 2009 11:02:56 +0000 Nicola,

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.