What Is an Access Control List (ACL)?

What an ACL Actually Is

At its core, an ACL is just a numbered or named list of rules, and each rule is either a permit (allow this traffic) or a deny (block this traffic). You attach the list to a router interface in a specific direction — inbound or outbound — and the router evaluates matching traffic against it.

The key word is ordered. An ACL is not a bag of rules the router weighs all at once; it is a sequence. Order changes behavior, which is one of the first things that trips up beginners. Two ACLs with the exact same rules in a different order can produce completely different results.

Why ACLs Exist — the Problem They Solve

By default, a router happily forwards any packet toward its destination as long as it has a route. That is great for connectivity but terrible for control. You often do not want every device talking to every other device — you may want to keep a guest network away from your servers, block a risky protocol, or stop one subnet from reaching another.

ACLs give you that control at Layer 3. They are the router's built-in traffic filter, letting you enforce simple security and policy rules without buying a separate firewall. They are also used beyond filtering — for example, to identify which traffic other features (like NAT or route maps) should act on — but filtering is the concept to learn first.

How It Works: Top-Down Processing and the Implicit Deny

When a packet hits an ACL, the router compares it to the first rule. If it matches, the router applies that rule's action (permit or deny) and stops — it does not keep reading. If it does not match, the router moves to the next rule, and the next, until something matches.

Here is the gotcha that catches almost every beginner: at the very bottom of every ACL sits an invisible, unwritten rule called the implicit deny. If a packet reaches the end without matching any of your rules, it is dropped. This means an ACL that contains only permit statements still blocks everything you did not explicitly allow. If you write an ACL and forget to permit the traffic you actually need, that traffic silently disappears.

A practical consequence: your more specific rules generally need to come before your broader rules. Because processing stops at the first match, a broad permit or deny placed too early can shadow a specific rule below it so that the later rule never gets read.

Standard vs. Extended: What Each One Can See

ACLs come in two flavors that differ in how much of the packet they can inspect. A standard ACL filters on the source IP address only. It is blunt — it can say 'traffic from this host or subnet is allowed or denied' but it cannot tell where that traffic is headed or what kind of traffic it is.

An extended ACL is far more granular. It can match on source address, destination address, the protocol (such as TCP, UDP, or ICMP), and port numbers (which map to services like web or SSH). That lets you write precise rules such as 'allow this subnet to reach that server, but only for web traffic.' Because extended ACLs see so much more, they are the workhorse for real-world policy.

Where to Put Them: Placement Rules

Placement matters because you want to drop unwanted traffic efficiently without accidentally blocking traffic you meant to keep. The classic guidance follows directly from what each ACL type can see.

Place a standard ACL close to the destination. Since it only knows the source address, putting it too close to the source risks filtering out traffic the sender legitimately needs elsewhere — so you keep it near the end of the path, close to what you are protecting. Place an extended ACL close to the source. Because it can match the specific destination, protocol, and port, you can safely drop unwanted traffic right where it enters the network, saving it from crossing links only to be discarded later.

Treat these as sound rules of thumb rather than unbreakable laws — real designs sometimes deviate for good reasons — but for CCNA they are the expected answers and they reflect genuinely useful logic.

Common Confusions a Beginner Hits

A few things reliably cause head-scratching. First, direction: an ACL is applied inbound or outbound on an interface, and 'inbound' means traffic entering the router through that interface, not traffic entering your building. Getting the direction backwards is a classic mistake.

Second, the wildcard mask. When an ACL specifies a range of addresses, it often uses a wildcard mask, which is essentially the inverse of a subnet mask — where a subnet mask marks network bits, the wildcard marks which address bits the router should ignore when matching. It looks similar to a subnet mask but behaves the opposite way.

Third, remember that an ACL only filters traffic that actually passes through (or is destined to) the router. It is a Layer 3 tool. This concept article stays at the 'what and why' level on purpose — the exact command syntax for building and applying ACLs lives in our separate step-by-step how-to guide.