I've got the feeling that the CSDiscovery process does not take care of the flag 'Update DCR Display Name' anymore. These were the global settings used for the discovery job (no filters are in use, only CDP module, use DCR as seed and jump router boundaries enabled)
Preferred DCR Display Name: Host Name
Preferred Management IP: Resolve By SysName
Update DCR Display Name: Yes
Use Default Credentials: Yes
ICMP Timeout: 1000
ICMP Retry: 1
InterPacket Timeout: 20
Add Discovered Devices to a Group: No
Selected Group Name:
This is the second time I could see this behaviour. I saw this 1x windows2k3 and 1x solaris9 both with LMS 3.1;
On windows it was a fresh install of LMS 3.1; after the initial disco all devices (around 70) were found but no name resolution was present (thus they were in DCR with their IP); I configured the hosts file but even after several disco cycles the hostnames were not updated. I deleted all devices and they appeared with resolved hostnames with the next disco cycle.
Now I see it again on solaris.
I have a device with sysName_1 and IP_1(fa0/0) and IP_2 (loopback0) ;the Device is present in DCR with IP_1 because sysName_1 is not in DNS. This is ok acording to the 'Resolve by SysName' mechanism.
Now sysName_1 was changed to sysName_2 which resolves to IP_2 in DNS. After the next disco cycle I could see the device in the list 'Total Devices Discovered' with the corrected sysName_2. But when I checked the list 'Devices Updated to DCR' no change happened. The device was still listed with IP_1 as the 'IP Address' and as the 'Display Name' and 'Host Name'.
With my current knowledge of CSDisocvery I would assume that the 'IP Address' and the 'Display Name' and 'Host Name' should be updated.
The code that directly controls this feature did not change between CS 3.1.1 and 3.2. It would be helpful to see the CSDiscovery.log after enabling CSDiscovery Adaptor debugging, and re-running Discovery.
unfortunately this is not possible because of limited time on site I had to go forward and deleted all devices and did a new discovery which solved my problem (but I will keep these steps in mind for the next time!)
Currently I ask myself on which name resolution mechanism CSDiscovery relies? I think it is a java module which does not rely on nslookup and can be tested with the resolver.pl script.
But this is what I get for a certain IP/Name pair - and I ask myself if this is what it should be ?? - is the reverse lookup broken??
bash-2.05# /opt/CSCOpx/bin/perl /opt/CSCOpx/bin/resolver.pl 10.4.29.55
Original name: 10.4.29.55
bash-2.05# /opt/CSCOpx/bin/perl /opt/CSCOpx/bin/resolver.pl 01104ds01-10
Original name: 01104ds01-10
bash-2.05# nslookup 01104ds01-10
bash-2.05# nslookup 10.4.29.55
The CS 3.2 code actually uses two methods for name resolution. The first uses the system resolver (so the local hosts file will be queried). The second uses JNDI which directly talks to the DNS servers configured on the server. resolver.pl will adequately test the first method, and host or nslookup will test the second.
You're seeing a bug with resolver.pl (CSCsq54877) which will be fixed in LMS 3.2. My patch is available by contacting the TAC.
I have also just identified a bug in CS 3.2 where Discovery may not properly update the device attributes in DCR. I am testing a code fix now.
thanks, I will contact TAC to get the patch.
I have one more question about the list 'Devices Updated To DCR'; Is this just a ('static') list that reflects more or less precise what's going on after a disco cycle or is it really used by the code to determine updated devices? (which I could hardly believe).
I saw some strange entries in this list caused by the fact that devices deleted form DCR were still be listed here because they were found by the latest disco cycle. But now they are deleted form DCR and a new disco cycle was started. After discovery finished these devices were listed in 'New Devices Added To DCR' - so far so good. But they are also listed in 'Devices Updated To DCR' because they were in this list before and because this list did not get updated when Devices are removed from DCR. I assume that this is just a cosmetic thing but I think it is good to know how this works if one needs to interprete these results.
The devices updated in DCR list refreshes each time discovery is run. As the code is currently written, the list gets built when a duplicate device addition is attempted. Any device showing up in this list must have already existed in DCR.
'...the list gets built when a duplicate device addition is attempted.' - Good, but what is the algorithm to detect if it is a duplicate device addition?- I assume that it is a match against the list from the previous discovery and not a lookup if a device currently exists in DCR and must be updated.
To get the maximum effect, run a discovery and afterwards just remove all devices from CS> Device Management. The list 'Devices Updated To DCR' still exists - but there are no devices in DCR anymore. Start an new discovery cycle and all device are listed in 'Devices Newly added to DCR' *AND* 'Devices updated to DCR'.
Ah. Once a Discovery runs, the last run is cached in a serialized Java object on the file system. As long as another Discovery is not run, the lists of devices to be added, reachable devices, unreachable devices, and devices to be updated will be the same.
As for the second part of your problem, I cannot reproduce. I did this yesterday while testing my patch. When the device is not a duplicate to one already in DCR, it goes into the Added category only.
A duplicate device is one that shares the same display name as another device.
Now I understand - and the second part of my problem was homemade- just compared the wrong lists.
Is it the display name or the combination of the display name and domain name that counts? Could this be seen as a unique id for the code?
As a consequence it would be not allowed to have the same device name in another domain even if nameresolution is enabled and working !?
No. Discovery can update DCR with the FQDN or simply the hostname; your choice. If you have a case where a device has the same hostname, but unique FQDNs, then you will want Discovery to update the display name with the FQDN. This is perfectly legal.
Hi Joe, can this patch not be downloaded from http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-cd-one ? I don't understand why we have to contact TAC for important patches such as these. I'm also facing this problem with many of our customers using LMS. Cheers
Neither patch is posted to Cisco.com. TAC is the only way to get them. The reason for this is that these patches were not fully tested as point patches. Only patches which have undergone a required testing phase can be published to Cisco.com.
ok, thanks Joe. As a gold partner to Cisco, I hope we don;t get penalized for contacting TAC for these patches. I will contact TAC for the patches. P
to get you back to the bottom of reality... ;-)
for sure this will count on your score of opened SRs...