Why am I not getting any SNMP traps from the Cisco Unified Communication Manager node for the CISCO-CCM-MIB?
For receiving SNMP traps in CISCO-CCM-MIB, you need to ensure that the value of the following MIB OIDs is set to appropriate
values: ccmPhoneFailedAlarmInterval (188.8.131.52.184.108.40.206.220.127.116.11) and ccmPhoneStatusUpdateAlarmInterv (18.104.22.168.22.214.171.124.126.96.36.199)
are set between 30 and 3600. The default specifies zero (0).
Execute the following commands from any Linux machine:
The Following Issues Relate to Registration, Deregistration, and Failure of Phones
Configuring notification destinations—You need to ensure that notification destinations are configured. You can do this from
the Cisco Unified Serviceability Web window. A menu for exist.
Before you configure notification destination, verify that the required SNMP services are activated and running (SNMP Master
Agent and Cisco UCM SNMP Services). Also, make sure that you configured the privileges for the community string/user correctly,
they should contain Notify permissions as well.
If traps still are not generated, check whether corresponding alarms are generated. Because these traps get generated based
on the alarm events, ensure that SNMP agents are getting these alarm events. Enable Local Syslog. Set up the Cisco UCM Alarm
configuration to the informational level for Local Syslog destination from the Alarm configuration that is available on Cisco
UCM Serviceability window
. Reproduce the traps and see whether corresponding alarms are logged into the CiscoSyslog file.
Receiving syslog messages as traps—To receive syslog messages above a particular severity as traps, set the following 2 MIB
objects in the clogBasic table:
clogNotificationsEnabled (188.8.131.52.184.108.40.206.220.127.116.11)—Set this to true (1) to enable syslog trap notification. Default value specifies false (2). For example, snmpset -c <Community String> -v 2c <transmitter ip address> 18.104.22.168.22.214.171.124.126.96.36.199.0 i <value>.
clogMaxSeverity (188.8.131.52.184.108.40.206.220.127.116.11)—Set the severity level above which traps are desired. Default value specifies warning (5). All syslog messages with alarm severity lesser than or equal to configured severity level get sent as traps if notification
is enabled. For example, snmpset -c <Community String> -v 2c <transmitter ip address> 18.104.22.168.22.214.171.124.126.96.36.199.0 i <value>
What are the different traps that are defined for Cisco Unified Communication Manager?
The CISCO-CCM-MIB contains the following list of defined traps:
ccmCallManagerFailed—Indication that the Cisco UCM process detects a failure in one of its critical subsystems. It can also
get detected from a heartbeat/event monitoring process.
ccmPhoneFailed—Notification that the intervals that are specified in ccmPhoneFailedAlarmInterval indicate at least one entry
in the ccmPhoneFailedTable.
ccmPhoneStatusUpdate—Notification that gets generated at the intervals specified in ccmPhoneStatusUpdateInterv if there one
entry in the ccmPhoneStatusUpdateTable exists.
ccmGatewayFailed—Indication that at least one gateway attempted to register or communicate with the Cisco UCM and failed.
ccmMediaResourceListExhausted—Indication that Cisco UCM has run out of a specified type of resource.
ccmRouteListExhausted—Indication that the Cisco UCM could not find an available route in the indicated route list.
ccmGatewayLayer2Change—Indication that the D-Channel/Layer 2 of a registered interface in a skinny gateway changes state.
ccmMaliciousCall—Indication that a user registers a call as malicious with the local Cisco UCM server.
ccmQualityReport—Indication that a user reports a quality problem using the Quality Report Tool.
ccmTLSConnectionFailure—Indication that the Unified Communications Manager failed to open TLS connection for the indicated device.
The mapping of the traps to alarms follows:
How can different SNMP traps from Cisco Unified Communication Manager be checked?
Use the following procedure for triggering few traps:
If the Cisco UCM Agent consumes high CPU continuously, what needs to be done?
Collect logs for analysis and refer to defect CSCsm74316. Verify whether the defect fix was added to your Cisco UCM release.
If the CTI Routepoint is deleted from Unified Communications Manager Administration, an entry exists for that in ccmCTIDeviceTable mib. Why?
A service parameter that is called "RIS Unused Cisco CallManager Device Store Period" defines how long unregistered devices remain in RIS database and in the MIB. The Cisco UCM Administration window and the
SNMP MIB may not be in sync because the Cisco UCM Administration window shows information from the database and SNMP uses
the RIS database.
When ccmPhoneType is queried from ccmPhoneTable in Cisco-CCM-MIB, no information is returned. Why?
This means that the ccmPhoneType has been obsoleted. You can retrieve the same information from ccmPhoneProductTypeIndex against
CcmProductTypeEntry. In the table, the indexes correspond to the index and name as listed in that table.
The following list gives some of other obsolete and alternate OIDs to be referred:
Because ccmGatewayType is obsolete, you need to refer to ccmGateWayProductTypeIndex.
Because ccmMediaDeviceType is obsolete, you need to refer to ccmMediaDeviceProductTypeIndex.
Because ccmCTIDeviceType is obsolete, you need to refer to ccmCTIDeviceProductTypeIndex.
A query on ccmPhoneProductTypeIndex returns zero. Why?
Verify that the Unified Communications Manager release that you are using has this capability.
While a WALK is performed on ccmPhoneTable, ccmPhoneUserName is not returning any value. How are usernames associated to the
Create an end user and go to the phone that has been registered and associate the Owner User ID. After this is done, the OID
in the SNMP Walk will show the user.
How do I get the firmware versions of each phone by using SNMP?
ccmPhoneLoadID object in the ccmPhoneTable will give the firmware version of each phone. This value may differ if new image
download failed because SNMP exposes both configured firmware ID (ccmPhoneLoadID) and the actual running firmware (ccmPhoneActiveLoad).
CCM MIB returns ccmVersion as 5.0.1, which is incorrect.
Verify the Unified Communications Manager release that you are using has this capability. If it does not, upgrade.
CCM MIB returns incorrect ccmPhoneLoadID
ccmPhoneLoadID values get picked up from the RIS database, which gets populated based on the alarm that is received during
phone registration. Perform the following steps and collect the logs for further analysis:
In Cisco Unified Serviceability, choose . Choose the server; then, click Go. Choose CM Services for the Services Group; then, click Go. Choose Cisco CallManager for the service; then, click Go.
Check Enable Alarm for Local Syslog, SDI Trace, and SDL Trace. Choose Informational from each Alarm Event Level drop-down list box.
In the Trace Configuration window, set the Debug Trace Level for the Cisco UCM service to Detailed.
Reset the phones that are showing incorrect LoadID.
Collect the Syslog and Cisco UCM traces.
Collect the phone details.
How Cisco Call Manager status (START/STOP) monitored?
For service monitoring, you have following options:
A ccmCallManagerFailed trap exists for Cisco UCM service failures. But this does not cover normal service stop and unknown
Why does the device pool information seem incorrect for any device that was polled? The OID that was used is ccmPhoneDevicePoolIndex.
As stated in the CISCO-CCM-CAPABILITY MIB, ccmPhoneDevicePoolIndex does not get supported, so it returns zero (0). The Cisco
UCM device registration alarm currently does not contain the device pool information.