cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1081
Views
0
Helpful
20
Replies

Long Device Discovery in LMS 3.0.1

sfenderson
Level 1
Level 1

I recently installed the Dec 2007 update to my Windows 2003 based LMS 3.0 system which upgrades it to LMS 3.0.1. Device Discovery was changed in this update and is now part of CS instead of CM. Since this upgrade my device discovery times have gone from about 15 minutes to 7 hours. I am using the discovery method created by the Dec 2007 update which just migrates the settings from CM to CS so the module being used is CDP. My existing seed devices and IP address range filter was migrated correctly. I performed a sniffer trace and found all the extra time is apparently due to discovery treating Cisco IP Phones as valid Cisco devices that should be discovered via SNMP. I see discovery try SNMP queries on each IP Phone and the phone responds with an ICMP port unreachable because IP phones don't run SNMP. Discovery ignores this and goes through the configured timeouts and retries that are configured before giving up and moving on to the next one only to suffer the same time wasting queries again. My SNMP timeout is 3 seconds with 2 retries. This adds up when you have 1500 IP phones. Is this a bug or is there some way to stop this? I never had this problem with LMS 3.0 or LMS 2.X.

20 Replies 20

Joe Clarke
Cisco Employee
Cisco Employee

Good catch. I'm looking into this. In the meantime, using filters can help avoid this problem.

I have IP Phones and some voice gateways in the same voice only subnets. So if I exclude the entire IP range I will miss the voice gateways. I thought about a DNS filter to filter out SEP* but I am already using an IP address filter and you can't use both. I have a TAC case open but I haven't heard much from them so I thought I would ask here. Thanks.

I will be filing a new bug on this. I'll post the bug ID when I have it.

I have filed CSCsm13114 to track this issue. I have written an untested patch as well to fix it. If you would like to try the patch, please have your TAC engineer contact me directly to get it.

Joe, I installed the 2 files you provided to TAC. Now when I try to configure the discovery settings I get an HTTP Status 500 error with a java.lang.NullPointerException. When I look at CSDiscovery.log I see this error:

[ Tue Jan 15 09:31:36 EST 2008 ] FATAL [DiscoverySettingsSummaryAction : perform] : Exception in reading CSDiscovery-config.xml.

Reason :unable to find FieldDescriptor for 'CDPID' in ClassDescriptor of SystemFilters

com.cisco.nm.csdiscovery.CSDiscoveryException: Exception in reading CSDiscovery-config.xml.

Reason :unable to find FieldDescriptor for 'CDPID' in ClassDescriptor of SystemFilters

I have a new patch ready. Please have your engineer contact me again.

Joe I received the new patch with 3 files from TAC. I applied these files, updated my discovery settings, and started a discovery. Something is still wrong. Once I started discovery the CS home page doesn't show discovery status as "running". However a job was submitted and is running. I let it run for several hours and it still had not finished so I cancelled it. I then enabled debug for CSdiscover and started it again. The CS home page still didn't show the correct discovery status. I let this run for about 15 minutes and then cancelled the job. I will attach the csdiscovery.log file. I looked at it and see lots of this message group:

[ Wed Jan 23 13:20:53 EST 2008 ] DEBUG [DiscoveryUtil : getNMSROOT] : NMSROOT: E:\PROGRA~1\CSCOpx

[ Wed Jan 23 13:20:53 EST 2008 ] DEBUG [DiscoveryJobUtil : processStatus] : [processStatus] Called!!

[ Wed Jan 23 13:20:53 EST 2008 ] DEBUG [DiscoveryJobUtil : processStatus] : Executing jobCmd: E:\PROGRA~1\CSCOpx\bin\pdshow.cmd CSDiscovery

[ Wed Jan 23 13:20:53 EST 2008 ] DEBUG [DiscoveryJobUtil : processStatus] : Job Command Response:

[ Wed Jan 23 13:20:53 EST 2008 ] DEBUG [DiscoveryJobUtil : processStatus] : Exit

These groups of messages are in the log about every 2 seconds.

I also sent this info to the TAC engineer I am working with.

Thanks

You need to manually adjust the two XML files I sent you. My development platform is Solaris, and thus the paths are set accordingly. You need to adjust them for your NMSROOT. Replace all instances of /opt/CSCOpx in both files with wherever CiscoWorks installed (e.g. C:\PROGRA~1\CSCOpx). Then, replace all '/' with '\'. Once the files have been properly adjusted, place them into NMSROOT\conf\csdiscovery, and restart dmgtd. That should solve this problem.

Joe, I updated the 2 files to correct the path information. It still didn't work so I compared the old and new files and found the last statement in each file (Value=) was delimited differently. The ones you sent me had file paths delimited with ":" and my old one used ";". So I changed this and then discovery started working. However I am still seeing the same thing. The discovery runs for a very long time and appears to still be trying to discover IP Phones. The Device Discovery Summary shows the "Unreachable Devices" count slowly incrementing. When I click on this count to show the devices they are IP phones.

Please tell me the byte size of the discovery.jar file you were given. It sounds like you still have an early bug that should have been fixed in the latest version.

My discovery.jar file shows as:

Size: 581,018 bytes

Size on disk: 581,632

Hmm, this should be 581019. Looks like you have the wrong version. I might have attached the wrong one by accident. I'll send the right one out.

Thanks Joe. I got the updated discovery.jar file and this works much better. One remaining issue is that the patch doesn't skip the following 3 device types:

ATA-186

7936 conference phone

PC's running IP Communicator

These currently make up only a small amount (15) of devices in my network so it didn't slow discovery down to much (it ran in about 7 minutes). I would think you would want to include skipping these in the patch however.

Any idea when this patch will become an official fix?

The device types were taken from LMS 3.0's ANIDevice.properties file which is the last set of non-SNMP CDP devices Campus supported. The conference phone can certainly be added (given its CDP platform ID), but the others have not been evaluated.

This should be fixed in the next Campus Manager release due out this spring.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: