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
To Next Page
Loading...
Need help?
General
