Extend LACP time multiplier for advanced-reboot tests with cEOS peers by justin-wong-ce · Pull Request #17964 · sonic-net/sonic-mgmt

justin-wong-ce · 2025-04-11T17:32:09Z

Description of PR

Summary:
Extend LACP timeout for cEOS peers by setting LACP timer multiplier to 5 during advanced-reboot PTF test, and restore the value to the default 3 after the test completes.

Fixes # (issue)

Type of change

Back port request

Approach

What is the motivation for this PR?

Transitioning from using vSonic peers to cEOS peers for some tests. Requested by Microsoft.

How did you do it?

Adding cli commands for each cEOS peers at the start and end of the PTF test advanced-reboot.py.

How did you verify/test it?

Tested with test_upgrade_path.py::test_upgrade_path on a Arista-7050CX3-32S-C32.

Any platform specific information?

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

Documentation

…sting

mssonicbld · 2025-04-11T17:32:17Z

/azp run

azure-pipelines · 2025-04-11T17:32:29Z

Azure Pipelines successfully started running 1 pipeline(s).

justin-wong-ce · 2025-04-11T21:28:16Z

/azpw run Azure.sonic-mgmt

mssonicbld · 2025-04-11T21:28:18Z

/AzurePipelines run Azure.sonic-mgmt

azure-pipelines · 2025-04-11T21:28:29Z

Azure Pipelines successfully started running 1 pipeline(s).

lipxu · 2025-04-15T06:52:32Z

thanks @justin-wong-ce , I picked this diff into our internal branch and will have a try in these days, meanwhile, could you please share your test result, if the case will pass 100% with this fix? thanks a lot

ansible/roles/test/files/ptftests/py3/advanced-reboot.py

mssonicbld · 2025-04-15T18:36:37Z

/azp run

azure-pipelines · 2025-04-15T18:36:48Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2025-04-15T18:39:07Z

/azp run

azure-pipelines · 2025-04-15T18:39:20Z

Azure Pipelines successfully started running 1 pipeline(s).

justin-wong-ce · 2025-04-15T18:48:42Z

thanks @justin-wong-ce , I picked this diff into our internal branch and will have a try in these days, meanwhile, could you please share your test result, if the case will pass 100% with this fix? thanks a lot

I have tested with upgrade_path/upgrade_path.py::test_upgrade_path and platform_tests/test_advanced_reboot.py::test_warm_reboot_mac_jump on the Arista-7050CX3-32S-C32 topo, they both pass.

I will be testing the sad cases from advanced_reboot overnight next.

justin-wong-ce · 2025-04-16T00:34:08Z

/azpw run Azure.sonic-mgmt

mssonicbld · 2025-04-16T00:34:10Z

/AzurePipelines run Azure.sonic-mgmt

azure-pipelines · 2025-04-16T00:34:21Z

Azure Pipelines successfully started running 1 pipeline(s).

lipxu

I picked the diff and tried it on our internal pipeline for case platform_tests/test_advanced_reboot.py, one passed, but the other failed (second retry seems timeout, will try again today),
https://elastictest.org/scheduler/testplan/67fdfe9e40a6f1f300f540f0
https://elastictest.org/scheduler/testplan/67fdfe7b1a569391805d5be0

justin-wong-ce · 2025-04-16T04:13:14Z

thanks @justin-wong-ce , I picked this diff into our internal branch and will have a try in these days, meanwhile, could you please share your test result, if the case will pass 100% with this fix? thanks a lot

I have tested with upgrade_path/upgrade_path.py::test_upgrade_path and platform_tests/test_advanced_reboot.py::test_warm_reboot_mac_jump on the Arista-7050CX3-32S-C32 topo, they both pass.

I will be testing the sad cases from advanced_reboot overnight next.

This change also passes all variants of platform_tests/advanced_reboot.py::test_warm_reboot_sad:

platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad-ld592] PASSED                  [ 14%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[multi_sad-ld592] PASSED              [ 28%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_bgp-ld592] PASSED                [ 42%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_lag_member-ld592] PASSED         [ 57%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_lag-ld592] PASSED                [ 71%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_vlan_port-ld592] PASSED          [ 85%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_inboot-ld592] PASSED             [100%]

justin-wong-ce · 2025-04-16T17:38:03Z

I picked the diff and tried it on our internal pipeline for case platform_tests/test_advanced_reboot.py, one passed, but the other failed (second retry seems timeout, will try again today), https://elastictest.org/scheduler/testplan/67fdfe9e40a6f1f300f540f0 https://elastictest.org/scheduler/testplan/67fdfe7b1a569391805d5be0

Thanks for checking.
I am unable to open the link to see the fail logs, do you mind pasting here or uploading a file?

lipxu · 2025-04-17T06:43:42Z

I picked the diff and tried it on our internal pipeline for case platform_tests/test_advanced_reboot.py, one passed, but the other failed (second retry seems timeout, will try again today), https://elastictest.org/scheduler/testplan/67fdfe9e40a6f1f300f540f0 https://elastictest.org/scheduler/testplan/67fdfe7b1a569391805d5be0

Thanks for checking. I am unable to open the link to see the fail logs, do you mind pasting here or uploading a file?

Thanks @justin-wong-ce I sent the logs to you, please help to check. thank you very much.

lipxu

@saiarcot895 Could you please help to review the PR, thanks a lot.

justin-wong-ce · 2025-04-17T21:32:03Z

I picked the diff and tried it on our internal pipeline for case platform_tests/test_advanced_reboot.py, one passed, but the other failed (second retry seems timeout, will try again today), https://elastictest.org/scheduler/testplan/67fdfe9e40a6f1f300f540f0 https://elastictest.org/scheduler/testplan/67fdfe7b1a569391805d5be0

Did the second try pass?
I have taken a look at the logs and never reached state activating is a flaky error that sometimes happen, failing that test will cause the DUT to be in a bad state and affect subsequent test runs.

I will also be running the tests again on a Arista-7060CX-32S-D48C8

justin-wong-ce · 2025-04-18T22:10:11Z

I picked the diff and tried it on our internal pipeline for case platform_tests/test_advanced_reboot.py, one passed, but the other failed (second retry seems timeout, will try again today), https://elastictest.org/scheduler/testplan/67fdfe9e40a6f1f300f540f0 https://elastictest.org/scheduler/testplan/67fdfe7b1a569391805d5be0

Did the second try pass? I have taken a look at the logs and never reached state activating is a flaky error that sometimes happen, failing that test will cause the DUT to be in a bad state and affect subsequent test runs.

I will also be running the tests again on a Arista-7060CX-32S-D48C8

The tests pass on my end:

platform_tests/test_advanced_reboot.py::test_fast_reboot[up613] PASSED                              [  7%]
platform_tests/test_advanced_reboot.py::test_fast_reboot_from_other_vendor[up613] SKIPPED (skip...) [ 14%]
platform_tests/test_advanced_reboot.py::test_warm_reboot[single-up613] PASSED                       [ 21%]
platform_tests/test_advanced_reboot.py::test_warm_reboot[dual-up613] SKIPPED (skip DUAL_TOR_MOD...) [ 28%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_mac_jump[up613] PASSED                     [ 35%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad-up613] PASSED    [ 42%]                                                                                     
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[multi_sad-up613] PASSED [ 50%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_bgp-up613] PASSED [ 57%]                                                                                    
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_lag_member-up613] PASSED [ 64%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_lag-up613] PASSED [ 71%]                                                                                    
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_vlan_port-up613] PASSED [ 78%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_inboot-up613] PASSED [ 85%]
platform_tests/test_advanced_reboot.py::test_cancelled_fast_reboot[up613] PASSED  [ 92%]                                                                                     
platform_tests/test_advanced_reboot.py::test_cancelled_warm_reboot[up613] PASSED  [100%]

Let me know if you would like me to send you the logs

lipxu · 2025-04-21T02:31:06Z

I picked the diff and tried it on our internal pipeline for case platform_tests/test_advanced_reboot.py, one passed, but the other failed (second retry seems timeout, will try again today), https://elastictest.org/scheduler/testplan/67fdfe9e40a6f1f300f540f0 https://elastictest.org/scheduler/testplan/67fdfe7b1a569391805d5be0

Did the second try pass? I have taken a look at the logs and never reached state activating is a flaky error that sometimes happen, failing that test will cause the DUT to be in a bad state and affect subsequent test runs.
I will also be running the tests again on a Arista-7060CX-32S-D48C8

The tests pass on my end:

