layer 2 failover within the rack

Question

what do you do to avoid downtime caused by top-of-the-rack switch hang / malfunction? some possible solutions are can be found in this presentation.

i'm interested in hearing how do you approach the problem when automatic fail-over is necessary.

edit some possible options:

• spanning tree run at each server as suggested by womble
• ethernet bonding in active-backup mode as described here.

Answer 1

For things that need that level of protection (risk/reward calculation justifies the extra expense, given the low probability of occurance -- unless you're buying really shoddy switches they just don't fail very often) I just dual-path everything -- two switches, one hooked to an on-board NIC the other to an off-board NIC (preferably different models/manufacturers, to protect from driver/NIC failure), then the edge switches hook to a pair of distribution or core switches (as appropriate), which then hook up to a pair of core routers, and so on. Everything's duplicated.

Bonding is configured to test links via ARP and cutover to the other switch in the pair if, say, a core switch dies (although everything is cross-connected too). Let spanning tree deal with the redundancy, which in my experience is a lot more robust than the author of those slides suggests.

Answer 2

i'll answer myself in this case since idea of running STP at the client presented by womble slightly freaks me out. it seems that:

• bonding between the server and two independent switches with periodic connectivity checks [ arp_ip_target parameter ]
• RSTP in the core / between switches

is most reasonable solution.

Answer 3

We simply don't use 'top of the rack' switches. We either use blades with in-built switches that are trunked back to redundant distribution or core switches or we patch servers straight through to redundant distribution switches (ideally running VSS).