Table Of Contents
Troubleshooting QPM
Obtaining System Status Information for Troubleshooting
Obtaining Additional Debug Information for Cisco Technical Support
Problems Starting QoS Policy Manager
Troubleshooting Problems Starting Common Services
Troubleshooting Problems Starting QPM
Troubleshooting User Interface Problems
Troubleshooting Policy Configuration Problems
Troubleshooting Device Management Problems
Troubleshooting Deployment Problems
Troubleshooting QoS Analysis Problems
Disk Space Shortage Problems
Monitoring Error Messages
Troubleshooting Display Problems
Troubleshooting the IP Telephony Network
Troubleshooting Database Backup Problems
Troubleshooting QPM
The following topics can help you troubleshoot problems you might encounter when using QPM:
•
Obtaining System Status Information for Troubleshooting
•Obtaining Additional Debug Information for Cisco Technical Support
•Problems Starting QoS Policy Manager
•Troubleshooting User Interface Problems
•Troubleshooting Policy Configuration Problems
•Troubleshooting Device Management Problems
•Troubleshooting Deployment Problems
•Troubleshooting QoS Analysis Problems
•Troubleshooting the IP Telephony Network
•Troubleshooting Database Backup Problems
Obtaining System Status Information for Troubleshooting
If unusual exceptions occur or error windows are displayed while running QPM, you can obtain system status information by running the QPM Diagnostic Tool on the QPM server. This tool generates a report in a browser window of the system status with its diagnostics, and suggests possible solutions where applicable.
You can access the Diagnostic Tool only from the QPM server.
Note In general, if you come across troubleshooting problems that do not have an obvious solution, you should try logging out of QPM and CiscoWorks, and restarting the QPM server. If the problem persists, run the QPM Diagnostic Tool on the QPM server to create the troubleshooting log file, and consult your system administrator.
If you want to send the diagnostics results to a TAC representative, you can run the MDCSupport.exe command-line utility, which collects configuration and system information in a zip file, called MDCSupportInformation.zip. This zip file includes any problems that occurred during the installation or the running of QPM. You can send this file to the Cisco Technical Assistance Center (TAC) support staff to assist in diagnosing the problems.
Procedure
Step 1 On the QPM server, select Start > Programs > Cisco Systems > QoS Policy Manager > Diagnostic Tool.
A report is generated and displayed in a browser window for you to view.
Step 2 To send the diagnostics results to a TAC representative:
a. At the command line, enter MDCSupport.exe and press Enter.
A zip file named MDCSupportInformation.zip is created in installation-directory\CSCOpx\MDC\etc, where installation-directory is the directory in which you installed the program, typically c:\Program Files.
b. Send this file to the TAC representative by email.
Related Topics
•Obtaining Additional Debug Information for Cisco Technical Support
Obtaining Additional Debug Information for Cisco Technical Support
If Cisco Technical Support requests that you gather additional debug information in the trace files, you can set the QPM trace logging mode to collect the information. Because collecting debug information will reduce the performance of your server, and the collected data can only be interpreted by Cisco, do not collect debug information unless requested. After you have collected the information, reset the logging mode to only collect informational messages.
Procedure
Step 1 From the QPM-install-directory\CSCOpx\MDC\qpm\bin directory (where QPM-install-directory is the directory in which you installed QPM), enter this command to begin collecting debug information:
setqpmloggermode -debug
Step 2 Repeat the activities you were doing in QPM that led to the problems you encountered.
Step 3 When sufficient debug information has been collected, send these files to your Cisco Technical Support representative (paths are relative to the QPM installation directory):
•CSCOpx\MDC\log\collector_last_run.trace
•CSCOpx\MDC\log\jboss_last_run.trace
•CSCOpx\MDC\log\tomcat_last_run.trace
•CSCOpx\MDC\log\pdp_last_run.trace
Step 4 Reset the logging mode so that only informational messages are collected (the default behavior):
setqpmloggermode -info
Related Topics
•Obtaining System Status Information for Troubleshooting
Problems Starting QoS Policy Manager
The following topics describe causes and solutions for problems you might encounter when trying to start QoS Policy Manager:
•Troubleshooting Problems Starting Common Services
•Troubleshooting Problems Starting QPM
Troubleshooting Problems Starting Common Services
Common Services might not start for any of the following reasons:
•Port Conflict
Port Conflict
Problem You cannot start Common Services because port 1741, which is used by Common Services, is in use by another application.
Solution Try the following:
•Restart the QPM server.
•To run CiscoWorks, enter http://<QPMinstall>:1741/login.html, where <QPMinstall> is the name or IP address of the QPM server.
If ports are still in use, open the JbossStdout.log file and look for the error "java.rmi.server.ExportException:Port already in use:<port-number>". Check whether the listed port is in use by another application. If so, stop the other application or change the port it is using.
Troubleshooting Problems Starting QPM
QPM might not start for any of the following reasons:
•QPM Server Does Not Meet System Requirements
•Changed Database Password
•Old Version of Java Plug-In
•Different HTTPS Port in Common Services and QPM
•Unknown Cause
QPM Server Does Not Meet System Requirements
Problem QPM startup and performance might be slow, or QPM might not work at all.
Solution Install QPM on a server that meets system requirements.
Changed Database Password
Problem If you changed the QPM database password, and then try to start QPM without restarting the QPM server or Daemon Manager, the connection to the database is lost.
Solution After changing the QPM database password, restart the QPM server.
Old Version of Java Plug-In
Problem QPM might not start if there is a older version of the Java plug-in than the one required by QPM.
Solution Uninstall the old Java plug-in. When you start CiscoWorks it automatically installs the Java plug-in.
Different HTTPS Port in Common Services and QPM
Problem If the HTTPS port number used by CiscoWorks Common Services is different from the HTTPS port number configured in QPM, you will not be able to launch QPM.
Solution Update QPM with the Common Services port number, using the updateSSLPort utility. This utility updates QPM with the new port and restarts the services.
To start the utility from the QPM server, in the Command window:
•Change directory to the CSCOpx\MDC\qpm\bin folder in the QPM installation folder.
•Enter updateSSLPort <new port number>
Unknown Cause
Problem QPM does not start due to an unknown cause.
Solution Restart the QPM server.
Troubleshooting User Interface Problems
These topics describe causes and solutions for your user interface problems:
•Options for QoS features do not appear in the user interface
Many buttons in the user interface are grayed out
Problem You might not have the correct user permissions to perform the tasks associated with the grayed out buttons.
Solution Verify your user permissions in the CiscoWorks desktop (Server Configuration > Setup > Security), or in ACS (depending on the method you are using for user authentication). For more information about user permissions, and working with ACS user permissions, see the Installation Guide for QoS Policy Manager.
Troubleshooting Policy Configuration Problems
These topics describe causes and solutions for your policy configuration problems:
•Options for QoS features do not appear in the user interface
•You remove a network element from a policy group, but the policies are not removed from the network element
Options for QoS features do not appear in the user interface
Problem You cannot see options for QoS features that are not valid for the defined device constraints.
Solution When you define policy groups and policies, QPM presents you with only those QoS properties and policy options that are valid for the defined device constraints. Verify that you have chosen the correct network element and defined the device constraints correctly. For information about the devices and software releases that QPM supports, and the QoS features you can configure on the supported platforms, see the device support tables at the following URL:
http://www.cisco.com/en/US/products/sw/cscowork/ps2064/products_device_support_tables_list.html
You remove a network element from a policy group, but the policies are not removed from the network element
Problem You remove a network element from a policy group, then redeploy the policy group. However, the policy group's policies are not removed from the deleted network element.
Solution QPM does not remove QoS configurations from network elements when the network element is removed from a policy group. If you want to remove the QoS configuration on a network element, you must create a policy group that does not have any QoS configuration defined (an "empty" policy group), assign the network element to the empty policy group, and deploy the empty policy group.
Troubleshooting Device Management Problems
The following sections help you troubleshoot problems with QPM device management:
•QPM cannot log into a device
•A device is not added to the expected device group when imported into QPM
•A device has a status that indicates an error
•QPM does not detect the correct card type
QPM cannot log into a device
Problem QPM can connect to a device, but cannot log into it for any of the following reasons:
•The device access parameters in the QPM inventory do not match those configured on the device.
•The standard device prompts have been customized.
Solution Verify that the device access parameters in the QPM inventory match those configured on the device. If the device access parameters are correct but QPM still cannot log into the device, enable the blind login option, which causes QPM to send login information to the device (including access parameters) without waiting for or evaluating return prompts from the device. For instructions for enabling blind login, see Viewing and Editing Device Properties, page 4-110. You can also configure blind login as the default for all devices in a device group; see Editing Device Group Properties, page 4-133.
Determine whether the device prompts have been customized using the prompt (Cisco IOS software) or set prompt (Catalyst OS) commands.
•Cisco IOS software devices—These are the standard prompts for Cisco IOS software devices:
•Catalyst OS devices—These are the standard prompts for Catalyst OS devices:
For example, if the prompt was changed to "my_prompt" using the CLI command set prompt, the following prompts will appear when you log into the device:
If the device prompts have been customized, you must configure QPM to recognize the customized device prompts, and enable blind login for the device.
Use a text editor such as WordPad or Notepad to add command lines to the qpm.cfg file in the mdc\shared\config folder in the Common Services installation folder on the QPM server. Enter this line for each device whose prompt is customized:
devicename.login_prompt=custom_prompt
where devicename is the IP address or host name of the device, and custom_prompt is the customized prompt. For example, if the customized prompt for device 10.10.2.4 is "my_prompt," enter this line in qpm.cfg:
10.10.2.4.login_prompt=my_prompt
Note•If all devices have the same prompt, you can use an asterisk (*) instead of a specific device name, to denote all devices.
•You can use any characters for the prompt, but it cannot end in $, ^, or \.
After you update qpm.cfg, you must restart the QPM server before the changes take effect.
A device is not added to the expected device group when imported into QPM
Problem The device might be defined in ACS as an AAA server and an AAA client, which is supported in ACS but not in QPM. In this case, the device is added to only the QPM AAA client device group in QPM.
Solution Remove the device from the ACS AAA server device group.
A device has a status that indicates an error
The device statuses described in Table 11-1 indicate that the device is in an error state. You cannot deploy to devices with these statuses.
Table 11-1 Device Status Errors
Device Status
|
Description
|
Explanation
|
Unreachable
|
The QPM server cannot establish basic network connectivity to the device.
|
Establish basic network connectivity to the device.
|
SNMP Error
|
The device has an SNMP error that is preventing QPM from gathering the data it needs to work with the device.
|
These are the common causes:
•The device public community string entered in QPM is incorrect. Correct the community string in QPM.
•QPM can't read all of the necessary SNMP information from the device, possibly because there are corrupted or missing MIBs.
•The device does not have a functioning SNMP engine.
•The SNMP request timed out, typically because the device or network was too congested to respond before the timeout limit. The possible resolutions are to retry the SNMP connection, or increase the SNMP timeout value.
|
Telnet Error
|
QPM cannot connect to the device using Telnet.
|
These are the common causes:
•The device Telnet password entered in QPM is incorrect. Correct the Telnet password in QPM.
•SSH is enabled but SSH login failed because SSH is not configured correctly on the device. Fix the SSH configuration on the device.
•The login to the device failed.
•There is no Telnet connection to the device.
|
QPM does not detect the correct card type
Problem In rare cases, QPM does not recognize the type of card on which an interface resides. Because the card type influences what types of QoS can be configured on an interface, an incorrect card type can prevent you from deploying the desired QoS configuration to the interface.
Solution If you cannot get QPM to correctly recognize the card type for an interface, update the qpm.local.cfg file on the QPM server with the following line, then restart all QPM services:
This line will turn the Card Type display field on the Interface Properties page into a list box (see Interface Properties Page, page A-350). You can then select the correct card type for the interface. Make sure you do not select an incorrect card type, or QPM will probably generate errors if you try to deploy policies to the interface.
Troubleshooting Deployment Problems
Policies can only be deployed to devices if QPM can correctly contact and connect to the device. QPM can usually provide a specific error message that clearly indicates the problem. However, sometimes providing a clear error message is not possible.
If QPM cannot configure a device, and the error is not clear in the device log for the device, this might be due to any of the following reasons:
•Incorrect software version or device type
•Deployment fails because QPM could not connect to a device
•Configuration messages from the device indicate that distributed Cisco Express Forwarding (dCEF) is not configured on VIP cards
•Configuration messages from the device indicate that Cisco Express Forwarding (CEF) is not configured on the device
•Deployment fails on virtual interface because "CB QoS not supported on device" when the device supports Class Based QoS
•Queuing policies that were defined for ATM PVC interfaces in QPM are not deployed or monitored
Incorrect software version or device type
Problem QPM does not support an imported device's Cisco IOS version. The device is assigned the status "Unsupported", and no mapped OS version is assigned to it. You cannot perform any tasks on a device that has been assigned this status.
Solution If the device model is supported by QPM but the Cisco IOS version is not, you can upgrade the device to a supported Cisco IOS version, and then rediscover the device to make it available in QPM. Click Rediscover in the Device Table to have QPM query the device for the correct information.
Alternatively, if the Cisco IOS version is not supported, but you know that the IOS version's QoS features are the same as in a supported version, you can use the following workaround:
1. After you have added the device, in the Device Properties page, change the Mapped OS version to the supported OS version, and save the change.
2. Rediscover the device. The device status changes to OK.
Deployment fails because QPM could not connect to a device
There are several possible explanations for this problem:
•Problem—Unable to log into the device due to an incorrect access passwords.
Solution—Check in the Device Properties page that the correct Telnet, TACACS, and Enable passwords are defined. QPM does not display the passwords (to maintain security), so carefully retype the passwords.
•Problem—There is no connectivity between QPM and the device—the device status is "Unreachable."
Solution—Check the device to ensure that it is powered on and that it is connected to the network. Log into the server and telnet to the device to see if you can connect to it (from the Device Properties page).
•Problem—There might be a problem with the login prompts returned by the device.
Solution—Enable the Blind Login check box in the Access Parameters area of the Device Properties page. This feature lets you bypass the login prompts (such as, user name and password) that wait for a response when the device returns a string. Then try to log in again.
In the system configuration file of the QPM installation directory (CSCOpx\MDC\share\config\qpm.cfg), you can configure blind login for all devices, by setting devcomm.blind_login=on. To use blind login for a specific device, set <hostname>.blind_login=On,where hostname is the IP address or host name of the device. This will override the global blind login setting. If required, you can also increase the login timeout delay parameter for the devices (devcomm/hostname.blind_login_timeout).
Configuration messages from the device indicate that distributed Cisco Express Forwarding (dCEF) is not configured on VIP cards
Problem Some types of QoS configurations require that dCEF is configured on VIP cards and QPM cannot detect this.
Solution Before distributing policies to VIP interfaces, configure dCEF on the device's VIP card interfaces through the device's commands.
Configuration messages from the device indicate that Cisco Express Forwarding (CEF) is not configured on the device
Problem Some QoS features, such as DWFQ and NBAR, require CEF to be configured on the devices (not on the VIP cards) and QPM cannot detect this.
Solution Before distributing policies to devices, configure CEF on the device through the device's commands.
Deployment fails on virtual interface because "CB QoS not supported on device" when the device supports Class Based QoS
Problem Deployment of policies to a virtual interface (such as subinterfaces or tunnel interfaces) fails with the indication that Class Based QoS is not supported on the device, whereas you know that this specific device does support this type of QoS.
Solution In general, on virtual interfaces, if you want to configure class based queuing, you must configure modular shaping. If you have not configured modular shaping with class based queuing on a virtual interface, deployment might fail with the above message. Check that you have configured the virtual interface correctly.
Queuing policies that were defined for ATM PVC interfaces in QPM are not deployed or monitored
Problem Queuing policies are defined for ATM PVC interfaces in QPM, but cannot be seen on the "Show run", and cannot be monitored. The queuing policy has not been deployed to the ATM PVC, and hence cannot be monitored.
With the newer IOS and port-adapters, the service-policy command can only be deployed to the PVC if the vbr-nrt command is configured on the PVC. "vbr-nrt" is an ATM hardware command, and is used for configuring QoS shaping. QPM does not automatically configure this command, and no error is displayed on deployment.
Solution Configure the vbr-nrt command manually on the ATM PVC before configuring QoS through QPM.
Related Topics
•Viewing and Editing Device Properties, page 4-110
•Connecting to a Device Using Telnet, page 4-112
•Rediscovering Device Information, page 4-115
•Device Properties Page, page A-341
Troubleshooting QoS Analysis Problems
The following sections help you troubleshoot problems with QoS analysis:
•Disk Space Shortage Problems
•Monitoring Error Messages
•Troubleshooting Display Problems
•Queuing policies that were defined for ATM PVC interfaces in QPM are not deployed or monitored
Disk Space Shortage Problems
Cannot perform monitoring; a Disk Space Shortage message appears
Problem You do not have enough disk space on the QPM server because you have already performed monitoring tasks, and the database is full.
Solution See Freeing Disk Space for QoS Analysis, page 9-286 for information on freeing disk space for monitoring tasks.
Occasionally, you might not have enough space in the QPM database for monitoring because the percentage of free disk space defined during installation is too high.
Your system administrator can change the percentage of free disk space defined in the installation procedure:
1. On the QPM server, locate the qpm.cfg file under mdc\qpm\config in the Common Services installation folder.
2. Open qpm.cfg in WordPad or other text editor.
3. In the command line, database.trigger.percentage=0, change the 0 to the percentage of free disk space required. You can enter a percentage value from 1 to 99.
4. Save and close the file.
5. Reboot the QPM server. A new file, qpm.local.cfg, has been created.
6. Open qpm.local.cfg.
The original command line, database.trigger.percentage=0, reappears, and a new command line appears, database.trigger.percentage.actual=<%>, where % is the percentage you defined. If you need to change the percentage again, make the change in this file.
Monitoring Error Messages
The following sections describe monitoring error messages and their fixes or workarounds:
•Monitoring system error
•Collection service error
•Cannot run task
•The task does not contain a device from the current device group
Error Message Monitoring system error
Explanation This error message indicates that an unspecified error occurred
when attempting to run a report.
Recommended Action Restarting the QPM server might resolve the problem.
Error Message Collection service error
Explanation This error message indicates that there was a collection service
error when trying to run a real-time report or complete the definition of a
historical analysis task. The error message contains additional explanation of
the error. Each variation of the error is described in Table 11-2.
Table 11-2 Collection Service Error Troubleshooting
Error Variation
|
Description
|
Fix or Workaround
|
Connection to collector refused
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
Failed to load task to the collector
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
Failed to get settings from the collector
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
Failed to get data from the collector
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
SNMP request timeout
|
SNMP requests sent to the device timed out.
|
Try the following fixes in this order:
1. Verify basic device connectivity using ping or Telnet.
2. Verify that the device access parameters stored in QPM inventory agree with those configured on the device.
3. Check device CPU load. If it's abnormally high, SNMP requests might not get processed. Lower the CPU load to restore monitoring.
|
The device: <IP address> is not configured with the policy: "<Policy>" on interface with MIB index y
|
The device does not contain the policy or MIB index that QPM needs to monitor a policy.
This happens when the device is changed in certain ways after the monitoring task was created.
|
These are possible causes of this error. To resolve the error, fix the applicable problem, then either rerun the real-time analysis report, or redefine the historical analysis task.
•The interface is shut down. Enable the interface.
•There was an undetected deployment error. Redeploying the policies to the device might resolve the problem.
•You deployed policies to a file rather than to the network. QPM cannot detect that policies are deployed to a file, so it updates monitoring tasks that are affected by a policy deployment, even if the changes were not deployed to the actual device. There is no workaround.
•You changed the device hardware configuration or created subinterfaces on the device, but did not rediscover the device. Rediscover the device.
•You selected a CAR policy with the Mark and Transmit option configured. QPM cannot monitor this QoS configuration. Remove the CAR policy with the Mark and Transmit option from the monitoring task definition.
|
Error Message Cannot run task
Explanation The device is not responding because the QPM SNMP timeout
was changed to larger than two minutes. It is recommended that you use the
default QPM SNMP timeout value.
Recommended Action Try the following fixes in this order:
a. Verify basic device connectivity using ping or Telnet.
b. Verify that the device access parameters stored in QPM inventory agree with those configured on the device.
c. Check device CPU load. If it's abnormally high, SNMP requests might not get processed. Lower the CPU load to restore monitoring.
Error Message The task does not contain a device from the current
device group
Explanation The analysis report cannot run because none of the devices that
it is assigned to monitor are still in the current device group. The likely cause
is that the devices were removed from the current device group. This error
will also occur if you move a device that is being monitored from the Default
device group to another device group.
If any of the devices assigned to the monitoring task are still in the current device group, you can run the report, which will contain data only for the devices that are still in the current device group.
Recommended Action To fix this, add at least one of the devices that are
assigned to the monitoring task back into the current device group.
Troubleshooting Display Problems
The following sections describe display problems and their fixes or workarounds:
•Graphs Appear in Analysis Report, but They Are Empty
•Graphs Do Not Appear in Analysis Reports
•Subinterface Graphs Display Incorrect Bandwidth Percentages
Graphs Appear in Analysis Report, but They Are Empty
Problem You can view an historical analysis report, but the graphs do not show any information.
Solution You will not see data on the historical graphs immediately after the task starts. Depending on when you start the task, the length of the polling interval, and how many other tasks are being run concurrently, it can take several hours to see graphed data, due to how QPM collects the data and writes it to the QPM database. To see any data in the graphs, your task must include at least three polling periods. For example, if you use a polling period of 30 minutes, and run the task for only one hour, you will not see any graphed data for the task. Even if you define a task whose duration is three times the polling interval, QPM might not have collected data three times during the task. Ensure that you create analysis tasks that will collect data a sufficient number of times to create a meaningful graph for your purposes (for example, at least 10 or more times).
Graphs Do Not Appear in Analysis Reports
Problem The browser's missing graphic icon appears where graphs should appear in analysis reports. The likely cause is that the Common Services session has expired.
Solution Log out of QPM and log back into Common Services using the Login dialog box in the desktop.
Subinterface Graphs Display Incorrect Bandwidth Percentages
Problem When a subinterface is displayed in monitoring graphs with the units of display set to percentage, the graph will display incorrect values for the subinterface in the following cases:
•The subinterface has CIR or Minimum CIR configured on it and the value assigned to these Qos features is different than the actual rate configured on the parent interface of the subinterface.
•The bandwidth of the parent interface was changed on the device but the device was not rediscovered by QPM.
Solution To fix this, rediscover the device. See Rediscovering Device Information, page 4-115.
Troubleshooting the IP Telephony Network
The following topics help you troubleshoot problems with the IP telephony network:
•Deployment fails because interface does not support "mls qos vlan-based" command
•Shaping interval is 0 milliseconds. Intervals below 4 milliseconds rejected
•Deployment fails for a serial PPP interface
•Selected interfaces were not assigned
•Voice policy group templates are missing or are from a previous templates version set
Deployment fails because interface does not support "mls qos vlan-based" command
Problem This occurs while trying to configure VLAN-based QoS on a Catalyst 6000 device running IOS. The reason it occurs is because you must first configure the switchport command on the interface to configure the VLAN-based QoS command.
Solution Configure the switchport command (switchport<cr>) manually on the interface before configuring VLAN-based QoS (mls qos vlan-based).
Shaping interval is 0 milliseconds. Intervals below 4 milliseconds rejected
Problem This message displays while trying to deploy policies to a Frame Relay interface on a VIP card. The reason it occurs is because Modular shaping on VIP cards requires the BC/CIR interval to be in units of 4 milliseconds.
Solution Adjust the shaping parameters according to the link speed. If you have several rates, you can create a group for each rate. Note that the IP Telephony wizard will assign the interfaces to only one of the groups, and you will have to move the others manually.
Deployment fails for a serial PPP interface
Problem After assigning a serial Point-to-Point interface with a rate equal to or less than 768kbs, this error occurs on deployment. The reason it occurs is that serial Point-to-Point cannot support LFI, which is applied on interfaces with link speeds below 768kbs.
Solution Select a multilink interface instead of a serial one. The following provides an example of a Multilink configuration:
•interface Multilink20
– bandwidth 256
– ppp multilink
– multilink-group 20
•interface Serial5/2
– bandwidth 256
– encapsulation ppp
– multilink-group 20
Selected interfaces were not assigned
Problem After selecting an interface in a configuration step of the IP Telephony wizard, it was not assigned to any voice policy group. It appears in the "Selected but not assigned" counter. The reason could be that the interface has no policies for the current voice role.
Solution There is no recommended action since this is expected behavior for an interface with no policies for the current voice role. See Assignment Summary, page 5-144 for more details about interface assignments.
Voice policy group templates are missing or are from a previous templates version set
Problem This occurs if you deleted templates from the QPM template library, or if you imported a QPM database from QPM 3.0.x.
Solution When you run the IP Telephony wizard, any required voice policy group templates that are missing are generated. If you have voice templates from a previous templates version set, you should disconnect any attached policy groups and delete the templates before you run the IP Telephony wizard.
If you need to regenerate the entire set of voice policy group templates, do the following:
1. Delete all the system voice policy group templates in the templates library (or delete only the ones you want to replace). Verify that all attached policy groups have been disconnected before deleting the templates. See Disconnecting Policy Groups from Policy Group Templates, page 6-214 and Deleting Policy Group Templates, page 6-215.
2. Open the qpm.local.cfg file in the CSCOpx\MDC\qpm\config folder.
3. Change the line:
com.cisco.nm.qpm.server.framework.services.QpmVoiceService.created
Templates=true
to:
com.cisco.nm.qpm.server.framework.services.QpmVoiceService.created
Templates=false
4. Restart the QPM server. The latest voice policy group templates will be in the templates library.
Troubleshooting Database Backup Problems
This topic describes causes and solutions for problems you might encounter when trying to backup the QPM database:
•Scheduled Incremental Backup Fails
Scheduled Incremental Backup Fails
Problem If the time or date was changed on the QPM server, and the server was not restarted, the scheduled incremental backups following the time/date change fail.
Solution Restart the QPM server.
