You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the IEEE standard, it mentions the following:
All Keys are 16-bit identifiers. All values except the null value (all zeros) are available for local use.
(This is at the end of section 6.3.5 of the document 2014 edition of 802.1ax document at IEEE). Going over all the subsquent corrigendums of the document did not alter that section.
I believe that the current implementation that allows the key to be 0 (and even sets it by default) creates an interoperability issue.
This default should be changed to 1 (or any other 16-bit value) to comply with the standard.
and the code checks that the following:
} else if (tmp < 0 || tmp > USHRT_MAX) {
teamd_log_err("%s: \"lacp_key\" value is out of its limits.",
port_name);
I believe the check should be changed to <1
I can provide a patch on the mailing list but wanted to raise the issue first.
There are real interoperability issues seen in the field with devices that do not accept 0 as a partner key. Its true that a simple config change solves this but it would be good to not allow values which are not valid according to the standard.
The text was updated successfully, but these errors were encountered:
Looking at the IEEE standard, it mentions the following:
(This is at the end of section 6.3.5 of the document 2014 edition of 802.1ax document at IEEE). Going over all the subsquent corrigendums of the document did not alter that section.
I believe that the current implementation that allows the key to be 0 (and even sets it by default) creates an interoperability issue.
Looking at the code in https://github.com/jpirko/libteam/blob/master/teamd/teamd_runner_lacp.c, we see that the default value for they key is
This default should be changed to 1 (or any other 16-bit value) to comply with the standard.
and the code checks that the following:
I believe the check should be changed to
<1
I can provide a patch on the mailing list but wanted to raise the issue first.
There are real interoperability issues seen in the field with devices that do not accept 0 as a partner key. Its true that a simple config change solves this but it would be good to not allow values which are not valid according to the standard.
The text was updated successfully, but these errors were encountered: