From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: billcarlson@wkks.org
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: bonding-devel mail list?
Date: Thu, 23 May 2019 15:31:56 -0700 [thread overview]
Message-ID: <32364.1558650716@famine> (raw)
In-Reply-To: <ec7a86ec-56e0-7846-ed02-337850fc8478@wkks.org>
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
next prev parent reply other threads:[~2019-05-23 22:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 15:31 bonding-devel mail list? Bill Carlson
2019-05-23 16:46 ` Jay Vosburgh
2019-05-23 20:06 ` Bill Carlson
2019-05-23 22:31 ` Jay Vosburgh [this message]
2019-05-24 12:56 ` Bill Carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32364.1558650716@famine \
--to=jay.vosburgh@canonical.com \
--cc=billcarlson@wkks.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).