CCNA ACL Lab — Standard & Extended Access Control Lists

What Access Control Lists Are and Why They Matter in 2026

Access Control Lists (ACLs) are ordered sets of permit and deny statements that Cisco routers and switches evaluate sequentially to filter IP traffic. Each ACL entry compares packet headers—source IP, destination IP, protocol, port—against configured criteria, then permits or denies forwarding. ACLs remain the foundational security mechanism in enterprise networks because they operate at line rate in hardware ASICs, consume minimal CPU, and integrate natively with routing protocols, NAT, and quality-of-service policies. In 2026, despite the rise of next-generation firewalls and zero-trust architectures, ACLs still protect branch routers at Cisco India deployments, Aryaka SD-WAN edge appliances, and the 24×7 rack infrastructure in our HSR Layout lab where CCNA candidates configure hundreds of ACL scenarios before their first interview.

Standard ACLs filter solely on source IPv4 address and should be placed closest to the destination to avoid blocking legitimate traffic upstream. Extended ACLs inspect source, destination, protocol (TCP/UDP/ICMP), and Layer 4 ports, offering granular control and belonging near the source to conserve bandwidth. Named ACLs—both standard and extended—allow mid-list insertion and descriptive labels, simplifying audits in production. The CCNA 200-301 blueprint allocates roughly 8 percent of exam weight to ACL configuration, troubleshooting, and placement strategy, making hands-on lab practice non-negotiable for passing and for real-world competence.

How ACLs Work Under the Hood

When a packet arrives at a router interface, the IOS checks whether an inbound ACL is applied. If present, the router walks the ACL from top to bottom, comparing packet attributes against each access control entry (ACE) until a match occurs. The first matching ACE's action—permit or deny—is executed immediately; no further entries are evaluated. If no explicit match is found, an implicit deny-all rule at the end of every ACL drops the packet and logs the event if logging is enabled. Outbound ACLs are evaluated after the routing decision, just before the packet exits the interface, which means denied traffic still consumes router CPU for the lookup but never touches the wire.

Cisco routers compile ACLs into Ternary Content-Addressable Memory (TCAM) on platforms like Catalyst 9000 and ASR 1000 series, enabling parallel matching at multi-gigabit rates. Each TCAM entry stores a value, mask, and result triplet; the mask uses wildcard bits (inverse of subnet mask) where 0 means "must match exactly" and 1 means "ignore this bit." For example, the wildcard 0.0.0.255 matches any address in a /24 subnet because the last octet is ignored. Understanding wildcard math is critical: interviewers at HCL and Akamai India routinely ask candidates to convert CIDR notation to wildcard masks on a whiteboard, and mistakes here fail the technical round.

ACL processing incurs negligible latency—typically under 10 microseconds per lookup on modern hardware—but poorly designed ACLs with thousands of entries can exhaust TCAM or force software switching. During our 4-month paid internship at the Network Security Operations Division, trainees monitor ACL hit counters with show access-lists to identify unused rules and optimize order, placing the most frequently matched entries at the top to reduce average lookup depth.

Standard ACLs vs Extended ACLs vs Named ACLs

Cisco IOS supports three ACL categories, each suited to different filtering requirements. Standard ACLs (numbered 1–99 and 1300–1999) match only the source IP address, making them simple but coarse. Extended ACLs (numbered 100–199 and 2000–2699) match source, destination, protocol, port, TCP flags, ICMP type, and more, delivering surgical precision. Named ACLs use descriptive strings instead of numbers and support both standard and extended syntax, plus the ability to insert or delete individual entries by sequence number without rewriting the entire list.

In our HSR Layout lab, we configure all three types on back-to-back scenarios: a standard ACL to prevent a guest VLAN from reaching the management subnet, an extended ACL to block HTTP but permit HTTPS from a contractor segment, and a named ACL with 40+ entries mirroring a real Cisco India branch policy. Named ACLs are mandatory in enterprises because renumbering a 200-line extended ACL to insert a new rule at line 15 is operationally reckless; sequence numbers (default increment 10) allow ip access-list extended BRANCH-IN followed by 15 permit tcp 10.50.0.0 0.0.255.255 any eq 443 to slot the rule precisely.

Configuring Standard ACLs in Cisco IOS

