[packet_trimming] Skip symmetric SRv6 trimming on isolated topo for 202412 - #1
Open
sdszhang wants to merge 6201 commits into
Open
[packet_trimming] Skip symmetric SRv6 trimming on isolated topo for 202412#1sdszhang wants to merge 6201 commits into
sdszhang wants to merge 6201 commits into
Conversation
…isolated-v6 topologies (sonic-net#778) <!-- 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: New conditional mark rules specific to acl tests were added as a part of [PR18078](sonic-net#18078) to skip these tests on isolated-v6 topologies. This conflicted somewhat with [PR13668](sonic-net#13668) in that the first PR specified a more targeted rule. This resulted in several acl tests being run on isolated-v6 topologies despited the broad rule in PR18078. This change can be undone once [Issue18077](sonic-net#18077) is addressed. ### 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 - [x] 202505 ### Approach #### What is the motivation for this PR? This was found while triaging [Issue18077](sonic-net#18077), and was implemented in order to cut down on failed-test noise due to known issues. #### How did you do it? I modified the rule for acl/test_acl.py::TestAclWithReboot in tests/common/plugins/conditional_mark/tests_mark_conditions_acl.yaml such that its skip criteria includes isolated-v6 topologies. #### How did you verify/test it? I verified that acl/test_acl.py::TestAclWithReboot tests are now skipped on isolated-v6 testbeds, whereas they were not prior to this change.
…-net#780) <!-- 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 ### Approach #### What is the motivation for this PR? After ansible >= 2.14, custom modules are executed on the managed node (or in an execution environment container) that only contains the runtime bits Ansible intentionally ships there (mainly ansible.module_utils plus Python stdlib). Controller‑only internals like ansible.inventory.manager and ansible.parsing.dataloader are not present. So importing them on the remote side is fundamentally unsupported now. #### How did you do it? This change removed the code of importing ansible API in the testbed_vm_info.py customized module. Then this module can be executed in sonic-mgmt docker using ansible >= 2.14. #### How did you verify/test it? Tested on ansible 2.13.13 and 2.19.2 #### 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? -->
### Summary: Add packet trimming counter testcase phase1 ### Related PR - Add packet trimming drop counter test plan sonic-net#19824 - Packet Trimming: Drop Counters HLD sonic-net/SONiC#2033 - [trim]: Add Packet Trimming Drop Counters YANG model sonic-net/sonic-buildimage#23422 - [trim]: Add Packet Trimming Drop Counters DB schema sonic-net/sonic-swss-common#1055 - [trim]: Add Packet Trimming Drop Counters to VS lib sonic-net/sonic-sairedis#1630 - [trim]: Add Packet Trimming Drop Counters to OA sonic-net/sonic-swss#3777 - [trim]: Add Packet Trimming Drop Counters CLI sonic-net/sonic-utilities#3993 ### 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 - [x] 202505 ### 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? -->
Initialize lldpctl_interface in ansible/tests/lldp/test_lldpsyncd.py in order to prevent potential UnboundLocalError. <!-- 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) Fix potential UnboundLocalError in ansible/tests/lldp/test_lldp_syncd.py by initializing lldpctl_interface to None. The assertion this variable is passed to performs an existence check, and so will fail the testlet appropriately if lldpctl_interface is not set. ### 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 - [x] 202505 ### Approach #### What is the motivation for this PR? Enhance the debug-ability of ansible/tests/lldp/test_lldpsyncd.py such that in the even that no lldp interface is identified in the test, the error is propagated up to and reported by the verification method and does not simply throw UnboundLocalError. #### How did you do it? Fix is to initialize the variable lldpctl_interface to None outside of conditional logic so that it has a value when passed to the test verification method. #### How did you verify/test it? Verified that the same failing test case no longer throws UnboundLocalError and fails in a meaningful way for further debug.
…only (sonic-net#745) add --limited_ports flag to run it on a limited number of ports
…d bugs (sonic-net#20750) (sonic-net#722) Manual cherry-pick of sonic-net#20750 Added xfail to condition mark, for tests, which failed on IPv6 only topo. Related tests and their created issues: vxlan_route_adv - sonic-net#20725 test_vlan_tc3_send_invalid_vid - sonic-net#20726 vlan_interface_cases - sonic-net#20727 test_add_rack - sonic-net#20728 test_po_update - sonic-net#20729 test_route_bgp_ecmp - sonic-net#20730 nhop_group - sonic-net#20731 test_lag_member_remove_add - sonic-net#20733 test_lag_member_flap - sonic-net#20733 test_lag_hash - sonic-net#20733 test_ecmp_hash - sonic-net#20733 Signed-off-by: AntonHryshchuk <antonh@nvidia.com>
…g template (sonic-net#736) Manually cherry pick PR to 202412: Remove mgmt. gateway in ceos config template sonic-net#20650
…t_orchagent_reboot due to github issue 19658' (sonic-net#705) Manual cherry-pick of sonic-net#20091 'Xfail test_lldp_neighbor_post_orchagent_reboot due to github issue 19658'"
) What is the motivation for this PR? The docker-sonic-mgmt will be upgraded to Ubuntu 24.04 based. The python packages will be upgraded together. Due to breaking changes in the packages, the devutils and snmp pdu controller need to be fixed to address the compability issues. How did you do it? Major changes in this PR: Updated snmp_pdu_controllers.py to use pysnmp 7.1.21 APIs. Moved the current snmp_pdu_controllers.py based on pysnmp 4.x API to snmp_pdu_controllers_legacy.py. Updated the pdu_manager.py to import correct snmp pdu controller based on pysnmp versions. Other changes: Improve the import in ssh_utils.py to make it compatible with old and new paramiko package. Add code to show traceback in task_runner.py to help troubleshooting. Improve the import in ansible_fixture.py to be compatible with old and new pytest_ansible. All the changes are compatible with old and new docker-sonic-mgmt. How did you verify/test it? Tested devutils using old and new docker-sonic-mgmt Tested pytest collect using old and new docker-sonic-mgmt
…#791) <!-- 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 --> - [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 - [x] 202411 - [x] 202505 ### Approach #### What is the motivation for this PR? To enable proper ipv6-only topo test for test_vlan.py #### How did you do it? Added treatment for ipv6, so it's not just looking for ipv4. #### How did you verify/test it? Ran on ipv6-only topo testbed. <img width="2988" height="330" alt="image" src="https://github.com/user-attachments/assets/23f15f5a-c4c9-4059-93a2-0a383aea3807" /> #### 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? -->
<!-- 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 ipfwd assert assumption for Broadcom TH5 The test limits the number of nhops that is used for testing. However, the general assert assumes this limit does not exist and asserts with CRM to make sure nhops available after the test is 0. This causes issues on TH5 because the number of nhop groups supported is 4095, where the limit of the test is 1024. This means that the number of nhop groups after the test would not be 0 `(4095 - 1024 - (extra groups) >> 0)`. The Cisco-case of the test has the proper assert that adjusts for this test limit. Fixing the test by including Broadcom TH5 devices to use that proper assert. 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 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] msft-202412 - [x] 202505 ### Approach #### What is the motivation for this PR? ipfwd tests failing for Arista TH5 devices. #### How did you do it? Adjust the assert conditions for Arista TH5 devices. #### How did you verify/test it? Test no longer fails on Arista TH5 devices. #### Any platform specific information? Broadcom TH5 #### 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? -->
…mbers on Broadcom (sonic-net#793) <!-- 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) https://github.com/aristanetworks/sonic-qual.msft/issues/629 ### 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 - [x] 202412 - [x] 202505 ### Approach #### What is the motivation for this PR? The `drop_packets` tests were intermittently failing on certain Broadcom platforms. The root cause was identified as the test selecting interfaces where the FEC counters are not functional. #### How did you do it? Update the `rif_members` construction logic. The logic for populating `rif_members` was modified to check the `minigraph_neighbors` for each interface. If an interface's neighbor device name contains the string "PT0", it is excluded from the list of potential test interfaces. #### How did you verify/test it? Run the `drop_packets` test suite on an affected Broadcom platform and confirmed that the tests now consistently pass by avoiding the problematic interfaces. The test continues to function correctly on other platforms where this issue is not present. #### 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: zitingguo-ms <zitingguo@microsoft.com>
…v6 only topology (sonic-net#794) <!-- 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: skip not relevant test_show_ip_route_**v4** test on IPv6 only topology ### 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 ### Approach #### What is the motivation for this PR? Clear regression #### How did you do it? Skipped not relevant test for IPv6 only topology ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? -->
### Description of PR Adjust test_dip_sip.py to ipv6 only topology Modified get_lag_facts and get_ports_facts to support ipv6 only topo, and adjusted the cases to run with this topo. This PR is only for 202412 branch, because the following PR - sonic-net#17058 was not CP to this branch ### Type of change - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Approach #### What is the motivation for this PR? fix test to run as expected on ipv6 only topo #### How did you do it? selected the ipv6 ip option for lags and ports facts and only run ipv6 validation on the test itself. #### How did you verify/test it? internal nvidia regression
…al bug (sonic-net#797) <!-- 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 buffer profile name retrieval bug. Currently, the packet trimming config setup is hard-coded to retrieve the exact queue_id match from a list of buffer profiles which may not exist at all, resulting in this error: ``` Error computing buffer threshold for queue 1 on Ethernet120: 'pool' ``` This PR checks across all buffer profiles for that specific interface and matches on a queue range that fits. 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 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [X] 202505 ### Approach #### What is the motivation for this PR? Bug fix for packet trimming config setup that's hitting a lot of packet trimming tests. #### How did you do it? Allow closest match to buffer profile for the specific queue if the queue specific one doesn't exist. #### How did you verify/test it? Tested on lab device. #### 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? -->
Remove unused parameters in remove_topo.yml The parameters added in Azure/sonic-mgmt.msft#743 When previously removed in Azure/sonic-mgmt.msft#622 Without this change we have the next error: ```fatal: [*****]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'duts_midplane_ports' is undefined\n\nThe error appears to be in '...../sonic-mgmt/ansible/roles/vm_set/tasks/remove_topo.yml'``` Signed-off-by: AntonHryshchuk <antonh@nvidia.com>
…ion for everflow IPv6 erspan_ipv6-default test (sonic-net#806) <!-- 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 Mellanox ASIC skip condition to the exact match rule for test_everflow_per_interface[ipv6-erspan_ipv6-default] because exact match rules have higher priority than prefix match rules, causing the test to ignore the Mellanox skip condition in the prefix match configuration. 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 - [x] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [x] 202411 - [ ] 202505 ### Approach #### What is the motivation for this PR? Skip everflow per interface IPv6 test on Mellanox ASICs #### How did you do it? Add Mellanox ASIC skip condition to the exact match rule for test_everflow_per_interface[ipv6-erspan_ipv6-default] because exact match rules have higher priority than prefix match rules, causing the test to ignore the Mellanox skip condition in the prefix match configuration. #### How did you verify/test it? ``` ================================================== short test summary info =================================================== SKIPPED [1] everflow/test_everflow_per_interface.py: SAI_STATUS_NOT_SUPPORTED for everflow over IPv6 on Arista-7260CX3 and Arista-7060CX. Skip everflow per interface IPv6 test on unsupported platforms =============================================== 1 skipped, 1 warning in 54.18s =============================================== ``` #### Any platform specific information? str5-sn5640-2 #### Supported testbed topology if it's a new test case? t0-isolated-d32u32s2 ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? -->
…ic-net#20846) (sonic-net#789) Cherry pick sonic-net#20846 to 202412 branch of this repository. What is the motivation for this PR? The docker-sonic-mgmt will be upgraded to Ubuntu 24.04 based. The python packages will be upgraded together. Due to breaking changes in the packages, the devutils and snmp pdu controller need to be fixed to address the compability issues. How did you do it? Major changes in this PR: Updated snmp_pdu_controllers.py to use pysnmp 7.1.21 APIs. Moved the current snmp_pdu_controllers.py based on pysnmp 4.x API to snmp_pdu_controllers_legacy.py. Updated the pdu_manager.py to import correct snmp pdu controller based on pysnmp versions. Other changes: Improve the import in ssh_utils.py to make it compatible with old and new paramiko package. Add code to show traceback in task_runner.py to help troubleshooting. Improve the import in ansible_fixture.py to be compatible with old and new pytest_ansible. All the changes are compatible with old and new docker-sonic-mgmt. How did you verify/test it? Tested devutils using old and new docker-sonic-mgmt Tested pytest collect using old and new docker-sonic-mgmt
What is the motivation for this PR? Ansible 2.14+ enforces FQCN (with a few exceptions for “very core” filters like default, to_json, dictsort that are still built into Jinja2/Ansible). Directly using filters like ipaddr, ipv6 will fail with filter not found issue. How did you do it? This change fixed the issue by adding ansible.utils. to the ipaddr and ipv6 filters used in the templates. How did you verify/test it? Tested using ansible 2.13 and ansible 2.19.
sonic-net#815) <!-- 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: ipv6 topo-only skips are recently introduced to various test cases. Within those cases are various sub-cases of `fib/test_fib.py::test_nvgre_hash`. New skip entries are added for the specific sub-cases, which overrides the umbrella skip condition for fib/test_fib.py::test_nvgre_hash, causing the cases to be unintentionally unskipped. Fix by adding the needed skip conditions to the sub-case entries. Also fixing some entries that were not in alphabetical order. 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 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] msft-202412 - [x] msft-202503 - [x] 202505 ### Approach #### What is the motivation for this PR? Tests are unintentionally unskipped, and there are commit checks that failed when attempting to commit the fix. #### How did you do it? Added the missing skip conditions and rearranged the order of skip conditions to match the alphabetical order. #### How did you verify/test it? `fib/test_fib.py::test_nvgre_hash` is skipped properly on Broadcom platforms after the fix. #### Any platform specific information? Broadcom specific #### 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? -->
<!-- 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 ### 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? -->
…ts from internal to internal-202412 Across different branches, the connection graph facts should remain consistent. However, as the code undergoes continuous updates, the disparities between connection graph facts files among different branches are becoming more pronounced, which divergence poses significant challenges for cherry-pick. To address these differences and reduce the time spent synchronizing branches, we can automate the creation of pull requests by running a pipeline. This pull request use the connection graph facts from the internal branch to overwrite other branches, thereby synchronizing the connection graph facts across different branches.This pull request is created from https://dev.azure.com/mssonic/internal/_git/sonic-mgmt-int/pullrequest/19480
…ternal-202412 Merge remote-tracking branch 'source/202412' into internal-202412
What is the motivation for this PR? To enable ipv6 only topo for test_static_route How did you do it? Have a check for ipv6 and use appropriate prefix for it. How did you verify/test it? Tested on ipv6 only testbed to verify (cherry picked from commit 0048c8e)
What is the motivation for this PR? Enable test_po_update with ipv6-only topo How did you do it? Added steps for ipv6 How did you verify/test it? Ran on ipv6-only topo testbed (cherry picked from commit 4af314c)
…net#1066) <!-- 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 sonic-net#20729 ### 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 - [x] 202411 - [x] 202505 - [x] 202511 ### Approach #### What is the motivation for this PR? Enable test_po_update with ipv6-only topo #### How did you do it? Added steps for ipv6 #### How did you verify/test it? Ran on ipv6-only topo testbed <img width="2964" height="400" alt="image" src="https://github.com/user-attachments/assets/1ba5af3a-8a5f-4eab-8180-9eb96329cb6a" /> #### 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: Sonic Build Admin <sonicbld@microsoft.com>
… test bgp scale from rotated logs (sonic-net#1065) <!-- 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: Update IPv6 BGP scale test log parsing to also include relevant events from rotated `sairedis` logs (`sairedislog.1`). Instead of only falling back to the rotated log when the current log has no matches, this change always reads both files and combines the results so RP/NHG events aren’t missed due to log rotation. Also downgrade a “failed to read” message from warning to info to reduce noise when a file isn’t present. 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 - [ ] 202511 ### Approach #### What is the motivation for this PR? During the IPv6 BGP scale tests, relevant RP/NHG events can be split across `sairedis` logs due to log rotation. The previous implementation only checked the rotated log as a fallback when the active log had no matches, which could miss events when both logs contain matches (or when some events are only in `.1` while others are in the active file). #### How did you do it? In `tests/bgp/test_ipv6_bgp_scale.py`: - Read matching lines from both `sairedislog` and `sairedislog.1`. - Combine results as `lines = log_rotated_lines + lines` so rotated log events are included. - Change the “Failed to read …” message from `warning` to `info` since the rotated log file may not exist and that’s not necessarily an error condition. #### How did you verify/test it? Ran the tests on Arista 7060X6 and Mellanox SN5640 #### 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: Sonic Build Admin <sonicbld@microsoft.com>
…onic-net#1064) <!-- 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 Remove xfail because the test can pass on v6 topos after garp fix: sonic-net#21155 <!-- - 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 - [x] Test case improvement ### Back port request - [x] 202412 - [x] 202505 ### Approach #### What is the motivation for this PR? The test case can pass with the fix from sonic-net#21155 #### How did you do it? Remove xfail in tests_mark_conditions.yaml #### How did you verify/test it? The test passed on v6 topo after removing xfail #### Any platform specific information? #### Supported testbed topology if it's a new test case? v6 topos ### 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: Sonic Build Admin <sonicbld@microsoft.com>
…G route-map for upstream LC (sonic-net#1063) <!-- 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) In addition to the fix provided by sonic-net#15962 for the issue sonic-net#9052, this code change is also needed for handling AZNG route map changes on upstream LC. ### 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 - [x] Test case improvement ### Back port request - [ ] 202012 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [x] 202405 - [x] 202411 ### Approach #### What is the motivation for this PR? - '_test_default_route_with_bgp_flap_', for msft specific AZNG route maps on upstream LC fails even with the fix provided by sonic-net#15962 #### How did you do it? - In addition to the fix provided by sonic-net#15962 , handle the case for all route maps. #### How did you verify/test it? - Ran the test on T2 chassis with upstream LC, having different sets of route maps and made sure the tests are passing as expected. #### 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: Sonic Build Admin <sonicbld@microsoft.com>
…e range (sonic-net#1062) <!-- 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: Update the IPv6 BGP scale PTF traffic generation to use a *cyclic* ICMPv6 type chosen from a safe, non-reserved range, instead of incrementing a global ICMP type value. This avoids eventually drifting into reserved/invalid ICMP type values across repeated test phases/runs in future when new test cases maybe added and keeps packet-mask counters stable. 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 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? The bgp scale test previously used a global ICMP type that was incremented on each phase. Over time when new test cases kept adding, this can move into reserved/unsafe ICMP type values, which may cause unexpected behavior and flaky results. We want each phase to use a distinct ICMP type for mask counters, while guaranteeing the type stays within a safe range. #### How did you do it? - Added an `itertools.cycle()` generator over a bounded ICMP type range (currently `5..125`). - Replaced the global incrementing variable with `_get_icmp_type()` to fetch the next type for each test phase. - This global variable can only be accessed through this function. - Updated `generate_packets()` to accept `icmp_type` as an explicit parameter and plumbed it through call sites (flapper + withdraw/announce phases). #### How did you verify/test it? - Verified the test module imports and packet generation uses the provided `icmp_type`. - Confirmed all previous call sites were updated to pass `icmp_type`, and packet-mask setup uses the same value for each phase. #### 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: Sonic Build Admin <sonicbld@microsoft.com>
…F Reachability and Accurate Downtime (sonic-net#1061) <!-- 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: In IPv6 BGP scale flap testing, when `all_flap` is enabled we must keep one neighbor stable avoid dataplane downtime miscalculation. This PR updates the target selection logic to flap “all minus one” neighbors by removing the randomly chosen injection neighbor from the flapping neighbor list, and updates the log message accordingly. 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 - [ ] 202511 ### Approach #### What is the motivation for this PR? The flap test requires a dedicated “injection neighbor” to remain up for route injection/verification. Previously, with `all_flap=True`, the injection neighbor could also be included in the flapping set, causing inconsistent/incorrect behavior. #### How did you do it? In `tests/bgp/test_ipv6_bgp_scale.py` (`_select_targets_to_flap`), when `all_flap` is enabled: - Copy the neighbor list (`list(bgp_neighbors)`) to avoid aliasing. - Randomly pick the injection neighbor. - Remove the injection neighbor from `flapping_neighbors` so we flap all other neighbors. - Update the log message to reflect “All - 1 neighbors”. #### How did you verify/test it? Ran the tests on Arista 7060X6 and Mellanox SN5640 #### 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: Sonic Build Admin <sonicbld@microsoft.com>
…616/20260311061100 into internal-202412
…643/20260312095342 into internal-202412
What is the motivation for this PR? Enable OTEL feature when OTEL image exists How did you do it? Add a function to check if otel docker image exists, if yes, enable otel feature. How did you verify/test it? Verified it in internal setup. Any platform specific information? Nvidia SN5640 Supported testbed topology if it's a new test case? to-isolated-d32u32s2 Signed-off-by: Janet Cui <janet970527@gmail.com>
…et#1058) Cherry-pick of sonic-net#21910 to 202412. Original PR: sonic-net#21910
) <!-- 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: subnet decap tunnel is disabled on 202412 in Azure/sonic-swss.msft#209. xfail related cases. `qos/test_qos_dscp_mapping.py::TestQoSSaiDSCPQueueMapping_IPIP_Base::test_dscp_to_queue_mapping[uniform]` `srv6/test_srv6_dataplane:py::TestSRv6DataPlaneBase::test_srv6_full_func` ### 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? xfail decap related cases in 202412. #### How did you do it? add marked condition #### 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: Sonic Build Admin <sonicbld@microsoft.com>
…ngleasic call PR sonic-net#1067 cherry-picked the otel feature enablement from upstream PR sonic-net#22341, but the upstream overwrite_feature_golden_config_db_singleasic() accepts optional auto_restart and state parameters, while the 202412 branch version only accepts (config, feature_key) and hardcodes both as 'enabled'. This causes a TypeError at runtime: TypeError: overwrite_feature_golden_config_db_singleasic() takes 3 positional arguments but 5 were given Fix by removing the extra arguments since the 202412 branch already hardcodes the desired 'enabled' values. Signed-off-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Dashuai Zhang <dashuaizhang@microsoft.com>
…-net#1055) Cherry-pick of sonic-net#21765 to 202412. Original PR: sonic-net#21765
fix sync error for console_user Signed-off-by: Dashuai Zhang <dashuaizhang@microsoft.com>
…ts from internal to internal-202412 Across different branches, the connection graph facts should remain consistent. However, as the code undergoes continuous updates, the disparities between connection graph facts files among different branches are becoming more pronounced, which divergence poses significant challenges for cherry-pick. To address these differences and reduce the time spent synchronizing branches, we can automate the creation of pull requests by running a pipeline. This pull request use the connection graph facts from the internal branch to overwrite other branches, thereby synchronizing the connection graph facts across different branches.This pull request is created from https://dev.azure.com/mssonic/internal/_git/sonic-mgmt-int/pullrequest/19846
…ts from internal to internal-202412 Across different branches, the connection graph facts should remain consistent. However, as the code undergoes continuous updates, the disparities between connection graph facts files among different branches are becoming more pronounced, which divergence poses significant challenges for cherry-pick. To address these differences and reduce the time spent synchronizing branches, we can automate the creation of pull requests by running a pipeline. This pull request use the connection graph facts from the internal branch to overwrite other branches, thereby synchronizing the connection graph facts across different branches.This pull request is created from https://dev.azure.com/mssonic/internal/_git/sonic-mgmt-int/pullrequest/20056
…ts from internal to internal-202412 Across different branches, the connection graph facts should remain consistent. However, as the code undergoes continuous updates, the disparities between connection graph facts files among different branches are becoming more pronounced, which divergence poses significant challenges for cherry-pick. To address these differences and reduce the time spent synchronizing branches, we can automate the creation of pull requests by running a pipeline. This pull request use the connection graph facts from the internal branch to overwrite other branches, thereby synchronizing the connection graph facts across different branches.This pull request is created from https://dev.azure.com/mssonic/internal/_git/sonic-mgmt-int/pullrequest/20072
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
/azp run |
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:
packet_trimming/test_packet_trimming_symmetric.py::TestPacketTrimmingSymmetric::test_trimming_with_srv6when topology containsisolatedand release is202412.Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
Avoid known failing/unsupported behavior for this specific test case on isolated topologies in 202412.
How did you do it?
Added a conditional skip entry in
tests/common/plugins/conditional_mark/tests_mark_conditions.yamlfor the specific testcase.How did you verify/test it?
Validated the updated YAML file parses successfully.
Any platform specific information?
No platform-specific code changes; condition is scoped to
isolatedtopo andrelease == 202412.Supported testbed topology if it's a new test case?
N/A
Documentation
N/A