Standard and Extended ACL Lab

Introduction

Access Control Lists (ACLs) are one of the most fundamental security and traffic-filtering tools available on Cisco routers. Every network engineer needs to understand how ACLs work, how to configure them, and where to apply them. Without ACLs, a router forwards every packet it receives without any filtering whatsoever — meaning any host on your network can reach any other host, any service, on any port. In production environments, that level of openness is unacceptable.

This lesson walks you through the two primary types of ACLs used on Cisco IOS routers: standard ACLs and extended ACLs. You will learn the differences between them, understand how the router processes ACL entries, configure both types in a hands-on lab topology, verify your work with show commands, and understand where each type should be applied. By the end of this lesson, you will be able to build ACLs that permit or deny traffic based on source address, destination address, protocol, and port number.

Key Concepts

What Is an Access Control List?

An Access Control List (ACL) is an ordered set of rules (called Access Control Entries, or ACEs) that a router evaluates against each packet passing through an interface. Each ACE specifies a condition and an action — either permit or deny. The router checks each packet against the ACEs from top to bottom. The first matching rule is applied, and no further rules are evaluated for that packet.

Important: Every ACL has an invisible implicit deny at the end. If a packet does not match any ACE in the list, it is dropped. You must always include at least one permit statement, or the ACL will block all traffic.

Standard vs. Extended ACLs

The two ACL types differ in what criteria they can match:

Feature	Standard ACL	Extended ACL
Number Range	1-99, 1300-1999	100-199, 2000-2699
Match Criteria	Source IP address only	Source IP, destination IP, protocol, port numbers
Granularity	Low — can only filter by who sent the packet	High — can filter by source, destination, protocol, and port
Placement	Close to the destination	Close to the source
Named ACL Keyword	`standard`	`extended`

Wildcard Masks

ACLs use wildcard masks instead of subnet masks to define which bits in an IP address must match. A wildcard mask is the inverse of a subnet mask:

Subnet Mask	Wildcard Mask	Meaning
255.255.255.0	0.0.0.255	Match the first three octets, ignore the last
255.255.255.255	0.0.0.0	Match all bits (single host)
255.255.0.0	0.0.255.255	Match the first two octets, ignore the last two

A 0 bit in the wildcard means "this bit must match."
A 1 bit in the wildcard means "this bit is ignored."

The keyword host is a shortcut for the wildcard mask 0.0.0.0, and the keyword any is a shortcut for 0.0.0.0 255.255.255.255.

How It Works

ACL Processing Logic

When an ACL is applied to a router interface, the router evaluates packets against the list in the following sequence:

The packet arrives on (or is about to leave) the interface where the ACL is applied.
The router compares the packet against the first ACE in the list.
If the packet matches, the router takes the specified action (permit or deny) and stops processing.
If the packet does not match, the router moves to the next ACE.
This continues until a match is found or the end of the list is reached.
If no ACE matches, the implicit deny drops the packet.

Inbound vs. Outbound Direction

An ACL is applied to an interface in one of two directions:

Inbound (in): The router evaluates the ACL before making a routing decision. If the packet is denied, it is dropped immediately and never enters the routing table lookup.
Outbound (out): The router evaluates the ACL after the routing decision, just before the packet is sent out the interface. If the packet is denied, it is dropped before being transmitted.

Placement Best Practices

Where you place an ACL on the network matters significantly:

Standard ACLs should be placed as close to the destination as possible. Because they can only match on source IP, placing them near the source would inadvertently block that source from reaching all destinations — not just the one you intend to protect.
Extended ACLs should be placed as close to the source as possible. Because they can match on source, destination, protocol, and port, they can precisely filter the unwanted traffic early, preventing it from consuming bandwidth across the network.

Configuration Example

Lab Topology

Consider the following topology for this lab:

Device	Interface	IP Address	Subnet Mask	Role
R1	GigabitEthernet0/0	192.168.10.1	255.255.255.0	LAN gateway (PC network)
R1	GigabitEthernet0/1	10.0.0.1	255.255.255.252	Link to R2
R2	GigabitEthernet0/0	10.0.0.2	255.255.255.252	Link to R1
R2	GigabitEthernet0/1	172.16.1.1	255.255.255.0	Server network
Server	NIC	172.16.1.100	255.255.255.0	Web and FTP server
PC1	NIC	192.168.10.10	255.255.255.0	End user workstation

Task 1: Standard ACL — Block a Specific Host

Block PC1 (192.168.10.10) from reaching the server network (172.16.1.0/24), while allowing all other traffic. Because this is a standard ACL, place it close to the destination.

Step 1: Create the standard ACL on R2.

R2(config)# access-list 10 deny host 192.168.10.10
R2(config)# access-list 10 permit any

The first line denies traffic from the single host 192.168.10.10. The second line permits everything else. Without the second permit statement, the implicit deny would block all traffic.

Step 2: Apply the ACL to the interface closest to the destination.

R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip access-group 10 out