Standard ACL syntax is compact: access-list number {permit | deny} source [wildcard]. The source can be a specific host (host 192.168.1.10), a subnet with wildcard (10.0.0.0 0.0.255.255), or the keyword any to match all addresses. After defining ACL entries in global configuration mode, apply the ACL to an interface with ip access-group number {in | out} in interface configuration mode.

Router(config)# access-list 10 deny host 192.168.1.50
Router(config)# access-list 10 permit 192.168.1.0 0.0.0.255
Router(config)# access-list 10 deny 10.0.0.0 0.255.255.255
Router(config)# access-list 10 permit any
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group 10 out

This ACL blocks a single host (192.168.1.50), permits the rest of the 192.168.1.0/24 subnet, denies the entire 10.0.0.0/8 range, then permits everything else. Because standard ACLs are evaluated top-down, the permit any at the end overrides the implicit deny-all, which is common when you want to log denied traffic without actually blocking it (add the log keyword to any deny statement). Applying the ACL outbound on GigabitEthernet0/1 means packets routed toward that interface are filtered after the routing decision.

Placement is critical: standard ACLs should sit as close to the destination as possible. If you place a standard ACL inbound on a core router interface and deny 10.0.0.0/8, you inadvertently block that entire range from reaching any destination, not just the intended target. In the best CCNA course in Bangalore, we drill this with a three-router topology where misplaced ACLs break OSPF adjacencies or SSH access, forcing students to troubleshoot with show ip interface and show access-lists until the logic clicks.

Configuring Extended ACLs for Granular Filtering

Extended ACL syntax adds protocol and destination fields: access-list number {permit | deny} protocol source [source-wildcard] [operator port] destination [destination-wildcard] [operator port] [options]. Protocol can be ip (any IP traffic), tcp, udp, icmp, eigrp, ospf, or a protocol number. Operators include eq (equal), neq (not equal), lt (less than), gt (greater than), and range.

Router(config)# access-list 100 permit tcp 192.168.10.0 0.0.0.255 any eq 443
Router(config)# access-list 100 permit tcp 192.168.10.0 0.0.0.255 any eq 80
Router(config)# access-list 100 permit udp any eq 53 192.168.10.0 0.0.0.255
Router(config)# access-list 100 permit icmp any any echo-reply
Router(config)# access-list 100 deny ip any any log
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group 100 in

This extended ACL permits the 192.168.10.0/24 subnet to initiate HTTPS and HTTP to any destination, allows DNS replies (UDP source port 53) back to that subnet, permits ICMP echo-reply (ping responses) from anywhere, then logs and denies all other IP traffic. The explicit deny ip any any log makes the implicit deny visible in logs, which is invaluable during security audits. Applying it inbound on GigabitEthernet0/0 filters traffic as it enters the router, conserving bandwidth on denied flows.

Extended ACLs belong close to the source to prevent unwanted traffic from traversing the network. For example, if a branch office should never send Telnet (TCP 23) to the data center, place the deny rule inbound on the branch router's WAN interface rather than outbound on the data center router, saving WAN bandwidth and core router CPU. Cisco India network architects follow this principle religiously; during technical interviews at Movate and Wipro, candidates who suggest placing extended ACLs near the destination are immediately flagged as lacking production experience.

Named ACLs and Sequence Number Editing

Named ACLs improve manageability in large environments. Instead of access-list 100 permit..., you enter ACL configuration mode with ip access-list {standard | extended} name, then add entries that automatically receive sequence numbers in increments of 10. You can later insert a new rule between existing entries by specifying the desired sequence number.

Router(config)# ip access-list extended OFFICE-FILTER
Router(config-ext-nacl)# 10 permit tcp 10.20.0.0 0.0.255.255 any eq 443
Router(config-ext-nacl)# 20 permit udp any eq 53 10.20.0.0 0.0.255.255
Router(config-ext-nacl)# 30 deny ip any any log
Router(config-ext-nacl)# exit
Router(config)# interface GigabitEthernet0/2
Router(config-if)# ip access-group OFFICE-FILTER in

To insert a new rule permitting SSH between lines 10 and 20, re-enter the named ACL and specify sequence 15:

Router(config)# ip access-list extended OFFICE-FILTER
Router(config-ext-nacl)# 15 permit tcp 10.20.0.0 0.0.255.255 any eq 22

