netdev - Re: bonding-devel mail list?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 May 2019 15:31:56 -0700
From:   Jay Vosburgh <jay.vosburgh@...onical.com>
To:     billcarlson@...s.org
cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: bonding-devel mail list?

Bill Carlson <billcarlson@...s.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@...onical.com