Advanced IPv4 Access Control Lists (CCNA 200-301)

Ever had that moment at 2 a.m. where you’re the only thing standing between your company and a rogue user blowing up your network because someone forgot to implement any sort of access control? I’ve been there more times than I care to admit. One of my earliest “learning experiences” as a junior admin was when I misapplied an ACL on a production router and suddenly nobody could get to the payroll server. The phone calls started instantly. My mentor at the time told me, “If you don’t respect ACLs, they’ll teach you to.” He was right—fast forward sixteen years and I’m still learning little nuances about these deceptively simple lists. Let’s dig in and make sure you’re the one teaching ACLs, not the other way around.

Why Mastering Advanced IPv4 ACLs Matters (Both For CCNA and Real Life)

You might see access control lists (ACLs) as just another line item on the CCNA checklist, but let me tell you, mastering them is key if you want to protect your network—and, honestly, your job. Whether you're knee-deep in CCNA 200-301 prep or juggling the demands of a live network, ACLs are your go-to defense—be it firewalls, segmentation, compliance checks, you name it, ACLs have got you covered.

For the CCNA, you’re guaranteed to see questions on both standard and extended IPv4 ACLs: configuration, placement, troubleshooting, and theory. Many candidates trip up because they memorize configs but don’t really understand how packets are processed, how wildcard masks work, or what “implicit deny” really means. We’re going beyond memorization to get you confident enough to handle anything Cisco (or a cranky auditor) throws your way.

ACL Fundamentals: What, Why, and How

First things first: What is an ACL, really? In practice, think of an ACL as a traffic cop stationed at an intersection. Every packet rolling up gets checked against a rulebook—the ACL—to see if it’s allowed through or not. Sure, they might look simple, but don't let that fool you—they've got some serious power behind them.

• Security: Blocking unauthorized access, segmenting traffic, enforcing policies.
• Traffic Control: Limiting bandwidth, prioritizing services, filtering protocols and application access.

Cisco divides ACLs into two main types—standard and extended. Here’s a quick breakdown:

• Standard ACLs: Filter by source IP only. They're blunt instruments—good for basic restrictions, such as management plane access, but can't do port- or protocol-level filtering on routed data paths.
• Extended ACLs: Far more granular. Filter by source and destination IP, protocol (TCP, UDP, ICMP), and even specific ports. This gives you precise control over traffic flows.

ACL Types and Number Ranges

Named ACLs can be either standard or extended. They are easier to manage, support sequence numbers, and are preferred for all but the simplest scenarios.

Top-Down Processing, Statement Order, and the Dreaded Implicit Deny

Here’s a key thing a lot of folks miss: ACLs process rules from top to bottom. The first matching permit or deny wins—after that, the packet’s fate is sealed. If nothing matches, there’s an implicit deny any at the end (even though you don’t see it in your config). This is one of the most common gotchas in the field and on the exam.

Think of it like airport security: first you check for a boarding pass (permit trusted users), then for restricted items (deny certain apps), and if someone doesn’t match any rule… sorry, you’re not getting on the plane.

ACL Application: Directions and Default Behavior

• Inbound (in): Packets are filtered before they’re routed. Used to block or allow traffic as soon as it enters an interface.
• Outbound (out): Packets are filtered after routing, just before exiting an interface.

By default, if no ACL is applied to an interface, all traffic is permitted. Here's the kicker: you can stick just one ACL on each protocol per direction per interface. So, you'll have one for IPv4 traffic coming in, another one for IPv4 traffic heading out, and so on.

Important: ACLs applied to an interface only filter traffic passing through the router. Traffic originated by the router (such as pings, traceroutes, routing updates) is not filtered by interface ACLs, unless you use features like control-plane ACLs or access-class on VTY lines.

Calculating and Using Wildcard Masks

Wildcard masks trip up a lot of people, even seasoned pros. Why not just use subnet masks? Well, Cisco borrowed this “reverse mask” idea from OSPF and it stuck. Wildcard masks tell the router which bits to care about and which to ignore—“0” means exact match, “1” means don’t care.

