APA link failure when spanning-tree happens in network

[chisle]

We don't allow our network devices (servers) to use spanning-tree, due to the traffic that occurs.

however, there was a blade failure on a Cisco switch last night, and when that occured, the switches kicked off spanning-tree. Similarly, when the engineers plopped the new card in, spanning-tree went out as well again.

I have two rx6600 (ia64, B.11.31) configured with HP APA.

the APA on the one host, though it spans two switches that are not interconnected, ended up bringing down lan900 completely, thus forcing the IP offline.

[chisle]

More info...

ia64, rx6600
B.11.31, latest QPK and a recent patch scan an dupdate

both nodes running HP SG, so, of course, package failed over in this event.

[Matti_Kurkela · Accepted solution]

Unless you have done something to make your servers act as network bridges, there should be no need for STP at the server level. STP concerns with bridge devices only.

If your network is using the classic Spanning Tree Protocol and the network topology changes (a switch or a link between switches is connected/disconnected), then it's normal for the STP to take up to 30-50 seconds to converge to a new configuration.

There are improvements to the classic STP, namely RSTP (Rapid STP), MSTP (Multiple STP, a superset of RSTP) and various proprietary solutions. They typically respond to network topology changes much faster.

How exactly is your APA configured? Have you verified that both physical ports are in fact up and ready with APA when the system is in normal state?

Since your physical ports are connected to two different switches with no interconnect, neither FEC nor LACP mode should work. I guess you're using HOT_STANDBY, either in MANUAL or LAN_MONITOR mode.

If you're using LAN_MONITOR and the switches are not interconnected, the APA poll packets must apparently go through a *third* switch to be able to go out of one physical port and in another. While STP was converging, one of the links required for this may certainly have been down, causing a false failure detection.

MK

[chisle]

Thank you for your lengthy, informative response!

We are using HOT_STANDBY with LAN_MONITOR for our SG configuration for the primary adapter of the server.

I believe both switches are actally hooked together to another switch, which then, in turn is attached to the router, so I can see now, that this is a single point of failure, which we will need o remdiate at some point.

Thank you.