Una traffic-policy se aplica sin errores — display traffic-policy applied-record indica success en cada slot — y el tráfico se comporta exactamente igual que antes de configurar nada. Esto es lo que realmente ocurre en ese espacio: tres problemas de orden de configuración que nunca generan un error, más la regla de prioridad de vista que decide cuál de varias políticas aplicadas gana.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Los tres casos detrás de esta nota muestran la misma salida de applied-record — cada slot indica success. Ninguno se presenta como un error de configuración.
Una traffic-policy — o su prima más simple, traffic-filter — puede aplicarse a una interfaz, una VLAN o todo el equipo, mostrar success en cada slot, y aun así no hacer lo que se escribió para que hiciera. No porque la sintaxis esté mal, sino porque el orden en que se evalúa no coincide con lo que la persona que la configuró asumió.
Tres problemas de orden específicos explican la mayoría de estos casos: una ACL personalizada cuyas reglas no usan todas el mismo offset, una política dejada en el orden de coincidencia predeterminado que permite que una regla de capa 2 se dispare antes que una de capa 3, y una regla anterior — a menudo un permit ip olvidado — que atrapa silenciosamente el tráfico antes de que la regla que realmente le importa tenga oportunidad. Un cuarto problema relacionado es la prioridad de vista: aplicar el mismo tipo de política en más de un lugar, y solo una de ellas está realmente vigente.
Las tres son silenciosas por diseño — la CLI no tiene motivo para advertirle, porque desde su punto de vista nada está mal.
Ubicar primero el síntoma frente a este árbol indica cuál de las tres secciones siguientes vale la pena leer.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Los tres casos residen dentro de la propia configuración de traffic-policy / traffic-classifier / ACL — ninguno es un problema de enrutamiento, interfaz o NAT oculto en otro lugar. Por eso vale la pena revisarlos primero, antes de suponer que la falla está más arriba.
Mismo punto de partida siempre — display traffic-policy applied-record confirma que la política realmente está en la interfaz. Lo que cambia es qué revisar a continuación.
Este caso generalmente no falla en silencio — vincular el clasificador a la ACL falla directamente, señalando la regla exacta 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 política se aplica sin errores, el siguiente salto existe, y el tráfico igual sale por el clasificador equivocado — porque dos clasificadores coinciden con el mismo paquete, y el orden de coincidencia predeterminado elige uno que usted no esperaba.
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 configUna traffic-policy configurada con un comportamiento redirect ip-nexthop como este hace el mismo trabajo que el enrutamiento basado en políticas — si eso es lo que realmente intenta construir, consulte nuestra nota sobre configuración de enrutamiento basado en políticas; las mismas reglas de match-order y prioridad de vista descritas aquí se le aplican directamente.
La nueva ACL es correcta, el nuevo traffic-filter se vincula sin errores, y el tráfico sigue pasando como si la regla deny nunca se hubiera escrito — porque otra ACL vinculada antes en la misma vista ya lo atrapó.
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 bothNinguno de estos genera un error. Los cuatro se manifiestan como una política aplicada limpiamente que aun así hace lo incorrecto.
SÍNTOMAVincular un clasificador de tráfico a una ACL definida por el usuario falla directamente con un error Add rule failed que nombra un número de regla e interfaz específicos.
CAUSAUna ACL definida por el usuario (tipo l4-head) coincide con una cadena de bytes a partir de un offset configurado desde el encabezado de capa 4. Cada regla de esa misma ACL debe usar el mismo valor de offset — una regla con offset 0 y otra con 24 basta para que falle todo el enlace del clasificador, no solo la regla discordante.
SOLUCIÓNEjecute display acl acl-number, compare el offset de cada regla, y reescriba la regla discordante para usar el mismo offset que las demás.
[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.SÍNTOMAUna traffic-policy con dos clasificadores se aplica correctamente, pero el tráfico que debería seguir la redirección de capa 3 sigue saliendo por la de capa 2 — aunque el clasificador de capa 3 tenga un número de precedencia más bajo (que parece de mayor prioridad).
CAUSALa precedencia del clasificador controla el orden de visualización y el desempate dentro del mismo tipo de regla — no controla qué tipo de regla se verifica primero. Bajo el match-order auto predeterminado, un clasificador que coincide con una regla de capa 2 (como un VLAN ID) se evalúa antes que uno que coincide con una regla de capa 3 (como una ACL de IP origen), sin importar la precedencia asignada a cada uno.
SOLUCIÓNSi necesita que los clasificadores se evalúen en el orden en que realmente los configuró, cambie explícitamente la política a match-order config — no confíe en los números de precedencia para eso.
[HUAWEI] traffic policy tpCorpApn1101 match-order configSÍNTOMAUn nuevo traffic-filter con una regla deny correcta se vincula sin errores, pero el tráfico que se supone debe bloquear sigue pasando sin verse afectado.
CAUSAMisma vista, misma dirección, más de un traffic-filter vinculado en momentos distintos: la ACL vinculada primero se evalúa primero, regla por regla, en orden. Si esa primera ACL termina en un simple permit ip sin otras condiciones de coincidencia, atrapa cada paquete que la alcanza — así que una segunda ACL vinculada después, que referencia una regla deny más específica, nunca tiene oportunidad de coincidir con nada.
SOLUCIÓNElimine la vinculación anterior e incorpore sus reglas específicas en la ACL que realmente desea aplicar, en lugar de apilar un segundo traffic-filter detrás de un permit que lo atrapa todo.
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 3333SÍNTOMAEl mismo tipo de política se aplica en más de una vista — una interfaz VLANIF, una interfaz física, una VLAN, la vista global — y solo una de ellas está realmente vigente, no necesariamente la que estaba editando.
CAUSACuando se aplican políticas de la misma clase de regla en varias vistas del mismo equipo, solo se aplica la política de la vista de mayor prioridad. El orden es: vista de interfaz VLANIF, luego vista de interfaz WLAN-ESS / perfil SSID, luego vista de subinterfaz física / subinterfaz Eth-Trunk, luego vista de interfaz física / interfaz Eth-Trunk / grupo de puertos, luego vista de VLAN, luego vista global. De forma más general en switches de caja, interfaz gana a VLAN, que gana a global.
SOLUCIÓNAplique la política una sola vez, en la vista donde realmente pretende que se aplique. Si está deliberadamente en capas sobre varias vistas, confirme cuál está ganando con display traffic-applied record antes de suponer que la última editada es la vigente.
Extraídas directamente del campo — las que vale la pena tener una respuesta lista.
traffic-filter y las demás políticas simplificadas basadas en ACL evitan crear un clasificador, comportamiento y política por separado — la configuración es más corta, pero la coincidencia se limita a reglas ACL simples, sin las condiciones de coincidencia más ricas que admite MQC. Ambas pueden ejecutarse a la vez: si sus clasificadores nunca coinciden con el mismo paquete, ambas surten efecto; si coinciden con el mismo paquete, gana la política simplificada basada en ACL.
Solo una, decidida por la prioridad de vista, no por cuál configuró más recientemente. Para switches de caja, el orden general es interfaz sobre VLAN sobre global; cuando se trata de la misma clase de regla, la vista de interfaz VLANIF supera a la vista WLAN-ESS/perfil SSID, que supera a la vista de subinterfaz física, que supera a la vista de interfaz física, que supera a la vista de VLAN, que supera a la vista global. Ejecute display traffic-applied record para ver cuál está ganando realmente.
No necesariamente. El contador matched bajo display acl solo cuenta paquetes coincidentes con la copia propia de la ACL del CPU maestro, no paquetes coincidentes por el procesamiento del plano de reenvío de la traffic-policy — y gran parte del tráfico coincidente con la política nunca toca el CPU maestro. Si necesita un conteo real, agregue una acción count al propio comportamiento de tráfico en lugar de leerlo de display acl.
Cuando el destino de un paquete es la propia IP del switch, una ACL interna predeterminada envía ese tráfico a la CPU para procesamiento local, y esa ACL predeterminada supera a cualquier traffic-policy que haya configurado — así que el ICMP destinado localmente sigue recibiendo respuesta. Esto solo aplica al tráfico que realmente termina en el propio switch; el tráfico que solo pasa por él se filtra exactamente según su traffic-policy.
En las tarjetas serie X, el orden de prioridad es: una política simplificada en una vista no global, luego una traffic-policy completa en una vista no global, luego una política simplificada en la vista global, luego una traffic-policy completa en la vista global. En resumen, el alcance de vista (no global antes que global) se verifica antes que el tipo de política, y las políticas simplificadas ganan los empates dentro del mismo alcance.
Esta nota se basa en el modelo traffic-policy / traffic-classifier / ACL del switch de campus Huawei serie S — las familias S2700 a S6700, S5730 y S6730 en V100R00x–V200R02x — y en los casos de campo detrás de display traffic-policy applied-record, display acl y las reglas de prioridad de vista documentadas. El orden de prioridad exacto difiere según el modelo de switch, como muestran los casos anteriores, así que confirme el orden de su propio modelo en lugar de suponer que interfaz siempre gana a VLAN. No cubre en profundidad el comportamiento entre slots de chasis ni la configuración MQC en líneas de productos Huawei que no son de campus.
Cuéntenos qué muestran display traffic-policy applied-record y display acl, además de qué vistas toca la política, y le ayudamos a determinar cuál de estos casos es realmente.