Rule: Wildcard mask = Inverse of the subnet mask. You simply take each piece of the subnet mask, lop it off from 255, and voilà!

Let's walk through it one step at a time, with some examples to keep us on track.

Practice: Convert 255.255.254.0 to a wildcard mask.
255–255=0, 255–255=0, 255–254=1, 255–0=255 ⇒ 0.0.1.255

Now, when do you actually roll these masks out? If you're setting your sights on just one host, a wildcard mask like 0.0.0.0 is your ticket. For an entire /24 subnet, you want to reach for 0.0.0.255. For ranges within a subnet, say even-numbered hosts, you'll get crafty with something like 0.0.0.254.

Keep an eye out for these trip-ups.

• Don't confuse subnet masks with wildcard masks—they're like night and day!
• Practice converting both ways—it's a favorite CCNA exam trick.
• Use the host keyword for clarity (e.g., permit ip host 192.168.1.5 any).

Wildcard Mask Drill:
Can you figure out the wildcard mask for each of these subnet masks?

• 255.255.252.0 = 0.0.3.255
• 255.255.255.248 = 0.0.0.7
• 255.255.254.0 = 0.0.1.255
• 255.255.255.192 = 0.0.0.63

Standard IPv4 ACLs: Blunt but Useful

Standard ACLs only inspect the source IP address. They don’t care about destination, protocol, or port. This means they’re great for simple “allow/deny this host or subnet” scenarios, especially for management plane (VTY, SNMP, etc.) or very basic segmentation. Do not use standard ACLs for traffic filtering on routed data paths in modern best practices—use extended ACLs instead.

Practical uses:

• Locking down access to management interfaces like VTY lines
• Basic network segmentation
• Filtering SNMP or backup traffic

Standard ACL Configuration Examples

Example 1: Numbered Standard ACL

! Shut down access for host 192.168.1.100, but let everyone else slide on through. access-list 10 puts up a 'No Entry' sign for 192.168.1.100. access-list 10 permit any ! interface GigabitEthernet0/1 ip access-group 10 in

Example 2: Named Standard ACL

ip access-list standard BLOCK_PRINTER block 192.168.10.50 permit any ! interface GigabitEthernet0/2 ip access-group BLOCK_PRINTER out

Editing Numbered ACLs with Sequence Numbers (Newer IOS):

Here's your standard access-list: 10 5 lockdown on 192.168.1.100 10 permit any

In modern Cisco IOS, you can edit numbered ACLs with sequence numbers (as above), not just named ACLs.

Tip: Always add a “permit any” at the end (unless you want to block all traffic; remember the implicit deny).

Setting Up Standard ACLs: Inbound Against Outbound

You can slap an ACL on either inbound, as packets roll in, or outbound, as they head out. For management plane filtering (like VTY lines), use access-class instead of access-group:

line vty 0 4 access-class BLOCK_PRINTER in

For data plane, apply to the interface:

interface GigabitEthernet0/0 ip access-group 10 in

Key Point: Inbound ACLs check packets as they arrive on the interface, outbound as they leave. Always check the direction and test things out before applying them widely.console access is your friend!).

Common Pitfalls With Standard ACLs (And How To Dodge Them)

• Applying to the wrong interface or direction.
• Forgetting “permit any” at the end—leading to a total block (implicit deny).
• Not documenting why you created the ACL—future you will be confused.
• Trying to use standard ACLs for advanced filtering (ports, protocols)—use extended instead.

Key Points: Standard ACLs are best for management plane access. Go for named ACLs and throw in some comments to keep things clear. Aim to put them as close to the destination as you can.

Extended IPv4 ACLs: Precision Control

Extended ACLs give you the upper hand—you can filter according to protocol, source and destination IPs, and even dive down to port numbers. Need to greenlight HTTP/HTTPS to a server farm, shut down Telnet, or curb ICMP? No sweat! Extended ACLs let you do all that with precision and power.

Extended ACLs are your best bet for traffic filtering on routed interfaces, splitting up networks, and locking things down by protocol or port.

Here's a peek at some Extended ACL Configs (just a taste of numbered and named).

Example 1: Numbered Extended ACL

! Roll out the red carpet for HTTP traffic heading to 192.168.20.50, but slam the brakes on everything else. access-list 101 opens the gates for TCP traffic from anywhere straight to host 192.168.20.50 on port 80. access-list 101 gives the nod to TCP traffic to 192.168.20.50, but this time on port 443. access-list 101 slams the door on any other IP traffic ! interface GigabitEthernet0/3 ip access-group 101 in

Example 2: Named Extended ACL

ip access-list extended WEB_ONLY 10 let TCP traffic sail from 10.10.10.0/24 to 192.168.30.0/24 on port 80. 20 deny ip any any ! interface GigabitEthernet0/4 ip access-group WEB_ONLY in

Dissecting: permit tcp any host 192.168.20.50 eq 80 allows TCP traffic from any source to 192.168.20.50 on port 80 only.

Using Extended ACLs in Real Life

• Allowing only specific subnets to reach sensitive servers (e.g., finance to payroll DB on port 3306)
• Blocking social media for a campus, but allowing business apps
• Rate-limiting ICMP to prevent ping floods
• Allowing only specific API traffic between business units

Order matters! Always review your statement order. A “deny” before a required “permit” can break business-critical traffic.

Statement Order, Performance, and Security Implications

• First-match wins. Put most-specific “deny” or “permit” statements first.
• Place common matches near the top for performance—saves router CPU, especially on busy networks.
• For troubleshooting, use an explicit “deny ip any any log” at the end (and remove for production!)
• Avoid over-permitting—“permit ip any any” nullifies your ACL.

Extended ACL Placement Diagram

[User LAN]----[Router Gi0/1]----[DMZ/Web Servers] |                | [Router Gi0/2]   (Extended ACL on Gi0/1 inbound) | [Admin LAN]

By placing the extended ACL inbound on Gi0/1, you filter traffic from the User LAN before it even gets routed to the DMZ, reducing unwanted traffic and logging events.

ACL Logging and Monitoring

Logging helps you observe which packets match your ACL rules, which is invaluable for troubleshooting and security monitoring. Use the log keyword to enable syslog messages for specific ACL entries.

access-list 120 blocks TCP traffic on port 23 and logs the activity access-list 120 graciously allows any other IP traffic

Or in a named ACL:

ip access-list extended MONITOR_BLOCKS 10 deny ip any any log

Where does the log go? Log messages appear on the console and can be sent to a syslog server (if configured). You can view them in real time with terminal monitor or check the log buffer with show logging.

Sample syslog log entry:
%SEC-6-IPACCESSLOGP: list 120 denied tcp 10.1.1.10(1025) -> 10.2.2.20(23), 1 packet

Performance impact: Logging every match (especially on “deny ip any any log”) can spike CPU and flood logs—use judiciously. For busy networks, log only critical denies or during troubleshooting.

Advanced ACL Features

Time-Based ACLs

Time-based ACLs allow you to activate/disable access based on time of day or day of week. Use time-range objects:

time-range we can label as BUSINESS_HOURS on regular weekdays from 8 AM to 6 PM ! ip access-list extended OFFICE_WEB permit tcp any any eq 80 time-range we can label as BUSINESS_HOURS deny ip any any

Only permits web access during business hours.

Dynamic (Lock-and-Key) ACLs

Dynamic ACLs (“lock-and-key”) allow users to authenticate (e.g., via Telnet/SSH), which temporarily opens access. Rare today, but good for exam trivia.

Reflexive ACLs (Stateful Filtering)

Reflexive ACLs allow return traffic for sessions initiated from inside the network—adding basic statefulness. They're beyond CCNA 200-301 scope but worth knowing exist.

Object Groups and Remarks

Some platforms support object groups for grouping hosts/networks, and “remark” statements for documentation:

ip access-list extended SALES_ACCESS remark Allow sales subnet to CRM server give the green light for TCP traffic to cruise from 10.20.30.0/24 to the host 192.168.5.10 on port 443.

Always document your rules!

ACLs and Control Plane Protection

