we're sharing a server room with another company, including the network infrastructure. All the switches are HP ProCurve, in various models depending on port need and so on. We're using VLANs to separate traffic to various virtual servers

Problem description:

We have six switches in two racks, where one in each rack is used for management (ILO, IPMI and so on), and the other two are set up for redundancy. Let's call them A, B and C, and D, E and F. A and D are the management switches. B is connected to E, and C to F, and there is a trunk between B and C where all our VLANs are supposed to be transported. In addition, E and F has similar trunks to the main switches, these trunks only allow a few VLANs with public traffic.

The STP designated root is in one of the main “backbone” switches on the outside of E and F, and of course, to avoid loops, that root switch has disabled the trunk between B and C. The result is of course that traffic on our internal networks can't reach all the switches, and then hilarity ensues.


Is it reasonable to enable root-guard on the trunk ports on E and F, on both sides of the trunks, to create a situation with two root switches? Hopefully this would mean that the root switch on the inside of the root-guard will be aware of all the VLANs that the root switch on the outside isn't.

As far as I can tell, HP doesn't support per-VLAN STP. Are there other solutions I should consider here, preferably ones which wouldn't require new hardware or huge amounts of downtime to implement.

  • (Standard first question for ProCurve issues because it fixes 90% of problem) Are you running the latest firmware on all switches? You say "there is a trunk between B and C", sounds like you have bonded ports between just those two. In the next sentence you say "E and F has similar trunks to the main switches" which makes it sound like B is not connected to C, E is not to F, and all four are connected somehow to some core switching fabric. "The result is of course that traffic on our internal networks can't reach all the switches" that doesn't sound right... why "of course"?? – Chris S Jan 4 '12 at 13:59
  • The switches are connected together like this (omitting the management switches here): Outside <-> E <-> B <-/-> C <-> F <-> Outside. The link between B and C is set to blocking, all other to forwarding. The "outside" switches are connected together, so physically (E and B) can connect to (C and F), just not logically since the necessary VLANs don't exist on the Outside switches. – Vegar Nilsen Jan 4 '12 at 14:15
  • If I'm following, it sounds like it should work. Was this setup working at one point in time? – Chris S Jan 4 '12 at 14:30
  • Every switch, ours and the other company's, was managed by the other company previously. That meant that they added every VLAN to all the necessary paths, and then it worked. After we split up the responsibility there's been strange network connectivity issues that I've recently tracked down to this STP situation. As mentioned in the question, the problem is caused by STP blocking the only link where our private VLANs are allowed, and instead forwarding on the outside link where these VLANs are not allowed. – Vegar Nilsen Jan 4 '12 at 14:34
  • 1
    I understand now, I'll blame my density on it being early morning here. Truebsalgeblaese has the correct answer, you have to configure MSTP for per-vLAN STP. – Chris S Jan 4 '12 at 14:44

Most ( = not too old) ProCurve switches support MST - here you can set up several instances of STP for a group (1-many) VLANs each.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.