Uma traffic-policy é aplicada sem erros — display traffic-policy applied-record mostra success em cada slot — e o tráfego se comporta exatamente como antes de qualquer configuração. Isto é o que realmente acontece nessa lacuna: três problemas de ordem de configuração que nunca geram erro, além da regra de prioridade de view que decide qual das políticas aplicadas prevalece.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Os três casos por trás desta nota mostram a mesma saída de applied-record — cada slot indica success. Nenhum deles aparece como um erro de configuração.
Uma traffic-policy — ou sua prima mais simples, traffic-filter — pode ser aplicada a uma interface, uma VLAN ou o equipamento inteiro, mostrar success em cada slot, e mesmo assim não fazer o que foi escrita para fazer. Não porque a sintaxe esteja errada, mas porque a ordem em que é avaliada não corresponde ao que quem a configurou presumiu.
Três problemas de ordem específicos respondem pela maioria desses chamados: uma ACL personalizada cujas regras não usam todas o mesmo offset, uma política deixada na ordem de correspondência padrão que deixa uma regra de camada 2 disparar antes de uma de camada 3, e uma regra anterior — muitas vezes um permit ip esquecido — que captura silenciosamente o tráfego antes que a regra que realmente importa tenha chance. Um quarto problema relacionado é a prioridade de view: aplicar o mesmo tipo de política em mais de um lugar, e apenas uma delas está realmente em vigor.
As três são silenciosas por design — a CLI não tem motivo para avisar, porque do ponto de vista dela nada está errado.
Colocar primeiro o sintoma diante desta árvore indica qual das três seções abaixo vale a pena ler.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Os três casos residem dentro da própria configuração de traffic-policy / traffic-classifier / ACL — nenhum é um problema de roteamento, interface ou NAT escondido em outro lugar. É por isso que vale a pena verificá-los primeiro, antes de supor que a falha está a montante.
Mesmo ponto de partida sempre — display traffic-policy applied-record confirma que a política está realmente na interface. O que muda é o que verificar a seguir.
Este geralmente não falha em silêncio — vincular o classificador à ACL falha diretamente, apontando a regra exata responsável.
[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 5000A política se aplica sem erros, o próximo salto existe, e o tráfego ainda sai pelo classificador errado — porque dois classificadores correspondem ao mesmo pacote, e a ordem de correspondência padrão escolhe um que você não esperava.
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 configUma traffic-policy configurada com um comportamento redirect ip-nexthop como este faz o mesmo trabalho que o roteamento baseado em políticas — se é isso que você realmente está tentando construir, veja nossa nota sobre configuração de roteamento baseado em políticas; as mesmas regras de match-order e prioridade de view descritas aqui se aplicam a ele diretamente.
A nova ACL está correta, o novo traffic-filter é vinculado sem erros, e o tráfego ainda passa como se a regra deny nunca tivesse sido escrita — porque outra ACL vinculada antes na mesma view já a capturou.
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 bothNenhum deles gera erro. Todos os quatro se manifestam como uma política aplicada de forma limpa que ainda assim faz a coisa errada.
SINTOMAVincular um classificador de tráfego a uma ACL definida pelo usuário falha diretamente com um erro Add rule failed que nomeia um número de regra e interface específicos.
CAUSAUma ACL definida pelo usuário (tipo l4-head) corresponde a uma sequência de bytes a partir de um offset configurado do cabeçalho de camada 4. Cada regra nessa mesma ACL precisa usar o mesmo valor de offset — uma regra com offset 0 e outra com 24 já é suficiente para falhar toda a vinculação do classificador, não apenas a regra divergente.
SOLUÇÃOExecute display acl acl-number, compare o offset de cada regra, e reescreva a regra divergente para usar o mesmo offset das demais.
[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.SINTOMAUma traffic-policy com dois classificadores se aplica corretamente, mas o tráfego que deveria seguir o redirecionamento de camada 3 continua saindo pelo de camada 2 — mesmo que o classificador de camada 3 tenha um número de precedência menor (que parece de maior prioridade).
CAUSAA precedência do classificador controla a ordem de exibição e o desempate dentro do mesmo tipo de regra — não controla qual tipo de regra é verificado primeiro. Sob o match-order auto padrão, um classificador que corresponde a uma regra de camada 2 (como um VLAN ID) é avaliado antes de um que corresponde a uma regra de camada 3 (como uma ACL de IP de origem), independentemente da precedência atribuída a cada um.
SOLUÇÃOSe você precisa que os classificadores sejam avaliados na ordem em que realmente os configurou, mude explicitamente a política para match-order config — não confie nos números de precedência para isso.
[HUAWEI] traffic policy tpCorpApn1101 match-order configSINTOMAUm novo traffic-filter com uma regra deny correta é vinculado sem erros, mas o tráfego que deveria bloquear continua passando sem ser afetado.
CAUSAMesma view, mesma direção, mais de um traffic-filter vinculado em momentos diferentes: a ACL vinculada primeiro é avaliada primeiro, regra por regra, em ordem. Se essa primeira ACL termina em um simples permit ip sem outras condições de correspondência, ela captura todo pacote que a alcança — então uma segunda ACL vinculada depois, referenciando uma regra deny mais específica, nunca tem chance de corresponder a nada.
SOLUÇÃORemova a vinculação anterior e incorpore suas regras específicas na ACL que você realmente quer aplicar, em vez de empilhar um segundo traffic-filter atrás de um permit que pega tudo.
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 3333SINTOMAO mesmo tipo de política é aplicado em mais de uma view — uma interface VLANIF, uma interface física, uma VLAN, a view global — e apenas uma delas está realmente em vigor, não necessariamente a que você estava editando.
CAUSAQuando políticas da mesma classe de regra são aplicadas em várias views do mesmo equipamento, apenas a política da view de maior prioridade entra em vigor. A ordem é: view de interface VLANIF, depois view de interface WLAN-ESS / perfil SSID, depois view de subinterface física / subinterface Eth-Trunk, depois view de interface física / interface Eth-Trunk / grupo de portas, depois view de VLAN, depois view global. De forma mais geral em switches de caixa, interface vence VLAN, que vence global.
SOLUÇÃOAplique a política uma única vez, na view onde você realmente pretende que ela vigore. Se estiver deliberadamente em camadas em várias views, confirme qual está vencendo com display traffic-applied record antes de supor que a última editada é a que está em vigor.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
traffic-filter e as demais políticas simplificadas baseadas em ACL evitam criar um classificador, comportamento e política separados — a configuração é mais curta, mas a correspondência se limita a regras ACL simples, sem as condições de correspondência mais ricas que o MQC suporta. As duas podem rodar ao mesmo tempo: se seus classificadores nunca corresponderem ao mesmo pacote, ambas entram em vigor; se corresponderem ao mesmo pacote, a política simplificada baseada em ACL prevalece.
Apenas uma, decidida pela prioridade de view, não por qual você configurou mais recentemente. Para switches de caixa, a ordem geral é interface sobre VLAN sobre global; quando a mesma classe de regra está envolvida, a view de interface VLANIF supera a view WLAN-ESS/perfil SSID, que supera a view de subinterface física, que supera a view de interface física, que supera a view de VLAN, que supera a view global. Execute display traffic-applied record para ver qual está realmente vencendo.
Não necessariamente. O contador matched em display acl só conta pacotes correspondidos contra a própria cópia da ACL na CPU mestre, não pacotes correspondidos pelo processamento do plano de encaminhamento da traffic-policy — e boa parte do tráfego correspondido pela política nunca toca a CPU mestre. Se precisar de uma contagem real, adicione uma ação count ao próprio comportamento de tráfego em vez de ler em display acl.
Quando o destino de um pacote é o próprio IP do switch, uma ACL interna padrão envia esse tráfego para a CPU para processamento local, e essa ACL padrão supera qualquer traffic-policy que você tenha configurado — então o ICMP destinado localmente ainda recebe resposta. Isso só se aplica ao tráfego que realmente termina no próprio switch; o tráfego que apenas passa por ele é filtrado exatamente conforme sua traffic-policy.
Nas placas da série X, a ordem de prioridade é: uma política simplificada em uma view não global, depois uma traffic-policy completa em uma view não global, depois uma política simplificada na view global, depois uma traffic-policy completa na view global. Em resumo, o escopo de view (não global antes de global) é verificado antes do tipo de política, e políticas simplificadas vencem empates dentro do mesmo escopo.
Esta nota se baseia no modelo traffic-policy / traffic-classifier / ACL do switch de campus Huawei série S — as famílias S2700 a S6700, S5730 e S6730 em V100R00x–V200R02x — e nos casos de campo por trás de display traffic-policy applied-record, display acl e as regras de prioridade de view documentadas. A ordem de prioridade exata difere conforme o modelo do switch, como mostram os casos acima, então confirme a ordem do seu próprio modelo em vez de supor que interface sempre vence VLAN. Não cobre em profundidade o comportamento entre slots de chassi nem a configuração MQC em linhas de produtos Huawei fora de campus.
Conte-nos o que display traffic-policy applied-record e display acl mostram, além de quais views a política toca, e ajudamos você a determinar qual desses casos realmente é.