Courseiva
ACLGlobal Config

ip access-list extended [name]

Creates or enters an extended named access list to filter traffic based on source/destination IP, protocol, and port numbers, used for granular traffic control.

Definition: ip access-list extended [name] is a Cisco IOS global config command. Creates or enters an extended named access list to filter traffic based on source/destination IP, protocol, and port numbers, used for granular traffic control.

Overview

The `ip access-list extended` command is a fundamental tool in Cisco IOS for creating granular traffic filters based on Layer 3 and Layer 4 information. Extended access lists evaluate packets using source and destination IP addresses, protocol type (e.g., TCP, UDP, ICMP), and port numbers, enabling precise control over which traffic is permitted or denied. This command is essential for security policies, QoS classification, route filtering, and NAT control.

Unlike standard access lists, which only filter on source IP, extended lists provide the flexibility needed in modern networks where traffic must be differentiated by application or destination. Network engineers reach for this command when they need to block specific services (e.g., deny Telnet from a subnet), permit only certain traffic types (e.g., allow HTTP to a web server), or implement security zones. It fits into the broader workflow of securing network perimeters, implementing access control between VLANs, and troubleshooting connectivity issues by isolating traffic flows.

Important IOS behaviors include: the implicit deny all at the end of every ACL; the order of entries matters (first match wins); and ACLs are processed in hardware on most platforms, but changes to an active ACL can briefly impact CPU. The command is available in global configuration mode and requires privilege level 15. The running config stores ACLs in the order entered, and they can be edited by sequence numbers in newer IOS versions (15.x+).

Extended ACLs can be applied to interfaces (inbound or outbound), VTY lines, or used with route maps and other features. Understanding this command is critical for CCNA and CCNP candidates as it appears in security, routing, and troubleshooting scenarios.

Syntax·Global Config
ip access-list extended [name]

When to Use This Command

  • Restricting inbound traffic to a web server to only allow HTTP and HTTPS from specific subnets.
  • Blocking all traffic from a known malicious IP range while allowing legitimate traffic.
  • Permitting only specific protocols (e.g., OSPF, EIGRP) between routers for routing updates.
  • Controlling outbound traffic from a guest VLAN to the internet, allowing only DNS and web traffic.

Parameters

ParameterSyntaxDescription
nameWORD (1-64 characters)A unique alphanumeric name for the access list. Must start with a letter, cannot contain spaces, and is case-sensitive. Common mistake: using a name that conflicts with a numbered ACL or using special characters.

Command Examples

Permit HTTP and HTTPS from specific subnet to a web server

ip access-list extended WEB-ACCESS
Router(config-ext-nacl)#

Enters extended ACL configuration mode for the named ACL 'WEB-ACCESS'. Subsequent permit/deny statements define the rules.

Block traffic from a specific host and permit all other traffic

ip access-list extended BLOCK-HOST
Router(config-ext-nacl)#

Creates a new extended ACL named 'BLOCK-HOST'. After entering, you add deny and permit statements to filter traffic.

Understanding the Output

The command itself does not produce output; it enters a configuration submode. The real output is seen when you use 'show access-lists' or 'show ip access-list'. In that output, each line shows a sequence number, permit/deny action, protocol, source IP/wildcard, destination IP/wildcard, and optional port info.

The 'hit count' indicates how many packets matched that line. A high hit count on a deny entry may indicate blocked traffic that should be investigated. Good values show expected permit matches; bad values are unexpected denies or high denies on critical traffic.

Configuration Scenarios

Restrict HTTP Access to a Web Server from a Specific Subnet

A company wants to allow only the 192.168.1.0/24 subnet to access the internal web server at 10.0.0.10 on TCP port 80. All other traffic to the server should be denied.

Topology

Client(192.168.1.0/24)---(Gi0/0)R1(Gi0/1)---Server(10.0.0.10/24)

Steps

  1. 1.Step 1: Enter global configuration mode: configure terminal
  2. 2.Step 2: Create the extended ACL: ip access-list extended WEB-ACCESS
  3. 3.Step 3: Permit HTTP from the subnet: permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80
  4. 4.Step 4: Deny all other traffic (implicit deny already exists, but explicit deny can be added for logging): deny ip any any log
  5. 5.Step 5: Apply the ACL inbound on the interface facing the server: interface gi0/1, ip access-group WEB-ACCESS in
Configuration
! Configure extended ACL
ip access-list extended WEB-ACCESS
 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80
 deny ip any any log
!
! Apply to interface
interface GigabitEthernet0/1
 ip access-group WEB-ACCESS in

Verify: show ip access-list WEB-ACCESS Expected output shows the permit and deny entries with match counts. Also use show ip interface gi0/1 to verify the ACL is applied inbound.

Watch out: Applying the ACL in the wrong direction. In this scenario, the ACL must be applied inbound on the interface facing the server (Gi0/1) to filter traffic arriving from the client side. If applied outbound, it would filter traffic leaving the server, which is not the intent.

Block Telnet Access from a Remote Network to All Routers

A security policy requires that Telnet (TCP port 23) from the 172.16.0.0/16 network be denied to all routers in the enterprise. Other management traffic (SSH) should be allowed.

Topology

Remote(172.16.0.0/16)---(Gi0/0)R1(Gi0/1)---Core---R2

Steps

  1. 1.Step 1: Enter global configuration mode: configure terminal
  2. 2.Step 2: Create the extended ACL: ip access-list extended BLOCK-TELNET
  3. 3.Step 3: Deny Telnet from the remote network: deny tcp 172.16.0.0 0.0.255.255 any eq 23
  4. 4.Step 4: Permit all other traffic (including SSH): permit ip any any
  5. 5.Step 5: Apply the ACL inbound on the interface facing the remote network: interface gi0/0, ip access-group BLOCK-TELNET in
