Une ACL qui semble modeste sur le papier peut quand même épuiser les ressources TCAM d'un slot — non pas parce qu'il y a trop de règles, mais parce qu'une poignée d'entre elles sont discrètement coûteuses. Voici comment lire display acl resource avant de deviner, et les trois habitudes de configuration qui l'épuisent le plus vite.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Les ressources ACL basées sur le TCAM ne sont pas allouées à raison d'une par règle — certains types de règles coûtent bien plus que d'autres, et certaines fonctionnalités puisent dans le même pool sans jamais mentionner ACL dans leur nom.
Les fonctionnalités ACL et QoS d'un commutateur partagent un pool fixe de ressources matérielles de correspondance par slot — généralement affiché sous forme d'entrées VACL, IACL, EACL, Meter, Counter et UDF dans display acl resource. La plupart des règles coûtent une entrée chacune, ce qui explique pourquoi une ACL de 20 règles semble généralement proportionnée aux ressources qu'elle consomme. Le problème commence lorsqu'une habitude de configuration multiplie ce coût par règle, ou lorsqu'une fonctionnalité loin de l'arborescence de commandes ACL puise discrètement dans le même pool UDF.
Le résultat, lorsque le pool est épuisé, ressemble rarement à un message d'erreur pointant vers la cause réelle. Cela ressemble à une fonctionnalité correctement configurée qui ne fonctionne tout simplement pas — une affectation VLAN qui ne prend jamais effet, une politique de trafic qui s'applique sur le premier port et échoue silencieusement sur tous les ports suivants, ou une ligne de log sur les ressources UDF qui semble n'avoir aucun rapport avec le changement que vous venez d'effectuer.
Aucun de ces trois ne se manifeste comme un problème de nombre de règles ACL avant que vous ne sachiez déjà où chercher.
Chaque branche ci-dessous produit un symptôme différent, mais toutes trois puisent dans le même pool de ressources fini par slot — c'est pourquoi display acl resource doit être la première commande, pas la dernière.
Les légendes du schéma restent en anglais pour la clarté technique.
Le pool lui-même ne fait pas la différence entre une règle qui a légitimement besoin des ressources qu'elle utilise et une qui dépense 15 fois ce que son auteur attendait — display acl resource se contente de signaler Used, Free et Total. Lire les trois branches ci-dessus vous indique à quel type de consommateur vous avez réellement affaire.
Quatre vérifications, dans l'ordre qui permet réellement de trouver lequel des trois consommateurs est 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 briefUne fois que display acl resource vous a indiqué que le pool est réellement serré, ces cinq éléments expliquent l'essentiel de ce qui le consomme réellement.
SYMPTÔMEUne politique de trafic ou une fonctionnalité basée sur ACL échoue à s'appliquer avec un log signalant insufficient rule resources, même si display acl ressemble à un jeu de règles court et anodin.
CAUSEDans un cas de terrain, une ACL avec seulement quatre règles — deux utilisant le mot-clé gt pour une correspondance basée sur les ports — a consommé environ 400 entrées de ressources matérielles une fois appliquée. Chaque règle contenant gt occupe environ 15 entrées au lieu de la seule qu'utiliserait une simple règle permit/deny, de sorte qu'une poignée d'entre elles peut dominer le coût matériel réel d'une ACL alors que son nombre de règles reste trompeusement modeste.
SOLUTIONLorsque la même correspondance peut être écrite comme une valeur explicite, une courte liste, ou une plage plutôt qu'une comparaison supérieur-à, faites-le à la place — et traitez toute ACL mélangeant gt avec d'autres opérateurs comme une ACL à vérifier avec display acl resource avant de l'ajouter à d'autres ports.
SYMPTÔMELa même politique de trafic s'applique proprement sur le premier port d'un slot, puis échoue sur chaque port suivant, avec un log citant insufficient rule resources pour un numéro de règle spécifique.
CAUSEUne politique de trafic appliquée à plusieurs ports du même slot partage normalement une seule copie de son empreinte de ressources entre eux tous. Configurer statistic enable dans le comportement de flux désactive ce partage pour cette politique — chaque port auquel elle est appliquée consomme désormais sa propre copie complète. Dans un cas de terrain, une politique coûtant 894 entrées de ressources par port a épuisé un slot ne disposant que de 642 entrées libres dès le tout premier port supplémentaire.
SOLUTIONRetirez statistic enable du comportement de flux si les compteurs de trafic ne sont pas réellement nécessaires, ou déplacez le besoin de statistiques vers une politique séparée limitée aux interfaces qui en ont besoin — car et certains modes de table étendue spécifiques à la carte désactivent le même partage et méritent d'être vérifiés pour la même raison.
SYMPTÔMEL'appareil enregistre insufficient UDF resource, et la fonctionnalité qui échoue réellement à s'appliquer n'a absolument aucun rapport avec une quelconque ACL personnalisée dont quelqu'un se souvienne avoir configurée.
CAUSELes ressources UDF (User-Defined Field) sont partagées par une liste spécifique et documentée de fonctionnalités, pas seulement les règles ACL personnalisées : igmp-snooping over-vpls enable, dhcp snooping over-vpls enable, bfd for pw enable, bfd for vsi-pw enable, statistic enable sur une interface Tunnel, rôles SVF ou WLAN sur l'appareil, et toute règle ACL personnalisée. Un appareil exécutant plusieurs d'entre elles pour des raisons sans rapport peut épuiser le pool sans qu'aucune ACL personnalisée ne soit impliquée.
SOLUTIONVérifiez les sept consommateurs avec les commandes qui révèlent chacun d'eux — display as all et display ap all pour les rôles SVF/WLAN, display traffic-applied brief pour les ACL personnalisées — avant de supposer que l'épuisement est lié aux ACL, et retirez celui d'entre eux qui n'est pas réellement nécessaire.
SYMPTÔMECertaines interfaces d'un commutateur apprennent les adresses MAC des clients dans le mauvais VLAN malgré une configuration identique sur toutes — mêmes commandes, mêmes définitions de sous-réseau, résultat différent d'un port à l'autre.
CAUSEDans un cas de terrain, l'affectation VLAN basée sur le sous-réseau était configurée à l'identique sur chaque port d'accès, mais les ressources VLAN-ACL se sont épuisées en cours d'application sur toutes les interfaces. L'appareil a levé une alarme SRVSERCONFIGFAILED identifiant l'interface et la fonctionnalité exactes ayant échoué à s'appliquer — mais le symptôme sur le câble ressemblait à une simple erreur de configuration VLAN, et l'alarme est facile à manquer si personne ne la surveille.
SOLUTIONLorsque plusieurs interfaces partagent une configuration censée être identique et que seules certaines se comportent correctement, vérifiez l'historique des alarmes pour SRVSERCONFIGFAILED avant de revérifier la configuration elle-même, puis confirmez avec display acl resource — la solution consiste généralement à fusionner les définitions sous-réseau-VLAN qui se chevauchent plutôt que d'en ajouter.
SYMPTÔMEUne règle ACL nouvellement ajoutée, plus spécifique, semble n'avoir absolument aucun effet, même si display acl resource montre que la règle a été acceptée et que les ressources n'étaient pas le problème cette fois.
CAUSELes règles ACL programmées matériellement sur un port donné correspondent selon un principe de premier coup, à usage unique — si une règle antérieure (numéro de séquence inférieur, ou appliquée dans une politique antérieure sur la même interface) correspond déjà au trafic, le paquet n'atteint jamais la règle plus récente et plus spécifique, quelle que soit la marge de ressources disponible.
SOLUTIONAvant de supposer un problème de ressources, vérifiez l'ordre des règles avec display acl et confirmez qu'aucune règle plus large, plus tôt dans la séquence, ne revendique déjà le même trafic — l'épuisement des ressources et les conflits d'ordre de règles produisent un symptôme similaire de « ma règle ne semble rien faire » mais nécessitent des corrections complètement différentes.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Exécutez display acl resource [ slot slot-id ] et lisez Used par rapport à Total pour chaque catégorie — VACL, IACL, EACL, Meter, Counter et Ingress UDF sont suivis séparément, et une nouvelle politique peut échouer même si d'autres catégories affichent encore une marge confortable.
Non — une règle permit/deny simple coûte généralement une entrée, mais les règles utilisant le mot-clé gt coûtent environ 15 entrées chacune dans le cas de terrain documenté, et des fonctionnalités comme statistic enable modifient combien de copies des ressources d'une politique sont consommées sur plusieurs ports. Le nombre de règles seul n'est pas une estimation fiable du coût matériel réel.
Le principal compromis est la perte des compteurs de trafic par règle que fournissait statistic enable ; si ces compteurs sont réellement nécessaires, les limiter à une politique séparée, appliquée de manière restreinte, plutôt qu'à la politique partagée entre ports, conserve la comptabilisation sans payer partout la pénalité de partage.
IACL et EACL sont respectivement les ressources de traitement en amont (entrant) et en aval (sortant), chacune divisée en une allocation de Slice plus l'allocation réelle des règles par type — classes ACL IPv4, IPv6, sécurité et autres. VACL est la ressource consommée avant le pipeline de transfert principal de couche 2 côté entrant. Une politique peut manquer de marge dans l'une de ces catégories indépendamment des autres.
Sur les commutateurs modulaires, c'est suivi par slot — display acl resource slot slot-id affiche le pool pour cette carte spécifique. Une configuration gourmande en ressources sur un slot n'affecte pas nécessairement la marge sur un autre, ce qui explique aussi pourquoi la même politique peut réussir sur une carte et échouer sur une autre avec un nombre de ports ou un matériel différent.
insufficient rule resources dans le log d'application de la politique de trafic, insufficient UDF resource spécifiquement pour l'épuisement UDF, et SRVSERCONFIGFAILED comme alarme générale d'échec de service liée aux ressources ou à un conflit de hachage — les trois pointent directement vers le pool de ressources partagé plutôt que vers une erreur logique dans la configuration propre de la fonctionnalité.
Cette note s'articule autour du modèle de ressources ACL/QoS basé sur le TCAM des commutateurs Huawei série S et des commandes display acl resource / display traffic-policy applied-record, ainsi que des cas de terrain sous-jacents. Les coûts exacts en ressources par type de règle, et la liste des fonctionnalités partageant le pool UDF, varient selon la carte et la version logicielle — considérez les chiffres de 15 entrées par règle gt et de 894 entrées par port ici comme des illustrations du mécanisme, pas des constantes universelles, et confirmez les chiffres réels sur votre propre matériel avec display acl resource.
Envoyez-nous la sortie de display acl resource pour le slot concerné, plus tout texte de log ou d'alarme que vous voyez, et nous vous aiderons à trouver lequel des trois consommateurs est responsable.