From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [Issue] Bonding can't show correct speed if lower interface is bond 802.3ad
Date: Mon, 08 May 2023 11:32:16 -0700 [thread overview]
Message-ID: <84548.1683570736@vermin> (raw)
In-Reply-To: <ZFjAPRQNYRgYWsD+@Laptop-X1>
Hangbin Liu <liuhangbin@gmail.com> wrote:
>On Fri, Apr 28, 2023 at 09:06:40AM -0700, Jay Vosburgh wrote:
>> Hangbin Liu <liuhangbin@gmail.com> wrote:
>>
>> >A user reported a bonding issue that if we put an active-back bond on top of a
>> >802.3ad bond interface. When the 802.3ad bond's speed/duplex changed
>> >dynamically. The upper bonding interface's speed/duplex can't be changed at
>> >the same time.
>> >
>> >This seems not easy to fix since we update the speed/duplex only
>> >when there is a failover(except 802.3ad mode) or slave netdev change.
>> >But the lower bonding interface doesn't trigger netdev change when the speed
>> >changed as ethtool get bonding speed via bond_ethtool_get_link_ksettings(),
>> >which not affect bonding interface itself.
>>
>> Well, this gets back into the intermittent discussion on whether
>> or not being able to nest bonds is useful or not, and thus whether it
>> should be allowed or not. It's at best a niche use case (I don't recall
>> the example configurations ever being anything other than 802.3ad under
>> active-backup), and was broken for a number of years without much
>> uproar.
>>
>> In this particular case, nesting two LACP (802.3ad) bonds inside
>> an active-backup bond provides no functional benefit as far as I'm aware
>> (maybe gratuitous ARP?), as 802.3ad mode will correctly handle switching
>> between multiple aggregators. The "ad_select" option provides a few
>> choices on the criteria for choosing the active aggregator.
>>
>> Is there a reason the user in your case doesn't use 802.3ad mode
>> directly?
>
>Hi Jay,
>
>I just back from holiday and re-read you reply. The user doesn't add 2 LACP
>bonds inside an active-backup bond. He add 1 LACP bond and 1 normal NIC in to
>an active-backup bond. This seems reasonable. e.g. The LACP bond in a switch
>and the normal NIC in another switch.
>
>What do you think?
That case should work fine without the active-backup. LACP has
a concept of an "individual" port, which (in this context) would be the
"normal NIC," presuming that that means its link peer isn't running
LACP.
If all of the ports (N that are LACP to a single switch, plus 1
that's the non-LACP "normal NIC") were attached to a single bond, it
would create one aggregator with the LACP enabled ports, and then a
separate aggregator for the indvidual port that's not. The aggregator
selection logic prefers the LACP enabled aggregator over the individual
port aggregator. The precise criteria is in the commentary within
ad_agg_selection_test().
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
next prev parent reply other threads:[~2023-05-08 18:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 7:36 [Issue] Bonding can't show correct speed if lower interface is bond 802.3ad Hangbin Liu
2023-04-28 16:06 ` Jay Vosburgh
2023-05-08 9:26 ` Hangbin Liu
2023-05-08 18:32 ` Jay Vosburgh [this message]
2023-05-09 3:16 ` Hangbin Liu
2023-05-10 7:50 ` Hangbin Liu
2023-05-10 16:57 ` Andrew J. Schorr
2023-05-10 17:14 ` Andrew J. Schorr
2023-05-12 1:38 ` Jay Vosburgh
2023-05-12 14:44 ` Andrew J. Schorr
2023-05-16 15:11 ` Andrew J. Schorr
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=84548.1683570736@vermin \
--to=jay.vosburgh@canonical.com \
--cc=liuhangbin@gmail.com \
--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).