Hi,

I have a few questions regarding the mixing of port-speeds in link aggregates and how it is handled by teamd. It's about how teamd is fulfilling the requirement that a Link Aggregation Group should consists of N parallel instances of full duplex point-to-point links operating at the same data rate.

The most obvious case is when a link in a LAG has its speed changed (either manually by configuration or automatically by autoneg). In the current setup of teamd that we have (lacp runner), a link that has its speed lowered will still be a part of the aggregate, a set with three 100 MBit links and one 10 Mbit link will still be aggregated together (same applies for mixing with GBit ports as well of course).

Q1. Is there a way to configure teamd to automatically disable ports/links of lower port speed, e.g. through "agg_select_policy"?
Q2. If the answer to Q1 is no, I am hopeful about the option to use dynamic keys (see my test (3) below). Is there a reason for this not being a part of teamd? Maybe some side-effects that I have missed?
Q3. Or is it so that this problem is generally avoided manually, i.e. it is a implicit requirement to manually see to it that links with different speeds are never configured to be part of the same LAG?
Q4. Or is there a totally different solution to this that I have overlooked completely?

Some background to the experiments I have done:
I have tested three main approaches to see if I can get the low speed 10 Mbit link to be disabled from the LAG:

1. I have tested with setting the parameter "agg_select_policy" to "bandwidth" for the lacp runner in the hope that agg_lead would be set differently and automatically disable the low speed 10 Mbit link. But it does not.

2. I wrote a patch that actively disables ports that have a lower speed than the highest in the LAG. It calls a evaluation function from for example lacp_port_link_update and lacpdu_recv to iteratate over all links and disable those that of lower speed. The code is located here (branch wmo/mismatch commit 4b1eca47624c6dc39a59efebcc6480ed5b33f47b):
https://github.com/westermo/libteam.git
I'm not entirely happy with this patch, but is food for the discussion though.

3. I have tried to see if operational key could be a solution. As 802.1ax states in clause 5.6.2 "Dynamic allocation of operational Keys":
"In the course of normal operation a port can dynamically change its operating characteristics (e.g., data rate, full or half duplex operation). It is permissible (and appropriate) for the operational Key value associated with such a port to change with the corresponding changes in the operating characteristics of the link, so that the operational Key value always correctly reflects the aggregation capability of the link. Operational Key changes that reflect such dynamic changes in the operating characteristics of a link may be made by either System without restriction."

Since it seems that teamd does not actively set key on the outgoing lacp frames, I have tried out code that sets lacp_port->actor.key in lacp_port_link_update() based on the speed of the port. This in turn means that lacp_ports_aggregable at the partner will in fact rule out lower priority links/ports as expected. It seems to work very well in fact. Is this a plausible way forward?

Thanks for your time, and all feedback is appreciated.

Best Regard, Leif