Standard/extended ACLs protect data plane traffic (traffic through the router). To protect the control plane (traffic to/from the router itself—VTY, SNMP, routing updates), use these:

• Access-class: Restricts management access (e.g., VTY lines)
• Control Plane Policing (CoPP): Advanced feature to limit/control traffic to the router's CPU (beyond CCNA, but good to know exists)

line vty 0 4 access-class MGMT_ONLY in

This prevents unauthorized hosts from even attempting SSH/Telnet to your router.

IPv6 ACLs Overview

Setting up IPv6 ACLs is a whole separate ballgame from IPv4 ACLs—they're configured and applied differently. Key differences:

• Use ipv6 access-list for configuration
• Applied with ipv6 traffic-filter
• Implicit permit for neighbor discovery (ICMPv6) traffic—don't accidentally block it!

ipv6 access-list to keep the GUESTS out block ipv6 traffic from 2001:db8:1::/64 heading anywhere permit ipv6 any any ! interface GigabitEthernet0/0 ipv6 traffic-filter BLOCK_GUESTS in

Exam tip: IPv6 ACLs are similar in logic, but syntax and traffic defaults differ.

Dive into Some Hands-on Lab Scenarios

Lab 1: Wildcard Mask Calculation and Application

Scenario: Permit only subnet 172.16.8.0/21 to access a server.

• For this one, you're dealing with a subnet mask of 255.255.248.0, so your wildcard mask turns into 0.0.7.255.

access-list 20 rolls out the welcome mat for 172.16.8.0/21 using the wildcard 0.0.7.255

Practice: Convert and configure for 192.168.100.64/26.

It's got a subnet mask of 255.255.255.192, which converts to a wildcard of 0.0.0.63. access-list 21 gives the nod to 192.168.100.64 with a wildcard of 0.0.0.63

Lab 2: Standard ACL – Restrict Host Access

Scenario: Only IT admin PC (192.168.10.10) should access VTY lines (Telnet/SSH). All others denied.

[Admin PC]---[Switch]---[Router Gi0/0] |                        | [Other PCs]                 | access-list 15 lets 192.168.10.10 through the gate access-list 15 deny any ! line vty 0 4 access-class 15 in

Verification:

Router# show access-lists 15 Standard IP access list 15 10 allow 192.168.10.10 20 deny any

Test by connecting via SSH/Telnet from allowed and denied PCs.

Troubleshooting Gotcha: If you forget to “permit” the admin PC before the “deny any,” nobody can connect—including you. Always keep a console session open!

Lab 3: Extended ACL – Control Web Traffic

Scenario: Allow only HTTP/HTTPS from Engineering subnet (10.0.20.0/24) to a web server (192.168.50.100), block everything else.

[Engineering LAN]---[Router Gi0/1]---[Internet] | [Web Server] ip access-list extended ENG_WEB_ONLY permit tcp 10.0.20.0 0.0.0.255 host 192.168.50.100 eq 80 permit tcp 10.0.20.0 0.0.0.255 host 192.168.50.100 eq 443 deny ip any any log ! interface GigabitEthernet0/1 ip access-group ENG_WEB_ONLY in

Verification: Try accessing the web server from the Engineering LAN (should work); ping or use other ports (should fail). Check syslog for denied packets due to the log keyword.

Troubleshooting Gotcha: ICMP is not TCP/UDP. If you want to allow pings, add permit icmp 10.0.20.0 0.0.0.255 host 192.168.50.100.

Lab 4: Time-Based ACLs

Scenario: Permit database access (port 3306) from 10.5.5.0/24 only during backup window (midnight-2am Sundays).

time-range BACKUP_WINDOW periodic Sunday 0:00 to 2:00 ! ip access-list extended DB_BACKUP permit tcp 10.5.5.0 0.0.0.255 host 192.168.100.10 eq 3306 time-range BACKUP_WINDOW deny ip any any ! interface GigabitEthernet0/2 ip access-group DB_BACKUP in

Scenario: Logging and Monitoring

Scenario: Log all denied access attempts to a sensitive subnet.

