|
|
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.)
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 2 Change to the bin directory of Cisco EMF:
Step 3 Enter the following command to run the backup script:
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 2 Change to the following directory:
Step 3 Enter the following command to stop Cisco EMF:
Step 4 Enter the following command:
Step 5 Enter the date that the backup was created:
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:
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 2 Change to the following directory:
Step 3 Enter the following command to stop Cisco EMF:
Step 4 Enter the following command:
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 2 Select On or Off for these logging levels:
When Cisco UGM is installed, this is Off.
When Cisco UGM is installed, this is Off.
When Cisco UGM is installed, this is On.
When Cisco UGM is installed, this is On.
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 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 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 troubleshooting information, see "Upgrading Cisco Universal Gateway Manager."
The Cisco UGM upgrade process is described in "Upgrading Cisco Universal Gateway Manager."
Step 2 With Cisco UGM 2.0 installed, run these scripts:
This error occurs when you run the installUpgradeQuery or ASUpgradeQuery scripts.
To clear these errors, follow this procedure.
Step 2 Check that the specified directory and file exist.
Step 3 Rerun the script where this error occurred.
These errors occur when you run the installUpgradeQuery script.
To clear these errors, follow this procedure.
Step 2 Check that the destination file exists.
Step 3 Run the installUpgradeQuery script. (See the "Task 3: Installing the Data Query Utility" section.)
This error occurs when you run the ASUpgradeParser script.
In order to clear this error, follow these steps.
Step 2 Check that the configuration file exists.
Step 3 If the configuration file does not exist, rerun the installUpgradeQuery script (see the "Task 3: Installing the Data Query Utility" section).
Step 4 Run the ASUpgradeParser script (see the "Task 4: Creating an Object for the Standalone Process" section).
This error occurs when you run the ASUpgradeQuery or runASDataMigration script.
To clear this error, follow these steps.
Step 2 Rerun the script.
This error occurs when you run the ASUpgradeQuery script.
To clear these errors, follow these steps.
Step 2 Check the available disk space (see the "Freeing Up Disk Space" section).
This error occurs when you run the ASUpgradeQuery script.
To clear these errors, complete these steps.
a. Check the integrity of the database.
b. If necessary, restore the database from the last backup. (See the "Restoring Your Database Manually" section and the "Restoring Your Database Interactively" section.)
Step 2 If the procedure does not abort, continue with the upgrade, which completes successfully without this specific attribute value.
This error occurs when you run the ASUpgradeQuery script.
The standalone ASUpgradeQuery process could not be initialized. Contact Cisco TAC.
This error occurs when you run the ASUpgradeQuery script.
To clear these errors, follow these steps.
Step 2 Check the available disk space (see the "Freeing Up Disk Space" section).
Step 3 Run the ASUpgradeQuery script (see the "Task 5: Running the ASUpgradeQuery Utility" section).
This error occurs when you run the ASUpgradeQuery script.
To clear these errors, follow these steps.
Step 2 Run the ASUpgradeQuery script (see the "Task 5: Running the ASUpgradeQuery Utility" section).
Step 3 When prompted, enter the name of the directory.
This error occurs when you run the ASUpgradeQuery script.
To clear these errors, follow these steps.
Step 2 Run the ASUpgradeQuery script (see the "Task 5: Running the ASUpgradeQuery Utility" section).
Step 3 Enter the full path to the directory.
This error occurs when you run the runASUpgradeobjectSpecParser script.
In order to clear this error, follow these steps.
Step 2 Check that devices and sites deployed in Cisco UGM 1.0 are not displayed in Map Viewer.
Step 3 Run the runASUpgradeobjectSpecParser script on the server with Cisco UGM 2.0 installed.
The script runs without errors.
This error occurs when you run the runASUpgradeObjectSpecParser script during the procedure to upgrade Cisco UGM on different servers. (Server 1 runs Cisco UGM 1.0, and server 2 runs Cisco UGM 2.0; you must migrate data from Cisco UGM 1.0 to Cisco UGM 2.0.)
In order to clear this error, follow these steps.
Transfer data from the Cisco UGM 1.0 server to the Cisco UGM 2.0 server:
|
Note This Cisco UGM 2.0 directory must have the same name as the Cisco UGM 1.0 directory created in the "Task 4: Creating a Working Directory in Cisco UGM 1.0" section. |
Step 2 Copy the contents of the directory on the Cisco UGM 1.0 server to the directory (of the same name) on the Cisco UGM 2.0 server.
Step 3 Create a directory on the Cisco UGM 2.0 server to hold the IOS, SPE, and modem image files and configuration files from the Cisco UGM 1.0 directory created in the "Task 4: Creating a Working Directory in Cisco UGM 1.0" section.
|
Note This Cisco UGM 2.0 directory must have the same name as the Cisco UGM 1.0 directory created in the "Task 4: Creating a Working Directory in Cisco UGM 1.0" section. |
Step 4 Copy or transfer the contents of the directory on the Cisco UGM 1.0 server to the directory (of the same name) on the Cisco UGM 2.0 server.
Step 5 From the server where Cisco UGM 2.0 is installed, run the runASUpgradeObjectSpecParser script.
The script runs without errors.
This error occurs when you run either the runASDataMigrationParser or runASDataMigration script.
In order to clear this error, follow these steps.
Step 2 Check that the specified file exists.
Step 3 Rerun the runASDataMigrationParser or runASDataMigration scripts.
Step 4 Enter the full path to the data migration file.
This error occurs when you run either the runASDataMigrationParser or the runASDataMigration script.
In order to clear this error, follow these steps.
Step 2 If the file is empty, rerun the runASUpgradeQuery script (see the "Task 5: Running the ASUpgradeQuery Utility" section).
Step 3 Rerun the data migration scripts. (See the "Upgrading and Migrating Data to Cisco UGM 2.0" section.)
This error occurs when you run either the runASDataMigrationParser or the runASDataMigration script.
In order to clear this error, follow these steps.
Step 2 If necessary, restore the database from a previous backup (see the "Restoring Your Database Manually" section and "Restoring Your Database Interactively" section.)
Step 3 Uninstall Cisco UGM 2.0 (see the "Overview of Uninstalling Cisco UGM" section).
Step 4 Reinstall Cisco UGM 2.0 (see the "Overview of Cisco UGM Installation" section).
Step 5 Rerun the data migration scripts. (See the "Upgrading and Migrating Data to Cisco UGM 2.0" section.)
Step 6 Contact Cisco TAC.
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 2 Check if the Cisco UGM processes are up and running by entering this command:
The ASMainCtrl, IOSConfigCtrl, and ASFaultStandAlone processes should be running at this time.
In order to clear this error, follow these steps.
Step 2 Change to this directory:
Step 4 Reset the Cisco EMF database by entering these commands:
Step 5 Enter Y (yes).
Step 6 Enter this command to start Cisco EMF:
Step 7 Enter this command to start a Cisco EMF 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 2 Open the log file by entering the following command:
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 2 To change to this directory, enter:
Step 3 Enter this command:
Step 4 Reset the Cisco EMF database with these commands:
Step 5 Enter Y (yes).
Step 6 Enter this command to start Cisco EMF:
Step 7 Enter this command to install Cisco UGM:
Step 8 Enter this command to start a Cisco EMF 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 2 To change to this directory, enter:
All the CEMF-related processes that are running appear.
Step 4 Enter this command:
|
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 2 Change to this directory:
Step 3 Enter this command:
Step 4 Reset the Cisco EMF database with these commands:
Step 5 Enter Y (yes).
Step 6 Enter this command to start Cisco EMF:
This message appears when a Cisco EMF application stops. In order to clear this error, follow these steps.
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:
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.
|
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 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 2 If this is an internal Cisco UGM problem:
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 2 To decommission and commission the device object:
a. Select AS5xxx object> Chassis > Chassis Commissioning.
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.
attrValueSnmpRetries= xx (default value is 4)
attrValueSnmpTimeout= yy (default value is 500 ms)
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 2 Check if the devices are receiving power and operational.
Step 3 Delete the errored devices and run discovery again.
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 2 If the Event Browser shows a sysOID mismatch:
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 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:
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.
|
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:
|
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 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 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 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 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 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.
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.
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.
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:
Step 3 Repeat the command:
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 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 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.
Cisco UGM returns a report containing this line:
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 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 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 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 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.
See the "Changing Polling Period Intervals" section.
See the "Stopping Performance Polling on Devices" section.
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 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 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.
After upgrading to Cisco UGM 2.0, you may notice that the performance polling configuration dialog contains polling intervals set during Cisco UGM 1.0 operation.
Only common MIBs that are present in Cisco UGM 1.0 and Cisco UGM 2.0 performance polling configuration dialogs will be upgraded to the common polling interval.
Uncommon MIBs are set to their default polling intervals.
Step 2 From the command line, enter:
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.
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.
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 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 Path, check the directory path and filename where the exported data is to be stored.
Step 9 Check the permissions for the directory.
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, check the directory path and filename where the exported data will be stored.
Step 5 Check the permissions for the directory.
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.
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 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.
Step 3 To restart performance polling:
When you initiate polling on a device, an alarm is raised, and the Event Browser shows the device to be in status 4.
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 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.
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 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.
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.
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
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 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: Fri Apr 4 23:32:58 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.