CiscoWorks questions

Unanswered Question
May 22nd, 2007

If the discovery is working in Ciscoworks, and there are problems with the existing devices in the differnet modules, couldn't you just delete the duplicate devices and let the discovery process rediscover what was deleted?

I have some devices configured in Switches and the same devices configured in Routers in the ACS server.

Which I am thinking has caused problems in CiscoWorks.

If I remove the duplicates and have only one entry in ACS, then delete the devices in Ciscoworks, shouldn't CiscoWorks rediscover the ACS devices?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Joe Clarke Tue, 05/22/2007 - 11:39

I don't think you can duplicate devices in ACS. It complains when trying to add overlapping ranges. Though I suppose you could add multiple IP addresses for the same device. In any event, this won't have any impact on LMS. LMS just requires that the IP address or hostname that LMS is using to manage the device is known to ACS.

If you're getting duplicate devices in LMS, you can usually resolve these (at least in RME and DFM) by going to the list of aliased devices. If they cannot be resolved there, then simply remove them from DCR. IF you remove all dup entries from DCR, then discovery should re-find the device, but you will lose data that has already been collected (e.g. in RME).

wilson_1234_2 Tue, 05/22/2007 - 13:02

Thanks for the reply.

Actually the devices are in the created groups Switches as one ip address and in Routers as another ip address in the ACS

The devices are 6509 switches which have multiple VLANs configured.

These are also the devices that are getting the SNMP authentication failure from the ciscoworks server (along with a CallManager server).

I still have not found where it is coming from, all SNMP serttings are correct in CiscoWorks.

Joe Clarke Tue, 05/22/2007 - 13:12

I answered your other thread on the auth messages.

Again, I don't think these multiple ACS entries will cause you any problems provided your user ID (and the LMS System Identity User ID) has access to all ACS NDGs.

wilson_1234_2 Tue, 05/22/2007 - 14:49

Thanks j,

I still do not understand the different components of Ciscoworks and how they work with ACS.

For example:

If the devices are in ACS twice (slightly differnet names)and the integration is working correctly from ACS to LMS, which device would show up in CiscoWorks?

Would both of the names show up?

If you have integration set up and working, why do you need to have a discovery of the differnet devices? Shouldnt the integration be all you need?

As in your earlier replys, is the "devices not in LMS" report a way to determine what was integrated and what was discoverd?

also, just because a device is discovered does not make it manageable within Ciscoworks, correct?

Joe Clarke Tue, 05/22/2007 - 17:52

Ideally you will ever only have ONE of each device in LMS. Cisco recommends you pick a loopback or other always-up virtual interface to use a central management interface for each device. From the address bound to this interface, all syslog messages and SNMP traps will be sourced, and this will be the address that is managed by LMS. In that case, that address, and associated hostname is what will appear in DCR (and thus in all LMS applications), and that is the address that you would need to add to ACS.

However, if you had two entries for the same device in ACS, you could have both entries in LMS as well. This would be a non-optimal configuration as you are basically eating up twice the resources for one device.

Integration and discovery serve two different tasks. But, if you already had ACS setup with all your devices, you can forgo discovery, and simply import from ACS. The DCR Import feature supports this.

If a device appears in the "Devices not in ACS" report, then that means the IP address and hostname listed in that report are not listed in ACS. In other words, discovery found that IP address, but that is not what ACS has. At that point, you will need to add that address to ACS, or redesign discovery to pick a different management IP for the device. By playing with the name resolution schemes in discovery, you should be able to get the desired address. Of course, this goes back to what I said earlier about it being a leading practice to pick one interface on which all management operations will occur.

If a device is discovered, and is reachable, then by default all LMS applications will attempt to manage it. However, in LMS 2.6, the device will only have a read-only SNMP credential in DCR. This is not sufficient for all management operations (e.g. config collection). In this case, additional credentials will need to be added to the device in DCR before those operations will succeed. LMS 3.0 will be adding a Default Credential feature that will address this shortcoming.


This Discussion