[dhcp_relay] Add DHCPv6 relay VRF tests - #25785
Open
AnantKishorSharma wants to merge 2 commits into
Open
Conversation
Contributor
Author
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
@wangxin @yejianquan @zypgithub - Please review when you have a chance. |
AnantKishorSharma
marked this pull request as draft
July 1, 2026 10:01
AnantKishorSharma
marked this pull request as ready for review
July 1, 2026 10:07
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
AnantKishorSharma
marked this pull request as draft
July 1, 2026 10:16
AnantKishorSharma
marked this pull request as ready for review
July 1, 2026 10:18
AnantKishorSharma
force-pushed
the
dhcp6relay-vrf-support
branch
from
July 13, 2026 20:05
6334ba6 to
28011d1
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Add sonic-mgmt tests that dhcp6relay applies configuration at runtime without restarting the dhcp_relay container: - starts when no dhcpv6_servers are configured - adds a relay instance when a VLAN gets an IPv6 address at runtime, and removes it when that address is removed - applies dhcpv6_server changes in place (PID unchanged, no "need restart container" log) Signed-off-by: Anant Kishor Sharma <anant.kishor-sharma@hpe.com>
Control- and data-plane tests for dhcp6relay VLAN-VRF and server_vrf upstream socket binding (Option A/B), runtime rebind/unbind, applied without container restart. Tests for sonic-net/sonic-dhcp-relay#89. Signed-off-by: Anant Kishor Sharma <anant.kishor-sharma@hpe.com>
AnantKishorSharma
force-pushed
the
dhcp6relay-vrf-support
branch
from
July 13, 2026 20:33
28011d1 to
fa7b38c
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
/azpw run |
Collaborator
|
Retrying failed(or canceled) jobs... |
Collaborator
|
Retrying failed(or canceled) stages in build 1163915: ✅Stage Test:
|
Contributor
Author
|
/azpw retry |
Collaborator
|
Retrying failed(or canceled) jobs... |
Collaborator
|
Retrying failed(or canceled) stages in build 1163915: ✅Stage Test:
|
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.
Why I did it
Add hardware test coverage for the
dhcp6relayVRF support (sonic-net/sonic-dhcp-relay#89 / sonic-net/sonic-dhcp-relay#117): the relay must reach DHCPv6 servers through a non-default VRF, applied at runtime without a container restart.How I did it
New
tests/dhcp_relay/test_dhcpv6_relay_vrf.pywith 4 control-plane + 4 data-plane tests:server_vrfshared socket (Option B), runtime VRF change (rebind), and runtime VRF unbind (revert to global) — each asserts the relay re-binds at runtime with thedhcp6relayPID unchanged.dhcpv6_relay_test.DHCPTestPTF exchange both directions.Syslog assertions match only genuine
dhcp6relaylog lines (ansible command echoes excluded) and are marker-scoped where a VRF name is reused, so the tests are deterministic in CI.How to verify it
Run on a t0 testbed:
./run_tests.sh ... -c "dhcp_relay/test_dhcpv6_relay.py dhcp_relay/test_dhcpv6_relay_vrf.py"Validated on a qfx5200 t0: the existing v6 relay suite passes (no regression) alongside the new VRF tests.
Tests for sonic-net/sonic-dhcp-relay#89
CI note - The
impacted-area-kvmtestfailures are expected on the current imageChain for these to go green in CI:
sonic-dhcp-relay#116+#117merge → thesonic-dhcp-relaysubmodule is advanced to include them → thevsimage is rebuilt → this PR's tests pass unmodified.The full suite (8 VRF + 4 runtime-config cases) passes on hardware (qfx5200 T0) with an image built from #116 + #117. This PR should merge after the image carries the relay changes.