platform_tests/test_advanced_reboot.py::test_fast_reboot[up613] PASSED                              [  7%]
platform_tests/test_advanced_reboot.py::test_fast_reboot_from_other_vendor[up613] SKIPPED (skip...) [ 14%]
platform_tests/test_advanced_reboot.py::test_warm_reboot[single-up613] PASSED                       [ 21%]
platform_tests/test_advanced_reboot.py::test_warm_reboot[dual-up613] SKIPPED (skip DUAL_TOR_MOD...) [ 28%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_mac_jump[up613] PASSED                     [ 35%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad-up613] PASSED    [ 42%]                                                                                     
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[multi_sad-up613] PASSED [ 50%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_bgp-up613] PASSED [ 57%]                                                                                    
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_lag_member-up613] PASSED [ 64%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_lag-up613] PASSED [ 71%]                                                                                    
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_vlan_port-up613] PASSED [ 78%]
platform_tests/test_advanced_reboot.py::test_warm_reboot_sad[sad_inboot-up613] PASSED [ 85%]
platform_tests/test_advanced_reboot.py::test_cancelled_fast_reboot[up613] PASSED  [ 92%]                                                                                     
platform_tests/test_advanced_reboot.py::test_cancelled_warm_reboot[up613] PASSED  [100%]

Let me know if you would like me to send you the logs

Thanks, @justin-wong-ce , It's OK with me, let's waiting for @saiarcot895's review, thanks a lot

StormLiangMS

LGTM

…sonic-net#17964) What is the motivation for this PR? Transitioning from using vSonic peers to cEOS peers for some tests. Requested by Microsoft. How did you do it? Adding cli commands for each cEOS peers at the start and end of the PTF test advanced-reboot.py. How did you verify/test it? Tested with test_upgrade_path.py::test_upgrade_path on a Arista-7050CX3-32S-C32.

mssonicbld · 2025-04-24T04:12:13Z

Cherry-pick PR to 202411: #18113

vaibhavhd · 2025-04-24T21:08:33Z

@justin-wong-ce, I think this change will extend LACP time multiplier for all advanced-reboot (or upgrade path) cases.

Although that will not fail the test, but it is also excessive - we only need to extend the LACP retry count for the platforms where we do NOT trust the boot up process to be fast enough.
On newer platforms this should not be needed (yet).

Additionally the test should verify the behavior of the TOR devices in production. So if (for eg., 7260) upgrades w/o retry count extended it should be tested against that criteria during qualification stage.

justin-wong-ce · 2025-04-24T22:49:27Z

@justin-wong-ce, I think this change will extend LACP time multiplier for all advanced-reboot (or upgrade path) cases.

Although that will not fail the test, but it is also excessive - we only need to extend the LACP retry count for the platforms where we do NOT trust the boot up process to be fast enough. On newer platforms this should not be needed (yet).

Additionally the test should verify the behavior of the TOR devices in production. So if (for eg., 7260) upgrades w/o retry count extended it should be tested against that criteria during qualification stage.

Hmm the ptftest has no easy way of telling whether if the test is testing for upgrade_path or not - I can try checking by comparing self.test_params['target_version'] vs the DUT's current version. Will post a follow up PR.

justin-wong-ce · 2025-04-25T18:34:18Z

@vaibhavhd seems like there is no easy to determine if the test is doing upgrade_path testing from the PTF test's POV since self.test_params['target_version'] is not populated. The current PTF test logic would do a version check if this field is populated, and skip the check if it is not populated (and probably for a good reason, since version names are not always consistent). We may also not want to always complete this check.

I think we have to introduce a new test param so the PTF test knows if it is doing a upgrade_path test or normal advanced-reboot.py test. Will that be okay?

…#17964) What is the motivation for this PR? Transitioning from using vSonic peers to cEOS peers for some tests. Requested by Microsoft. How did you do it? Adding cli commands for each cEOS peers at the start and end of the PTF test advanced-reboot.py. How did you verify/test it? Tested with test_upgrade_path.py::test_upgrade_path on a Arista-7050CX3-32S-C32.

Ryangwaite · 2025-04-29T04:22:44Z

@justin-wong-ce the issue here is that previously we used cEOS neighbors with 7260 (lacp multiplier 3) and sonic neighbors (lacp multiplier 5) for 7060 and Mellanox 2700. This gave us the tight lacp boundaries we needed for each platform.

Now with this change, ceos can be used for 7060 and 2700 with the same lacp multiplier 5 as sonic had, but the side-effect is that the timing boundary for 7260 has increased from 3 to 5 which we don't want.

This is not really a decision of the type of test (upgrade_path vs platform_tests/advanced_reboot) but rather, the platform + OS combo.

Previously, we had to make a decision to use sonic or ceos neighbors based on platform + OS and we did that by passing in the --neighbor_type=sonic cli arg. I think we should introduce a new cli arg called --ceos_neighbor_lacp_multiplier (for example) and plumb it through following the same path as --neighbor_type which will mean introducing a new ptf test param.

