ACLACL Config

permit ip [source] [dest]

Configures a permit rule in an IPv4 ACL to allow traffic matching specified source and destination addresses.

Overview

The 'permit ip' command is used within an IPv4 access control list (ACL) configuration mode on Cisco NX-OS (Nexus) switches to create a rule that permits IP packets matching specified source and destination addresses. ACLs are fundamental for network security and traffic filtering, allowing administrators to control which traffic is allowed or denied through the switch. The command supports various address specifications: specific IP addresses with wildcard masks, the 'any' keyword to match all addresses, or the 'host' keyword for a single host. Additionally, optional parameters like DSCP, precedence, fragments, logging, and time-range can be applied to fine-tune the rule. On NX-OS, ACLs are applied to interfaces in the inbound or outbound direction using the 'ip access-group' command. This command is typically used in scenarios such as segmenting network traffic, permitting specific flows for monitoring, or allowing management access. Understanding wildcard masks is crucial, as they define which bits of the IP address must match. The command does not produce output upon entry; verification is done via 'show ip access-lists'. ACLs on NX-OS support sequence numbers for easy insertion and deletion of rules. The implicit deny at the end of every ACL means that any traffic not explicitly permitted is dropped. This command is a key building block for creating effective security policies on Nexus switches.

Syntax·ACL Config

permit ip {source source-wildcard | any | host source} {destination dest-wildcard | any | host destination} [dscp dscp-value] [precedence precedence] [fragments] [log] [time-range time-range-name]

When to Use This Command

Allow all IP traffic from a specific subnet to a server subnet.
Permit traffic from a specific host to any destination.
Allow traffic from any source to a specific destination host.
Permit IP traffic with a specific DSCP value for QoS marking.

Parameters

Parameter	Syntax	Required	Description
source	source source-wildcard \| any \| host source	Required	Specifies the source IP address and wildcard mask. Use 'any' to match any source, or 'host' followed by an IP address to match a single host.
destination	destination dest-wildcard \| any \| host destination	Required	Specifies the destination IP address and wildcard mask. Use 'any' to match any destination, or 'host' followed by an IP address to match a single host.
dscp	dscp dscp-value	Optional	Optional. Matches packets with a specific DSCP value (0-63). Used for QoS-based filtering.
precedence	precedence precedence	Optional	Optional. Matches packets with a specific IP precedence value (0-7).
fragments	fragments	Optional	Optional. Matches non-initial fragments of fragmented packets. Use with caution as it can bypass ACL checks.
log	log	Optional	Optional. Enables logging for packets matching this rule. Logs are sent to the console or syslog server.
time-range	time-range time-range-name	Optional	Optional. Associates the rule with a time range, making it active only during specified times.

Command Examples

Permit traffic from subnet 10.1.1.0/24 to any destination

permit ip 10.1.1.0 0.0.0.255 any

No output is displayed upon successful entry; the rule is added to the ACL.

Permit traffic from any source to host 192.168.1.100

permit ip any host 192.168.1.100

No output is displayed upon successful entry; the rule is added to the ACL.

Permit traffic from host 10.10.10.1 to subnet 172.16.0.0/16 with logging

permit ip host 10.10.10.1 172.16.0.0 0.0.255.255 log

No output is displayed upon successful entry; the rule is added to the ACL with logging enabled.

Understanding the Output

The permit ip command does not produce output upon successful configuration. To verify the ACL entries, use the 'show ip access-lists' command. The output of 'show ip access-lists' displays each ACL entry with sequence numbers, permit/deny action, protocol, source/destination addresses, and any additional options like logging. Each line represents a rule; the order is critical as ACLs are processed top-down. A healthy ACL has rules that correctly match intended traffic without unintended matches. Common issues include missing wildcard masks, incorrect sequence numbers, or implicit deny blocking traffic.

Configuration Scenarios

Permit specific subnet to server subnet

Allow traffic from the Engineering subnet (10.1.1.0/24) to the Server subnet (192.168.10.0/24).

Topology

Engineering (10.1.1.0/24) --- Nexus Switch --- Servers (192.168.10.0/24)

Steps

1.Enter global configuration mode.
2.Create an IPv4 ACL named 'ENG-TO-SERVERS'.
3.Add a permit rule for IP traffic from 10.1.1.0/24 to 192.168.10.0/24.
4.Apply the ACL inbound on the interface facing Engineering.

Configuration

