Implicit Deny
If a packet does not have a match with the criteria in any of the ACEs in the ACL, the ACL denies (drops) the packet. If you need to override the implicit deny so that a packet that does not have a match will be permitted, then you can use the "permit any" option as the last ACE in the ACL. This directs the ACL to permit (forward) packets that do not have a match with any earlier ACE listed in the ACL, and prevents these packets from being filtered by the implicit "deny any".
The ACL tries to apply the first ACE in the list. If there is not a match, it tries the second ACE, and so on. When a match is found, the ACL invokes the configured action for that entry (permit or drop the packet) and no further comparisons of the packet are made with the remaining ACEs in the list. This means that when an ACE whose criteria matches a packet is found, the action configured for that ACE is invoked, and any remaining ACEs in the ACL are ignored. Because of this sequential processing, successfully implementing an ACL depends in part on configuring ACEs in the correct order for the overall policy you want the ACL to enforce.
The order in which an ACE occurs in an ACL is significant.
For example, if an ACL contains six ACEs, but the first ACE allows Permit Any forwarding, then the ACL permits all IPv4 traffic, and the remainingACEs in the list do not apply, even if they specify criteria that would make a match with any of the traffic permitted by the first ACE.
It is important to remember that all IPv4 ACLs
configurable on the switch include an implicit deny
ip any. That is, IPv4 packets that the ACL does not explicitly permit
or deny will be implicitly denied, and therefore
dropped instead of forwarded on the interface. If you want topreempt the implicit deny so that IPv4 packets not explicitly
denied by other ACEs in the ACL will be permitted, insert an explicit
"permit any" as the last ACE in the ACL. Doing so permits
any packet not explicitly denied by earlier entries.