ACL Scaling on HPE Comware

This post will be of zero interest to anyone who doesn’t need to create very large ACLs on HPE Comware switches. If you are normal, look away now.

I had a need to understand the ACL scaling limits on HP5130 switches. ACLs elsewhere on the network consist of a handful of rules to permit/deny specific items at the L3 zone or occasional route maps to control route distribution. In the future this might change with network micro-segmentation becoming a highly desirable state. One way to implement the enforcement part of micro-segmentation is using stateless ACLs at the very edge of the network. This means that IP packets are filtered before even hitting the first hop. This isn’t a post about that but an implication of this dev is the potential need for larger and more complex ACLs. As well as lots of them configured on a single switch.

This post looks at the maximum rules you can implement on a physical interface. Upon starting this investigation I thought the answer would be a number. Spoiler alert: the answer is “it depends”.

The starting point was to create the largest ACL possible. I created a spreadsheet to automate the creation of rules

I started pasting in rules into an advanced ACL:

acl advanced name testacl
rule 1 permit ip source 1.1.1.1 0.0.0.0 destination any

After a few thousand I lost interest and so had a single ACL with several thousand rules. It looks like this could have been extended forever and at first I thought this meant that you can use really large ACLs. That was until I tried to apply the acl.

Using the command [teststack1-GigabitEthernet1/0/1]packet-filter name testacl inbound I got the error

Failed to apply or refresh IPv4 ACL testacl2 to the outbound direction of interface GigabitEthernet1/0/1. The resources are insufficient.

Lesson one: the scaling check is done when an ACL is applied.

This makes sense as I suspect you can have larger ACLs for certain purposes (packet filters) than you might in other places (route filters). So next a new ACL with a small number of rules. This was accepted. So add 100 more rules. At this point the CLI is slow like a CPU issue. I realised that there is some backend work applying each rule as it is added. However when I reached 2000 I realised this isn’t the case. Undoing the application on the interface and re-adding gave the above error. Next I created a small ACL and kept undoing/doing until I reach the error. Then went backwards until I found the limit. In this case for outbound interface filtering on a 5130 it was 1280 rules (or so I thought). Next I applied the same ACL to the inbound….and got the above error. It would be ridiculous to have a smaller inbound limit to the outbound. But that is the case. I applied the same logic and created a small ACL and wound it up to find the limit: 512. So here is the proof:


[teststack1-GigabitEthernet1/0/1]packet-filter  name testacl2 o
[teststack1-GigabitEthernet1/0/1]packet-filter  name testacl i
[teststack1-GigabitEthernet1/0/1]dis acl name testacl | i rules
Advanced IPv4 ACL named testacl, 1280 rules,
[teststack1-GigabitEthernet1/0/1]dis acl name testacl2 | i rules
Advanced IPv4 ACL named testacl2, 512 rules,




[teststack1-GigabitEthernet1/0/1]packet-filter  name testacl2 o
[teststack1-GigabitEthernet1/0/1]packet-filter  name testacl i
Failed to apply or refresh IPv4 ACL testacl rule 1 to the inbound direction of interface GigabitEthernet1/0/1. The resources are insufficient.
[teststack1-GigabitEthernet1/0/1]dis acl name testacl | i rules
Advanced IPv4 ACL named testacl, 1281 rules,
[teststack1-GigabitEthernet1/0/1]dis acl name testacl2 | i rules
Advanced IPv4 ACL named testacl2, 512 rules,




[teststack1-GigabitEthernet1/0/1]packet-filter  name testacl2 o
Failed to apply or refresh IPv4 ACL testacl2 to the outbound direction of interface GigabitEthernet1/0/1. The resources are insufficient.
[teststack1-GigabitEthernet1/0/1]packet-filter  name testacl i
[teststack1-GigabitEthernet1/0/1]dis acl name testacl | i rules
Advanced IPv4 ACL named testacl, 1280 rules,
[teststack1-GigabitEthernet1/0/1]dis acl name testacl2 | i rules
Advanced IPv4 ACL named testacl2, 513 rules,

Lesson two: inbound and outbound interface filters have different scale limits

Something wasn’t quite right. More than two decades of playing this came meant I could sense something was wrong. So I swapped the last rule in the testacl2 to rule 512 permit tcp source-port range 1 6500 destination-port range 1 65000

So the same number of rules, but with a little more complexity for just one of them. Fail. In fact with just the one interesting rule and lots of the original simple rules I wasn’t able to get half the scale.

Lesson three: the scale limit isn’t the number of rules, but an internal calculation resulting from the rules

So how do you calculate the ACL scale limit of any switch? The answer is more complex and possibly the reason you’ll never see the true answer on any data sheet. In reality you need to enter a config close to what you need in reality. Then double the lines with the same amount of complexity. In reality you could have hundreds of ACLs with source/destination ports and be OK. So for the most part this is a theoretical issue rather than a practical one.

This does have implications for micro-segmentation. These ACLs on switches were designed to put a few lines in to only permit specific traffic or deny specific unwanted traffic. They aren’t really designed for firewalling. So when we use this tool as a way to limit traffic in a general sense care must be taken. You can’t put an entire corporate firewalling policy down to the switch for each VLAN. Either the above specific limit or some other limit will break everything. But you can use the concept of a coarse and fine filter with this approach. Filter using a small number of broad policies at this level, the kind that don’t change much. Use this together with a true firewall policy on hardware designed to cope with it for the fine detail. Add routing that requires access to go through that firewall. Job done.

Aruba facilitate this approach by permitting user based tunnels. These are a VXLAN or similar tunnel between the edge port and some other part of the network (firewall, virtual machine, subnet…). This allows you to filter the majority at source but then if required inspect traffic at depth if required.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

Create your website with WordPress.com
Get started