Access Security Guide K/KA/KB.15.15

Table 27 Interface options: (continued)
Filter actionApplication pointACL applicationInterface
inbound IPv4 trafficentering the switch on the VLANVACLVLAN
routed IPv4 traffic entering the
switch and any IPv4 traffic with a
destination on the switch itself
entering the switch on the VLANRACL
2
routed IPv4 traffic exiting from the
switch
exiting from the switch on the
VLAN
1
The information provided here describes ACLs statically configured on the switch. See “RADIUS server support for switch
services” (page 199).
2
Supports one inbound and/or one outbound RACL. When both are used, one RACL can be assigned to filter both inbound
and outbound, or different RACLs can be assigned to filter inbound and outbound.
NOTE: After you assign an IPv4 ACL to an interface, the default action on the interface is to
implicitly deny IPv4 traffic that is not specifically permitted by the ACL. This applies only in the
direction of traffic flow filtered by the ACL.
General ACL operating notes
• ACLs do not provide DNS hostname support. ACLs cannot be configured to screen hostname
IPv4 traffic between the switch and a DNS.
• ACLs Do Not Affect Serial Port Access. ACLs do not apply to the switch’s serial port.
• ACL Screening of IPv4 Traffic Generated by the Switch. Outbound RACL applications on a
switch do not screen IPv4 traffic generated by the switch itself (such as broadcasts, Telnet,
Ping, and ICMP replies). Note that ACLs applied on the switch do screen this type of IPv4
traffic when other devices generate it. Similarly, ACL applications can screen responses from
other devices to unscreened IPv4 traffic the switch generates.
• ACL Logging.
The ACL logging feature generates a message only when packets are explicitly denied
or permitted as the result of a match, and not when implicitly denied. To help test ACL
◦
logging, configure the last entry in an ACL as an explicit deny or permit statement with
a log statement included, and apply the ACL to an appropriate VLAN.
◦ A detailed event will be logged for the first packet that matches a “deny” or “permit”
ACL logged entry with the appropriate action specified. Subsequent packets matching
ACL logged entries will generate a new event that summarizes the number of packets
that matched each specific entry (with the time period).
◦ Logging enables you to selectively test specific devices or groups. However, excessive
logging can affect switch performance. For this reason, HP recommends that you remove
the logging option from ACEs for which you do not have a present need. Also, avoid
configuring logging where it does not serve an immediate purpose. (Note that ACL logging
is not designed to function as an accounting method.) See also “Apparent Failure To Log
All ‘Deny’ or ‘Permit’ Matches” in the section titled “ACL Problems”, found in appendix
C, “Troubleshooting” of the Management and Configuration Guide for your switch.
◦ When configuring logging, you can reduce excessive resource use by configuring the
appropriate ACEs to match with specific hosts instead of entire subnets.
• Minimum Number of ACEs in an ACL. Any ACL must include at least one ACE to enable IP
traffic screening. A numbered ACL cannot be created without at least one ACE. A named ACL
can be created “empty”; that is, without any ACEs. However in an empty ACL applied to an
interface, the Implicit Deny function does not operate, and the ACL has no effect on traffic.
Overview 303