! 
configure terminal
ip access-list ENG-TO-SERVERS
 permit ip 10.1.1.0 0.0.0.255 192.168.10.0 0.0.0.255
 exit
interface ethernet 1/1
 ip access-group ENG-TO-SERVERS in
 end

Verify: Use 'show ip access-lists ENG-TO-SERVERS' to verify the rule. Use 'show interface ethernet 1/1' to confirm ACL application.

Watch out: Ensure the wildcard mask is correct; 0.0.0.255 matches the last octet. A common mistake is using 255.255.255.0, which would not match.

Permit host to any destination with logging

Allow a specific management host (10.10.10.1) to access any destination and log matches.

Topology

Management Host (10.10.10.1) --- Nexus Switch --- Network

Steps

1.Enter global configuration mode.
2.Create an IPv4 ACL named 'MGMT-ACCESS'.
3.Add a permit rule for IP traffic from host 10.10.10.1 to any with logging.
4.Apply the ACL inbound on the management interface.

Configuration

! 
configure terminal
ip access-list MGMT-ACCESS
 permit ip host 10.10.10.1 any log
 exit
interface ethernet 1/2
 ip access-group MGMT-ACCESS in
 end

Verify: Check 'show ip access-lists MGMT-ACCESS' to see the rule. Monitor logs with 'show logging' or syslog.

Watch out: Logging can generate many messages; use it sparingly to avoid performance impact.

Troubleshooting with This Command

When troubleshooting ACL issues on Cisco NX-OS, the 'permit ip' command itself does not provide direct troubleshooting output. Instead, use 'show ip access-lists' to display the configured rules. Verify that the sequence numbers are in the desired order; if a rule is missing, check if it was entered correctly. Use 'show ip interface' to confirm the ACL is applied to the correct interface and direction. If traffic is unexpectedly denied, check for an implicit deny rule at the end of the ACL. Use 'show access-lists' with the 'hardware' keyword to see if the ACL is programmed in hardware. For logging, enable 'log' on permit rules to see matches in syslog. If a permit rule is not matching, verify the wildcard mask and IP addresses. Use 'ping' or 'traceroute' with source IP to test connectivity. On NX-OS, ACLs are processed in hardware for performance; if a rule is not working, check for TCAM resource exhaustion with 'show hardware capacity'. Also, ensure that the ACL name is correctly referenced in the 'ip access-group' command. If using time-ranges, verify the switch clock and time-range configuration. For fragmented packets, the 'fragments' keyword may be needed to permit non-initial fragments. Remember that ACLs are stateless; return traffic must be permitted by a separate rule if needed. Use 'show ip access-lists' with the 'summary' option to see hit counts; a rule with zero hits may indicate a misconfiguration.

CCNA Exam Tips

Remember that the wildcard mask is the inverse of a subnet mask; 0.0.0.255 matches the last octet.

The 'any' keyword is equivalent to 0.0.0.0 255.255.255.255.

ACL entries are processed in order; the first match applies, so place more specific rules before general ones.

Common Mistakes

Using a subnet mask instead of a wildcard mask (e.g., 255.255.255.0 instead of 0.0.0.255) – this will not match the intended addresses.

Forgetting that an implicit deny all exists at the end of every ACL – traffic not explicitly permitted is denied.

Placing a broad permit rule before a more specific deny rule, causing the deny to never be evaluated.

Platform Notes

On Cisco NX-OS (Nexus), the 'permit ip' command behaves similarly to Cisco IOS but with some differences. NX-OS uses sequence numbers by default, allowing easy insertion of rules. The syntax for wildcard masks is the same. However, NX-OS does not support the 'established' keyword for TCP; use 'tcp' with flags instead. NX-OS also supports object groups for scalable ACLs. The 'log' keyword on NX-OS sends logs to the console and syslog, but the rate is limited. On Nexus 9000 series, ACLs are typically programmed in hardware for line-rate performance. For older Nexus models, there may be TCAM limitations. The 'permit ip' command is part of the 'ip access-list' configuration mode, which is entered via 'ip access-list <name>'. To exit, use 'exit'. NX-OS also supports IPv6 ACLs with 'ipv6 access-list'. For equivalent commands on other platforms, on Cisco IOS, the command is identical. On Juniper Junos, the equivalent is 'term <name> then accept' within a firewall filter. On Arista EOS, the command is similar to IOS. Version differences: NX-OS 7.x and later support enhanced ACL features like object groups and time-ranges. Always check the specific NX-OS version documentation for any syntax changes.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions