Re: how to handle bonding failover when using a bridge over the bond?

[Chris Friesen <chris.friesen@genband.com>]

On 02/14/2013 12:03 PM, Jay Vosburgh wrote:
> Chris Friesen<chris.friesen@genband.com>  wrote:

>> The problem is that L2 switch "B" still thinks that all the virtual
>> machines are accessible via L2 switch "A".  Thus any incoming packets
>> destined for a virtual machine will get dropped.
>
> 	I'm trying to track down the system I tested previously to see
> exactly how it is set up and why it works when yours does not.  It's
> possible that it doesn't work, and the testing we did simply missed this
> case.

After thinking about this for a while, it doesn't seem like a natural 
thing for either the bond or the bridge to care about--though if someone 
wanted to fix it generically that would be great.

It might be worth considering sending out a bonding-specific netlink 
message when a bond fails over, giving the name of the bond as well as 
the newly active slave device.  This would allow for an efficient 
userspace daemon to issue gratuitous arps for all the VM MAC addresses.

It almost seems like the most elegant way to deal with this would be to 
forgo the bond completely and just add both links into the bridge, then 
run STP to make sure there are no loops.  That way link pulls get 
handled immediately and STP will update the other L2 switches 
appropriately.  Unfortunately this doesn't seem to be an option for us 
since some apparently customers frown on a server participating in STP. 
(Not sure why, we're already dealing with much more complicated 
protocols...)

Chris