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 or IPv6 ACL, you can specify ICMP by name.

You can specify any protocol by number. In MAC ACLs, you can specify protocols by the EtherType number of the protocol, which is a hexadecimal number. For example, you can use 0x0800 to specify IP traffic in a MAC ACL rule.

In IPv4 and IPv6 ACLs, you can specify protocols by the integer that represents the Internet protocol number. For example, you can use 115 to specify Layer 2 Tunneling Protocol (L2TP) traffic.

For a list of the protocols that each type of ACL supports by name, see the applicable permit and deny commands in the Cisco Nexus 7000 Series NX-OS Security Command Reference.

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. How you specify the source and destination depends on whether you are configuring IPv4, IPv6, or MAC ACLs. For information about specifying the source and destination, see the applicable permit and deny commands in the Cisco Nexus 7000 Series NX-OS Security Command Reference.

IP and MAC ACLs have implicit rules, which means that although these rules do not appear in the running configuration, the device applies them to traffic when no other rules in an ACL match. When you configure the device to maintain per-rule statistics for an ACL, the device does not maintain statistics for implicit rules.

All IPv4 ACLs include the following implicit rule:

deny ip any any

This implicit rule ensures that the device denies unmatched IP traffic.

All IPv6 ACLs include the following implicit rules:

permit icmp any any nd-na 
permit icmp any any nd-ns 
permit icmp any any router-advertisement 
permit icmp any any router-solicitation 
deny ipv6 any any

Unless you configure an IPv6 ACL with a rule that denies ICMPv6 neighbor discovery messages, the first four rules ensure that the device permits neighbor discovery advertisement and solicitation messages. The fifth rule ensures that the device denies unmatched IPv6 traffic.

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 IPv6 ACL 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.

You can identify traffic by using additional options. These options differ by ACL type. The following list includes most but not all additional filtering options:

• IPv4 ACLs support the following additional filtering options:

  • Layer 4 protocol

  • Authentication Header Protocol

  • Enhanced Interior Gateway Routing Protocol (EIGRP)

  • Encapsulating Security Payload

  • General Routing Encapsulation (GRE)

  • KA9Q NOS-compatible IP-over-IP tunneling

  • Open Shortest Path First (OSPF)

  • Payload Compression Protocol

  • Protocol-independent multicast (PIM)

  • 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

  • Packet length

• IPv6 ACLs support the following additional filtering options:

  • Layer 4 protocol

  • Authentication Header Protocol

  • Encapsulating Security Payload

  • Payload Compression Protocol

  • Stream Control Transmission Protocol (SCTP)

  • SCTP, TCP, and UDP ports

  • ICMP types and codes

  • IGMP types

  • Flow label

  • DSCP value

  • TCP packets with the ACK, FIN, PSH, RST, SYN, or URG bit set

  • Established TCP connections

  • Packet length

• MAC ACLs support the following additional filtering options:

  • Layer 3 protocol

  • VLAN ID

  • Class of Service (CoS)

For information about all filtering options available in rules, see the applicable permit and deny commands in the Cisco Nexus 7000 Series NX-OS Security Command Reference.

The 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, Cisco NX-OS 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.

IP ACL rules for TCP and UDP traffic can use logical operators to filter traffic based on port numbers. The device stores operator-operand couples in registers called logical operator units (LOUs). Cisco Nexus 7000 Series devices support 104 LOUs.

The LOU usage for each type of operator is as follows:

eq

Is never stored in an LOU

gt

Uses 1/2 LOU

lt

Uses 1/2 LOU

neq

Uses 1/2 LOU

range

Uses 1 LOU

The following guidelines determine when the devices store 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.

You can enable the device to create an informational log message for packets that match a rule. The log message contains the following information about the packet:

• Protocol

• Status of whether the packet is a TCP, UDP, or ICMP packet, or if the packet is only a numbered packet.

• Source and destination address

• Source and destination port numbers, if applicable

As non-initial fragments contain only Layer 3 information, these access-list entries containing only Layer 3 information, can now be applied to non-initial fragments also. The fragment has all the information the system requires to filter, so the access-list entry is applied to the fragments of a packet.

This feature adds the optional fragments keyword to the following IP access list commands: deny (IPv4), permit (IPv4), deny (IPv6), permit (IPv6). By specifying the fragments keyword in an access-list entry, that particular access-list entry applies only to non-initial fragments of packets; the fragment is either permitted or denied accordingly.

The behavior of access-list entries regarding the presence or absence of the fragments keyword can be summarized as follows:

You should not add the fragments keyword to every access-list entry, because the first fragment of the IP packet is considered a non-fragment and is treated independently of the subsequent fragments. Because an initial fragment will not match an access list permit or deny entry that contains the fragments keyword, the packet is compared to the next access list entry until it is either permitted or denied by an access list entry that does not contain the fragments keyword. Therefore, you may need two access list entries for every deny entry. The first deny entry of the pair will not include the fragments keyword, and applies to the initial fragment. The second deny entry of the pair will include the fragments keyword and applies to the subsequent fragments. In the cases where there are multiple deny access list entries for the same host but with different Layer 4 ports, a single deny access-list entry with the fragments keyword for that host is all that has to be added. Thus all the fragments of a packet are handled in the same manner by the access list.

Packet fragments of IP datagrams are considered individual packets and each fragment counts individually as a packet in access-list accounting and access-list violation counts.

Note	The fragments keyword cannot solve all cases involving access lists and IP fragments.

Note

Within the scope of ACL processing, Layer 3 information refers to fields located within the IPv4 header; for example, source, destination, protocol. Layer 4 information refers to other data contained beyond the IPv4 header; for example, source and destination ports for TCP or UDP, flags for TCP, type and code for ICMP.

Fragmentation and the fragment control feature affect policy routing if the policy routing is based on the match ip address command and the access list had entries that match on Layer 4 through Layer 7 information. It is possible that noninitial fragments pass the access list and are policy routed, even if the first fragment was not policy routed or the reverse.

By using the fragments keyword in access-list entries as described earlier, a better match between the action taken for initial and noninitial fragments can be made and it is more likely policy routing will occur as intended.

Note

Filtering with L3 and L4 information can lead to routing or packet loss issues in the network. Perform any one of the following to prevent these issues: Modify the route map to allow required L3 information for appropriate UDP ports. Check the MTU by verifying the path from source to destination to ensure that the packet is not fragmented.

You can configure ACL capture in order to selectively monitor traffic on an interface or VLAN.

When you enable the capture option for an ACL rule, packets that match this rule are either forwarded or dropped based on the specified permit or deny action and may also be copied to an alternate destination port for further analysis.

ACL capture can be used in a variety of scenarios. For example, ACL capture can use ACL rules to identify packets belonging to a tunnel and to send a copy (or capture) of the tunnel packets to a specific destination. ACL capture can also be used to monitor all HTTP traffic on a particular VLAN.

Finally, you can also configure the capture session for the whole ACL rather than configuring it per ACL rule. This configuration applies the capture session to all of the ACL rules.

To adequately plan for Atomic ACL updates you need to be aware of how many ACE (Access Control Elements) you are using on all of your ACLs on each module. You also need to know how many ACEs your TCAM can support. You can find out your current usage with the show hardware access-list resource utilization mod module-number command.

show hardware access-list resource
utilization mod 3
 INSTANCE 0x0
 -------------
 ACL Hardware Resource Utilization (Mod 3)
 --------------------------------------------
                Used  Free  Percent 
                            Utilization
 -----------------------------------------------------
 Tcam 0, Bank 0  1   16383  0.01
 Tcam 0, Bank 1  2   16382  0.01
 Tcam 1, Bank 0  7   16377  0.04
 Tcam 1, Bank 1  138 16246  0.84

For M-series modules, the ACL TCAM is spread across four banks. On non-XL modules, each bank has 16,000 entries for a total of 64K entries. On XL modules each bank has 32,000 entries for a total of 128,000 entries. Under normal circumstances, a single ACL will only use the resources of a single TCAM bank. In order to enable a single ACL to use resources from all of the banks you need to enable bank pooling with the hardware access-list resource pooling module mod-number command.

You can verify that bank pooling is enabled with the show hardware access-list resource pooling command.

Session Manager supports the configuration of object groups. This feature allows you to create a configuration session and verify your object group configuration changes prior to committing them to the running configuration. For more information about Session Manager, see the Cisco Nexus 7000 Series NX-OS System Management Configuration Guide.

1.    configure terminal


