Une traffic-policy s'applique sans erreur — display traffic-policy applied-record indique success sur chaque slot — et le trafic se comporte exactement comme avant toute configuration. Voici ce qui se passe réellement dans cet écart : trois problèmes d'ordre de configuration qui ne génèrent jamais d'erreur, plus la règle de priorité de vue qui détermine laquelle des politiques appliquées l'emporte.
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 trois cas derrière cette note affichent tous la même sortie applied-record — chaque slot indique success. Aucun ne se manifeste comme une erreur de configuration.
Une traffic-policy — ou sa cousine plus simple, traffic-filter — peut être appliquée à une interface, un VLAN ou l'ensemble de l'équipement, afficher success sur chaque slot, et pourtant ne pas faire ce pour quoi elle a été écrite. Non pas parce que la syntaxe est fausse, mais parce que l'ordre dans lequel elle est évaluée ne correspond pas à ce que la personne qui l'a configurée supposait.
Trois problèmes d'ordre précis expliquent la plupart de ces tickets : une ACL personnalisée dont les règles n'utilisent pas toutes le même décalage, une politique laissée sur l'ordre de correspondance par défaut qui laisse une règle de couche 2 s'exécuter avant une règle de couche 3, et une règle antérieure — souvent un permit ip oublié — qui capture discrètement le trafic avant que la règle qui vous intéresse vraiment n'ait sa chance. Un quatrième problème connexe est la priorité de vue : appliquer le même type de politique à plusieurs endroits, et seul l'un d'eux est réellement en vigueur.
Les trois sont silencieuses par conception — la CLI n'a aucune raison de vous avertir, car de son point de vue, rien ne va mal.
Placer d'abord le symptôme face à cet arbre indique laquelle des trois sections ci-dessous mérite d'être lue.
Les légendes du schéma restent en anglais pour la clarté technique.
Ces trois cas se situent tous à l'intérieur de la configuration traffic-policy / traffic-classifier / ACL elle-même — aucun n'est un problème de routage, d'interface ou de NAT caché ailleurs. C'est ce qui justifie de les vérifier en premier, avant de supposer que la panne se situe en amont.
Même point de départ à chaque fois — display traffic-policy applied-record confirme que la politique est réellement sur l'interface. Ce qui diffère, c'est la suite à vérifier.
Celle-ci n'échoue généralement pas en silence — la liaison du classificateur à l'ACL échoue franchement, en nommant la règle exacte responsable.
[HUAWEI] acl number 5000
[HUAWEI-acl-user-5000] rule 5 permit l4-head 0x00000868 0x0000ffff 0
[HUAWEI-acl-user-5000] rule 10 permit l4-head 0x00060000 0x00ff0000 24
[HUAWEI] quit
[HUAWEI] traffic classifier c1 operator or
[HUAWEI-classifier-c1] if-match acl 5000
[HUAWEI-classifier-c1] quit
[HUAWEI] traffic behavior b1
[HUAWEI-behavior-b1] redirect interface gigabitethernet0/0/24
[HUAWEI-behavior-b1] quit
[HUAWEI] traffic policy p5000
[HUAWEI-trafficpolicy-p5000] classifier c1 behavior b1
Error:Add rule failed, slot 0, policy p5000, class c1, behavior b1 acl 5000, rule 10, on interface
GigabitEthernet0/0/21.
// rule 5 uses offset 0, rule 10 uses offset 24 -- same ACL, different offsets -> bind fails
[HUAWEI] display acl 5000La politique s'applique sans erreur, le prochain saut existe, et le trafic sort quand même par le mauvais classificateur — parce que deux classificateurs correspondent tous deux au même paquet, et l'ordre de correspondance par défaut en choisit un que vous n'attendiez pas.
acl number 3100
rule 1 permit ip source 10.25.8.10 0
#
traffic classifier tcCorpApnRadiusUp precedence 100
if-match acl 3100
#
traffic classifier tcCorpApnSvr1101 precedence 1101
if-match vlan-id 1101
#
traffic behavior bCorpApnRadius1101
redirect vpn-instance CorpApn1101 ip-nexthop 192.168.15.20
#
traffic behavior bCorpApnSvr1101
redirect vpn-instance CorpApn1101 ip-nexthop 192.168.15.10
#
traffic policy tpCorpApn1101
classifier tcCorpApnRadiusUp behavior bCorpApnRadius1101
classifier tcCorpApnSvr1101 behavior bCorpApnSvr1101
#
vlan 1101
traffic-policy tpCorpApn1101 inbound
<HUAWEI> display traffic-policy applied-record tpCorpApn1101
*vlan 1101
traffic-policy tpCorpApn1101 inbound
slot 1 : success
// applied-record says success -- this is not an apply failure
<HUAWEI> display arp interface vlanif 1501
// once the next hop resolves, traffic still leaves toward 192.168.15.10, not .20:
// the packet matches BOTH tcCorpApnRadiusUp (Layer 3) and tcCorpApnSvr1101 (Layer 2)
// match-order auto (the default) lets the Layer-2 classifier win regardless of precedence
[HUAWEI] traffic policy tpCorpApn1101 match-order configUne traffic-policy configurée avec un comportement redirect ip-nexthop comme celle-ci fait le même travail que le routage basé sur des politiques — si c'est ce que vous essayez réellement de construire, consultez notre note sur la configuration du routage basé sur des politiques ; les mêmes règles de match-order et de priorité de vue décrites ici s'y appliquent directement.
La nouvelle ACL est correcte, le nouveau traffic-filter se lie sans erreur, et le trafic passe quand même comme si la règle deny n'avait jamais été écrite — parce qu'une autre ACL liée plus tôt dans la même vue l'a déjà capturé.
acl number 3334
rule deny ip source 192.168.112.0 0.0.0.255 destination 192.168.121.0 0.0.0.255
// bound alone on VLANIF112 inbound, this works exactly as expected
// bound the same way, it does NOT work, because this was already configured first:
traffic-filter vlan 112 inbound acl 3333
traffic-filter vlan 112 inbound acl 3334
acl number 3333
rule 1 deny tcp source-port eq 445 destination-port eq 445
rule 2 deny udp source-port eq 445 destination-port eq 445
rule 3 permit ip
// rule 3 permit ip matches everything else first -- acl 3334 is never reached
[HUAWEI] undo traffic-filter vlan 112 inbound acl 3333
// then fold acl 3333's two deny rules into acl 3334 instead of running bothAucun d'eux ne génère d'erreur. Les quatre se manifestent par une politique appliquée proprement qui fait pourtant la mauvaise chose.
SYMPTÔMELa liaison d'un classificateur de trafic à une ACL personnalisée échoue franchement avec une erreur Add rule failed nommant un numéro de règle et une interface précis.
CAUSEUne ACL personnalisée (de type l4-head) fait correspondre une chaîne d'octets à partir d'un décalage configuré depuis l'en-tête de couche 4. Chaque règle de cette même ACL doit utiliser la même valeur de décalage — une règle à un décalage de 0 et une autre à 24 suffit à faire échouer toute la liaison du classificateur, pas seulement la règle en désaccord.
SOLUTIONExécutez display acl acl-number, comparez le décalage de chaque règle, et réécrivez la règle discordante pour utiliser le même décalage que les autres.
[HUAWEI-acl-user-5000] rule 5 permit l4-head 0x00000868 0x0000ffff 0
[HUAWEI-acl-user-5000] rule 10 permit l4-head 0x00060000 0x00ff0000 24
Error:Add rule failed, slot 0, policy p5000, class c1, behavior b1 acl 5000, rule 10, on interface GigabitEthernet0/0/21.SYMPTÔMEUne traffic-policy avec deux classificateurs s'applique correctement, mais le trafic qui devrait suivre la redirection de couche 3 continue de sortir par celle de couche 2 — même si le classificateur de couche 3 a un numéro de précédence plus bas (paraissant plus prioritaire).
CAUSELa précédence du classificateur contrôle l'ordre d'affichage et le départage au sein du même type de règle — elle ne contrôle pas quel type de règle est vérifié en premier. Sous le match-order auto par défaut, un classificateur correspondant à une règle de couche 2 (comme un VLAN ID) est évalué avant celui correspondant à une règle de couche 3 (comme une ACL d'IP source), quelle que soit la précédence attribuée.
SOLUTIONSi vous avez besoin que les classificateurs soient évalués dans l'ordre où vous les avez réellement configurés, basculez explicitement la politique en match-order config — ne comptez pas sur les numéros de précédence pour ce faire.
[HUAWEI] traffic policy tpCorpApn1101 match-order configSYMPTÔMEUn nouveau traffic-filter avec une règle deny correcte se lie sans erreur, mais le trafic qu'il est censé bloquer continue de passer sans être affecté.
CAUSEMême vue, même direction, plusieurs traffic-filter liés à des moments différents : l'ACL liée en premier est évaluée en premier, règle par règle, dans l'ordre. Si cette première ACL se termine par un simple permit ip sans autre condition de correspondance, elle capture chaque paquet qui l'atteint — de sorte qu'une seconde ACL liée plus tard, référençant une règle deny plus spécifique, n'a jamais la chance de correspondre à quoi que ce soit.
SOLUTIONSupprimez la liaison antérieure et intégrez ses règles spécifiques dans l'ACL que vous voulez réellement appliquer, plutôt que d'empiler un second traffic-filter derrière un permit attrape-tout.
acl number 3333
rule 1 deny tcp source-port eq 445 destination-port eq 445
rule 2 deny udp source-port eq 445 destination-port eq 445
rule 3 permit ip
// rule 3 catches everything -- a later acl 3334 bound on the same view never fires
[HUAWEI] undo traffic-filter vlan 112 inbound acl 3333SYMPTÔMELe même type de politique est appliqué dans plusieurs vues — une interface VLANIF, une interface physique, un VLAN, la vue globale — et une seule d'entre elles est réellement appliquée, pas forcément celle que vous étiez en train de modifier.
CAUSELorsque des politiques de la même classe de règles sont appliquées dans plusieurs vues du même équipement, seule la politique de la vue la plus prioritaire s'applique. Le classement est : vue interface VLANIF, puis vue interface WLAN-ESS / profil SSID, puis vue sous-interface physique / sous-interface Eth-Trunk, puis vue interface physique / interface Eth-Trunk / groupe de ports, puis vue VLAN, puis vue globale. Plus généralement sur les commutateurs boîtiers, interface l'emporte sur VLAN qui l'emporte sur global.
SOLUTIONAppliquez la politique une seule fois, dans la vue où vous voulez réellement qu'elle s'applique. Si elle est réellement superposée intentionnellement sur plusieurs vues, confirmez laquelle l'emporte avec display traffic-applied record avant de supposer que celle éditée en dernier est celle en vigueur.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
traffic-filter et les autres politiques simplifiées basées sur ACL évitent de créer un classificateur, un comportement et une politique séparés — la configuration est plus courte, mais la correspondance se limite aux règles ACL simples, sans les conditions de correspondance plus riches prises en charge par MQC. Les deux peuvent fonctionner simultanément : si leurs classificateurs ne correspondent jamais au même paquet, les deux s'appliquent ; s'ils correspondent au même paquet, la politique simplifiée basée sur ACL l'emporte.
Une seule, décidée par la priorité de vue, pas par celle que vous avez configurée le plus récemment. Pour les commutateurs boîtiers, le classement général est interface avant VLAN avant global ; lorsque la même classe de règles est impliquée, la vue interface VLANIF prime sur la vue WLAN-ESS/profil SSID, qui prime sur la vue sous-interface physique, qui prime sur la vue interface physique, qui prime sur la vue VLAN, qui prime sur la vue globale. Exécutez display traffic-applied record pour voir laquelle l'emporte réellement.
Pas nécessairement. Le compteur matched sous display acl ne compte que les paquets correspondant à la propre copie de l'ACL du CPU maître, pas les paquets correspondant au traitement du plan de transfert de la traffic-policy — et une grande partie du trafic correspondant à la politique ne touche jamais le CPU maître. Si vous avez besoin d'un compte réel, ajoutez une action count au comportement de trafic lui-même plutôt que de le lire via display acl.
Lorsque la destination d'un paquet est la propre IP du commutateur, une ACL interne par défaut envoie ce trafic au CPU pour un traitement local, et cette ACL par défaut prime sur toute traffic-policy que vous avez configurée — l'ICMP destiné localement reçoit donc toujours une réponse. Cela ne s'applique qu'au trafic se terminant réellement sur le commutateur lui-même ; le trafic simplement de passage est filtré exactement selon votre traffic-policy.
Sur les cartes de la série X, l'ordre de priorité est : une politique simplifiée en vue non globale, puis une traffic-policy complète en vue non globale, puis une politique simplifiée en vue globale, puis une traffic-policy complète en vue globale. En bref, la portée de vue (non globale avant globale) est vérifiée avant le type de politique, et les politiques simplifiées l'emportent en cas d'égalité dans la même portée.
Cette note s'appuie sur le modèle traffic-policy / traffic-classifier / ACL des commutateurs de campus Huawei série S — les familles S2700 à S6700, S5730 et S6730 sur V100R00x–V200R02x — et sur les cas de terrain derrière display traffic-policy applied-record, display acl et les règles de priorité de vue documentées. L'ordre de priorité exact diffère selon le modèle de commutateur, comme le montrent les cas ci-dessus ; confirmez donc le classement de votre propre modèle plutôt que de supposer qu'interface l'emporte toujours sur VLAN. Elle ne couvre pas en profondeur le comportement inter-slots des châssis ni la configuration MQC sur les gammes Huawei hors campus.
Dites-nous ce que montrent display traffic-policy applied-record et display acl, ainsi que les vues touchées par la politique, et nous vous aiderons à déterminer laquelle de ces causes s'applique réellement.