ip access-list extended SENSITIVE_LOG permit ip any 10.100.10.0 0.0.0.255 deny ip any any log ! interface Vlan50 ip access-group SENSITIVE_LOG in

On the router, enable logging and monitor:

conf t logging buffered 4096 logging trap informational end show logging | include access-list

Performance warning: Too many logs can impact CPU—log only as needed.

Integration Scenarios and Real-World Applications

ACLs and NAT Integration

Order of Operations: For traffic entering an interface, the ACL is checked before NAT is applied. For outbound traffic, NAT is done before the ACL is checked on egress.

ip nat inside source list 22 interface GigabitEthernet0/0 overload access-list 22 permit 10.0.0.0 0.0.0.255

You can use ACLs to define which traffic is eligible for NAT, or to exempt certain subnets (NAT exemption).

ACLs and VPNs

To restrict which IPs can access a VPN tunnel, use an ACL as the “interesting traffic” for the crypto map:

access-list 110 permit ip 10.10.10.0 0.0.0.255 10.20.20.0 0.0.0.255 crypto map VPN-MAP 10 match address 110

ACLs and Routing Protocols

Filter which networks are advertised or received:

access-list 40 deny 192.168.1.0 0.0.0.255 access-list 40 permit any router ospf 1 distribute-list 40 out

This prevents OSPF from advertising the 192.168.1.0/24 network.

ACLs and VLANs/SVIs

Apply ACLs to switched virtual interfaces (SVIs) to control inter-VLAN routing:

interface Vlan30 ip access-group OPS_ACL in

Troubleshooting and Diagnostics

Verification Commands & Sample Outputs

• show access-lists – Lists all ACLs and hit counts.
• show running-config – Shows ACLs and where they’re applied.
• show ip interface – Confirms ACL applied to interface, in/out direction.
• show logging – Displays log buffer (for ACL log messages).
• show access-lists NAME – Shows specific ACL.

Router# show access-lists 110 Extended IP access list 110 10 deny tcp any any eq 23 (25 matches) 20 permit ip any any (150 matches)

Debugging: For advanced troubleshooting (be careful in production!):

debug ip packet detail undebug all

Packet captures: On some platforms, use monitor capture or SPAN ports to see which packets hit which ACL rules.

Advanced Troubleshooting Methodology

• Is the ACL applied to the correct interface and direction?
• Are the wildcard masks correct?
• Is the statement order correct (specific before general)?
• Is there an implicit deny blocking traffic?
• Check ACL hit counters—are packets hitting the expected statements?
• Look for typos—host vs. network, eq vs. range, protocol mismatches.
• Verify router-originated traffic (may require control-plane ACLs).

Decision Tree:

1. Confirm ACL is applied to interface (show run / show ip interface)
2. Identify traffic flow (source/destination, protocol, port)
3. Review ACL statements, order, and wildcard masks
4. Check hit counts (show access-lists)
5. Test from both permitted and denied sources
6. Adjust, document, and retest

Scenario: Troubleshooting “Locked Out” Situations

Situation: You applied “deny any any” too early in your ACL and locked yourself out remotely.

• Try to access via console port
• Remove or modify the ACL to permit your management IP
• Always keep console access available when making changes!

Performance, Security, and Scalability Considerations

It’s tempting to pile on ACL rules, but this can slow down your router—especially older gear. Each packet must be matched against every statement, top-down, until a match is found.

• Put your most likely matches first—drop “bad actors” immediately, permit trusted hosts up top.
• Keep ACLs lean—review and remove obsolete statements regularly.
• Monitor ACL hit counts to check effectiveness.
• On some platforms, ACLs are processed in hardware (TCAM) for speed. On others, long ACLs can consume CPU—check your device documentation.
• Never end with “permit ip any any” unless you really mean it. It will defeat your security.
• Use log options judiciously—too much logging can crush your CPU and fill up storage fast.
• In very large environments, use hierarchical ACL design or object groups (if supported) for maintainability.

Security note: Standard and extended ACLs are stateless—they only check each packet individually (no tracking of sessions). For stateful filtering, use firewalls or reflexive ACLs. Always pair ACLs with defense-in-depth: firewalls, segmentation, and monitoring.