The ACL is applied outbound on R2's GigabitEthernet0/1 interface, which faces the server network. This ensures that packets from PC1 are filtered just before they reach the servers, while PC1 can still reach other networks.

Step 3: Verify the ACL.

R2# show access-lists
Standard IP access list 10
    10 deny   host 192.168.10.10
    20 permit any

R2# show ip interface GigabitEthernet0/1
  Outgoing access list is 10
  Inbound  access list is not set

Task 2: Named Extended ACL — Permit Web, Deny FTP

Allow PC1 to access the web server (HTTP on port 80 and HTTPS on port 443) but deny FTP access (port 21) to the same server. Use a named extended ACL applied close to the source.

Step 1: Create the named extended ACL on R1.

R1(config)# ip access-list extended FILTER-FTP
R1(config-ext-nacl)# deny tcp host 192.168.10.10 host 172.16.1.100 eq 21
R1(config-ext-nacl)# permit tcp host 192.168.10.10 host 172.16.1.100 eq 80
R1(config-ext-nacl)# permit tcp host 192.168.10.10 host 172.16.1.100 eq 443
R1(config-ext-nacl)# permit ip any any

The first line denies TCP traffic from PC1 to the server on port 21 (FTP control).
The second and third lines permit TCP traffic from PC1 to the server on ports 80 (HTTP) and 443 (HTTPS).
The fourth line permits all other IP traffic so that the implicit deny does not block everything else.

Step 2: Apply the ACL inbound on R1's LAN-facing interface.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group FILTER-FTP in

Because this is an extended ACL, it is placed close to the source — on the interface where PC1's traffic enters the router.

Step 3: Verify the ACL.

R1# show access-lists
Extended IP access list FILTER-FTP
    10 deny   tcp host 192.168.10.10 host 172.16.1.100 eq ftp
    20 permit tcp host 192.168.10.10 host 172.16.1.100 eq www
    30 permit tcp host 192.168.10.10 host 172.16.1.100 eq 443
    40 permit ip any any

Best Practice: Use named ACLs whenever possible. Named ACLs are easier to read, easier to troubleshoot, and allow you to insert or remove individual ACEs without recreating the entire list.

Task 3: Verify Filtering with Ping and Telnet

After applying your ACLs, always test connectivity to confirm the expected behavior.

PC1> ping 172.16.1.100

If the standard ACL from Task 1 is active on R2, this ping should fail. If only the extended ACL from Task 2 is active, the ping should succeed because ICMP is permitted by the permit ip any any statement.

To test FTP filtering specifically:

PC1> telnet 172.16.1.100 21
Trying 172.16.1.100, 21 ...
% Connection refused by remote host

The connection to port 21 is refused because the extended ACL denies it. Testing against port 80 should succeed.

Real-World Application

Common Deployment Scenarios

ACLs are used extensively in production networks for a variety of purposes:

Perimeter security: Filtering traffic entering or leaving the network at the WAN edge. Extended ACLs block known malicious ports and protocols before they reach internal resources.
Server farm protection: Restricting which subnets or hosts can access specific servers on specific ports. For example, only allowing the management VLAN to SSH into network devices.
VTY line security: Applying a standard ACL to the router's VTY lines to restrict which IP addresses are allowed to Telnet or SSH into the device.
Route filtering: Standard ACLs are used with routing protocols to control which routes are advertised or accepted by a neighbor.
NAT traffic selection: Standard ACLs define which internal addresses are eligible for Network Address Translation.

Design Considerations

Order matters. ACEs are processed top-down. Place the most specific entries at the top and the most general entries at the bottom.
One ACL per interface, per direction, per protocol. You cannot apply two IPv4 ACLs in the same direction on the same interface. The second one replaces the first.
Document your ACLs. Use the remark keyword inside named ACLs to add comments explaining the purpose of each entry.
Monitor hit counts. The show access-lists command displays how many packets matched each ACE. Use this to verify that your ACL is working as intended and to identify unused rules.

R1(config)# ip access-list extended FILTER-FTP
R1(config-ext-nacl)# remark Block FTP to production server

Warning: Be extremely careful when applying ACLs to interfaces on remote routers. If you accidentally block your own management traffic (SSH or Telnet), you will lock yourself out of the device. Always include a permit statement for your management subnet before applying the ACL.

Summary

Standard ACLs filter traffic based on source IP address only and use numbers 1-99 or 1300-1999. Place them close to the destination.
Extended ACLs filter traffic based on source IP, destination IP, protocol, and port numbers, using numbers 100-199 or 2000-2699. Place them close to the source.
Every ACL ends with an implicit deny all. You must include explicit permit statements to allow desired traffic through.
ACLs are processed top-down — the first matching ACE is applied, and processing stops. Order your entries from most specific to most general.
Always verify your ACLs using show access-lists and show ip interface commands, and test connectivity to confirm the expected permit and deny behavior before moving on.

In the next lesson, you will build on this foundation by working with IPv6 ACLs and exploring SLAAC and DHCPv6 configuration in a hands-on lab environment.