|
|
To verify Cisco UGM system performance and reliability, follow the troubleshooting procedures described in this chapter:
 |
Note Additional sources of troubleshooting information: Cisco EMF and Cisco UGM Release Notes for additional tips and debugging information. Individual chapters of the Cisco Universal Gateway Manager User Guide. Chapter 2, Upgrading Cisco Universal Gateway Manager (in this document) for information on troubleshooting the upgrade procedure. |
This section contains the following procedures:
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. (Access this dialog by choosing from the Map Viewer, ASEMSConfig > File Export Properties.)
The exported data can be:
To free up disk space, you can delete or archive these files to another location.
For a detailed description of this procedure, refer to the Cisco Element Management Framework Installation and Administration Guide.
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 Log in as a root user.
Step 2 Change to the bin directory of Cisco EMF:
cd /opt/cemf/bin
Step 3 Enter the following command to run the backup script:
./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 Log in as the root user.
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/2002, the backup file directory and configuration are saved in a directory named 05/29/2002, which reflects the date when the backup was performed.
In order to restore the database as of 5/29/2002, enter this command:
./cemf restore -t 05-29-2002
Refer to the Cisco Element Management Framework Installation Guide for further details.
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 Log in as the root user.
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 restoreDataset
A list of stored backups (by weekly date) appears.
Step 5 Select the relevant week.
Step 6 Select the relevant backup.
Refer to the Cisco Element Management Framework Installation Guide for further details.
When the IOSConfigCtrl, ASMainCtrl, ASFaultStandAlone, and ASPerformInv controllers start, they read these values from the database and set their logging levels accordingly.
These logging levels are stored even if Cisco EMF and Cisco UGM stop. The logging levels are erased only if the database is reset.
 |
Tip You can set logging levels for several controllers at the same time by selecting their corresponding objects from the list in the left pane of the dialog box. |
Step 1 Select one or more of these:
Step 2 Select On or Off for these logging levels:
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, ASMainCtrl.old is the backup file for ASMainCtrl.log.
|
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
These files contain parameters relevant to the discovery and deployment of devices.
This section contains the following error descriptions and their recovery procedures:
For additional information, see the Cisco Element Management Framework Installation and Administration Guide.
After you install Cisco UGM, and the install script reports that the Cisco UGM controllers are successfully installed, perform these checks for possible errors.
Step 1 Check the ugminstall.log located in the /tmp directory.
Step 2 Check if the Cisco UGM processes are up and running by entering this command:
ps -ef | grep
The ASMainCtrl, IOSConfigCtrl, and ASFaultStandAlone processes should be running at this time.
If CiscoView cannot be launched from Cisco UGM, follow these steps:
Step 1 From the Netscape browser window, choose Help > About Plugins.
Step 2 Check that the Java Plugin version is 1.3.1.
Step 3 Check the path defined for the Java plugin:
a. Open the <CEMF_ROOT>/bin/UgmLaunchCVClient_Wrapper.sh file.
b. Look for the line containing JAVA_HOME.
Example: JAVA_HOME=/usr/j2se
Step 4 Check that the home directory for the Java plugin is correct.
See the "Installing the Java Plugin for Operating CiscoView with Cisco UGM 2.1" section.
Step 5 When you have corrected the path to the Java plugin, launch CiscoView again.
In order to clear this error, follow these steps.
Step 1 Open a terminal window on the Sun server.
Step 2 Change to this directory:
cd /opt/cemf/bin
./cemf stop
Step 4 Reset the Cisco EMF database by entering these commands:
./cemf reset
WARNING -- This will remove all the databases. All of your data will
be lost. Are you sure [N/Y]:
Step 5 Enter Y (yes).
Step 6 Enter this command to start Cisco EMF:
./cemf start
Step 7 Enter this command to start a Cisco EMF session:
./cemf session
The Map Viewer appears, and all Cisco UGM views should be present.
After you install Cisco UGM, view the avLoad.log file (located in the /opt/cemf/logs directory) to ensure that no installation errors occurred.
Step 1 Change to this directory by entering the following command:
cd /opt/cemf/logs
Step 2 Open the log file by entering the following command:
vi avLoad.log
Step 3 Examine the file and ensure that no error messages are printed to this file.
When Cisco UGM is uninstalled and installed again, all device objects are deleted. If the Map Viewer still shows device objects, follow this procedure.
Step 1 Open a terminal window on the Sun server.
Step 2 To change to this directory, enter:
cd /opt/cemf/bin
Step 3 Enter this command:
./cemf stop
Step 4 Reset the Cisco EMF database with these commands:
./cemf reset
WARNING -- This will remove all the databases. All of your data will
be lost. Are you sure [N/Y]:
Step 5 Enter Y (yes).
Step 6 Enter this command to start Cisco EMF:
./cemf start
Step 7 Enter this command to install Cisco UGM:
./ installems
Step 8 Enter this command to start a Cisco EMF session:
./cemf session
The Map Viewer appears, and no device objects are present.
This error occurs after you reboot the Sun server and enter a ./cemf session command.
In order to clear this error, follow these steps.
Step 1 Open a terminal window on the Sun server.
Step 2 To change to this directory, enter:
cd /opt/cemf/bin
./cemf query
All the CEMF-related processes that are running appear.
Step 4 Enter this command:
./cemf start
|
Note If any of the processes are not running, repeat Step 3 until all the processes are running. |
This error occurs when you enter the ./cemf start command.
In order to clear this error, follow these steps.
Step 1 Open a terminal window on the Sun server.
Step 2 Change to this directory:
cd /opt/cemf/bin
Step 3 Enter this command:
./cemf stop
Step 4 Reset the Cisco EMF database with these commands:
./cemf reset
WARNING -- This will remove all the databases. All of your data will
be lost. Are you sure [N/Y]:
Step 5 Enter Y (yes).
Step 6 Enter this command to start Cisco EMF:
./cemf start
This message appears when a Cisco EMF application stops. In order to clear this error, follow these steps.
Step 1 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 2 To check which Cisco UGM processes are running, enter:
./cemf query
The processes to check for are ASMainCtrl, IOSConfigCtrl, ASFaultStandAlone, and ASPerformInv.
Step 3 To start terminated processes, enter:
./sysmgrClient -x <process-name>
This message indicates that the hostname entered for CiscoView installation does not exist in the /etc/hosts directory.
Reenter the hostname (see the "Installing the Cisco UGM Software Image" section).
This section contains the following error descriptions and their recovery procedures:
For additional information, see the Cisco Element Management Framework Installation and Administration Guide.
The "Deployment Failed" message appears in the Deployment Wizard -- Results dialog.
Step 1 In the Deployment Wizard -- Object Parameters dialog, 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, modem, SPE, or VFC), make sure that the file is binary.
Step 3 Enter this UNIX command to identify the type of file:
file <aConfigurationFile><aConfigurationFile>:ascii text
Step 4 Check if the file to be imported has the right permission.
|
Note You cannot import a file with permission 111. |
This error is caused by incorrect MIB information on the Cisco AS5800 device. The MIB information changed when cards (especially the voice feature card) in the device were hot swapped.
Step 1 Power off the device.
Step 2 Power on the device.
Step 3 Manually delete the device object from the Map Viewer.
Step 4 Redeploy the device object.
See the Cisco Universal Gateway Manager User Guide for details on deployment.
With this condition, device objects transition into the error state and no device components are discovered.
To clear this error, follow these steps.
Step 1 Check for an internal (Cisco UGM or Cisco EMF) problem by checking log files (see the "About Viewing Log Files" section).
Step 2 If this is an internal Cisco UGM problem:
a. Delete the device object.
b. Rediscover the device object.
Step 3 If this is a Cisco IOS problem, check the MIBs on the device for any abnormalities such as duplicate cards.
With this condition, device objects transition into the error state and no device components are discovered.
To clear this error, follow these steps.
Step 1 Check log files (see the "About Viewing Log Files" section).
Step 2 To decommission and commission the device object:
a. Select AS5xxx object> Chassis > Chassis Commissioning.
b. Click Decommission.
c. Select AS5xxx object> Chassis > Chassis Commissioning.
d. Click Commission.
Step 3 Check if the database is corrupted.
Step 4 If the database is corrupted, reset the database:
a. Back up the database (see the "Backing Up Your Database" section.)
b. Restore the database (see the "Restoring Your Database Manually" section and the "Restoring Your Database Interactively" section).
This error occurs both during auto discovery and manual deployment. Device objects transition to the errored state, and no device components are discovered. A major alarm is raised against the device object.
Increase the SNMP timeout and number of retries values in the ASMainCtrlUser.ini file.
[deployment]
attrValueSnmpRetries= xx (default value is 4)
attrValueSnmpTimeout= yy (default value is 500 ms)
Step 1 Check the system log files (see the "About Viewing Log Files" section).
Step 2 Check the specified values for SNMP community strings.
Step 3 Right-click the container object and select Deployment > Auto discovery.
Step 4 Check the specified values for SNMP community strings.
Step 5 Check these values in the configuration file for the managed device.
snmp-serve community private/public RO
snmp-serve community private/public RW
Step 6 If necessary, change the values in the deployment dialogs to match those in the device configuration file.
If you see an error icon for some devices in a specified discovery range:
Step 1 Check if the 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.
The number of failures can be controlled by increasing the values of two variables in the ASMainCtrlUserData.ini file:
The default value for each variable is 3.
When the maximum number of retries is reached, the device object enters the error state and a major alarm is raised.
This condition appears when a device (that was originally manually deployed) goes into a decommissioned state (with a major alarm) when subsequently auto discovered.
To clear this error follow these steps:
Step 1 Check the Event Browser for an alarm description.
Step 2 If the Event Browser shows a sysOID mismatch:
a. Delete the device object.
b. Deploy the device by using the correct template.
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.
Frequent rediscovery could occur as often as every polling cycle for card- or device-level presence polling. Polling frequency affects the Event browser performance.
This condition occurs if either of these conditions is present:
In order to clear this condition, follow these steps:
Step 1 Use NTP to synchronize managed devices with the Cisco UGM server.
Step 2 Reduce presence polling frequencies.
Refer to the Universal Gateway Manager User Guide.
This error appears in the Map Viewer as incorrect associations between device component objects and the parent device.
This error is caused by an incomplete handover when the device comes out of the handover state.
To clear this error, follow these steps:
Step 1 Increase the handover interval by changing these values in the ASMainCtrlUserData.ini file:
AS5800ChassisHandoverLingerSec=
AS5800ChassisHandoverLingerSec=
The default value for these variables is 90 seconds.
Step 2 To initiate rediscovery on the device:
a. Choose AS5xxx object> Chassis > Chassis Commissioning.
b. Click Decommission.
c. Choose AS5xxx object> Chassis > Chassis Commissioning.
d. Click Commission.
|
Tip |
This section contains the following error messages and their recovery procedures:
For additional information, refer to the Cisco Element Management Framework Installation and Administration Guide.
If the ERROR: input file does not exist or is not a valid file message appears when you reassociate file repository objects 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 reassociate a configuration file object with a new file, make sure that the new file is an ASCII file; if you reassociate an image (IOS image, modem image, SPE image, or VFC image) file object with a new file, make sure that the file is binary. |
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. (Refer to the Cisco Universal Gateway Manager User Guide.)
Step 2 Check that the file object was not deleted.
This error occurs as a result of the Send Configuration to Startup action, and the message appears in the Action Report.
Step 1 Open the Associate Configuration File Object with Device dialog by choosing Configure Device > Associate Configuration File Object with Device.
Step 2 Make sure that a configuration file is associated with the device.
Step 3 Click Send Configuration to Startup.
This error occurs as a result of the Send Configlet to Running action, and the message appears in the Action Report.
Step 1 Open the Associate Configlet Object with Device dialog by choosing Configure Device > Associate Configlet Object with Device.
Step 2 Make sure that a configlet is associated with the device.
Step 3 Click Send Configlet to Running.
This error appears in the Action Report, and occurs as a result of any of these actions:
Step 1 From a container or device object to be configured, select Configure Device > Open Device Authentication Information.
Step 2 Check the specified values for login, password, enable password.
Step 3 Check the same values in the configuration file for the managed device.
Step 4 Change the values in the Device Authentication Information dialog to match those in the device configuration file.
This error appears in the Action Report, and occurs as a result of any of these actions:
Step 1 From a container or device object to be configured, select Configure Device > Open Device Authentication Information.
Step 2 Check the specified values for login, password, and enable password.
Step 3 Check the same values in the configuration file for the managed device.
Step 4 Change the values in the Device Authentication Information dialog to match those in the device configuration file.
This error appears in the Progress window and occurs as a result of a Cisco IOS image upgrade action.
This error occurs as a result of upgrading a Cisco IOS image.
Step 1 From a container or device object, choose Configure Device > Associate Firmware File Object with Devices.
Or
Choose Configure Device > Associate IOS Image File Object with Device.
Step 2 Check the name of the file associated with the managed device object.
Step 3 In the Map Viewer, click the NAS-File-Repository.
Step 4 Check if the associated firmware or image file is listed.
Step 5 If the file object does not appear in the repository, from the AS5xxxImages folder in the NAS-File-Repository, choose Deployment > Import NAS File Object.
Step 6 After importing the image, associate it with the device object.
Step 7 Repeat the image upgrade action.
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser and is accompanied by the "Invalid Copy Operation" message in the Progress window.
This error occurs as a result of upgrading a Cisco IOS image.
Step 1 From a container or device object, choose Configure Device > Associate Firmware File Object with Devices.
Or
Choose Configure Device > Associate IOS Image File Object with Device.
Step 2 Check the name of the file associated with the managed device object.
Step 3 In the Map Viewer, click the NAS-File-Repository.
Step 4 Check if the associated firmware or image file is listed.
Step 5 If the file object does not appear in the repository, from the AS5xxxImages folder in the NAS-File-Repository, choose Deployment > Import NAS File Object.
Step 6 After importing the image, associate it with the device object.
Step 7 Repeat the image upgrade action.
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser and is accompanied by the "Device Full" message in the Progress window.
This error occurs when you upgrade a Cisco IOS image.
Check the available Flash memory on the device. (For Cisco AS5800 devices, check the available boot Flash memory.)
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser, and is accompanied by the "Unknown Error" message in the Progress window.
This error occurs when you upgrade a Cisco IOS image on a Cisco AS5800 device.
Check the available Flash memory on the device. (For Cisco AS5800 devices, check the available boot Flash memory.)
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser and is accompanied by the "IOS image upgrade unable to reload the chassis, Timeout" message in the Progress window.
This error occurs when you upgrade a Cisco IOS image followed by a Reload operation on a Cisco AS5800 device.
Step 1 From the Cisco AS5800 router shelf, enter this command:
execute-on slot n sh vers
Where n is either 12 or 13 (the slot number of the dial shelf).
Step 2 If you are prompted for a password, modify the dial shelf configuration file to include:
conf t
line vty 0 4
no login
end
Step 3 Repeat the command:
execute-on slot n sh vers
Where n is either 12 or 13 (the slot number of the dial shelf).
You are not prompted for a password.
Step 4 Repeat the Cisco IOS image upgrade followed by Reload.
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser and is accompanied by the "Could not Connect" message in the Progress window.
This error occurs when you upgrade an image.
Step 1 From a container or device object to be configured, choose Configure Device > Open Device Authentication Information.
Step 2 Check the specified values for login, password, and enable password in this dialog.
Step 3 Check the same values in the configuration file for the managed device.
Step 4 Change the values in the Device Authentication Information dialog to match those in the device configuration file.
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser and is accompanied by the "An internal error has occurred" message in the Progress window.
This error occurs as a result of any image upgrade action.
Step 1 From a container or device object to be configured, choose Configure Device > Open Device Authentication Information.
Step 2 Right-click a site or region object and choose Deployment > Deploy Access Servers.
Step 3 Check the specified values for SNMP community strings.
Step 4 Right-click the container object and choose Deployment > Auto discovery.
Step 5 Check the specified values for SNMP community strings.
Step 6 Check these values in the configuration file for the managed device.
snmp-serve community private/public RO
snmp-serve community private/public RW
Step 7 If necessary, change the values in the deployment dialogs to match those in the device configuration file.
Step 8 Repeat the image upgrade.
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser, and is accompanied by the "Invalid Server Address" message in the Progress window.
This error occurs when you upgrade an image by using the NAS TFTP host.
Check the configuration file of the device that is being used as a TFTP server, and make sure that the device has been configured to act as a TFTP server.
You can configure the device by using configlets, building a configuration file, or through Cisco IOS commands.
For details on the Cisco IOS commands, refer to the Cisco IOS Release 12.0 Configuration Fundamentals Configuration Guide (Chapter: File Management, Section: Configuring Additional File Transfer Functions).
The "Upgrade xxx Image Operation Failed" message appears in the device's Event Browser, and is accompanied by the "Invalid Source Name" message in the device's Event Browser.
This error occurs when you upgrade an image by using the NAS TFTP host.
Check if the image file exists in the NAS TFTP server's Flash memory.
Enter the following command:
netstat -na | grep 69
Cisco UGM returns a report containing this line:
*.69 Idle
Step 1 Verify that the /tftpdir directory is linked to <CEMFROOT>/config/IOSConfigCtrl/IOSFiles.
Step 2 Verify that there is a lochness subdirectory.
Step 3 Verify that all the directories and files have permission mode 777.
This section contains the following error descriptions and their recovery procedures:
For additional information, refer to the Cisco Element Management Framework Installation and Administration Guide.
Step 1 Check that the required SNMP trap groups are enabled (through Cisco IOS commands) on the device. These groups consist of snmp-server enable traps.
Step 2 Verify that the IP address of the Cisco UGM server is properly configured (through Cisco IOS commands) as a trap recipient on the device (example: snmp-host ugm server ip address public).
Step 3 Verify that the community string is configured (through Cisco IOS commands) on the device. (Example: snmp-server community public RO, snmp-server community private RW.)
Step 4 Verify that the trap source is configured (through Cisco IOS commands) on the device (example: snmp-server trap-source f0/0).
Step 5 Verify that the device can reach the Cisco UGM server. (By using Cisco IOS commands, ping the Cisco UGM server from the device.)
Step 6 Verify that the Cisco UGM server is receiving SNMP traps sent from the device.
Step 7 Verify that SNMP traps from the device are reaching the controller process in the Cisco UGM server (ASFaultStandAlone). You can do this by enabling the Informational logging level and Debug logging level (ASEMSConfig > LoggingConfiguration > ASFaultStandAlonelog.) You can tail -f the log file in the <CEMFROOT>/logs/ASFaultStandAlone.log to monitor received traps.
Step 8 Verify that the managed devices are not in a decommissioned state.
Step 9 Verify that the traps sent from the managed devices are supported by Cisco UGM. See the Cisco Universal Gateway Manager User Guide for a list of supported traps and alarms.
Step 10 Verify that Cisco UGM supports the managed devices (Cisco AS5300, AS5350, AS5400, AS5800, and AS5850 devices). Traps from unsupported devices are discarded.
Step 11 Verify that Cisco UGM supports the Cisco IOS image installed on the device. (For details on supported images, see the Cisco Universal Gateway Manager Release Note.) Cisco UGM discards traps from devices with unsupported images.
If a remote host that was configured as a destination for trap forwarding is not receiving SNMP traps, follow these steps:
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 the 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 commands, 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.
Step 6 Verify that the trap forwarding configuration is saved. View the trapForwardFile located in <CEMFROOT>/config/data/trapForwardFile.
An alarm event is raised against the device, but you cannot see the alarm in the Event Browser:
Step 1 Verify your query setup for the event. (Open the Event Browser and select Edit > Query setup.)
Step 2 Verify that missing events have not been manually cleared. See the Event History to view all past events. (From the Event Browser, select View > Event History.)
If alarm events are manually cleared, Cisco UGM does not generate the alarm events, again even though the alarm conditions are still present.
Step 1 Check the ASFaultStandAlone.log file for errors or warning messages. (See the "About Viewing Log Files" section.)
Step 2 If the log shows that the problem is in link up/down events, check for a mismatch between ifIndex parameters in the device and Cisco UGM.
Step 3 If a mismatch is detected, redeploy the device.
This section contains the following error descriptions and their recovery procedures:
For additional information, see the Cisco Element Management Framework Installation and Administration Guide.
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 these steps:
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.
Step 1 Login as the superuser (su).
Step 2 From the command line, enter:
<CEMF_ROOT>/bin/cemf start
where <CEMF_ROOT> is the directory in which Cisco EMF is installed.
The Cisco EMF processes start, and a message informs you when the startup is complete.
Step 1 Check if polling occurred during the polling period requested. If no polling occurred, change the polling period:
a. In the Map View, choose ASEMSConfig > PerfPollConfig > Open Global Performance Polling Configuration.
b. Click the appropriate tabs for the performance parameters that you need to change.
c. In the drop-down menu, select a shorter polling interval.
d. Click Save in the menu bar.
Step 2 Ensure that polling can occur:
a. Check that performance polling interval is enabled for the attributes (see
Step 1 of this procedure).
b. Check that an appropriate performance polling interval is selected (see
Step 1 of this procedure).
c. Check that the device is reachable.
d. Make sure that performancePolling-ON is selected for the device. (Choose ASMainEM > Start/Stop Performance Polling.)
The object in question is usually a container object such as NextPort SPE. Go to the next (lower) level for information on attributes.
Step 1 From the Map viewer choose ASEMSConfig > File Export > Open File Export Properties.
Step 2 Click the Alarm tab.
Step 3 Under Export Type, select continuous.
Step 4 Under Storage Path, check the directory path and filename where the exported data is to be stored.
Step 5 Check the permissions for the directory.
Step 6 Click the Performance tab.
Step 7 Under Export Type, select continuous.
Step 8 Under Storage Directory, check the directory path and filename where the exported data is to be stored.
Step 9 Check the permissions for the directory.
Step 1 From the Map viewer, choose ASEMSConfig > File Export > Open File Export Properties.
Step 2 Under the Inventory, Alarm, and Performance tabs, check the File Aging Action selected.
Step 3 Check the file size that initiates the action, and reduce it if necessary.
Step 4 Under Storage Path (under the Inventory and Alarm tabs) and Storage Directory (under the Performance tab), check the directory path and filename where the exported data will be stored.
Step 5 Check the permissions for the directory.
Step 1 To check that performancePolling-ON is selected for the device.
a. Choose ASMainEM > Start/Stop Performance Polling.
b. Select performancePolling-ON.
c. Click Save.
Step 2 To check the polling interval selected for MIBs.
a. Choose ASEMSConfig > PerfPollConfig > Open Global Performance Polling Configuration.
b. Click a tab: Chassis, Chassis..., DS0, DS1, DS1..., DS3, DSP, Ethernet Port, Modem, or Others.
c. Check the polling interval that is selected for the attributes under this tab.
The polling interval should be one of the following: fiveMin, fifteenMin, thirtyMin, sixtyMin, oneDay, or sevenDay. (If you select none, the MIBs in that group are not polled.)
Step 3 Wait for the duration of the selected performance polling interval (see Step 2 of this sequence).
The Performance Manager window is updated after this interval.
Step 4 Stop and restart performance polling.
a. Choose ASMainEM > Start/Stop Performance Polling.
b. Select performancePolling-OFF.
c. Click Save.
d. Select performancePolling-ON.
e. Click Save.
Step 5 From the left pane of the Performance Manager window, select a different object.
Step 6 From the left pane of the Performance Manager window, reselect the original object.
Step 7 Click Refresh.
If you reduce the polling interval, the previous (longer) polling interval is still in effect for this polling cycle. When this cycle is completed, the new shorter polling interval takes effect.
If the previous polling interval was set to a large value (example: sevenDay), this interval is already in effect, even though you reduce the polling interval. The new polling interval takes effect only after the previous interval is completed.
To start polling at the new interval before the previous polling interval is completed, follow these steps:
Step 1 To stop performance polling:
a. Choose ASMainEM > Start/Stop Performance Polling.
b. Select performancePolling-OFF.
c. Click Save.
Step 2 To change the performance polling interval:
a. Choose ASEMSConfig > PerfPollConfig > Open Global Performance Polling Configuration.
b. Click a tab: Chassis, Chassis..., DS0, DS1, DS1..., DS3, DSP, Ethernet Port, Modem, or Others.
c. Select a polling interval for the attributes under this tab.
d. Click Save (in the menu bar).
Step 3 To restart performance polling:
a. Choose ASMainEM > Start/Stop Performance Polling.
b. Select performancePolling-ON.
c. Click Save.
When you initiate polling on a device, an alarm is raised, and the Event Browser shows the device to be in status 4.
Step 1 Verify that the read-write (RW) and read-only (RO) community strings have been configured on the device by using SNMP IOS commands.
Step 2 Check if the device has been configured for FTP data transfer.
Step 3 If yes, Telnet to the Cisco UGM server by using the configured FTP username and password combination.
This eliminates the possibility that local administrative settings prevented the proper creation of the username or password on the host.
Step 4 Start the Cisco EMF log.
This section contains the following error descriptions and their recovery procedures:
The Action Report indicates a ping failure which means 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, follow these steps:
Step 1 Retry the Configure Administrative State action twice. (Refer to the Cisco Universal Gateway Manager User Guide.)
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. Choose Open Device Authentication Information 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 way 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 Action 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 device 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 device 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
Cisco IOS configuration problem or a switch (signaling) problem.
This section contains the following error descriptions and their recovery procedures:
Make sure you set the Login and Enable Password correctly in the Device Authentication Information dialog box.
Refer to the Cisco Universal Gateway Manager User Guide.
Step 1 Check that the device is in the normal (commissioned) state.
Step 2 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: Wed Dec 4 14:30:19 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.