Platform alert: IOS, IOS XE, NX-OS, and other Cisco operating systems have different ACL feature sets and processing capabilities. Check platform docs for hardware acceleration support, max ACL size, and syntax differences.

Key Points:

• Order statements by match frequency and specificity for performance.
• Document all rules—use remarks and change management.
• Regularly audit ACLs for compliance and effectiveness.

ACL Limitations and Alternatives

• ACLs cannot filter traffic originated by the router (use control-plane features).
• Stateless—cannot track sessions (use firewalls or reflexive ACLs for stateful needs).
• Complex, large-scale rulesets become hard to manage—consider Cisco’s Security Group Tags, zone-based firewalls, or automation tools for large deployments.

Case Study: Branch Office Security with Multiple ACLs

Let’s pull it all together. Picture a branch office with multiple subnets, inter-VLAN routing, and strict PCI DSS compliance requirements.

Requirements Gathering

• Finance VLAN (10.10.10.0/24) – access to HQ servers only, no internet.
• Guest VLAN (10.10.20.0/24) – internet access only, no internal resources.
• Operations VLAN (10.10.30.0/24) – access to HQ and internet but not to Finance.

[Finance VLAN]---+ [Guest VLAN]-----|Switch|---[Router]---[Internet] [Ops VLAN]-------+       | [HQ WAN]

Configuration Blocks

! Finance VLAN: Deny all except HQ servers (192.168.100.0/24) ip access-list extended FINANCE_ACL permit ip 10.10.10.0 0.0.0.255 192.168.100.0 0.0.0.255 deny ip 10.10.10.0 0.0.0.255 any log ! interface Vlan10 ip access-group FINANCE_ACL in ! Guest VLAN: Deny all internal, permit internet ip access-list extended GUEST_ACL deny ip 10.10.20.0 0.0.0.255 10.0.0.0 0.255.255.255 log permit ip 10.10.20.0 0.0.0.255 any ! interface Vlan20 ip access-group GUEST_ACL in ! Ops VLAN: Deny Finance, permit all else ip access-list extended OPS_ACL deny ip 10.10.30.0 0.0.0.255 10.10.10.0 0.0.0.255 log permit ip 10.10.30.0 0.0.0.255 any ! interface Vlan30 ip access-group OPS_ACL in

Integration and Verification

• ACLs on SVI interfaces control inter-VLAN and external access.
• NAT overload applies to Guest and Ops VLANs only (not Finance).
• All ACLs are documented and reviewed quarterly per PCI DSS.

Verification:

Router# show access-lists FINANCE_ACL Extended IP access list FINANCE_ACL 10 permit ip 10.10.10.0 0.0.0.255 192.168.100.0 0.0.0.255 20 deny ip 10.10.10.0 0.0.0.255 any log (2 matches)

Troubleshooting Scenario

Issue: Guest VLAN users report they can access Finance VLAN resources.

• Check GUEST_ACL for missing or incorrect deny statements.
• Verify direction (should be inbound on Vlan20).
• Check for wildcard mask mistakes.
• Review hit counters for the deny rule.

Lessons learned: Always test ACLs from both allowed and denied sources, and check logs for unexpected matches.

Case Study Key Points:

• Layered, properly documented ACLs enable compliance and security.
• Regular review and verification is required post-implementation.
• Logging and hit counters are invaluable for troubleshooting and audits.

Automation and Template Use

For large deployments, consider automating ACL management:

• Use configuration templates with variables for subnets/hosts.
• Leverage tools like Ansible, Nornir, or Python scripts to deploy and audit ACLs.
• Export ACL configs and documentation for compliance and change review.

Automation reduces errors, ensures consistency, and speeds up change management for complex environments.

Summary & Key Takeaways

