LESSON PURPOSE Develop a practical understanding of how IPv4 Access Control Lists classify and filter traffic on Cisco routers and multilayer switches, and how standard, extended, numbered, and named ACLs are designed, configured, verified, and troubleshot. |
Lesson Overview
IPv4 ACLs are ordered lists of Access Control Entries (ACEs) used to permit or deny traffic based on Layer 3 and, with extended ACLs, Layer 4 information. ACLs can protect network resources, limit unwanted traffic, define which flows are allowed between subnets, and classify traffic for other features.
This lesson explains standard and extended ACL behavior, wildcard masks, top-down processing, first-match logic, the implicit deny at the end of every ACL, correct inbound/outbound application, and practical ACL placement. It also covers numbered versus named ACLs, editing with sequence numbers, verification commands, and a structured troubleshooting workflow.
Learning Objectives
• Explain the purpose of IPv4 ACLs and how an ACL differs from a stateful firewall.
• Describe ACL processing: top-down evaluation, first-match action, and the implicit deny any at the end.
• Differentiate standard ACLs from extended ACLs and identify the traffic fields each type can match.
• Interpret and calculate wildcard masks for hosts, subnets, address ranges, and the any / host keywords.
• Configure numbered and named standard IPv4 ACLs on Cisco IOS.
• Configure numbered and named extended IPv4 ACLs using source, destination, protocol, and TCP/UDP port criteria.
• Apply ACLs to router or multilayer-switch interfaces in the correct inbound or outbound direction with ip access-group.
• Choose appropriate ACL placement: standard ACLs generally close to the destination and extended ACLs generally close to the source.
• Use sequence numbers and named ACL configuration mode to insert, remove, or modify ACEs safely.
• Verify and troubleshoot ACL operation using show access-lists, show ip interface, packet counters, ping, traceroute, and traffic-path analysis.
Recommended Study Sequence
Foundations → processing order → wildcard masks → standard ACLs → extended ACLs → named ACL editing → direction and placement → verification → troubleshooting → integrated lab.
1. ACL Foundations
An Access Control List (ACL) is an ordered set of permit and deny statements used by a router or multilayer switch to classify IPv4 packets. When an ACL is attached to a Layer 3 interface with ip access-group, it can filter packets entering or leaving that interface.
|
Key behavior An ACL does not “route” a packet. Routing determines where the packet should go; an applied ACL decides whether the packet is allowed to continue in the configured direction. |
|
Term |
Meaning |
|
ACL |
The complete ordered rule set. |
|
ACE |
One Access Control Entry such as permit tcp ... or deny ip ... |
|
Permit |
Allow matching traffic to continue. |
|
Deny |
Drop matching traffic. |
|
Implicit deny |
Hidden final deny that drops traffic not matched by an earlier permit. |
|
Hit counter |
Number of packets that matched an ACE; useful during verification/troubleshooting. |
2. ACL Processing Logic
Figure 2. ACL evaluation is top-down; the first matching ACE determines the action.
The router starts with the first ACE and compares the packet with each entry in order.
As soon as an ACE matches, its permit or deny action is taken and processing stops.
A more specific rule must appear before a broader rule if both could match the same packet.
If no explicit ACE matches, the packet is dropped by the implicit deny at the end of the ACL.
Changing ACE order can change the policy even if all individual lines stay the same.
|
Exam / operations point A correct ACL often fails because of rule order, not syntax. Always read an ACL from the top down and ask which line will match first. |
3. ACL Types and Number Ranges
|
ACL type |
Numbered ranges |
Primary match fields |
Typical placement |
|
Standard |
1–99, 1300–1999 |
Source IPv4 address only |
Closer to destination |
|
Extended |
100–199, 2000–2699 |
Protocol, source, destination, TCP/UDP ports, ICMP |
Closer to source |
|
Named standard |
Name instead of number |
Source IPv4 address only |
Closer to destination |
|
Named extended |
Name instead of number |
Protocol, source, destination, Layer 4 information |
Closer to source |
Named ACLs are usually easier to document and modify because the name can describe the purpose and sequence numbers can be used to insert or remove individual ACEs.
4. Wildcard Masks
IPv4 ACLs use wildcard masks rather than subnet masks. A wildcard mask tells the router which address bits must match and which bits may vary.
|
Wildcard bit |
Meaning |
|
0 |
The corresponding address bit must match. |
|
1 |
The corresponding address bit is ignored. |
|
Requirement |
ACL address + wildcard |
Shortcut |
|
Exactly 10.10.10.10 |
10.10.10.10 0.0.0.0 |
host 10.10.10.10 |
|
10.10.10.0/24 |
10.10.10.0 0.0.0.255 |
— |
|
10.10.8.0/22 |
10.10.8.0 0.0.3.255 |
— |
|
Any IPv4 source/destination |
0.0.0.0 255.255.255.255 |
any |
Wildcard-mask calculation example
|
Subnet mask: 255.255.255.0 Wildcard mask: 0. 0. 0.255 Rule: wildcard = 255.255.255.255 - subnet mask |
|
Important Do not read a wildcard mask like a subnet mask. In ACL logic, 0 means “check this bit,” while 1 means “do not care about this bit.” |
5. Standard IPv4 ACLs
A standard ACL evaluates only the source IPv4 address. It cannot distinguish the destination, IP protocol, or TCP/UDP application port. Because its match capability is broad, place it as close to the intended destination as practical.
Figure 5. Standard ACL applied outbound near the destination to block one source only for the server LAN.
Numbered standard ACL example
|
access-list 10 deny host 10.10.10.50 access-list 10 permit any ! interface GigabitEthernet0/1 ip access-group 10 out |
In this example, 10.10.10.50 is denied only when traffic is about to leave R2 toward the protected server LAN. Other source addresses are permitted because the explicit permit any appears before the implicit deny.
6. Named Standard ACLs and Sequence Numbers
Named standard ACL
|
ip access-list standard BLOCK-TEST-HOST 10 deny host 10.10.10.50 20 permit any ! interface GigabitEthernet0/1 ip access-group BLOCK-TEST-HOST out |
Sequence numbers provide a clean way to edit an ACL without recreating the entire list.
Editing ACL by sequence number
|
ip access-list standard BLOCK-TEST-HOST 15 deny host 10.10.10.60 no 10 10 deny host 10.10.10.55 |
|
Prod Change-management tip Before editing a production ACL, capture the current ACL, confirm the direction/interface, identify the intended insertion point, and have a rollback plan. |
7. Extended IPv4 ACLs
Extended ACLs can make much more precise decisions because they can match the IP protocol, source address, destination address, and Layer 4 information such as TCP or UDP ports.
Figure 7. Extended ACL permits HTTP/HTTPS to the web server, denies other traffic to that server, then permits unrelated traffic.
Named extended ACL example
|
ip access-list extended WEB-FILTER 10 permit tcp 10.10.10.0 0.0.0.255 host 10.30.30.10 eq 80 20 permit tcp 10.10.10.0 0.0.0.255 host 10.30.30.10 eq 443 30 deny ip 10.10.10.0 0.0.0.255 host 10.30.30.10 log 40 permit ip any any ! interface GigabitEthernet0/0 ip access-group WEB-FILTER in |
|
Why line 40 matters Without permit ip any any, all packets that did not match the web-server rules would be dropped by the implicit deny. Whether that is desirable depends on the policy goal. |
8. Extended ACL Syntax and Match Operators
Generic extended ACL structure
|
access-list <number> {permit|deny} <protocol> <source> <source-wildcard> <destination> <destination-wildcard> [operator port] |
|
Field / operator |
Purpose |
Example |
|
ip |
Match all IPv4 protocols |
permit ip any any |
|
tcp |
Match TCP traffic |
permit tcp ... eq 443 |
|
udp |
Match UDP traffic |
permit udp ... eq 53 |
|
icmp |
Match ICMP |
permit icmp ... echo |
|
eq |
Equal to a specific port |
eq 22 |
|
range |
Inclusive port range |
range 10000 20000 |
|
gt / lt |
Greater than / less than port |
gt 1023 |
|
neq |
Not equal to port |
neq 23 |
Named ports such as ssh, www, https, domain, ftp, and tftp may be supported by IOS syntax, but numeric ports are often clearer in training examples and change documentation.
9. Common TCP/UDP Ports Used in ACLs
|
Service |
Protocol |
Port(s) |
ACL example fragment |
|
FTP |
TCP |
20/21 |
permit tcp ... eq 21 |
|
SSH |
TCP |
22 |
permit tcp ... eq 22 |
|
Telnet |
TCP |
23 |
deny tcp ... eq 23 |
|
DNS |
UDP/TCP |
53 |
permit udp ... eq 53 |
|
DHCP |
UDP |
67/68 |
permit udp ... eq 67 |
|
TFTP |
UDP |
69 |
permit udp ... eq 69 |
|
HTTP |
TCP |
80 |
permit tcp ... eq 80 |
|
NTP |
UDP |
123 |
permit udp ... eq 123 |
|
SNMP |
UDP |
161/162 |
permit udp ... eq 161 |
|
HTTPS |
TCP |
443 |
permit tcp ... eq 443 |
|
Statefulness Traditional interface ACLs are stateless. If a policy requires return traffic to be restricted, the return direction must also be considered; stateful firewall features solve a different problem than a basic ACL. |
10. Inbound and Outbound ACL Direction
Figure 10. “In” and “out” are always relative to the specific router interface.
Inbound: the packet is checked as it enters the Layer 3 interface.
Outbound: the packet is checked after the router has selected an egress interface and before it is transmitted.
An ACL can be correct but still appear ineffective if it is applied to the wrong interface or direction.
A single IPv4 interface can have one IPv4 ACL per direction for a given filtering context; plan rules so the intended policy is consolidated.
11. ACL Placement Guidelines
|
Situation |
Recommended approach |
Reason |
|
Standard ACL |
Place near destination |
Source-only matching is broad; destination-side placement limits unintended impact. |
|
Extended ACL |
Place near source |
Unwanted traffic is discarded early and does not consume downstream bandwidth. |
|
Shared transit interface |
Review all flows before applying |
A broad ACL may affect multiple applications/subnets using the same path. |
|
Management access |
Use a dedicated ACL / access-class where appropriate |
Separates management-plane policy from ordinary data-plane filtering. |
|
Guideline, not a law Topology, asymmetric routing, redundancy, hardware architecture, and operational requirements can justify a different placement. Always validate the actual packet path. |
12. Management-Plane ACL Example (VTY access-class)
ACLs are also used as classification tools outside normal interface packet filtering. A common example is restricting which management subnet may open SSH sessions to the router VTY lines.
Restrict SSH sources with access-class
|
ip access-list standard MGMT-SOURCES 10 permit 10.99.99.0 0.0.0.255 20 deny any log ! line vty 0 4 transport input ssh access-class MGMT-SOURCES in |
|
Distinction: ip access-group applies an ACL to routed interface traffic; access-class under the VTY lines controls remote management access to the device itself. |
13. Verification Commands
|
Command |
What it verifies |
|
show ip access-lists |
Named/numbered IPv4 ACLs, ACE sequence, and hit counters. |
|
show access-lists |
ACL contents and counters. |
|
show ip interface <interface> |
Inbound/outbound ACL applied to an interface. |
|
show running-config | section access-list |
Configured ACL definitions. |
|
show running-config interface <interface> |
ACL attachment and interface configuration. |
|
clear access-list counters <name|number> |
Reset counters before a controlled test. |
Example hit-counter interpretation
|
R1# show ip access-lists WEB-FILTER Extended IP access list WEB-FILTER 10 permit tcp 10.10.10.0 0.0.0.255 host 10.30.30.10 eq www (18 matches) 20 permit tcp 10.10.10.0 0.0.0.255 host 10.30.30.10 eq 443 (42 matches) 30 deny ip 10.10.10.0 0.0.0.255 host 10.30.30.10 log (3 matches) 40 permit ip any any (126 matches) |
14. ACL Troubleshooting Workflow
Figure 14. Troubleshoot the traffic path, ACL attachment, order, wildcard, protocol/port, and counters in that order.
- Confirm the source/destination IP addresses and the actual routed path before blaming the ACL.
- Verify the ACL is attached to the correct interface and direction.
- Read the ACL top-down and look for an earlier broad rule that shadows a later rule.
- Recalculate wildcard masks and confirm host/any usage.
- Verify TCP/UDP protocol and destination/source port placement in the ACE syntax.
- Clear counters for a controlled test, generate one flow, then inspect which ACE increments.
- Check for the implicit deny if no hit counter appears on an expected permit line.
|
Final study rule Write the requirement in plain language first. Then identify protocol, source, destination, port, placement, direction, rule order, and explicit permits before entering configuration. |
Quick knowledge check
1. What implicit rule exists at the end of every IPv4 ACL?
Answer: Implicit deny (deny any for standard logic / deny ip any any for extended IPv4 logic).
2. Why is a standard ACL normally placed close to the destination?
Answer: Because it cannot match the destination; destination-side placement reduces unintended blocking.
3. If a permit line never increments, what two things should you verify first?
Answer: Confirm the packet actually traverses the interface and confirm the ACL is applied in the correct direction.