Enterasys Networks X-PeditionTM manual Managing Message Logs, Performing Fault Management

Utilizing the Command Line Interface

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-1for 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-1for 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)

XSR User’s Guide 2-23