Uma ACL que parece pequena no papel ainda assim pode esgotar os recursos TCAM de um slot — não porque há regras demais, mas porque algumas delas são silenciosamente caras. Veja como ler display acl resource antes de ficar adivinhando, e os três hábitos de configuração que o esgotam mais rápido.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Os recursos de ACL baseados em TCAM não são alocados um por regra — alguns tipos de regra custam muito mais do que outros, e alguns recursos gastam do mesmo pool sem nunca mencionar ACL no nome.
Os recursos de ACL e QoS de um switch compartilham um pool fixo de recursos de correspondência de hardware por slot — normalmente exibido como entradas VACL, IACL, EACL, Meter, Counter e UDF em display acl resource. A maioria das regras custa uma entrada cada, por isso uma ACL de 20 regras geralmente parece proporcional aos recursos que consome. O problema começa quando um hábito de configuração multiplica esse custo por regra, ou quando um recurso nada relacionado à árvore de comandos de ACL silenciosamente consome do mesmo pool de UDF.
O resultado, quando o pool se esgota, raramente parece uma mensagem de erro apontando para a causa real. Parece um recurso configurado corretamente que simplesmente não funciona — uma atribuição de VLAN que nunca entra em vigor, uma política de tráfego que se aplica na primeira porta e falha silenciosamente em cada porta seguinte, ou uma linha de log sobre recursos de UDF que parece não ter nada a ver com a mudança que você acabou de fazer.
Nenhum desses três aparece como um problema de contagem de regras de ACL até você já saber que deve procurá-los.
Cada ramo abaixo produz um sintoma diferente, mas todos os três estão consumindo o mesmo pool finito de recursos por slot — por isso display acl resource precisa ser o primeiro comando, não o último.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
O pool em si não distingue entre uma regra que legitimamente precisa dos recursos que usa e uma que gasta 15x o que seu autor esperava — display acl resource apenas relata Used, Free e Total. Ler os três ramos acima indica com qual tipo de consumidor você realmente está lidando.
Quatro verificações, na ordem que realmente identifica qual dos três consumidores é o responsável.
<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 briefDepois que display acl resource indicar que o pool está realmente apertado, essas cinco armadilhas explicam a maior parte do que realmente o está consumindo.
SINTOMAUma política de tráfego ou recurso baseado em ACL falha ao aplicar com um log reportando insufficient rule resources, mesmo que display acl pareça um conjunto de regras curto e sem nada de especial.
CAUSAEm um caso de campo, uma ACL com apenas quatro regras — duas delas usando a palavra-chave gt para uma correspondência baseada em porta — consumiu cerca de 400 entradas de recursos de hardware depois de aplicada. Cada regra contendo gt ocupa cerca de 15 entradas em vez da 1 que uma simples regra permit/deny usaria, então algumas delas podem dominar o custo real de hardware de uma ACL enquanto sua contagem de regras permanece enganosamente pequena.
SOLUÇÃOQuando a mesma correspondência puder ser escrita como um valor explícito, uma lista curta, ou um intervalo em vez de uma comparação maior-que, faça isso — e trate qualquer ACL que misture gt com outros operadores como uma que deve ser verificada com display acl resource antes de adicioná-la a mais portas.
SINTOMAExatamente a mesma política de tráfego se aplica limpa na primeira porta de um slot e depois falha em cada porta seguinte, com um log citando insufficient rule resources para um número de regra específico.
CAUSAUma política de tráfego aplicada a várias portas do mesmo slot normalmente compartilha uma única cópia de sua pegada de recursos entre todas elas. Configurar statistic enable no comportamento de fluxo desativa esse compartilhamento para essa política — cada porta à qual ela é aplicada agora consome sua própria cópia completa. Em um caso de campo, uma política custando 894 entradas de recursos por porta esgotou um slot com apenas 642 entradas livres logo na primeira porta adicional.
SOLUÇÃORemova statistic enable do comportamento de fluxo se as contagens de tráfego não forem realmente necessárias, ou mova o requisito de estatísticas para uma política separada limitada apenas às interfaces que precisam dela — car e certos modos de tabela estendida específicos de placa desativam o mesmo compartilhamento e vale a pena verificar pelo mesmo motivo.
SINTOMAO dispositivo registra insufficient UDF resource, e o recurso que realmente falha ao aplicar não tem nenhuma relação com qualquer ACL personalizada que alguém se lembre de ter configurado.
CAUSAOs recursos de UDF (User-Defined Field) são compartilhados por uma lista específica e documentada de recursos, não apenas regras de ACL personalizadas: igmp-snooping over-vpls enable, dhcp snooping over-vpls enable, bfd for pw enable, bfd for vsi-pw enable, statistic enable em uma interface Tunnel, papéis SVF ou WLAN no dispositivo, e qualquer regra de ACL definida pelo usuário. Um dispositivo executando vários desses por razões não relacionadas pode esgotar o pool sem nenhuma ACL personalizada envolvida.
SOLUÇÃOVerifique os sete consumidores com os comandos que revelam cada um — display as all e display ap all para papéis SVF/WLAN, display traffic-applied brief para ACLs definidas pelo usuário — antes de supor que o esgotamento está relacionado a ACL, e remova qualquer um deles que não seja realmente necessário.
SINTOMAAlgumas interfaces de um switch aprendem os endereços MAC dos clientes na VLAN errada apesar da configuração idêntica em todas elas — mesmos comandos, mesmas definições de sub-rede, resultado diferente de porta para porta.
CAUSAEm um caso de campo, a atribuição de VLAN baseada em sub-rede foi configurada de forma idêntica em cada porta de acesso, mas os recursos de VLAN-ACL se esgotaram no meio da aplicação em todas as interfaces. O dispositivo emitiu um alarme SRVSERCONFIGFAILED identificando a interface e o recurso exatos que falharam ao aplicar — mas o sintoma no fio parecia uma simples configuração incorreta de VLAN, e o alarme é fácil de passar despercebido se ninguém estiver de olho.
SOLUÇÃOQuando várias interfaces compartilham o que deveria ser uma configuração idêntica e apenas algumas se comportam corretamente, verifique o histórico de alarmes por SRVSERCONFIGFAILED antes de reverificar a própria configuração, depois confirme com display acl resource — a correção geralmente é consolidar definições de sub-rede-VLAN sobrepostas em vez de adicionar mais.
SINTOMAUma regra de ACL recém-adicionada e mais específica parece não ter efeito algum, embora display acl resource mostre que a regra foi aceita e os recursos não foram o problema desta vez.
CAUSARegras de ACL programadas em hardware em uma determinada porta correspondem em base de disparo único, primeiro acerto — se uma regra anterior (número de sequência menor, ou aplicada em uma política anterior na mesma interface) já corresponde ao tráfego, o pacote nunca chega à regra mais nova e específica, não importa quanta margem de recursos esteja disponível.
SOLUÇÃOAntes de supor um problema de recursos, verifique a ordem das regras com display acl e confirme que nada mais amplo, anterior na sequência, já reivindica o mesmo tráfego — o esgotamento de recursos e os conflitos de ordem de regras produzem um sintoma semelhante de «minha regra não parece fazer nada», mas precisam de correções completamente diferentes.
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Execute display acl resource [ slot slot-id ] e leia Used em relação a Total para cada categoria — VACL, IACL, EACL, Meter, Counter e Ingress UDF são rastreados separadamente, e uma nova política pode falhar mesmo enquanto outras categorias ainda mostram bastante margem.
Não — uma regra simples permit/deny normalmente custa uma entrada, mas regras usando a palavra-chave gt custam cerca de 15 entradas cada uma no caso de campo documentado, e recursos como statistic enable mudam quantas cópias dos recursos de uma política são consumidas em várias portas. A contagem de regras sozinha não é uma estimativa confiável do custo real de hardware.
A principal desvantagem é perder os contadores de tráfego por regra que statistic enable fornecia; se esses contadores forem realmente necessários, limitá-los a uma política separada, aplicada de forma restrita, em vez da compartilhada entre portas, mantém a contabilização sem pagar a penalidade de compartilhamento em todo lugar.
IACL e EACL são os recursos de processamento de entrada (upstream) e saída (downstream) respectivamente, cada um dividido em uma alocação de Slice mais a alocação real de regras por tipo — classes de ACL IPv4, IPv6, segurança e outras. VACL é o recurso consumido antes do pipeline principal de encaminhamento de camada 2 no lado de entrada. Uma política pode ficar sem margem em qualquer uma dessas categorias independentemente das outras.
Em switches modulares, isso é rastreado por slot — display acl resource slot slot-id mostra o pool daquela placa específica. Uma configuração que consome muitos recursos em um slot não necessariamente afeta a margem em outro, o que também explica por que a mesma política pode ter sucesso em uma placa e falhar em outra com contagem de portas ou hardware diferentes.
insufficient rule resources no log de aplicação da política de tráfego, insufficient UDF resource especificamente para o esgotamento de UDF, e SRVSERCONFIGFAILED como alarme geral de falha de serviço por recurso ou conflito de hash — os três apontam diretamente para o pool de recursos compartilhado em vez de um erro de lógica na própria configuração do recurso.
Esta nota é construída em torno do modelo de recursos de ACL/QoS baseado em TCAM do switch Huawei da série S e dos comandos display acl resource / display traffic-policy applied-record, além dos casos de campo por trás deles. Os custos exatos de recursos por tipo de regra, e a lista de recursos que compartilham o pool de UDF, variam de acordo com a placa e a versão de software — trate os números de 15 entradas por regra gt e 894 entradas por porta aqui como ilustrações do mecanismo, não constantes universais, e confirme os números reais em seu próprio hardware com display acl resource.
Envie-nos a saída de display acl resource para o slot envolvido, além de qualquer texto de log ou alarme que você estiver vendo, e ajudaremos você a descobrir qual dos três consumidores é o responsável.