Skip to content

[action] [PR:21947] Fix Issue with Checking for Active ACL Rules by aclshow -a#22226

Merged
vmittal-msft merged 1 commit intosonic-net:202511from
mssonicbld:cherry/202511/21947
Feb 3, 2026
Merged

[action] [PR:21947] Fix Issue with Checking for Active ACL Rules by aclshow -a#22226
vmittal-msft merged 1 commit intosonic-net:202511from
mssonicbld:cherry/202511/21947

Conversation

@mssonicbld
Copy link
Copy Markdown
Collaborator

Description of PR

Some platforms appear to treat everflow ACLs differently from typical dataplane ACLs, in that counters in showacl -a will always appear as N/A before and after traffic even if the rules are correctly formed. The previous version of the IPv6 Everflow test used the results of showacl -a to determine whether ACLs were configured and ready, but in the case of some Arista devices, the N/A behaviour caused the test to fail at that check. This PR simply changes the logic to check that all rules are 'active' in `show acl rule'.

Type of change

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

Approach

What is the motivation for this PR?

We saw unexpected test failures after the deployment of the previous test

How did you do it?

Updated the failing check to use a source of truth that was reliable across platforms

How did you verify/test it?

Ran it against the known working platforms (sn4600) and verified it against platforms known to have the N/A issue (Arista 7060x6 and 7050cx3).

Documentation

acl_counters_fix_7060x6.txt
acl_counters_fix_sn2700.txt

…et#21947)

* Feature/route programming data (sonic-net#21523)

This PR adds test cases and supporting utilities to measure route programming time under high‑scale BGP IPv6 scenarios, building on the refactoring in PR sonic-net#21335. It focuses on quantifying how long it takes for routes to be fully programmed after BGP/connection events (e.g., convergence, admin flaps), and verifying that the measured RP times stay within expected limits and similar to the convergence time.

Signed-off-by: Andoni Sanguesa <andoniesanguesa@gmail.com>
@mssonicbld
Copy link
Copy Markdown
Collaborator Author

Original PR: #21947

@mssonicbld
Copy link
Copy Markdown
Collaborator Author

/azp run

@github-actions github-actions bot requested a review from xwjiang-ms February 3, 2026 03:13
@azure-pipelines
Copy link
Copy Markdown

Azure Pipelines successfully started running 1 pipeline(s).

@radha-danda
Copy link
Copy Markdown

/azpw run Azure.sonic-mgmt

@mssonicbld
Copy link
Copy Markdown
Collaborator Author

/AzurePipelines run Azure.sonic-mgmt

@azure-pipelines
Copy link
Copy Markdown

Azure Pipelines successfully started running 1 pipeline(s).

@vmittal-msft vmittal-msft merged commit 419518b into sonic-net:202511 Feb 3, 2026
17 checks passed
lakshmi-nexthop pushed a commit to lakshmi-nexthop/sonic-mgmt that referenced this pull request Feb 11, 2026
…et#21947) (sonic-net#22226)

* Feature/route programming data (sonic-net#21523)

This PR adds test cases and supporting utilities to measure route programming time under high‑scale BGP IPv6 scenarios, building on the refactoring in PR sonic-net#21335. It focuses on quantifying how long it takes for routes to be fully programmed after BGP/connection events (e.g., convergence, admin flaps), and verifying that the measured RP times stay within expected limits and similar to the convergence time.

Signed-off-by: Andoni Sanguesa <andoniesanguesa@gmail.com>
Co-authored-by: Andoni Sanguesa <31708881+AndoniSanguesa@users.noreply.github.com>
Signed-off-by: Lakshmi Yarramaneni <lakshmi@nexthop.ai>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants