Bonding driver problem

Bonding driver problem

[Greg Rose]

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.

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.

Re: Bonding driver problem

[Jiri Pirko]

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.


>
>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.

Re: Bonding driver problem

[Greg Rose]

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.