Una ACL que parece pequeña sobre el papel aun así puede agotar los recursos TCAM de un slot — no porque haya demasiadas reglas, sino porque unas pocas son sigilosamente costosas. Así se lee display acl resource antes de adivinar, y los tres hábitos de configuración que lo agotan más rápido.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Los recursos ACL respaldados por TCAM no se asignan uno por regla — algunos tipos de regla cuestan mucho más que otros, y algunas funciones gastan del mismo grupo sin mencionar nunca ACL en su nombre.
Las funciones de ACL y QoS de un switch comparten un grupo fijo de recursos de coincidencia de hardware por slot — que normalmente se muestra como entradas VACL, IACL, EACL, Meter, Counter y UDF en display acl resource. La mayoría de las reglas cuestan una entrada cada una, por lo que una ACL de 20 reglas suele verse proporcional a los recursos que consume. El problema comienza cuando un hábito de configuración multiplica ese costo por regla, o cuando una función que no tiene nada que ver con el árbol de comandos de ACL toma silenciosamente recursos del mismo grupo UDF.
El resultado, cuando el grupo se agota, rara vez parece un mensaje de error que señale la causa real. Parece una función configurada correctamente que simplemente no funciona — una asignación de VLAN que nunca surte efecto, una política de tráfico que se aplica en el primer puerto y falla silenciosamente en cada puerto siguiente, o una línea de log sobre recursos UDF que parece no tener nada que ver con el cambio que acaba de hacer.
Ninguno de estos tres se presenta como un problema de cantidad de reglas ACL hasta que ya sabe que debe buscarlos.
Cada rama a continuación produce un síntoma distinto, pero las tres agotan el mismo grupo finito de recursos por slot — por eso display acl resource debe ser el primer comando, no el último.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
El grupo en sí no distingue entre una regla que legítimamente necesita los recursos que usa y una que gasta 15 veces lo que su autor esperaba — display acl resource simplemente informa Used, Free y Total. Leer las tres ramas anteriores le indica con qué tipo de consumidor está realmente tratando.
Cuatro comprobaciones, en el orden que realmente identifica cuál de los tres consumidores es responsable.
<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 briefUna vez que display acl resource le indica que el grupo está realmente ajustado, estos cinco problemas explican la mayor parte de lo que realmente lo está consumiendo.
SÍNTOMAUna política de tráfico o función basada en ACL falla al aplicarse con un log que reporta insufficient rule resources, aunque display acl parezca un conjunto de reglas corto y sin nada destacable.
CAUSAEn un caso de campo, una ACL con solo cuatro reglas — dos de ellas usando la palabra clave gt para una coincidencia basada en puertos — consumió aproximadamente 400 entradas de recursos de hardware una vez aplicada. Cada regla que contiene gt ocupa unas 15 entradas en lugar de la 1 que usaría una simple regla permit/deny, así que un puñado de ellas puede dominar el costo real de hardware de una ACL mientras su número de reglas permanece engañosamente pequeño.
SOLUCIÓNCuando la misma coincidencia se pueda escribir como un valor explícito, una lista corta, o un rango en lugar de una comparación mayor-que, hágalo así — y trate cualquier ACL que mezcle gt con otros operadores como una que debe verificarse con display acl resource antes de añadirla a más puertos.
SÍNTOMAExactamente la misma política de tráfico se aplica limpiamente en el primer puerto de un slot y luego falla en cada puerto siguiente, con un log que cita insufficient rule resources para un número de regla específico.
CAUSAUna política de tráfico aplicada a varios puertos del mismo slot normalmente comparte una sola copia de su huella de recursos entre todos ellos. Configurar statistic enable en el comportamiento de flujo desactiva ese uso compartido para esta política — cada puerto al que se aplica ahora consume su propia copia completa. En un caso de campo, una política que costaba 894 entradas de recursos por puerto agotó un slot con solo 642 entradas libres tras el primer puerto adicional.
SOLUCIÓNElimine statistic enable del comportamiento de flujo si los conteos de tráfico no son realmente necesarios, o traslade el requisito de estadísticas a una política separada limitada solo a las interfaces que lo necesitan — car y ciertos modos de tabla extendida específicos de la tarjeta desactivan el mismo uso compartido y vale la pena verificarlos por la misma razón.
SÍNTOMAEl equipo registra insufficient UDF resource, y la función que realmente falla al aplicarse no tiene ninguna relación con ninguna ACL personalizada que alguien recuerde haber configurado.
CAUSALos recursos UDF (User-Defined Field) son compartidos por una lista específica y documentada de funciones, no solo reglas ACL personalizadas: igmp-snooping over-vpls enable, dhcp snooping over-vpls enable, bfd for pw enable, bfd for vsi-pw enable, statistic enable en una interfaz Tunnel, roles SVF o WLAN en el equipo, y cualquier regla ACL definida por el usuario. Un equipo que ejecute varios de estos por razones no relacionadas puede agotar el grupo sin que intervenga ninguna ACL personalizada en absoluto.
SOLUCIÓNVerifique los siete consumidores con los comandos que revelan cada uno — display as all y display ap all para roles SVF/WLAN, display traffic-applied brief para ACL definidas por el usuario — antes de asumir que el agotamiento está relacionado con ACL, y elimine el que realmente no sea necesario.
SÍNTOMAAlgunas interfaces de un switch aprenden las direcciones MAC de los clientes en la VLAN equivocada a pesar de tener una configuración idéntica en todas — mismos comandos, mismas definiciones de subred, resultado distinto de un puerto a otro.
CAUSAEn un caso de campo, la asignación de VLAN basada en subred se configuró de forma idéntica en cada puerto de acceso, pero los recursos VLAN-ACL se agotaron a mitad de la aplicación en todas las interfaces. El equipo generó una alarma SRVSERCONFIGFAILED que identificaba la interfaz y función exactas que fallaron al aplicarse — pero el síntoma en el cable parecía una simple falla de configuración de VLAN, y la alarma es fácil de pasar por alto si nadie la está vigilando.
SOLUCIÓNCuando varias interfaces comparten lo que debería ser una configuración idéntica y solo algunas se comportan correctamente, revise el historial de alarmas en busca de SRVSERCONFIGFAILED antes de volver a revisar la configuración en sí, luego confirme con display acl resource — la solución suele ser consolidar las definiciones de subred-VLAN superpuestas en lugar de añadir más.
SÍNTOMAUna regla ACL recién agregada y más específica parece no tener ningún efecto, aunque display acl resource muestre que la regla fue aceptada y los recursos no fueron el problema esta vez.
CAUSALas reglas ACL programadas en hardware en un puerto determinado coinciden sobre una base de un solo disparo, la primera que aplica — si una regla anterior (número de secuencia menor, o aplicada en una política anterior en la misma interfaz) ya coincide con el tráfico, el paquete nunca llega a la regla más nueva y específica, sin importar cuánto margen de recursos haya disponible.
SOLUCIÓNAntes de asumir un problema de recursos, verifique el orden de las reglas con display acl y confirme que nada más amplio, antes en la secuencia, ya reclama el mismo tráfico — el agotamiento de recursos y los conflictos de orden de reglas producen un síntoma similar de «mi regla no parece hacer nada», pero necesitan soluciones completamente distintas.
Extraídas directamente del campo — las que vale la pena tener una respuesta preparada.
Ejecute display acl resource [ slot slot-id ] y lea Used frente a Total para cada categoría — VACL, IACL, EACL, Meter, Counter e Ingress UDF se rastrean por separado, y una nueva política puede fallar incluso mientras otras categorías siguen mostrando bastante margen.
No — una regla simple permit/deny normalmente cuesta una entrada, pero las reglas que usan la palabra clave gt cuestan alrededor de 15 entradas cada una en el caso de campo documentado, y funciones como statistic enable cambian cuántas copias de los recursos de una política se consumen en varios puertos. El número de reglas por sí solo no es una estimación confiable del costo real de hardware.
El principal compromiso es perder los contadores de tráfico por regla que proporcionaba statistic enable; si esos conteos son realmente necesarios, limitarlos a una política separada, aplicada de forma restringida, en lugar de la compartida entre puertos, mantiene el conteo sin pagar la penalización de compartición en todas partes.
IACL y EACL son los recursos de procesamiento de entrada (ascendente) y salida (descendente) respectivamente, cada uno dividido en una asignación de Slice más la asignación real de reglas por tipo — clases de ACL IPv4, IPv6, seguridad y otras. VACL es el recurso consumido antes del pipeline principal de reenvío de capa 2 en el lado de entrada. Una política puede quedarse sin margen en cualquiera de estas categorías independientemente de las demás.
En switches modulares se rastrea por slot — display acl resource slot slot-id muestra el grupo para esa tarjeta específica. Una configuración que consume muchos recursos en un slot no necesariamente afecta el margen en otro, lo cual también explica por qué la misma política puede tener éxito en una tarjeta y fallar en otra con distinta cantidad de puertos o hardware.
insufficient rule resources en el log de aplicación de la política de tráfico, insufficient UDF resource específicamente para el agotamiento de UDF, y SRVSERCONFIGFAILED como alarma general de fallo de servicio por recursos o conflicto de hash — los tres apuntan directamente al grupo de recursos compartido en lugar de a un error lógico en la propia configuración de la función.
Esta nota se basa en el modelo de recursos ACL/QoS respaldado por TCAM del switch Huawei serie S y los comandos display acl resource / display traffic-policy applied-record, además de los casos de campo detrás de ellos. Los costos exactos de recursos por tipo de regla, y la lista de funciones que comparten el grupo UDF, varían según la tarjeta y la versión de software — trate las cifras de 15 entradas por regla gt y 894 entradas por puerto aquí como ilustraciones del mecanismo, no constantes universales, y confirme las cifras reales en su propio hardware con display acl resource.
Envíenos la salida de display acl resource para el slot involucrado, más cualquier texto de log o alarma que esté viendo, y le ayudaremos a encontrar cuál de los tres consumidores es responsable.