Information About ACLs
An access control list (ACL) is an ordered set of rules that you can use to filter traffic. Each rule specifies a set of conditions that a packet must satisfy to match the rule. When the switch determines that an ACL applies to a packet, it tests the packet against the conditions of all rules. The first match determines whether the packet is permitted or denied. If there is no match, the switch applies the applicable default rule. The switch continues processing packets that are permitted and drops packets that are denied.
You can use ACLs to protect networks and specific hosts from unnecessary or unwanted traffic. For example, you could use ACLs to disallow HTTP traffic from a high-security network to the Internet. You could also use ACLs to allow HTTP traffic but only to specific sites, using the IP address of the site to identify it in an IP ACL.
IP ACL Types and Applications
The Cisco Nexus device supports IPv4 for security traffic filtering. The switch allows you to use IP access control lists (ACLs) as port ACLs, VLAN ACLs, and Router ACLs as shown in the following table.
Application |
Supported Interfaces |
Types of ACLs Supported |
||
---|---|---|---|---|
Port ACL |
An ACL is considered a port ACL when you apply it to one of the following:
When a port ACL is applied to a trunk port, the ACL filters traffic on all VLANs on the trunk port. |
IPv4 ACLs IPv6 ACLs IPv6 ACLs with UDF-based match for Cisco NX-OS 3000 Series switches. |
||
Router ACL |
|
IPv4 ACLs IPv6 ACLs |
||
VLAN ACL (VACL) |
An ACL is a VACL when you use an access map to associate the ACL with an action and then apply the map to a VLAN. |
IPv4 ACLs |
||
VTY ACL |
VTYs |
IPv4 ACLs IPv6 ACLs |
Application Order
-
Port ACL
-
Ingress VACL
-
Ingress Router ACL
-
Egress Router ACL
-
Egress VACL
Rules
You can create rules in access-list configuration mode by using the permit or deny command. The switch allows traffic that matches the criteria in a permit rule and blocks traffic that matches the criteria in a deny rule. You have many options for configuring the criteria that traffic must meet in order to match the rule.
Source and Destination
In each rule, you specify the source and the destination of the traffic that matches the rule. You can specify both the source and destination as a specific host, a network or group of hosts, or any host.
Protocols
IPv4, IPv6, and MAC ACLs allow you to identify traffic by protocol. For your convenience, you can specify some protocols by name. For example, in an IPv4 ACL, you can specify ICMP by name.
You can specify any protocol by the integer that represents the Internet protocol number.
Implicit Rules
IP and MAC ACLs have implicit rules, which means that although these rules do not appear in the running configuration, the switch applies them to traffic when no other rules in an ACL match.
All IPv4 ACLs include the following implicit rule:
deny ip any any
This implicit rule ensures that the switch denies unmatched IP traffic.
All IPv6 ACLs include the following implicit rule:
deny ipv6 any any
This implicit rule ensures that the device denies unmatched IPv6 traffic.
Note |
|
All MAC ACLs include the following implicit rule:
deny any any protocol
This implicit rule ensures that the device denies the unmatched traffic, regardless of the protocol specified in the Layer 2 header of the traffic.
Additional Filtering Options
You can identify traffic by using additional options. IPv4 ACLs support the following additional filtering options:
-
Layer 4 protocol
-
TCP and UDP ports
-
ICMP types and codes
-
IGMP types
-
Precedence level
-
Differentiated Services Code Point (DSCP) value
-
TCP packets with the ACK, FIN, PSH, RST, SYN, or URG bit set
-
Established TCP connections
Sequence Numbers
The Cisco Nexus device supports sequence numbers for rules. Every rule that you enter receives a sequence number, either assigned by you or assigned automatically by the device. Sequence numbers simplify the following ACL tasks:
-
Adding new rules between existing rules—By specifying the sequence number, you specify where in the ACL a new rule should be positioned. For example, if you need to insert a rule between rules numbered 100 and 110, you could assign a sequence number of 105 to the new rule.
-
Removing a rule—Without using a sequence number, removing a rule requires that you enter the whole rule, as follows:
switch(config-acl)# no permit tcp 10.0.0.0/8 any
However, if the same rule had a sequence number of 101, removing the rule requires only the following command:
switch(config-acl)# no 101
-
Moving a rule—With sequence numbers, if you need to move a rule to a different position within an ACL, you can add a second instance of the rule using the sequence number that positions it correctly, and then you can remove the original instance of the rule. This action allows you to move the rule without disrupting traffic.
If you enter a rule without a sequence number, the device adds the rule to the end of the ACL and assigns a sequence number that is 10 greater than the sequence number of the preceding rule to the rule. For example, if the last rule in an ACL has a sequence number of 225 and you add a rule without a sequence number, the device assigns the sequence number 235 to the new rule.
In addition, the device allows you to reassign sequence numbers to rules in an ACL. Resequencing is useful when an ACL has rules numbered contiguously, such as 100 and 101, and you need to insert one or more rules between those rules.
Logical Operators and Logical Operation Units
IP ACL rules for TCP and UDP traffic can use logical operators to filter traffic based on port numbers.
The Cisco Nexus device stores operator-operand couples in registers called logical operation units (LOUs) to perform operations (greater than, less than, not equal to, and range) on the TCP and UDP ports specified in an IP ACL.
Note |
The range operator is inclusive of boundary values. |
These LOUs minimize the number of ternary content addressable memory (TCAM) entries needed to perform these operations. A maximum of two LOUs are allowed for each feature on an interface. For example an ingress RACL can use two LOUs, and a QoS feature can use two LOUs. If an ACL feature requires more than two arithmetic operations, the first two operations use LOUs, and the remaining access control entries (ACEs) get expanded.
The following guidelines determine when the device stores operator-operand couples in LOUs:
-
If the operator or operand differs from other operator-operand couples that are used in other rules, the couple is stored in an LOU.
For example, the operator-operand couples "gt 10" and "gt 11" would be stored separately in half an LOU each. The couples "gt 10" and "lt 10" would also be stored separately.
-
Whether the operator-operand couple is applied to a source port or a destination port in the rule affects LOU usage. Identical couples are stored separately when one of the identical couples is applied to a source port and the other couple is applied to a destination port.
For example, if a rule applies the operator-operand couple "gt 10" to a source port and another rule applies a "gt 10" couple to a destination port, both couples would also be stored in half an LOU, resulting in the use of one whole LOU. Any additional rules using a "gt 10" couple would not result in further LOU usage.
Note |
The expanded ACEs are not stored if the TCAM or all 24 LOU registers are full. |
ACL TCAM Regions
You can change the size of the ACL ternary content addressable memory (TCAM) regions in the hardware.
The IPv4 TCAMs are single wide.
You can create IPv6 port ACLs, VLAN ACL, router ACLs, and you can match IPv6 addresses for QoS. However, Cisco NX-OS cannot support all of them simultaneously. You must remove or reduce the size of the existing TCAMs to enable these new IPv6 TCAMs.
TCAM region sizes have the following guidelines and limitations:
-
To revert to the default ACL TCAM size, use the no hardware profile tcam region command. You no longer need to use the write erase command and reload the switch.
-
Depending upon the platform, each TCAM region might have a different minimum/maximum/aggregate size restriction.
-
The default size of the ARPACL TCAM is zero. Before you use the ARP ACLs in a Control Policing Plane (CoPP) policy, you must set the size of this TCAM to a non-zero size.
-
You must set the VACL and egress VLAN ACL (E-VACL) size to the same value.
-
Both IPv4 and IPv6 addresses cannot coexist, even in a double-wide TCAM.
-
IPv6 PACL TCAM is not supported for Cisco NX-OS 3000 Series switches.
-
The total TCAM depth is 2000 for ingress and 1000 for egress, which can be carved in 256 entries blocks.
-
After TCAM carving, you must reload the switch.
-
All existing TCAMs cannot be set to size 0.
-
By default, all IPv6 TCAMs are disabled (the TCAM size is set to 0).
TCAM ACL Region |
Default Size |
Minimum Size |
Incremental Size |
Maximum Size |
---|---|---|---|---|
SUP (ingress) |
128 x 2 |
128 x 2 |
N/A |
128 x 2 |
SPAN (ingress) |
128 |
128 |
N/A |
128 |
ARPACL (ingress) |
0 |
0 |
128 |
128 |
PACL (ingress) |
384 |
ARPACL disabled = 128 ARPACL enabled = 256 |
256 |
1664 (combined) |
VACL (ingress) |
512 |
0 |
256 |
|
RACL (ingress) |
512 |
256 |
256 |
|
QOS (ingress) |
256 |
256 |
256 |
|
PACL_IPV6 (ingress) |
0 |
0 |
256 x 2 |
|
VACL_IPV6 (ingress) |
0 |
0 |
256 x 2 |
|
RACL_IPV6 (ingress) |
0 |
0 |
256 x 2 |
|
QOS_IPV6 (ingress) |
0 |
0 |
256 x 2 |
|
E-VACL (egress) |
512 |
0 |
256 |
1024 (combined) |
E-RACL (egress) |
512 |
0 |
256 |
|
E-VACL_IPV6 (egress) |
0 |
0 |
256 x 2 |
|
E-RACL_IPV6 (egress) |
0 |
0 |
256 x 2 |
|
QOSLBL (pre-lookup) |
256 |
256 |
256 |
256 |
SUP_IPV6 (pre-lookup) |
128 x 2 |
256 x 2 |
N/A |
256 x 2 |
Licensing Requirements for ACLs
The following table shows the licensing requirements for this feature:
Product |
License Requirement |
---|---|
Cisco NX-OS |
No license is required to use ACLs. |
Prerequisites for ACLs
IP ACLs have the following prerequisites:
-
You must be familiar with IP addressing and protocols to configure IP ACLs.
-
You must be familiar with the interface types that you want to configure with ACLs.
VACLs have the following prerequisite:
-
Ensure that the IP ACL that you want to use in the VACL exists and is configured to filter traffic in the manner that you need for this application.
Guidelines and Limitations for ACLs
IP ACLs have the following configuration guidelines and limitations:
-
For all Network Forwarding Engine (NFE) enabled switches, the ingress RACLs matching the outer header of the tunnel interface are not supported.
-
You cannot create ACE with SMAC or DMAC. The SMAC and DMAC options are specific to OpenFlow. OpenFlow is handled by the POLICY_MGR process and tap-aggregation is handled by the ACLMGR process. Due to this enhancement, OpenFlow specific options are not available for tap-aggregation. There is no requirement to support these options for tap-aggregation.
-
You cannot configure the set-vlan option on the tap-aggregation policy. The set-vlan and strip-vlan options are specific to OpenFlow. OpenFlow and tap-aggregation are handled by two different processes. Due to this, OpenFlow specific options are not available for tap-aggregation.
-
As an enhancement to HTTP method match, the tcp-option-length option has been added to the ACE syntax to specify the length of the TCP options header in the packets. You can configure up to 4 tcp-option-lengths in the ACEs, which includes the TCP option length of 0. If you do not configure the tcp-option-length option, the length is considered as 0. It means that only the packets without the TCP options header can match this ACE. This feature gives more flexibility in such a way that the HTTP method can be matched even on the packets that have the variable length TCP options header
-
We recommend that you perform ACL configuration using the Session Manager. This feature allows you to verify ACL configuration and confirm that the resources required by the configuration are available prior to committing them to the running configuration. This is especially useful for ACLs that include more than about 1000 rules.
-
Only 62 unique ACLs can be configured. Each ACL takes one label. If same ACL is configured on multiple interfaces, the same label is shared; but if each ACL has unique entries, the ACL labels are not shared and that label limit is 62.
-
Packets that fail the Layer 3 maximum transmission unit check and therefore require fragmenting.
-
IPv4 packets that have IP options (additional IP packet header fields following the destination address field).
-
When you apply an ACL that uses time ranges, the device updates the ACL entries whenever a time range referenced in an ACL entry starts or ends. Updates that are initiated by time ranges occur on a best-effort priority. If the device is especially busy when a time range causes an update, the device may delay the update by up to a few seconds.
-
To apply an IP ACL to a VLAN interface, you must have enabled VLAN interfaces globally.
-
To use the match-local-traffic option for all inbound and outbound traffic, you must first enable the ACL in the software.
-
An RACL applied on a Layer 3 physical or logical interface does not match multicast traffic. If multicast traffic must be blocked, use a PACL instead.
-
You cannot configure egress RACLs on L3 port channels.
-
IPv4 ACL logging in the egress direction is not supported.
VACLs have the following configuration:
-
We recommend that you perform ACL configurations using the Session Manager. This feature allows you to verify ACL configuration and confirm that the resources required by the configuration are available prior to committing them to the running configuration.
-
ACL statistics are not supported if the DHCP snooping feature is enabled.
-
If an IPv4 ACL, applied as a VLAN ACL, contains one or more ACEs with logical operators for TCP/UDP port numbers, the port numbers are matched in the ingress direction but ignored in the egress direction.
-
One VLAN access map can match only one IP ACL.
-
An IP ACL can have multiple permit/deny ACEs.
-
One VLAN can have only one access map applied.
-
The following limitations apply to Cisco Nexus 34180YC platform:
-
Egress RACL is not supported.
-
IPV6 ACLs are not supported.
-
TCAM carving is not supported . Cisco Nexus 34180YC supports two profiles – default and l3-heavy. The default has size 7166 for IP ACL and 459 for MAC ACL, while l3-heavy has size 1022 for IP ACL and size 483 for MAC ACL
-
The VACL redirect option is not supported.
-
The LOU threshold is not supported.
-
ACL Logging is not supported.
-
The show hardware access-list tcam region command is not supported.
-
Default ACL Settings
The following table lists the default settings for IP ACLs parameters.
Parameters |
Default |
---|---|
IP ACLs |
No IP ACLs exist by default. |
ACL rules |
Implicit rules apply to all ACLs . |
The following table lists the default settings for VACL parameters.
Parameters |
Default |
---|---|
VACLs |
No IP ACLs exist by default. |
ACL rules |
Implicit rules apply to all ACLs. |
ACL Logging
The Cisco Nexus device supports ACL logging, which allows you to monitor flows that hit specific access control lists (ACLs). To enable the feature for the ACL entry, configure specific ACEs with the optional log keyword.
When you configure ACEs with the optional log keyword, statistics for each flow that matches the permit or deny conditions of the ACL entry are logged in the software.
ACL Consistency Checker
Beginning with Cisco NX-OS Release 9.3(3), the ACL consistency checker supports the following devices:
N3K-C3016Q-40GE, N3K-C3048TP-1GE, N3K-C3064PQ-10GE, N3K-C3064PQ-10GX, N3K-C3064T-10GT, N3K-C3132C-Z
The following entities are verified as part of the ACL consistency check:
Action, Protocol, SIP, DIP, source port, destination port, Source MAC, Destination MAC, Ethertype, COS, DSCP, VLAN and UDFs.
Cisco NX-OS supports the following PACL, RACL, and VACL consistency checker commands.
Command |
Description |
---|---|
show consistency-checker pacl extended ingress ip module <module-id> [brief | detail] |
Verifies PACL consistency check for ingress interfaces and port channel for the specified IP module. |
show consistency-checker pacl extended ingress ipv6 module <module-id> [brief | detail] |
Verifies PACL consistency check for ingress interfaces and port channel for the specified IPv6 module. |
show consistency-checker pacl extended ingress mac module <module-id> [brief | detail] |
Verifies MAC PACL consistency check for ingress interfaces and port channel for the specified MAC module. |
show consistency-checker pacl extended ingress ip interface {<int-id> | <ch-id> [brief | detail] |
Verifies PACL consistency check for the specified ingress interface. |
show consistency-checker pacl extended ingress ipv6 interface {<int-id> | <ch-id> [brief | detail] |
Verifies PACL consistency check for the specified IPv6 ingress interface. |
show consistency-checker pacl extended ingress mac interface {<int-id> | <ch-id> [brief | detail] |
Verifies PACL consistency check for the specified ingress MAC interface. |
show consistency-checker racl extended ingress ip module <module-id> [brief | detail] |
Verifies RACL consistency check for ingress interfaces and port channel for the specified IP module. |
show consistency-checker racl extended ingress ipv6 module <module-id> [brief | detail] |
Verifies RACL consistency check for ingress interfaces and port channel for the specified IPv6 module. |
show consistency-checker racl extended ingress ip interface {<int-id> | <ch-id> | <vlan-id>} [brief | detail] |
Verifies RACL consistency check for the specified ingress interface. |
show consistency-checker racl extended egress ip interface {<int-id> | <ch-id> | <vlan-id>} [brief | detail] |
Verifies RACL consistency check for the specified egress IP interface. |
show consistency-checker racl extended ingress ipv6 interface {<int-id> | <ch-id> | <vlan-id>} [brief | detail] |
Verifies RACL consistency check for the specified ingress IPv6 interface. |
show consistency-checker racl extended egress ipv6 interface {<int-id> | <ch-id> | <vlan-id>}[brief | detail] |
Verifies RACL consistency check for the specified egress IPv6 interface. |
show consistency-checker vacl extended ingress ip vlan <vlan-id> [brief | detail] |
Verifies VACL consistency check for the specified IP VLAN. |
show consistency-checker vacl extended ingress ipv6 vlan <vlan-id> [brief | detail] |
Verifies VACL consistency check for the specified IPv6 VLAN. |
show consistency-checker vacl extended ingress mac vlan <vlan-id> [brief | detail] |
Verifies VACL consistency check for the specified ingress MAC VLAN. |
Output Examples for ACL Consistency Checker Commands
This example shows the RACL consistency check results:
switch# show consistency-checker racl extended ingress ip module 1 Consistency checker passed for Eth1/3 (ingress, ip, ip-list)
switch#
switch#
switch# show consistency-checker racl extended ingress ip module 1 brief
{
"result": {
"status": "CC_STATUS_OK",
"checkers": [
{
"version": 1,
"type": "CC_TYPE_IF_RACL",
"status": "CC_STATUS_OK",
"platformDetails": {
"classType": "CC_PLTFM_NXOS_BCM"
},
"recoveryActions": [],
"failedEntities": []
}
]
}
}
switch#
switch # show consistency-checker racl extended ingress ip interface ethernet 3/5
Consistency checker passed for Ethernet3/5 (ingress, ip, ip-list)
switch#
switch# show consistency-checker racl extended ingress ip interface ethernet 3/5 brief
{
"result": {
"status": "CC_STATUS_OK",
"checkers": [
{
"version": 1,
"type": "CC_TYPE_IF_RACL",
"status": "CC_STATUS_OK",
"platformDetails": {
"classType": "CC_PLTFM_NXOS_BCM"
},
"recoveryActions": [],
"failedEntities": []
}
]
}
}