Named ACLs also support the remark keyword for inline comments: remark Allow HTTPS for SaaS applications. In our 4-month paid internship, trainees inherit a production-like named ACL with 60 entries and must insert a new rule, delete an obsolete entry, and add remarks—all without disrupting traffic. This mirrors change-control workflows at Infosys and TCS, where ACL modifications require peer review and rollback plans.

Common ACL Pitfalls and CCIE Interview Gotchas

The implicit deny-all at the end of every ACL catches beginners off guard. If you create an ACL with only deny statements and apply it, all traffic is blocked because nothing explicitly permits flows. Always end with permit ip any any (extended) or permit any (standard) if you intend default-allow behavior, or accept that the implicit deny will drop everything else.

Order matters absolutely. Because IOS evaluates ACLs top-down and stops at the first match, placing permit ip any any as the first entry renders all subsequent deny rules useless. During CCIE Security lab exams and interviews at Barracuda Networks India, candidates are given intentionally misordered ACLs and asked to identify why certain traffic is unexpectedly permitted or denied. The fix is always to reorder entries from most specific to least specific.

Wildcard mask confusion is the second-most common error. A subnet mask of 255.255.255.0 translates to wildcard 0.0.0.255, not 255.255.255.0. The formula is simple: wildcard = 255.255.255.255 minus subnet mask. Forgetting this inverts the match logic, permitting the wrong hosts. In our HSR Layout lab, we force students to calculate wildcards manually before using the show access-lists command to verify, building muscle memory that survives high-pressure interviews.

Applying an ACL to the wrong direction or interface is trivial to do and catastrophic in production. An inbound ACL on a LAN interface filters traffic from users toward the router; an outbound ACL on the same interface filters traffic from the router toward users. Mixing these up can lock administrators out of SSH or block routing protocol hellos. Always test ACL changes in a maintenance window with console access available, and use show ip interface interface to confirm which ACLs are applied and in which direction.

Finally, ACLs do not filter traffic originated by the router itself. If the router generates SNMP traps or syslog messages, outbound ACLs on its interfaces will not block them. This surprises candidates in troubleshooting scenarios where they expect an ACL to stop the router's own traffic but it continues unimpeded.

Real-World ACL Deployment Scenarios

At Cisco India branch offices, extended ACLs on WAN interfaces enforce security policies: deny inbound Telnet and HTTP management protocols, permit only SSH (TCP 22) and HTTPS (TCP 443) from headquarters subnets, allow EIGRP and OSPF for routing, permit established TCP sessions for return traffic, and log everything else. This layered approach reduces attack surface without requiring a separate firewall appliance at small sites.

Aryaka SD-WAN edge routers use ACLs in conjunction with policy-based routing (PBR) to steer SaaS traffic (Office 365, Salesforce) directly to the internet while routing internal application traffic through MPLS. An extended ACL matches destination IP ranges published by Microsoft and Salesforce, then a route-map references that ACL to set the next-hop to the ISP gateway. Our founder Vikas Swami architected similar logic in QuickSDWAN, where ACLs classify traffic into bronze/silver/gold tiers before applying QoS marking and path selection.

In service provider environments, standard ACLs protect routing protocol peering: access-list 10 permit 203.0.113.0 0.0.0.255 applied to a BGP neighbor statement ensures only the peer's subnet can establish BGP sessions, mitigating route injection attacks. Extended ACLs on customer-facing interfaces implement anti-spoofing by denying inbound packets with source addresses from RFC 1918 private ranges or the provider's own public space, a technique mandated by CERT-In for Indian ISPs.

During the 4-month paid internship at our Network Security Operations Division, trainees deploy ACLs on live customer routers under supervision, learning to balance security with operational access. A common task is creating a "management ACL" that permits SSH from the NOC subnet and denies it from everywhere else, then applying it to VTY lines with access-class number in. This protects the control plane without impacting data plane traffic, a distinction that interviewers at Akamai India probe deeply.

How ACLs Integrate with NAT, VPNs, and QoS

ACLs are not standalone; they interlock with nearly every Cisco feature. Network Address Translation (NAT) uses ACLs to define "interesting traffic"—the source addresses eligible for translation. A typical inside-to-outside NAT configuration includes ip nat inside source list 1 interface GigabitEthernet0/0 overload, where access-list 1 specifies which internal hosts can share the outside interface's public IP via Port Address Translation (PAT).

