Enterasys Networks Security Router X-PeditionTM - Manual (Page 59)

Utilizing the Command Line Interface
XSR User’s Guide 2-23
Managing Message Logs
Messages produced by the XSR, whether alarms or events, as well as link state changes for critical
ports and a management authentication log, can be routed to various destinations with the
logging command. And by issuing the no logging command, you can block messages to a site
while permitting transmission to others.
For normal operation, you should log only HIGH severity alarms which indicate critical events
and those requiring operator intervention. Be aware that the XSR may drop LOW and DEBUG
level alarms if the system is too busy to deliver them. The number of dropped messages is
displayed by the
show logging command.
Be aware that the DEBUG alarm level is used by maintenance personnel only.
The XSR serves the following logging destinations:
• Syslog (to remote Syslog server over the network)
• Console terminal
• Monitor (up to five CLI sessions via Telnet)
• Buffer (in XSR’s memory)
• File on CompactFlash card when persistent logging (with respect to power loss) is enabled.
This feature is used especially for the firewall (see “Configuring Security on the XSR” on
page 16-1 for more information)
• SNMP Trap (async notification by XSR to the SNMP Manager)
Logging Commands
You can log all messages into a particular destination based on the severity level of the message
(high, medium, low and debug) with the
logging command. Note that entering logging medium
sets that level for all destinations. Also, you can log ACL violations in particular on a per-source
per-ACL group basis with the
access-list log command and view them every five minutes.
Alternatively, you can display the log when it reaches a specified packet threshold with access-
list log-update-threshold . Generally, you can display your logging configuration with show
logging and show or clear messages in the memory buffer with show logging history and
clear logging commands, respectively. Be aware that the entire message history is lost when the
XSR is powered down.
Refer to Appendix A: “Alarms/Events, System Limits, and Standard ASCII Table” on page A-1 for a
thorough listing of XSR alarms/events and the XSR CLI Reference Guide for command details.
Performing Fault Management
When a software problem causes the XSR’s processor to fail, the system captures pertinent data,
produces a Fault Report, and restarts the router automatically. The Fault Report is useful in
diagnosing the problem because it contains the following data relevant to the failure:
• Cause of processor exception
• Time-stamp
• Contents of processor registers
• Operating system status
• Status of tasks, current task (the crashed task)