An ACL that looks small on paper can still exhaust a slot's TCAM resources — not because there are too many rules, but because a handful of them are quietly expensive. This is how to read display acl resource before you're guessing, and the three configuration habits that burn through it fastest.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
TCAM-backed ACL resources aren't allocated one-per-rule — some rule types cost far more than others, and some features spend from the same pool without ever mentioning ACL in their name.
A switch's ACL and QoS features share a fixed, per-slot pool of hardware matching resources — commonly shown as VACL, IACL, EACL, Meter, Counter and UDF entries in display acl resource. Most rules cost one entry each, which is why a 20-rule ACL usually looks proportionate to the resources it consumes. The trouble starts when a configuration habit multiplies that cost per rule, or when a feature nowhere near the ACL command tree quietly draws from the same UDF pool.
The result, when the pool runs out, rarely looks like an error message pointing at the actual cause. It looks like a feature that's configured correctly and simply doesn't work — a VLAN assignment that never takes effect, a traffic-policy that applies on the first port and silently fails on every port after it, or a log line about UDF resources that seems to have nothing to do with the change you just made.
None of these three show up as an ACL rule count problem until you already know to look for them.
Each branch below produces a different symptom, but all three are drawing down the same finite per-slot resource pool — which is why display acl resource has to be the first command, not the last.
Diagram labels are kept in English for engineering clarity.
The pool itself doesn't distinguish between a rule that legitimately needs the resources it's using and one that's spending 15x what its author expected — display acl resource just reports Used, Free and Total. Reading the three branches above tells you which kind of consumer you're actually looking at.
Four checks, in the order that actually finds which of the three consumers is responsible.
<HUAWEI> display acl resource slot 1
Slot 1
GigabitEthernet1/0/0 to GigabitEthernet1/0/23
Used Free Total
--------------------------------------------
VACL Slice 1 3 4
VACL 12 1012 1024
IACL Slice 11 1 12
Sec ACL 284 228 512
Ingress UDF 7 1 8
--------------------------------------------
// Sec ACL and Ingress UDF are both close to Total on this slot -- the ones to chase
Nov xx 2024 xx:xx:xx FutureMatrix SCMTRAP/3/SRVSERCONFIGFAILED:OID 1.3.6.1.4.1.56813.5.25.334.2.1.3
The service configurations on the device failed because of no enough resources or hash conflict, please
undo it. (Service ID=9, Service Description="IP subnet-based VLAN assignment", Service Fail
Description="Enable IP subnet-based VLAN assignment on GigabitEthernet0/0/48")Advanced ACL 3333, 4 rules
Acl's step is 5
rule 5 permit udp destination-port gt sunrpc
rule 10 permit udp destination-port gt 1111
rule 15 permit udp destination-port lt 1111
rule 20 permit udp destination-port range 1111 2222
// two gt rules here accounted for the bulk of ~400 consumed resource entries
[HUAWEI] display traffic-policy applied-record test
*interface Vlanif335
traffic-policy test inbound
slot 0 : fail
// Failed to add the rule due to insufficient rule resources in policy test
// classifier test behavior PERMIT acl 3999, rule 120<Switch2>display traffic-policy applied-record
*interface XGigabitEthernet2/0/8
traffic-policy Test inbound
slot 2 : success
*interface XGigabitEthernet2/0/9
traffic-policy Test inbound
slot 2 : fail
// Failed to add the rule due to insufficient rule resources in policy Test
// classifier Test-permit behavior Test-permit acl 3001, rule 1762 on interface
// XGigabitEthernet2/0/9 of slot 2
[Switch2]display acl resource
Slot 2
Used Free Total
--------------------------------------------
IACL Slice 8 2 10
IACL Unallocated 512
IACL Allocated 1536
// only 512 unallocated + ~130 recoverable = 642 entries free -- not enough for a
// second port at ~894 entries each, because statistic enable stopped this policy
// from sharing one copy across every port on the slot// Documented UDF resource consumers -- check for all seven before assuming
// the exhaustion is ACL-related:
igmp-snooping over-vpls enable
dhcp snooping over-vpls enable
bfd for pw enable
bfd for vsi-pw enable
statistic enable // Tunnel interface view
SVF / WLAN roles // display as all, display ap all
user-defined ACL rules // display traffic-applied briefOnce display acl resource has told you the pool is genuinely tight, these five account for most of what's actually spending it.
SYMPTOMA traffic-policy or ACL-based feature fails to apply with a log reporting insufficient rule resources, even though display acl looks like a short, unremarkable rule set.
CAUSEIn one field case, an ACL with just four rules — two of them using the gt keyword for a port-based match — consumed roughly 400 hardware resource entries once applied. Each rule containing gt occupies about 15 entries instead of the 1 a simple permit/deny rule would use, so a handful of them can dominate an ACL's real hardware cost while its rule count stays deceptively small.
FIXWhere the same match can be written as an explicit value, a short list, or a range instead of a greater-than comparison, do that instead — and treat any ACL that mixes gt with other operators as one to check against display acl resource before adding it to more ports.
SYMPTOMThe exact same traffic-policy applies cleanly to the first port on a slot and then fails on every subsequent port, with a log citing insufficient rule resources for a specific rule number.
CAUSEA traffic-policy applied to multiple ports on the same slot normally shares one copy of its resource footprint across all of them. Configuring statistic enable in the flow behavior turns off that sharing for this policy — each port it's applied to now consumes its own full copy. In one field case, a policy costing 894 resource entries per port exhausted a slot with only 642 entries free after the very first additional port.
FIXRemove statistic enable from the flow behavior if the traffic counts aren't actually needed, or move the statistics requirement into a separate policy scoped only to the interfaces that need it — car and certain board-specific extended table modes disable the same sharing and are worth checking for the same reason.
SYMPTOMThe device logs insufficient UDF resource, and the feature that actually fails to apply is completely unrelated to any custom ACL anyone remembers configuring.
CAUSEUDF (User-Defined Field) resources are shared by a specific, documented list of features, not just custom ACL rules: igmp-snooping over-vpls enable, dhcp snooping over-vpls enable, bfd for pw enable, bfd for vsi-pw enable, statistic enable on a Tunnel interface, SVF or WLAN roles on the device, and any user-defined ACL rule. A device running several of these for unrelated reasons can exhaust the pool with no custom ACL involved at all.
FIXCheck for all seven consumers with the commands that reveal each — display as all and display ap all for SVF/WLAN roles, display traffic-applied brief for user-defined ACLs — before assuming the exhaustion is ACL-related, and remove whichever of them isn't actually needed.
SYMPTOMSome interfaces on a switch learn client MAC addresses into the wrong VLAN despite identical configuration across all of them — same commands, same subnet definitions, different result port to port.
CAUSEIn one field case, subnet-based VLAN assignment was configured identically on every access port, but VLAN-ACL resources ran out partway through applying it across all interfaces. The device raised an SRVSERCONFIGFAILED alarm identifying the exact interface and feature that failed to apply — but the symptom on the wire looked like an ordinary VLAN misconfiguration, and the alarm is easy to miss if no one is watching for it.
FIXWhen several interfaces share what should be identical configuration and only some of them behave correctly, check the alarm history for SRVSERCONFIGFAILED before re-checking the configuration itself, then confirm with display acl resource — the fix is usually to consolidate overlapping subnet-VLAN definitions rather than add more of them.
SYMPTOMA newly added, more specific ACL rule appears to have no effect at all, even though display acl resource shows the rule was accepted and resources weren't the problem this time.
CAUSEHardware-programmed ACL rules on a given port match on a one-shot, first-hit basis — if an earlier rule (lower sequence number, or applied in an earlier policy on the same interface) already matches the traffic, the packet never reaches the newer, more specific rule at all, regardless of how much resource headroom is available.
FIXBefore assuming a resource problem, check the rule order with display acl and confirm nothing broader, earlier in sequence, already claims the same traffic — resource exhaustion and rule-ordering conflicts produce a similar "my rule doesn't seem to do anything" symptom but need completely different fixes.
Pulled straight from the field — the ones worth having an answer ready for.
Run display acl resource [ slot slot-id ] and read Used against Total for each category — VACL, IACL, EACL, Meter, Counter and Ingress UDF are tracked separately, and a new policy can fail even while other categories still show plenty of headroom.
No — a plain permit/deny rule typically costs one entry, but rules using the gt keyword cost around 15 entries each in the documented field case, and features like statistic enable change how many copies of a policy's resources get consumed across multiple ports. Rule count alone is not a reliable estimate of real hardware cost.
The main tradeoff is losing the per-rule traffic counters that statistic enable was providing; if those counts are genuinely needed, scoping them to a separate, narrowly-applied policy rather than the shared cross-port one keeps the accounting without paying the sharing penalty everywhere.
IACL and EACL are the ingress (upstream/inbound) and egress (downstream/outbound) processing resources respectively, each split into a Slice allocation plus the actual rule allocation by type — IPv4, IPv6, security and other ACL classes. VACL is the resource consumed before the main Layer 2 forwarding pipeline on the ingress side. A policy can run out of headroom in any one of these independently of the others.
On modular switches it's tracked per slot — display acl resource slot slot-id shows the pool for that specific board. A resource-hungry configuration on one slot doesn't necessarily affect headroom on another, which is also why the same policy can succeed on one board and fail on another with a different port count or hardware.
insufficient rule resources in the traffic-policy apply log, insufficient UDF resource for UDF exhaustion specifically, and SRVSERCONFIGFAILED as a general resource-or-hash-conflict service failure alarm — all three point straight at the shared resource pool rather than a logic error in the feature's own configuration.
This note is built around the Huawei S-series switch's TCAM-backed ACL/QoS resource model and the display acl resource / display traffic-policy applied-record commands, plus the field cases behind them. Exact resource costs per rule type, and the list of features sharing the UDF pool, vary by board and software version — treat the 15-entries-per-gt-rule and 894-entries-per-port figures here as illustrations of the mechanism, not universal constants, and confirm the actual numbers on your own hardware with display acl resource.
Send us the display acl resource output for the slot involved, plus whatever log or alarm text you're seeing, and we'll help you find which of the three consumers is responsible.