[orchagent]: Recreate custom BFD monitor for reused nexthop - #4808
Open
zjswhhh wants to merge 2 commits into
Open
[orchagent]: Recreate custom BFD monitor for reused nexthop#4808zjswhhh wants to merge 2 commits into
zjswhhh wants to merge 2 commits into
Conversation
Signed-off-by: Jing Zhang <zhangjing@microsoft.com>
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). |
zjswhhh
marked this pull request as draft
July 31, 2026 18:21
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a lifecycle bug in orchagent where per-route custom BFD endpoint monitor state was not recreated when a directly-connected next-hop-group (NHG) was reused after route deletion/recreation, leading to stale monitor ownership and incorrect subsequent delete behavior.
Changes:
- Updates
VNetRouteOrch::selectNextHopGroup()to (re)create route-specific endpoint monitor state when either the NHG is new or the route is new, while only creating the shared NHG when needed. - Adds a DVS regression scenario that deletes and recreates a local-only custom-BFD route while reusing the directly connected next hop.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| orchagent/vnetorch.cpp | Adjusts monitor-setup vs NHG-creation logic in selectNextHopGroup() to ensure route-specific monitor state is recreated when appropriate. |
| tests/test_vnet.py | Extends test_vnet_orch_34 with a delete/recreate route sequence validating custom BFD session recreation under NH reuse. |
Comment on lines
+1175
to
+1177
| bool next_hop_group_exists = hasNextHopGroup(vnet, nexthops_primary); | ||
| bool route_exists = syncd_tunnel_routes_[vnet].find(ipPrefix) != syncd_tunnel_routes_[vnet].end(); | ||
|
|
zjswhhh
marked this pull request as ready for review
August 3, 2026 17:13
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
… fix-vnet-stale-custom-bfd-delete
Collaborator
|
/azp 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
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.
What I did
Decouple endpoint monitor setup from next-hop-group creation in
VNetRouteOrch::selectNextHopGroup().A directly connected next-hop group can survive route deletion. When the route was recreated, the existing NHG caused monitor setup to be skipped, so the route owned stale monitor state without recreating its custom BFD session. A later route update then emitted a delete for a session that had never been created in that cycle.
The updated logic recreates route-specific endpoint monitor state whenever either the NHG or route is new, while creating the shared NHG only when needed.
Added a DVS regression that deletes and recreates a local-only custom-BFD route while its directly connected next hop is reused.
Testing
make -C orchagent -j2 orchagenttest_vnet.py::TestVnetOrch::test_vnet_orch_34: fails at the second BFD-session check after route recreationtest_vnet.py::TestVnetOrch::test_vnet_orch_34: passedgit diff --checkpython3 -m py_compile tests/test_vnet.pyFixes sonic-net/sonic-buildimage#28336
sonic-mgmt validation
Targeted SmartSwitch HA validation used
ha/test_ha_launch_with_no_peer.py::test_ha_launch_with_no_peerwith sonic-mgmt PR #26298 applied.remove_bfd_sessionerror.The issue-specific lifecycle validation passed. The overall pytest result remained non-passing because of an unrelated traffic assertion and Log Analyzer sensor errors.