Skip to content
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

[action] [PR:11921] Fixed test issues for dualtor topologies. #12488

Merged
merged 1 commit into from
Apr 17, 2024

Conversation

mssonicbld
Copy link
Collaborator

Description of PR

Summary: Fixed test issue in dualtor topology.
Fixes # (issue): https://github.com/aristanetworks/sonic-qual.msft/issues/69

Type of change

  • Bug fix
  • Testbed and Framework(new/improvement)
  • Test case(new/improvement)

Back port request

  • 201911
  • 202012
  • 202205
  • 202305
  • 202311

Approach

What is the motivation for this PR?

  1. 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.
  2. 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?

  1. 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

  1. 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

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.
@mssonicbld
Copy link
Collaborator Author

Original PR: #11921

@mssonicbld mssonicbld merged commit 1e11926 into sonic-net:202305 Apr 17, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants