testssssss - #25600
Closed
simonchen1109 wants to merge 167 commits into
Closed
Conversation
…ry_table_after_syncd_orchagent (#25085) ### Description of PR Summary: This PR makes two related fixes to `tests/lldp/test_lldp_syncd.py::test_lldp_entry_table_after_syncd_orchagent`, which deliberately restarts `swss`/`syncd` and cascades to a `bgp` container restart. #### Commit 1 — Replace `time.sleep(60)` with a BGP convergence wait After restarting `swss`/`syncd`, the test currently waits a hardcoded `time.sleep(60)` before proceeding. On a DUT with many BGP neighbors (e.g., T1/T2 with 7050CX3), 60 seconds is **not enough** for bgpd to fully re-converge after the cascade restart. This leaves bgpd in a warming-up state by the time the test ends. The **next test** (e.g. `test_lldp_entry_table_after_cont_flap`) then takes its memory baseline snapshot while bgpd RSS is still low. When bgpd subsequently reaches its normal post-init RSS during the next test, the framework's memory monitor reports a large increase (e.g. +139 MB > 128 MB threshold) and fails the next test with a **false-positive memory alarm**. Replace `time.sleep(60)` with `wait_until(duthost.check_bgp_session_state, ...)` so the test deterministically waits for all BGP sessions to reach `Established` state before exiting. #### Commit 2 — Disable `memory_utilization` check for this test This test deliberately restarts swss/syncd, which cascades to a `bgp` container restart. The `memory_utilization` fixture takes before/after snapshots that become meaningless across such a restart (bgpd RSS drops to ~0 then warms back up over several minutes), so the in-test memory delta has no signal. Add `@pytest.mark.disable_memory_utilization` to make the test intent explicit and prevent future framework changes (e.g. alarming on volatility or absolute decreases) from flagging this test on a meaningless measurement. This is consistent with other restart-style tests (e.g. `test_advanced_reboot`, `test_warm_reboot`, `test_container_autorestart`). ADO: https://msazure.visualstudio.com/One/_workitems/edit/38230412 ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? Observed in plan `6a1b270895e3f84fd1e9ace9` (7050cx3.m1-128.202603 NightlyTest, branch `20260310.11`) on `testbed-bjw3-can-7050c-6`: - `test_lldp_entry_table_after_syncd_orchagent` restarted swss/syncd (which cascades to bgp container) - `time.sleep(60)` returned while bgpd RSS was still 67.9 MB (mid-convergence) - Next test `test_lldp_entry_table_after_cont_flap` took its "before" snapshot: bgpd = 67.9 MB - 16 minutes later, bgpd had warmed up to its normal 207.1 MB - Framework reported `+139.2 MB > 128 MB threshold` → ALARM → next test FAILED `vtysh show memory bgp` (FRR internal allocator counter) showed a consistent 204 MB both before and after the next test — proving bgpd did not actually leak memory. Only `top` RSS appeared to grow because the baseline was taken too early. #### How did you do it? **Commit 1 — wait for BGP convergence instead of sleep(60):** ```python bgp_neighbors = list(duthost.get_bgp_neighbors().keys()) pytest_assert( wait_until(300, 10, 30, duthost.check_bgp_session_state, bgp_neighbors), "BGP sessions did not reach Established state after swss restart", ) ``` - Uses existing `duthost.get_bgp_neighbors()` to dynamically fetch the neighbor list (works on all topologies) - Uses existing `duthost.check_bgp_session_state()` (default expected state = `"established"`) - Parameters: `timeout=300s`, `interval=10s`, `delay=30s` **Commit 2 — disable memory check on this test:** ```python @pytest.mark.disable_loganalyzer @pytest.mark.disable_memory_utilization # NEW def test_lldp_entry_table_after_syncd_orchagent(...): ``` The two changes are complementary: - **Commit 1** prevents pollution of the next test (wait for BGP convergence before exit) - **Commit 2** disables the meaningless measurement on this test itself #### How did you verify/test it? Logic review against existing helpers (`get_bgp_neighbors`, `check_bgp_session_state`, `wait_until`, `disable_memory_utilization` marker) — all are widely used elsewhere in sonic-mgmt. Behavior change matrix for Commit 1: - Healthy fast DUT (T0): exits in ~20–30 s (faster than old 60s sleep) - Slow DUT (T1 with many neighbors): waits up to 300 s for actual convergence (vs. silently returning after insufficient 60s) A real run on testbed-bjw3-can-7050c-7 / 7050c-6 will be needed to confirm the next-test memory alarm cascade no longer fires. #### Any platform specific information? None — both changes are platform-agnostic. The helpers used are standard sonic-mgmt helpers. #### Supported testbed topology if it's a new test case? N/A — not a new test case. The existing test continues to run on all topologies where it currently runs. ### Documentation N/A ### Elastic Test Jobs - testbed-bjw3-can-7050c-7: https://elastictest.org/scheduler/testplan/6a20dc922047c3c4a9f91c7c - testbed-bjw3-can-7050c-8: https://elastictest.org/scheduler/testplan/6a20dc94729d944bd21c92e0 - testbed-bjw3-can-7050c-11: https://elastictest.org/scheduler/testplan/6a20dc962296f2ad62e47dbc --------- Signed-off-by: lipxu <lipxu@microsoft.com> Signed-off-by: Liping Xu <108326363+lipxu@users.noreply.github.com>
…ious config_reload (#25116) ### Description of PR The `clean_passw_policies` teardown in `tests/passw_hardening` reset the password hardening policies to a set of hard-coded "default" values. Whenever those hard-coded values drifted from the real SONiC boot defaults (defined in `init_cfg.json.j2`), the module-scoped config check detected a `CONFIG_DB` diff and ran `config_reload`. That `config_reload` restarts BGP, which produces spurious `bgpd memory increased` alarms on the **next, unrelated test** (e.g. `test_snmp_memory`), causing flaky failures. This PR replaces the hard-coded reset with a **snapshot/restore** approach: - `get_passw_policies()` captures the DUT's actual `PASSW_HARDENING|POLICIES` values once per module. - `restore_passw_policies()` in teardown re-applies **only the fields that changed** during the test. A test that does not touch the policies now issues **zero** CLI commands in teardown, so no `CONFIG_DB` diff is created and no `config_reload` is triggered. Summary: Fixes spurious `test_snmp_memory` (and other downstream) failures caused by password hardening teardown triggering `config_reload`. ADO: https://msazure.visualstudio.com/One/_workitems/edit/38230412 ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [x] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? `test_snmp_memory` (and other tests) intermittently fail with `bgpd memory increased` alarms. Root cause: the password hardening test teardown resets policies to hard-coded "default" values that drift from the image's real boot defaults. The resulting `CONFIG_DB` diff triggers `config_reload` → BGP restart → memory alarm on the subsequent test. #### How did you do it? - Added `get_passw_policies(duthost)` to snapshot the live `PASSW_HARDENING|POLICIES` hash from `CONFIG_DB` (parsed with `ast.literal_eval`; returns `None` and logs a warning on read/parse failure). - Added `restore_passw_policies(duthost, snapshot)` which reads the live state at teardown and re-applies only the fields whose value differs from the snapshot. `state` is applied last. If the live state cannot be read, it conservatively restores every snapshot field. CONFIG_DB field names (underscores) are mapped to the `config passw-hardening policies` CLI subcommands (hyphens) via `field.replace('_', '-')`, removing the previous hand-maintained key map. - Replaced the module fixture so it snapshots the actual values (`passw_policies_snapshot`); `clean_passw_policies` now restores from that snapshot. #### How did you verify/test it? - Verified `sonic-db-cli CONFIG_DB hgetall "PASSW_HARDENING|POLICIES"` output and `ast.literal_eval` parsing on a live DUT (Arista-7050CX3). - Confirmed all 10 DB fields map 1:1 to `config passw-hardening policies` CLI subcommands via pure `_`→`-` transform. - Unit-simulated the restore diff logic: unchanged → 0 commands; changed fields → only those re-applied with `state` last; live-read `None` → restore all; snapshot `None` → skip. - flake8 (max-line-length=120) clean; `py_compile` passes. #### Any platform specific information? None. The fix is platform-agnostic. #### Supported testbed topology if it's a new test case? N/A — existing test improvement. ### Documentation N/A ### Elastic Test Jobs - testbed-bjw3-can-7050c-11: https://elastictest.org/scheduler/testplan/6a28e79d2047c3c4a9f924b1 Signed-off-by: Liping Xu <108326363+lipxu@users.noreply.github.com>
…#25297) ### Description of PR Summary: PR #25085 removed the import time statement because no one was using it at the time. However, PR #24876 — which adds code that uses time — was merged afterward, which caused the issue. `tests/lldp/test_lldp_syncd.py` uses `time.sleep()` inside the `wait_for_lldp_appl_db()` helper, but the `time` module is never imported. As soon as the `lldpctl` stabilization retry loop is entered, the test raises: ``` NameError: name 'time' is not defined. Did you forget to import 'time'? File "tests/lldp/test_lldp_syncd.py", line 73, in wait_for_lldp_appl_db time.sleep(poll_interval) ``` This is a deterministic (100%) failure of `test_lldp_syncd.py` whenever the retry/poll path runs. The fix adds the missing `import time` to the stdlib import block. Fixes # (issue) ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? `test_lldp_syncd.py` fails immediately with `NameError("name 'time' is not defined")` because the `time` module is referenced (`time.sleep(poll_interval)` and `time.sleep(appl_db_poll_interval)`) but never imported. The test cannot pass on any platform until this import is added. #### How did you do it? Added `import time` to the module-level import block, alongside the other stdlib imports (`json`, `logging`). #### How did you verify/test it? - Confirmed the file references `time.` in two places (`wait_for_lldp_appl_db` retry loops) with no corresponding import. - Verified `python -c "import ast; ast.parse(open('tests/lldp/test_lldp_syncd.py').read())"` parses cleanly after the change. - Single-line, import-only change with no behavioral impact beyond resolving the `NameError`. #### Any platform specific information? None — platform-independent Python import fix. #### Supported testbed topology if it's a new test case? N/A — existing test fix. ### Documentation N/A Signed-off-by: Liping Xu <108326363+lipxu@users.noreply.github.com>
Approach What is the motivation for this PR? BGP sessions failed to establish after stopping orchagent, and it could persist for long time. How did you do it? Wait for bgp in config reload operation in suppress fib test How did you verify/test it? Run it locally Any platform specific information? Supported testbed topology if it's a new test case? Documentation
…itions (#25268) PR #24618 added a second condition for Nokia-7215-C1 under the existing test_console_availability skip rule without specifying conditions_logical_operator. The default operator is AND, so the two platform-specific predicates were AND'ed together and could never both match, causing the skip to never trigger on either platform. Set conditions_logical_operator: OR so each platform predicate is evaluated independently and the test is correctly skipped on both arm64-c8220tg_48a_o* (vpp) and arm64-nokia_ixs7215_c1xa-r0 hardware. <!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 ### 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 <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> Signed-off-by: lizhijianrd <zhijianli@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…R_SYMBOL (#23936) <!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Broadcom TH SAI does not support FEC_ERR_SYMBOL on 50G links. This test is reliant on that counter to work. Skipping the test logic for intfs that has 50G link speed on the up.t0-56 topo. Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [x] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 ### Approach #### What is the motivation for this PR? The test is failing on Arista-7060CX-32S-D48C8. #### How did you do it? Skip the test logic for affected intfs as it is a ASIC/SAI support issue. #### How did you verify/test it? `platform_tests/test_intf_fec.py` no longer fails on Arista-7060CX-32S-D48C8. #### Any platform specific information? Broadcom Legacy (Tomahawk only). #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> --------- Signed-off-by: Justin Wong <jvwong@arista.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR Summary: Ansible 2.19+ enforces stricter type checking for boolean conditionals in when: clauses, causing fatal task failures that block fanout deployment and ECMP testing. This PR adds explicit | bool filters to all affected conditionals to ensure Ansible 2.19+ compatibility. The error occurs at: - ansible/roles/fanout/tasks/rootfanout_connect.yml line 8 - ansible/roles/test/tasks/ecmp.yml lines 29, 43 - ansible/roles/test/tasks/ecmp/link_down.yml lines 46, 50, 74, 78 Summary: Fixes #24936 ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [x] 202605 ### Approach #### What is the motivation for this PR? **add-topo was failing on master** `./testbed-cli.sh -t testbed.yaml -m veos -k ceos add-topo dt password.txt -vvv` Ansible 2.19+ requires explicit boolean type conversion in conditional expressions. Without the | bool filter, variables in when: clauses are treated as strings, causing fatal errors: [ERROR]: Task failed: Conditional result (True) was derived from value of type 'str' at '/data/ansible/roles/fanout/tasks/rootfanout_connect.yml:4:13'. Conditionals must have a boolean result. fatal: [STR-ACS-SERV-01]: FAILED! This blocks critical workflows: - Fanout switch deployment fails at rootfanout_connect.yml - ECMP test configuration fails for IPv4/IPv6 routing - Link down test scenarios cannot execute #### How did you do it? Fixed boolean conditionals in 3 files by adding explicit | bool filters: 1. ansible/roles/fanout/tasks/rootfanout_connect.yml (line 8): - Changed: `when: deploy_leaf` - To: `when: deploy_leaf | bool` 2. ansible/roles/test/tasks/ecmp.yml (lines 29, 43): - Changed: `when: "{{ ipv6 }} == True"` - To: `when: ipv6 | bool` - Changed: `when: "{{ ipv6 }} == False"` - To: `when: not (ipv6 | bool)` 3. ansible/roles/test/tasks/ecmp/link_down.yml (lines 46, 50, 74, 78): - Applied same ipv6 boolean fixes (4 occurrences) - Replaced True/False comparisons with | bool filter #### How did you verify/test it? add-topo passed without errors `./testbed-cli.sh -t testbed.yaml -m veos -k ceos add-topo dt password.txt -vvv` #### Any platform specific information? None #### Supported testbed topology if it's a new test case? None ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> None Signed-off-by: Pratik Dam <pdam@arista.com>
…24979) Currently we call the perform_reboot in tests.smartswitch.common.reboot to reboot the switch in test_cold_reboot_switch. The method doesn't have the step to check the switch ssh down. But in the later step post_test_switch_check, it checks the ssh started state. This step could immediately pass and cause failure because the switch is still rebooting. We should use the common reboot function which has the step to wait ssh down. Same as in test case test_dpu_status_post_switch_reboot. - What is the motivation for this PR? Fix test issue in test_cold_reboot_switch - How did you do it? Call common reboot function in test_cold_reboot_switch - How did you verify/test it? Run the test on SN4280 smartswitch testbed. Signed-off-by: Cong Hou <congh@nvidia.com>
Add Mellanox-SN5640-C508O1X2 into the hwsku skip list for generic_config_updater/test_pfcwd_interval.py - What is the motivation for this PR? pfcwd gcu test should be skipped on the lossy platform sn5640 with hwsku Mellanox-SN5640-C508O1X2 - How did you do it? Add Mellanox-SN5640-C508O1X2 into the hwsku skip list for generic_config_updater/test_pfcwd_interval.py - How did you verify/test it? Run it locally Signed-off-by: echuawu <chuanw@nvidia.com>
…#25119) Add enable_monit_refresh for all test cases in test_monitor_config.py - What is the motivation for this PR? Some test cases in test_monitor_config.py will report false alarm for the monitor memory utilization check - How did you do it? add enable_monit_refresh to the monitor config tests. - How did you verify/test it? run the test cases - Any platform specific information? Signed-off-by: Yanpeng Zhang <yanpengz@nvidia.com>
…ge and test_vlan_interface_tc1_suite (#25121) Enable monit refresh for the test case test_lo_interface_tc2_vrf_change and test_vlan_interface_tc1_suite - What is the motivation for this PR? The test cases are failed due to the false alarm of monitor memory check. - How did you do it? Enable monit refresh for the test case test_lo_interface_tc2_vrf_change and test_vlan_interface_tc1_suite - How did you verify/test it? Run the test cases Signed-off-by: Yanpeng Zhang <yanpengz@nvidia.com>
Topology t1-isolated-d32u1s2 was newly introduced in #24521 Add t1-isolated-d32u1s2 into lossy topology list - What is the motivation for this PR? Add t1-isolated-d32u1s2 into lossy topology list - How did you do it? Add t1-isolated-d32u1s2 into lossy topology list - How did you verify/test it? Run it locally Signed-off-by: echuawu <chuanw@nvidia.com>
Update qos case for SPC6. sonic-net/sonic-buildimage#27276 - What is the motivation for this PR? Update qos case for SPC6 - How did you do it? Adjust the test for SPC6 accordingly - How did you verify/test it? Run the qos sai tests on SPC6 - Any platform specific information? SPC6 Signed-off-by: jbao <jbao@nvidia.com>
Summary: The predicted FLR regex rejects valid device output like '3.38e+00 (nan%)' because it only accepts digit percentages. When FLR is saturated (>1), hardware reports accuracy as 'nan' since it's meaningless. Update regex to accept both numeric and 'nan' accuracy values. Signed-off-by: sourabh kumar <kumarsourabh@microsoft.com>
Check APPL_DB for the DPU NEIGH_TABLE neighbor entries. Signed-off-by: dypet <dypeters@cisco.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Fixes # (issue) Fixed test_qos_dscp_mapping which was failing due to two issues: loganalyzer false positives during warm-reboot, and a memory utilization alarm triggered by expected post-reboot memory spikes. ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 ### Approach #### What is the motivation for this PR? `test_qos_dscp_mapping` was failing due to two issues: loganalyzer false positives during warm-reboot, and a memory utilization alarm triggered by expected post-reboot memory spikes. #### How did you do it? - Added `ignore_loganalyzer=loganalyzer` to the `reboot()` call so benign warm-reboot syslog messages are suppressed. - Added `pytest.mark.disable_memory_utilization` since the warm-reboot causes an expected transient memory spike that exceeds the 10% threshold. #### How did you verify/test it? Ran `test_qos_dscp_mapping.py` on `t0` topology (Cisco-8000). Uniform mode passed, pipe mode correctly skipped due to platform limitation. No errors in teardown. #### Any platform specific information? Tested on Cisco-8000 series. #### Supported testbed topology if it's a new test case? N/A — existing test, no topology changes. ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> #### Test Run [test_run_qos.log](https://github.com/user-attachments/files/26905250/test_run_qos.log) Signed-off-by: Nanma Purushotam <gupurush@gmail.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR 1.Support topology t1-isolated-d32u1s2 2.Support run on sn5640 platform Summary: Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [x] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 - [ ] 202512 - [x] 202605 ### Approach #### What is the motivation for this PR? 1. Run stress acl test on topology t1-isolated-d32u1s2 2. Make sure when running it on SN5640, the PTF could validate packet received #### How did you do it? 1. Add the topology support for t1-isolated-d32u1s2 2. Increase the ptf packet validation timeout value #### How did you verify/test it? Run it locally #### Any platform specific information? #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> Signed-off-by: echuawu <chuanw@nvidia.com>
Summary: Update conditional test markers so lossy topologies exclude unsupported test modules and scripts. This PR updates the shared `lossyTopos` anchor with the applicable lossy topology list and applies it to the requested module-level and script-level skip rules. Signed-off-by: securely1g <securely1g@users.noreply.github.com> Co-authored-by: securely1g <securely1g@users.noreply.github.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR Skip the warm reboot test in test_static_route on dualtor setup Currently warm reboot is not supported on dualtor setup Summary: Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [x] New Test case - [x] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? The warm reboot test in test_static_route are failing on dualtor setup. #### How did you do it? Skip the warm reboot test in test_static_route on dualtor setup #### How did you verify/test it? Run it locally #### Any platform specific information? #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> Signed-off-by: echuawu <chuanw@nvidia.com>
…red by no_log (#25028) ### Description of PR Summary: Fix `multi_passwd_ssh` connection plugin so that the password-retry loop is not prematurely aborted when a task sets `no_log: true` under ansible-core 2.19+. Fixes # (no GitHub issue filed; reproduced on `master` while running `testbed-cli.sh add-topo`, which invokes `config_sonic_basedon_testbed.yml` → "Rotate the password" task). ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 ### Approach #### What is the motivation for this PR? Under ansible-core 2.19+, the default SSH password mechanism is `ssh_askpass`, and authentication failures surface as `AnsibleConnectionFailure` rather than `AnsibleAuthenticationFailure`. The plugin distinguishes auth failures from real connectivity issues by string-matching `"Permission denied"` in the exception message (see PERMISSION_DENIED_ERR_FLAG, introduced when adding 2.19 support). However, when the task sets `no_log: true` (e.g. the `Rotate the password` task in `ansible/config_sonic_basedon_testbed.yml`, which echoes a credential on the shell command line), Ansible **censors the underlying SSH stderr before this plugin sees it**. The exception message becomes something like: ``` Failed to connect to the host via ssh: <error censored due to no log> ``` `"Permission denied"` is no longer present, so the existing check classifies the failure as a real connectivity failure, re-raises immediately, and the retry loop never advances to the next entry in `ansible_altpasswords`. The task is reported as `UNREACHABLE`, and because `ignore_errors: true` does **not** suppress `UNREACHABLE` results, the playbook aborts — even though the *next* password in the list would have authenticated successfully. Concrete repro (an `n3000`-style DUT that recently had its password rotated, with the new password supplied via `ansible_altpasswords`): ``` TASK [Rotate the password] ***************************************** <DUT> rc=255, stdout and stderr censored due to no log fatal: [DUT]: UNREACHABLE! => { ... } ``` Removing `no_log: true` from the task makes the same run succeed, because the plain stderr does contain `"Permission denied"` and the retry loop then walks through the password list to the working one. The verbose log shows two `Permission denied` attempts followed by a third successful attempt. #### How did you do it? In `ansible/plugins/connection/multi_passwd_ssh.py`, expand the auth-failure detection in the `AnsibleConnectionFailure` handler to also treat the no-log censorship marker (`"censored due to no log"`) as a possible authentication failure. When the marker is present we genuinely cannot tell whether SSH failed for auth or for connectivity, so it's safer to keep iterating through the remaining passwords than to abort on the first attempt. If all passwords are exhausted, the original exception is still re-raised. Behaviour for **genuine** connectivity failures is unchanged: those carry markers like `"Connection timed out"` / `"No route to host"` and are still handled by the IPv6-fallback path further up in `wrapped()`. #### How did you verify/test it? - Re-ran `./testbed-cli.sh -t testbed.yaml -m veos -k ceos add-topo <tb> password.txt -vvv` against a DUT whose current password is the second entry in `ansible_altpasswords`, with `no_log: True` left in place on the `Rotate the password` task. With this patch the plugin now retries with the second password, the task succeeds, and the playbook continues. Without the patch the same setup fails with `UNREACHABLE`. - Re-ran the same flow with a deliberately unreachable host (host powered off / wrong IP). The connection still correctly fails through to the IPv6-fallback / unreachable path — no behaviour change. - `flake8 --max-line-length=120 ansible/plugins/connection/multi_passwd_ssh.py` — no new warnings introduced. (Two pre-existing E721 warnings on lines 149 and 171 are unrelated and unchanged.) #### Any platform specific information? No — the change is in an Ansible connection plugin and affects all platforms whose deploy/test flow uses tasks with `no_log: true` together with `ansible_altpasswords` under ansible-core 2.19+. #### Supported testbed topology if it's a new test case? N/A — not a test case. ### Documentation N/A — no doc/Wiki change required; behaviour matches the documented intent of the plugin (retry across all configured passwords on auth failure). Signed-off-by: Xin Wang <xiwang5@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
**Description of PR**
**Summary:**
On broadcom-dnx VOQ platforms (e.g. Q3D), `test_crm_neighbor` fails for
IPv4 because the CRM counter does not increment when the neighbor
address (2.2.2.2) is outside the interface's configured subnet
(10.0.0.0/31).
Investigation shows that the kernel accepts the neighbor entry and
orchagent programs it into SAI (`addNeighbor: Created neighbor` in
syslog, `SAI_OBJECT_TYPE_NEIGHBOR_ENTRY` create in sairedis). However,
on some vendor SAI implementations, CRM accounting does not count
out-of-subnet neighbor entries, so `crm_stats_ipv4_neighbor_used` never
increments and the test assertion fails.
The test already handles this for Cisco devices by adding the host IP
(2.2.2.1/8 or 2001::2/64) to the interface before adding the neighbor,
making the neighbor address in-subnet. This PR extends that logic to
broadcom-dnx platforms so CRM correctly tracks the entry.
Fixes persistent `test_crm_neighbor[IPv4]` failure on single-asic
broadcom-dnx VOQ switches.
**Type of change**
- Bug fix
**Approach**
*What is the motivation for this PR?*
`test_crm_neighbor` has been failing on single-asic broadcom-dnx VOQ
platforms with:
```
Failed: "crm_stats_ipv4_neighbor_used" counter was not incremented or
"crm_stats_ipv4_neighbor_available" counter was not decremented
```
Root cause: The test adds neighbor 2.2.2.2 on PortChannel101 which has
IP 10.0.0.0/31. Since 2.2.2.2 is outside the /31 subnet, the neighbor
gets programmed into SAI but the CRM counter does not account for it on
some vendor SAI implementations — the counter stays unchanged even
though the neighbor entry exists in hardware.
Note: This behavior is vendor-SAI-specific. Some broadcom-dnx SAI
implementations do correctly update CRM for out-of-subnet neighbors,
while others do not. Adding the host IP to make the neighbor in-subnet
ensures consistent CRM behavior across all broadcom-dnx vendor SAI
implementations.
*How did you do it?*
Extended the existing Cisco host-IP-add logic to also apply to
broadcom-dnx platforms:
```python
# Before (only Cisco):
if is_cisco_device(duthost):
asichost.config_ip_intf(crm_interface[0], host, "add")
# After (Cisco + broadcom-dnx):
needs_host_ip = is_cisco_device(duthost) or \
duthost.facts.get("platform_asic") == "broadcom-dnx"
if needs_host_ip:
asichost.config_ip_intf(crm_interface[0], host, "add")
```
Same change for the cleanup (remove) path. No other platforms are
affected.
*How did you verify/test it?*
Tested on a broadcom-dnx Q3D single-ASIC VOQ platform (`switch_type:
voq`):
| Test | Without fix | With fix |
|------|-------------|----------|
| test_crm_neighbor[IPv4] | FAILED — CRM counter not incremented |
PASSED |
| test_crm_neighbor[IPv6] | PASSED | PASSED |
Manual verification on the DUT confirmed:
- `ip neigh replace 2.2.2.2 ... dev PortChannel101` — neighbor appears
in kernel AND orchagent programs it into SAI
- CRM counter does NOT increment for the out-of-subnet neighbor
- After adding host IP (2.2.2.1/8), CRM counter correctly increments
*Any platform specific information?*
Affects broadcom-dnx platforms where vendor SAI does not update CRM
counters for out-of-subnet neighbors. Safe for all platforms — on SAI
implementations where CRM already works without the host IP, adding it
is a no-op since the neighbor was already being counted.
*Supported testbed topology if it's a new test case?*
N/A — bug fix for existing test supporting `any` and `t1-multi-asic`
topologies.
Signed-off-by: Yatish Koul <yatishkoul@microsoft.com>
…ed (#25311) Summary: Nokia TH6 (`x86_64-nokia_ixr7220_h6_128-r0`) SAI does not support `SAI_MIRROR_SESSION_ATTR_POLICER`. The `is_policer_supported()` function already excludes Arista 7060x6 for the same reason. This PR extends that logic to also exclude Nokia TH6 platforms. Fixes Nokia-ION/nokia-th6#12 Signed-off-by: Bing Wang <bingwang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Summary:
This test is covering the re-pairing test part of the HA testplan,
module 2.
Steps:
Configure HA with ENI objects on DUT-1-DPU0, DUT-2-DPU0
Start sending traffic
Select another DPU from DUT-2, remove DPU-2 out of the HA pair, and
re-pair DPU-1 with the new DPU selected.
Expectations:
DUT-1, DPU0 remains active, while new DPU on DUT-2 becomes the new
standby.
No traffic loss is observed
### Type of change
- [ ] Bug fix
- [ ] Testbed and Framework(new/improvement)
- [x] New Test case
- [ ] Skipped for non-supported platforms
- [ ] Test case improvement
### Back port request
- [ ] 202205
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [ ] 202505
- [x] 202511
### Approach
#### What is the motivation for this PR?
Need to implement the HA re-pairing test
#### How did you do it?
Add new tests: one for primary re-pairing and the other for standby
re-pairing
#### How did you verify/test it?
Run the tests on smartswitch Ha testbed, passing in DPUs as:
-H
MtFuji-dut01-dpu-0,MtFuji-dut02-dpu-0,MtFuji-dut01-dpu-1,MtFuji-dut02-dpu-1
```
-------------------------------------------------- generated xml file: /data/sonic-mgmt/tests/logs/ha/test_ha_repairing_dpu.xml --------------------------------------------------
INFO:root:Can not get Allure report URL. Please check logs
----------------------------------------------------------------------------- live log sessionfinish -----------------------------------------------------------------------------
INFO root:__init__.py:67 Can not get Allure report URL. Please check logs
================================================================= 2 passed, 1227 warnings in 2099.79s (0:34:59) ==================================================================
```
#### Any platform specific information?
Smartswitch
#### Supported testbed topology if it's a new test case?
HA topology
### Documentation
N/A
---------
Signed-off-by: Mihut Aronovici <aronovic@cisco.com>
Signed-off-by: dypet <dypeters@cisco.com>
Co-authored-by: dypet <dypeters@cisco.com>
- conftest: route csonic to CsonicHost (the substring guard 'sonic' in neighbor_type was capturing csonic into the SSH SonicHost branch). - TestbedProcessing: add csonic to generated supported_vm_types. - testbed-cli.sh: treat csonic like ceos for the VM-less start/stop[-topo]-vms subcommands; propagate vm_type to renumber/connect/disconnect flows. - csonic bring-up: replace fixed sleeps with bounded CONFIG_DB-ready and front-panel-interface readiness waits; drop dead FRR/zebra/daemons/vtysh rendering (cSONiC FRR is generated by bgpcfgd from CONFIG_DB) and remove the unused fp_num/bp_ifname netbase port counting. - add_csonic: replace EOL debian:jessie net-base image with a configurable csonic_netbase_image (default debian:bookworm-slim, pull-if-missing). Signed-off-by: BYGX-wcr <wcr@live.cn>
These generic helpers are commonly called on neighbor hosts across the test suites; implement them on CsonicHost (via docker exec) for parity with EosHost/SonicHost. Signed-off-by: BYGX-wcr <wcr@live.cn>
- csonic_config.yml: select CONFIG_DB template via first_found fallback
(configdb-{topo}-{swrole}.j2 -> configdb-{swrole}.j2 -> configdb-csonic.j2)
so T1/T2/dualtor neighbor roles render without a bespoke per-role file.
- Add generic role-aware configdb-csonic.j2 (maps props.swrole to
DEVICE_METADATA type: leaf->LeafRouter, spine->SpineRouter, tor->ToRRouter).
- CsonicHost.fetch(): copy files out of the container via docker cp (and
scp for remote VM hosts) so collect_techsupport_all_nbrs works for csonic.
- Treat csonic like sonic (FRR/vtysh CLI) in inline neighbor-type gating:
bgp/test_prefix_list, test_bgp_router_id, test_ipv6_nlri_over_ipv4,
test_bgp_authentication, ospf/conftest, pc/test_retry_count.
- docs: document the required neighbor image features (bgpcfgd + lldpd via
_INCLUDE_DOCKER) and the role-aware template fallback.
Signed-off-by: BYGX-wcr <wcr@live.cn>
cSONiC neighbors share the host kernel; SONiC LACP PortChannels need the kernel 'team' module loadable on the host. Document how to verify/load it and the two common failure modes (module absent; Secure Boot rejecting an unsigned module), plus the observable symptom (teammgrd 'Operation not supported', PortChannel never forms, BGP stuck Active while FRR/LLDP are otherwise healthy). Signed-off-by: BYGX-wcr <wcr@live.cn>
… steps Provide the concrete procedure to (1) build the team driver out-of-tree against the installed kernel headers when a cloud kernel omits it, and (2) sign it with a MOK and enroll the key under Secure Boot. Documents the unavoidable single reboot needed to enroll the MOK / disable Secure Boot. Signed-off-by: BYGX-wcr <wcr@live.cn>
Document that the cSONiC neighbor image automatically realizes PortChannels with the in-tree Linux bonding driver in 802.3ad (LACP) mode when the host kernel 'team' module is unavailable, so PortChannel/LACP topologies work with no host changes, module signing, or reboot. The previous 'team module is required' framing is demoted to an optional path for running stock teamd. Signed-off-by: BYGX-wcr <wcr@live.cn>
cSONiC neighbors previously created only one front-panel veth per
container (hardcoded index 0) with the backplane on eth2/Ethernet2, so
multi-link LAG neighbors (T1-LAG/T2) failed at the vm_topology bind step
("could not open network device VMxxxx-t1").
Create one front-panel interface per topology vlan and move the backplane
past the last front-panel port:
- csonic_network.py: loop over num_fp_links to create FP veths eth1..ethK
(-> Ethernet1..EthernetK via lanemap), backplane on eth{K+1}. New
num_fp_links module arg (defaults to 1, identical to prior single-link
behavior).
- add_csonic.yml: pass num_fp_links = topology.VMs[vm].vlans | length.
- configdb-csonic.j2: render the backplane PORT/INTERFACE on Ethernet{K+1}
(K = number of front-panel Ethernet interfaces) instead of a hardcoded
Ethernet2, computing its lanes accordingly. Single-link neighbors still
resolve to Ethernet2 (no change).
- csonic.yml: bring up the backplane veth eth{K+1} instead of a hardcoded
eth2.
Validated on a live KVM T1-LAG csonic testbed: 8 PortChannels LACP(A)(Up)
with both members Selected, BGP 24/24 Established, LLDP 32. The 802.3ad
bonding fallback aggregates both members (single Aggregator ID, partner
MAC learned). Single-link T0/T1 behavior is unchanged.
Signed-off-by: BYGX-wcr <wcr@live.cn>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Fix test_ha_dpu_process_crash.py for NPU-driven HA Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [x] 202605 ### Approach #### What is the motivation for this PR? `test_ha_dpu_process_crash.py` assumed HA was always DPU-owned and asserted a fixed `"active"` state from the DPU-acked STATE_DB field. On NPU-driven (`ha_owner != "dpu"`) setups the expected post-crash and verification states differ (`HA_STATE_STANDBY` / `HA_STATE_STANDALONE`), so the test reported false failures. The state also needs to be read from `local_ha_state` rather than the DPU-acked field in this case. #### How did you do it? - `tests/ha/ha_utils.py`: Added an `ack` parameter to `verify_ha_state` so the caller can choose which STATE_DB field to query — `local_acked_asic_ha_state` (ack=True, default) or `local_ha_state` (ack=False). - `tests/ha/test_ha_dpu_process_crash.py`: - Added an autouse `_setup` fixture that derives the expected post-crash and verify states from the `ha_owner` fixture (`"active"` for DPU-owned, otherwise `HA_STATE_STANDBY` / `HA_STATE_STANDALONE`). - Replaced the hard-coded `"active"` expectations across all four crash scenarios with the owner-derived values. - Set `ack=False` in `verify_ha_state_converged` to read `local_ha_state`. - Added `orchagent`/`swss` to `DPU_CRITICAL_PROCESSES` to extend crash coverage. #### How did you verify/test it? Ran `test_ha_dpu_process_crash.py` on a SmartSwitch HA testbed for NPU-driven HA configurations, covering the syncd, bgp, and swss critical processes. #### Any platform specific information? SmartSwitch / DPU platforms with DASH HA enabled. #### Supported testbed topology if it's a new test case? N/A (existing SmartSwitch HA test). ### Documentation N/A Signed-off-by: BYGX-wcr <wcr@live.cn>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Fix test_ha_npu_reboot.py for NPU-driven HA by using generic flow comparison function. Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 ### Approach #### What is the motivation for this PR? The current test_ha_npu_reboot test case only works for AMD DPU. We need to make it generic. #### How did you do it? Use platfrom-agnostic flow comparison function #### How did you verify/test it? #### Any platform specific information? #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> Signed-off-by: BYGX-wcr <wcr@live.cn>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Fixes #25222 ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 ### Approach #### What is the motivation for this PR? After #24416, `dut_asn` is replaced by `confed_asn`, however, vtysh/FRR commands need the original `dut_asn`. Maintain the `dut_asn` and use those in appropriate commands. P.S. This is a fix on top of #24416 which is still open, so blocked by that #### How did you do it? Make a copy of `dut_asn` and use that for vtysh commands on duthost. #### How did you verify/test it? Test on top of #24416 changes #### Any platform specific information? Confed ASN topologies #### Supported testbed topology if it's a new test case? N/A ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> Signed-off-by: Javier-Tan <47554099+Javier-Tan@users.noreply.github.com>
…tability fixes (#23725) <!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> This pull request implements test improvements and stability fixes by updating configuration reload behavior, disabling vtysh in BGP update tests (bgp confed), and refining various test conditions. Summary: Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 ### Approach #### What is the motivation for this PR? This PR is to improve test infra to support BGP confederation on LT2/FT2/UT2. #### How did you do it? By making changes to the test files #### How did you verify/test it? By running in msft lab #### Any platform specific information? #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> --------- Signed-off-by: Yatish Koul <yatishkoul@microsoft.com>
## Summary Fixes cSONiC validation issue securely1g/csonic-validation#2 by treating `CsonicHost` like `SonicHost` in `bgp/test_bgp_route_neigh_learning.py`. The test already has SONiC-compatible commands for adding/removing the Loopback1 route and BGP network. cSONiC neighbors expose the same `shell()` interface and run SONiC/FRR inside the container, but `CsonicHost` does not subclass `SonicHost`, so the old type check fell through to `ValueError("Unsupported neighbor type")`. This updates both the setup path and cleanup path to use the SONiC command path for `CsonicHost`. ## Validation Local/static: - `python3 -m py_compile tests/bgp/test_bgp_route_neigh_learning.py` - `git diff --check` Focused local cSONiC pytest was not run yet because the local KVM/cSONiC testbed is not currently deployed: no running `sonic-mgmt`/cSONiC containers or `virsh` domains were present, and the required `/data/sonic-buildimage/target/docker-sonic-vs.gz` and `target/sonic-vs.img.gz` artifacts were absent. Planned focused validation once the testbed is available: ```bash cd /data/sonic-mgmt/tests pytest bgp/test_bgp_route_neigh_learning.py \ --neighbor_type csonic \ --inventory ../ansible/veos_vtb \ --host-pattern vlab-01 \ --module-path ../ansible/library \ --testbed vms-kvm-t0-csonic \ --testbed_file ../ansible/vtestbed.yaml ``` Fixes securely1g/csonic-validation#2 --------- Signed-off-by: securely1g <securely1g@gmail.com> Signed-off-by: securely1g <securely1g@users.noreply.github.com> Co-authored-by: securely1g <securely1g@users.noreply.github.com>
…2.21 (#25482) ### Description of PR Summary: Fix KeyError: 'failed' in AnsibleHostBase._run caused by ansible-core >= 2.21 changing how task results are post-processed. ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] 202505 - [x] 202511 - [x] 202605 ### Approach #### What is the motivation for this PR? The existing _IGNORE hack in base.py prevents ansible from stripping 'failed' from task results. This hack no longer works in **ansible-core >= 2.21**, which changed post-processing so that 'failed' is absent from successful command results. Multiple test modules hit KeyError: 'failed' when they access c['failed'] after a successful self.shell() or self.command() call, observed when running with the latest sonic-mgmt docker: | Module | Location | |---|---| | tacacs | common/helpers/tacacs/tacacs_helper.py:366 — if nss_config_attribute['failed']: | | dualtor_io | common/dualtor/dual_tor_io.py:591 — if not output['failed']: | | bgp | bgp/route_checker.py:121 — if res['failed'] and cmd_backup != "": | | macsec | macsec/test_dataplane.py:117 — ...["failed"] | #### How did you do it? Normalize hostname_res in _run() to always include 'failed' (based on hostname_res.is_failed) before returning. This is a **single-point fix** that covers all call sites without requiring per-file changes. `python if 'failed' not in hostname_res: hostname_res['failed'] = hostname_res.is_failed ` This approach is backward-compatible — it has no effect when ansible-core already includes 'failed' in the result. #### How did you verify/test it? - Pre-commit checks passed locally - Observed failures in ADO build [1142845](https://dev.azure.com/mssonic/build/_build/results?buildId=1142845) are all caused by this root issue - The fix aligns with the original intent of the _IGNORE hack — ensuring callers always have access to c['failed'] #### Any platform specific information? N/A — this is a framework-level fix affecting all platforms. #### Supported testbed topology if it's a new test case? N/A ### Documentation N/A Signed-off-by: xwjiang-ms <xiaweijiang@microsoft.com>
…ate (#25536) ### Description of PR Summary: Add two new pipeline parameters, `MGMT_BRANCH` and `KVM_IMAGE_BRANCH`, to `.azure-pipelines/pr_test_template.yml` and use them in place of the hardcoded `$(BUILD_BRANCH)` value across all test jobs. Both parameters default to `$(BUILD_BRANCH)`, so the existing behavior is unchanged when callers do not pass them. Templates that consume `pr_test_template.yml` can now override the sonic-mgmt branch and the KVM image branch independently (for example, to run a PR's tests against a different mgmt branch or KVM image branch). Fixes # (issue) ### Type of change - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 ### Approach #### What is the motivation for this PR? The `KVM_IMAGE_BRANCH` and `MGMT_BRANCH` values were hardcoded to `$(BUILD_BRANCH)` in every job of `pr_test_template.yml`, so there was no way for a caller to point the test run at a different sonic-mgmt branch or KVM image branch. Parameterizing these allows callers to override the branches when needed. #### How did you do it? - Added two new template parameters with defaults preserving current behavior: - `MGMT_BRANCH` (default `$(BUILD_BRANCH)`) - `KVM_IMAGE_BRANCH` (default `$(BUILD_BRANCH)`) - Replaced every hardcoded `KVM_IMAGE_BRANCH: $(BUILD_BRANCH)` and `MGMT_BRANCH: $(BUILD_BRANCH)` with `${{ parameters.KVM_IMAGE_BRANCH }}` and `${{ parameters.MGMT_BRANCH }}` across all jobs in the template. #### How did you verify/test it? Validated the YAML template parameter expansion through the Azure Pipelines PR test runs. With no parameters passed, the jobs resolve to `$(BUILD_BRANCH)` (identical to previous behavior); when overridden, the jobs pick up the provided branch values. #### Any platform specific information? No. This is a CI/pipeline template change only; no platform-specific code is affected. #### Supported testbed topology if it's a new test case? N/A — not a new test case. ### Documentation No documentation changes required. Signed-off-by: Yijing Yan <yijingyan@microsoft.com>
…rdown (#25488) ### Description of PR Summary: Fix the flaky `pc/test_retry_count.py::TestDutRetryCount::test_kill_team_peer_lag_up` test. The test verifies LAG retry count behavior (that LAG stays up for 150s after killing teamd). The test body **passes** — the functional behavior is correct. However, the test fails intermittently on **teardown** because LogAnalyzer catches transient syslog errors that occur during `config_reload` in the `config_reload_on_cleanup` fixture. Transient errors during config_reload include: - `ERR teamd#teamsyncd: Failed to initialize team handler for LAG ... Unable to initialize team socket` - `ERR memory_checker: cgroup memory usage file ... does not exist` - `ERR swss#orchagent: removeLag: Failed to remove ref count` These are **expected** during container restart — the system retries and recovers automatically. The `config_reload_on_cleanup` fixture was not telling LogAnalyzer to expect these transient errors, so LogAnalyzer was failing the test. Fixes the intermittent failure observed in Elastictest test plans including: - `6a338e53d2130994bb47b365` (https://elastictest.org/scheduler/testplan/6a338e53d2130994bb47b365) ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [x] 202605 ### Approach #### What is the motivation for this PR? `test_kill_team_peer_lag_up` is a flaky test. Over the last 14 days: 71 errors / 39 distinct PRs. The dominant error signatures are: - `teamsyncd: Failed to initialize team handler` (68 occurrences, 96%) - `memory_checker: cgroup memory usage file does not exist` (3 occurrences, 4%) Both occur during `config_reload` in the teardown fixture and are transient/self-healing. #### How did you do it? Added `loganalyzer` as a fixture dependency to `config_reload_on_cleanup` and passed `ignore_loganalyzer=loganalyzer` to the `config_reload()` call. This tells LogAnalyzer to add start/end ignore markers around the reload operation, so transient errors during reload are not captured. This is the canonical pattern used by 8+ other tests in sonic-mgmt that perform config_reload: - `tests/route/test_route_perf.py` - `tests/pc/test_lag_member_forwarding.py` - `tests/drop_packets/drop_packets.py` - `tests/wan/lacp/test_wan_lag_min_link.py` - `tests/bgp/test_bgp_suppress_fib.py` - etc. #### How did you verify/test it? 1. **Confirmed transient errors occur during config_reload** on dev-VM (vlab-03, t1-lag): ``` === ERR messages during config_reload === 2026 Jun 19 07:12:30 vlab-03 ERR swss#orchagent: :- removeLag: Failed to remove ref count 3 LAG PortChannel102 2026 Jun 19 07:12:30 vlab-03 ERR swss#orchagent: :- removeLag: Failed to remove ref count 3 LAG PortChannel105 ... (30+ transient ERR lines during reload) ``` 2. **Verified the fix follows the canonical pattern** used by other tests. 3. Syntax and lint verified: `py_compile` and `flake8 --max-line-length=120` clean. #### Any platform specific information? None #### Supported testbed topology if it's a new test case? N/A ### Documentation N/A Signed-off-by: sakshamkhurana <sakkhurana@microsoft.com>
…25467) Summary: Move the `ensure_all_dpus_ready` teardown fixture (previously `ensure_dpus_up_after_test` in `test_reload_dpu.py`) into a new `tests/smartswitch/platform_tests/conftest.py` so it is automatically applied to all tests in the `platform_tests` directory. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Add a new unplanned test case that emulates the scenario where the data-plane interface of DPU goes down. Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [x] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 ### 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 <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> Signed-off-by: BYGX-wcr <wcr@live.cn>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: The expected states for a pair of DASH DPUs are different in NPU-driven HA mode versus DPU-driven HA mode. Adapt the test for NPU-driven HA. Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [x] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [x] 202605 ### 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 <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> --------- Signed-off-by: BYGX-wcr <wcr@live.cn>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Replace the platform-specific flow comparison code and modify traffic loss threshold in test_ha_bgp_down.py. Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [x] 202605 ### 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 <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? -->
Parallelize HA DPU config reload cleanup so multiple DPUs are restored concurrently after HA tests instead of sequentially. Signed-off-by: Jing Zhang <zhangjing@microsoft.com>
…on T2 (#25498) What: Adds wait_for_frr_ready() and rewrites restart_bgp_container() in tests/bgp/test_prefix_list_suppress.py to gate on per-ASIC FRR VTY-socket readiness instead of only bgpcfgd RUNNING. Why: On T2 KVM (multi-ASIC, slow I/O, large FRR config), vtysh blocks indefinitely for 6-7 min after a BGP container restart since FRR daemons have not opened their VTY socket yet, causing 100% (139/139) module timeouts over 30 days. How: Restart all BGP services in parallel, then per ASIC verify bgpcfgd RUNNING followed by 'timeout 10 vtysh -c "show version"' polled via wait_until(480,15,0,...), which adapts to system speed and avoids indefinite blocking. Testing: CI all green (Azure sonic-mgmt + all Elastictest KVM lanes t0/t1-lag/t2/multi-asic, DCO, CodeQL, Semgrep). Kusto baseline + console-log analysis across multiple testplans confirmed the vtysh hang pattern; fast systems pass in <30s with no penalty. Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com>
Approach What is the motivation for this PR? Make test_vxlan_decap_ttl pass on dualtor by ensuring the VxLAN packet is both delivered to and L3-terminated (decapsulated) by the ToR the test actually configures. How did you do it? Pin the configured (upper) ToR active for the mux ports via the setup_dualtor_mux_ports markers: dualtor_active_standby_toggle_to_upper_tor; dualtor_active_active_setup_standby_on_lower_tor. Both pin the upper ToR (duthosts[0]) active, matching the duthost fixture the test configures. The markers are no-ops on non-dualtor topologies. Add get_dest_mac() to select the outer VxLAN packet's destination MAC: the VLAN SVI MAC when the ingress port is a VLAN member on t0/dualtor, otherwise the global router MAC (preserving t1 behavior). The inner frame's destination MAC stays the router MAC, which is the configured vxlan_router_mac. How did you verify/test it? vxlan/test_vxlan_decap_ttl.py::test_vxlan_decap_ttl[v4-v4] ✓ 25% ██▌ vxlan/test_vxlan_decap_ttl.py::test_vxlan_decap_ttl[v4-v6] ✓ 50% █████ vxlan/test_vxlan_decap_ttl.py::test_vxlan_decap_ttl[v6-v6] ✓ 75% ███████▌ vxlan/test_vxlan_decap_ttl.py::test_vxlan_decap_ttl[v6-v4] ✓ 100% Any platform specific information? The test already runs only on supported ASICs. Supported testbed topology if it's a new test case? N/A (existing test). Restores correct behavior on dualtor / dualtor-aa.
Approach What is the motivation for this PR? Make test_vnet_decap pass on dualtor by ensuring the upstream test packet is both delivered to and L3-terminated (decapsulated) by the ToR the test actually configures. How did you do it? Pin the randomly selected ToR active for the mux ports via the setup_dualtor_mux_ports markers (the modern, non-deprecated mechanism; the autouse fixture in tests/conftest.py reads these markers and drives the correct simulator for each cable type): dualtor_active_standby_toggle_to_random_tor toggles the selected ToR active for active-standby; dualtor_active_active_setup_standby_on_random_unselected_tor sets the unselected ToR standby (i.e. the selected ToR active) for active-active. Add get_dest_mac() to choose the correct decap destination MAC: the VLAN SVI MAC when the chosen ingress port is a VLAN member on dualtor, otherwise the global router MAC (preserving existing t1 behavior). find_ptf_dest_port() now also returns the selected interface name so its VLAN membership can be checked, and the ingress IP-in-IP packet is built with this MAC. The expected egress VXLAN packet still uses the router MAC. The markers are no-ops on non-dualtor topologies and get_dest_mac() falls back to the router MAC. Assisted-by: Stuart 🍌 (Hermes Agent, model claude-opus-4.8) Signed-off-by: Longxiang Lyu lolv@microsoft.com How did you verify/test it? 4700 dualtor vxlan/test_vnet_decap.py::test_vnet_decap[inner_ipv4-outer_ipv4] ✓ 25% ██▌ vxlan/test_vnet_decap.py::test_vnet_decap[inner_ipv4-outer_ipv6] ✓ 50% █████ vxlan/test_vnet_decap.py::test_vnet_decap[inner_ipv6-outer_ipv6] ✓ 75% ███████▌ vxlan/test_vnet_decap.py::test_vnet_decap[inner_ipv6-outer_ipv4] ✓ 100% ██████████ Any platform specific information? The test already runs only on Cisco-8000 and Mellanox ASICs (existing skip). Supported testbed topology if it's a new test case? N/A (existing test). Restores correct behavior on dualtor / dualtor-aa.
The PL sip values have only some assigned ranges which are allowed for the ENI, for the SIP encoding and for the IP, so the IP addresses are modified to align with those changes - What is the motivation for this PR? As per the requirement for the PL SIP encoding values, the values of the PL_OVERLAY_SIP and PL_ENCODING_IP are modified for alignment - How did you do it? Modify the variables as required Signed-off-by: gpunathilell <gpunathilell@nvidia.com>
### Description of PR Summary: Add a conditional xfail for `generic_config_updater/test_bgp_prefix.py::test_bgp_prefix_tc1_suite` while the known 202605 BGP allowed-prefix GCU failure is tracked. Kusto data shows the case fails across multiple platforms/HWSKUs. Related issue: #25549 ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [x] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202605 - [ ] 202511 ### Approach #### What is the motivation for this PR? Kusto query over the last 30 days shows `generic_config_updater.test_bgp_prefix.test_bgp_prefix_tc1_suite` failing on 202605 across multiple platforms/topologies The failures include both parametrizations: ```text generic_config_updater.test_bgp_prefix.test_bgp_prefix_tc1_suite[None-empty] generic_config_updater.test_bgp_prefix.test_bgp_prefix_tc1_suite[None-1010:1010] ``` The issue is tracked in #25549. #### How did you do it? Added a conditional xfail in `tests/common/plugins/conditional_mark/tests_mark_conditions.yaml` for the whole `test_bgp_prefix_tc1_suite`, tied to #25549 so the mark remains active while the issue is open. #### How did you verify/test it? - Updated GitHub issue #25549 with the broader all-platform scope. - Parsed `tests_mark_conditions.yaml` with PyYAML successfully. - Verified the issue-gated condition is converted to `True` while the issue is open. - Ran `git diff --check` successfully. Note: full conditional-mark unittest cannot run in this native Windows environment because the test package imports `fcntl`. #### Any platform specific information? #### Supported testbed topology if it's a new test case? N/A - no new test case. ### Documentation N/A --------- Signed-off-by: Storm Liang <stormliang@microsoft.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? Several BGP tests assumed the DUT's peer ASN is always the dut_asn, which breaks on confederation-based topologies where neighbors peer using the confederation ASN or sub ASN. This fixes those tests to pick the right ASN when based on the neighbor #### How did you do it? In affected BGP tests, check the peer_in_bgp_confed flag from the topo config. If set, use the confederation ASN from get_bgp_confed_asn() instead of dut_asn when looking up peer IPs. Added a get_bgp_confed_peer_asn() helper to MultiAsicSonicHost for fetching confederation peer ASNs from running config. #### How did you verify/test it? Ran the affected BGP tests on a confederation-based UT2 topology and confirmed sessions establish and tests pass #### Any platform specific information? #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> --------- Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…25573) ### Description of PR Summary: Adjust Broadcom ECN kmax threshold with 500-cell distance from kmin Fixes: #25004 This PR improves the ECN dequeue test for Broadcom Trident 3 platforms by setting the kmax threshold to create a precise 500-cell gap from kmin. This aligns with cell-based queue accounting where: - Trident 3 uses 256-byte cells - Test packets are 1024 bytes (4 cells each) - A 500-cell gap provides adequate hysteresis between marking and non-marking regions **Previous values:** - kmin: 50,000 bytes (default) - kmax: 51,000 bytes (default, only 1,000 byte gap) **New values for Broadcom:** - kmin: 40,000 bytes (~156 cells) - kmax: 168,000 bytes (~656 cells) - Gap: 128,000 bytes (500 cells) This change makes the ECN dequeue test more reliable on Broadcom hardware by ensuring packets sent during the test properly transition from marked (when queue above kmax) to unmarked (when queue below kmin). ### Type of change - [x] Bug fix - [ ] Test case improvement ### Back port request - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [x] 202511 - [ ] 202512 - [ ] 202605 ### Approach #### What is the motivation for this PR? The ECN test was using the same threshold parameters for all ASIC types, but Broadcom Trident 3 devices have different queue depth behavior and cell-based accounting. The original 1,000-byte gap (50-51KB) was insufficient, leading to flaky test results on Broadcom platforms. #### How did you do it? Calculated ECN thresholds based on Trident 3 hardware characteristics: 1. Identified cell size: 256 bytes (TD3 default) 2. Computed cells per packet: ceil(1024 / 256) = 4 cells 3. Selected target gap: 500 cells (conservative margin for timing jitter) 4. Calculated thresholds: - Gap in bytes: 500 × 256 = 128,000 bytes - kmin: 40,000 bytes - kmax: kmin + gap = 40,000 + 128,000 = 168,000 bytes 5. Updated packet count to 301 (increased from 101 for non-Broadcom) to ensure sufficient packets for ECN marking verification #### How did you verify/test it? - Verified 256-byte cell size for Trident 3 in existing SONiC codebase ([tests/qos/test_tunnel_qos_remap.py](tests/qos/test_tunnel_qos_remap.py)) - Confirmed threshold gap calculation: (168,000 - 40,000) / 256 = 500 cells exactly - Change is isolated to Broadcom platform via ASIC type check in test #### Any platform specific information? - **Broadcom Trident 3**: 256-byte cells, updated thresholds in ECN_PARAMS_BY_ASIC['broadcom'] - **Other ASICs**: Unchanged; continue using default parameters (50KB kmin, 51KB kmax) - Tested on: Arista 7050CX3 (Broadcom Trident 3) #### Supported testbed topology if it's a new test case? N/A - This is an improvement to existing `test_dequeue_ecn` test which supports multidut-tgen topology. ### Documentation The min (104,000 bytes) and max (208,000 bytes) thresholds in the standard line-rate profile are derived by mapping SONiC byte configurations to the 208-byte cell constraints of the Broadcom Trident ASIC. These values ensure a 500-cell slope for optimal WRED/ECN operation. ``` ~$ show ecn Profile: AZURE_LOSSLESS ----------------------- ------- ecn ecn_all green_drop_probability 5 green_max_threshold 2097152 green_min_threshold 1048576 red_drop_probability 5 red_max_threshold 2097152 red_min_threshold 1048576 wred_green_enable true wred_red_enable true wred_yellow_enable true yellow_drop_probability 5 yellow_max_threshold 2097152 yellow_min_threshold 1048576 ----------------------- ------ ``` Signed-off-by: Edi Wibowo <ediwibowo@microsoft.com>
- What is the motivation for this PR? fix test failure - How did you do it? add skip condition - How did you verify/test it? Any platform specific information? mellanox, spc1-spc3 Signed-off-by: Wenjun Wang <wenjwang@nvidia.com>
Summary: Skip test_show_platform_fan on BMC Fixes # Add `"'bmc' in topo_type"` skip condition `platform_tests/cli/test_show_platform.py::test_show_platform_fan`. BMC platforms do not support the fan platform API - What is the motivation for this PR? BMC platforms do not support the fan platform API, need skip related case on BMC - How did you do it? Add "'bmc' in topo_type" skip condition platform_tests/cli/test_show_platform.py::test_show_platform_fan. BMC platforms do not support the fan platform API - How did you verify/test it? Run regression pass - Any platform specific information? BMC Signed-off-by: weiguo-nvidia <weguo@nvidia.com>
…6 VXLAN tunnels are not supported on Spectrum-1 (#25089) Skip test cases test_vxlan_decap_ttl for IPv6, because IPv6 VXLAN tunnels are not supported on Mellanox Spectrum-1 Signed-off-by: Yanpeng Zhang <yanpengz@nvidia.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Summary: Fixes # (issue) Added new test cases to validate the vendor addon docker installation ### Type of change New testcase <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [x] New Test case - [x] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? New addon vendor docker required to launch addon services on production router. #### How did you do it? Added new test cases to: 1. Validate docker installtion, bringup and health validation. 2. Vaidated docker health across config reloads. #### How did you verify/test it? Run test case in sonic-mgmt #### Any platform specific information? Enabled for cisco-8000 platforms. #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> --------- Signed-off-by: Anand Mehra (anamehra) <anamehra@cisco.com>
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR <!-- - Please include a summary of the change and which issue is fixed. - Please also include relevant motivation and context. Where should reviewer start? background context? - List any dependencies that are required for this change. --> Parameterize gNMI CONFIG DB tests with different VRFs to ensure correct VRF binding of gNMI listener Summary: Fixes sonic-net/sonic-gnmi#504 Depends on: - sonic-net/sonic-gnmi#503 - sonic-net/sonic-buildimage#23867 - sonic-net/sonic-utilities#4395 ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [x] New Test case - [x] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 ### Approach #### What is the motivation for this PR? To test the changes in sonic-net/sonic-gnmi#503 and sonic-net/sonic-buildimage#23867 #### How did you do it? Parameterized `test_gnmi_configdb.py` with `default`, `mgmt_vrf` and a custom VRF scenario. #### How did you verify/test it? Manual verification of relevant changes are already done with the `sonic-buildimage` changes. The updated tests ran successfully in local setup. #### Any platform specific information? NA #### Supported testbed topology if it's a new test case? Any testbed works for the default and `mvrf` test cases. Custom non-mgmt VRF testcase requires a `t0` topology for now, but it is not a realistic case anyway since the gNMI request is shoved through a dataplane VRF. ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? --> NA #### A picture of a cute animal (not mandatory but encouraged)  Signed-off-by: Spandan Chowdhury <spandan@nexthop.ai>
…let to avoid rebooting the DUT (#25317) Summary: `test_turn_on_off_psu_and_check_psustatus` powers off each PSU's PDU outlet to verify the PSU reports `NOT OK` while the DUT stays up on its remaining PSU(s). When the PDU connection graph maps **every** PSU of a DUT to the **same** outlet, turning it off cuts all power and reboots the DUT — surfacing as a misleading `Timeout (62s) waiting for privilege escalation` failure plus a cascade of `container pmon is not running` errors in later platform tests (not real SONiC bugs). This PR adds a pre-toggle safety check requiring **≥2 distinct PDU outlets** across all PSUs. If all PSUs share one outlet, it logs a warning and skips (via `pytest_require`) **before** powering anything off. DUTs with independent per-PSU outlets are unaffected and run all existing assertions. > **Action required for testbed owners:** this is a PDU cabling/connection-graph issue, not a DUT/SONiC bug. Please cable each PSU to its **own independent** PDU outlet and update the corresponding `*_pdu_links.csv` (matching healthy peers in the same pod). Until fixed, the test will skip on these DUTs, and PSU on/off coverage will not run. Signed-off-by: Priyansh Tratiya <ptratiya@microsoft.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| def _safe(fn, *args, **kwargs): | ||
| """Run a teardown step, log and swallow any exception so later steps still run.""" | ||
| try: | ||
| return fn(*args, **kwargs) |
| '{}').format(file_location, file_name, url) | ||
| subprocess.run(uhdConf_cmd, shell=True, capture_output=True, text=True) | ||
| try: | ||
| res = subprocess.run(uhdConf_cmd, shell=True, capture_output=True, text=True) # noqa: F841 |
|
|
||
| connections_list = arp_bypass_list | ||
| num_cps_cards = cards_dict['num_cps_cards'] | ||
| first_cps_card, first_tcpbg_card = set_first_stateful_cards(cards_dict) |
|
|
||
| connections_list = arp_bypass_list | ||
| num_cps_cards = cards_dict['num_cps_cards'] | ||
| first_cps_card, first_tcpbg_card = set_first_stateful_cards(cards_dict) |
Comment on lines
+405
to
+408
| # if server_vlan <= 128: | ||
| # lb_ip = 1 | ||
| # else: | ||
| # lb_ip = 2 |
| return "active" | ||
|
|
||
|
|
||
| def _select_replacement_dpuhost(requested_dpuhosts, duthost_to_replace): |
Collaborator
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
Summary:
Fixes # (issue)
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