The Packet-Filtering Process - HP ProCurve 6400cl Series Access Security Manual

RADIUS Authentication and Accounting
Configuring a RADIUS Server To Specify Per-Port CoS and Rate-Limiting Services
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.
The packet is not compared to the
4.
ACE.
6-30

The Packet-filtering Process

Sequential Comparison and Action. When an ACL filters a packet, it
sequentially compares each ACE's filtering criteria to the corresponding data
in the packet until it finds a match. The action indicated by the matching ACE
(deny or permit) is then performed on the packet.
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".
Example. Suppose the ACL in figure 6-10 is assigned to filter the traffic from
an authenticated client on a given port in the switch:
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-based ACL. Any inbound ip traffic from the authenticated
client that does not have a match with any of the five explicit ACEs
fourth
in this ACL will be denied by the impl
Figure 6-10. 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.
)
icit "deny any any".