-
Notifications
You must be signed in to change notification settings - Fork 740
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed test issues for dualtor topologies. #11921
Fixed test issues for dualtor topologies. #11921
Conversation
Used `toggle_all_simulator_ports_to_enum_rand_one_per_hwsku_frontend_host_m` to make all the links active of the randomly selected ToR.
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
The testcase dualtor/test_tor_ecn.py::test_ecn_during_encap_on_standby is suppose to run on standby ToR however the test is not doing anything to make the randomly selected ToR as standby in case of active-active links as the fixture `toggle_all_simulator_ports_to_rand_unselected_tor` only works for active-standby links. The proposed solution is to move the fixture `setup_active_active_ports` from dualtor/test_tor_ecn.py, rename it to `setup_standby_ports_on_rand_selected_tor` and let both the tests use it.
UC1 will always have gRPC traffic flowing through if active-active links exist (dualtor-aa/dualtor-mixed), therefore, queue counters check for UC1 should be skipped in case of following tests if active-active links exist. 1. bgp/test_bgp_queue.py 2. dualtor/test_tor_ecn.py
The traffic from active-active mux ports is ECMPed twice:first time on the NiC to choose the ToR, second time on the ToR to choose the uplinks. The NiC ECMP is not within the test scope, and we also cannot guarantee that the traffic is evenly distributed among all the uplinks. The proposed fix is to configure active-active ports to work in active-standby mode in case of the following tests :- 1. dhcp_relay/test_dhcp_relay.py 2. dhcp_relay/test_dhcpv6_relay.py 3. drop_packets/test_configurable_drop_counters.py 4. pfcwd/test_pfcwd_function.py 5. route/test_route_flap.py 6. snmp/test_snmp_fdb.py 7. everflow/test_everflow_testbed.py 8. everflow/test_everflow_ipv6.py
99975b4
to
3056620
Compare
…nks." This change is not longer required as it was fixed by: sonic-net#11459 This reverts commit 45cb9ed.
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
hi @vivekverma-arista could I ask your help to validate these changes with T0/T1? to avoid regression. pls verify with 202305 image also. |
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
What is the motivation for this PR? In some test cases the packets go to unselected ToR in case of active-active links or forwarded by the unselected ToR in case of active-standby links. Some tests verify queue counters, but this check fails for UC1 in presence of active active links as UC1 always has gRPC traffic flowing through it. How did you do it? First issue can be addressed by using the following fixtures in case of active-standby (wherever missing, commit 1) :- a) toggle_all_simulator_ports_to_rand_selected_tor b) toggle_all_simulator_ports_to_enum_rand_one_per_hwsku_frontend_host_m To handle this in case of active-active links new fixtures are introduced (commit 3 & 4) a) setup_standby_ports_on_rand_unselected_tor b) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m c) setup_standby_ports_on_rand_unselected_tor_unconditionally d) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m_unconditionally Second issue can be addressed by simply skipping the check for UC1 in presence of active-active links. (commit 2) How did you verify/test it? Verified on Arista 7260 device using dualtor/dualtor-aa topology.
Cherry-pick PR to 202305: #12488 |
What is the motivation for this PR? In some test cases the packets go to unselected ToR in case of active-active links or forwarded by the unselected ToR in case of active-standby links. Some tests verify queue counters, but this check fails for UC1 in presence of active active links as UC1 always has gRPC traffic flowing through it. How did you do it? First issue can be addressed by using the following fixtures in case of active-standby (wherever missing, commit 1) :- a) toggle_all_simulator_ports_to_rand_selected_tor b) toggle_all_simulator_ports_to_enum_rand_one_per_hwsku_frontend_host_m To handle this in case of active-active links new fixtures are introduced (commit 3 & 4) a) setup_standby_ports_on_rand_unselected_tor b) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m c) setup_standby_ports_on_rand_unselected_tor_unconditionally d) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m_unconditionally Second issue can be addressed by simply skipping the check for UC1 in presence of active-active links. (commit 2) How did you verify/test it? Verified on Arista 7260 device using dualtor/dualtor-aa topology.
Cherry-pick PR to 202311: #12489 |
What is the motivation for this PR? In some test cases the packets go to unselected ToR in case of active-active links or forwarded by the unselected ToR in case of active-standby links. Some tests verify queue counters, but this check fails for UC1 in presence of active active links as UC1 always has gRPC traffic flowing through it. How did you do it? First issue can be addressed by using the following fixtures in case of active-standby (wherever missing, commit 1) :- a) toggle_all_simulator_ports_to_rand_selected_tor b) toggle_all_simulator_ports_to_enum_rand_one_per_hwsku_frontend_host_m To handle this in case of active-active links new fixtures are introduced (commit 3 & 4) a) setup_standby_ports_on_rand_unselected_tor b) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m c) setup_standby_ports_on_rand_unselected_tor_unconditionally d) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m_unconditionally Second issue can be addressed by simply skipping the check for UC1 in presence of active-active links. (commit 2) How did you verify/test it? Verified on Arista 7260 device using dualtor/dualtor-aa topology.
What is the motivation for this PR? In some test cases the packets go to unselected ToR in case of active-active links or forwarded by the unselected ToR in case of active-standby links. Some tests verify queue counters, but this check fails for UC1 in presence of active active links as UC1 always has gRPC traffic flowing through it. How did you do it? First issue can be addressed by using the following fixtures in case of active-standby (wherever missing, commit 1) :- a) toggle_all_simulator_ports_to_rand_selected_tor b) toggle_all_simulator_ports_to_enum_rand_one_per_hwsku_frontend_host_m To handle this in case of active-active links new fixtures are introduced (commit 3 & 4) a) setup_standby_ports_on_rand_unselected_tor b) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m c) setup_standby_ports_on_rand_unselected_tor_unconditionally d) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m_unconditionally Second issue can be addressed by simply skipping the check for UC1 in presence of active-active links. (commit 2) How did you verify/test it? Verified on Arista 7260 device using dualtor/dualtor-aa topology.
Testcases fail in drop_packets/test_configurable_drop_counters.py fail in dualtor-aa because some of the traffic goes to the unselected ToR. How did you do it? Similar approach is taken as in #11921 How did you verify/test it? Verified on Arista 7260 and Arista 7050 with both dualtor and dualtor-aa topology.
Testcases fail in drop_packets/test_configurable_drop_counters.py fail in dualtor-aa because some of the traffic goes to the unselected ToR. How did you do it? Similar approach is taken as in sonic-net#11921 How did you verify/test it? Verified on Arista 7260 and Arista 7050 with both dualtor and dualtor-aa topology.
Testcases fail in drop_packets/test_configurable_drop_counters.py fail in dualtor-aa because some of the traffic goes to the unselected ToR. How did you do it? Similar approach is taken as in sonic-net#11921 How did you verify/test it? Verified on Arista 7260 and Arista 7050 with both dualtor and dualtor-aa topology.
Testcases fail in drop_packets/test_configurable_drop_counters.py fail in dualtor-aa because some of the traffic goes to the unselected ToR. How did you do it? Similar approach is taken as in #11921 How did you verify/test it? Verified on Arista 7260 and Arista 7050 with both dualtor and dualtor-aa topology.
Testcases fail in drop_packets/test_configurable_drop_counters.py fail in dualtor-aa because some of the traffic goes to the unselected ToR. How did you do it? Similar approach is taken as in #11921 How did you verify/test it? Verified on Arista 7260 and Arista 7050 with both dualtor and dualtor-aa topology.
Description of PR
Summary: Fixed test issue in dualtor topology.
Fixes # (issue): https://github.com/aristanetworks/sonic-qual.msft/issues/69
Type of change
Back port request
Approach
What is the motivation for this PR?
How did you do it?
First issue can be addressed by using the following fixtures in case of active-standby (wherever missing, commit 1) :-
a) toggle_all_simulator_ports_to_rand_selected_tor
b) toggle_all_simulator_ports_to_enum_rand_one_per_hwsku_frontend_host_m
To handle this in case of active-active links new fixtures are introduced (commit 3 & 4)
a) setup_standby_ports_on_rand_unselected_tor
b) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m
c) setup_standby_ports_on_rand_unselected_tor_unconditionally
d) setup_standby_ports_on_non_enum_rand_one_per_hwsku_frontend_host_m_unconditionally
Second issue can be addressed by simply skipping the check for UC1 in presence of active-active links. (commit 2)
How did you verify/test it?
Verified on Arista 7260 device using dualtor/dualtor-aa topology.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation