12-31-2007 08:19 AM
Hi,
I had a bit of trouble getting the DCR discovery to work in LMS 3.0 with Dec update and wanted to share the findings. Originally I had the LMS pupulated with the devices from a CSV file where I also inculded the MCS Call Managers that are not supported by LMS 3.0. When I enabled the DCR discovery (the new feature in the Dec update), it would run for 2 sec without discovering anything. In the debug log file it was showing exception on reaching the CCM hosts (I had "Use DCR as seed"). As soon as these CCM hosts were removed from DCR the discovery started working with no issues
12-31-2007 09:25 AM
What exception were you seeing? An unknown device in DCR should not cause discovery to abort.
12-31-2007 09:51 AM
There was not much details on this, just the fragment below that gave some clues (the entire CSDiscovery.log just for a single discovery attempt was 130K):
[ Fri Dec 28 21:36:44 EST 2007 ] ERROR [CSDiscoveryAdaptor : constructDeviceInfo] : Exception while constructing Seed Device Info
from DCR device. mrkmccccm02: mrkmccccm02
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : getSeed] : [getSeed()] called .
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : getGlobalSeedDevices] : [getGlobalSeedDevices] No Global Seed Devices
set from File/GUI.
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : [putStatus()] called. com.cisco.nm.discovery.framework.i
nfo.DiscoveryProgressInfo@14df764
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : [putStatus()] called. com.cisco.nm.discovery.framework.i
nfo.DiscoveryProgressInfo@14df764
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : NGDDiscoveryStatus start time : 0
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : NGDDiscoveryStatus start time : 0
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : CS DiscoveryStatus start time : 0
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : CS DiscoveryStatus start time : 0
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : CS UNManaged Devices: 0
[ Fri Dec 28 21:36:44 EST 2007 ] DEBUG [CSDiscoveryAdaptor : putStatus] : CS UNManaged Devices: 0
12-31-2007 10:41 AM
What does the entry look like for this device from your import CSV file? How do you have discovery configured. I've tried a few things locally, but I am unable to reproduce this problem.
12-31-2007 10:49 AM
And compressing and attaching the entire CSDiscovery.log will be helpful.
12-31-2007 11:52 AM
12-31-2007 12:16 PM
I think I found the bug. I have a patch you can try. You will need to open a TAC service request, and have the engineer contact me directly to get it.
12-31-2007 12:26 PM
Thanks, so far it has been ok, I guess as long as I'm careful with adding the devices (to make sure they are supported / recognized by CS), all should be good
12-31-2007 12:31 PM
That's not the problem. The problem is hostname resolution. Any device that does not have an IP address in DCR will trigger a hostname lookup on the hostname value in DCR. If that fails, then discovery will fail. But it's worse than that. The domain name component is not taken into consideration. Therefore, if the short hostname fails to resolve, then discovery will fail.
The workaround is to make sure every entry in DCR has an IP address configured.
12-31-2007 12:58 PM
You are right, all the routers / switches are configured in subdomain net.otn.local which is in the search path of resolv.conf; the CCM boxes are in otn.local, this domain is configured only as the domain name of the CW host Sun box in resolv.conf and not in the search path, apparently solaris does not try to search with its own domain name unless it is also in the search path.
12-31-2007 02:21 PM
I filed CSCsl99637 to track this issue.
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: