How ACL matching works

An ACL contains one or more Access Control Entries (ACE) which are listed according to priority by sequence number.

A single ACE matches on one or more characteristics of the particular traffic type. A single ACL also has a configured action to either deny or permit the packet to continue through the switch.

The matching process begins with the ACE with the lowest sequence number. The incoming or outgoing packet is compared against entries in the match characteristics. If a match occurs, the action of the ACE - either permit or deny - is taken. If no match occurs, the match characteristics of the next ACE in sequence is compared to the relevant frame/packet details. If a match occurs, the specified action is taken. This process continues until a match is found, or the end of the list is reached.

If no ACEs in a given applied ACL match, the frame/packet is discarded. This discarding of the frame/packet occurs because of the presence of an invisible implicit deny rule at the end of *all* applied ACLs whether populated or empty. This mechanism is a security feature to ensure that any Access Controlled interface will only pass explicitly permitted traffic. Because of this security feature, an ACE permitting ICMPv6 traffic must be added to the end of an IPv6 ACL. This appending allows IPv6 neighbor discovery packets. For example:

switch(config)# do show run
...
access-list ipv6 TEST1
    10 deny any 100.2.1::0 any
    20 permit any 100.2::0 any
    30 permit icmpv6 any any
interface 1/1/3
    no shutdown
    no routing
    apply access-list ipv6 TEST1 in

Traffic matching an explicit deny or permit rule can be counted and recorded in the system log. Logging permitted traffic is not currently supported.

An ACL must be applied using the apply access-list command (in the interface context) before it affects traffic. If an ACL with no user-created entries is applied, the ACL will deny all traffic on the ACL type on the applied interface. This denying of traffic occurs since only the implicit default-deny ACE will be present. For example, applying an empty IPv4 ACL will not deny ARP, ICMPv6, and many other non-IPv4 types of traffic.

ACLs can only be applied to port and lag interfaces, but not to VLAN interfaces.

If you enter an existing ACL-NAME value, the existing ACL will be modified with both of the following:

any new sequence-number value creating an additional ACE
any existing sequence-number value replacing the existing ACE with the same sequence number

If you modify an ACL already applied to a port, it is possible that packets, blocked by the previous ACL, will briefly pass through the switch during the ACL reconfiguration.

NOTE:

In a highly secured environment, bring down the port prior to modifying the ACL, and then bring the port back up once the configuration is complete.

Sequence numbering

If no sequence number is specified, the software appends the ACEs to the end of the ACL with a sequence number equal to the highest ACE currently in the list plus 10.

The sequence numbers may be reordered with the access-list {ip|ipv6|mac} <ACL-NAME> resequence command.

Deny ACLs

If multiple ACLs of different types are applied in the same direction, a deny ACE, whether explicit or implicit, in one ACL overrides a permit ACL in another. A deny ACE is an ACE within an ACL that uses the "deny" action keyword. Comment only ACEs are also supported.

Denied ping requests

A ping request is denied when an ACL is applied on ingress or egress.

switch# ping 100.1.2.10
PING 100.1.2.10 (100.1.2.10) 100(128) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted