bonding-devel mail list?

bonding-devel mail list?

[Bill Carlson]

Hello,

Noted the old bonding-devel mail list at sourceforge is no more, is 
there an alternate?

Chasing whether a bond of bonds has an issue my testing hasn't revealed.

Thanks,

-- 

Bill Carlson

Anything is possible, given Time and Money.

Re: bonding-devel mail list?

[Jay Vosburgh]

Bill Carlson <billcarlson@wkks.org> wrote:

>Noted the old bonding-devel mail list at sourceforge is no more, is there
>an alternate?

	Use this list (netdev).

	Some time ago, I put a parking message on the bonding-devel list
redirecting people to netdev, but it appears that sourceforge deleted
the mailing list entirely at some point.

>Chasing whether a bond of bonds has an issue my testing hasn't revealed.

	As far as I'm aware, nesting bonds has no practical benefit; do
you have a use case for doing so?

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

Re: bonding-devel mail list?

[Bill Carlson]

On 5/23/19 11:46 AM, Jay Vosburgh wrote:
> As far as I'm aware, nesting bonds has no practical benefit; do
> you have a use case for doing so?
>
>
Use case is very specific, but needed in my situation until some 
switches are stabilized.

Switches A1..Ax provide LACP, 40G. These are unstable, lose link on one 
or more interfaces or drop completely. A single bond to the A switches 
was acceptable at first, including when one interface was down for quite 
a while. Then all A switches dropped.

Switches B1..Bx provide no LACP, 10G. These are sitting and connected 
anyway, already in place for backup.

All are on the same layer two, as in any MAC is visible on any switch.

Goal is to use A switches primarily, and drop back to B _IF_ A are 
completely down. As long as one interface is active on A, that will be used.

I assume LACP and active-passive can't be used in the same bond, 
interested to hear if I'm wrong.

My setup I achieved:

bond0 -> switches B, multiple interfaces, active-passive
bond1 -> switches A, multiple interfaces, LACP
bond10 -> slaves bond0 and bond1, active-passive
Various VLANs are using bond10.

Options to bonding:

bond0: mode=1 fail_over_mac=none miimon=100
bond1: mode=4 lacp_rate=1 miimon=100
bond10: mode=1 fail_over_mac=1 primary=bond1 updelay=10000 miimon=100
(I should probably change to arp monitoring, I know.)

updelay in place because LACP takes a long time to link.
Making sure the MACs switched was the key.

Network performance tests via iperf3 look good, including when dropping 
bond1. Unfortunately, target test system was on bond0, as its A switches 
were down.

The only, critical, test I haven't been able to perform is physically 
dropping A links, can't reach that far. :)

-- 

Bill Carlson

Anything is possible, given Time and Money.

Re: bonding-devel mail list?

[Jay Vosburgh]

Bill Carlson <billcarlson@wkks.org> wrote:

>On 5/23/19 11:46 AM, Jay Vosburgh wrote:
>> As far as I'm aware, nesting bonds has no practical benefit; do
>> you have a use case for doing so?
>>
>>
>Use case is very specific, but needed in my situation until some switches
>are stabilized.
>
>Switches A1..Ax provide LACP, 40G. These are unstable, lose link on one or
>more interfaces or drop completely. A single bond to the A switches was
>acceptable at first, including when one interface was down for quite a
>while. Then all A switches dropped.
>
>Switches B1..Bx provide no LACP, 10G. These are sitting and connected
>anyway, already in place for backup.
>
>All are on the same layer two, as in any MAC is visible on any switch.
>
>Goal is to use A switches primarily, and drop back to B _IF_ A are
>completely down. As long as one interface is active on A, that will be
>used.
>
>I assume LACP and active-passive can't be used in the same bond,
>interested to hear if I'm wrong.

	Well, yes and no.

	No, you can't explicitly configure what you describe (in the
sense of saying "slave A is LACP, slave B is active-backup").

	However, the logic in LACP will attach every slave of the bond
to an aggregator.  If one or more slaves are connected to a specific
LACP peer, they will aggregate together.  If any slave is connected to a
non-LACP peer, it will aggregate as an "individual" port.

	When bonding's LACP mode selects the best aggregator to use,
"non-individual" (i.e., connected to a LACP peer) ports are preferred,
but if no such ports are available, an individual port is selected as
the active aggregator.  The precise logic is found in the
ad_agg_selection_test() function [1].

	If what you've got works for you, then that's great, but I
suspect it would still work if all of the interfaces were in a single
802.3ad bond without the nesting.

	-J

[1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/tree/drivers/net/bonding/bond_3ad.c#n1562


>My setup I achieved:
>
>bond0 -> switches B, multiple interfaces, active-passive
>bond1 -> switches A, multiple interfaces, LACP
>bond10 -> slaves bond0 and bond1, active-passive
>Various VLANs are using bond10.
>
>Options to bonding:
>
>bond0: mode=1 fail_over_mac=none miimon=100
>bond1: mode=4 lacp_rate=1 miimon=100
>bond10: mode=1 fail_over_mac=1 primary=bond1 updelay=10000 miimon=100
>(I should probably change to arp monitoring, I know.)
>
>updelay in place because LACP takes a long time to link.
>Making sure the MACs switched was the key.
>
>Network performance tests via iperf3 look good, including when dropping
>bond1. Unfortunately, target test system was on bond0, as its A switches
>were down.
>
>The only, critical, test I haven't been able to perform is physically
>dropping A links, can't reach that far. :)
>
>-- 
>
>Bill Carlson
>
>Anything is possible, given Time and Money.

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

Re: bonding-devel mail list?

[Bill Carlson]

On 5/23/19 5:31 PM, Jay Vosburgh wrote:
>
> 	However, the logic in LACP will attach every slave of the bond
> to an aggregator.  If one or more slaves are connected to a specific
> LACP peer, they will aggregate together.  If any slave is connected to a
> non-LACP peer, it will aggregate as an "individual" port.
>
> 	When bonding's LACP mode selects the best aggregator to use,
> "non-individual" (i.e., connected to a LACP peer) ports are preferred,
> but if no such ports are available, an individual port is selected as
> the active aggregator.  The precise logic is found in the
> ad_agg_selection_test() function [1].
>
> 	If what you've got works for you, then that's great, but I
> suspect it would still work if all of the interfaces were in a single
> 802.3ad bond without the nesting.
>
> 	-J
Ah, hadn't considered LACP mode would accept non-LACP interfaces. I'll 
chase this.
Thanks.