[EVPN-MH] Add kernel patches for EVPN VXLAN Multihoming support#540
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@bdfriedman , are these PR upstreamed to linux kernel already? or in the process of upstream? |
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- Bug in
br.c(patch 2):br_switchdev_eventpassesfdb_info->locked(bool) as theprotocolparameter andRTPROT_UNSPECasext_flags— argument order is wrong after the signature change - Bug in
br_fdb_add(patch 2):protocolis initialized toRTPROT_UNSPECbut never parsed fromtb[NDA_PROTOCOL]— the add path silently ignores the user-supplied protocol, unlike the delete path which parses it correctly - Patch 1 (NDA_FLAGS_EXT) and Patch 3 (NTF_EXT_VALIDATED) look structurally sound
- Patches are not upstream-accepted — these appear to be custom SONiC patches carrying significant kernel neighbor/FDB subsystem changes
| - bool swdev_notify, u32 ext_flags) | ||
| + const unsigned char *addr, u16 vid, u8 protocol, | ||
| + bool locked, bool swdev_notify, u32 ext_flags) | ||
| { |
There was a problem hiding this comment.
Bug: protocol is never parsed from netlink in the add path. The variable is initialized to RTPROT_UNSPEC but there's no if (tb[NDA_PROTOCOL]) protocol = nla_get_u8(tb[NDA_PROTOCOL]); anywhere in br_fdb_add. Compare with br_fdb_delete which correctly parses it. This means bridge fdb add ... proto hw will silently ignore the protocol — it will always store RTPROT_UNSPEC.
There was a problem hiding this comment.
Still open. br_fdb_add initializes u8 protocol = RTPROT_UNSPEC but never parses tb[NDA_PROTOCOL]. The parsing only exists in br_fdb_delete and vxlan_fdb_parse, not in the bridge add path.
There was a problem hiding this comment.
Still unaddressed. br_fdb_add declares u8 protocol = RTPROT_UNSPEC but never parses tb[NDA_PROTOCOL]. The parsing block (if (tb[NDA_PROTOCOL]) protocol = nla_get_u8(...)) exists in br_fdb_delete but is missing from br_fdb_add.
There was a problem hiding this comment.
Still unaddressed in iteration 2. This bug remains in the current diff.
There was a problem hiding this comment.
Fixed in 41a91c8. br_fdb_add now parses tb[NDA_PROTOCOL] via nla_get_u8. ✅
There was a problem hiding this comment.
Still unaddressed in 0ae2cb5. br_fdb_add declares u8 protocol = RTPROT_UNSPEC but never parses tb[NDA_PROTOCOL]. The parsing exists in br_fdb_delete but is still missing from br_fdb_add.
There was a problem hiding this comment.
Fixed in 27a7faf. br_fdb_add now correctly parses tb[NDA_PROTOCOL] via nla_get_u8. ✅
There was a problem hiding this comment.
Verified fixed in 27a7faf. br_fdb_add now parses NDA_PROTOCOL.
There was a problem hiding this comment.
Fixed in ad1ebce. br_fdb_add now parses tb[NDA_PROTOCOL] via nla_get_u8. ✅
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- Patch ordering concern: Patch 2 (protocol field) modifies
br_fdb_external_learn_addsignature from patch 1 but gets argument order wrong inbr.c(already noted by prior reviewer). - Missing NDA_PROTOCOL parse in br_fdb_add:
protocolis initialized toRTPROT_UNSPECbut never read fromtb[NDA_PROTOCOL], so bridge fdb add silently ignores user-specified protocol (already noted). - Internal callers can silently overwrite protocol:
vxlan_snoopandvxlan_fdb_external_learn_addpassRTPROT_UNSPEC— if the entry already has a real protocol set, it gets silently cleared on update. - Patches are well-structured overall: Clean kernel patch backports with proper commit messages and sign-offs. The NTF_EXT_VALIDATED and NTF_EXT_MH_PEER_SYNC patches look correct.
| int err; | ||
|
|
||
| if (!(ndm->ndm_state & (NUD_PERMANENT|NUD_REACHABLE))) { | ||
| @@ -1281,7 +1296,7 @@ static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[], |
There was a problem hiding this comment.
Protocol overwrite on internal update. When vxlan_fdb_update_existing is called by internal callers like vxlan_snoop or vxlan_fdb_external_learn_add with RTPROT_UNSPEC, this block will overwrite any previously-set protocol value back to 0. Consider guarding with if (protocol != RTPROT_UNSPEC && f->protocol != protocol) to avoid unintentional protocol clearing by internal callers that don't carry protocol context.
There was a problem hiding this comment.
Still open. vxlan_fdb_update_existing unconditionally sets f->protocol = protocol when they differ. Internal callers like vxlan_snoop pass RTPROT_UNSPEC, which will overwrite a previously-set protocol value.
There was a problem hiding this comment.
Still unaddressed. vxlan_fdb_update_existing unconditionally overwrites f->protocol when values differ. Internal callers like vxlan_snoop pass RTPROT_UNSPEC, which will clear a previously-set protocol value (e.g. RTPROT_ZEBRA → RTPROT_UNSPEC).
There was a problem hiding this comment.
Still unaddressed in iteration 2. This bug remains in the current diff.
There was a problem hiding this comment.
Still unaddressed in 41a91c8. vxlan_fdb_update_existing unconditionally overwrites f->protocol when values differ. Internal callers like vxlan_snoop pass RTPROT_UNSPEC, which will clear a previously-set protocol (e.g. RTPROT_ZEBRA → RTPROT_UNSPEC). Needs a guard: if (protocol != RTPROT_UNSPEC && ...).
There was a problem hiding this comment.
Fixed. vxlan_fdb_update_existing now guards with if (protocol != RTPROT_UNSPEC && f->protocol != protocol), preventing snoop from clearing control-plane protocol. ✅
There was a problem hiding this comment.
Fixed in ad1ebce. vxlan_fdb_update_existing now guards with if (protocol != RTPROT_UNSPEC && f->protocol != protocol). ✅
There was a problem hiding this comment.
Fixed in ad1ebce. vxlan_fdb_update_existing now guards with if (protocol != RTPROT_UNSPEC && f->protocol != protocol). ✅
There was a problem hiding this comment.
Fixed in c2ee918. vxlan_fdb_update_existing now guards with if (protocol != RTPROT_UNSPEC && f->protocol != protocol) preventing internal callers from clobbering the protocol. ✅
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- VXLAN FDB protocol field not emitted in netlink dumps:
vxlan_fdb_info()is not updated to includeNDA_PROTOCOLin the protocol patch, so VXLAN FDB dumps won't show the protocol even though it's stored internally. Bridge side (fdb_fill_info) does this correctly. - Existing review comments correctly identify: wrong argument order in
br_switchdev_eventcall, missingNDA_PROTOCOLparsing inbr_fdb_add, protocol not propagated throughfdb_add_entrypath, and protocol overwrite risk from internal VXLAN callers. - NTF_EXT_VALIDATED patch is well-designed — proper state validation, GC exemption, stale-instead-of-failed fallback, and carrier-down protection.
- NTF_EXT_MH_PEER_SYNC / ext_flags plumbing through VXLAN and bridge layers looks correct.
- All three patches use
0001-prefix — consider renaming to0001-/0002-/0003-for clarity in the series.
|
Patch 3 (NTF_EXT_VALIDATED) is upstreamed and merged — great. Patches 1 and 2 appear to be Cisco-specific and not yet submitted upstream. Are there plans to upstream these? Carrying out-of-tree kernel patches long-term creates maintenance burden on every kernel version bump. If there are upstream submissions in progress, linking them here would help reviewers assess the risk. |
|
The |
|
The bugs flagged by banidoru (wrong argument order in |
|
Agree with what Tamer has said about upstreaming patches. There is already a fullcone NAT patch in this repo that hasn't been upstreamed, requires significant maintenance work to update, and is currently not getting applied on the Trixie kernel because no one has updated it. I do not want another instance of that. Additionally, if a patch has been upstreamed, please use the git patch from upstream, adjust for any patch conflicts, and (preferably) add the commit ID in the patch description. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
Re-review (iteration 2):
- Fixed:
vxlan_fdb_info()now emitsNDA_PROTOCOL— resolved - Still open (bug):
br_switchdev_eventpassesfdb_info->lockedasprotocol— wrong argument order after patch 0002 changes the signature - Still open (bug):
br_fdb_addnever parsestb[NDA_PROTOCOL]— protocol is alwaysRTPROT_UNSPECin the bridge add path - Still open:
vxlan_fdb_update_existingunconditionally overwrites protocol from internal callers passingRTPROT_UNSPEC - Still open: non-extern_learn path in
__br_fdb_addignores the protocol parameter
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
Re-review (iteration 2) — 4 of 5 previous issues remain unaddressed:
- br_switchdev_event wrong arg order:
fdb_info->lockedpassed asprotocolparam — will interpret bool as protocol type - br_fdb_add missing NDA_PROTOCOL parse: protocol always
RTPROT_UNSPECon add path - vxlan_fdb_update_existing unconditional overwrite: internal callers (snoop) clear previously-set protocol to
RTPROT_UNSPEC - fdb_add_entry ignores protocol: non-extern_learn bridge FDB adds never store protocol
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- Patch 0002 bug:
br_switchdev_eventpassesfdb_info->lockedasprotocol— wrong argument order after signature change - Patch 0002 bug:
br_fdb_addnever parsestb[NDA_PROTOCOL]—bridge fdb add ... proto hwsilently ignored - Patch 0002 design:
vxlan_fdb_update_existingunconditionally overwrites protocol — internal callers (e.g.vxlan_snoop) will clear previously-set protocol values - Patch 0002 design:
fdb_add_entry(non-extern_learn path) ignores protocol param — silent data loss - Patch 0002 fix confirmed:
vxlan_fdb_infonow emitsNDA_PROTOCOL✅ - Patches 0001, 0003: No new issues found; well-structured kernel patches with proper state machine handling
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- ✅ Fixed:
br_switchdev_eventarg order —RTPROT_UNSPECnow correctly passed asprotocol - ✅ Fixed:
br_fdb_addnow parsestb[NDA_PROTOCOL]from netlink - ❌ Still open:
vxlan_fdb_update_existingunconditionally overwritesf->protocol— internal callers likevxlan_snoopwill clear a previously-set protocol value - ❌ Still open:
fdb_add_entry(non-extern_learn path) ignores protocol —bridge fdb addwithoutextern_learnalways storesRTPROT_UNSPEC
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
Iteration 3 re-review:
- ✅
br_switchdev_eventargument order fixed —RTPROT_UNSPECnow correctly passed asprotocol - ✅
br_fdb_addnow parsestb[NDA_PROTOCOL] - ✅
vxlan_fdb_info()emitsNDA_PROTOCOL(confirmed in prior iteration) - ❌
vxlan_fdb_update_existingstill unconditionally overwritesf->protocol— internal callers passingRTPROT_UNSPECwill clear a previously-set protocol - ❌
fdb_add_entry(non-extern_learn path) still ignores the protocol parameter
| int err; | ||
|
|
||
| if (!(ndm->ndm_state & (NUD_PERMANENT|NUD_REACHABLE))) { | ||
| @@ -1281,7 +1296,7 @@ static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[], |
There was a problem hiding this comment.
Still unaddressed in iteration 3. vxlan_fdb_update_existing does if (f->protocol != protocol) { f->protocol = protocol; } but internal callers like vxlan_snoop pass RTPROT_UNSPEC. This will silently clear a protocol value set by the control plane (e.g. RTPROT_ZEBRA → RTPROT_UNSPEC).
Suggested fix: if (protocol != RTPROT_UNSPEC && f->protocol != protocol)
There was a problem hiding this comment.
Fixed in 0ae2cb5. vxlan_fdb_update_existing now correctly guards with if (protocol != RTPROT_UNSPEC && f->protocol != protocol). ✅
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
Add three Linux kernel patches required for EVPN VXLAN Multihoming in SONiC: 1. NDA_FLAGS_EXT with NTF_EXT_MH_PEER_SYNC - Extended FDB flags for multi-homing peer synchronization across EVPN-MH peers. 2. Protocol field in bridge FDB - Distinguishes control plane (zebra) vs data plane (hw) learned MACs for proper EVPN-MH state management. 3. NTF_EXT_VALIDATED for externally validated neighbors - Prevents kernel from invalidating neighbor entries managed by the control plane during ES link transitions. These patches are essential for the EVPN-MH feature described in: https://github.com/sonic-net/SONiC/blob/master/doc/vxlan/EVPN/EVPN_VxLAN_Multihoming.md Co-authored-by: Barry Friedman (friedman) <friedman@cisco.com> Signed-off-by: Tamer Ahmed <tamerahmed@microsoft.com>
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
Iteration 7 re-review (ad1ebce)
✅ All previously reported bugs are now fixed:
br_switchdev_eventargument orderbr_fdb_addparsingNDA_PROTOCOLvxlan_fdb_update_existingRTPROT_UNSPEC guardfdb_add_entryprotocol propagationvxlan_fdb_infoemittingNDA_PROTOCOLbr_fdb_external_learn_addupdate-path RTPROT_UNSPEC guard
Remaining (non-blocking):
ext_flagsdeclared but unused invxlan_fdb_delete(will cause compiler warning)- Minor style:
ext_flags/protocolfields invxlan_private.hlost tab alignment vs surrounding members - Patch 0002 reformats alignment in
include/net/neighbour.h(removes tabs fromNTF_EXT_MASK,NTF_MH_PEER_SYNC, etc.) — cosmetic churn unrelated to protocol field
Verdict: Approve. Core bugs resolved. Only cosmetic nits remain.
| goto out; | ||
| } | ||
| @@ -1301,7 +1316,7 @@ out: | ||
|
|
There was a problem hiding this comment.
Still present in ad1ebce. ext_flags is declared and parsed via vxlan_fdb_parse but never referenced in vxlan_fdb_delete. This will produce a compiler warning (-Wunused-variable). Non-blocking but should be cleaned up.
There was a problem hiding this comment.
Still present in ad1ebce. ext_flags declared and parsed but unused in vxlan_fdb_delete. Will cause compiler warning. Non-blocking nit.
There was a problem hiding this comment.
Still present in ad1ebce. ext_flags parsed but unused in vxlan_fdb_delete. Non-blocking nit.
There was a problem hiding this comment.
Still present — ext_flags parsed but unused in vxlan_fdb_delete. Non-blocking.
There was a problem hiding this comment.
Fixed in c2ee918. ext_flags is no longer declared in vxlan_fdb_delete — passes NULL for ext_flags to vxlan_fdb_parse. ✅
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- All previously reported bugs are fixed: argument order, NDA_PROTOCOL parsing, RTPROT_UNSPEC guard, fdb_add_entry propagation, br_fdb_external_learn_add guard, vxlan_fdb_info emission
- Protocol-aware FDB delete logic (both bridge and vxlan) is a solid addition — prevents cross-protocol entry clobbering
- Two minor issues remain open: unused
ext_flagsvariable invxlan_fdb_delete(compiler warning), and tab+spaces alignment inconsistency for new struct fields invxlan_private.h - Patch 0003 (NTF_EXT_VALIDATED backport) looks clean and well-documented
- Verdict: Approve — remaining items are non-blocking style/warning nits
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- All previously reported bugs are fixed: argument order in
br_switchdev_event,NDA_PROTOCOLparsing inbr_fdb_add,RTPROT_UNSPECguard invxlan_fdb_update_existingandbr_fdb_external_learn_add,fdb_add_entryprotocol propagation,vxlan_fdb_infoemission - Two minor nits remain from prior reviews: unused
ext_flagsvariable invxlan_fdb_delete(compiler warning), andext_flags/protocolstruct fields invxlan_fdbdrop tab+space alignment used by surrounding members - Patch 0002 formatting commit drops tab alignment in
include/net/neighbour.hdefines (NTF_EXT_MASK,NTF_MH_PEER_SYNC,NEIGH_UPDATE_F_EXT_MH_PEER_SYNC) — cosmetic only - Overall: correctness issues are resolved, design is sound, backward compatible. Approving with the two non-blocking nits noted above.
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- All prior bugs fixed: argument order, NDA_PROTOCOL parsing in br_fdb_add, RTPROT_UNSPEC guards, fdb_add_entry propagation
- Protocol-aware delete logic in both bridge and VXLAN is clean and correct
- Patch 0003 (NTF_EXT_VALIDATED) is well-structured with proper state validation on create/replace paths
- Minor nits remain: unused
ext_flagsinvxlan_fdb_delete, inconsistent indentation invxlan_private.h— non-blocking - LGTM, approve
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- All previously reported bugs (argument order, protocol parsing, RTPROT_UNSPEC guards, vxlan_fdb_info emission, fdb_add_entry propagation) are fixed
- Protocol-aware FDB deletion logic is a nice addition for control-plane/data-plane coexistence
- Two non-blocking nits remain:
ext_flagsunused invxlan_fdb_delete, and struct field indentation style mismatch - Overall design is sound — protocol field correctly propagated through all bridge and VXLAN FDB paths
- LGTM
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- All previously reported bugs (argument order, missing netlink parse, protocol overwrite, fdb_add_entry propagation, NTF_EXT bit conflict) are fixed in ad1ebce
ext_flagsstill parsed but unused invxlan_fdb_delete— harmless dead code, non-blocking- Indentation style inconsistency (
ext_flags/protocolfields use spaces instead of tab+spaces) persists — non-blocking - Protocol-guarded delete in both bridge and vxlan layers is a nice addition for control/data plane coexistence
- Patch 0003 (NTF_EXT_VALIDATED) is clean upstream cherry-pick, no concerns
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Tamer Ahmed <tamerahmed@microsoft.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Fixed in c2ee918. ext_flags is no longer declared in vxlan_fdb_delete — the function now passes NULL for the ext_flags parameter to vxlan_fdb_parse, and the parse function guards with if (ext_flags) before dereferencing. ✅
There was a problem hiding this comment.
Fixed in c2ee918. The indentation in patch 0003 now uses tab+spaces alignment matching the surrounding struct members. ✅
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
Iteration 9 re-review of c2ee918:
- ✅
ext_flagsunused variable invxlan_fdb_delete— fixed by passingNULLand adding null guards invxlan_fdb_parse - ✅ Indentation in
vxlan_private.hand patch 0003 defines — now uses proper tab+spaces alignment - ✅
include/net/neighbour.h/include/uapi/linux/neighbour.hremoved from patch 0002 (moved to patch 0003 where they belong) — addresses saiarcot895's comment about removing non-functional sections ⚠️ New issue:u32 ext_flagsdeclared but unused invxlan_fdb_external_learn_add(line 4772 in the patched file). The function passes literal0tovxlan_fdb_updaterather than using this variable. Will produce a compiler warning.- Non-blocking style nit:
u8 protocol;inbr_private.hstill lacks tab alignment matching surrounding struct members — cosmetic only.
| struct netlink_ext_ack *extack; | ||
| u32 hash_index; | ||
| + u32 ext_flags; | ||
| int err; |
There was a problem hiding this comment.
Unused variable. ext_flags is declared here but never referenced — the call to vxlan_fdb_update below passes literal 0 for the ext_flags argument. Either remove this declaration or use fdb_info->ext_flags (if the struct carries one) to pass through the actual value. Will produce a -Wunused-variable compiler warning.
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
Re-review of c2ee918. All prior bugs are confirmed fixed. Remaining nits:
vxlan_fdb_external_learn_adddeclaresu32 ext_flags(patch 0002) that is never used — literal0is passed tovxlan_fdb_updateinstead. Compiler warning risk.br_private.h:u8 protocol;uses space-only alignment while surrounding struct members use tab+spaces. Non-blocking.- Overall: clean implementation, protocol-aware deletion logic is a nice addition, RTPROT_UNSPEC guards are consistently applied.
| struct netlink_ext_ack *extack; | ||
| u32 hash_index; | ||
| + u32 ext_flags; | ||
| int err; |
There was a problem hiding this comment.
Unused variable. ext_flags is declared here but the call to vxlan_fdb_update below passes literal 0 for the ext_flags argument — this variable is never read. Will produce a -Wunused-variable compiler warning. Either remove it or use it in the vxlan_fdb_update call.
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- All previously reported bugs (argument order, protocol parsing, RTPROT_UNSPEC guard, vxlan_fdb_delete ext_flags, indentation, neighbour.h section removal) are now fixed in c2ee918
- Unused
ext_flagsvariable invxlan_fdb_external_learn_add(patch 0002) — declared but literal0passed tovxlan_fdb_update. Non-blocking compiler warning - Patch 0003 (NTF_EXT_VALIDATED) is well-structured with proper validation of state before setting the flag, correct gc exemption, and fallback to NUD_STALE instead of NUD_FAILED
- Protocol-aware delete logic in
vxlan_fdb_deleteis a good addition for control-plane/data-plane coexistence - LGTM overall — remaining nits are non-blocking style issues
Signed-off-by: Tamer Ahmed <tamerahmed@microsoft.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
banidoru
left a comment
banidoru
left a comment
There was a problem hiding this comment.
- All previously raised issues (protocol parsing, RTPROT_UNSPEC guard, unused variables, bit conflict, indentation) are fixed in this revision.
- Patch 0002 still carries cosmetic reformatting of existing call sites (e.g. vxlan_snoop, __vxlan_dev_create) that add churn but are non-blocking.
- NTF_EXT_MH_PEER_SYNC uses bit 3, NTF_EXT_EXT_VALIDATED uses bit 2 — no conflict. Series ordering is correct.
- LGTM. Approve.
6 participants
Why I did it
This PR adds three critical Linux kernel patches required to enable EVPN VXLAN Multihoming in SONiC. These kernel enhancements provide the necessary infrastructure for:
These patches are essential for implementing the EVPN-MH feature as described in the EVPN VXLAN Multihoming HLD.
NOTE: The file patches-sonic/0003-neighbor-Add-NTF_EXT_VALIDATED-flag-for-externally-v.patch has been committed upstream to the Linux kernel master branch. See torvalds/linux@03dc03f
Work item tracking
How I did it
Added three kernel patches to patches-sonic directory:
1. NDA_FLAGS_EXT Support with NTF_EXT_MH_PEER_SYNC (0001-vxlan-bridge-Add-NDA_FLAGS_EXT-support-with-NTF_EXT_.patch)
This patch adds extended flags support for VXLAN and bridge FDB entries to enable multi-homing peer synchronization:
ext_flagsinvxlan_fdbstructureNTF_EXT_MH_PEER_SYNC- Indicates FDB entry is synchronized across EVPN-MH peersNEIGH_UPDATE_F_EXT_MH_PEER_SYNCfor propagating sync statevxlan_fdb_alloc()- Initialize ext_flagsvxlan_fdb_create()- Pass ext_flags parametervxlan_fdb_update_existing()- Handle ext_flags updates and notificationsvxlan_fdb_update_create()- Create FDB with ext_flagsvxlan_fdb_info()- Include NDA_FLAGS_EXT in netlink messagesFiles modified:
drivers/net/vxlan/vxlan_core.c(140 lines)drivers/net/vxlan/vxlan_private.h(21 lines)drivers/net/vxlan/vxlan_vnifilter.c(11 lines)include/net/neighbour.h(4 lines)include/uapi/linux/neighbour.h(1 line)net/bridge/br.c(4 lines)net/bridge/br_fdb.c(35 lines)net/bridge/br_private.h(5 lines)net/core/neighbour.c(13 lines)2. Protocol Field in Bridge FDB (0001-net-bridge-vxlan-Protocol-field-in-bridge-fdb.patch)
This patch introduces an optional "protocol" field for bridge FDB entries to distinguish between control plane and data plane learned MAC addresses:
Purpose: In EVPN Multihoming, MAC addresses can be learned via:
This distinction enables:
Implementation:
protocolinnet_bridge_fdb_entryandvxlan_fdbstructuresRTPROT_UNSPECwhen protocol not specified (backward compatible)Usage Example:
Files modified:
drivers/net/vxlan/vxlan_core.c(55 lines)drivers/net/vxlan/vxlan_private.h(5 lines)drivers/net/vxlan/vxlan_vnifilter.c(4 lines)net/bridge/br.c(2 lines)net/bridge/br_fdb.c(55 lines)net/bridge/br_private.h(5 lines)3. NTF_EXT_VALIDATED Flag for External Validation (0001-neighbor-Add-NTF_EXT_VALIDATED-flag-for-externally-v.patch)
This patch adds a new "extern_valid" neighbor flag to indicate entries learned and validated externally that should not be invalidated by the kernel:
Background: In EVPN multi-homing:
Solution (based on draft-rbickhart-evpn-ip-mac-proxy-adv-03):
Implementation:
NTF_EXT_VALIDATED(extern_valid) - Entry is externally validatedUse case: Required for EVPN-MH proxy advertisements where control plane needs full control over neighbor entry validity and removal decisions.
Files modified:
How to verify it
Build kernel with these patches applied:
cd sonic-linux-kernel make BLDENV=bookwormVerify NDA_FLAGS_EXT support:
Verify protocol field support:
Verify extern_valid flag:
Integration testing with EVPN-MH:
Compatibility testing:
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Add kernel patches for EVPN VXLAN Multihoming: extended FDB flags (NTF_EXT_MH_PEER_SYNC), protocol field for bridge FDB entries, and extern_valid flag for externally validated neighbor entries
Link to config_db schema for YANG model changes
N/A - This PR only adds kernel patches, no CONFIG_DB schema changes
Depends on
Related upstream work
Summary:
Critical for EVPN-MH:
✅ Peer synchronization flag (NTF_EXT_MH_PEER_SYNC)
✅ Control/data plane MAC distinction (protocol field)
✅ External neighbor validation (extern_valid flag)
✅ Proxy advertisement support
✅ Prevents intermittent EVPN-MH failures