• ACLs are foundational for security and traffic management in Cisco networks.
• Standard ACLs filter by source IP—ideal for management plane, not data plane filtering.
• Extended ACLs provide granular control by source, destination, protocol, and port—use for routed interfaces and traffic control.
• Order matters: first-match wins, and there’s an implicit deny at the end.
• Wildcard masks are NOT subnet masks—practice conversions for the exam and real life.
• Named ACLs (standard or extended) are more maintainable—use sequence numbers and remarks.
• Use logging for visibility, but be mindful of performance impacts.
• Document every rule, regularly review, and always test before and after changes.
• Know ACL limitations—stateless, can’t filter router-originated traffic, not a firewall replacement.
• Automate where possible for scale and compliance.

Pro tip: Hands-on practice in Packet Tracer, GNS3, or Cisco Modeling Labs is the only way to truly master ACLs.

Certification and Exam Guidance

Everything here maps directly to CCNA 200-301 objectives. Here’s what you need for the exam:

• Configure, verify, and troubleshoot standard and extended IPv4 ACLs—numbered and named
• Apply ACLs to interfaces with correct direction
• Interpret wildcard masks in ACLs
• Understand and troubleshoot ACL processing order and implicit deny
• Identify functional differences between numbered and named ACLs
• Recognize best practices for ACL placement and documentation

Sample CCNA-Style Questions

1. Which command applies an extended ACL named "SECURE" on an interface for inbound traffic?

• A. ip access-group SECURE out
• B. ip access-group SECURE in
• C. ip access-list extended SECURE in
• D. access-class SECURE in        Answer: B

1. What is the wildcard mask for the subnet 255.255.254.0?

• A. 0.0.1.255
• B. 0.0.0.255
• C. 0.0.2.255
• D. 0.0.0.1        Answer: A

1. In a standard numbered ACL, which number range is valid?

• A. 100–199
• B. 1–99, 1300–1999
• C. 2000–2699
• D. 1000–1099        Answer: B

1. What happens if you forget to add a “permit any” at the end of an ACL?

• A. All traffic is permitted
• B. Only the last rule is applied
• C. All other traffic is denied (implicit deny)
• D. The ACL is not used        Answer: C

Exam Simulation Walkthrough

Scenario: You are told to allow only SSH (TCP/22) access from subnet 192.168.1.0/24 to server 10.10.10.10, and block all other access.

1. Calculate wildcard mask: 255.255.255.0 → 0.0.0.255
2. Write the ACL: ip access-list extended SSH_ONLY permit tcp 192.168.1.0 0.0.0.255 host 10.10.10.10 eq 22 deny ip any any
3. Apply to interface: interface GigabitEthernet0/0 ip access-group SSH_ONLY in

Top 10 ACL Pitfalls on the CCNA Exam

1. Applying ACL in the wrong direction (in vs. out)
2. Wrong wildcard mask (subnet mask instead of wildcard, or vice versa)
3. Missing “permit” for necessary traffic (locked out!)
4. Order of statements—general before specific
5. Forgetting implicit deny at the end
6. Wrong ACL number/type (standard vs. extended)
7. Incorrect interface (applying to the wrong SVI/physical interface)
8. Misunderstanding “host” vs. “any” keywords
9. Not verifying with show commands
10. Not matching exam syntax exactly (typos, missing keywords)

Exam Prep Checklist

Downloadable Quick Reference Sheet

• ACL number ranges and meanings
• Wildcard mask conversion table
• Common configuration templates
• Top troubleshooting commands and checklist

Study tip: Practice writing both numbered and named ACLs by hand. Set up lab scenarios, break and fix configurations, and quiz yourself on wildcards and statement order.

Final Thoughts & Encouragement

You’ve probably noticed ACLs are part art, part science—and occasionally part black magic, especially when troubleshooting at 3 a.m. But once you’ve put in the hands-on practice and really internalized how these lists work, you’ll find yourself solving problems others can’t even spot. Don’t be afraid to experiment, ask questions, and share your own war stories. The best network engineers are always learning.

If you’re prepping for CCNA, keep at it. Practice, practice, practice—don’t just read configs, type them in, break them, fix them. If you’re working in production, never underestimate the power of a well-placed ACL—or the chaos of a careless one. Stay curious, stay careful, and always document everything.

See you on the wire!