That way the test caller when they pick the testbed/dut and to/from versions they can also set the neighbor type to ceos and set the lacp multipiler too.

justin-wong-ce · 2025-04-29T18:42:22Z

@justin-wong-ce the issue here is that previously we used cEOS neighbors with 7260 (lacp multiplier 3) and sonic neighbors (lacp multiplier 5) for 7060 and Mellanox 2700. This gave us the tight lacp boundaries we needed for each platform.

Now with this change, ceos can be used for 7060 and 2700 with the same lacp multiplier 5 as sonic had, but the side-effect is that the timing boundary for 7260 has increased from 3 to 5 which we don't want.

This is not really a decision of the type of test (upgrade_path vs platform_tests/advanced_reboot) but rather, the platform + OS combo.

Previously, we had to make a decision to use sonic or ceos neighbors based on platform + OS and we did that by passing in the --neighbor_type=sonic cli arg. I think we should introduce a new cli arg called --ceos_neighbor_lacp_multiplier (for example) and plumb it through following the same path as --neighbor_type which will mean introducing a new ptf test param.

That way the test caller when they pick the testbed/dut and to/from versions they can also set the neighbor type to ceos and set the lacp multipiler too.

I see, sounds good.
I will add a new argument to pass into the ptftest and add a check to the test file to only set this argument when 7060 and 2700 is being tested.

saiarcot895 · 2025-05-01T23:06:35Z

@justin-wong-ce instead of hardcoding the 7060 and 2700 hwskus in the test scripts, can we have a CLI passed in from the top-level? (i.e. when triggering the sonic-mgmt test)

justin-wong-ce · 2025-05-02T17:44:35Z

@justin-wong-ce instead of hardcoding the 7060 and 2700 hwskus in the test scripts, can we have a CLI passed in from the top-level? (i.e. when triggering the sonic-mgmt test)

As in a new param defining lacp multiplier passed in from sonic-mgmt/tests/run.sh(via -e/extra params)?

Also, should platform_tests/test_advanced_reboot.py also use multiplier of 5 for 7060 and 2700, or only for upgrade_path?

Add an argument for the advanced_reboot PTF test to set the LACP multiplier for ceos neighbors. Requested here: sonic-net#17964 (comment)

justin-wong-ce · 2025-05-03T00:21:06Z

PR created @Ryangwaite @saiarcot895 :
#18215

Code sync sonic-net/sonic-mgmt:202411 => 202412 ``` * | c6a94a0 (pub_upstream/202411) Revert "[dualtor_io] Allow duplications for link down downstream I/O (sonic-net#17909)" (sonic-net#18192) * | de454d5 [testARPCompleted] Cleanup ptf ip after test failure (sonic-net#18170) * | 4a3d1d9 [dualtor] Refine `fdb_mac_learning_test.py` (sonic-net#18092) * | 5964a78 [dualtor_io] Fix the start marker not found issue (sonic-net#18096) * | ce40816 Extend LACP time multiplier for advanced-reboot tests with cEOS peers (sonic-net#17964) * | 0e70ba3 adjust port selection in case testQosSaiXonHysteresis for Cisco-8101 (sonic-net#18130) * | 8bb7203 [202411] Restore disable packet aging fixture 202411 (sonic-net#18103) * | 8f6d1a3 Filter out Not Applicable values in command line (sonic-net#18006) * | 9d5de5c Backport t0-118 test configs to 202411 (sonic-net#17983) ```

