In which configuration mode is permit|deny [proto] [src] [dest] [eq port] used?

The permit|deny [proto] [src] [dest] [eq port] command is entered in ACL Config mode on Cisco IOS devices.

ACLACL Config

permit|deny [proto] [src] [dest] [eq port]

Configures an access control list (ACL) entry to permit or deny traffic based on protocol, source, destination, and optional port number.

Definition: permit|deny [proto] [src] [dest] [eq port] is a Cisco IOS acl config command. Configures an access control list (ACL) entry to permit or deny traffic based on protocol, source, destination, and optional port number.

Overview

The `permit|deny [proto] [src] [dest] [eq port]` command is the fundamental building block of Cisco IOS access control lists (ACLs). ACLs are used to filter network traffic for security, traffic engineering, and policy enforcement. This command defines a single entry in an ACL, specifying whether to permit or deny packets based on protocol (e.g., IP, TCP, UDP), source and destination IP addresses, and optionally the destination port number.

ACLs are applied to interfaces (inbound or outbound), VTY lines, or used in features like route maps and QoS. Understanding this command is critical for CCNA and CCNP candidates because ACLs are ubiquitous in network design and troubleshooting. The command operates in ACL configuration mode, which is entered via `ip access-list extended <name>` or `access-list <number>`.

When you issue this command, the entry is appended to the ACL. The order of entries matters: the first match determines the action. There is no implicit deny at the end of an ACL unless explicitly configured (though Cisco IOS adds an implicit deny all at the end).

This command is used when you need to control traffic flows—for example, blocking specific hosts, allowing only web traffic, or restricting management access. Alternatives include using named ACLs (which offer easier editing) or object-group ACLs (on newer IOS versions). The command is available in privileged EXEC mode (configuring via terminal) and requires privilege level 15.

Changes take effect immediately when the ACL is applied to an interface. A common pitfall is forgetting that ACLs are processed top-down; a misordered entry can inadvertently permit or deny traffic. Also, ACLs do not filter locally generated traffic (e.g., pings from the router itself).

In terms of workflow, ACL configuration typically follows a plan: identify traffic to filter, create the ACL entries, apply to an interface, and verify with `show access-lists`. The command's output is stored in the running configuration and can be saved to startup-config. For troubleshooting, `show access-lists` displays hit counts, helping identify which entries are matching traffic.

The command is supported across all IOS platforms, but syntax varies slightly in IOS-XE, NX-OS, and ASA. This reference covers the classic IOS syntax used in CCNA/CCNP labs.

Syntax·ACL Config

permit|deny [proto] [src] [dest] [eq port]

When to Use This Command

Restrict inbound HTTP traffic to a web server from a specific subnet.
Block all Telnet access from external networks to internal devices.
Allow only ICMP echo requests from a monitoring server to network devices.
Deny FTP traffic from a specific host to a file server.

Parameters

Parameter	Syntax	Required	Description
permit\|deny	permit \| deny	Required	Specifies the action to take when a packet matches the ACL entry. 'permit' allows the packet; 'deny' drops it. This is the first keyword in the command. Common mistake: using 'permit' when 'deny' is intended, or vice versa.
proto	ip \| tcp \| udp \| icmp \| <protocol-number>	Required	Specifies the IP protocol to match. Common values: 'ip' (any IP), 'tcp', 'udp', 'icmp'. You can also use protocol numbers (e.g., 6 for TCP, 17 for UDP). For TCP/UDP, you can optionally specify source and destination ports. Common mistake: forgetting to specify protocol when using port numbers; port matching only works with TCP/UDP.
src	A.B.C.D <wildcard-mask> \| any \| host A.B.C.D	Required	Source IP address and wildcard mask. Use 'any' to match any source, or 'host <ip>' for a single host. The wildcard mask uses 0 to match exact bits and 1 for 'don't care'. Common mistake: using subnet mask instead of wildcard mask (e.g., 255.255.255.0 instead of 0.0.0.255).
dest	A.B.C.D <wildcard-mask> \| any \| host A.B.C.D	Required	Destination IP address and wildcard mask. Same format as source. Common mistake: reversing source and destination, which can cause unexpected filtering.
eq port	eq <port-number> \| eq <port-name>	Optional	Optional parameter for TCP/UDP protocols. Specifies the destination port to match. Use port number (e.g., 80) or well-known name (e.g., www). Common mistake: using 'eq' without specifying TCP or UDP as the protocol; the command will be rejected.

