Basic and Advanced ACLs

Basic and Advanced ACLs

Quick Answer: On Huawei VRP, basic ACLs are numbered 2000–2999 and match source IP only. Advanced ACLs are numbered 3000–3999 and can match source, destination, protocol, and TCP/UDP ports. Rules are evaluated top-down by rule ID; first match wins. Wildcard bits of 0 must match; bits of 1 are don’t-care—the inverse of how you read a subnet mask.

Access Control Lists (ACLs) are the workhorse of traffic classification on Huawei routers and Layer 3 switches. HCIA-Datacom expects you to choose the correct ACL type for a requirement, write legal match criteria, interpret wildcard masks, and predict what happens when a packet does not match any rule. Later sections apply those ACLs with traffic-filter and combine identity control with AAA; this section builds the ACL objects themselves.

Why ACLs exist in campus and WAN designs

An ACL is a named or numbered ordered list of classification rules. Each rule answers two questions for a candidate packet:

1. Does this packet match the criteria?
2. If yes, should the action be permit or deny?

Uses you will see on H12-811 and in production:

For associate-level Datacom, prioritize packet filtering and correct type selection. If the requirement only cares about who sent the packet (source host or subnet), a basic ACL is enough. If the requirement cares about where it is going, which protocol, or which port (HTTP, SSH, DNS), you need an advanced ACL.

Number ranges you must memorize

Huawei VRP uses fixed number ranges for numbered ACLs. Confusing these ranges is one of the highest-frequency H12-811 traps.

Exam trap: ranges such as 1000–1999 or 4000–4999 appear as distractors for “basic source-IP ACL.” The correct basic range is 2000–2999. Advanced is 3000–3999, not “any number above 2000.”

Named ACLs also exist (acl name FILTER_SERVERS). Named ACLs still have a type (basic vs advanced). On the exam, numbered ranges are the fastest way to score the item; in labs, names improve readability.

Entering ACL view and writing rules

From system-view:

[Huawei] acl 2000
[Huawei-acl-basic-2000] rule 5 permit source 192.168.10.0 0.0.0.255
[Huawei-acl-basic-2000] rule 10 deny source any

Or for advanced:

[Huawei] acl 3000
[Huawei-acl-adv-3000] rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 203.0.113.10 0 destination-port eq 443
[Huawei-acl-adv-3000] rule 10 deny ip

Each rule has:

You may omit an explicit rule ID on some platforms and let VRP auto-assign, but exam configurations usually show explicit IDs so order is clear. Spacing rule IDs (5, 10, 15…) leaves room to insert later rules without renumbering everything.

Basic ACL match semantics

A basic ACL answers: “Is the source address interesting?” It cannot express “allow HTTP to the server but deny SSH.” Classic basic examples:

[Huawei] acl 2001
[Huawei-acl-basic-2001] rule 5 permit source 10.1.1.0 0.0.0.255
[Huawei-acl-basic-2001] rule 10 deny source 10.1.2.0 0.0.0.255
[Huawei-acl-basic-2001] rule 15 permit source any

Interpretation:

• Sources in 10.1.1.0/24 are permitted by rule 5.
• Sources in 10.1.2.0/24 are denied by rule 10.
• All other sources hit rule 15 and are permitted (if the ACL is applied as a filter—application is the next section).

If you need “only the server at 203.0.113.10 may be contacted on TCP 443 from VLAN 10,” basic ACL is the wrong tool. That requires destination and port → advanced ACL 3000–3999.

Advanced ACL match semantics

Advanced ACLs support protocol-aware matching. Common patterns:

Example: permit branch users to reach a web server, then deny everything else from that source range:

[Huawei] acl 3001
[Huawei-acl-adv-3001] rule 5 permit tcp source 192.168.20.0 0.0.0.255 destination 203.0.113.10 0 destination-port eq 80
[Huawei-acl-adv-3001] rule 10 permit tcp source 192.168.20.0 0.0.0.255 destination 203.0.113.10 0 destination-port eq 443
[Huawei-acl-adv-3001] rule 15 deny ip source 192.168.20.0 0.0.0.255

