In which configuration mode is access-list [100-199] permit|deny [proto] [src] [dst] used?

The access-list [100-199] permit|deny [proto] [src] [dst] command is entered in Global Config mode on Cisco IOS devices.

ACLGlobal Config

access-list [100-199] permit|deny [proto] [src] [dst]

Configures an extended access list (100-199) to permit or deny traffic based on protocol, source, and destination, used for granular traffic filtering on Cisco routers.

Definition: access-list [100-199] permit|deny [proto] [src] [dst] is a Cisco IOS global config command. Configures an extended access list (100-199) to permit or deny traffic based on protocol, source, and destination, used for granular traffic filtering on Cisco routers.

Overview

The `access-list [100-199] permit|deny [proto] [src] [dst]` command is a fundamental tool for implementing extended access control lists (ACLs) on Cisco IOS routers. Extended ACLs provide granular traffic filtering based on protocol type, source IP address, destination IP address, and optionally port numbers (for TCP/UDP). They are essential for network security, traffic engineering, and policy enforcement.

Unlike standard ACLs that filter only on source IP, extended ACLs allow precise control over which traffic is permitted or denied, making them suitable for perimeter security, inter-VLAN filtering, and QoS classification. Network engineers reach for this command when they need to restrict specific applications (e.g., block HTTP traffic to a server), allow only certain protocols (e.g., permit OSPF between routers), or implement security policies that require inspection of both source and destination. Extended ACLs are typically applied on interfaces in the inbound or outbound direction using the `ip access-group` command.

They are also used with features like route maps, NAT, and VPN filtering. In the broader workflow, ACL configuration is part of the initial security baseline or troubleshooting step when traffic is unexpectedly blocked or allowed. Important IOS behaviors: extended ACLs are processed top-down; the first match determines the action; an implicit deny all exists at the end; ACLs are stored in the running configuration and can be edited with sequence numbers in newer IOS versions (15.x+).

Privilege level 15 (enable) is required to configure them. Changes take effect immediately when applied to an interface. Extended ACLs consume CPU cycles for each packet processed, so efficient design (e.g., placing more specific entries first) is critical for performance.

Syntax·Global Config

access-list [100-199] permit|deny [proto] [src] [dst]

When to Use This Command

Block all HTTP traffic from a specific subnet to a web server while allowing other services.
Permit only ICMP echo requests from a management station to core routers for monitoring.
Deny Telnet traffic from external networks to internal servers to enforce secure management.
Allow specific application traffic (e.g., HTTPS) between two VLANs while blocking others.

Parameters

Parameter	Syntax	Required	Description
access-list-number	100-199	Required	Specifies the extended ACL number. Valid range is 100-199 (or 2000-2699 for expanded range in newer IOS). This number identifies the ACL and must be unique. Common mistake: using a number outside the range or confusing with standard ACL (1-99).
permit\|deny	permit \| deny	Required	Action to take if the packet matches the conditions. 'permit' allows the traffic; 'deny' blocks it. The action is applied to the first matching entry. Common mistake: forgetting that an implicit deny all exists at the end, so if no permit matches, traffic is dropped.
protocol	ip \| tcp \| udp \| icmp \| <0-255>	Required	Protocol to filter. Common values: ip (all IP protocols), tcp, udp, icmp. Numeric protocol numbers can also be used (e.g., 89 for OSPF). Common mistake: using 'ip' when only TCP is intended, which may permit unintended traffic.
source	A.B.C.D wildcard-mask \| any \| host A.B.C.D	Required	Source IP address and wildcard mask. 'any' matches all sources; 'host A.B.C.D' matches a single host. Wildcard mask bits: 0 means exact match, 1 means ignore. Common mistake: confusing wildcard mask with subnet mask (e.g., using 0.0.0.255 instead of 0.0.0.255 is correct but often misapplied).
destination	A.B.C.D wildcard-mask \| any \| host A.B.C.D	Required	Destination IP address and wildcard mask. Same syntax as source. Common mistake: reversing source and destination, which can cause unexpected filtering behavior.

Command Examples

Block HTTP from 192.168.1.0/24 to 10.0.0.1

access-list 101 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80

No output is generated by this command; it is verified with 'show access-lists'.

Permit ICMP from management station to any

access-list 110 permit icmp host 10.1.1.100 any echo

No output; use 'show access-lists' to confirm the entry.

Understanding the Output

