Skip to content

[neighsyncd]: Replay IPv6 link-local neighbors when enabled - #4867

Open
gs1571 wants to merge 3 commits into
sonic-net:masterfrom
gs1571:fix/neighsyncd-link-local-replay
Open

gs1571 wants to merge 3 commits into
sonic-net:masterfrom
gs1571:fix/neighsyncd-link-local-replay

Conversation

@gs1571

@gs1571 gs1571 commented Sep 5, 2026 •

Copy link
Copy Markdown

Description of PR

Summary:
Replay existing IPv6 link-local neighbors when link-local-only mode
is enabled. Include tagged sub-interfaces configured through
VLAN_SUB_INTERFACE.

Type of change

  • Bug fix
  • Test improvement

Approach

What is the motivation for this PR?

Neighbors learned while link-local-only mode is disabled are not
published after the mode is enabled unless another neighbor event
occurs.

Sub-interfaces also need their mode read from VLAN_SUB_INTERFACE,
rather than the parent interface or a duplicate INTERFACE entry.

How did you do it?

Use the existing interface-scoped replay mechanism and subscribe to
VLAN_SUB_INTERFACE changes.

Each sub-interface owns its configuration. Parent settings are not
inherited, and sibling sub-interfaces are handled independently.
The existing neighbor deletion and warm-restart behavior is unchanged.

How did you verify/test it?

Added unit coverage for sub-interface configuration lookup and
independent enable/delete/re-enable transitions.

Added DVS cases for new neighbor events and replay of permanent
neighbors without another neighbor update.

Local extracted-code harness checks passed: 11 state tests and
21 configuration lookup checks. These checks use stubs and do not
replace the full SWSS unit suite or DVS.

The new DVS cases and full SWSS build have not been run yet.
Existing IPv6 link-local tests passed in Azure build 1236899,
but the overall vstest job failed and remains under investigation.

Any platform specific information?

Equivalent downstream changes were validated on a physical SONiC
switch, including neighbor replay, sibling independence, and IPv6
forwarding. This does not replace validation of the updated upstream
source.

Documentation

No separate documentation change.

@gs1571
gs1571 requested a review from prsunny as a code owner September 5, 2026 13:58
@azure-pipelines

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

@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

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

@mssonicbld

Copy link
Copy Markdown
Collaborator

Hi, there are workflow run(s) waiting for approval, you may be first-time contributor. I will notify maintainers to help approve once PR is approved. Thanks!

---Powered by SONiC BuildBot

@anarasimhan-upscale

Copy link
Copy Markdown

@gs1571, can you please add UT for this change?

@gs1571
gs1571 force-pushed the fix/neighsyncd-link-local-replay branch from 364126b to a0019e1 Compare September 12, 2026 06:42
@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

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

@gs1571

gs1571 commented Sep 12, 2026

Copy link
Copy Markdown
Author

@anarasimhan-upscale, added a focused DVS regression test for the reported scenario.

The test creates an IPv6 link-local neighbor while
ipv6_use_link_local_only is disabled, verifies that it is absent from
APPL_DB, then enables the option and verifies that the existing kernel
neighbor is replayed without generating another neighbor event.

This is covered in the DVS suite because the behavior depends on Linux
kernel neighbor state and netlink replay.

Comment thread neighsyncd/neighsyncd.cpp Outdated
@gs1571
gs1571 force-pushed the fix/neighsyncd-link-local-replay branch from a0019e1 to c23f02b Compare September 15, 2026 09:32
@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

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

@anarasimhan-upscale anarasimhan-upscale left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@anarasimhan-upscale

Copy link
Copy Markdown

@prsunny can you please help signoff on this PR?

@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

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

@prsunny

prsunny commented Sep 18, 2026

Copy link
Copy Markdown
Collaborator

@gs1571 , what is the usecase of enabling "ipv6_use_link_local_only" at a later stage? Why is it not part of the original config? Can you share the command of enabling just "ipv6_use_link_local_only"

@gs1571

gs1571 commented Sep 19, 2026

Copy link
Copy Markdown
Author

@prsunny, ipv6_use_link_local_only can be enabled at runtime through the supported interface CLI:

sudo config interface ipv6 enable use-link-local-only Ethernet0

