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 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).
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...