-
Notifications
You must be signed in to change notification settings - Fork 1.4k
zebra: EVPN fix L3VNI to L2VNI transition #20334
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
Open
chiragshah6
wants to merge
2
commits into
FRRouting:master
Choose a base branch
from
chiragshah6:zdev2
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
+350
−32
Conversation
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
when the vni is moved from l3 to l2vni, the vxlan interface belonging to the l3 was still holding this vni in its table. when this vxlan interfae is assigned new vni, it would go ahead remove the old vni from its table. while removing it asserts beacuse the vxaln interface belonging to this vni is now pointing to l2vni vxlan interface. Fix: when the vni is transition from l3 to l2, remove the vni binging from the vxlan interface belong to the l3. 1. removing the vni info from the hash which is primarly maintain to have cache of netlink notification for SVD to vlan-vni mapping. The hash values should only be removed when vni mapping is removed for vxlan device or vxlan interface is removed by Kernel. The vni info removal lead to an issue where when the same vni is transition back to L3VNI, all the info is lost hence L3VNI does not come up properly. 2. while the vni info removed from hash, the vni info was not freed lead to memory leak. To have proper vni transition, instead of removing vni info from hash, simply dereference from vxlan vlan infomration and when readded as L3VNI restore the referecen for vlan vlan information. Related Ticket: #4404076 Ticket: #4667654 Testing: Before fix: torm-21(config)# vrf vrf1 torm-21(config-vrf)# no vni 4000 torm-21(config-vrf)# do show evpn vni 4000 L2 vxlan99 10 34 4 vrf1 0 br_l3vni After fix: torm-21(config-vrf)# do show evpn vni 4000 L3 vxlan99 0 0 n/a vrf1 2501 br_l3vni torm-21(config)# vrf vrf1 torm-21(config-vrf)# no vni 4000 torm-21(config-vrf)# do show evpn vni 4000 L2 vxlan99 10 34 4 vrf1 2501 br_l3vni torm-21(config-vrf)# vni 4000 torm-21(config-vrf)# do show evpn vni 4000 L3 vxlan99 4 4 n/a vrf1 2501 br_l3vni Detail output after vni transition: torm-21(config-vrf)# do show evpn vni 4000 VNI: 4000 Type: L2 Vlan: 2501 Bridge: br_l3vni Tenant VRF: vrf1 VxLAN interface: vxlan99 VxLAN ifIndex: 27 SVI interface: vlan2501_l3 SVI ifIndex: 29 Local VTEP IP: 2001:c001:ff:f00d::6 Mcast group: 0.0.0.0 Remote VTEPs for this VNI: 2001:c001:ff:f00d::7 flood: - 2001:c001:ff:f00d::5 flood: - 2001:c001:ff:f00d::4 flood: - 2001:cf11:ff:f00d::3 flood: - Number of MACs (local and remote) known for this VNI: 10 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 31 Advertise-gw-macip: No Advertise-svi-macip: No torm-21(config-vrf)# vni 4000 torm-21(config-vrf)# do show evpn vni 4000 VNI: 4000 Type: L3 Tenant VRF: vrf1 Vlan: 2501 Bridge: br_l3vni Local Vtep Ip: 2001:c001:ff:f00d::6 Vxlan-Intf: vxlan99 SVI-If: vlan2501_l3 State: Up VNI Filter: none System MAC: 44:38:39:ff:ff:18 Router MAC: 44:38:39:ff:ff:18 Number of MACs (local and remote) known for this VNI: 4 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 4 L2 VNIs: 1000 1001 1002 1003 Signed-off-by: Chirag Shah <[email protected]>
ton31337
approved these changes
Jan 4, 2026
Member
|
@Mergifyio backport stable/10.5 |
🟠 Waiting for conditions to matchDetails
|
Signed-off-by: Chirag Shah <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When a VNI is moved from the L3VNI to the L2VNI, the VxLAN interface associated with the L3VNI continues to retain this VNI in its internal table. Later, when that VxLAN interface is assigned a new VNI, it attempts to remove the old VNI from its table. During this removal, an assertion is triggered because the VNI now references the L2VNI's VxLAN interface instead of the original L3VNI interface.
Fix: when the vni is transition from l3 to l2, remove the vni binging from the vxlan interface belong to the l3.
removing the vni info from the hash which is primarily maintain to have cache of netlink notification for SVD to vlan-vni mapping. The hash values should only be removed when vni mapping is removed for vxlan device or vxlan interface is removed by Kernel.
The vni info removal lead to an issue where when the same vni is transition back to L3VNI, all the info is lost hence L3VNI does not come up properly.
while the vni info removed from hash, the vni info was not freed lead to memory leak.
To ensure a correct VNI transition, avoid removing the VNI entry from the hash. Instead, simply dereference it from the VxLAN VLAN information. When the VNI is later re‑added as an L3VNI, restore the VLAN information reference.
Before fix:
After fix:
Vijayalaxmi Basavaraj [email protected]
Signed-off-by: Chirag Shah [email protected]