From 110f6d970f9762c6d7c5d4b4bad4fee7764cfc27 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 17 Oct 2022 15:42:57 +0800 Subject: [PATCH 01/12] Create Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 194 ++++++++++++++++++++++++ 1 file changed, 194 insertions(+) create mode 100644 docs/testplan/Generic-hash-test-plan.md diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md new file mode 100644 index 00000000000..618c6e2b1a9 --- /dev/null +++ b/docs/testplan/Generic-hash-test-plan.md @@ -0,0 +1,194 @@ +# Generic Hash Test Plan + +## Related documents + +| **Document Name** | **Link** | +|-------------------|----------| +| SONiC Generic Hash | [https://github.com/sonic-net/SONiC/doc/hash/hash-design.md]| + + +## Overview +The hashing algorithm is used to make traffic-forwarding decisions for traffic exiting the switch. +It makes hashing decisions based on values in various packet fields, as well as on the hash seed value. +The packet fields used by the hashing algorithm varies by the configuration on the switch. + +For ECMP, the hashing algorithm determines how incoming traffic is forwarded to the next-hop device. +For LAG, the hashing algorithm determines how traffic is placed onto the LAG member links to manage +bandwidth by evenly load-balancing traffic across the outgoing links. + +GH is a feature which allows user to configure which hash fields suppose to be used by hashing algorithm. +GH provides global switch hash configuration for ECMP and LAG. + + +## Requirements + +#### The Generic Hash feature supports the following functionality: +1. Ethernet packet hashing configuration with inner/outer IP frames +2. Global switch hash configuration for ECMP and LAG +3. Warm/Fast reboot + +#### This feature will support the following commands: + +1. config: set switch hash global configuration +2. show: display switch hash global configuration + +#### This feature will provide error handling for the next situations: + +1. Frontend + Invalid parameter value +2. Backend + 1. Missing parameters + 2. Invalid parameter value + 3. Parameter removal + 4. Configuration removal + +### Scope + +The test is to verify the hash configuration can be added/updated/removed by the generic hash, and the behavior of ECMP and lag hashing will change according to the generic hash config. + +### Scale / Performance + +No scale or performance test related + +### Related **DUT** CLI commands + +#### Config +The following command can be used to configure generic hash: +``` +config +|--- switch-hash + |--- global + |--- ecmp-hash ARGS + |--- lag-hash ARGS +``` + +Examples: +The following command updates switch hash global: +``` +config switch-hash global ecmp-hash \ +'DST_MAC' \ +'SRC_MAC' \ +'ETHERTYPE' \ +'IP_PROTOCOL' \ +'DST_IP' \ +'SRC_IP' \ +'L4_DST_PORT' \ +'L4_SRC_PORT' \ +'INNER_DST_MAC' \ +'INNER_SRC_MAC' \ +'INNER_ETHERTYPE' \ +'INNER_IP_PROTOCOL' \ +'INNER_DST_IP' \ +'INNER_SRC_IP' \ +'INNER_L4_DST_PORT' \ +'INNER_L4_SRC_PORT' +``` +``` +config switch-hash global lag-hash \ +'DST_MAC' \ +'SRC_MAC' \ +'ETHERTYPE' \ +'IP_PROTOCOL' \ +'DST_IP' \ +'SRC_IP' \ +'L4_DST_PORT' \ +'L4_SRC_PORT' \ +'INNER_DST_MAC' \ +'INNER_SRC_MAC' \ +'INNER_ETHERTYPE' \ +'INNER_IP_PROTOCOL' \ +'INNER_DST_IP' \ +'INNER_SRC_IP' \ +'INNER_L4_DST_PORT' \ +'INNER_L4_SRC_PORT' +``` + +#### Show +The following command shows switch hash global configuration: +``` +show ip interfaces loopback-action +``` +Example: +``` +root@sonic:/home/admin# show switch-hash global +ECMP HASH LAG HASH +----------------- ----------------- +DST_MAC DST_MAC +SRC_MAC SRC_MAC +ETHERTYPE ETHERTYPE +IP_PROTOCOL IP_PROTOCOL +DST_IP DST_IP +SRC_IP SRC_IP +L4_DST_PORT L4_DST_PORT +L4_SRC_PORT L4_SRC_PORT +INNER_DST_MAC INNER_DST_MAC +INNER_SRC_MAC INNER_SRC_MAC +INNER_ETHERTYPE INNER_ETHERTYPE +INNER_IP_PROTOCOL INNER_IP_PROTOCOL +INNER_DST_IP INNER_DST_IP +INNER_SRC_IP INNER_SRC_IP +INNER_L4_DST_PORT INNER_L4_DST_PORT +INNER_L4_SRC_PORT INNER_L4_SRC_PORT +``` +### Related DUT configuration files + +``` +{ + "SWITCH_HASH": { + "GLOBAL": { + "ecmp_hash": [ + "DST_MAC", + "SRC_MAC", + "ETHERTYPE", + "IP_PROTOCOL", + "DST_IP", + "SRC_IP", + "L4_DST_PORT", + "L4_SRC_PORT", + "INNER_DST_MAC", + "INNER_SRC_MAC", + "INNER_ETHERTYPE", + "INNER_IP_PROTOCOL", + "INNER_DST_IP", + "INNER_SRC_IP", + "INNER_L4_DST_PORT", + "INNER_L4_SRC_PORT" + ], + "lag_hash": [ + "DST_MAC", + "SRC_MAC", + "ETHERTYPE", + "IP_PROTOCOL", + "DST_IP", + "SRC_IP", + "L4_DST_PORT", + "L4_SRC_PORT", + "INNER_DST_MAC", + "INNER_SRC_MAC", + "INNER_ETHERTYPE", + "INNER_IP_PROTOCOL", + "INNER_DST_IP", + "INNER_SRC_IP", + "INNER_L4_DST_PORT", + "INNER_L4_SRC_PORT" + ] + } + } +} +``` +### Supported topology +The test will be supported on any topology + + +## Test cases + +### Test cases #1 - Verify when generic ecmp hash is configured, the traffic can be balanced accordingly. + +### Test cases #2 - Verify when generic lag hash is configured, the traffic can be balanced accordingly. + +### Test cases #3 - Verify when both generic ecmp/lag hash are configured, the traffic can be balanced accordingly. + +### Test cases #4 - Verify the generic hash cannot be configured seccessfully with invalid arguments . + +### Test cases #5 - Verify generic hash configuration persists after reboot(config reload, reboot, fast-reboot, warm-reboot). + From 71ed47658efe7e250d16a51172e2eee1407f6b89 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 17 Oct 2022 15:45:23 +0800 Subject: [PATCH 02/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index 618c6e2b1a9..8ec800a9fb6 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -35,12 +35,12 @@ GH provides global switch hash configuration for ECMP and LAG. #### This feature will provide error handling for the next situations: 1. Frontend - Invalid parameter value + 1.1 Invalid parameter value 2. Backend - 1. Missing parameters - 2. Invalid parameter value - 3. Parameter removal - 4. Configuration removal + 2.1 Missing parameters + 2.2 Invalid parameter value + 2.3 Parameter removal + 2.4 Configuration removal ### Scope From b0c2a4d7507ad0e0b4738c5d9ea088c73386ad4c Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 17 Oct 2022 19:29:54 +0800 Subject: [PATCH 03/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 62 ++++++++++++++++++++----- 1 file changed, 51 insertions(+), 11 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index 8ec800a9fb6..ad61fcb82ad 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -106,8 +106,11 @@ config switch-hash global lag-hash \ #### Show The following command shows switch hash global configuration: ``` -show ip interfaces loopback-action +show +|--- switch-hash + |--- global ``` + Example: ``` root@sonic:/home/admin# show switch-hash global @@ -182,13 +185,50 @@ The test will be supported on any topology ## Test cases -### Test cases #1 - Verify when generic ecmp hash is configured, the traffic can be balanced accordingly. - -### Test cases #2 - Verify when generic lag hash is configured, the traffic can be balanced accordingly. - -### Test cases #3 - Verify when both generic ecmp/lag hash are configured, the traffic can be balanced accordingly. - -### Test cases #4 - Verify the generic hash cannot be configured seccessfully with invalid arguments . - -### Test cases #5 - Verify generic hash configuration persists after reboot(config reload, reboot, fast-reboot, warm-reboot). - +### Test cases #1 - Verify the default hash fields are ip_proto, src_ip, dst_ip, src_l4_port, dst_l4_port, inner_src_ip, inner_dst_ip. +1. Get the default hash fields configration via cli "show switch-hash global" +2. Check the default ecmp and lag hash fields are ip_proto, src_ip, dst_ip, src_l4_port, dst_l4_port, inner_src_ip, inner_dst_ip. + +### Test cases #2 - Verify when generic ecmp hash is configured, the traffic can be balanced accordingly. +1. The test is using the default links and routes in a community setup. +2. Randomly select a hash field and configure it to the ecmp hash list via cli "config switch-hash global ecmp-hash". +3. Configure the lag hash list to exclude the selected field in case the egress links are portchannels. +4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination via mutiple nexthops. +5. Check the traffic is balanced between the nexthops. +6. If the uplinks are portchannels with multiple members, check the traffic is not balanced between the members. +7. Recover the hash configs to the default. + +### Test cases #3 - Verify when generic lag hash is configured, the traffic can be balanced accordingly. +1. The test is using the default links and routes in a community setup and only runs on setups which have multi-member portchannel uplinks. +2. Randomly select a hash field and configure it to the lag hash list via cli "config switch-hash global lag-hash". +3. Configure the ecmp hash list to exclude the selected field in case the uplink portchannels are in ecmp groups. +4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination via the portchannels. +5. Check only one portchannel receives the traffic and the traffic is balanced between the members. +6. Recover the hash configs to the default. + +### Test cases #4 - Verify when both generic ecmp/lag hash are configured with all the valid fields, the traffic can be balanced accordingly. +1. The test is using the default links and routes in a community setup. +2. Configure all the valid hash fields for the ecmp and lag hash. +3. Randomly select one hash field for the test. +4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination. +5. Check the traffc is balanced between all the egress physical ports. +6. Recover the hash configs to the default. + +### Test cases #5 - Verify the generic hash cannot be configured seccessfully with invalid arguments. +1. Configure the ecmp/lag hash with invalid fields list arguments. +2. Check there is a cli error notify the user the the argument is invalid. +3. Check the running config is not changed. +4. The invalid arguments includes: + a. empty argument + b. single invalid field + c. invalid field(s) combined with valid field(s) +5. Recover the hash configs to the default. + +### Test cases #6 - Verify generic hash running configuration persists after warm-reboot. +1. The test is using the default links and routes in a community setup. +2. Configure all the valid hash fields for the ecmp and lag hash. +3. Randomly select one hash field for the test. +4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination. +5. Do warm-reboot while sending the traffic. +6. After the warm-reboot finished, check the traffc is balanced between all the egress physical ports and no traffic loss. +7. Recover the hash configs to the default. From 28bc05ea1e523efa1018fa6fc2bd0d0164dcd219 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Wed, 19 Oct 2022 10:00:28 +0800 Subject: [PATCH 04/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index ad61fcb82ad..dafcb5cb49b 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -193,7 +193,7 @@ The test will be supported on any topology 1. The test is using the default links and routes in a community setup. 2. Randomly select a hash field and configure it to the ecmp hash list via cli "config switch-hash global ecmp-hash". 3. Configure the lag hash list to exclude the selected field in case the egress links are portchannels. -4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination via mutiple nexthops. +4. Send traffic with changing selected field from a downlink ptf to uplink destination via multiple nexthops. 5. Check the traffic is balanced between the nexthops. 6. If the uplinks are portchannels with multiple members, check the traffic is not balanced between the members. 7. Recover the hash configs to the default. @@ -201,8 +201,8 @@ The test will be supported on any topology ### Test cases #3 - Verify when generic lag hash is configured, the traffic can be balanced accordingly. 1. The test is using the default links and routes in a community setup and only runs on setups which have multi-member portchannel uplinks. 2. Randomly select a hash field and configure it to the lag hash list via cli "config switch-hash global lag-hash". -3. Configure the ecmp hash list to exclude the selected field in case the uplink portchannels are in ecmp groups. -4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination via the portchannels. +3. Configure the ecmp hash list to exclude the selected field. +4. Send traffic with changing selected field from a downlink ptf to uplink destination via the portchannels. 5. Check only one portchannel receives the traffic and the traffic is balanced between the members. 6. Recover the hash configs to the default. @@ -210,7 +210,7 @@ The test will be supported on any topology 1. The test is using the default links and routes in a community setup. 2. Configure all the valid hash fields for the ecmp and lag hash. 3. Randomly select one hash field for the test. -4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination. +4. Send traffic with changing selected field from a downlink ptf to uplink destination. 5. Check the traffc is balanced between all the egress physical ports. 6. Recover the hash configs to the default. @@ -224,11 +224,11 @@ The test will be supported on any topology c. invalid field(s) combined with valid field(s) 5. Recover the hash configs to the default. -### Test cases #6 - Verify generic hash running configuration persists after warm-reboot. +### Test cases #6 - Verify generic hash running configuration persists after fast/warm reboot. 1. The test is using the default links and routes in a community setup. 2. Configure all the valid hash fields for the ecmp and lag hash. 3. Randomly select one hash field for the test. -4. Send traffic whose selected field is changing, from a downlink ptf to uplink destination. -5. Do warm-reboot while sending the traffic. -6. After the warm-reboot finished, check the traffc is balanced between all the egress physical ports and no traffic loss. +4. Send traffic with changing selected field from a downlink ptf to uplink destination. +5. Randomly do fast/warm reboot while sending the traffic. +6. After the reboot finished, check the traffc is balanced between all the egress physical ports. 7. Recover the hash configs to the default. From 48c7adad1b3bab7566708255897196cb1ed729a4 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 24 Oct 2022 11:06:24 +0800 Subject: [PATCH 05/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 85 +++++++++++++++++++------ 1 file changed, 65 insertions(+), 20 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index dafcb5cb49b..49c1d2a7445 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -180,55 +180,100 @@ INNER_L4_SRC_PORT INNER_L4_SRC_PORT } ``` ### Supported topology -The test will be supported on any topology +The test will be supported on t0 and t1 topologies. ## Test cases +Note: + 1. The hash field is randomly selected in the test cases, and in the first phase, the fields required by MSFT will be coverd in the cases - including ip_proto, dst ip, src ip, dst port, src port, inner dst ip, inner src ip. Other supported fields will be covered in the future. + 2. IPv4 or IPv6 traffic is randomly selected in the test cases. + ### Test cases #1 - Verify the default hash fields are ip_proto, src_ip, dst_ip, src_l4_port, dst_l4_port, inner_src_ip, inner_dst_ip. 1. Get the default hash fields configration via cli "show switch-hash global" 2. Check the default ecmp and lag hash fields are ip_proto, src_ip, dst_ip, src_l4_port, dst_l4_port, inner_src_ip, inner_dst_ip. +* This case depends on the final implementation, if there is no default config of generic hash in configDB, remove this test case. ### Test cases #2 - Verify when generic ecmp hash is configured, the traffic can be balanced accordingly. 1. The test is using the default links and routes in a community setup. 2. Randomly select a hash field and configure it to the ecmp hash list via cli "config switch-hash global ecmp-hash". 3. Configure the lag hash list to exclude the selected field in case the egress links are portchannels. 4. Send traffic with changing selected field from a downlink ptf to uplink destination via multiple nexthops. -5. Check the traffic is balanced between the nexthops. -6. If the uplinks are portchannels with multiple members, check the traffic is not balanced between the members. -7. Recover the hash configs to the default. +5. Check the traffic is balanced over the nexthops. +6. If the uplinks are portchannels with multiple members, check the traffic is not balanced over the members. ### Test cases #3 - Verify when generic lag hash is configured, the traffic can be balanced accordingly. -1. The test is using the default links and routes in a community setup and only runs on setups which have multi-member portchannel uplinks. +1. The test is using the default links and routes in a community setup, and only runs on setups which have multi-member portchannel uplinks. 2. Randomly select a hash field and configure it to the lag hash list via cli "config switch-hash global lag-hash". 3. Configure the ecmp hash list to exclude the selected field. 4. Send traffic with changing selected field from a downlink ptf to uplink destination via the portchannels. -5. Check only one portchannel receives the traffic and the traffic is balanced between the members. -6. Recover the hash configs to the default. +5. Check only one portchannel receives the traffic and the traffic is balanced over the members. ### Test cases #4 - Verify when both generic ecmp/lag hash are configured with all the valid fields, the traffic can be balanced accordingly. 1. The test is using the default links and routes in a community setup. 2. Configure all the valid hash fields for the ecmp and lag hash. 3. Randomly select one hash field for the test. 4. Send traffic with changing selected field from a downlink ptf to uplink destination. -5. Check the traffc is balanced between all the egress physical ports. -6. Recover the hash configs to the default. +5. Check the traffc is balanced over all the uplink physical ports. -### Test cases #5 - Verify the generic hash cannot be configured seccessfully with invalid arguments. -1. Configure the ecmp/lag hash with invalid fields list arguments. -2. Check there is a cli error notify the user the the argument is invalid. +### Test cases #5 - Verify the generic hash cannot be configured seccessfully with invalid parameters. +1. Configure the ecmp/lag hash with invalid fields list parameter. +2. Check there is a cli error notifies the user the parameter is invalid. 3. Check the running config is not changed. -4. The invalid arguments includes: - a. empty argument +4. The invalid parameters to test: + a. empty parameter b. single invalid field - c. invalid field(s) combined with valid field(s) -5. Recover the hash configs to the default. + c. invalid fields combined with valid fields + +### Test cases #6 - Verify when a generic hash config entry/parameter is removed, or updated with invalid values from configDB via redis cli, there will be warnings printed in the log. +1. Config ecmp and lag hash via cli. +2. Remove the ecmp hash entry via redis cli. +3. Check there is a warning printed in the log. +4. Remove the lag hash entry via redis cli. +5. Check there is a warning printed in the log. +6. Re-config the ecmp and lag hash via cli. +7. Update the ecmp hash fields with an invalid value via redis cli. +8. Check there is a warning printed in the log. +9. Update the lag hash fields with an invalid value via redis cli. +10. Check there is a warning printed in the log. +11. Re-config the ecmp and lag hash via cli. +12. Remove the generic hash table via redis cli. +13. Check there is a warning printed in the log. -### Test cases #6 - Verify generic hash running configuration persists after fast/warm reboot. +### Test cases #7 - Verify generic hash works properly when there are nexthop flaps. 1. The test is using the default links and routes in a community setup. 2. Configure all the valid hash fields for the ecmp and lag hash. 3. Randomly select one hash field for the test. 4. Send traffic with changing selected field from a downlink ptf to uplink destination. -5. Randomly do fast/warm reboot while sending the traffic. -6. After the reboot finished, check the traffc is balanced between all the egress physical ports. -7. Recover the hash configs to the default. +5. Check the traffic is balanced over all the uplink ports. +6. Randomly shutdown 1 nexthop interface. +7. Send the traffic again. +8. Check the traffic is balanced over all remaining uplink ports with no packet loss. +9. Recover the interface and do shutdown/startup on the interface 3 more times. +10. Send the traffic again. +11. Check the traffic is balanced over all uplink ports with no packet loss. + +### Test cases #8 - Verify generic hash works properly when there is lag member flaps. +1. The test is using the default links and routes in a community setup, and only runs on setups which have multi-member portchannel uplinks +3. Configure all the valid hash fields for the ecmp and lag hash. +4. Randomly select one hash field for the test. +5. Send traffic with changing selected field from a downlink ptf to uplink destination. +6. Check the traffic is balanced over all the uplink ports. +7. Randomly shutdown 1 member port in all uplink portchannels. +8. Send the traffic again. +9. Check the traffic is balance over all remaining uplink ports with no packet loss. +10. Recover the members and do shutdown/startup on them 3 more times. +11. Send the traffic again. +12. Check the traffic is balance over all uplink ports with no packet loss. + +### Test cases #9 - Verify generic hash running configuration persists after fast/warm reboot, and the saved configuration persists after code reboot. +1. The test is using the default links and routes in a community setup. +2. Configure all the valid hash fields for the ecmp and lag hash. +3. Randomly select one hash field for the test. +4. Randomly select fast/warm/cold reboot for the test, if cold reboot, save the config before the reboot. +5. Send traffic with changing selected field from a downlink ptf to uplink destination. +6. Check the traffic is balance over all the uplink ports. +7. Randomly do fast/warm/cold reboot. +8. After the reboot, check the generic hash config via cli, it should keep the same as before the reboot. +9. Send traffic again. +10. Check the traffic is balance over all the uplink ports. From 6e53216efd79ab022e052b92d843e2a4fb87e110 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 24 Oct 2022 11:23:37 +0800 Subject: [PATCH 06/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index 49c1d2a7445..abce74c58fe 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -218,12 +218,14 @@ Note: ### Test cases #5 - Verify the generic hash cannot be configured seccessfully with invalid parameters. 1. Configure the ecmp/lag hash with invalid fields list parameter. -2. Check there is a cli error notifies the user the parameter is invalid. -3. Check the running config is not changed. -4. The invalid parameters to test: +2. Check there is a cli error that notifies the user the parameter is invalid. +3. Check there is a warning printed in the syslog. +4. Check the running config is not changed. +5. The invalid parameters to test: a. empty parameter b. single invalid field c. invalid fields combined with valid fields + d. duplicated valid fields(depends on the final implememtation) ### Test cases #6 - Verify when a generic hash config entry/parameter is removed, or updated with invalid values from configDB via redis cli, there will be warnings printed in the log. 1. Config ecmp and lag hash via cli. @@ -253,7 +255,7 @@ Note: 10. Send the traffic again. 11. Check the traffic is balanced over all uplink ports with no packet loss. -### Test cases #8 - Verify generic hash works properly when there is lag member flaps. +### Test cases #8 - Verify generic hash works properly when there are lag member flaps. 1. The test is using the default links and routes in a community setup, and only runs on setups which have multi-member portchannel uplinks 3. Configure all the valid hash fields for the ecmp and lag hash. 4. Randomly select one hash field for the test. From 01935015635a9aa8168b1bb6ae62d1c4778be1d5 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 24 Oct 2022 16:58:31 +0800 Subject: [PATCH 07/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index abce74c58fe..b3e50ef3469 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -44,7 +44,7 @@ GH provides global switch hash configuration for ECMP and LAG. ### Scope -The test is to verify the hash configuration can be added/updated/removed by the generic hash, and the behavior of ECMP and lag hashing will change according to the generic hash config. +The test is to verify the hash configuration can be added/updated by the generic hash, and the behavior of ECMP and lag hashing will change according to the generic hash config. ### Scale / Performance @@ -268,7 +268,7 @@ Note: 11. Send the traffic again. 12. Check the traffic is balance over all uplink ports with no packet loss. -### Test cases #9 - Verify generic hash running configuration persists after fast/warm reboot, and the saved configuration persists after code reboot. +### Test cases #9 - Verify generic hash running configuration persists after fast/warm reboot, and the saved configuration persists after cold reboot. 1. The test is using the default links and routes in a community setup. 2. Configure all the valid hash fields for the ecmp and lag hash. 3. Randomly select one hash field for the test. From f93fbf4fa8be4788f179723f5457ef1434bf5f37 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Wed, 26 Oct 2022 09:56:57 +0800 Subject: [PATCH 08/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index b3e50ef3469..01298e88b62 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -193,6 +193,7 @@ Note: 1. Get the default hash fields configration via cli "show switch-hash global" 2. Check the default ecmp and lag hash fields are ip_proto, src_ip, dst_ip, src_l4_port, dst_l4_port, inner_src_ip, inner_dst_ip. * This case depends on the final implementation, if there is no default config of generic hash in configDB, remove this test case. +* If there is a cli to get the hw capabilities, verify the cli in this case. ### Test cases #2 - Verify when generic ecmp hash is configured, the traffic can be balanced accordingly. 1. The test is using the default links and routes in a community setup. From db38a9af211943a7ef2586bb7eb988281737d98b Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 30 Jan 2023 18:58:56 +0800 Subject: [PATCH 09/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 142 ++++++++++++++---------- 1 file changed, 85 insertions(+), 57 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index 01298e88b62..f590f63ffe9 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -7,7 +7,7 @@ | SONiC Generic Hash | [https://github.com/sonic-net/SONiC/doc/hash/hash-design.md]| -## Overview +## 1. Overview The hashing algorithm is used to make traffic-forwarding decisions for traffic exiting the switch. It makes hashing decisions based on values in various packet fields, as well as on the hash seed value. The packet fields used by the hashing algorithm varies by the configuration on the switch. @@ -20,39 +20,41 @@ GH is a feature which allows user to configure which hash fields suppose to be u GH provides global switch hash configuration for ECMP and LAG. -## Requirements +## 2. Requirements -#### The Generic Hash feature supports the following functionality: +### 2.1 The Generic Hash feature supports the following functionality: 1. Ethernet packet hashing configuration with inner/outer IP frames 2. Global switch hash configuration for ECMP and LAG 3. Warm/Fast reboot -#### This feature will support the following commands: +### 2.2 This feature will support the following commands: 1. config: set switch hash global configuration 2. show: display switch hash global configuration -#### This feature will provide error handling for the next situations: +### 2.3 This feature will provide error handling for the next situations: -1. Frontend - 1.1 Invalid parameter value -2. Backend - 2.1 Missing parameters - 2.2 Invalid parameter value - 2.3 Parameter removal - 2.4 Configuration removal +#### 2.3.1 Frontend +**This feature will provide error handling for the next situations:** +1. Invalid parameter value +#### 2.3.2 Backend +**This feature will provide error handling for the next situations:** +1. Missing parameters +2. Invalid parameter value +3. Parameter removal +4. Configuration removal -### Scope +## 3. Scope -The test is to verify the hash configuration can be added/updated by the generic hash, and the behavior of ECMP and lag hashing will change according to the generic hash config. +The test is to verify the hash configuration can be added/updated by the generic hash, and the ECMP and lag hash behavior will change according to the generic hash configurations. -### Scale / Performance +## 4. Scale / Performance No scale or performance test related -### Related **DUT** CLI commands +## 5. CLI commands -#### Config +### 5.1 Config The following command can be used to configure generic hash: ``` config @@ -103,16 +105,18 @@ config switch-hash global lag-hash \ 'INNER_L4_SRC_PORT' ``` -#### Show +### 5.2 Show The following command shows switch hash global configuration: ``` show |--- switch-hash |--- global + |--- capabilities ``` Example: -``` +**The following command shows switch hash global configuration:** +```bash root@sonic:/home/admin# show switch-hash global ECMP HASH LAG HASH ----------------- ----------------- @@ -133,7 +137,33 @@ INNER_SRC_IP INNER_SRC_IP INNER_L4_DST_PORT INNER_L4_DST_PORT INNER_L4_SRC_PORT INNER_L4_SRC_PORT ``` -### Related DUT configuration files + +**The following command shows switch hash capabilities:** +```bash +root@sonic:/home/admin# show switch-hash capabilities +ECMP HASH LAG HASH +----------------- ----------------- +IN_PORT IN_PORT +DST_MAC DST_MAC +SRC_MAC SRC_MAC +ETHERTYPE ETHERTYPE +VLAN_ID VLAN_ID +IP_PROTOCOL IP_PROTOCOL +DST_IP DST_IP +SRC_IP SRC_IP +L4_DST_PORT L4_DST_PORT +L4_SRC_PORT L4_SRC_PORT +INNER_DST_MAC INNER_DST_MAC +INNER_SRC_MAC INNER_SRC_MAC +INNER_ETHERTYPE INNER_ETHERTYPE +INNER_IP_PROTOCOL INNER_IP_PROTOCOL +INNER_DST_IP INNER_DST_IP +INNER_SRC_IP INNER_SRC_IP +INNER_L4_DST_PORT INNER_L4_DST_PORT +INNER_L4_SRC_PORT INNER_L4_SRC_PORT +``` + +### 6. DUT related configuration in config_db ``` { @@ -180,41 +210,39 @@ INNER_L4_SRC_PORT INNER_L4_SRC_PORT } ``` ### Supported topology -The test will be supported on t0 and t1 topologies. +The test supports t0 and t1 topologies, not supports dualtor topology. ## Test cases Note: - 1. The hash field is randomly selected in the test cases, and in the first phase, the fields required by MSFT will be coverd in the cases - including ip_proto, dst ip, src ip, dst port, src port, inner dst ip, inner src ip. Other supported fields will be covered in the future. + 1. The hash field is randomly selected in the test cases, and in the first phase, the fields required by MSFT will be coverd in the cases - including ip protocol, dst ip, src ip, dst port, src port, inner dst ip, inner src ip. Other supported fields will be covered in the future. 2. IPv4 or IPv6 traffic is randomly selected in the test cases. -### Test cases #1 - Verify the default hash fields are ip_proto, src_ip, dst_ip, src_l4_port, dst_l4_port, inner_src_ip, inner_dst_ip. -1. Get the default hash fields configration via cli "show switch-hash global" -2. Check the default ecmp and lag hash fields are ip_proto, src_ip, dst_ip, src_l4_port, dst_l4_port, inner_src_ip, inner_dst_ip. -* This case depends on the final implementation, if there is no default config of generic hash in configDB, remove this test case. -* If there is a cli to get the hw capabilities, verify the cli in this case. +### Test cases #1 - Verify the “show switch-hash capabilities” gets the supported hash fields. +1. Get the supported hash fields via cli "show switch-hash capabilities" +2. Check the fields are as expected`. ### Test cases #2 - Verify when generic ecmp hash is configured, the traffic can be balanced accordingly. -1. The test is using the default links and routes in a community setup. +1. The test is using the default links and routes in a t0/t1 testbed. 2. Randomly select a hash field and configure it to the ecmp hash list via cli "config switch-hash global ecmp-hash". -3. Configure the lag hash list to exclude the selected field in case the egress links are portchannels. -4. Send traffic with changing selected field from a downlink ptf to uplink destination via multiple nexthops. +3. Configure the lag hash list to exclude the selected field to verify the lag hash does not affect the hash result. +4. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination via multiple nexthops. 5. Check the traffic is balanced over the nexthops. 6. If the uplinks are portchannels with multiple members, check the traffic is not balanced over the members. ### Test cases #3 - Verify when generic lag hash is configured, the traffic can be balanced accordingly. -1. The test is using the default links and routes in a community setup, and only runs on setups which have multi-member portchannel uplinks. +1. The test is using the default links and routes in a t0/t1 testbed, and only runs on setups which have multi-member portchannel uplinks. 2. Randomly select a hash field and configure it to the lag hash list via cli "config switch-hash global lag-hash". -3. Configure the ecmp hash list to exclude the selected field. -4. Send traffic with changing selected field from a downlink ptf to uplink destination via the portchannels. -5. Check only one portchannel receives the traffic and the traffic is balanced over the members. - -### Test cases #4 - Verify when both generic ecmp/lag hash are configured with all the valid fields, the traffic can be balanced accordingly. -1. The test is using the default links and routes in a community setup. -2. Configure all the valid hash fields for the ecmp and lag hash. -3. Randomly select one hash field for the test. -4. Send traffic with changing selected field from a downlink ptf to uplink destination. +3. Configure the ecmp hash list to exclude the selected field to verify the ecmp hash does not affect the hash result. +4. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination via the portchannels. +5. Check the traffic is forwarded through only one portchannel is balanced over the members. + +### Test cases #4 - Verify when both generic ecmp and lag hash are configured with all the valid fields, the traffic can be balanced accordingly. +1. The test is using the default links and routes in a t0/t1 testbed. +2. Configure all the supported hash fields for the ecmp and lag hash. +3. Randomly select one hash field to test. +4. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination. 5. Check the traffc is balanced over all the uplink physical ports. ### Test cases #5 - Verify the generic hash cannot be configured seccessfully with invalid parameters. @@ -228,11 +256,11 @@ Note: c. invalid fields combined with valid fields d. duplicated valid fields(depends on the final implememtation) -### Test cases #6 - Verify when a generic hash config entry/parameter is removed, or updated with invalid values from configDB via redis cli, there will be warnings printed in the log. +### Test cases #6 - Verify when a generic hash config key is removed, or updated with invalid values from config_DB via redis cli, there will be warnings printed in the log. 1. Config ecmp and lag hash via cli. -2. Remove the ecmp hash entry via redis cli. +2. Remove the ecmp hash key via redis cli. 3. Check there is a warning printed in the log. -4. Remove the lag hash entry via redis cli. +4. Remove the lag hash key via redis cli. 5. Check there is a warning printed in the log. 6. Re-config the ecmp and lag hash via cli. 7. Update the ecmp hash fields with an invalid value via redis cli. @@ -240,14 +268,14 @@ Note: 9. Update the lag hash fields with an invalid value via redis cli. 10. Check there is a warning printed in the log. 11. Re-config the ecmp and lag hash via cli. -12. Remove the generic hash table via redis cli. +12. Remove the generic hash key via redis cli. 13. Check there is a warning printed in the log. ### Test cases #7 - Verify generic hash works properly when there are nexthop flaps. -1. The test is using the default links and routes in a community setup. -2. Configure all the valid hash fields for the ecmp and lag hash. -3. Randomly select one hash field for the test. -4. Send traffic with changing selected field from a downlink ptf to uplink destination. +1. The test is using the default links and routes in a t0/t1 testbed. +2. Configure all the supported hash fields for the ecmp and lag hash. +3. Randomly select one hash field to test. +4. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination. 5. Check the traffic is balanced over all the uplink ports. 6. Randomly shutdown 1 nexthop interface. 7. Send the traffic again. @@ -257,10 +285,10 @@ Note: 11. Check the traffic is balanced over all uplink ports with no packet loss. ### Test cases #8 - Verify generic hash works properly when there are lag member flaps. -1. The test is using the default links and routes in a community setup, and only runs on setups which have multi-member portchannel uplinks -3. Configure all the valid hash fields for the ecmp and lag hash. -4. Randomly select one hash field for the test. -5. Send traffic with changing selected field from a downlink ptf to uplink destination. +1. The test is using the default links and routes in a t0/t1 testbed, and only runs on setups which have multi-member portchannel uplinks +3. Configure all the supported hash fields for the ecmp and lag hash. +4. Randomly select one hash field to test. +5. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination. 6. Check the traffic is balanced over all the uplink ports. 7. Randomly shutdown 1 member port in all uplink portchannels. 8. Send the traffic again. @@ -270,11 +298,11 @@ Note: 12. Check the traffic is balance over all uplink ports with no packet loss. ### Test cases #9 - Verify generic hash running configuration persists after fast/warm reboot, and the saved configuration persists after cold reboot. -1. The test is using the default links and routes in a community setup. -2. Configure all the valid hash fields for the ecmp and lag hash. -3. Randomly select one hash field for the test. -4. Randomly select fast/warm/cold reboot for the test, if cold reboot, save the config before the reboot. -5. Send traffic with changing selected field from a downlink ptf to uplink destination. +1. The test is using the default links and routes in a t0/t1 testbed. +2. Configure all the supported hash fields for the ecmp and lag hash. +3. Randomly select one hash field to test. +4. Randomly select a reboot type from fast/warm/cold reboot, if cold reboot, save the config before the reboot. +5. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination. 6. Check the traffic is balance over all the uplink ports. 7. Randomly do fast/warm/cold reboot. 8. After the reboot, check the generic hash config via cli, it should keep the same as before the reboot. From f681bd8d5db0f814eb89615881a95554e49b9561 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 6 Feb 2023 13:56:06 +0800 Subject: [PATCH 10/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 104 ++++++++++++------------ 1 file changed, 54 insertions(+), 50 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index f590f63ffe9..124eab90dfc 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -48,13 +48,13 @@ GH provides global switch hash configuration for ECMP and LAG. The test is to verify the hash configuration can be added/updated by the generic hash, and the ECMP and lag hash behavior will change according to the generic hash configurations. -## 4. Scale / Performance +### 3.1 Scale / Performance No scale or performance test related -## 5. CLI commands +### 3.2 CLI commands -### 5.1 Config +#### 3.2.1 Config The following command can be used to configure generic hash: ``` config @@ -105,7 +105,7 @@ config switch-hash global lag-hash \ 'INNER_L4_SRC_PORT' ``` -### 5.2 Show +#### 3.2.2 Show The following command shows switch hash global configuration: ``` show @@ -163,7 +163,7 @@ INNER_L4_DST_PORT INNER_L4_DST_PORT INNER_L4_SRC_PORT INNER_L4_SRC_PORT ``` -### 6. DUT related configuration in config_db +### 3.3 DUT related configuration in config_db ``` { @@ -209,15 +209,17 @@ INNER_L4_SRC_PORT INNER_L4_SRC_PORT } } ``` -### Supported topology +### 3.4 Supported topology The test supports t0 and t1 topologies, not supports dualtor topology. -## Test cases +## 4. Test cases -Note: - 1. The hash field is randomly selected in the test cases, and in the first phase, the fields required by MSFT will be coverd in the cases - including ip protocol, dst ip, src ip, dst port, src port, inner dst ip, inner src ip. Other supported fields will be covered in the future. - 2. IPv4 or IPv6 traffic is randomly selected in the test cases. +Notes: + 1. The hash field is randomly selected in the test cases. Currently these fields are tested: 'IN_PORT', 'SRC_MAC', 'DST_MAC', 'ETHERTYPE', 'VLAN_ID', 'IP_PROTOCOL', 'SRC_IP', 'DST_IP', 'L4_SRC_PORT', 'L4_DST_PORT', 'INNER_SRC_IP', 'INNER_DST_IP'. + 2. DST_MAC, ETHERTYPE, VLAN_ID fields are only tested in lag hash test cases, because L2 traffic is needed to test these fields, and there is no ecmp hash when switching in L2. + 3. IPv4 and IPv6 are covered in the test, but the versions(including the inner version when testing the inner fields) are randomly selected in the test cases. + 4. For the inner fields, three types of encapsulations are covered: IPinIP, VxLAN and NVGRE. For the VxLAN packet, the default port 4789 and a custom port 13330 are covered in the test. ### Test cases #1 - Verify the “show switch-hash capabilities” gets the supported hash fields. 1. Get the supported hash fields via cli "show switch-hash capabilities" @@ -235,8 +237,9 @@ Note: 1. The test is using the default links and routes in a t0/t1 testbed, and only runs on setups which have multi-member portchannel uplinks. 2. Randomly select a hash field and configure it to the lag hash list via cli "config switch-hash global lag-hash". 3. Configure the ecmp hash list to exclude the selected field to verify the ecmp hash does not affect the hash result. -4. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination via the portchannels. -5. Check the traffic is forwarded through only one portchannel is balanced over the members. +4. If the hash field is DST_MAC, ETHERTYPE or VLAN_ID, change the topology to allow L2 switching and send L2 traffic in the next step. +5. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination via the portchannels. +6. Check the traffic is forwarded through only one portchannel is balanced over the members. ### Test cases #4 - Verify when both generic ecmp and lag hash are configured with all the valid fields, the traffic can be balanced accordingly. 1. The test is using the default links and routes in a t0/t1 testbed. @@ -245,33 +248,7 @@ Note: 4. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination. 5. Check the traffc is balanced over all the uplink physical ports. -### Test cases #5 - Verify the generic hash cannot be configured seccessfully with invalid parameters. -1. Configure the ecmp/lag hash with invalid fields list parameter. -2. Check there is a cli error that notifies the user the parameter is invalid. -3. Check there is a warning printed in the syslog. -4. Check the running config is not changed. -5. The invalid parameters to test: - a. empty parameter - b. single invalid field - c. invalid fields combined with valid fields - d. duplicated valid fields(depends on the final implememtation) - -### Test cases #6 - Verify when a generic hash config key is removed, or updated with invalid values from config_DB via redis cli, there will be warnings printed in the log. -1. Config ecmp and lag hash via cli. -2. Remove the ecmp hash key via redis cli. -3. Check there is a warning printed in the log. -4. Remove the lag hash key via redis cli. -5. Check there is a warning printed in the log. -6. Re-config the ecmp and lag hash via cli. -7. Update the ecmp hash fields with an invalid value via redis cli. -8. Check there is a warning printed in the log. -9. Update the lag hash fields with an invalid value via redis cli. -10. Check there is a warning printed in the log. -11. Re-config the ecmp and lag hash via cli. -12. Remove the generic hash key via redis cli. -13. Check there is a warning printed in the log. - -### Test cases #7 - Verify generic hash works properly when there are nexthop flaps. +### Test cases #5 - Verify generic hash works properly when there are nexthop flaps. 1. The test is using the default links and routes in a t0/t1 testbed. 2. Configure all the supported hash fields for the ecmp and lag hash. 3. Randomly select one hash field to test. @@ -284,20 +261,21 @@ Note: 10. Send the traffic again. 11. Check the traffic is balanced over all uplink ports with no packet loss. -### Test cases #8 - Verify generic hash works properly when there are lag member flaps. +### Test cases #6 - Verify generic hash works properly when there are lag member flaps. 1. The test is using the default links and routes in a t0/t1 testbed, and only runs on setups which have multi-member portchannel uplinks 3. Configure all the supported hash fields for the ecmp and lag hash. 4. Randomly select one hash field to test. -5. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination. -6. Check the traffic is balanced over all the uplink ports. -7. Randomly shutdown 1 member port in all uplink portchannels. -8. Send the traffic again. -9. Check the traffic is balance over all remaining uplink ports with no packet loss. -10. Recover the members and do shutdown/startup on them 3 more times. -11. Send the traffic again. -12. Check the traffic is balance over all uplink ports with no packet loss. - -### Test cases #9 - Verify generic hash running configuration persists after fast/warm reboot, and the saved configuration persists after cold reboot. +5. If the hash field is DST_MAC, ETHERTYPE or VLAN_ID, change the topology to allow L2 switching and send L2 traffic in the next step. +6. Send traffic with changing values of the field under test from a downlink ptf port to uplink destination. +7. Check the traffic is balanced over all the uplink ports. +8. Randomly shutdown 1 member port in all uplink portchannels. +9. Send the traffic again. +10. Check the traffic is balance over all remaining uplink ports with no packet loss. +11. Recover the members and do shutdown/startup on them 3 more times. +12. Send the traffic again. +13. Check the traffic is balance over all uplink ports with no packet loss. + +### Test cases #7 - Verify generic hash running configuration persists after fast/warm reboot, and the saved configuration persists after cold reboot. 1. The test is using the default links and routes in a t0/t1 testbed. 2. Configure all the supported hash fields for the ecmp and lag hash. 3. Randomly select one hash field to test. @@ -308,3 +286,29 @@ Note: 8. After the reboot, check the generic hash config via cli, it should keep the same as before the reboot. 9. Send traffic again. 10. Check the traffic is balance over all the uplink ports. + +### Test cases #8 - Verify the generic hash cannot be configured successfully with invalid parameters. +1. Configure the ecmp/lag hash with invalid fields list parameter. +2. Check there is a cli error that notifies the user the parameter is invalid. +3. Check there is a warning printed in the syslog. +4. Check the running config is not changed. +5. The invalid parameters to test: + a. empty parameter + b. single invalid field + c. invalid fields combined with valid fields + d. duplicated valid fields(depends on the final implememtation) + +### Test cases #9 - Verify when a generic hash config key is removed, or updated with invalid values from config_DB via redis cli, there will be warnings printed in the log. +1. Config ecmp and lag hash via cli. +2. Remove the ecmp hash key via redis cli. +3. Check there is a warning printed in the log. +4. Remove the lag hash key via redis cli. +5. Check there is a warning printed in the log. +6. Re-config the ecmp and lag hash via cli. +7. Update the ecmp hash fields with an invalid value via redis cli. +8. Check there is a warning printed in the log. +9. Update the lag hash fields with an invalid value via redis cli. +10. Check there is a warning printed in the log. +11. Re-config the ecmp and lag hash via cli. +12. Remove the generic hash key via redis cli. +13. Check there is a warning printed in the log. From dd6387f40f094896d07e80d866aa61b94e08c793 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 6 Feb 2023 19:01:01 +0800 Subject: [PATCH 11/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index 124eab90dfc..2006223048a 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -288,15 +288,14 @@ Notes: 10. Check the traffic is balance over all the uplink ports. ### Test cases #8 - Verify the generic hash cannot be configured successfully with invalid parameters. -1. Configure the ecmp/lag hash with invalid fields list parameter. +1. Configure the ecmp/lag hash with invalid fields parameter. 2. Check there is a cli error that notifies the user the parameter is invalid. -3. Check there is a warning printed in the syslog. -4. Check the running config is not changed. -5. The invalid parameters to test: +3. Check the running config is not changed. +4. The invalid parameters to test: a. empty parameter b. single invalid field c. invalid fields combined with valid fields - d. duplicated valid fields(depends on the final implememtation) + d. duplicated valid fields ### Test cases #9 - Verify when a generic hash config key is removed, or updated with invalid values from config_DB via redis cli, there will be warnings printed in the log. 1. Config ecmp and lag hash via cli. From c9e2129c52b52e08fa7d04acc27bf10b093beb06 Mon Sep 17 00:00:00 2001 From: Cong Hou <97947969+congh-nvidia@users.noreply.github.com> Date: Mon, 6 Feb 2023 19:03:05 +0800 Subject: [PATCH 12/12] Update Generic-hash-test-plan.md --- docs/testplan/Generic-hash-test-plan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/testplan/Generic-hash-test-plan.md b/docs/testplan/Generic-hash-test-plan.md index 2006223048a..c6bb0f74ffd 100644 --- a/docs/testplan/Generic-hash-test-plan.md +++ b/docs/testplan/Generic-hash-test-plan.md @@ -30,7 +30,7 @@ GH provides global switch hash configuration for ECMP and LAG. ### 2.2 This feature will support the following commands: 1. config: set switch hash global configuration -2. show: display switch hash global configuration +2. show: display switch hash global configuration or capabilities ### 2.3 This feature will provide error handling for the next situations: