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 |
||
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
Rules are what you create, modify, and remove when you configure how an ACL filters network traffic. Rules appear in the running configuration. When you apply an ACL to an interface or change a rule within an ACL that is already applied to an interface, the supervisor module creates ACL entries from the rules in the running configuration and sends those ACL entries to the applicable I/O module. Depending upon how you configure the ACL, there may be more ACL entries than rules, especially if you implement policy-based ACLs by using object groups when you configure rules.
he device 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.
This section describes some of the options that you can use when you configure a 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
permit icmp any any nd-na
permit icmp any any nd-ns
permit icmp any any router-advertisement
permit icmp any any router-solicitation
Note |
If you explicitly configure an IPv6 ACL with a deny ipv6 any any rule, the implicit permit rules can never permit traffic. If you explicitly configure a deny ipv6 any any rule but want to permit ICMPv6 neighbor discovery messages, explicitly configure a rule for all five implicit rules. |
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
-
Layer 3 protocol
-
VLAN ID
-
Class of Service (CoS)
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.
Policy-Based ACLs
The device supports policy-based ACLs (PBACLs), which allow you to apply access control policies across object groups. An object group is a group of IP addresses or a group of TCP or UDP ports. When you create a rule, you specify the object groups rather than specifying IP addresses or ports.
Using object groups when you configure IPv4 or IPv6 ACLs can help reduce the complexity of updating ACLs when you need to add or remove addresses or ports from the source or destination of rules. For example, if three rules reference the same IP address group object, you can add an IP address to the object instead of changing all three rules.
PBACLs do not reduce the resources required by an ACL when you apply it to an interface. When you apply a PBACL or update a PBACL that is already applied, the device expands each rule that refers to object groups into one ACL entry per object within the group. If a rule specifies the source and destination both with object groups, the number of ACL entries created on the I/O module when you apply the PBACL is equal to the number of objects in the source group multiplied by the number of objects in the destination group.
The following object group types apply to port, router, and VLAN ACLs:
- IPv4 address object groups
-
Can be used with IPv4 ACL rules to specify source or destination addresses. When you use the permit or deny command to configure a rule, the addrgroup keyword allows you to specify an object group for the source or destination.
- IPv6 address object groups
-
Can be used with IPv6 ACL rules to specify source or destination addresses. When you use the permit or deny command to configure a rule, the addrgroup keyword allows you to specify an object group for the source or destination.
- Protocol port object groups
-
Can be used with IPv4 and IPv6 TCP and UDP rules to specify source or destination ports. When you use the permit or deny command to configure a rule, the portgroup keyword allows you to specify an object group for the source or destination.
ACL Resource Management
Understanding the ACL capacities when configuring ACLs helps avoid resource contention and exhaustion. Because the platform enforces several types of ACLs in hardware rather than in software, the switch programs hardware lookup tables and various hardware resources so that when a packet arrives, the switch can perform a hardware table lookup and execute the appropriate action without affecting performance, while the packets are cut-through switched.
For typical configurations, the switch uses one of the following main hardware resources:
- Logical operation units (LOUs)-Registers that are used to store Layer 2, Layer 3, and Layer 4 operations information.
-
Value, Mask, Result (VMR)-Entries in the TCAM that consist of a value pattern, the associated mask value, and a result for lookups returning a hit for the entry.
The switch optimizes the use of these hardware resources for Layer 4 operations (L4Op). When the number of (L4Ops) are exhausted, an ACL that needs to check a particular value using a L4Op can be expanded to use a set of entries in the TCAM instead. The ACL uses the TCAM entries to perform the same filtering that L4Op would have performed.
If the number of L4Ops are not exhausted, the switch computes the cost of using each resource. If the cost of using a set of expanded TCAM entries is less than that of using a L4Op, the switch expands the set of TCAM entries to preserve the L4Op for higher priority operations.
Depending on the size of ACL TCAM, and the size of various regions in the TCAM, it is possible that policies that are expanded might not fit within the available space. For example, after the switch is reloaded, the set of policies that were expanded before might not be expanded again.
To manage this issue, you can configure a threshold value. The threshold value is from 0 to 32 and the default value is 5. When an ACL policy needs a L4Op, the policy is expanded to check if the number of expanded TCAM entries needed exceeds the threshold value. If the number exceeds the threshold value, the expansion is not used, and L4Op is used instead. If the number of TCAM entries do not exceed the threshold value (that is, they are less than or equal to the threshold value), then the expanded TCAM entries are installed.
Note |
|
Statistics and ACLs
The device can maintain global statistics for each rule that you configure in IPv4, IPv6, and MAC ACLs. If an ACL is applied to multiple interfaces, the maintained rule statistics are the sum of packet matches (hits) on all the interfaces on which that ACL is applied.
Note |
The device does not support interface-level ACL statistics. |
For each ACL that you configure, you can specify whether the device maintains statistics for that ACL, which allows you to turn ACL statistics on or off as needed to monitor traffic filtered by an ACL or to help troubleshoot the configuration of an ACL.
The device does not maintain statistics for implicit rules in an ACL. For example, the device does not maintain a count of packets that match the implicit deny ip any any rule at the end of all IPv4 ACLs. If you want to maintain statistics for implicit rules, you must explicitly configure the ACL with rules that are identical to the implicit rules.
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:
-
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.
-
To apply an IP ACL to a VLAN interface, you must have enabled VLAN interfaces globally.
MAC ACLs have the following configuration guidelines and limitations:
-
MAC ACLs apply to ingress traffic only.
-
ACL statistics are not supported if the DHCP snooping feature is enabled.
VACLs have the following configuration guidelines and limitations:
-
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.
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 . |
Object groups |
No object groups exist by default. |
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. |