The 'show access-lists' command displays the configured extended ACL entries. Each line shows the sequence number, permit/deny action, protocol, source (with wildcard mask), destination (with wildcard mask), and optional operator/port. For example, '10 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80' means sequence 10 denies TCP traffic from subnet 192.168.1.0/24 to host 10.0.0.1 on port 80.

The 'matches' counter increments each time a packet matches the entry, helping identify which rules are hit. A high match count on a deny rule may indicate blocked traffic that should be permitted. Watch for implicit deny at the end; if no match occurs, traffic is denied.

Configuration Scenarios

Block HTTP access to a specific server from a subnet

A company wants to prevent the 192.168.1.0/24 subnet from accessing the web server at 10.0.0.10 (TCP port 80). All other traffic should be allowed.

Topology

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

Steps

1.Step 1: Enter global configuration mode: configure terminal
2.Step 2: Create extended ACL 101 to deny TCP traffic from subnet to server port 80: access-list 101 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80
3.Step 3: Permit all other IP traffic: access-list 101 permit ip any any
4.Step 4: Apply ACL inbound on the interface facing the server (Gi0/1): interface gigabitethernet0/1
5.Step 5: Apply ACL: ip access-group 101 in
6.Step 6: Exit and save: end, write memory

Configuration

!
interface GigabitEthernet0/1
 ip access-group 101 in
!
access-list 101 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80
access-list 101 permit ip any any
!

Verify: Use 'show access-lists 101' to verify the ACL entries and hit counts. Use 'show ip interface gigabitethernet0/1' to confirm ACL is applied. Expected output: ACL 101 with deny line showing matches.

Watch out: Applying the ACL inbound on the wrong interface (e.g., Gi0/0 instead of Gi0/1) will not block traffic from the client to the server. Also, forgetting the 'permit ip any any' will cause all traffic to be denied due to implicit deny.

Allow OSPF routing updates between two routers

Two routers (R1 and R2) are connected via a serial link. OSPF adjacency must be established, but all other traffic between the routers should be denied for security.

Topology

R1(Se0/0)---10.0.12.0/30---(Se0/0)R2

Steps

1.Step 1: Enter global configuration mode: configure terminal
2.Step 2: Create extended ACL 110 to permit OSPF (protocol 89) from R1 to R2: access-list 110 permit ospf host 10.0.12.1 host 10.0.12.2
3.Step 3: Permit OSPF from R2 to R1: access-list 110 permit ospf host 10.0.12.2 host 10.0.12.1
4.Step 4: Deny all other IP traffic: access-list 110 deny ip any any
5.Step 5: Apply ACL outbound on R1's serial interface: interface serial0/0
6.Step 6: Apply ACL: ip access-group 110 out
7.Step 7: Repeat on R2 with reversed source/destination (or apply inbound on R2). Exit and save.

Configuration

!
interface Serial0/0
 ip access-group 110 out
!
access-list 110 permit ospf host 10.0.12.1 host 10.0.12.2
access-list 110 permit ospf host 10.0.12.2 host 10.0.12.1
access-list 110 deny ip any any
!

Verify: Use 'show ip ospf neighbor' to verify adjacency is established. Use 'show access-lists 110' to see matches. Expected output: OSPF state FULL.

Watch out: OSPF uses multicast addresses 224.0.0.5 and 224.0.0.6; if the ACL uses 'host' IPs, ensure the source/destination are the router interfaces, not the multicast addresses. Also, applying the ACL outbound on both routers may cause issues; typically apply inbound on one side or outbound on both with careful direction.

Troubleshooting with This Command

When troubleshooting extended ACLs, the first step is to verify the ACL configuration using `show access-lists [number]`. This command displays each entry with a sequence number, permit/deny action, protocol, source, destination, and hit count. Healthy output shows hit counts incrementing on the expected entries.

If hit counts are zero on a permit entry that should be matching, the ACL may be applied on the wrong interface or direction, or the traffic may be matching a preceding deny entry. Conversely, if a deny entry has high hit counts, it indicates blocked traffic, which may be intentional or a problem. Focus on the order of entries: ACLs are processed top-down, so a broad permit earlier can override a later deny.

Common symptoms: traffic that should be allowed is dropped; this often occurs because the implicit deny at the end is catching traffic, or a deny entry appears before a permit. Use `show ip interface [interface]` to confirm which ACL is applied inbound/outbound. For deeper diagnostics, use `debug ip packet [acl-number]` (with caution in production) to see packets being permitted or denied.

