netdev - Re: [Bonding Draft Proposal] Add lacp_prio Support for ad

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] [day] [month] [year] [list]

Message-ID: <aF4fEGySN8Pwpnab@fedora>
Date: Fri, 27 Jun 2025 04:33:20 +0000
From: Hangbin Liu <liuhangbin@...il.com>
To: Jay Vosburgh <jv@...sburgh.net>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
Subject: Re: [Bonding Draft Proposal] Add lacp_prio Support for ad_select?

On Thu, Jun 26, 2025 at 04:28:35PM -0700, Jay Vosburgh wrote:
> Hangbin Liu <liuhangbin@...il.com> wrote:
> 
> >Hi Jay,
> >
> >We have a customer setup involving two separate switches with identical
> >L2/VLAN configurations. Each switch forms an independent aggregator
> >(port-channel), and the end host connects to both with the same number of
> >links and equivalent bandwidth.
> >
> >As a result, the host ends up with two aggregators under a single bond
> >interface. Since the user cannot arbitrarily override port count or
> >bandwidth, they are asking for a new mechanism, lacp_prio, to influence
> >aggregator selection via ad_select.
> >
> >Do you think this is a reasonable addition?
> 
> 	In principle, I don't see a reason not to use the system
> priority, et al, to influence the aggregator selection when bonding ends
> up with multiple aggregators.  I'm undecided as to whether it should be
> a separate ad_select policy or a "tiebreaker," but a separate policy is
> probably simpler to deal with.

There is only one system priority in the bond, which means all aggregators
share the same system priority — right?

Or do you mean we should also take the partner's system priority into account?

> 
> >If yes, what would be the best way to compare priorities?
> >
> >1. Port Priority Only. Currently initialized to 0xff. We could add a parameter
> >   allowing users to configure it.
> >   a) Use the highest port priority within each aggregator for comparison
> >   b) Sum all port priorities in each aggregator and compare the totals
> 
> 	I'm not a fan of this, as explained below.
> 
> 	Also, note that in LACP-land, when comparing priorities, the
> higher priority is numerically smaller, which makes "add them up and
> compare" a little counter intuitive to me.

Yeah..

> 
> >2. Full LACP Info Comparison. Compare fields such as system_priority, system,
> >   port_priority, port_id, etc.
> 
> 	I think it makes more sense to use the System ID (system
> priority and aggregator MAC address) from the LAG ID of the local
> aggregator.  In the bonding implementation, an aggregator is assigned a
> MAC when an interface is added, so the only aggregators lacking a MAC
> are ones that have no ports (which can't be active).

Same question, the system priority and aggregator MAC address are all same
in the same bonding interface. So how can we prioritize between two
aggregators within the same bond?

Unless we take the partner's System ID into account. Which looks like, if
we want to choose a better aggregator in bond, we need to config the switch side...

> 
> 	If we want to use the partner System ID, that's a little more
> complicated.  If aggregators in question both have LACP partners, then
> the System IDs will be unique, since the MAC addresses will differ.  If
> the aggregators don't have LACP partners, then they'll be individual
> ports, and the partner information won't be available.

Can we active a aggregator that don't have LACP partner? If not, then
we don't need to compare that aggregator.

> 
> 	Modulo the fact that bonding assigns a MAC to an aggregator
> before the standard does (for the System ID), this is approximately
> what's described in 802.1AX-2014 6.7.1, although the context there is
> criteria for prioritizing between ports during selection for aggregation
> when limited capabilities exist (i.e., 6 ports but only the ability to
> accomodate 4 in an aggregrator).
> 
> 	FWIW, the 802.1AX standard is pretty quiet on this whole
> situation.  It recognises that "A System may contain multiple
> Aggregators, serving multiple Aggregator Clients" (802.1AX-2014 6.2.1)
> but doesn't have any verbiage that I can find on requirements for
> choosing between multiple such Aggregators if only one can be active.  I
> think the presumption in the standard is that the multiple aggregators
> would or could be active simultaneously as independent entities.
> 
> 	Anyway, the upshot is that we can pretty much choose as we see
> fit for this particular case.

Yes

Thanks
Hangbin