My assumption has always been that ACLs (L2/L3) on the CX switches are handled in hardware, but not 100% sure. Of course, when you enable logging on an ACL (possibly even counting), the log will be handled on the CPU and may overload the CPU and flood the (management) network when remote logging/syslog is configured.
Maybe others can confirm or correct me. Can't speak for what others do, but it's probably dependent on the actual product, not so much on the vendor, where lower end product are more likely to have performance bottlenecks because the hardware/ASICs are less capable.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check
https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------
Original Message:
Sent: May 20, 2025 03:33 AM
From: Abdal_opr
Subject: The impact of Layer 2 ACLs on CPU performance
Hello,
we want to ensure that clients within the same VLAN cannot communicate with each other. I know this can be achieved using private VLANs, but I would like to inquire about implementing Layer 2 ACLs on switches in the 6100-6200 series. I've heard that such ACLs can heavily load the CPU and cause CPU spikes. Is that correct? Is there any documentation on this? Does Aruba implement these ACLs on hardware similar to Cisco, or are they processed at the CPU level? Are there alternative solutions?
Thank you!