Fabric OS Administrator’s Guide 59
53-1001763-02
Audit log configuration 3
Out of range Flash contributing to MARGINAL status: (0..1) [1]
MarginalPorts contributing to DOWN status: (0..1800) [112]
MarginalPorts contributing to MARGINAL status: (0..1800) [44]
FaultyPorts contributing to DOWN status: (0..1800) [112]
FaultyPorts contributing to MARGINAL status: (0..1800) [44]
MissingSFPs contributing to DOWN status: (0..576) [0]
MissingSFPs contributing to MARGINAL status: (0..576) [0]
No change
On the Brocade 48000, and Brocade DCX and DCX-4S enterprise-class platforms, the command
output includes parameters related to CP blades.

Audit log configuration

When managing SANs you may want to audit certain classes of events to ensure that you can view
and generate an audit log for what is happening on a switch, particularly for security-related event
changes. These events include login failures, zone configuration changes, firmware downloads,
and other configuration changes—in other words—critical changes that have a serious effect on the
operation and security of the switch.
Important information related to event classes is also tracked and made available. For example,
you can track changes from an external source by the user name, IP address, or type of
management interface used to access the switch.
Auditable events are generated by the switch and streamed to an external host through a
configured system message log daemon (syslog). You specify a filter on the output to select the
event classes that are sent through the system message log. The filtered events are streamed
chronologically and sent to the system message log on an external host in the specified audit
message format. This ensures that they can be easily distinguished from other system message log
events that occur in the network. Then, at some regular interval of your choosing, you can review
the audit events to look for unexpected changes.
Before you configure audit event logging, familiarize yourself with the following audit event log
behaviors and limitations:
•By default, all event classes are configured for audit; to create an audit event log for specific
events, you must explicitly set a filter with the class operand and then enable it.
•Audited events are generated specific to a switch and have no negative impact on
performance.
•The last 256 events are persistently stored on the switch and are streamed to a system
message log.
•The audit log depends on the system message log facility and IP network to send messages
from the switch to a remote host. Because the audit event log configuration has no control over
these facilities, audit events can be lost if the system message log and IP network facilities fail.
•If too many events are generated by the switch, the system message log becomes a bottleneck
and audit events are dropped by the Fabric OS.
•If the user name, IP address, or user interface is not transported, None is used instead for
each of the respective fields.
•For High Availability, the audit event logs exist independently on both active and standby CPs.
The configuration changes that occur on the active CP are propagated to the standby CP and
take effect.
•Audit log configuration is also updated through a configuration download.