Campus manager & DCR

Unanswered Question
Aug 12th, 2007

The automation between CM and DCR appears to have stopped working on our CiscoWorks.

Changes made to the DCR are not reflected in the device list in CM, and new devices discovered by CM are not being added to DCR.

Where do i check the settings to ensure the two modules are interacting properly?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joe Clarke Sun, 08/12/2007 - 18:28

For sending newly discovered devices into DCR, check to make sure those devices are reachable under Campus Manager > Home (click the number of devices discovered). Also, check the discovery.log file for any errors.

As for the other way around, which device list are you looking at? What changes are not beign reflected?

philmcgregor Sun, 08/12/2007 - 20:14

We're looking at the Device Management section of Device and Credentials, under All Devices.

We're changing the config of devices in our network.

The old devices are still in DCR with their old hostname and IP. We assumed they would be updated with the new hostname and IP.

These old devices are also showing up in the CM discovered devices (as unreachable).

The updated devices with their new hostnames and IP are also showing up in the discovery list (as reachable), though are not being updated in DCR.

We're assuming the old devices are remaining in the discovery list because they are still in DCR.

However, upon deleting a couple of the old devices from DCR, these old devices still show up in the discovery list, and they are not being re-entered into DCR with their updated hostname and IP.

Joe Clarke Sun, 08/12/2007 - 22:19

The discovery list should change each time discovery is run, and that list has no bearing on what is in DCR. Since you changed _both_ the IP address and hostname on your devices, Discovery will not be able to determine those devices in its seed list (which includes DCR) are the same devices as the ones it finds with the new IP and hostname. Therefore, it will add the new hostname/IP as a new device to DCR (thus creating a duplicate in DCR). As long as the old names are still in DCR, Discovery will report that it "found" them as unreachable because all devices in DCR act as seed devices for Discovery.

If you remove the old devices from DCR, then Discovery will find all of the new names, and update DCR properly. Of course, this will mean you will lose all of the RME history for these devices. Another alternative is to go through DCR, and manually update the hostname and IP addresses on all of the changed devices.

philmcgregor Mon, 08/13/2007 - 15:23

Since you changed _both_ the IP address and hostname on your devices, Discovery will not be able to determine those devices in its seed list (which includes DCR) are the same devices as the ones it finds with the new IP and hostname.

We've deleted the old seed list of IP addresses and put in all the new IP's as seeds. So the seed list should now include all the new IP's of the updated devices, and the old devices that are coming from DCR. Correct?

The new devices are being discovered correctly, correct hostname and IP and are reachable, its just the old entries that remain that are the problem.

As long as the old names are still in DCR, Discovery will report that it "found" them as unreachable because all devices in DCR act as seed devices for Discovery.

Thats what we thought, but its not what we're seeing. Having deleted a few old devices from DCR as a test, we still see these old devices showing up in the discovery list, even though there's no seed in the seed list for that item, and there's no entry for it in DCR anymore. Does discovery draw its info from anywhere other than the seed list and DCR?

If you remove the old devices from DCR, then Discovery will find all of the new names, and update DCR properly.

Again, not what we're seeing. The few test devices that we deleted from DCR are not being updated/repopulated back into DCR after a new discovery is run.

Joe Clarke Mon, 08/13/2007 - 15:45

Both the seed list and the devices in DCR will be used as seeds for Discovery. So if you removed the devices from the old seed list, and left them in DCR, they will still show up as unreachable when Discovery runs.

If you've removed the devices from DCR AND from the seed list, but they still show up in Discovery, their information must still exist in some device's CDP cache. Discovery will not make up devices, and there are no other sources from which it can learn devices.

The order by which discovery works:

1. Pull in seed list from DeviceDiscovery.properties

2. Pull in list of all devices from DCR that match the discovery filter

3. For each device, query the CDP cache, and add all devices that pass the discovery filter to the list of devices to query

4. Repeat step 3 until all devices have been found

So, check the neighbor lists for your devices in the Discovery report, and look for stale entries. Then perform a full DCR export, and confirm the devices have been deleted. Finally, manually check NMSROOT/campus/etc/cwsi/DeviceDiscovery.properties and make sure your old devices are gone.

philmcgregor Tue, 08/14/2007 - 18:31

Well our discovery report lists our new devices correctly, with hostname, ip, neighbours and are reachable.

The old devices we're trying to get rid of show with their old hostnames, old ip's, no neighbours and are unreachable.

So if the old devices arent in the seed list, arent in the DCR, and arent showing up as cdp neighbours to anything, where in the world could they be coming from?

Could it maybe be drawing its info from RME?

You used the term 'CDP cache'. I was unaware cdp kept its info about neighbours for any longer than a couple of minutes, as specified by the holdtime.

Joe Clarke Tue, 08/14/2007 - 19:43

No, the devices cannot be coming from any other source. The CDP cache will expire devices based on the hold timer unless they are still present on the network. If you enable devdiscovery debugging under Campus Manager > Admin > Device Discovery > Debugging Options, then run a new Discovery, you should be able to see where those old devices are coming from.

philmcgregor Thu, 08/30/2007 - 17:57

Ok, so we've created a 2nd instance of our CW servers to test, running on 2 new solaris boxes, using the exact same install procedure as our servers in the live environment.

Campus manager is discovering devices correctly, with the new devices having the new hostnames and ip's, and the yet-to-be-updated devices displaying their correct old hostname and ip's. There's no unreachable devices displaying old ip's or hostnames.

DCR however, has no devices in it whatsoever.

If the campus discovery is supposed to automatically populate DCR, something is definitely wrong.

This pretty much confirms in my mind that there's something wrong with our implementation of the DCR <-> discovery interaction on our production servers too...

Joe Clarke Thu, 08/30/2007 - 18:36

Is this other server integrated with ACS? If so, are the devices showing up under the Common Services > Device and Credentials > Reports > Devices not in ACS report?

Joe Clarke Thu, 08/30/2007 - 21:05

Enable devdiscovery debugging under Campus Manager > Admin > Device Discovery > Debugging Options, then run a new Discovery, and post the discovery.log.

Joe Clarke Sun, 09/02/2007 - 19:03

These files all turned out to be binary. Please just compress the whole log, and post it. It's just plain text, so it should compress down quite well.

Joe Clarke Sun, 09/02/2007 - 22:17

Looks like there is a problem with DCR. It's strange, though, that Discovery can read from DCR, it just cannot write to it. To figure out what is going on will require DCR debugging. Since that is not so straight-forward in LMS 2.6, I recommend you open a TAC service request, include this discovery.log, and they can instruct you on how to enable and then disable DCR debugging.

philmcgregor Sun, 09/09/2007 - 15:47

Interesting...

On a hunch i went back and reinstalled our test implementation.

Discovery and DCR are working perfectly now.

Only difference to this configuration and the ones tested previously was we did not change nameserver.updateDCRDisplayName to true, as was suggested to combat our earlier problem: (http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=Network%20Management&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1dde9a36)

Our current issues seemed to start around the time we made this change.

Any ideas why updateDCRDisplayName would play such havoc on DCR?

Joe Clarke Sun, 09/09/2007 - 15:49

It wouldn't. This property just tells Campus to send a little bit more information to DCR when it does its update. It would not have caused the CSTM error you were seeing.

Actions

This Discussion