traffic-filter Application and Matching Order

traffic-filter Application and Matching Order

Quick Answer: Create the ACL first, then under interface view apply traffic-filter inbound acl <id> or traffic-filter outbound acl <id>. Traffic is checked against rules from lowest rule ID upward; first match wins. Packets that match no rule are implicitly denied when the ACL is used as a packet filter. Direction and attachment point matter as much as the rule text.

Writing a correct ACL is only half the job. HCIA-Datacom tests whether you can attach that ACL so it sees the intended packets, whether you understand inbound vs outbound, and whether you can predict outcomes when multiple rules exist. This section is pure operational skill: apply, order, direction, and verify.

The application command family

On Huawei VRP, interface packet filtering commonly uses traffic-filter:

[Huawei] interface GigabitEthernet0/0/1
[Huawei-GigabitEthernet0/0/1] traffic-filter inbound acl 3000

or outbound:

[Huawei-GigabitEthernet0/0/1] traffic-filter outbound acl 2000

Cisco mental models use ip access-group … in/out. On the exam, prefer the Huawei form traffic-filter inbound|outbound acl …. Distractors that look like IOS access-group wording are wrong for VRP.

Remove a filter with the undo pattern in the same view:

[Huawei-GigabitEthernet0/0/1] undo traffic-filter inbound acl 3000

(Exact undo syntax can include the same direction and ACL identity you applied—match what you configured.)

Inbound vs outbound: draw the arrow

Direction is relative to the interface, not relative to “the user” in the abstract.

Worked scenario A — block a bad source entering a WAN edge

Router R1, interface GE0/0/0 faces the untrusted WAN. You want to drop packets from 198.51.100.50 as soon as they hit the WAN interface.

1. ACL 2000: rule 5 deny source 198.51.100.50 0 then appropriate permits for the rest of your policy.
2. Apply traffic-filter inbound acl 2000 on GE0/0/0.

Why inbound? The bad packets are entering GE0/0/0 from the WAN. Outbound on that interface would examine traffic leaving toward the WAN, which is the opposite direction.

Worked scenario B — prevent internal servers from initiating to a guest VLAN

Interface VLANIF40 is the gateway for guest users. You want to stop certain server subnets from sending traffic out toward guests.

Applying a filter outbound on VLANIF40 examines packets the router/switch is emitting into VLAN 40. Applying inbound on VLANIF40 examines traffic coming from guests into the device. Those are different security goals. Always restate: “Am I filtering packets that arrive here, or packets that leave here?”

Worked scenario C — filter on the wrong device

ACL 3001 perfectly describes “users in 10.10.10.0/24 may only reach TCP 443 on 10.20.20.10.” You apply it inbound on a core interface that never carries that flow because users are routed via a different path. Result: zero effect (or you filter unrelated traffic). HCIA items sometimes include a small topology; pick the interface that actually sees the path in the stated direction.

Matching order in depth

When a packet hits an interface with an applied ACL:

1. Device selects the ACL bound for that direction.
2. Rules are checked in ascending rule-id order (top-down list order).
3. First match returns permit or deny and stops.
4. No match → implicit deny for traffic-filter style packet filtering (standard HCIA teaching).

Implications for design

Example ACL 3002 applied inbound:

rule 5 permit tcp destination-port eq 22
rule 10 deny tcp destination-port eq 23
rule 15 permit ip

• SSH (TCP 22) matches rule 5 → permitted.
• Telnet (TCP 23) matches rule 10 → denied.
• HTTPS (TCP 443) skips 5 and 10, matches rule 15 → permitted.
• If rule 15 were missing, HTTPS would hit implicit deny and drop—even though no deny mentioned 443.

That last bullet is an exam favorite: students look for an explicit deny and miss the implicit deny at the end.

Where to place the ACL: source vs destination thinking

Industry lore says “place extended ACLs close to the source” and “standard ACLs close to the destination.” Translate that to Huawei terms:

Example: basic ACL denies source 10.1.1.0/24. If applied inbound on the users’ access gateway toward the whole campus, users lose all destinations. If the goal is only to protect a single data-center segment, apply nearer that segment (or upgrade to an advanced ACL that includes destination).

Interaction with routing and interface state

• An ACL does not replace routing. Packets must still have a valid FIB path; the filter only adds a permit/deny gate on a specific interface direction.
• Admin-down interfaces do not pass traffic; troubleshooting “ACL broken” sometimes is simply shutdown.
• Applying filters on SVI/VLANIF interfaces is common for inter-VLAN controls on Layer 3 switches—same inbound/outbound logic relative to the VLANIF.
• Some platforms support ACL application in other features (NAT, QoS). Those are not always drop filters. nat outbound 2000 means “use ACL 2000 to select interesting traffic for NAT,” not “deny unmatched.” Keep feature context straight on multi-topic questions.

Configuration sequence that avoids self-lockout

When filtering remote management paths:

1. Prefer console access while editing.
2. Write the ACL offline in a notepad: specific permits for your management source first.
3. Create the ACL on the device.
4. Apply traffic-filter carefully on the correct direction.
5. Test from the management host immediately.
6. save only after validation.

A common outage pattern: deny ip or implicit deny without permitting the engineer’s SSH source, applied inbound on the only path to the device. Prevention is explicit management permits and out-of-band console.

Verification and troubleshooting checklist

[Huawei] display acl 3000
[Huawei] display current-configuration interface GigabitEthernet0/0/1
[Huawei] display traffic-filter applied-record

(Exact support for applied-record style commands can vary by platform/version; conceptually you must confirm binding, direction, and rule hits.)

Troubleshooting table:

Always re-read the topology: which interface, which way is the packet moving, which rule matches first.

Side-by-side: build → apply → match

Exam traps

• Using Cisco ip access-group syntax instead of traffic-filter.
• Choosing outbound when the stem describes traffic entering the interface (or the reverse).
• Believing unmatched packets are permitted by default on a filter ACL.
• Assuming all rules are evaluated and the “best” match wins—first match wins only.
• Applying a correct ACL on an interface that never sees the flow.
• Confusing NAT ACL interest matching with traffic-filter drop behavior.

Mini lab script (mental)

1. Host A 192.168.1.10 must reach Server 192.168.2.10 TCP 80 only.
2. ACL 3005: permit tcp from A’s subnet to server port 80; deny other IP from that subnet (or rely on implicit deny after a single permit if policy is that tight).
3. Apply inbound on the interface facing Host A or outbound on the interface facing the server—both can work if they see the flow; pick the design that matches the question’s diagram.
4. Predict: TCP 80 succeeds; TCP 22 fails; ICMP fails unless permitted.

If you can narrate direction, first match, and implicit deny for that lab without hesitation, you are exam-ready for traffic-filter items.