Access Control Lists (ACLs)

Access Control Lists (ACLs) are ordered sets of rules that filter network traffic based on various packet characteristics, providing essential security and traffic management capabilities in Cisco networks. ACLs examine packets as they traverse router interfaces, making permit or deny decisions according to configured criteria. Understanding ACL types, processing logic, and application methods is fundamental for CCNA certification and for implementing effective network security policies. Cisco IOS supports two primary ACL categories distinguished by their filtering granularity and number ranges. Standard ACLs (numbered 1-99 and 1300-1999) provide basic filtering based solely on source IP address—they cannot examine destination addresses, protocols, or port numbers. This limited capability makes standard ACLs suitable only for simple filtering scenarios where you need to permit or deny all traffic from specific sources regardless of destination or protocol. Extended ACLs (numbered 100-199 and 2000-2699) offer comprehensive filtering capabilities, examining source IP, destination IP, protocol type (TCP, UDP, ICMP, etc.), source and destination port numbers, TCP flags, and other packet characteristics. This granular control makes extended ACLs the preferred choice for sophisticated traffic filtering and security policies. ACL processing follows a critical top-down, first-match-wins logic that profoundly impacts ACL behavior. When a packet arrives at an interface with an applied ACL, the router examines the packet against each ACL entry sequentially, starting from the first entry. As soon as the packet matches an entry (permit or deny), the router takes the specified action and immediately stops processing—subsequent ACL entries are never evaluated for that packet. This means entry order is crucial: a permissive entry near the top might allow traffic you intended to block with a more specific entry further down. The implicit deny all at the end of every ACL blocks any traffic not explicitly permitted by earlier entries. You never see this implicit deny in the configuration, but it's always present, meaning an empty ACL denies all traffic. ACLs can be applied to router interfaces in two directions: inbound or outbound. Inbound ACLs filter traffic as it enters the interface before routing decisions are made, providing security benefits by dropping malicious traffic before it consumes router resources for routing lookups. This placement is most efficient for filtering traffic you never want forwarded. Outbound ACLs filter traffic as it exits the interface after routing decisions complete, useful for controlling what traffic leaves specific network segments. Understanding which direction to apply ACLs depends on your filtering goals and network topology. A single interface can have one inbound ACL and one outbound ACL applied simultaneously (one per direction, per protocol). ACL best practices significantly impact network security and performance. Place standard ACLs close to the destination because they filter all traffic from source addresses without granularity—placing them near the source would block wanted traffic along with unwanted traffic. Conversely, place extended ACLs close to the source to drop unwanted traffic early, preventing it from consuming bandwidth across your network. Document all ACLs thoroughly using the 'remark' command to add descriptive comments—undocumented ACLs become mysteries when you or others troubleshoot years later. Build ACLs outside production devices in a text editor, ensuring proper order and completeness before applying to routers. Always include an explicit permit statement for wanted traffic before the implicit deny catches everything else. Test ACLs carefully in lab environments before production deployment, as incorrect ACLs can completely block critical traffic. ACL application uses the 'ip access-group [number|name] {in|out}' command in interface configuration mode. For example, 'ip access-group 100 in' applies extended ACL 100 to inbound traffic on the interface. Only one ACL per protocol (IP, IPv6), per direction can be applied to an interface—applying a new ACL in the same direction replaces the previous one. Verification commands include 'show access-lists' (displays all configured ACLs and match counters), 'show ip interface [interface-id]' (shows which ACLs are applied to specific interfaces and in which direction), and 'show run | include access' (lists ACL references in the configuration). Understanding ACL fundamentals enables implementing effective traffic filtering and security policies in network infrastructure.

Wildcard masks represent one of the most confusing yet essential concepts in Cisco ACL configuration and OSPF network statements. Unlike subnet masks that use 1s to indicate network bits and 0s for host bits, wildcard masks use exactly the opposite logic: 0s mean 'must match exactly' and 1s mean 'don't care, any value acceptable.' This inverse relationship causes significant confusion for network engineers familiar with subnet masks, but understanding wildcard mask logic is crucial for CCNA success and effective ACL configuration. The fundamental wildcard mask principle is simple: examine each bit position in the wildcard mask. If the bit is 0, the corresponding bit in the IP address being tested must match the corresponding bit in the ACL statement exactly. If the bit is 1, the corresponding bit in the IP address can be anything—it's ignored during matching. This provides incredible flexibility in matching IP address ranges. For example, wildcard mask 0.0.0.0 means all bits must match exactly (single host), while 255.255.255.255 means no bits need to match (any host). Converting from subnet masks to wildcard masks uses a simple mathematical operation: subtract the subnet mask from 255.255.255.255. For a /24 subnet (mask 255.255.255.0), the wildcard is 255.255.255.255 - 255.255.255.0 = 0.0.0.255. This wildcard means the first 24 bits must match exactly (corresponding to the three 0 octets) while the last 8 bits can be anything (corresponding to the 255 in the last octet). For a /30 subnet (mask 255.255.255.252), the wildcard is 255.255.255.255 - 255.255.255.252 = 0.0.0.3, matching any of four addresses in a /30 subnet. Common wildcard mask patterns include: 0.0.0.0 for a single host (every bit must match), often replaced with the 'host' keyword in IOS commands. 0.0.0.255 for an entire /24 subnet (first 24 bits match, last 8 vary). 0.0.255.255 for a /16 subnet (first 16 bits match, last 16 vary). 0.255.255.255 for a /8 subnet (first 8 bits match, last 24 vary). 255.255.255.255 for any address, often replaced with the 'any' keyword. These patterns handle most common scenarios, but wildcard masks support any arbitrary bit pattern, enabling matching of discontiguous ranges or specific bit patterns within octets. Advanced wildcard mask usage includes matching odd or even addresses, specific subnet ranges, or non-standard patterns. For example, wildcard 0.0.0.1 matches pairs of addresses where the last bit can vary: 192.168.1.0 with wildcard 0.0.0.1 matches both 192.168.1.0 and 192.168.1.1 but not .2 or .3. Wildcard 0.0.0.7 matches blocks of 8 addresses. These advanced patterns are less common but demonstrate wildcard masks' flexibility. Wildcard masks in OSPF network statements follow the same logic: 'network 10.1.1.0 0.0.0.3 area 0' enables OSPF on any interface with an IP in the range 10.1.1.0-10.1.1.3. Using 'network 0.0.0.0 255.255.255.255 area 0' enables OSPF on all interfaces with any IP address—broad but sometimes useful for quickly enabling OSPF everywhere. Common mistakes include confusing subnet masks with wildcard masks, leading to incorrect matching. For example, using 255.255.255.0 as a wildcard (thinking it's a subnet mask) matches no bits instead of the intended 24-bit match. Another error is incorrect calculation when converting /30, /29, or other subnets—practice these conversions until automatic. The 'host' and 'any' keywords simplify ACL syntax: 'access-list 10 permit host 192.168.1.50' is clearer than 'access-list 10 permit 192.168.1.50 0.0.0.0', and 'access-list 10 deny any' is clearer than 'access-list 10 deny 0.0.0.0 255.255.255.255'. Modern IOS displays these keywords in 'show run' output even if you configured using numeric values. Understanding wildcard masks enables precise traffic matching in ACLs and correct OSPF network statement configuration, both essential for CCNA certification and practical network administration.

Standard Access Control Lists provide basic traffic filtering based solely on source IP addresses, making them suitable for simple scenarios where you need to permit or deny all traffic from specific hosts or networks regardless of destination, protocol, or application. Understanding standard ACL syntax, configuration best practices, and appropriate placement is essential for CCNA certification and for implementing basic security policies in network infrastructure. The standard ACL syntax follows a simple pattern: 'access-list [number] {permit|deny} [source-IP] [wildcard-mask]' in global configuration mode. The ACL number identifies the ACL (1-99 or 1300-1999 for standard ACLs) and groups related entries together. Multiple commands with the same number add entries to that ACL in the order configured. The permit or deny keyword specifies the action taken when packets match this entry. The source IP and wildcard mask define which source addresses match. For example, 'access-list 10 permit 192.168.1.0 0.0.0.255' permits all traffic from the 192.168.1.0/24 network. Several shortcut keywords simplify common configurations. The 'host' keyword replaces the 0.0.0.0 wildcard mask for single hosts: 'access-list 10 permit host 192.168.1.50' is equivalent to 'access-list 10 permit 192.168.1.50 0.0.0.0' but more readable. The 'any' keyword matches all source addresses: 'access-list 10 deny any' explicitly denies all traffic (though redundant given the implicit deny all). Using these keywords improves configuration clarity and is recommended for CCNA exam answers. Building a complete standard ACL requires careful planning of entry order due to top-down processing. Start with the most specific entries (single hosts) and proceed to more general entries (entire subnets), ending with the broadest match (any). This prevents broad matches from shadowing specific exceptions. For example, to permit host 192.168.1.50, deny the rest of 192.168.1.0/24, but permit 192.168.2.0/24: 'access-list 10 permit host 192.168.1.50' (most specific first), 'access-list 10 deny 192.168.1.0 0.0.0.255' (deny rest of subnet), 'access-list 10 permit 192.168.2.0 0.0.0.255' (permit different subnet). The implicit deny all handles everything else. If you reversed the first two entries, the deny 192.168.1.0/24 would catch the .50 host before the permit could take effect. Applying standard ACLs to interfaces uses the 'ip access-group [ACL-number] {in|out}' command in interface configuration mode. The ACL number references the standard ACL created in global config. The direction (in or out) specifies whether to filter traffic entering or leaving the interface. For example, on interface GigabitEthernet0/0, the command 'ip access-group 10 in' applies standard ACL 10 to traffic arriving on that interface. Remember: inbound ACLs filter before routing decisions, outbound ACLs filter after routing decisions. Standard ACL placement follows a critical rule: place standard ACLs as close to the destination as possible. This placement rule stems from standard ACLs' limitation—they filter all traffic from a source without granularity. If you place a standard ACL denying host 192.168.1.50 near the source (close to the host), you block all traffic from that host even if some of it should reach certain destinations. Placing the ACL near the destination (on the router interface closest to the protected resource) allows traffic from 192.168.1.50 to flow normally across your network until it reaches the specific destination you're protecting, where it's then filtered. Common mistakes include reversing the placement rule (putting standard ACLs near source), incorrect wildcard masks (using subnet masks instead), poor entry ordering (broad matches before specific ones), forgetting the implicit deny (adding permit statements without remembering everything else is denied), and applying ACLs to the wrong interface or direction. Verification uses 'show access-lists [number]' to display the ACL configuration and match counters (how many packets matched each entry), and 'show ip interface [interface-id]' to confirm which ACLs are applied and in which direction. Understanding standard ACL configuration enables implementing basic traffic filtering, though extended ACLs are usually preferred for their greater flexibility and precision.

