Skip to content

[action] [PR:17909] [dualtor_io] Allow duplications for link down downstream I/O#17970

Merged
mssonicbld merged 1 commit intosonic-net:202411from
mssonicbld:cherry/202411/17909
Apr 21, 2025
Merged

[action] [PR:17909] [dualtor_io] Allow duplications for link down downstream I/O#17970
mssonicbld merged 1 commit intosonic-net:202411from
mssonicbld:cherry/202411/17909

Conversation

@mssonicbld
Copy link
Copy Markdown
Collaborator

Description of PR

Summary:
Fixes # (issue)

Type of change

  • Bug fix
  • Testbed and Framework(new/improvement)
  • New Test case
  • Skipped for non-supported platforms
  • Test case improvement

Back port request

  • 202012
  • 202205
  • 202305
  • 202311
  • 202405
  • 202411

Approach

What is the motivation for this PR?

The following two link failure cases are failing on Cisco/MLNX:

test_active_link_down_downstream_active
test_active_link_down_downstream_active_soc

The reason is that, after link down, between the fdb flush and tunnel route add (due to mux toggle-to-standby), the ASIC has no l2 information for server/soc neighbors, downstream traffic will flood to all vlan member ports on Cisco/MLNX platform.
Those two testcase has no tolerance for packet duplications due to that, on Broadcom platform, traffic to neighbors with no l2 information will be simply dropped.

Let's adapt to Cisco/MLNX platform, by allowing packet duplications for those two testcases.

Signed-off-by: Longxiang Lyu lolv@microsoft.com

How did you do it?

As the motivation.

How did you verify/test it?

dualtor_io/test_link_failure.py::test_active_link_down_downstream_active[active-active] PASSED [100%]
dualtor_io/test_link_failure.py::test_active_link_down_downstream_active_soc[active-active] PASSED [100%]

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

…et#17909)

What is the motivation for this PR?
The following two link failure cases are failing on Cisco/MLNX:

test_active_link_down_downstream_active
test_active_link_down_downstream_active_soc
The reason is that, after link down, between the fdb flush and tunnel route add (due to mux toggle-to-standby), the ASIC has no l2 information for server/soc neighbors, downstream traffic will flood to all vlan member ports on Cisco/MLNX platform.
Those two testcase has no tolerance for packet duplications due to that, on Broadcom platform, traffic to neighbors with no l2 information will be simply dropped.

Let's adapt to Cisco/MLNX platform, by allowing packet duplications for those two testcases.

How did you verify/test it?
dualtor_io/test_link_failure.py::test_active_link_down_downstream_active[active-active] PASSED                                                                                                                                                                         [100%]
dualtor_io/test_link_failure.py::test_active_link_down_downstream_active_soc[active-active] PASSED                                                                                                                                                                     [100%]

Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
@mssonicbld
Copy link
Copy Markdown
Collaborator Author

Original PR: #17909

@mssonicbld
Copy link
Copy Markdown
Collaborator Author

/azp run

@azure-pipelines
Copy link
Copy Markdown

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld mssonicbld merged commit 7c31e46 into sonic-net:202411 Apr 21, 2025
14 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