Code sync sonic-net/sonic-mgmt:202411 => 202503 ``` * 6b59eaa (HEAD -> sync/202503, origin/sync/202503) Merge remote-tracking branch 'pub_upstream/202411' into sync/202503 |\ | * c6a94a0 (pub_upstream/202411) Revert "[dualtor_io] Allow duplications for link down downstream I/O (sonic-net#17909)" (sonic-net#18192) | * de454d5 [testARPCompleted] Cleanup ptf ip after test failure (sonic-net#18170) | * 4a3d1d9 [dualtor] Refine `fdb_mac_learning_test.py` (sonic-net#18092) | * 5964a78 [dualtor_io] Fix the start marker not found issue (sonic-net#18096) | * ce40816 Extend LACP time multiplier for advanced-reboot tests with cEOS peers (sonic-net#17964) | * 0e70ba3 adjust port selection in case testQosSaiXonHysteresis for Cisco-8101 (sonic-net#18130) | * 8bb7203 [202411] Restore disable packet aging fixture 202411 (sonic-net#18103) | * 8f6d1a3 Filter out Not Applicable values in command line (sonic-net#18006) | * 9d5de5c Backport t0-118 test configs to 202411 (sonic-net#17983) | * e758401 mark xfail on generic hash test for isolated topo (sonic-net#18071) | * c65ceab [202411][dualtor] Skip pfcwd warm reboot on dualtor (sonic-net#18072) | * c509006 Improve disabling packet aging to support swap_syncd (sonic-net#17728) (sonic-net#17739) | * 9dc2244 [202411][dualtor-aa] Fix test_arp_dualtor on active-active dualtor (sonic-net#18073) | * cf12a33 fixed tacacs duplicate user issue (sonic-net#18068) | * 330a893 Fix telemetry/test_events.py for dualtor (sonic-net#18025) | * dc6fee8 Remove admin down ports in BUFFER PG check logic (sonic-net#17505) | * 805d538 Update generic hash test to support dualtor active active topology (sonic-net#16217) | * 7c31e46 [dualtor_io] Allow duplications for link down downstream I/O (sonic-net#17909) | * a7f50c6 Fix vlan vs router mac issue with test_qos_dscp_mapping.py (sonic-net#17846) (sonic-net#18003) | * 9ab1e7a Skip test_incremental_qos on Mellanox dualtor (sonic-net#17406) (sonic-net#18048) | * f42afd0 Force eos default creds to be string (sonic-net#18026) | * be542b0 Restore config after vxlan_crm from vxlan_ecmp. (sonic-net#17767) | * f0718b9 [Fix for Issue sonic-net#17413] Modified the Tx Rx port id list selection for all to all scenario (sonic-net#17919) | * 3eb4ed4 [dualtor_io] Collect syslog to debug (sonic-net#17722) | * d5bd995 Disable PFC-WD during PCBB and some wmk test improvements (sonic-net#17889) | * 2f512aa Update outer UDP sport range to exclude port 53 (sonic-net#17570) (sonic-net#17798) | * 980b373 skip test_bgp_slb advanced reboot for isolated topo (sonic-net#17470) | * 408bf9e Default the inner dscp to outer dscp map to be 1-1. (sonic-net#17860) | * 37495a1 Add dualtor fixtures to no_traffic test. (sonic-net#17916) | * a13b599 Only print the matched syslog in loganalzyer teardown check, no traceback info printed (sonic-net#17926) | * 6127f29 Revert "Skip test_vnet_decap on Cisco-8000 with 202411 (sonic-net#17776)" (sonic-net#17941) (sonic-net#17942) | * 60274db Increase timeout to 5 in verify_packet_any_port for background traffic (sonic-net#17904) ```

PR sonic-net#17964 merged. and case passed https://elastictest.org/scheduler/testplan/682d4c15dbe6294207827572?leftSideViewMode=detail&testcase=platform_tests%2Ftest_advanced_reboot.py&type=console ---- #### AI description (iteration 1) #### PR Classification Configuration update #### PR Summary This pull request updates the configuration to exclude the warm-reboot test for the 7060 platform. - Changes in `/.azure-pipelines/elastictest/arista/7060cx.t0.202411.yml`: Excluded `platform_tests/test_advanced_reboot.py` from the test scripts.  Reverts !11104

…sonic-net#17964) What is the motivation for this PR? Transitioning from using vSonic peers to cEOS peers for some tests. Requested by Microsoft. How did you do it? Adding cli commands for each cEOS peers at the start and end of the PTF test advanced-reboot.py. How did you verify/test it? Tested with test_upgrade_path.py::test_upgrade_path on a Arista-7050CX3-32S-C32. Signed-off-by: opcoder0 <[email protected]>

…sonic-net#17964) What is the motivation for this PR? Transitioning from using vSonic peers to cEOS peers for some tests. Requested by Microsoft. How did you do it? Adding cli commands for each cEOS peers at the start and end of the PTF test advanced-reboot.py. How did you verify/test it? Tested with test_upgrade_path.py::test_upgrade_path on a Arista-7050CX3-32S-C32. Signed-off-by: Aharon Malkin <[email protected]>

…sonic-net#17964) What is the motivation for this PR? Transitioning from using vSonic peers to cEOS peers for some tests. Requested by Microsoft. How did you do it? Adding cli commands for each cEOS peers at the start and end of the PTF test advanced-reboot.py. How did you verify/test it? Tested with test_upgrade_path.py::test_upgrade_path on a Arista-7050CX3-32S-C32. Signed-off-by: Guy Shemesh <[email protected]>

