All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.