LMS 3.1 - CS 3.2: Duplicate Devices in DCR if DNS is unavailable?

[Martin Ermel]

A customer observed that devices where as duplicates in DCR - with the DNS name and the IP address. Currently we assume that this issue occures when the DNS server is not available and a discovery cycle runs. Thus the devices' IP address could not be resolved to a name and it will further be processed by its IP address. I know there is CSCsv65933 which affects the update of the DCRDisplay Name in CS 3.2 but the available patch from TAC is not installed on the system.

I cannot find any documentation about the behaviour of CSDiscovery when DNS is temporarily not available and the following settings for discovery are made:

use DCR as seed

Preferred DCR Display Name: FQDN

update DCR Display Name: yes

preferred Mgmt IP: Resolve by Name

So what happens if a device is in DCR with its FQDN and the next discovery cycle ths DNS server is not available. Will it be added into DCR with its IP or will the discovery process still find out that it is yet in DCR. And does this dependents on the way how the device will be picked up by the discovery process: as a seed from DCR or as a CDP neighbor in one of the discovery threads?

[Joe Clarke]

In CS 3.2, Discovery will try and resolve duplicates before inserting them into DCR. This is done by looking through the ipAddrTable on new devices to see if they have an IP address which already exists in DCR. However, if the device was added to DCR without an IP address, this cannot be properly done. The newly found device will be added to DCR.

[Martin Ermel]

I just verfied the devices in DCR by exporting them. Currently there is no device in DCR with missing IP address - but this is ok as the customer told me that currently there is no such problem (but now I know what to look at!)

Is there any other option then manually adding a device to have it in DCR just by its name and without an IP address (by manually I mean through the GUI or file import or cwcli) ?

Is it correct that this cannot happen through the discovery process?

Sorry, but your explanation rised another question...

what else will be used to find or reject possible duplicates if there is a matchof the IpAddrTable against an existing IP in DCR?

in which way is the following handled:

device_A in DCR with FQDN and IP_A

device_B (newly discovered) with IP_B configured on interface_B1 which is up and running; interface_B2 has IP_A configured but is shutdown;

[Joe Clarke]

One can manually add a device to DCR with just a display name. That display name will be treated as a hostname. We have a few customers that do not want IP addresses in DCR. These customers do not run Discovery, though. Devices added to DCR by Discovery will always have an IP.

Discovery ignores operationally down interfaces, period. They are not added to the internal device info object. Device B will be added to DCR.

[Martin Ermel]

Thank you for this clarification.

So back to the original problem, discovery will find that a discovered device is yet in DCR by comparing the ipAddrTable with the IPs in DCR. If there is a match and the newly discovered IP could not be resolved through DNS - will the DCR device get its display name updated to be the IP (asuming the settings from my first post)?

[Joe Clarke · Accepted solution]

No. The existing display name information in DCR should not change.

[Martin Ermel]

That's good to know, thanks.