[neighorch]: Retry until inband port is available#4770
Open
Xichen96 wants to merge 7 commits into
Open
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.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). |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates NeighOrch remote-system-port next-hop handling to follow SWSS’s retain-and-retry model when the local inband port is not yet available during initialization, avoiding an orchagent abort caused by assertions.
Changes:
- Replace
assert(getInbandPort())with a boolean check andreturn false(retry) in remote-system-port next-hop add, bulk completion, and remove paths. - Normalize remote-system-port next hops to use the inband alias consistently for RIF lookup and interface refcounting.
- Add focused mock tests to validate inband RIF usage and retry behavior when the inband port is absent.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| orchagent/neighorch.cpp | Converts remote-system-port inband-port dependency from assert to retry semantics; normalizes alias use for RIF/refcounting. |
| tests/mock_tests/neighorch_ut.cpp | Adds unit tests and SAI next-hop mocking to validate inband normalization and retry behavior. |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Xichen96
force-pushed
the
dev/xichenlin/neighorch-inband-retry
branch
from
July 20, 2026 17:08
3093e9c to
6af04e5
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Collaborator
|
/azp run |
1 similar comment
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Check the global inband dependency once per route or next-hop group before beginning removal. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Remote system-port next hops remain on the global inband RIF when their neighbor moves between remote ports. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
This was referenced Jul 22, 2026
Collaborator
|
This PR has backport request label(s) for branch(es): 202605, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202605: <test result>) in the Test result section as well in your PR description. ---Powered by SONiC BuildBot
|
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
NeighOrch previously asserted that an inband port always existed whenever it processed a remote-system-port next hop. This PR converts that boot-order assumption into the normal SWSS retain-and-retry behavior.
Root cause
Remote-system-port next hops must be normalized to the local inband interface. The original implementation called
getInbandPort()and then asserted that the returned alias was non-empty.That assumption has existed since the remote-system-port path was introduced in 2021. It is not guaranteed during initialization: a remote next-hop update can be processed before the local inband port has been configured.
The old behavior was:
An unavailable prerequisite is transient state, not an invariant violation.
Fix
Each remote next-hop path now checks the boolean result from
getInbandPort():The check covers:
No fallback alias or synthetic success is used. The operation reports retry and leaves the existing state machine responsible for reprocessing it.
Why I did it
SWSS orchagents routinely return
falsewhen a required object is not available yet. Treating inband-port boot order the same way avoids a process abort without hiding the missing dependency or programming an object against the wrong interface.This defect predates the interface deletion and VRF-rehome work. It is kept separate from the inband RIF identity/bookkeeping fix because the two changes address different failure modes:
Dependency
This branch is stacked on PR #4769 because that PR adds the bulk normalization path containing the third inband lookup. Until #4769 merges, GitHub's Files changed tab includes the prerequisite commit. The final upstream merge order is #4769 first, then this retry change.
How I verified it
Focused mock coverage configures a remote system port, removes the inband-port designation, and verifies that next-hop operations return
falserather than asserting:addNextHop();processBulkAddNextHop();removeNextHop();removeMplsNextHop().Route and label-route removal coverage also verifies that missing-inband MPLS dependencies are detected before any bulk SAI operation is queued. NhgOrch performs the same preflight before changing group or member state.
The available single-ASIC hardware testbed cannot exercise remote system ports, so this path is covered with focused unit tests and exact-head CI.
Current exact-head master PR build
b7c61bb6e2a9ef0b7af97a003b850b061439fa94Test vstest, andTestAsan vstestlanes passed.202605 PR-build validation
202605stack applies PR [neighorch]: Track remote next hops on inband RIF #4769 first, includes batch-1 PR [neighorch]: Avoid inserting missing bulk neighbors #4772, and applies this retry change last.d4b0502ecdac76d56fdf063a633045c0fb0de977Tested for 202605 branchlabel must remain absent until that exact result is complete.Details if related
Review follow-up
addNextHop()retry before advancing dependent work.removeNextHop()retry before refcount/cache progression.