This chapter describes how to use the command line interface (CLI) show commands to monitor system status and performance. These commands have related keywords that you can use to get information on all aspects of the system, from current software configuration to call activity and status.
This chapter describes how to use the command line interface (CLI) show commands to monitor system status and performance. These commands have related keywords that you can use to get information on all aspects of the system, from current software configuration to call activity and status.
See the “Command Line Interface Overview” chapter in the System Administration Guide, for a discussion on chassis access and CLI usage.
See the “Software Management Operations” chapter in the System Administration Guide, specifically the section “Managing Local-User Administrative Accounts”, for more information.
Use the show boot command to check the boot system priority and to see a list of all configuration files and associated builds that have been specified from most recently to up to nine past priorities. If the system is approaching a priority value of 1, delete priorities that will never be needed and restart numbering at a high value (such as 50).
See “Software Management Operations” in the System Administration Guide, specifically the section “Maintaining the Local File System”, for more information.
Use the show snmp trap history command to view SNMP traps. Through v7.1, up to 400 traps can be stored on the chassis as first in first out (FIFO). Anything beyond 400 is dropped. Starting with v8.0, the capacity has been increased to store up to 5000 traps. This longer history is useful in scenarios where issues are not reported or noticed until many days after they have occurred, or when an issue has happened many times over an extended period.
You can configure the chassis to send SNMP traps to a SNMP server application and/or a Cisco Systems EMS server. In the local context, use the commands snmp target, and
snmp community, etc. Maintain the trap server so that it can store traps for an extended period of time. One month is an absolute minimum; three or six months, if space allows, is recommended. Maintain the trap server so that it can handle the trap volume it receives, often from multiple sources besides the ASR 5000. Make sure that it is configured to delete traps beyond a specified time frame.
Refer to “Configuring Management Settings” in the System Administration Guide for more information, and the SNMP MIP Reference Manual.
Logs are stored on the chassis in memory as FIFO. To view all system logs, enter the command show logs. To limit output to a certain level of logging, use the
level qualifier. The range is from all logs to critical logs only. The qualifiers are: debug, trace, info, unusual, warning, error, critical.
You can also save logs to a file locally or remotely with the command save logs. If you save them locally, delete the file after it is saved remotely.
As with SNMP traps, to most safely address logging buffer size constraints, you may configure the chassis to send logging data to a syslog server application to assure that no data gets lost. In the local context, enter the command logging syslog. Note that it is still important to remove unnecessary filters as discussed above. Viewing the logs directly on the ASR 5000 makes troubleshooting faster since you have removed the delay caused by having to retrieve logs from a syslog server. Maintain the server so that it can store logs for an extended period of time. One month is an absolute minimum; three months, if space allows, is recommended. Maintain the server so it can handle the volume it receives, which often includes sources in addition to the ASR 5000. Assure that the server is configured to delete files older than a specific time frame.
To view a list of failures, enter the command show crash list. To see the details of the failure, enter
show crash number x. Through v6.0, the system can store the history list of up to 30 failures. However, the list is not FIFO, and new failures are not saved to the list, which remains static until it is cleared. For these older versions, check the failure list monthly to see if the list has grown. It is important to stay apprised of failure occurrences through the SNMP trap history and report unknown issues to Cisco Systems. It is not unusual for the same type of failure to occur more than once. Knowing the frequency can be valuable for troubleshooting and tracking. The actual failure data may not be as useful because you have already reported it.
On a monthly basis, clear the failure list with the command clear crash list. This command also clears the actual failure data at the same time. Run
show support details to save the failure list and all the data for all failures. If you want to save the data, run the commands individually.
In addition to the failure list and associated data, there is abridged version of failure information known as a mini-core that is stored locally in the /flash/crash directory. Run the command dir /flash/crash to see all the files and the date and times. Match the files with the failure list described above. These can be valuable troubleshooting tools for Cisco Systems Technical Support, though normally the full failure information is the most useful. On a monthly basis, clear out the mini-core files, saving files for troubleshooting specific failure issues.
Full failure information is too large to store in memory, but it may be useful to save it for analysis by Cisco Systems Engineering. Specify a local or remote storage location by entering the local context config command crash enable url. It is recommended that you store the data remotely to avoid running out of memory on the flash. If you decide to store locally, check for failures on a weekly basis. If there are failure log file(s) on the flash, delete them and save them to another location if needed for troubleshooting.
See “Configuring and Viewing System Logs” in the System Administration Guide, specifically the section “Configuring and Viewing Software Crash Logging Parameters”, for more information.
You can monitor all of the current alarms with the show alarm command to give a quick snapshot of all issues.With traps and logs, you must review a list and determine what is currently an issue and what is not. Both have their place, but you should not depend solely on the CLI-based alarm system. Even if you proactively run the
show alarm command on a regular basis, for example every 15 minutes, to monitor system health, a lot can happen in short period of time. Use trap notifications and bulkstats data, discussed below, as the primary mechanism to determine that a problem has occurred.
See “Software Management Operations” chapter in the System Administration Guide, specifically the section “Managing License Keys”, for more information.
See “Software Management Operations” in the System Administration Guide, specifically the section “Software Upgrades”, for more information.