Users Guide
Conguring ACL Logging
This functionality is supported on the platform.
To congure 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 conguration 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 specied 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 congured 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. Congure 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 specied trac instead of all trac on the interface. It is available for
Layer 2 and Layer 3 ingress trac. You can specify trac 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 noties 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 congured ACL rules. If the packet matches an
ACL rule, the system examines the corresponding ow processor to perform the action specied 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 conguration to the ACL agent. The interface manager noties 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, trac 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 trac that is traversing to the destination port. Enter the keyword
Access Control Lists (ACLs)
125