Standard vs Extended ACL
The core difference is what each ACL can see. A standard ACL filters on the source IP address only — it can't tell what the traffic is or where it's going, just who sent it. An extended ACL filters on source and destination IP, the protocol (TCP, UDP, ICMP, etc.), and the port number, so it can permit or deny very specific conversations like "this host reaching that server's web port."
Part of the Access Control Lists (ACLs) learning hub
That difference drives everything else, including where you put each one. Because a standard ACL matches only the source, you place it as close to the destination as possible — putting it near the source would block that source from reaching everything, not just the one thing you meant to protect. An extended ACL is specific enough to name the exact flow, so you place it as close to the source as possible to drop unwanted traffic early, before it wastes bandwidth crossing the network. Both list types share the same two rules: they process top-down (first match wins) and end with an implicit deny any that silently drops anything you didn't explicitly permit.
| At a glance | Standard ACL | Extended ACL |
|---|---|---|
| What it matches | Source IP address only | Source + destination IP, protocol, and port |
| Number ranges | 1-99 and 1300-1999 | 100-199 and 2000-2699 |
| Where to place it | As close to the destination as possible | As close to the source as possible |
| Granularity | Coarse — whole hosts/subnets by sender | Fine — specific service between two endpoints |
| Processing order | Top-down, first match wins | Top-down, first match wins |
| End of list | Implicit deny any (drops the rest) | Implicit deny any (drops the rest) |
| Typical use | Simple "block/allow this subnet" rules | Precise service filtering (e.g., allow web, deny the rest) |
What a standard ACL is
A standard ACL is the simplest filter Cisco offers. Each line matches on the source IP address only and then permits or denies it. It has no idea what protocol the packet carries or what it's trying to reach — it only knows who sent it.
Standard ACLs use number ranges 1-99 (and the expanded range 1300-1999). Because they can only identify the sender, they're blunt instruments: good for statements like "deny this subnet" or "permit only the management network," but incapable of anything more targeted.
What an extended ACL is
An extended ACL matches on source IP, destination IP, protocol, and port all at once. That lets you write precise rules — for example, permit one host to reach a server's web port while denying everything else to that server.
Extended ACLs use number ranges 100-199 (and 2000-2699). The extra matching power is what makes them the right tool whenever the rule depends on what the traffic is or where it's going, not just who sent it.
The key difference, and why placement flips
Everything comes back to what each list can see, and the placement rule follows directly from it.
A standard ACL sees only the source, so it can't distinguish good traffic from bad traffic coming out of that source. If you placed it near the source, you'd block that sender from reaching everything, not just the one destination you care about. So you place it near the destination, right before the traffic would arrive, where blocking it does the least collateral damage.
An extended ACL sees the whole conversation, so it can name exactly the flow to drop. That means you place it near the source and stop unwanted traffic immediately — before it consumes bandwidth crossing links to a destination where it was only going to be denied anyway.
When to choose each
Choose a standard ACL when the decision is purely about the sender: restrict which subnet can reach a management interface, or allow only one network into a resource. It's fewer moving parts and easy to read.
Choose an extended ACL when the decision depends on the service or the destination: allow HTTPS to a web server but block everything else, permit DNS but deny other UDP, or let one department reach one server and nothing more. If your rule contains the words "to," "on port," or names a protocol, you need an extended ACL.
A common gotcha: the invisible deny
Every ACL — standard or extended — ends with an implicit deny any that you never see in the configuration. The moment you apply an ACL, anything not explicitly permitted is dropped.
This bites beginners who write a single permit line to allow one thing and are surprised that everything else stops working. If you mean to allow the rest, you must add an explicit permit for it. Also remember lists are read top-down and first match wins: a broad permit placed above a specific deny means the deny is never reached, so order your entries from most specific to most general.
Frequently asked questions
Which is better, a standard or extended ACL?
Neither is universally better — they solve different problems. A standard ACL is simpler but can only match the source IP. An extended ACL matches source, destination, protocol, and port, so it's far more precise. Use the least complex list that actually expresses your rule: standard for "who," extended for "who, to where, doing what."
When would I use an extended ACL instead of a standard one?
Any time the rule depends on more than the sender. If you need to allow a specific service (say, web traffic to one server) while blocking others, or permit one host to reach one destination and nothing else, you need an extended ACL — a standard ACL simply can't see the destination, protocol, or port to make that decision.
What's the main difference between them?
What they can match, which then dictates placement. A standard ACL matches source IP only and is placed near the destination; an extended ACL matches source + destination + protocol + port and is placed near the source. Both process top-down (first match wins) and both end with an implicit deny that drops anything you didn't explicitly permit.
Now build it on real Cisco IOS
Concepts stick when you configure them. Try a free graded lab, then grade your own config against the answer key.