-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for static FDB Entries to allow MAC Move #1024
Conversation
* @default false | ||
* @validonly SAI_FDB_ENTRY_ATTR_TYPE == SAI_FDB_ENTRY_TYPE_STATIC | ||
*/ | ||
SAI_FDB_ENTRY_ATTR_ALLOW_MAC_MOVE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate on the use-case where we want to allow MAC_MOVE of a static MAC address?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in the SAI community meeting on Dec 19 the use case is for EVPN wherein the MACs donot age out as they are created and deleted by the EVPN control plane (BGP) . In that respect they are static MACs. However these MACs must be subjected to a MAC Move. For e.g. a MAC installed by BGP moves from the remote to a local port. This should trigger a hardware learn event. The SAI attribute is to allow for the hardware to learn the MAC even though the MAC is programmed as static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add some clarification on the TRAP attributed introduced in #696 ? What is the expectation of that notification when MAC_MOVE is enabled or disabled on this attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The trap introduced in #696 is a generic trap, where as this PR is about a specific MAC entry. So the specific entry would take precedence over a generic trap. I hope this clarifies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Additional clarification) When MAC_MOVE is explicitly disabled for a static mac-entry, the trap (introduced in #696) would also not be generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this also expected to work with MLAG?
The behavior of this entry is closer to being "dynamic but not ageable" than "static but movable" because static FDB is not supposed to be changed by anything besides the application that created it, whereas dynamic is expected to change, and we just say that it does not expire. Let me know if you considered this way of definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is expected to work with MCLAG as well. Please refer to the MC Lag enhancements HLD floated in sonic forum. Static vs dynamic refers to a MAC being ageable and not whether they are movable. Here we are adding an attribute to static mac specifying if this is moveable or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bandaru-viswanath, thanks for the clarification. can you make the clarification in the header?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lguohan Updated the header file.
Have you checked this? #696 |
696 is after a static move is detected. Here the setting is to allow for a static move as described in the previous reply. |
The #696 has a trap type added for static fdb mac move. I am not sure if this was intentional. Without this the added trap does not seem to make sense. The above packet action even if added is a switch wide attribute which is applicable to locally configured static MACs as well. We may not want this and would like to The EVPN remote macs though programmed as static are not the same as locally configured static MACs. These are dynamically learnt MACs on a remote |
@marian-pritsak and @itaibaz to check the behavior. |
@kcudnik , would you please review/approve also? thanks |
Added additional clarification for the attribute based on community feedback
No description provided.