A step-by-step diagnostic flow: 1) Identify the traffic flow (source, destination, protocol, port). 2) Check the ACL applied on the interface along the path. 3) Use `show access-lists` to see if the traffic matches an entry. 4) If not, check if the ACL is applied in the correct direction (inbound vs outbound). 5) Verify that the ACL number is correct and that there are no typos in IP addresses or wildcard masks. 6) Test with a more permissive ACL temporarily to isolate the issue. Correlate with other commands: `show ip route` to ensure routing is correct, `ping` and `traceroute` to test connectivity, and `show logging` for ACL log messages if configured. Remember that extended ACLs do not filter locally generated traffic (e.g., pings from the router itself) unless applied with `ip access-group` in the global or interface configuration for control plane protection.

CCNA Exam Tips

Extended ACLs must be applied close to the source to filter traffic early, per CCNA best practices.

Remember the order: protocol, source, destination, then operator/port (if TCP/UDP).

Wildcard masks are inverse of subnet masks; e.g., 0.0.0.255 matches a /24 subnet.

The 'established' keyword can be used to permit return traffic for TCP sessions.

Common Mistakes

Forgetting to apply the ACL to an interface with 'ip access-group' — the ACL has no effect until applied.

Misordering entries: Cisco processes ACLs top-down; a broad permit before a specific deny may bypass intended blocks.

Using wrong wildcard mask (e.g., 255.255.255.0 instead of 0.0.0.255) — this matches a single host instead of a subnet.

access-list [100-199] permit|deny [proto] [src] [dst] vs access-list [1-99] permit|deny [source]

Standard and extended access lists both use the 'access-list' global configuration command but differ in granularity. They are commonly confused because their number ranges (1-99 vs 100-199) are adjacent and both filter traffic, yet extended ACLs offer much finer control by including protocol, source, and destination.

Aspect	access-list [100-199] permit\|deny [proto] [src] [dst]	access-list [1-99] permit\|deny [source]
ACL Number Range	100-199 (extended)	1-99 (standard)
Filter Criteria	Protocol, source IP, destination IP, optional ports	Source IP only
Typical Placement	Closer to source for early filtering or destination for precise control	Closer to destination (since only source is checked)
Configuration Complexity	More parameters, longer command	Simple, shorter command
Common Use Case	Granular traffic filtering (e.g., block HTTP from a subnet to a server)	Basic permit/deny based on source network (e.g., restrict access to a router vty)

Use access-list [100-199] permit|deny [proto] [src] [dst] when you need to filter traffic based on protocol, source address, destination address, or port numbers for precise control.

Use access-list [1-99] permit|deny [source] when you only need to permit or deny traffic based on source IP address, such as for simple network segmentation or restricting management access.

Platform Notes

In IOS-XE (e.g., Catalyst 9000 switches), the syntax for extended ACLs is identical to classic IOS, but the configuration is often done using the `ip access-list extended` command with named ACLs, which is more flexible. The numbered ACL (100-199) still works. Output of `show access-lists` may include sequence numbers by default.

NX-OS (Cisco Nexus) uses a different syntax: `ip access-list [name]` followed by `permit|deny [proto] [src] [dst]`; numbered ACLs are not supported; instead, named ACLs are mandatory. For example: `ip access-list BLOCK_HTTP` then `deny tcp 192.168.1.0/24 10.0.0.10/32 eq 80`. NX-OS also supports object-groups for scalability.

ASA firewalls use a similar but distinct syntax: `access-list [name] extended permit|deny [proto] [src] [dst]`; the wildcard mask is replaced by subnet mask (e.g., 255.255.255.0). IOS-XR (Cisco Carrier-grade) uses `ipv4 access-list [name]` with a different syntax: `permit|deny [proto] [src] [dst]` and requires explicit sequence numbers. In IOS 12.x, extended ACLs do not support sequence numbers; editing requires removing and re-adding the entire ACL.

In IOS 15.x and later, sequence numbers allow insertion and deletion of individual entries. The command `ip access-list extended [number]` enters ACL configuration mode, enabling sequence numbers. For example: `ip access-list extended 101` then `deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80`.

This is the recommended method for newer IOS versions.

Related Commands

access-list [1-99] permit|deny [source]

Creates a standard numbered access list (1-99) to permit or deny traffic based on source IP address, used to filter packets entering or leaving a router interface.

ip access-group [acl] [in|out]

Applies an access control list (ACL) to an interface to filter inbound or outbound traffic based on the ACL rules.

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