[neighorch]: Track remote next hops on inband RIF

[Xichen96]

What I did

Remote-system-port next hops are represented through the local inband interface, but NeighOrch previously used two different interface identities for the same object.

Root cause

addNextHop() already rewrote the next-hop key from the remote system port to the inband interface:

remote system port alias
→ local inband alias
→ m_syncdNextHops key

The rest of the bookkeeping did not consistently follow that normalized key:

• the SAI next hop used the remote system port's RIF;
• the non-bulk path incremented the remote interface refcount;
• the bulk completion path stored the original remote key and incremented the remote refcount;
• removal searched with the inband key but decremented the original remote alias.

This produced three mismatches:

1. The SAI object could reference a different RIF than the key used to track it.
2. Normal add/remove updated different interface refcounts.
3. Bulk add stored a key that the existing removal path could not find.

Fix

This PR makes the normalized inband next-hop key authoritative:

remote alias
→ resolve inband alias once
→ use inband RIF
→ store inband key
→ increment inband refcount
→ remove inband key
→ decrement inband refcount

The changes are limited to remote-system-port next-hop identity and bookkeeping:

• addNextHop() obtains the RIF from nexthop.alias after remote-to-inband normalization.
• Normal and bulk completion increment the refcount for nexthop.alias.
• Bulk completion performs the same remote-to-inband key normalization as the non-bulk path.
• Removal decrements the refcount for the normalized alias.

Why I did it

The next-hop key, SAI RIF, sync map entry, and interface refcount describe one logical dependency. Using different aliases across those surfaces can leak references, prevent deletion, or leave bulk-created next hops unreachable by the removal path.

This defect predates the interface deletion and VRF-rehome work. It is therefore isolated from PRs #4746 and #4764 rather than being included as incidental hardening.

Scope

This PR does not change boot-order handling when the inband port is not yet available. The existing assertion behavior is handled in a separate follow-up so identity/bookkeeping and retry semantics remain independently reviewable.

How I verified it

Focused mock coverage configures a remote system port and local inband interface, then verifies:

• the SAI next hop receives the inband RIF ID;
• the next hop is stored under the inband key;
• the remote interface refcount is unchanged;
• the inband interface refcount increments on normal add and balances on removal;
• bulk completion stores the same inband key and balances the same refcount on removal.

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

• Head: df387c75cabd5ec325682a1304d1b6ac74882a1a
• Azure PR build: 1171076
• All architecture, ASAN, Docker, Trixie, Test vstest, and TestAsan vstest lanes passed.
• CodeQL, Semgrep, DCO, EasyCLA, and the exact-head Copilot review are clean.
• No local build was used; validation is PR-build only.

202605 PR-build validation

• Validation-only PR: #4747
• This change is included in the complete current-202605 stack after [intfsorch]: Fence new RIF dependencies during interface removal #4746 and [intfsorch]: Retry loopback action update failures #4766, and before [neighorch]: Avoid inserting missing bulk neighbors #4772 and dependent PR [neighorch]: Retry until inband port is available #4770.
• Exact validation head: d4b0502ecdac76d56fdf063a633045c0fb0de977
• Azure PR build: 1171672 — in progress.
• The Tested for 202605 branch label must remain absent until that exact result is complete.

Details if related

• Microsoft ADO: 38864631
• Follow-up: PR #4770, retry instead of asserting when the inband port is not yet available.
• This is a pre-existing remote-system-port defect and is independent of PRs [intfsorch]: Fence new RIF dependencies during interface removal #4746 and [intfsorch]: Retry explicit router interface VRF rehome #4764.
• Merge batch 1. PR [neighorch]: Retry until inband port is available #4770 must follow this PR.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR fixes NeighOrch bookkeeping for remote-system-port next hops by making the inband-normalized next-hop identity (alias/key, SAI RIF selection, sync map entry, and interface refcount) consistent across normal add, bulk completion, and removal paths.

Changes:

• Use the normalized nexthop.alias (inband) to select the RIF and to increment/decrement router-interface refcounts in next-hop add/remove paths.
• Normalize the key in the bulk completion path so bulk-created next hops are tracked/removable via the same inband key.
• Add focused mock test coverage validating inband RIF usage, inband-key storage, and correct refcount balancing for both non-bulk and bulk completion.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
orchagent/neighorch.cpp	Normalizes remote-system-port next-hop identity to inband across RIF selection, sync-map keys, and interface refcount updates (including bulk completion).
tests/mock_tests/neighorch_ut.cpp	Adds unit test coverage for remote-system-port next-hop normalization (inband RIF, key, and refcount behavior).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Xichen96]

/azpw run

[mssonicbld]

⚠️ Notice: /azpw run only runs failed jobs now. If you want to trigger a whole pipline run, please rebase your branch or close and reopen the PR.
💡 Tip: You can also use /azpw retry to retry failed jobs directly.

Retrying failed(or canceled) jobs...

[mssonicbld]

Retrying failed(or canceled) stages in build 1170069:

✅Stage TestAsan:

• Job vstest: retried.

✅Stage Test:

• Job vstest: retried.
• Job vstest: retried.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[mssonicbld]

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}