A traffic-policy applies clean — display traffic-policy applied-record says success on every slot — and the traffic still does exactly what it did before you configured anything. This is what actually happens in that gap: three configuration-order problems that never throw an error, plus the view-priority rule that decides which of several applied policies wins.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The three cases behind this note all show the same applied-record output — every slot says success. None of them show up as a configuration error.
A traffic-policy — or its simpler cousin, traffic-filter — can be applied to an interface, a VLAN, or the whole device, report success on every slot, and still not do what it was written to do. Not because the syntax is wrong, but because something about the order it's evaluated in doesn't match what the person configuring it assumed.
Three specific order problems account for most of these tickets: a custom ACL whose rules don't all use the same offset, a policy left on the default match-order that lets a Layer-2 rule fire ahead of a Layer-3 one, and an earlier rule — often a leftover permit ip — that quietly catches the traffic before the rule you actually care about gets a chance to. A fourth, related issue is view priority: apply the same style of policy in more than one place, and only one of them is actually in effect.
All three are silent by design — the CLI has no reason to warn you, because from its point of view nothing is wrong.
Placing the symptom against this tree first tells you which of the three sections below is worth reading.
Diagram labels are kept in English for engineering clarity.
All three of these live inside the traffic-policy / traffic-classifier / ACL configuration itself — none of them are a routing, interface, or NAT problem hiding somewhere else. That's what makes them worth checking first, before assuming the fault sits upstream.
Same starting point every time — display traffic-policy applied-record confirms the policy is genuinely on the interface. What differs is what to check next.
This one usually doesn't fail silently — binding the classifier to the ACL fails outright, naming the exact rule that broke it.
[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 5000The policy applies without error, the next hop exists, and traffic still leaves through the wrong classifier — because two classifiers both match the same packet, and the default match order picks one you didn't expect.
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 configA traffic-policy configured with a redirect ip-nexthop behavior like this one is doing the same job as policy-based routing — if that's what you're actually trying to build, see our policy-based routing configuration note; the same match-order and view-priority rules described here apply to it directly.
The new ACL is correct, the new traffic-filter binds without error, and traffic still passes as if the deny rule was never written — because a different ACL bound earlier in the same view already caught it.
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 bothNone of these throw an error. All four show up as a policy that applied cleanly and still did the wrong thing.
SYMPTOMBinding a traffic classifier to a user-defined ACL fails outright with an Add rule failed error naming a specific rule number and interface.
CAUSEA user-defined (l4-head style) ACL matches a byte string starting at a configured offset from the Layer-4 header. Every rule in that same ACL has to use the same offset value — one rule at offset 0 and another at offset 24 is enough to make the whole classifier bind fail, not just the mismatched rule.
FIXRun display acl acl-number, compare the offset on every rule, and rewrite the mismatched rule to use the same offset as the rest.
[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.SYMPTOMA traffic-policy with two classifiers applies fine, but traffic that should hit the Layer-3 redirect keeps leaving through the Layer-2 one instead — even though the Layer-3 classifier has a lower (higher-priority-looking) precedence number.
CAUSEClassifier precedence controls display ordering and tie-breaking within the same rule type — it does not control which rule type is checked first. Under the default match-order auto, a classifier matching a Layer-2 rule (like a VLAN ID) is evaluated ahead of one matching a Layer-3 rule (like a source IP ACL), no matter what precedence either was given.
FIXIf you need classifiers evaluated in the order you actually configured them, switch the policy to match-order config explicitly — don't rely on precedence numbers to do that job.
[HUAWEI] traffic policy tpCorpApn1101 match-order configSYMPTOMA new traffic-filter with a correct deny rule binds without error, but the traffic it's supposed to block keeps passing through unaffected.
CAUSESame view, same direction, more than one traffic-filter bound at different times: the ACL bound first is evaluated first, rule by rule, in order. If that first ACL ends in a bare permit ip with no other match conditions, it catches every packet that reaches it — so a second, later-bound ACL referencing a more specific deny rule never gets a chance to match anything.
FIXRemove the earlier binding and fold its specific rules into the ACL you actually want enforced, instead of stacking a second traffic-filter behind a catch-all permit.
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 3333SYMPTOMThe same style of policy is applied in more than one view — a VLANIF interface, a physical interface, a VLAN, the global view — and only one of them is actually enforced, not necessarily the one you were editing.
CAUSEWhen policies of the same rule class are applied in multiple views on the same device, only the highest-priority view's policy takes effect. The ranking runs VLANIF interface view, then WLAN-ESS interface / SSID-profile view, then physical sub-interface / Eth-Trunk sub-interface view, then physical interface / Eth-Trunk interface / port-group view, then VLAN view, then global view. On box switches more generally, interface beats VLAN beats global.
FIXApply the policy once, at the view you actually intend to enforce it in. If it's genuinely layered across views on purpose, confirm which view is winning with display traffic-applied record before assuming the one you last edited is the one in effect.
Pulled straight from the field — the ones worth having an answer ready for.
traffic-filter and the other ACL-based simplified policies skip creating a separate classifier, behavior and policy — configuration is shorter, but matching is limited to plain ACL rules, without the richer match conditions MQC supports. The two can run at the same time: if their classifiers never match the same packet, both take effect; if they do match the same packet, the simplified ACL-based policy wins.
Only one, decided by view priority, not by which one you configured most recently. For box switches, the general ranking is interface over VLAN over global; where the same rule class is involved, VLANIF interface view outranks WLAN-ESS/SSID-profile view, which outranks physical sub-interface view, which outranks physical interface view, which outranks VLAN view, which outranks global view. Run display traffic-applied record to see which view is actually winning.
Not necessarily. The matched counter under display acl only counts packets matched against the master CPU's own copy of the ACL, not packets matched by the traffic-policy's forwarding-plane processing — and plenty of policy-matched traffic never touches the master CPU at all. If you need a real count, add a count action to the traffic behavior itself rather than reading it off display acl.
When the destination of a packet is the switch's own IP, a default internal ACL sends that traffic to the CPU for local processing, and that default ACL outranks whatever traffic-policy you've configured — so locally-destined ICMP still gets answered. This only applies to traffic actually terminating on the switch itself; traffic merely passing through is filtered by your traffic-policy exactly as configured.
On the X-series boards the priority order is: a simplified policy in a non-global view, then a full traffic-policy in a non-global view, then a simplified policy in the global view, then a full traffic-policy in the global view. In short, view scope (non-global before global) is checked before policy type, and simplified policies win ties within the same scope.
This note is built around the Huawei S-series campus switch's traffic-policy / traffic-classifier / ACL model — the S2700 through S6700, S5730 and S6730 families across V100R00x–V200R02x — and the field cases behind display traffic-policy applied-record, display acl and the documented view-priority rules. Exact priority ordering differs by switch model, as the case notes above show, so confirm your own model's ranking rather than assuming interface always beats VLAN. It doesn't cover chassis cross-slot behavior or MQC configuration on non-campus Huawei product lines in depth.
Tell us what display traffic-policy applied-record and display acl show, plus which views the policy touches, and we'll help you figure out which of these it actually is.