Site-to-site IPsec VPNs rely on "crypto ACLs" to identify traffic that should be encrypted and sent through the tunnel. For example, access-list 110 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 tells the router that packets from 192.168.1.0/24 to 192.168.2.0/24 trigger IPsec encapsulation. If the crypto ACL is too broad (e.g., permit ip any any), the router attempts to encrypt all traffic including internet-bound flows, breaking connectivity. CCNA candidates in our CCNA study guide labs troubleshoot this exact misconfiguration weekly.

Quality of Service (QoS) policies use class-maps that reference ACLs to classify traffic into priority queues. A class-map might match access-list 120, which permits UDP ports 16384–32767 (RTP voice), then a policy-map assigns that class to the priority queue with guaranteed bandwidth. This is how Cisco Unified Communications Manager deployments at HCL and IBM India ensure voice quality over congested WAN links.

Policy-based routing (PBR) also depends on ACLs: a route-map's match ip address acl clause selects packets, then set ip next-hop overrides the routing table. This enables per-application path selection in dual-ISP scenarios, where an ACL matching streaming video (TCP 1935, UDP 3478) sends that traffic via the higher-bandwidth ISP while default traffic uses the lower-cost link.

ACL Troubleshooting Commands and Techniques

The show access-lists command displays all configured ACLs with hit counters for each entry, revealing which rules are actively matching traffic. Zero hits on a permit statement suggest the rule is redundant or shadowed by an earlier entry. Non-zero hits on the implicit deny (visible only if you add an explicit deny ip any any at the end) indicate blocked traffic that may be legitimate, prompting ACL refinement.

Router# show access-lists 100
Extended IP access list 100
    10 permit tcp 192.168.10.0 0.0.0.255 any eq 443 (1523 matches)
    20 permit udp any eq 53 192.168.10.0 0.0.0.255 (487 matches)
    30 deny ip any any log (34 matches)

The show ip interface interface command confirms which ACL is applied inbound or outbound. Look for the lines "Outgoing access list is 100" or "Inbound access list is not set." Mismatches between intended and actual ACL application are the top cause of ACL-related outages.

Packet capture with debug ip packet acl detail shows real-time ACL evaluation, but this command is CPU-intensive and should be used only in lab or during controlled troubleshooting windows. In production, enable ACL logging (log keyword) and monitor syslog for denied packets, then correlate timestamps with user complaints to identify false positives.

The clear access-list counters command resets hit counters to zero, useful when testing ACL changes. After modifying an ACL, clear counters, generate test traffic, then check show access-lists again to verify the new rule is matching as expected. In our HSR Layout lab, students run this sequence dozens of times per session until the troubleshooting workflow becomes instinctive.

ACLs in the CCNA 200-301 Exam Blueprint

The CCNA 200-301 exam dedicates approximately 8 percent of questions to ACL configuration, placement, and troubleshooting under the "Security Fundamentals" domain. Expect multiple-choice questions asking you to identify the correct wildcard mask for a given subnet, drag-and-drop exercises to order ACL entries for desired behavior, and simlets where you configure a named extended ACL on a router topology and verify with show commands.

Cisco's official exam topics include "Configure and verify access control lists," "Describe the purpose of ACLs," and "Identify the appropriate ACL type (standard vs. extended) for a given requirement." The simlet typically provides a three-router topology with specific filtering requirements—e.g., "Prevent VLAN 20 from accessing the 10.1.1.0/24 management subnet but allow all other traffic"—and you must choose standard or extended, calculate the wildcard, apply the ACL to the correct interface and direction, then answer follow-up questions about traffic flow.

Candidates who complete the best CCNA course in Bangalore at Networkers Home practice 40+ ACL scenarios in our physical lab, including intentionally broken configurations that mirror exam tricks: an ACL applied outbound when it should be inbound, a wildcard mask that's off by one bit, or a missing permit any that blocks all traffic. This repetition builds the pattern recognition needed to score full marks on ACL questions in under two minutes per question.

The NHPREP.COM mock test platform, free for 12 months with enrollment, includes 150+ ACL-focused questions with detailed explanations. Each wrong answer triggers a remediation link back to this chapter and related CCNA study guide sections, creating a closed-loop learning system that our 45,000+ placed alumni credit for their first-attempt pass rates.

Frequently Asked Questions About CCNA ACL Labs

What is the difference between inbound and outbound ACL application?