Rule 15 denies residual IP from the branch without needing a separate basic ACL. Notice advanced ACLs can still match “IP only” when you do not care about ports—they are a superset of source matching, not a different universe.

Wildcard masks: the inverted intuition

Huawei ACL wildcards (like many industry ACLs) use 0 = must match and 1 = ignore. This is the opposite of subnet masks, where 1 bits mark the network portion.

Worked example: match 172.16.5.0/24.

• Network address written: 172.16.5.0
• Wildcard: 0.0.0.255 (last octet free; first three octets fixed)

Match single host 172.16.5.10:

• source 172.16.5.10 0 (all bits must match)

Exam trap: choosing 255.255.255.0 as an ACL wildcard for a /24. That would invert the meaning and match incorrectly. Another trap is treating wildcard like OSPF network statements without converting.

Mental conversion tip: for a contiguous prefix, wildcard = bitwise NOT of the subnet mask (for classic masks). Mask 255.255.255.0 → wildcard 0.0.0.255.

Rule order and first-match logic

ACLs are not “score all rules and pick the most specific.” They are sequential:

1. Start at the lowest rule ID (or the head of the list).
2. Test the packet against that rule.
3. On first match, apply that rule’s permit or deny and stop.
4. If no rule matches, the result depends on how the ACL is used; for interface traffic-filter packet filtering, treat implicit deny as the standard teaching outcome for unmatched traffic.

Therefore order is security. A broad permit ip placed before a specific deny makes the deny unreachable. Always place more specific rules above broader ones.

Bad order (specific deny never hits for that host if an earlier permit any exists):

rule 5 permit ip
rule 10 deny ip source 10.1.1.50 0

Host 10.1.1.50 already matched rule 5 and was permitted.

Good order:

rule 5 deny ip source 10.1.1.50 0
rule 10 permit ip

Implicit deny and empty ACLs

When an ACL is applied as a packet filter and a packet matches no explicit rule, the safe associate-level model is implicit deny—the packet is dropped. That means:

• An ACL with only deny rules still needs an explicit permit if any traffic should pass.
• An ACL with only specific permits drops everything else by default.
• Forgetting a final permit for return/management traffic is a classic self-lockout when filtering management planes (always design carefully and prefer out-of-band console during experiments).

Empty ACLs (created but no rules) are dangerous mental models: do not assume “empty means allow all.” Treat applied filters as deny-by-default unless documentation for a specific non-filter feature says otherwise (NAT interest ACLs select traffic to translate; behavior is “match means interest,” not always drop).

Basic vs advanced decision table

If a question stem includes destination or port language, eliminate basic ACL answers immediately.

Verification commands

[Huawei] display acl 2000
[Huawei] display acl 3000
[Huawei] display acl all

Confirm rule IDs, hit counts (where shown), permit/deny, and wildcards. Mis-typed wildcards and inverted rule order show up here before you blame routing.

Exam traps checklist

• Basic range is 2000–2999, not 1000–1999.
• Advanced range is 3000–3999 for source/dest/protocol/port.
• Wildcard 0 bits match; 1 bits don’t-care—opposite of subnet masks.
• First matching rule wins; order matters more than “most specific somewhere in the list.”
• Unmatched traffic on a filter ACL is treated as denied in standard exam teaching.
• Basic ACL cannot match destination or ports—pick advanced when the stem requires them.

Practice goals before the next section

1. Write a basic ACL that permits one /24 and denies another.
2. Write an advanced ACL that permits TCP 22 and 443 to one server and denies other IP from a user subnet.
3. Convert three prefixes to correct wildcards without looking them up.
4. Reorder a broken ACL so a host deny actually takes effect.

Master type selection and wildcards here; the next section applies these ACLs on interfaces with traffic-filter and drills matching direction.