Re: active-backup/bonding with drivers not supporting set_mac_address()

[Or Gerlitz <ogerlitz@voltaire.com>]

Jay Vosburgh wrote:
> Or Gerlitz <ogerlitz@voltaire.com> wrote:
> 
>> Looking on the linux bonding driver, it seems to unconditionally (*)
>> assume that the enslaved device supports the set_mac_address call.
>>
>>From reading the doc (Documentation/networking/bonding.txt) i understand that
>> it is **not** a must prerequisite for the active-backup mode, this is since
>> there is at most one active slave at each point of time and as the doc states:
>>
>> 	when a failover occurs in active-backup mode, bonding will issue
>> 	one or more gratuitous ARPs on the newly active slave.
> 
> 	I think you're misreading the documentation a bit.  Some
> specific modes (balance-alb, for example) require that the slave device
> driver support set_mac_address while the device is up.  Many device
> drivers will only allow MAC changes while the device is down; those
> drivers won't work with the alb mode.
> 
> 	The active-backup and other modes have always needed a set_mac
> functionality, but they don't require that the device be up when
> changing the MAC (those modes set the mac for a slave one time, during
> the enslavement process, and the device is down when this is done).

Thanks for clarifying and sharpening this point; however thinking about 
set_mac_address for active-backup mode i could not convince myself that 
there is a **need** for that. However, at high level it does make some 
(much) sense that the bond net device exposes a mac which is not changed 
when the active slave changes.

> 	The purpose of the gratuitous ARP is to update switch forwarding
> tables (i.e., announce that the device has moved from one port to
> another), not to announce a change of MAC address.

I see, but it will have the affect of MAC address change announcement.

> 	I think changing active-backup (as an example here) to cause a
> MAC change during failover will have some side effects and secondary
> requirements that aren't necessarily obvious.  For example, the MAC of
> the bond itself will change during failover; I'm not sure right offhand
> what effect if any this might have on third parties.

I will be glad to know if you have more concrete ideas what would be the 
possible problems with such impl.

Or.