search

sonic-net / sonic-buildimage

Scripts which perform an installable binary image build for SONiC
Other
734 stars 1.41k forks source link

dhcp_relay/test_dhcpv6_relay.py::test_dhcp_relay_default fails on dualtor #16261

Open yanjundeng opened 1 year ago

yanjundeng commented 1 year ago

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 commented 1 year ago

@kevinskwang - could you please check this?

yanjundeng commented 1 year ago

@jcaiMR

jcaiMR commented 1 year ago

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 commented 1 year ago

IT's not image issue but test gap. Opened this PR to fix https://github.com/sonic-net/sonic-mgmt/pull/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.