Re: [patch net-next V2] bond: have random dev address by default instead of zeroes

[Jiri Pirko <jiri@resnulli.us>]

Fri, Jan 25, 2013 at 06:53:07PM CET, fubar@us.ibm.com wrote:
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>>Fri, Jan 25, 2013 at 07:37:13AM CET, jiri@resnulli.us wrote:
>>>Fri, Jan 25, 2013 at 02:35:01AM CET, fubar@us.ibm.com wrote:
>>>>Jiri Pirko <jiri@resnulli.us> wrote:
>>>>
>>>>>Makes more sense to have randomly generated address by default than to
>>>>>have all zeroes. It also allows user to for example put the bond into
>>>>>bridge without need to have any slaves in it.
>>>>>
>>>>>Also note that this changes only behaviour of bonds with no slaves. Once
>>>>>the first slave device is enslaved, its address will be used (no change
>>>>>here).
>>
>>
>>Also, this is not entirely true now. Example:
>>
>>eth1 has 52:54:00:b8:30:0b
>>
>># ip link add bondx address 22:33:44:55:66:77 type bond
>># ip link set eth1 master bondx
>>
>>Now both bondx and eth1 has 22:33:44:55:66:77
>>
>>Shouldn't both have 52:54:00:b8:30:0b ?
>
>	This is the way bonding has worked for as long as I can recall.
>The MAC of the first slave is assigned to the master, unless the bond
>has had its MAC manually set to something prior to the first slave being
>added.  If the bond's MAC has been set manually, then that MAC is used
>instead of the first slave's MAC.
>
>	Your patch doesn't appear to change that behavior, but it does
>substitute a random MAC in place of the all zeroes MAC used previously
>(and tests a flag to determine if the MAC has been manually set instead
>of checking for the all zeroes MAC).

Yeah, I know my patch is not changing this. I was just making sure it is
correct.

>
>	I know of customers that rely on this behavior to explicitly set
>the MAC of the bond (for filtering or accounting purposes).  It probably
>should be documented more clearly, but I don't think it should be
>changed.
>
>	-J
>
>---
>	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>