Configuration
! Configure extended ACL
ip access-list extended BLOCK-TELNET
 deny tcp 172.16.0.0 0.0.255.255 any eq 23
 permit ip any any
!
! Apply to interface
interface GigabitEthernet0/0
 ip access-group BLOCK-TELNET in

Verify: show access-list BLOCK-TELNET Check that the deny entry has matches. Also attempt a Telnet from a host in 172.16.0.0/16 to the router's IP; it should fail. SSH should succeed.

Watch out: Forgetting to add the permit ip any any statement. Without it, the implicit deny at the end would block all traffic, including SSH and other essential protocols. Always ensure the ACL ends with a permit statement unless the goal is to block everything.

Troubleshooting with This Command

When troubleshooting with `ip access-list extended`, the primary tool is `show ip access-list [name]` to view the ACL entries and their hit counts. A healthy ACL shows increasing hit counts for entries that are matching traffic as expected. If hit counts are zero for a permit entry that should be matching, suspect incorrect ordering, wrong direction, or misconfigured source/destination.

Conversely, if a deny entry has high hit counts, it indicates traffic is being blocked as intended. Key fields to focus on: the sequence numbers (if using named ACLs with sequence), the protocol, source/destination addresses and ports, and the action (permit/deny). Common symptoms: users cannot reach a service – check if an ACL is applied on the path using `show ip interface`; the ACL might be blocking the traffic.

Use `show ip access-list` to see if the permit entry for that service has matches. If not, verify the ACL order: the first matching entry wins, so a preceding deny might be blocking the traffic. Another diagnostic flow: 1) Identify the interface and direction where the ACL is applied. 2) Use `show ip access-list` to see the ACL contents and hit counts. 3) Use `show logging` if ACL logging is enabled to see real-time denies. 4) Temporarily add a permit entry with logging to see if traffic hits it. 5) Use `debug ip packet [acl]` with caution to see packet processing (use only in lab or maintenance windows).

Correlate with `show ip route` to ensure the destination is reachable. For complex issues, consider using `packet-tracer` on ASA or `test aaa` for authentication. Remember that ACLs are processed in order, and the implicit deny at the end can cause unexpected blocks.

Always verify the ACL logic by mentally tracing a packet through the entries. Also check for typos in wildcard masks: a common mistake is using a subnet mask instead of a wildcard mask (e.g., 255.255.255.0 instead of 0.0.0.255). Use `show running-config | section ip access-list` to review the exact configuration.

CCNA Exam Tips

1.

Remember that extended ACLs are processed top-down; the first match is applied, so order matters.

2.

CCNA 200-301 often tests the implicit deny all at the end of every ACL; you must include a permit statement if you want any traffic to pass.

3.

Know that extended ACLs should be applied as close to the source as possible to conserve bandwidth.

4.

Be able to identify correct wildcard mask usage (e.g., 0.0.0.255 for /24 subnet).

Common Mistakes

Forgetting the implicit deny all at the end, causing all traffic to be blocked unintentionally.

Misordering ACL entries: placing a broad permit before a specific deny, causing the deny to never be evaluated.

Using incorrect wildcard masks (e.g., using subnet mask instead of wildcard mask).

ip access-list extended [name] vs ip access-list standard [name]

Both 'ip access-list extended' and 'ip access-list standard' are used to create named ACLs, but they differ in filtering granularity. Extended ACLs filter on source/destination IP, protocol, and ports, while standard ACLs filter only on source IP. This distinction often confuses network engineers choosing the right tool for traffic filtering.

Aspectip access-list extended [name]ip access-list standard [name]
Filtering basisSource & destination IP, protocol, portSource IP only
Protocol awarenessSupports TCP, UDP, ICMP, etc.No protocol differentiation
Common placementApplied inbound or outbound near source/destinationUsually applied inbound near destination
Syntax complexityMore parameters, longerSimpler, fewer options
Use in policy routing/NATCommon for matching specific trafficRarely used; extended preferred

Use ip access-list extended [name] when you need to filter based on protocol, source/destination ports, or both IP addresses.

Use ip access-list standard [name] when you need simple source IP-based filtering and want to minimize configuration overhead.

Platform Notes

In IOS-XE (e.g., Catalyst 9000 switches), the `ip access-list extended` command syntax is identical to classic IOS, but the output of `show ip access-list` may include additional fields like 'sequence numbers' and 'match counters' in a slightly different format. On NX-OS (e.g., Nexus switches), the equivalent command is `ip access-list [name]` (without the 'extended' keyword) and the syntax uses 'permit/deny tcp/udp/ip' with similar parameters, but NX-OS uses 'seq' numbers by default and supports object-groups. For ASA firewalls, the equivalent is `access-list [name] extended [permit/deny] [protocol] [source] [destination]` applied via `access-group`.

In IOS-XR, the command is `ipv4 access-list [name]` with a different syntax (e.g., '10 permit ipv4 host 1.2.3.4 any'). Behavior differences: IOS 12.x did not support sequence numbers for named ACLs; they were introduced in 15.x. In 16.x (IOS-XE), sequence numbers are automatic and can be resequenced with `ip access-list resequence`.

On some platforms, applying an ACL to an interface causes a brief traffic interruption; use `ip access-group` with care in production. Always check the specific platform documentation for nuances.

Related Commands

ip access-list standard [name]

Creates or enters a standard named IP access list to filter traffic based on source IP address, used to permit or deny packets in a Cisco IOS network.

show access-lists

Displays all configured ACLs or a specific ACL showing each entry with its sequence number, match criteria (permit/deny, protocol, source, destination, ports), and hit count showing how many packets have matched each entry.

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions