10-04-2011 08:29 AM
Hi,
looks like I still have an issue with LMS to recognize the IP Phones in UT as IP Phones.
SNMP RO on Call Manager is enabled and is green in CM (e.g. topology) - so SNMP get is basically fine.
The Phones are recognised as End Devices in UT.
As far as I understand, now if I start a Phone Aquisition, the CUCM is polled by LMS to gather additional information about the phones.
So it seems there is a problem with the SNMP polling of the Callmanager?
thanks for any help!
br.herwig
10-04-2011 10:42 AM
Not quite sure I understand...
Does the Call Manager show-up in the LMS DCR?
Thanks,
-Joe
10-05-2011 04:44 AM
Yes, its in DCR
below the device status of the Callmanager:
20. | 192.168.2.10 | Callmanager | 192.168.2.10 | 1.3.6.1.4.1.9.1.583 | Cisco 7825H Media Convergence Server |
The phones are collected by UT as end hosts (it is seen through the voice vlan called "UC"):
But this phones are not recognized as phones in UT:
thanks,
br.herwig
10-05-2011 09:44 AM
User Tracking phone discovery is via snmp by walking ccmPhoneTable which is only available if the appropriate service is enabled
Prerequisite - The device must show up in Campus Data Collection.
Use device center and walk the follwoing OIDs
.1.3.6.1.2.1.1.2 - if this failed it is a problem with SNMP Engine, either it is not enabled, has the wrong community or has a host based ACL applied.
.1.3.6.1.4.1.9.9.156.1.2.1 - this is the phone table, if this does not return details then you need to enable SNMP Service or restart it.
Serviceability -> Tools -> Control Center - Feature Services, under Performance Monitoring Services -> Cisco Call Managers SNMp Service
If the ccmPhoneTable walk is slow , then the problem might also be snmp timeout, you could try as a last resort increasing these values. Keep in mind it will take both Data Collection and User Tracking longer to finish depending on how much these settings are modified.
Admin > Collection Settings > Data Collection > Data Collection SNMP Timeouts and Retries
If this does not work , then you may need to open a TAC case.
10-05-2011 12:47 PM
Thanks Thomas, these are very good hints for troubleshooting this.
What I can tell now, both SNMP walks deliver values- timeout issue maybe exist, the phone table walk was quite slow...
Now I'll play around with timeouts (seems like it's possible to change collection timeouts for single hosts also, so I try to change this only for the CCM).
The following is a SNMP walk of device 192.168.2.10 starting from .1.3.6.1.2.1.1.2
SNMP Walk Output
--------------------------------------------------------------------------------
.1.3.6.1.2.1.1.2
RFC1213-MIB::sysObjectID.0 = OID: CISCO-PRODUCTS-MIB::ciscoMCS7825H
The following is a SNMP walk of device 192.168.2.10 starting from .1.3.6.1.4.1.9.9.156.1.2.1
SNMP Walk Output
--------------------------------------------------------------------------------
.1.3.6.1.4.1.9.9.156.1.2.1
CISCO-CCM-MIB::ccmPhonePhysicalAddress.1 = STRING: 4:c5:a4:b0:10:a8
CISCO-CCM-MIB::ccmPhonePhysicalAddress.2 = STRING: 1c:17:d3:40:ca:d8
[...]
br.h
10-05-2011 11:09 PM
the SNMP timeout changes did not solve my issue.
My last test was a timeout of 300sec. with a second retry - so 10 minutes finally....
So I will go on and open a TAC Case as mentioned.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide