|
|
To verify Cisco UGM system performance and reliability, follow the troubleshooting procedures described in this appendix:
 |
Note See the Release Notes for additional tips and debugging information. |
If available disk space on your server is low or unavailable, verify that only the export data that you want is stored. Predefined and customized export data is stored in the directory specified by you in the File Export Properties dialog box. The exported data can be:
To free up disk space, you can delete or archive these files to another location.
With Cisco EMF, you can back up and restore databases (which are typically located in <CEMFROOT>/.../AVBackup) by using the Cisco EMF script (cemf), typically located in /opt/cemf/bin.
 |
Caution If Cisco UGM is reinstalled (after the Cisco UGM initial installation), any existing data is lost. Back up any existing data before reinstalling Cisco UGM. |
Step 1 Start an X-session.
Step 2 Change to the following directory:
cd /opt/cemf/bin
Step 3 To run the backup script, enter:
./cemf backup
This command backs up the databases currently in <CEMFROOT>/.../AVBackup.
With Cisco EMF, you can back up and restore databases (which are typically located in <CEMFROOT>/.../AVBackup) by using the Cisco EMF script (cemf), typically located in /opt/cemf/bin.
|
Caution Although Cisco EMF allows for selective restoration of its database, Cisco UGM doesn't support this feature. When restoring Cisco UGM data, you must restore all Cisco EMF databases. |
Step 1 Start an X-session.
Step 2 Change to the following directory:
cd /opt/cemf/bin
Step 3 Enter the following command to stop Cisco EMF:
./cemf stop
Step 4 Enter the following command:
./cemf restore
Step 5 Enter the date that the backup was created:
mm-dd-yyyy
If you backed up your database on 5/29/2000, the backup file directory and configuration are saved in a directory named 05/29/2000, which reflects the date when the backup was performed.
In order to restore the database as of 5/29/2000, enter this command:
./cemf restore -t 05-29-2000
Refer to the Cisco Element Management Framework Installation Guide for further details.
Cisco EMF stores system information in log files located in <CEMFROOT>/logs/ (typically /opt/cemf/logs/). The Cisco UGM application-specific log messages are located in the following (ASCII text) log files:
The name of each .log file corresponds to the Cisco UGM process that generates the log file.
Each .old file is the backup file for the .log file. (For example, commonCtrl.old is the backup file for commonCtrl.log.
By default, DEBUG entries are not included in log files. To see log messages of DEBUG severity (this includes all other severities), follow these steps:
Step 1 Locate the loggercommon.include file in the <CEMFROOT>/config/init/ directory.
Step 2 Change this setting to 15 (1111 binary).
By default the loggingLevelMask is set to 10 (1010 binary).
|
Note Changing the level to 15 affects how quickly the log files are
archived as .old files. Any changes you make to the
loggercommon.include file do not take effect until you restart Cisco UGM. |
For the ASMainCtrl and commonCtrl files, you can change the log level without starting and stopping Cisco EMF.
Choose commonEM > ASMainCtrlLog > Log Level Configuration.
Or
Choose commonEM > commonCtrlLog > Log Level Configuration.
|
Note Numerous other log files are also available for troubleshooting. They are stored in the <CEMFROOT>/logs/ directory. |
 |
Tip From time to time, run the listCores script in <CEMFROOT>/bin/ (typically /opt/cemf/bin). The report shows any core files affected by any malfunctioning processes. Whenever you see an affected core file, report it to Cisco customer support. |
Step 1 Locate the corresponding .ini file in the <CEMFROOT>/config/init/ directory.
Step 2 In the logger section of the .ini file, enter the size (in KBytes):
[logger]5000
#include "loggercommon.include"
loggingName = xxxxCtrl
maxLogfileSize =
(In this example, the user specified a 5 MB log file.)
Step 3 Stop and restart Cisco EMF.
When the .log file reaches the maximum size that you specified, it is archived to a corresponding .old file, and a new .log file is created.
If you reset and restart Cisco EMF, the historyCriteria files are not loaded automatically. If you do not see any monitored performance parameter in the Performance Manager, follow this procedure:
Step 1 On an X terminal, enter these commands:
/opt/cemf/bin/cemf shell
Step 2 Check the existing historyCriteria files in the system by entering:
/opt/cemf/bin/historyAdmin list
Step 3 If you do not find a historyCriteria file, enter these commands:
/opt/cemf/bin/historyAdmin add /opt/cemf/bin/historyCriteria
If any of the following actions fail:
Check the message in the Action Report window.
If the ERROR: input file does not exist or is not a valid file message appears when you re-associate file repository object with a new file, follow these steps:
Step 1 Enter the correct file path and name in the New File Path field.
|
Note You must specify a file that exists. |
Step 2 Enter the correct file type.
|
Tip If you re-associate a configuration file object with a new file, make sure that the new file is an ASCII file; if you re-associate an image (IOS image, modem image, or SPE image) file object with a new file, make sure that the file is executable. |
This error occurs when you try to download configuration or image files.
Step 1 Associate the configuration or image file object with the device object.
See the "Task 5: Option 1: Associating a Configuration File with a Device Object" section.
Step 2 Check that the file object was not deleted.
This section describes errors that may occur during the discovery and deployment of Cisco UGM managed devices.
If the "Deployment Failed" message appears when you are importing files or images, follow these steps:
Step 1 Enter the correct file path and name.
|
Note You must specify a file that exists. |
Step 2 Enter the correct file type.
If you import a configuration file, make sure that the file is an ASCII file; if you import an image (IOS image, modem image, SPE image), make sure that the file is executable.
Step 3 Enter this UNIX file command to identify the type of file:
file <aConfigurationFile><aConfigurationFile>:ascii text
If discovery displays an error icon for some devices in a specified discovery range:
Step 1 Check if IP routes have been defined for these devices.
Step 2 Check if the devices are receiving power and operational.
Step 3 Delete the errored devices and run discovery again.
Step 1 Check that you specified the correct device.
Step 2 Check that the specified IP address and device name are unique to the Cisco UGM-managed network.
Step 1 Check the Event Browser window for traps that may identify a problem with the device.
Step 2 Check if SNMP is still accessible by using a tool (such as SNMP Walk) to read SNMP tables.
Step 3 Ping the device.
This section describes errors that may occur while managing faults generated by Cisco UGM managed devices.
Step 1 Check that the required SNMP trap groups are enabled (through Cisco IOS) on the device.
Step 2 Verify that the IP address of the Cisco UGM server is properly configured (through Cisco IOS) as a trap recipient on the device.
Step 3 Verify that the device can reach the Cisco UGM server. (By using Cisco IOS, ping the Cisco UGM server from the device.)
Step 4 Verify that the Cisco UGM server is receiving SNMP traps sent from the device.
Step 5 Verify that SNMP traps from the device are reaching the main controller process (ASMainCtrl). You can do this by enabling the informational logging level, and scanning for "SNMP Trap" messages within this log file:
<CEMFROOT>/logs/ASMainCtrl.log
If a remote host that was configured as a destination for trap forwarding is not receiving SNMP traps:
Step 1 Verify that the remote host object and its associated list of trap specifier objects were properly created in the hierarchical object tree under the TrapForwarding object in ASEMSConfig view.
Step 2 Verify that the correct remote host destination (IP address or hostname) was configured in Cisco UGM.
Step 3 Verify that the Cisco UGM server can reach the remote host. (By using
Cisco IOS, ping the remote host from the Cisco UGM server.)
Step 4 Verify that the correct trap specifier values (Enterprise ID, Generic ID, and Specific ID) are configured in Cisco UGM.
Step 5 Click Accept Saved Setting in the Trap Forwarding Properties dialog box.
This section describes errors that may occur while obtaining performance data from Cisco UGM managed devices.
If you receive frequent Missed Poll messages in the Cisco EMF Performance Manager while charting performance parameters for a managed device, the performance polling load exceeds the capacity of Cisco EMF to complete the specified polling operations.
Select one of these options:
If you observe that Cisco UGM takes longer to poll than the polling period that you selected in the Cisco EMF Performance Manager, select a longer polling period for the same performance parameters.
Change the polling period by following this procedure:
Step 1 In the Map View, choose ASEMSConfig > PerfPollConfig > Open Global Performance Polling Configuration.
Step 2 Click the appropriate tabs for the performance parameters that you need to change.
Step 3 In the drop-down menu, select a longer polling interval.
Step 4 Click Save in the menu bar.
Step 1 In the Map View, right-click a site (or other container) icon.
Step 2 Choose ASMainEM > Start/Stop Performance Polling.
Step 3 Select one or more devices.
Step 4 Select PerformancePolling - OFF.
Step 5 Click the Save button.
This section describes errors that may occur while configuring the administrative state of Cisco UGM managed devices.
The Action Report indicates a ping failure which indicates that a telnet connection cannot be established to the device where the card is installed. This is likely due to ping failure during session setup, or bad device configuration.
To resolve ping failure, complete these steps:
Step 1 Retry the Configure Administrative State action twice.
See "Configuring the Administrative State of Objects."
Step 2 Open a telnet session to the device to verify that the passwords are correct and the device is reachable.
Step 3 Retry the Configure Administrative State action twice.
If the ping failure persists, the device configuration (particularly the passwords) specified for Cisco UGM may not match the passwords known to the device.
Step 4 Enter passwords for Cisco UGM:
a. In the Physical view, right-click the chassis object.
b. Select Open Device Readiness Configuration dialog box.
c. Select Group (if authenticating with TACACS), or select Local.
d. Enter the passwords.
Dialog box display fields are updated, even though you do not click an Action button.
This occurs because you started an action for a card, closed the dialog box, and then reopened the dialog box for the same card.
Even if the dialog box is closed, the action continues until the number of active DS0s drop to 0 and the card shuts down.
There is no resolution for this occurrence.
|
Note Once the dialog box is closed, there is no indication that the action is still in progress. The only ways to determine this is to reopen the dialog box for that object, or start another Configure Administrative State action. |
|
Tip Action Reports are not generated for closed dialog boxes (even if you reopen them). |
These messages appear in the Event Browser and are generated under the following circumstances:
Online Insertion or Removal (OIR) is described in the "Graceful Shutdown Alarm" section.
The alarm indicates that the card is in an indeterminate state. (For example: a busyout command may have been issued for the card but without the required subsequent shutdown command).
Step 1 Retry the action. (Click either Graceful Shutdown or Accept Traffic).
Step 2 Manually clear the alarm when the action succeeds.
The Progress Information field indicates that an action was completed before you clicked the button.
Any information that you see in the display fields may have been generated by another (possibly previous, possibly currently running) Configure Administrative State action.
The timestamp in the Progress Information field tells you when an action ended. The field is updated if an action is currently running.
There is no resolution for this occurrence.
Indicates that a graceful shutdown is in progress; the number of active DS0s reaches 0, an alarm event is raised, and a graceful shutdown occurs.
Reasons for this alarm are:
|
Note You may ignore the alarm temporarily. |
A graceful shutdown for the chassis is implemented as a busyout followed by a shut down. Therefore, when the number of DS0s reaches 0, the card is shut down. This causes a "card removed" trap to be generated. Cisco UGM then deletes the card object, causing any activity for that card (e.g. Graceful Shutdown) to end abruptly. Thereby, an alarm is raised.
Clear the alarm manually.
This error occurs when the Accept Traffic command fails to bring up some or all T1/E1/T3 controllers.
Accept Traffic directs Cisco UGM to bring up all possible T1/E1/T3 controllers (as appropriate) for the specified card. After telling the chassis to bring up the controllers for the card, the Accept Traffic logic delays checking for "up" T1/E1/T3 controllers until approximately 40 seconds have elapsed. Any controllers that do not come up within that time are identified in the Action Report.
|
Note This explanation does not describe all possible reasons for an Accept Traffic failure. |
Click Accept Traffic again. If the problem persists, there could be a possible IOS configuration problem or a switch (signaling) problem.
This section describes errors that may occur during IOS operations running with Cisco UGM.
Make sure you set the Line and Enable Password correctly in the Device Readiness Configuration dialog box.
See the "Task 1: Preparing the Device for Configuration" section.
Step 1 Check that the device is in the normal (commissioned) state.
Step 2 If you use the console Configuration Interface, check that the console address and port number are set correctly.
Step 3 Ping the IP address to see if there is any network delay.
Make sure that there is no other console login session running because only one user (at a time) can log in from the console.
Posted: Sat Sep 28 16:54:17 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.