We are using LMS 2.5 with Common Serivces 2.5, Campus Manager 4.0.4, RME 4.0.3, Cisco View 6.1.4.
Since we installed LMS 2.5, it is showing RME Config Archival Status failed for 41 devices (total of 285 devices)
Moreover, in Common Services->Report->Device that are not configured in ACS Report shows the same 41 devices failed archive.
Is there any relation with ACS server? Pls suggest
If you are integrated with ACS, all the devices managed by LMS must also be TACACS+ clients in the same ACS server. They do not need to actually use this ACS server for AAA (the devices do not even need to be configured for AAA). However, they must be configured as clients.
Yes, all these failed archive devices in RME are already configured for the same ACS server. How can we resolve the problem?
If they appear in the Devices Not in ACS report then they are not properly configured as clients of the ACS server. Check to make sure that the IP address or hostname in DCR is in the ACS server, and that the client protocol is TACACS+.
be sure you did the following steps while integration LMS-ACS. If you do it in this way it will work:
Step 1: Setup up a System Identity User
- Common Services > Server >Security >Multi-Server Trust Management >System Identity Setup
Step 2: Ensure that System Identity User is a local User with all the roles
- Server >Security >Single-Server Management >Local User Setup
Step 3: Define a group for CW Admin Users in ACS
- Go to GROUP SETUP
- Rename an available Group to something suitable such as CWAdmins
- Edit Settings
- Sessions available to user = unlimited
Step 4: Add the CW system identity user (and other Admin users in CW) to ACS
- Go to USER SETUP
- Create Users for Ciscoworks including the System Identity User in ACS
- Assign all these Admin users to the Group created in Step 3
Step 5: Add a network device group with Ciscoworks as a Client
- Go to NETWORK CONFIGURATION
- IP address or range with wildcard masks
- Authenticate using: TACACS+ (Cisco IOS)
Note: (If NDG options are not visible, you can enable Network Device Groups in ACS under INTERFACE CONFIGURATION -> ADVANCED)
Step 6: Change CW AAA Mode to ACS TYPE (and register CW applications with ACS)
- Common Services > Server > Security > AAA Mode Setup
- Select ACS type
- Fill in IP address/Hostname of ACS server
- Fill in the ACS admin login information and the shared key
Note: ?ACS admin login" must be a user with full admin rights to ACS (i.e. one configured under Administration Control in ACS with ALL options checked)
- Put a check mark in "Register all installed applications with ACS" **
- Click on apply
- Restart CW Daemon Manager for above changes to take effect.
**WARNING: Make sure that AFTER the first successful registration to any specific ACS server, you always keep this box UNCHECKED if switching between ACS and non-ACS modes on LMS server.
Failure to do so will erase all custom roles (SUPERUSER) and you will need to do Step 7-8 on ACS again.
Step 7: Add "SUPERUSER" role for each module of Ciscoworks in ACS
- Go to SHARED PROFILE COMPONENTS
- Select a CW module (such as Common Services)
- Name it CWSuperUser or something similar
- Select everything under the available functionality for that module
--REPEAT above procedure for Ciscoview, RME, Campus, DFM and any other Ciscoworks modules such as IPM, etc.
Step 8: Assign the "SUPERUSER" role to the Admins Group (created in Step 3)
- Go to GROUP SETUP
- Edit Settings
- Select cwhp, rme, campus, dfm and any other CW components a select the "SUPERUSER" role (created in step 7)
IMPORTANT: Once ACS mode is enabled on Ciscoworks, ALL devices MUST be added to the same ACS server as clients for them to be manageable in Ciscoworks. While the devices must be known (i.e. configured as clients) in the same ACS server, they do not have to use that ACS for their own AAA configuration, nor do those devices need to be configured for AAA themselves.
I hope that helps.
P.S. Please rate helpful posts
AAA mode setup with Ciscoworks has been configured correctly as apart from the problematic 41 devices, all other devices (244) are working fine and having sync config successfully with Ciscoworks.
I am confused when I run RME->Archive sync job and it shows me failed devices and at the same time Cisco ACS server shows the authentication failed attempts.
But it run perfectly with rest of the devices. Pls help.
Pick a device that is NOT showing up in the Device Not in ACS report and that DOES work. Look at the way that device is configured in ACS. Then pick one of the fialing 41. How is it configured in ACS? What is different?
I did the same and I could reduce the network failed sync devices to 7 only. (earlier it was 41).
Now there only two problem left with:
1. ASA firewall sync fail gives this error:
CM0056 Config fetch failed for mannfwinet.network.nemcorp.com.au Cause: CM0204 Could not create DeviceContext for 249 Cause: CM0206 Could not get the config transport implementation for 10.71.2.17 Cause: UNKNOWN Action: Check if required device packages are available in RME. Action: Check if protocol is supported by device and required device package is installed.
2.Cisco VPN concentrator: this gives error:
Connection timed out: connect
I had checked snmp community strings at both sides (device and cisco works). Pls suggest.
The ASA error is expected. These devices are not supported by RME. Support is expected this December.
As for the VPN concentrator, you might want to schedule a sync job to one failing concentrator, then run a sniffer trace filtering on all traffic to that device. See what connection is timing out. I believe it could be the HTTP session.
For VPN concentrator, I have checked that Cisco box can access VPN concentrator using HTTP without any problem.
In device credential verification report, read community is OK but telnet is Incorrect. Is it related with problem?
Again, your best bet is to get a sniffer trace or even look at the dcmaservice.log to see exactly what connection is not succeeding. I don't have enough information here to provide anymore insights.
Error message if it help to suggest something:
*** Device Details for sydnvpn1 ***
Protocol ==> Unknown / Not Applicable
CM0062 Polling sydnvpn1 for changes to configuration. CM00 Polling not supported on PRIMARY RUNNING config, defaulting to fetch. CM0151 PRIMARY RUNNING Config fetch failed for sydnvpn1 Cause: Connection timed out: connect Action: Check if protocol is supported by device and required device package is installed. Check device credentials. Increase timeout value, if required.
Besides the SNMP credentials, you must fill in HTTPS credentials for config archive to work. This means you need a valid HTTP Username, HTTP Password, and the Current Mode must be HTTPS. Also, 443/tcp is expected for HTTPS to the VPN Concentrators. If the concentrators are listening on another port, config fetch will fail.
I am also facing the same problem
I tried all the options u mentioned but still VPN config is not getting archived
also devcies package is installed.
What error message are you receiving when you run a Sync Archive job for one of these failing devices?