[teammgrd]: Use port-channel id as LACP key so that multiple port-channels from the peer can be distinguished #1117
Conversation
…he peer can be distinguished
|
In the current use-case which I'm aware, both sides are configured as two different port-channels. In your example, why is one side configured as single PC? Is this any specific use-case like MLAG or something? |
|
This is a case of mis-configuration where ports from different PO’s on one device (in this case SONiC) is connected to same PO on the other device (3rd party device). In such a case LACP is expected to identify such errors and not allow the mis-configured port to be part of the LAG.
From: Prince Sunny <notifications@github.com>
Reply to: Azure/sonic-swss <reply@reply.github.com>
Date: Wednesday, 6 November 2019 at 7:16 AM
To: Azure/sonic-swss <sonic-swss@noreply.github.com>
Cc: sandeep-kulambi <sandeep.kulambi@broadcom.com>, Author <author@noreply.github.com>
Subject: Re: [Azure/sonic-swss] [teammgrd]: Use port-channel id as LACP key so that multiple port-channels from the peer can be distinguished (#1117)
In the current use-case which I'm aware, both sides are configured as two different port-channels. In your example, why is one side configured as single PC? Is this any specific use-case like MLAG or something?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
| } | ||
| PoId = lag.substr(found+1); | ||
| /* Ignore all 0's in the Port-channel id*/ | ||
| PoId2 = PoId.erase(0, min(PoId.find_first_not_of('0'), PoId.size()-1)); |
There was a problem hiding this comment.
this part of logic can be improved, it should try to find the first digit, then use stol to get an integert and use it later.
|
retest this please |
There was a problem hiding this comment.
This approach will not work. Because lacp key_id is 16-bit number. What if someone creates PortChannel with id greater than 65535?
Also, What if we have PortChannel01 and PortChannel1? It is the same key id.
I suggest to introduce an additional field to config db for LAG: key_id.
It allows us to put desired key_id in the configuration.
Another approach would be to restrict PortChannel format to have a proper format.
We are testing LAG in our lab as well with SONiC and having a configurable "key_id" as suggested by pavel-shirshov would be more "future" proof (IMHO). Also, Key=0 should not be allowed since from IEEE-8021ax, paragraph 6.3.5 Capability identification: An administrative Key value and an operational Key value shall also be associated with each Aggregator. The operational Key is the Key that is currently in active use for the purposes of forming aggregations. Aggregation Ports that are members of a given Key Group can only be bound All Keys are 16-bit identifiers. |
…ng (sonic-net#1117) Co-authored-by: Jing Kan<jika@microsoft.com>
Upgrade submodule SAI head to latest commit 566d4a8 Signed-off-by: richardyu-ms <richard.yu@microsoft.com> Signed-off-by: richardyu-ms <richard.yu@microsoft.com>
What I did
When a member port is added to port-channel, ensure the lacp-key is updated by using the Port-channel id value as the key value.
Why I did it
If LACP key is not set, then the peer will not be able to distinguish the ports which are connected to different port-channels, as it will receive the actor key (lacp key) as 0 for all the ports from different port-channels.
Sonic== 2links ===3rd party device
On Sonic 2 POs are created.:
Link1 on Sonic is configured on PO1
Link2 on Sonic is configured on PO2.
On 3rd party device single PO is created and both links are added to same PO.
All the links are in sync on both POs on Sonic and also in PO on 3rd party device.
How I verified it
Configure the devices as mentioned above and see on the 3rd party device only one of the port comes up in the PO and the other one stays down.