IPv4 Access Control Lists (ACLs)

IPv4 Static ACL Operation

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”.

Example. Suppose the ACL in figure 9-2 is assigned to filter the IPv4 traffic from an authenticated client on a given port in the switch:

For an inbound packet with a destination IP address of 18.28.156.3, the ACL:

1.Compares the packet to this ACE first.

2.Since there is not a match with the first ACE, the ACL compares the packet to the second ACE, where there is also not a match.

3.The ACL compares the packet to the third ACE. There is a exact match, so the ACL denies (drops) the packet.

4.The packet is not compared to the fourth ACE.

Permit in ip from any to 18.28.136.24

Permit in ip from any to 18.28.156.7 Deny in ip from any to 18.28.156.3 Deny in tcp from any to any 23 Permit in ip from any to any

(Deny in ip from any to any)

This line demonstrates the “deny any any” ACE implicit in every RADIUS-assigned ACL. Any inbound IPv4 traffic from the authenticated client that does not have a match with any of the five explicit ACEs in this ACL will be denied by the implicit “deny any any”.

Figure 9-2. Example of Sequential Comparison

As shown above, 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.

9-21