Repository navigation
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
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
|
|
@gs1571, can you please add UT for this change? |
364126b to
a0019e1
Compare
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
@anarasimhan-upscale, added a focused DVS regression test for the reported scenario. The test creates an IPv6 link-local neighbor while This is covered in the DVS suite because the behavior depends on Linux |
a0019e1 to
c23f02b
Compare
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
@prsunny can you please help signoff on this PR? |
c23f02b to
78ae666
Compare
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
@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" |
|
@prsunny, sudo config interface ipv6 enable use-link-local-only Ethernet0The concrete scenario that exposed the issue was an IS-IS/SRv6 setup:
At step 2, This PR handles that supported disabled-to-enabled transition by replaying the existing kernel link-local neighbors when the option becomes enabled. |
There was a problem hiding this comment.
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
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.
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>
78ae666 to
597aee3
Compare
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
@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>
|
/azp run |
|
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>
|
I added SUB_PORT support through VLAN_SUB_INTERFACE, without inheriting The update includes tests for independent sub-interface state, Could you please review the updated changes? The previous vstest run passed the IPv6 link-local tests, but the Previous CI run: Azure build 1236899. |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |

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
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.