The concrete scenario that exposed the issue was an IS-IS/SRv6 setup:

  1. An L3 interface was brought up and IS-IS established an adjacency using IPv6 link-local addresses.
  2. The corresponding link-local neighbor was already present in the Linux neighbor table while ipv6_use_link_local_only was still disabled.
  3. The option was then enabled as part of completing the interface configuration.
  4. An SRv6 End.X adjacency SID was configured using that link-local neighbor as its next hop.

At step 2, neighsyncd ignored the neighbor as expected because the option was disabled. After step 3, however, the kernel did not generate another neighbor notification. The existing neighbor therefore remained absent from APPL_DB, and the End.X adjacency could not be fully programmed until an unrelated neighbor update occurred.

This PR handles that supported disabled-to-enabled transition by replaying the existing kernel link-local neighbors when the option becomes enabled.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟡 Changes recommended

The synchronous full-neighbor dump can block live netlink processing and risk notification loss on large neighbor tables.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 Medium severity

Open (1)
What changed in this PR

Adds configuration-triggered replay of existing IPv6 link-local neighbors through neighsyncd.

Changes:

  • Tracks interface link-local mode transitions.
  • Adds separate netlink neighbor resync logic.
  • Adds integration and unit tests.
File Description
neighsyncd/​neighsync.cpp Dumps and replays matching neighbors.
neighsyncd/​neighsyncd.cpp Monitors configuration and schedules retries.
neighsyncd/​neighsync.h Exposes resync API.
neighsyncd/​linklocalresyncstate.* Tracks interface state and pending replays.
neighsyncd/​Makefile.am Builds new implementation.
tests/​test_ipv6_link_local.py Adds replay integration test.
tests/​mock_tests/​neighsyncd/​linklocalresyncstate_ut.cpp Adds state-machine tests.
tests/​mock_tests/​Makefile.am Registers the new unit-test target.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread neighsyncd/neighsync.cpp Outdated
Comment thread neighsyncd/linklocalresyncstate.h Outdated
IPv6 link-local neighbors learned while ipv6_use_link_local_only is
disabled are ignored. Enabling the option does not generate another
kernel notification, so the existing neighbors can remain absent from
APPL_DB.

Track authoritative interface state transitions and replay only
disabled-to-enabled interfaces. Query one interface at a time with an
IPv6 RTM_GETNEIGH dump filtered by NDA_IFINDEX, process the response
through the existing onMsg path, and return to the select loop between
interfaces. Keep failed or interrupted dumps pending with bounded
receive waits and per-interface retry backoff.

Add focused unit coverage for state generations, independent pending
interfaces, the filtered request, and dump failures. Keep the DVS
regression that enables the option after the kernel neighbor already
exists.

Signed-off-by: Grigorii Solovev <gs1571@gmail.com>
@gs1571
gs1571 force-pushed the fix/neighsyncd-link-local-replay branch from 78ae666 to 597aee3 Compare September 22, 2026 09:55
@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

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

@gs1571

gs1571 commented Sep 23, 2026

Copy link
Copy Markdown
Author

@prsunny, I updated the PR to address the review comments: the interface-state transitions are explicit, and replay now uses an interface-filtered IPv6 neighbor dump with per-interface retry. All checks on the current HEAD are green. Could you please take another look?

Resolve the overlapping additions in neighsync_ut.cpp by retaining the interface-filtered link-local replay tests and the upstream non-VLAN failed-neighbor recovery tests. Preserve the upstream interface-name reset alongside the replay mock reset.

Signed-off-by: Grigorii Solovev <gs1571@gmail.com>
@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

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

Read sub-port link-local mode from VLAN_SUB_INTERFACE and subscribe to its changes through the existing replay state machine.

Keep sub-port configuration independent of parent and sibling ports. Do not require duplicate entries in INTERFACE.

Add tests for configuration lookup, independent state transitions, new neighbor events, and replay of existing neighbors.

Signed-off-by: Grigorii Solovev <gs1571@gmail.com>
@gs1571

gs1571 commented Oct 6, 2026

Copy link
Copy Markdown
Author

I added SUB_PORT support through VLAN_SUB_INTERFACE, without inheriting
the parent setting or requiring duplicate INTERFACE entries.

The update includes tests for independent sub-interface state,
new neighbor events, and replay without another neighbor update.

Could you please review the updated changes?

The previous vstest run passed the IPv6 link-local tests, but the
overall job failed with Redis socket errors and SRv6 RIF assertions.
I have not established whether these failures are related to this PR.

Previous CI run: Azure build 1236899.

@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants