[vpp] saivpp VXLAN L3 decap: source-independent decap, inner source MAC, BD teardown fix#1996
Open
aaronber0614 wants to merge 6 commits into
Open
[vpp] saivpp VXLAN L3 decap: source-independent decap, inner source MAC, BD teardown fix#1996aaronber0614 wants to merge 6 commits into
aaronber0614 wants to merge 6 commits into
Conversation
Collaborator
|
/azp run |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
When a packet is routed into an L3 VXLAN tunnel, VPP builds the inner Ethernet header using the tunnel interface hardware MAC as the source. The interface default is VPPs auto-generated MAC (02:fe:..), which HW ASICs and the VNET decap tests do not expect. Override the tunnel interface MAC with the router MAC after creating the encap, via a new sw_interface_set_mac_by_index binary API helper. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3446b9ac-fa7f-4d26-914b-a4f076c603aa Signed-off-by: Aaron Bernardino <aaronber@microsoft.com>
…ecap
Extend the VPP virtual-switch SAI tunnel adaptation (vslib/vpp) to
program source-independent VNET tunnel termination, so decap matches on
local dst + VNI while ignoring the outer source IP. This supports RIOT /
secondary-VTEP topologies where encapsulated traffic may arrive from a
VTEP other than the primary tunnel source, which previously failed to
decap.
vslib/vpp/TunnelManager.{cpp,h}: add the decap-any tunnel-term wiring.
Stacked on top of the existing tunnel inner-source-MAC override.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 3446b9ac-fa7f-4d26-914b-a4f076c603aa
Signed-off-by: Aaron Bernardino <aaronber@microsoft.com>
aaronber0614
force-pushed
the
vpp-vxlan-enablement
branch
from
July 16, 2026 13:25
eba10f6 to
717dd0a
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
aaronber0614
changed the title
Address code-review findings on the L3 VXLAN VNET decap term handling in TunnelManager: - Refcount the VRF0 local-receive route by VTEP IP. Multiple VNIs can share one secondary VTEP, so program the route on the first term and remove it only on the last. Tearing down one VNI no longer removes the shared route and breaks decap for its siblings. - Check every VPP API return in create_vxlan_decap_term (interface state, L2 bridge bind, VRF set, both BVI address adds) and roll back the BD/BVI on failure instead of proceeding half-programmed and returning success. - Set decap_any on both L3 VNET decap tunnel requests so the decap term is source-independent. This covers the secondary-VTEP path (create_vxlan_decap_term) and the primary-VTEP L3 VNET path (tunnel_encap_nexthop_action, VIRTUAL_ROUTER_ID_TO_VNI mappers). L2 EVPN tunnels (create_l2_vxlan_tunnel_for_vni) intentionally leave decap_any unset to keep exact outer-source validation. SaiVppXlate signals the flag to VPP via the high bit of decap_next_index, forcing a valid default next index so the flag stays distinguishable. - Install L3 (VNI_TO_VIRTUAL_ROUTER_ID) decap terms from the tunnel-create path as well, so a TUNNEL created after its TUNNEL_MAP_ENTRY still gets its decap term programmed. A shared install_l3_vxlan_decap_terms helper keeps the map-entry and tunnel-create paths idempotent. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3446b9ac-fa7f-4d26-914b-a4f076c603aa Signed-off-by: Aaron Bernardino <aaronber@microsoft.com>
aaronber0614
force-pushed
the
vpp-vxlan-enablement
branch
from
July 16, 2026 14:38
717dd0a to
2329bf9
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
remove_vpp_vxlan_decap deleted the bridge-domain while the VXLAN tunnel interface was still a member of it. The tunnel is only removed later by remove_vpp_vxlan_encap, so at BD-delete time the BD still had a member and vpp_bridge_domain_add_del(is_add=0) failed with -120 (bridge-domain in use). This surfaced as a syncd ERR log during L3 VNET decap teardown and tripped loganalyzer in the vxlan ECMP tests, although it was functionally benign (the BD was reclaimed once the tunnel was later removed). Detach the tunnel interface from the BD (set_sw_interface_l2_bridge_by_index with is_add=false) before freeing the bd_id and deleting the bridge-domain. Validated on a t1-lag-vpp testbed: vxlan/test_vxlan_ecmp.py no longer emits the -120 bridge-domain delete error and leaves zero bridge-domains in use. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3446b9ac-fa7f-4d26-914b-a4f076c603aa Signed-off-by: Aaron Bernardino <aaronber@microsoft.com>
aaronber0614
force-pushed
the
vpp-vxlan-enablement
branch
from
July 16, 2026 16:19
2329bf9 to
a9b16c4
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Bring the saivpp VXLAN branch up to date with sonic-net/sonic-sairedis master so it builds against and re-runs the current Azure pipeline. No code conflicts; merge is clean. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3446b9ac-fa7f-4d26-914b-a4f076c603aa Signed-off-by: Aaron Bernardino <aaronber@microsoft.com>
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
The sonic-sairedis swsslogentercheck.sh test requires every method to call SWSS_LOG_ENTER() as its first statement. The vxlan_decap_term_set_dst helper in TunnelManager.cpp was missing it, failing "Run sonic sairedis unit tests" (1 of 11 tests) in the Build and BuildAsan legs. Add the macro to match the rest of the file. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3446b9ac-fa7f-4d26-914b-a4f076c603aa Signed-off-by: Aaron Bernardino <aaronber@microsoft.com>
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
aaronber0614
force-pushed
the
vpp-vxlan-enablement
branch
from
July 20, 2026 22:06
3af0195 to
9aa0dca
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
aaronber0614
marked this pull request as ready for review
July 20, 2026 22:07
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Collaborator
|
/azp run |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
Summary:
Enable L3 VXLAN decap on the sonic-vpp platform (saivpp / vslib/vpp) and fix
several pre-existing decap setup/teardown defects found during review.
Part of sonic-net/sonic-buildimage#25777
Depends on the VPP patch series in sonic-net/sonic-platform-vpp#262 being in the
built image first. All changes are confined to vslib/vpp.
Changes:
primary and secondary L3 VNET paths; L2 EVPN tunnels intentionally keep exact
outer-source validation.
sw_interface_set_mac_by_index binary-API helper, so the inner Ethernet header
matches what HW ASICs and the VNET decap tests expect (default was VPP's
auto-generated 02:fe:.. MAC).
shared VRF0 VTEP local-receive route so tearing down one VNI does not break
its siblings; check every VPP API return in create_vxlan_decap_term and roll
back the BD/BVI on failure instead of returning success half-programmed; and
install the L3 decap terms from the tunnel-create path too, so a tunnel
created after its map entry still gets programmed.
BD in remove_vpp_vxlan_decap: the tunnel was still a BD member at delete time
(it is removed later by remove_vpp_vxlan_encap), so
vpp_bridge_domain_add_del(is_add=0) failed with -120 (BD in use). Benign (BD
reclaimed later) but it tripped loganalyzer during teardown.
Files: vslib/vpp/{TunnelManager.cpp, TunnelManager.h, SwitchVpp.cpp,
vppxlate/SaiVppXlate.c, vppxlate/SaiVppXlate.h}.
Type of change
Approach
What is the motivation for this PR?
Enable correct L3 VXLAN decap on sonic-vpp and remove decap setup/teardown
defects: source-dependent decap, wrong inner source MAC, and the BD-in-use
teardown error.
How did you do it?
Changes in vslib/vpp (TunnelManager, SwitchVpp, SaiVppXlate) to install
source-independent decap terms, set the tunnel inner source MAC, and fix the BD
member-detach ordering on teardown.
How did you verify/test it?
Rebuilt syncd-vpp, hot-swapped onto a t1-lag-vpp testbed, and ran the VXLAN
regression suite: test_vnet_decap 4/4, test_vxlan_multiple_tunnels 16/16, and
vxlan/test_vxlan_ecmp.py with zero -120 bridge-domain-delete errors and zero
leaked bridge-domains after teardown.
Any platform specific information?
sonic-vpp (vslib/vpp) only; no other platform is affected.
Documentation
No doc/HLD changes.