bgpd: EVPN MH fix unimport ES route on vtep change (backport #20730)#20773
Merged
donaldsharp merged 1 commit intostable/10.5from Feb 11, 2026
Merged
bgpd: EVPN MH fix unimport ES route on vtep change (backport #20730)#20773donaldsharp merged 1 commit intostable/10.5from
donaldsharp merged 1 commit intostable/10.5from
Conversation
In EVPN MH deployment, when a VTEP-IP address changed at the sender VTEP, the remote VTEP sees a stale VTEP-IP entry in ES to VTEP-IP mapping. RCA: Handling for nexthop change for evpn es (Type-1) route is missing on receiver side. On changing the VTEP IP on local node, the EAD (Type-1) route's BGP update contains new originator VTEP-IP as nexthop. The new BGP update message treated as update to existing path and the ES route import simply goes with adding with the new VTEP-IP, hence the stale ES EVI/VTEP (old VTEP) references are seen. Fix: At the receiving VTEP, detect the nexthop change during processing of EVPN ES (Type-1) BGP Update. Unimport the prior Type-1 route entry before processing of the new nexthop pased bgp update. The unimport/import ensures the proper clean up of old VTEP-IP in ES to VTEP-IP list. Test: Before Fix: ---------- On local node vtep is changed from 27.0.0.103 to 27.0.0.3 Remote node shows 27.0.0.103 stale vtep ``` torm-21# show evpn es Type: B bypass, L local, R remote, N non-DF ESI Type ES-IF VTEPs 03:44:38:39:ff:ff:01:00:00:01 R - 27.0.0.3,27.0.0.4,27.0.0.5,27.0.0.103 ``` Afer fix: -------- The old VTEP IP is no longer present as stale entry on remote VTEP ``` root@torm-21:mgmt:/var/home/cumulus# vtysh -c "show evpn es" Type: B bypass, L local, R remote, N non-DF ESI Type ES-IF VTEPs 03:44:38:39:ff:ff:01:00:00:01 R - 27.0.0.3,27.0.0.4,27.0.0.5 ``` Topotest result with and without fix: ------------------------------------- Without fix: ``` E AssertionError: torm11: stale VTEP 192.168.100.117 still in ES 03:44:38:39:ff:ff:02:00:00:01 after restore E assert "stale vtep 192.168.100.117 still in ES 03:44:38:39:ff:ff:02:00:00:01 vteps ['192.168.100.17', '192.168.100.18', '192.168.100.117']" is None test_evpn_mh.py:864: AssertionError ``` With Fix: ``` PASSED test_evpn_mh.py::test_evpn_vtep_change ``` Ticket: #4850442 Signed-off-by: Vivek Venkatraman <vivek@nvidia.com> Signed-off-by: Chirag Shah <chirag@nvidia.com> Signed-off-by: Manpreet Kaur <manpreetk@nvidia.com> (cherry picked from commit 14a4f8b)
|
Target branch is not in the allowed branches list. |
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
2 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.
In EVPN MH deployment, when a VTEP-IP address changed at the sender VTEP, the remote VTEP sees a stale VTEP-IP entry in ES to VTEP-IP mapping.
RCA:
Handling for nexthop change for evpn es (Type-1) route is missing on receiver side.
On changing the VTEP IP on local node, the EAD (Type-1) route's BGP update contains new originator VTEP-IP as nexthop. The new BGP update message treated as update to existing path and the ES route import simply goes with adding with the new VTEP-IP,
hence the stale ES EVI/VTEP (old VTEP) references are seen.
Fix:
At the receiving VTEP, detect the nexthop change during processing of EVPN ES (Type-1) BGP Update.
Unimport the prior Type-1 route entry before processing of the new nexthop pased bgp update. The unimport/import ensures the proper clean up of old VTEP-IP in ES to VTEP-IP list.
Test:
Before Fix:
On local node vtep is changed from 27.0.0.103 to 27.0.0.3 Remote node shows 27.0.0.103 stale vtep
Afer fix:
The old VTEP IP is no longer present as stale entry on remote VTEP