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 device determines that an ACL applies to a packet, the device tests the packet against the conditions of all rules. The rule determines whether the packet is to be permitted or denied. If there is no match to any of the specified rules, then the device denies the packet. The device 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 can use ACLs to disallow HTTP traffic from a high-security network to the Internet. You can also use ACLs to allow HTTP traffic to a specific site using the IP address of the site to identify it in an IP ACL.
ACL Types and Applications
An ACL is considered a port ACL when you apply it to one of the following:
-
Ethernet interface
-
vEthernet interface
When a port ACL is applied to a trunk port, the ACL filters traffic on all VLANs on that trunk port. Both IPv4 and IPv6 ACLs are supported.
Active Ports and Services on Nexus 1000V VSM
The following table lists the active ports and services on Nexus 1000V VSM:
Port Number |
Protocol |
Remark |
---|---|---|
22 |
SSH / SCP /SFTP (TCP) |
|
23 |
TELNET (TCP) |
|
123 |
NTP (UDP) |
Used by NTP Sever |
161 |
SNMP (UDP) |
Used by SNMP Server |
Order of ACL Application
When the device processes a packet, it determines the forwarding path of the packet. The device applies the ACLs in the following order:
-
Ingress port ACL
-
Egress port ACL
Rules
Rules are what you create, modify, and remove when you configure how an access control list (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 all the Virtual Supervisor Engines (VSEs).
You can create rules in ACLs in access-list configuration mode by using the permit or deny command. The 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 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.
How you specify the source and destination depends on whether you are configuring IP or MAC ACLs.
Protocols
ACLs allow you to identify traffic by protocol. You can specify some protocols by name. For example, in an IP ACL, you can specify ICMP by name.
In IP 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.
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.
Implicit Rules
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. Implicit rules ensure that unmatched traffic is denied, regardless of the protocol specified in the Layer 2 header of the traffic.
All IPv4 ACLs include the following implicit rule that denies unmatched IP traffic:
deny ip any any
Additional Filtering Options
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:
-
IP 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
-
See the Cisco Nexus 1000VE Command Reference guide for information about filtering options available when using the applicable permit and deny commands.
Sequence Numbers
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 by 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, you can 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.
Statistics
The device can maintain global statistics for each rule that you configure. 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.
ACL Logging
You can use ACL logging to monitor flows that affect specific ACLs. The ACLs can be configured with the optional log keyword in each of the access control entries (ACEs). When you configure an option, statistics for each flow that match the ACL permit or deny conditions that you enter are logged in the software.
This example shows how to apply the log option to any IPv4 ACL:
switch(config)# ip access-list [name]
switch(config-acl)# permit tcp any 156.10.3.44/24 log
This example shows how to apply the log option to any IPv6 ACL:
switch(config)# ip access-list [name]
switch(config-acl)# permit tcp any 2001:0db8:85a3::/48 log
You can enable logging per rule(s) within the ACL. An implicit deny rule is the default action for ACLs. To log any packets that match the implicit deny rule, you must create an explicit deny rule and add the log keyword.
![]() Note |
|
Statistics and logging are provided for each flow. A flow is defined by the following IP flows:
-
VSM ID
-
Virtual Services Engine (VSE) ID
-
Source interface
-
Protocol
-
Source IP address
-
Source port
-
Destination IP address
-
Destination port
Scalability is provided through the following functionality:
-
Each Cisco Nexus 1000VE switch can support up to 64 VSEs.
-
Each VSE can support up to 5000 permits and 5000 denies flows. The maximum number of permit/deny flows is a configurable option.
-
The flow reporting interval can be set from 5 up to 86,400 seconds (1 day).
-
The configuration flow syslog level can be from 0 to 7.
-
Up to three syslog servers are supported.
ACL Flows
An ACL flow as it pertains to ACL logging has the following characteristics:
-
It represents a stream of IPv4/IPv6 packets with the same packet headers (SrcIP, DstIP, Protocol, SrcPort, DstPort) for which an identical ACL action is enforced. Each flow entry tracks the count of packets that match the flow.
-
It is created only if logging is enabled on the corresponding ingress/egress ACL policy. Ingress and egress flows are tracked separately.
-
Each VSE tracks a maximum of 10,000 ACL flows; a flow space is shared between permit/deny flows, and each has a configurable maximum of 5000.
-
Each flow entry contains the following:
-
Packet tuple
-
ACL action
-
Direction
-
Packet count
-
-
The ACL flow life cycle is as follows:
-
A flow is created when the first packet of a unidirectional stream matches a Layer 3 ACL policy. A new flow notification is sent to the syslog server.
-
For all subsequent packets with a tuple that matches the flow tuple, the per flow packet counter is incremented.
-
Each flow is tracked periodically based on the configured reporting interval. Within each periodic report, all the active flows and the corresponding packet count seen since the last periodic report are reported to the syslog server
-
If no packets match a flow for one full periodic interval, the flow entry is purged. This process is the only flow-aging scheme.
-
A flow is not stateful. There is no connection tracking for TCP flows.
-
-
The flow reporting process occurs in the following manner:
-
For each flow created, a new flow notification message is sent to the syslog server.
-
A periodic report for each active flow comes next. A flow is active if packets that match the flow are seen since the last periodic report.
-
The flow information is exported to the syslog server and contains the following: packet tuple, ACL action, direction, VSE-ID, VSM-ID, packet count.
-
The periodic time can be as low as 5 seconds with the default setting of 5 minutes. A new user space ACL-logging thread handles the periodic poll and report functionality.
-
Syslog messages that identify the flow space usage are sent at 75 percent, 90 percent, and 100 percent of the threshold maximum to the syslog server once during each interval.
-
Syslog Messages
Syslog message characteristics are as follows:
-
Syslog messages that contain flow information are exported from each Virtual Service Engine (VSE).
-
The syslog client functionality is RFC-5424 compliant and communicates to servers over a UDP port (514).
-
Any host that contains a VSE must be configured with a vmknic interface that can reach the remote syslog server.
-
On a ESXi-6.x host, syslog messages are blocked by a firewall. The Cisco Nexus 1000VE has installation scripts that open the firewall for port 514.