Extended Access Control Lists provide sophisticated, granular traffic filtering by examining multiple packet characteristics including source and destination IP addresses, protocol types, port numbers, TCP flags, and other Layer 3 and Layer 4 information. This comprehensive filtering capability makes extended ACLs the preferred choice for most production security policies and traffic management scenarios. Mastering extended ACL syntax and application is essential for CCNA certification and for implementing effective network security. The extended ACL syntax is more complex than standard ACLs due to additional parameters: 'access-list [100-199|2000-2699] {permit|deny} [protocol] [source-IP] [source-wildcard] [source-port] [destination-IP] [dest-wildcard] [dest-port] [additional-options]'. The protocol field specifies which Layer 3/4 protocol to match: ip (matches all IP traffic), tcp (Transmission Control Protocol), udp (User Datagram Protocol), icmp (Internet Control Message Protocol), eigrp (EIGRP protocol 88), ospf (OSPF protocol 89), gre (Generic Routing Encapsulation), and others. Specifying 'ip' creates a broad match across all protocols, while tcp/udp enables port-specific filtering. Port number specification uses operator keywords: eq (equal to), neq (not equal to), lt (less than), gt (greater than), and range (inclusive range). For example, 'eq 80' matches exactly port 80 (HTTP), 'gt 1023' matches ports above 1023 (unprivileged ports), 'range 1024 65535' matches all ports from 1024 to 65535. IOS recognizes well-known port names: www/http (80), https (443), telnet (23), ssh (22), ftp (20/21), smtp (25), dns (53), etc. Using names improves readability: 'eq www' is clearer than 'eq 80' for most administrators. Common extended ACL examples demonstrate practical filtering scenarios. To permit HTTP traffic from 10.1.1.0/24 to any destination: 'access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 80'. To permit HTTPS from any source to web server 203.0.113.50: 'access-list 100 permit tcp any host 203.0.113.50 eq 443'. To permit ICMP (ping) from 192.168.0.0/16 to anywhere: 'access-list 100 permit icmp 192.168.0.0 0.0.255.255 any'. To deny Telnet from any source to network 172.16.0.0/16: 'access-list 100 deny tcp any 172.16.0.0 0.0.255.255 eq 23'. Notice the flexibility—you can match on source, destination, or both, with protocol and port specificity. Extended ACL placement follows the opposite rule from standard ACLs: place extended ACLs as close to the source as possible. This placement prevents unwanted traffic from consuming bandwidth across your network. If you need to block Telnet traffic from 10.1.1.0/24 to server 172.16.1.100, placing an extended ACL on the router interface nearest the 10.1.1.0/24 network drops the traffic immediately. If you place the ACL near the destination (at the server's router), that Telnet traffic flows across your entire network infrastructure before being dropped, wasting bandwidth. Extended ACLs' granularity allows safe source placement—you're blocking specific traffic (Telnet to specific destination), not all traffic from the source. Established connection tracking uses the 'established' keyword with TCP ACLs to permit return traffic for connections initiated from inside your network. For example, 'access-list 100 permit tcp any any established' permits any TCP packet with the ACK or RST flags set, which occur in established connections but not in connection setup SYN packets. This allows inside users to browse the web (establishing outbound connections) while blocking inbound connection attempts from the internet. However, stateful inspection features in modern firewalls provide superior connection tracking—the established keyword is a basic approximation. Logging and remarks improve ACL management and troubleshooting. The 'log' keyword at the end of an ACL entry generates syslog messages when packets match: 'access-list 100 deny tcp any any eq 23 log' logs Telnet attempts. Be cautious with logging—high traffic rates matching logged entries can overwhelm router CPU and syslog servers. The 'remark' keyword adds comments: 'access-list 100 remark Block Telnet to DMZ servers' documents intent. Remarks appear in configuration but don't process traffic. Understanding extended ACL configuration enables implementing sophisticated traffic filtering and security policies for complex network requirements.

Named Access Control Lists introduced significant improvements over traditional numbered ACLs by using descriptive names instead of numbers, supporting sequence numbers for precise entry management, and allowing editing of individual entries without removing the entire ACL. These capabilities make named ACLs essential for modern network administration and strongly preferred for production deployments. Understanding named ACL syntax and the best practices that ensure effective, maintainable ACL implementations is critical for CCNA certification and professional network security management. Named ACL configuration uses a different syntax structure than numbered ACLs. Instead of entering complete ACL statements in global configuration mode, you first create the ACL name and type: 'ip access-list {standard|extended} [NAME]' in global configuration mode. This command enters ACL configuration mode specific to that named ACL. Within this mode, you enter permit and deny statements without repeating the ACL name. For example: 'ip access-list extended BLOCK-TELNET' enters ACL config mode, then 'deny tcp any any eq 23' and 'permit ip any any' add entries. This structure provides better organization than scattered numbered ACL statements throughout the configuration. Sequence numbers represent named ACLs' most powerful feature. Each entry in a named ACL automatically receives a sequence number (10, 20, 30, etc., incrementing by 10 by default) that determines processing order. These numbers appear when viewing the ACL: 'show access-lists BLOCK-TELNET' displays each entry with its sequence number. The critical advantage is that you can insert new entries between existing entries or delete specific entries without removing the entire ACL. With numbered ACLs, adding an entry always appends it to the end, and removing any entry requires removing the entire ACL and recreating it. Named ACLs eliminate these limitations. To insert an entry at a specific position in a named ACL, specify the sequence number: In ACL configuration mode, use '[sequence-number] {permit|deny} [parameters]'. For example, if you have entries at sequences 10, 20, and 30, you can insert a new entry at sequence 15: '15 permit tcp host 10.1.1.5 any eq 80'. This entry processes between the current entries 10 and 20. To delete a specific entry, use 'no [sequence-number]' in ACL configuration mode: 'no 20' removes only entry 20, leaving other entries intact. This granular control vastly simplifies ACL maintenance in production networks. ACL best practices begin with comprehensive documentation. Every ACL should have remarks explaining its purpose: 'remark Block external Telnet access to DMZ servers' documents intent clearly. Document the source network, destination network, permitted/denied services, and business justification. This documentation is invaluable when troubleshooting years later or when other administrators need to understand the security policy. Review and audit ACLs regularly—security requirements change, and ACLs accumulate unused entries over time. Build and test ACLs in lab environments before production deployment. A mistake in an ACL can block critical traffic, causing outages. Test all scenarios: verify permitted traffic works, verify denied traffic blocks, check that return traffic for permitted sessions succeeds. Use 'show access-lists' to monitor match counters—entries with zero hits may be unnecessary or incorrectly placed in the processing order. High hit counts on deny rules might indicate attacks or misconfigured devices generating unwanted traffic. ACL design should follow the principle of least privilege: explicitly permit only required traffic, relying on the implicit deny to block everything else. Start with a deny-all posture and add permits for specific needed services. This approach is more secure than attempting to deny specific threats while permitting everything else—you can't anticipate all threats. Order entries from most specific to most general, placing exceptions before general rules. Group related entries together and use remarks to delineate sections. Consider ACL performance impact. Routers process ACLs in software (in the CPU) for most platforms, with each packet being examined against potentially hundreds of entries. Complex extended ACLs with many entries can impact router performance under high traffic loads. Place the most commonly matched entries (both permits and denies) near the top to reduce average processing time. Consolidate multiple ACLs into fewer, well-organized ACLs where possible rather than having dozens of small ACLs. Use named ACLs for all new deployments—their superior manageability justifies the slightly different syntax. Reserve numbered ACLs only for legacy compatibility or very simple, temporary filtering. When migrating numbered ACLs to named, choose descriptive names that indicate the ACL's purpose: 'BRANCH-INTERNET-OUTBOUND', 'DMZ-WEB-SERVER-INBOUND', 'MANAGEMENT-ACCESS'. Understanding named ACL capabilities and following ACL best practices enables creating maintainable, effective security policies that protect network resources while remaining manageable over time.