justin-wong-ce added 3 commits April 9, 2025 18:29

Added LACP multiplier timer changes to cEOS peers for upgrade_path te…

424497d

…sting

Extend lacp timeout for cEOS peers to 150 seconds

f346431

Switch to parse cli with json instead of awk

6ca525f

lipxu requested review from lipxu and saiarcot895 April 15, 2025 06:42

XuChen-MSFT reviewed Apr 15, 2025

View reviewed changes

ansible/roles/test/files/ptftests/py3/advanced-reboot.py Outdated Show resolved Hide resolved

Make helper function

2e7b085

justin-wong-ce force-pushed the lacp_timer_ceos branch from 3859bf6 to 2e7b085 Compare April 15, 2025 18:38

lipxu reviewed Apr 16, 2025

View reviewed changes

lipxu approved these changes Apr 17, 2025

View reviewed changes

StormLiangMS approved these changes Apr 24, 2025

View reviewed changes

StormLiangMS merged commit 1e11c26 into sonic-net:master Apr 24, 2025
19 checks passed

StormLiangMS added the Approved for 202411 branch label Apr 24, 2025

mssonicbld added the Created PR to 202411 branch label Apr 24, 2025

mssonicbld mentioned this pull request Apr 24, 2025

[action] [PR:17964] Extend LACP time multiplier for advanced-reboot tests with cEOS peers #18113

Merged

11 tasks

justin-wong-ce deleted the lacp_timer_ceos branch April 24, 2025 22:45

mssonicbld added Included in 202411 branch and removed Created PR to 202411 branch labels Apr 29, 2025

justin-wong-ce mentioned this pull request May 3, 2025

Add PTF test parameter for ceos neighbor lacp multiplier #18215

Merged

11 tasks

Ryangwaite added the Request for 202405 branch label May 6, 2025

mssonicbld mentioned this pull request May 15, 2025

[action] [PR:18215] Add PTF test parameter for ceos neighbor lacp multiplier #18423

Merged

11 tasks

Conversation

justin-wong-ce commented Apr 11, 2025

Description of PR

Type of change

Back port request

Approach

What is the motivation for this PR?

How did you do it?

How did you verify/test it?

Any platform specific information?

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

Documentation

Uh oh!

mssonicbld commented Apr 11, 2025

Uh oh!

azure-pipelines bot commented Apr 11, 2025

Uh oh!

justin-wong-ce commented Apr 11, 2025

Uh oh!

mssonicbld commented Apr 11, 2025

Uh oh!

azure-pipelines bot commented Apr 11, 2025

Uh oh!

lipxu commented Apr 15, 2025

Uh oh!

Uh oh!

mssonicbld commented Apr 15, 2025

Uh oh!

azure-pipelines bot commented Apr 15, 2025

Uh oh!

mssonicbld commented Apr 15, 2025

Uh oh!

azure-pipelines bot commented Apr 15, 2025

Uh oh!

justin-wong-ce commented Apr 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

justin-wong-ce commented Apr 16, 2025

Uh oh!

mssonicbld commented Apr 16, 2025

Uh oh!

azure-pipelines bot commented Apr 16, 2025

Uh oh!

lipxu left a comment

Choose a reason for hiding this comment

Uh oh!

justin-wong-ce commented Apr 16, 2025

Uh oh!

justin-wong-ce commented Apr 16, 2025

Uh oh!

lipxu commented Apr 17, 2025

Uh oh!

lipxu left a comment

Choose a reason for hiding this comment

Uh oh!

justin-wong-ce commented Apr 17, 2025

Uh oh!

justin-wong-ce commented Apr 18, 2025

Uh oh!

lipxu commented Apr 21, 2025

Uh oh!

StormLiangMS left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mssonicbld commented Apr 24, 2025

Uh oh!

vaibhavhd commented Apr 24, 2025

Uh oh!

justin-wong-ce commented Apr 24, 2025

Uh oh!

justin-wong-ce commented Apr 25, 2025

Uh oh!

Ryangwaite commented Apr 29, 2025

Uh oh!

justin-wong-ce commented Apr 29, 2025

Uh oh!

saiarcot895 commented May 1, 2025

Uh oh!

justin-wong-ce commented May 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

justin-wong-ce commented Apr 15, 2025 •

edited

Loading

justin-wong-ce commented May 2, 2025 •

edited

Loading

justin-wong-ce commented May 3, 2025 •

edited

Loading