MSTP with different VLANs blocking port

Question

I am trying to use MSTP with HP Procurve switches. The edge switch (D in diagram) has half of the ports set to VLAN10 and half set to VLAN20, all untagged.

The problem is that the switch D to forward on port 1 (red line) but block the port 2 (blue line). Therefore VLAN20 ports do not function. What would be the best way to resolve this problem?

• I am able to resolve this issue if I use the bpdu-filter on switch D

# spanning-tree ethernet 2 bpdu-filter

But possibly, this is not the best solution.

• On the D router I tried to assign different instances for VLAN10 and VLAN20

# show spanning-tree mst-config
...
  Instance ID Mapped VLANs
  ----------- ---------------------------------------------------------
  1           10
  2           20

However, one of the ports are still in Blocking state.
If I setup same config-name and config-revision and instance settings on all four switches.

For reference the configuration on all switches is as follows:

spanning-tree config-name "TEST"
spanning-tree config-revision 1
spanning-tree instance 1 vlan 10
spanning-tree instance 2 vlan 20

With switch A having (so it can become root)

spanning-tree config-name "TEST"
spanning-tree config-revision 1
spanning-tree instance 1 vlan 10
spanning-tree instance 1 priority 4
spanning-tree instance 2 vlan 20
spanning-tree instance 2 priority 4

Why would having this configuration in all 4 switches are causing port to be blocked?

But also I find the configuration sort of cumbersome as same configuration needs to be put manually into every switch if I am not mistaken. Can there be a better solution?

Answer 1

In order for MSTP to split VLAN traffic across redundant trunks you need to configure MSTP instances in the exact same way on all switches within a region. The switches exchange config digests that need to match exactly. Otherwise, all switches just use the IST which is the same as a VLAN-agnostic RSTP config.

You could also use different MSTP regions (STP domains) but that's not the point of MSTP and prevents future expansion. bpdu-filter effectively disables xSTP on those ports, which likely isn't your goal.

When the instances are cleanly separated you have to select and configure potentially different root switches and port priorities, so that the various spanning trees can utilize all the physical links you've got.

What you are trying looks like something that could work with Cisco's RPVST+ but that's a really different angle.

With few VLANs, you could create an MST instance for each VLAN and pretty much work with them as you work with VLANs in RPVST+. Either move the instance root or change port priorities so that the instance's spanning tree uses the desired ports and links.

Most switches have a rather low limit of MST instances, so if there are many VLANs you'd need to group them into the MSTIs. In reality, there aren't that many redundant links to arrange so you're usually fine with two or three MSTIs.

Answer 2

You have a fairly common problem with MSTP, which is thinking it should work like PVST, when it's a completely different animal.

The concept that you have to get your head around is that in PVST you create VLANs and then run spanning trees on them. In MSTP you make spanning trees and run VLANs on them. MSTP frames do not care about port VLAN assignments, and so neither do the resulting spanning trees.

The first thing you need to do if you want to load balance is to assign the VLANs to different instance trees. As @Zac67 said, it's important that the mapping is the same for all switches in the MSTP region. That looks good so far.

So now you have four switches in a ring: one of the links is blocked in each instance tree. That's unavoidable barring hacks like bpdu-filter. All other things being equal, it's going to be the highest numbered port on switch D for both instance 1 and instance 2.

To get flip instance 2 you can increase the path cost on switch D for the CD link or change the port priorities. Having done that I would add all the VLANs you use on all the trunks (unless you have some security policy against that). That gives you some redundancy, and makes it less likely that you accidentally have a broken configuration.

Designing and implementing a MSTP configuation by hand can be cumbersome. Whether it's worth it depends on your traffic patterns.