Mesh, server blades and RSTP

[Anders_35]

Because of our blade-servers, we are running RSTP on all our switches. Unfortunately, this also includes our mesh (see drawing).
We would rather not run spanning-tree at all in the mesh, because of the problems the two have in working together (at least on 34xx/6400 switches). However, we don't see a way around it. Does anyone have a suggestion of how we could do this?
The reason we use spanning-tree for the blades, is because all blade servers are configured with Network Fault Tolerance teaming. As far as we can tell, this makes it necessary to have spanning-tree running on the blade switches.
We can't get these switches into production before we've solved this problem...

All tips appreciated :)

[Oleg Koroz]

GbE2 Interconnect Switch does allow the
disabling of spanning tree on a per switch or port basis. This capability is ideal for networks designed without loops or individual switch ports connected to server blades or other devices where a loop does not exist.


http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00111930/c00111930.pdf

[Anders_35]

Thanks, but the reason we need STP (as far as I know) is the fault tolerance.
During normal operations, both gbe2 switches will have open links to the mesh.
The NFT heartbeat is transmitted over these links, and if /any/ link between the two fails, the heartbeat is missed, and NFT switches to the other NIC.
Now picture this:
a server communicates through blade switch A, but the link from blade switch B to the mesh fails.
The active NIC can still communicate through switch A, but the heartbeat is missed, since switch B lost it's link.
NFT will now activate the card that's connected to switch B, even though that's where the failed link is.
If STP is enabled, switch B will still be on-line through the enclosure interconnect trunk. Without spanning tree, this trunk would have to be disabled to avoid loops.

[Les Ligetfalvy]

What are the issues with mesh and RSTP? I know only of problems with 802.1d STP.

If you cannot turn off spanning tree at the switches the blade servers connect to, you should still be able to turn it off at the other switches on specified ports.

[Anders_35]

Basically, the Mesh links have a tendency of just "disappearing" without trace when there are changes in the network. All causes are not known to me, but HP has fixed a lot of this. For instance, when a meshed switch boots, it doesn't cause the whole mesh to go down anymore. However, the 3400s seem to not interact well with RSTP on other switches.
Whether this is because of the 3400s or the other switches (blade switches and procurve 2626) I don't know.

But one mystery problem remains: when network topology changes (i.e. a switch boot) some meshed ports will be out of service for some time. The event log should state if RSTP or Meshing blocked the link, but no such notification is given.
I've left it to HP support to figure out how the links can just go "black hole" on me like that.
I've talked to people who say that they've run RSTP and Mesh together for a long time, though on other switches.
My guess is that there are problems with the 3400/6400 implementations, which I'm told is a whole new architecture.

Anyway, if I turn off spanning-tree on the 3400's, there is no point in having it on the blade switches, is there? I don't see how this would work. Am I missing something?