bonding: why zero out bond_dev->dev_addr when last slave removed?

bonding: why zero out bond_dev->dev_addr when last slave removed?

[Chris Friesen]

Hi all,

I've got a couple questions about the bonding driver.


I was wondering about the rationale for zeroing out bond_dev->dev_addr 
when the last slave is removed from the bond.

Assuming bond0 is currently using the mac address of eth0 then doing

ifenslave -d bond0 eth0
ifenslave -d bond0 eth1
ifenslave bond0 eth1
ifenslave bond0 eth0

ends up changing the MAC address of the bond link. Given that the bond 
itself stays up during this time, why don't we let the bond device keep 
it's previous MAC address (at least if fail_over_mac is zero)?

Is this to account for the case where we move the bond to totally 
different devices such that the old MAC no longer belongs to one of the 
slaves but instead belongs to a NIC outside the bond?

Chris


-- 

Chris Friesen
Software Designer

3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.genband.com

Re: bonding: why zero out bond_dev->dev_addr when last slave removed?

[Jay Vosburgh]

Chris Friesen <chris.friesen@genband.com> wrote:
[...]
>I was wondering about the rationale for zeroing out bond_dev->dev_addr
>when the last slave is removed from the bond.
>
>Assuming bond0 is currently using the mac address of eth0 then doing
>
>ifenslave -d bond0 eth0
>ifenslave -d bond0 eth1
>ifenslave bond0 eth1
>ifenslave bond0 eth0
>
>ends up changing the MAC address of the bond link. Given that the bond
>itself stays up during this time, why don't we let the bond device keep
>it's previous MAC address (at least if fail_over_mac is zero)?
>
>Is this to account for the case where we move the bond to totally
>different devices such that the old MAC no longer belongs to one of the
>slaves but instead belongs to a NIC outside the bond?

	More or less.  When the last slave is removed from the bond,
several properties of the bond are reset to an initial state, one of
which is that the bond's MAC is reset to all zeroes.

	If fail_over_mac is set to "active," then the bond must use the
MAC of one of its slaves, as the implication is that the slaves cannot
or should not change their MAC addresses.  In this case, I believe the
bond's MAC will be set to the first active slave's MAC, so holding over
the bond's MAC makes no practical difference.

	For fail_over_mac=follow, if the bond kept its MAC, then it
would be possible for both slaves to end up with the same MAC (because
the follow logic will set the first slave to the bond's MAC when it is
made active, and the second slave will keep its MAC after enslavement,
and those could be the same MAC if the second slave is the one the bond
originally got its MAC from).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com