2.    object-group ip address name


3.    Enter one of the following commands:

• [sequence-number] host IPv4-address
• [sequence-number] IPv4-address network-wildcard
• [sequence-number] IPv4-address/prefix-len

4.    Enter one of the following commands:

• no [sequence-number ]
• no host IPv4-address
• no IPv4-address network-wildcard
• no IPv4-address/prefix-len

5.    (Optional) show object-group name


6.    (Optional) copy running-config startup-config

switch# configure terminal
switch(config)#

switch(config)# object-group ip address ipv4-addr-group-13
switch(config-ipaddr-ogroup)#

switch(config-ipaddr-ogroup)# host 10.99.32.6

switch(config-ipaddr-ogroup)# no host 10.99.32.6

switch(config-ipaddr-ogroup)# show object-group ipv4-addr-group-13

switch(config-ipaddr-ogroup)# copy running-config startup-config

1.    config t


2.    object-group ipv6 address name


3.    Enter one of the following commands:

• [sequence-number] host IPv6-address
• [sequence-number] IPv6-address/prefix-len

4.    Enter one of the following commands:

• no sequence-number
• no host IPv6-address
• no IPv6-address/prefix-len

5.    (Optional) show object-group name


6.    (Optional) copy running-config startup-config

switch# config t
switch(config)#

switch(config)# object-group ipv6 address ipv6-addr-group-A7
switch(config-ipv6addr-ogroup)#

switch(config-ipv6addr-ogroup)# host 2001:db8:0:3ab0::1

switch(config-ipv6addr-ogroup)# no host 2001:db8:0:3ab0::1

switch(config-ipv6addr-ogroup)# show object-group ipv6-addr-group-A7

switch(config-ipv6addr-ogroup)# copy running-config startup-config

1.    configure terminal


2.    object-group ip port name


3.    [sequence-number] operator port-number [port-number]


4.    no {sequence-number | operator port-number [port-number]}


5.    (Optional) show object-group name


6.    (Optional) copy running-config startup-config

switch# configure terminal
switch(config)#

switch(config)# object-group ip port NYC-datacenter-ports
switch(config-port-ogroup)#

switch(config-port-ogroup)# eq 80

switch(config-port-ogroup)# no eq 80

switch(config-port-ogroup)# show object-group NYC-datacenter-ports

switch(config-port-ogroup)# copy running-config startup-config

1.    configure terminal


2.    no object-group {ip address | ipv6 address | ip port} name


3.    (Optional) show object-group


4.    (Optional) copy running-config startup-config

switch# configure terminal
switch(config)#

switch(config)# no object-group ip address ipv4-addr-group-A7

switch(config)# show object-group

switch(config)# copy running-config startup-config

Problem: The configuration of a feature on a VLAN or a port fails.

Scenario: The flexible ACL TCAM bank chaining feature is configured with the VLAN-VLAN mode on module 2. The QoS feature on the destination VLAN is configured. Additionally, the role-based access control list (RBACL) should be configured on the same VLAN. In this case, the configuration of the RBACL feature fails.

Solution: Check whether the feature result types overlap under the same TCAM in the TCAM bank mapping table, as follows:

switch# show system internal access-list feature bank-chain map vlan-vlan egress module 2
_________________________________________________________________________
Feature                Rslt Type      T0B0      T0B1      T1B0      T1B1
_________________________________________________________________________
QoS                        Qos         X         X
RACL                       Acl                             X         X
VACL                       Acl                             X         X
Tunnel Decap               Acl         X         X
Netflow                    Acl                             X         X
Netflow Sampler            Acc         X         X
Rbacl                      Acl         X         X
CTS implicit Tunnel        Acl         X         X
SPM WCCP                   Acl                             X         X
SPM OTV                    Acl         X         X
SPM LISP                   Acl         X         X
SPM ERSPAN (termination)   Acl         X         X
OTV25 DECAP                Acl         X         X
SPM NVE                    Acl                             X         X
SPM NVE RDT                Acl                             X         X
SPM ITD                    Acl                             X         X

Check whether features with different result types overlap under the same TCAM. In this scenario, the QoS and RBACL features have different result types and are displayed under the same TCAM: T0B0 and T0B1. Features that are displayed under the same TCAM bank, but have different result types, cannot be configured together.