Re: Bonding driver problem

[Greg Rose <gregory.v.rose@intel.com>]

On Mon, 25 Feb 2013 23:18:35 +0100
Jiri Pirko <jiri@resnulli.us> wrote:

> Mon, Feb 25, 2013 at 11:10:08PM CET, gregory.v.rose@intel.com wrote:
> >
> >We're having some problems with the following commit:
> >
> >commit 409cc1f8a4149c26bbb8e5d3bacb36541ad371e2
> >Author: Jiri Pirko <jiri@resnulli.us>
> >Date:   Wed Jan 30 11:08:11 2013 +0100
> >
> >    bond: have random dev address by default instead of zeroes
> >    
> >    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, fix dev_assign_type values on the way.
> >    
> >    Reported-by: Pavel Šimerda <psimerda@redhat.com>
> >    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> >    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
> >    Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >According to our tester, Sibai, before the patch, the mac of bonding
> >device is assigned by default as zero when it has no slave. Once the
> >first slave is enslaved, the bonding device takes the mac of first
> >slave, then passes this mac to all slaves. 
> >
> >But with this patch, the mac of the bonding interface is assigned a
> >random mac, and when the slave device is enslaved, the bonding device
> >keeps taking the mac of the slave it last enslaved. And former
> >enslaved slaves keep reverting to their original mac.  So for  mode
> >1, since the first slave is the active one, the rest of the slaves
> >are the backup, because the mac of bonding is different than the
> >first slave, so the bonding device cannot receive packets.
> 
> I think I know what is the issue. bond->dev_addr_from_first should be
> set to false in bond_enslave. I will fix this tomorrow. Sorry for the
> inconvenience.

Thank you Jiri!  Looking forward to the patch.

- Greg

> 
> 
> >
> >When we tried test build that reverted this patch the issue she was
> >seeing went away and the bonding worked the she was accustomed to.
> >
> >This may be deliberate and we may have to change our test procedures
> >but we wanted to make sure.
> >
> >The specific use case is to use a two virtual functions each from a
> >different physical function port to create fail over bonding.
> >
> >Thanks,
> >
> >- Greg Rose
> >Networking Division
> >Intel Corp.