dhcp_relay/test_dhcpv6_relay.py::test_dhcp_relay_default fails on dualtor

[yanjundeng]

Description

When run "dhcp_relay/test_dhcpv6_relay.py::test_dhcp_relay_default", it fails on dualtor due to the ptf script can't capture matched relay pkt.

After debug the pkt, it's related to inconsistent pkt format between the real relay pkt and relay pkt in script.

As to the real relay pkt from dualtor, it includes "interface_id" option.
Yet as to the script "dhcpv6_relay_test.py", it doesn't include this option when constructing the relay pkt for match.

Steps to reproduce the issue:

1. Just run "dhcp_relay/test_dhcpv6_relay.py::test_dhcp_relay_default" on dualtor

Describe the results you received:

This issue should be imported by following merge:
https://github.com/sonic-net/sonic-dhcp-relay/pull/42/files

Describe the results you expected:

Output of show version:

cisco@tor40-1:~$ show ver

SONiC Software Version: SONiC.azure_cisco_202205.6081-dirty-20230816.045024
SONiC OS Version: 11
Distribution: Debian 11.7
Kernel: 5.10.0-18-2-amd64
Build commit: 9ef1c3562
Build date: Wed Aug 16 14:27:21 UTC 2023
Built by: sonicci@sonic-ci-11-lnx

Platform: x86_64-8102_64h_o-r0
HwSKU: Cisco-8102-C64
ASIC: cisco-8000
ASIC Count: 1
Serial Number: FLM26400CVG
Model Number: 8102-64H-O
Hardware Revision: 1.0
Uptime: 01:42:35 up 7:46, 1 user, load average: 0.75, 1.01, 1.02
Date: Thu 24 Aug 2023 01:42:35

Docker images:
REPOSITORY TAG IMAGE ID SIZE
docker-macsec latest 94bcaa35470b 332MB
docker-gbsyncd-cisco azure_cisco_202205.6081-dirty-20230816.045024 24336761deec 493MB
docker-gbsyncd-cisco latest 24336761deec 493MB
docker-teamd azure_cisco_202205.6081-dirty-20230816.045024 e39634cf5158 330MB
docker-teamd latest e39634cf5158 330MB
docker-platform-monitor azure_cisco_202205.6081-dirty-20230816.045024 410f820f7adb 440MB
docker-platform-monitor latest 410f820f7adb 440MB
docker-orchagent azure_cisco_202205.6081-dirty-20230816.045024 a992ad229ae4 347MB
docker-orchagent latest a992ad229ae4 347MB
docker-fpm-frr azure_cisco_202205.6081-dirty-20230816.045024 a55bae467393 359MB
docker-fpm-frr latest a55bae467393 359MB
docker-syncd-cisco azure_cisco_202205.6081-dirty-20230816.045024 0f8ec3c272d8 923MB
docker-syncd-cisco latest 0f8ec3c272d8 923MB
docker-sflow azure_cisco_202205.6081-dirty-20230816.045024 51c8fef66f39 303MB
docker-sflow latest 51c8fef66f39 303MB
docker-nat azure_cisco_202205.6081-dirty-20230816.045024 7f9ff0400dd3 305MB
docker-nat latest 7f9ff0400dd3 305MB
docker-dhcp-relay latest 974fbab29cf9 321MB
docker-ipxeserver-cisco azure_cisco_202205.6081-dirty-20230816.045024 95095dbc2a6e 659MB
docker-ipxeserver-cisco latest 95095dbc2a6e 659MB
docker-sonic-telemetry azure_cisco_202205.6081-dirty-20230816.045024 d215728eaf32 394MB
docker-sonic-telemetry latest d215728eaf32 394MB
docker-snmp azure_cisco_202205.6081-dirty-20230816.045024 1fd791d49abf 363MB
docker-snmp latest 1fd791d49abf 363MB
docker-router-advertiser azure_cisco_202205.6081-dirty-20230816.045024 3426d0664697 314MB
docker-router-advertiser latest 3426d0664697 314MB
docker-mux azure_cisco_202205.6081-dirty-20230816.045024 7707ab585f16 362MB
docker-mux latest 7707ab585f16 362MB
docker-lldp azure_cisco_202205.6081-dirty-20230816.045024 5c9dc2a38a9c 356MB
docker-lldp latest 5c9dc2a38a9c 356MB
docker-database azure_cisco_202205.6081-dirty-20230816.045024 72d4cde68bc4 314MB
docker-database latest 72d4cde68bc4 314MB
docker-sonic-mgmt-framework azure_cisco_202205.6081-dirty-20230816.045024 ce5ed850097f 433MB
docker-sonic-mgmt-framework latest ce5ed850097f 433MB

(paste your output here)

Output of show techsupport:

(paste your output here or download and attach the file here )

Additional information you deem important (e.g. issue happens only occasionally):

[Aravind-Subbaroyan]

@kevinskwang - could you please check this?

[yanjundeng]

@jcaiMR

[jcaiMR]

It's a test gap for latest behavior change on dual-tor, we are working on the test gap fix. Will commit the code change soon.

[jcaiMR]

IT's not image issue but test gap.
Opened this PR to fix sonic-net/sonic-mgmt#9842

In dual tor, we will use loopback0 interface as source interface for relay-forward and dhcpv6 server response will send to loopback0 which is unique in dual tor case, to let response can reach the active mux cable interface tor.
Meanwhile, interface id option (with vlan ipv6 address inserted) will be enabled by default in dual tor as a solution for second level relay agent case, which has zero link address and need interface id option for downlink interface selection when deal with server responses.