Users Guide

Conguring ACL Logging
This functionality is supported on the platform.
To congure the maximum number of ACL log messages to be generated and the frequency at which these messages must be generated,
perform the following steps:
NOTE: This example describes the conguration of ACL logging for standard IP access lists. You can enable the logging
capability for standard and extended IPv4 ACLs, IPv6 ACLs, and standard and extended MAC ACLs.
1 Specify the maximum number of ACL logs or the threshold that can be generated by using the threshold-in-msgs count
option with the seq, permit, or deny commands. Upon exceeding the specied maximum limit, the generation of ACL logs is
terminated. You can enter a threshold in the range of 1-100. By default, 10 ACL logs are generated if you do not specify the threshold
explicitly.
CONFIG-STD-NACL mode
seq sequence-number {deny | permit} {source [mask] | any | host ip-address} [log [threshold-
in-msgs count] ]
2 Specify the interval in minutes at which ACL logs must be generated. You can enter an interval in the range of 1-10 minutes. The
default frequency at which ACL logs are generated is 5 minutes. If ACL logging is stopped because the congured threshold has
exceeded, it is re-enabled after the logging interval period elapses. ACL logging is supported for standard and extended IPv4 ACLs,
IPv6 ACLs, and standard and extended MAC ACLs. Congure ACL logging only on ACLs that are applied to ingress interfaces; you
cannot enable logging for ACLs that are associated with egress interfaces.
CONFIG-STD-NACL mode
seq sequence-number {deny | permit} {source [mask] | any | host ip-address} [log [interval
minutes]]
Flow-Based Monitoring Support for ACLs
Flow-based monitoring conserves bandwidth by monitoring only the specied trac instead of all trac on the interface. It is available for
Layer 2 and Layer 3 ingress trac. You can specify trac using standard or extended access-lists. This mechanism copies incoming
packets that matches the ACL rules applied on the ingress port and forwards (mirrors) them to another port. The source port is the
monitored port (MD) and the destination port is the monitoring port (MG).
The port mirroring application maintains and performs all the monitoring operations on the chassis. ACL information is sent to the ACL
manager, which in turn noties the ACL agent to add entries in the CAM area. Duplicate entries in the ACL are not saved.
When a packet arrives at a port that is being monitored, the packet is validated against the congured ACL rules. If the packet matches an
ACL rule, the system examines the corresponding ow processor to perform the action specied for that port. If the mirroring action is set
in the ow processor entry, the destination port details, to which the mirrored information must be sent, are sent to the destination port.
When a stack unit is reset or a stack unit undergoes a failure, the ACL agent registers with the port mirroring application. The port mirroring
utility downloads the monitoring conguration to the ACL agent. The interface manager noties the port mirroring application about the
removal of an interface when an ACL entry associated with that interface to is deleted.
Behavior of Flow-Based Monitoring
Activate ow-based monitoring for a monitoring session by entering the flow-based enable command in the Monitor Session mode.
When you enable this capability, trac with particular ows that are traversing through the ingress interfaces are examined, and
appropriate ACLs can be applied in the ingress direction. By default, ow-based monitoring is not enabled.
You must specify the monitor option with the permit, deny, or seq command for ACLs that are assigned to the source or the
monitored port (MD) to enable the evaluation and replication of trac that is traversing to the destination port. Enter the keyword
Access Control Lists (ACLs)
125