Command Examples

Permit HTTP traffic from a specific subnet to a web server

permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80

This command permits TCP traffic from any host in the 192.168.1.0/24 network to the destination host 10.0.0.1 on port 80 (HTTP). The wildcard mask 0.0.0.255 matches the subnet.

Deny Telnet traffic from any source to a specific server

deny tcp any host 10.0.0.2 eq 23

This command denies TCP traffic from any source to the destination host 10.0.0.2 on port 23 (Telnet). The keyword 'any' matches all source IP addresses.

Understanding the Output

This command does not produce output when entered; it simply adds an entry to the ACL. To view the ACL, use 'show access-lists'. The output of 'show access-lists' displays each entry with sequence number, permit/deny action, protocol, source, destination, and port if specified.

Each entry is evaluated in order until a match is found. An implicit 'deny any' exists at the end of every ACL, so traffic not explicitly permitted is denied.

Configuration Scenarios

Restrict Web Access from a Specific Subnet

A network administrator needs to block all HTTP traffic from the 192.168.1.0/24 subnet to the web server at 10.0.0.10, while allowing all other traffic. This is a common security policy to prevent internal users from accessing a sensitive server.

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 an extended ACL: ip access-list extended BLOCK_HTTP
3.Step 3: Add entry to deny TCP from 192.168.1.0/24 to server 10.0.0.10 port 80: deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80
4.Step 4: Add entry to permit all other IP traffic: permit ip any any
5.Step 5: Apply ACL inbound on interface Gi0/1 (facing server): interface gigabitethernet0/1, ip access-group BLOCK_HTTP in
6.Step 6: Exit and verify: end, show access-lists BLOCK_HTTP

Configuration

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

Verify: Use 'show access-lists BLOCK_HTTP' to see hit counts. Initially, all counters are 0. After traffic, the deny entry should increment. Also use 'show ip interface gigabitethernet0/1' to confirm ACL is applied.

Watch out: Forgetting the 'permit ip any any' entry will cause all traffic to be denied due to implicit deny. Also, ensure ACL is applied in the correct direction (inbound on the server-facing interface).

Allow Only SSH Management from a Management Station

A network engineer wants to restrict remote management access to the router's VTY lines to only a single management station at 10.0.0.100. This enhances security by preventing unauthorized SSH attempts.

Topology

Management Station(10.0.0.100)---(Gi0/0)R1

Steps

1.Step 1: Enter global configuration mode: configure terminal
2.Step 2: Create a standard ACL to permit the management host: access-list 10 permit host 10.0.0.100
3.Step 3: Apply the ACL to VTY lines: line vty 0 4, access-class 10 in
4.Step 4: Optionally, configure SSH and ensure transport input ssh
5.Step 5: Exit and verify: end, show access-lists 10

Configuration

!
access-list 10 permit host 10.0.0.100
!
line vty 0 4
 access-class 10 in
 transport input ssh
!

Verify: Use 'show access-lists 10' to see hit counts. Attempt SSH from 10.0.0.100 should succeed; from other hosts should fail. Also use 'show line vty 0 4' to verify access-class.

Watch out: Standard ACLs (1-99) only check source IP; they cannot filter by destination or port. For VTY access, the ACL is applied inbound, meaning it filters the source IP of the incoming connection. Do not forget to also configure 'transport input ssh' to allow SSH.

Troubleshooting with This Command

When troubleshooting ACLs, the primary command is `show access-lists [acl-name-or-number]`. This displays each entry with a counter of packets matched (hit count). A healthy ACL shows increasing hit counts on expected entries and zero on others.

If hit counts are zero on an entry that should match, suspect misconfiguration (wrong source/destination, wildcard mask, or direction). If hit counts are incrementing on a deny entry unexpectedly, traffic is being blocked that should be allowed. Focus on the order of entries: the first match wins.

Common symptoms: traffic not reaching destination (check if ACL is blocking), or traffic allowed when it should be denied (check for permit entries before deny). Step-by-step diagnostic flow: 1) Identify the interface and direction where ACL is applied using `show ip interface [interface]`. 2) View the ACL with `show access-lists`. 3) Check hit counts; if no hits, generate test traffic (e.g., ping, telnet) and re-check. 4) If hits appear on wrong entry, reorder or modify ACL. 5) Use `show logging` to see ACL deny logs if `log` keyword was used. Correlate with `debug ip packet [acl-number]` (use with caution on production) to see packet processing.

For complex scenarios, use `show ip access-list` to see extended ACLs. Also, remember that ACLs do not filter traffic originated by the router itself (e.g., routing updates). If you need to filter that, use distribute-lists or prefix-lists.

Another common issue: applying an ACL outbound on an interface that also has NAT; the ACL sees the post-NAT IP. Always verify the direction and the IP addresses the ACL will see. Finally, check for implicit deny: if you only have permit entries for specific traffic, all other traffic is denied.

Add a `permit ip any any` at the end if you want to allow all other traffic.

CCNA Exam Tips

Remember the implicit deny any at the end of every ACL; you must explicitly permit desired traffic.

ACL entries are processed top-down; order matters. Place more specific entries before general ones.

For extended ACLs, the protocol (e.g., tcp, udp, icmp) must be specified before source and destination.

The 'eq' operator matches only the exact port number; use 'gt', 'lt', 'range' for other comparisons.

Common Mistakes

Forgetting to apply the ACL to an interface with 'ip access-group' command, resulting in no effect.

Using the wrong wildcard mask (e.g., 255.255.255.0 instead of 0.0.0.255) which inverts the matching logic.

Placing a deny entry before a permit entry for the same traffic, causing unintended blocking.

permit|deny [proto] [src] [dest] [eq port] vs ip access-group [acl] [in|out]

These two commands are often confused because they work together to implement ACL filtering. The 'permit|deny' command defines the filtering rules within an ACL, while 'ip access-group' applies those rules to an interface. Understanding the distinction is critical for proper ACL configuration.

Aspect	permit\|deny [proto] [src] [dest] [eq port]	ip access-group [acl] [in\|out]
Scope	Applies to individual ACL entries	Applies to entire ACL on interface
Configuration mode	ACL configuration mode (submode)	Interface configuration mode
Persistence	ACL definition persists separately	Application persists on interface
Precedence	Order within ACL determines match	Applied after ACL is created
Typical use	Creating permit/deny rules	Activating ACL on interface

Use permit|deny [proto] [src] [dest] [eq port] when defining the specific traffic filtering rules inside a named or numbered ACL.

Use ip access-group [acl] [in|out] when attaching a previously defined ACL to an interface to enforce filtering in a specific direction.

Platform Notes

In IOS-XE (e.g., Catalyst 9000 switches), the syntax is identical to classic IOS, but ACLs are often applied using `ip access-group` under interface configuration. The output of `show access-lists` may include additional fields like 'match-all' or 'match-any' for object-group ACLs. NX-OS (Nexus switches) uses a different ACL configuration model: you create ACLs with `ip access-list <name>` and entries with `[sequence] permit|deny ...`.

The syntax for source/destination uses IP prefix and prefix length (e.g., `10.0.0.0/24`) instead of wildcard mask. For example: `ip access-list BLOCK_HTTP, 10 deny tcp 192.168.1.0/24 10.0.0.10/32 eq 80`. NX-OS also supports object-group ACLs natively.

ASA firewalls use a similar but distinct syntax: `access-list <name> extended permit tcp <src> <dest> eq <port>`. The ASA uses netmask instead of wildcard mask (e.g., `255.255.255.0`). Also, ASA ACLs are applied with `access-group <name> in interface <ifname>`.

IOS-XR (carrier-grade routers) uses a different configuration style: `ipv4 access-list <name>`, with entries like `10 permit tcp 192.168.1.0/24 10.0.0.10/32 eq 80`. IOS-XR also supports sequence numbers and uses prefix-length notation. For CCNA/CCNP, focus on classic IOS; but be aware that modern exams may include IOS-XE or NX-OS scenarios.

The command `permit|deny` itself is not used in NX-OS or IOS-XR; instead, you use `permit` or `deny` as part of the access-list entry. In all platforms, the concept of first-match applies. Always verify the specific platform documentation.

Related Commands

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