An inbound ACL filters packets as they arrive at an interface, before the routing decision. If denied, the packet is dropped immediately and never enters the routing table lookup process. An outbound ACL filters packets after the routing decision, just before they exit an interface. Outbound ACLs are useful for controlling traffic leaving a network segment, but they consume router CPU for the routing lookup even if the packet is ultimately denied. For security and bandwidth conservation, place extended ACLs inbound near the source; place standard ACLs outbound near the destination.

Can I edit a numbered ACL without deleting it entirely?

No. Numbered ACLs (standard 1–99, extended 100–199) do not support mid-list insertion or deletion. To modify a numbered ACL, you must remove it with no access-list number, which deletes all entries, then recreate it from scratch. This is why production networks use named ACLs exclusively: named ACLs assign sequence numbers (default increment 10) to each entry, allowing you to insert a new rule at sequence 15 or delete sequence 20 without touching other lines. Convert numbered ACLs to named format before deploying in any environment where change control matters.

Why does my ACL block all traffic even though I only added deny statements?

Every Cisco ACL ends with an implicit deny ip any any that is invisible in the configuration but always present. If your ACL contains only deny statements, the implicit deny at the end blocks everything that wasn't explicitly denied earlier—which is everything. To allow traffic, you must include at least one permit statement. For a default-allow posture, end your ACL with permit ip any any (extended) or permit any (standard). For default-deny, omit the final permit and accept that the implicit deny will drop all unmatched traffic.

How do I calculate the wildcard mask for a /26 subnet?

A /26 subnet has a subnet mask of 255.255.255.192. The wildcard mask is the bitwise inverse: subtract each octet of the subnet mask from 255. So 255 - 255 = 0, 255 - 255 = 0, 255 - 255 = 0, 255 - 192 = 63. The wildcard mask is 0.0.0.63. This wildcard matches any address in the /26 block because the last 6 bits (64 addresses minus network and broadcast) are "don't care" bits. Practice this arithmetic until it's instant; interviewers at Cisco India and Akamai expect you to convert CIDR to wildcard in under 10 seconds.

Can ACLs filter traffic originated by the router itself?

No. ACLs applied to interfaces filter only transit traffic—packets passing through the router from one interface to another. Traffic generated by the router's own control plane (OSPF hellos, SNMP traps, syslog messages, SSH sessions initiated by the router) bypasses interface ACLs entirely. To filter management access to the router, use a different mechanism: apply an ACL to VTY lines with access-class number in to control which source IPs can SSH or Telnet to the router. For control-plane protection, use Control Plane Policing (CoPP) on higher-end platforms.

What happens if I apply the same ACL inbound and outbound on the same interface?

The router evaluates the inbound ACL first, before routing. If the packet is permitted, the routing decision occurs, and if the exit interface is the same interface where the packet arrived (rare, but possible in certain NAT or loopback scenarios), the outbound ACL is evaluated next. If either ACL denies the packet, it is dropped. Applying the same ACL in both directions is usually redundant and doubles the processing overhead. In practice, you apply an ACL in one direction per interface based on your security policy: inbound to protect the network from external threats, outbound to prevent internal hosts from accessing restricted resources.

How do I allow ping (ICMP) through an extended ACL?

ICMP echo-request (ping) and echo-reply require separate permit statements because they are distinct ICMP message types. To allow hosts to ping external destinations and receive replies, use permit icmp source destination echo for outbound pings and permit icmp any any echo-reply for return traffic. If you only permit echo without echo-reply, pings will fail because the replies are blocked. A common mistake is permitting icmp any any, which allows all ICMP types including redirect and unreachable messages that can be exploited for reconnaissance. Be specific: permit only echo and echo-reply unless your security policy requires other ICMP types.

Where should I place a standard ACL to block a single host from accessing a server?

Place the standard ACL as close to the destination (the server) as possible, applied outbound on the interface nearest the server or inbound on the server's gateway interface. Standard ACLs filter only on source IP, so if you place the ACL near the source (the host), you block that host from reaching any destination, not just the server. For example, if the server is on 10.1.1.0/24 and the host is 192.168.1.50, apply access-list 10 deny host 192.168.1.50 then access-list 10 permit any outbound on the router interface connected to 10.1.1.0/24. This blocks only traffic from 192.168.1.50 to that subnet, leaving the host's access to other subnets intact.