This image shows that I have Telnet, SSH, TFTP and HTTPS configured for Config Fetch. What am I missing?
I don't know why, but nearly ALL of my Config Archive VLAN is failing. I am receiving the following:
TELNET: Failed to establish TELNET connection to xxx.xxx.xxx.xxx - Cause: Connection refused. Command failed VLAN Config fetch is not supported using RCP. VLAN Config fetch is not supported using TFTP.
The above switch is using SSH - not Telnet, but it doesn't try???
The other error is:
Command failed Could not detect SSH protocols running on the device VLAN Config fetch is not supported using RCP. VLAN Config fetch is not supported using TFTP.
On this one, it should be using Telnet as that is what is supported on this particular switch.
I have verified the credentials are set up correctly for both of these.
Also, this isn't isolated - it's happening on 293 devices. Only 2 are successful.
Any help would be GREATLY appreciated! I am running LMS 3.2
1. Goto Common Services ---> Software Center ---> Software Update --> Post screenshot and OS version.
2. From RME ---> Administration ---> System Preferences ---> Log Level Settings ---> Select Archive Management and enable debug.
3. Start a sync archive jog and not the job id for one of the problematic devices.
4. Get me the CSCOpx/log dcmaservice.log and dcmaclient.log.
5. Goto CSCOpx/files/rme/jobs/ArchiveMgmt/
6. Get show tech of one of the devices.
7. Run a device credential verification on the problematic device from the previous step from RME --> Devices --> Device Management --> RME Device Credential Verification Job.
8. Goto CSCOpx/files/rme/jobs/cda/output/
9. Post screenshot of RME --> Admin ---> Config Management --> Transport Settings.
Also try removing and re-adding the device from Common Services Device Management page and repeat above steps.
The following is what I see in the logs:
],ERROR,[Thread-1926],com.cisco.nm.rmeng.dcma.configmanager.ConfigManager,updateArchiveForDevice,1355,VLAN RUNNING Config fetch Failed for csw-a1xc-201-004
[ Fri Oct 08 06:27:18 MDT 2010 ],DEBUG,[Thread-1926],com.cisco.nm.rmeng.dcma.configmanager.ConfigManager,updateArchiveForDevice,1361,Message : Command failedSSH: Failed to establish SSH connection to x.x.x.x -
Cause: Authentication failed on device 3 times.
VLAN Config fetch is not supported using TFTP.
Please ensure that you have the credentials corrected in the DCR under Common Services --> Device and Credentials --> Devices Management --> Select all the devices in question, edit credentials.
1. Ensure the primary enable username and password is correct and populated.
2. Ensure you are using the correct SNMP RO/RW community string and must be populated.
3. Ensure that all firewall rules allow traffic to and from LMS and devices. Check port 69 UDP and high ports number are allowed.
4. If this is a multi-home system with two nic cards, go to RME ---> Administration --> System Preferences --> RME Device Attribute --> Add Natted RME IP Address
Afterwards, rerun the device credential verification to test for telnet, ssh, SNMP RO and RW and ensure it passes. Then do a sync archive and let me know the results.
Thank you for your help. Here is a screen shot. The first group fails on SSH (because it isn't configured) but is successful by Telnet. The second group is just the opposite. This is just a sample of what is there so you get an idea of what is happening.
Here is another of the collection status.
1. Goto RME ---> Administration --> System Preferences --> RME Device Attribute --> Add Natted RME IP Address.
2. Can you get a packet capture and do a sync archive on one of the devices then provide the ip address?
3. Can you verify if you have any firewall in place as well, enable debugs again, then post the dcmaclient.log and dcmaservice.log again?
Ok, so I did a capture and what I see is a TFTP Write request of file xxxx.200.245.cfg. The response is destination unreachable, port unreachable.
I would assume this is a firewall issue, but I got on the server to a command prompt, and did a netstat -ano and the server isn't even listening on UDP port 69.
I found out that the CWS tftp service on the server had changed to manual from automatic
. Changing it back to automatic and rebooting the server fixed it. (I actually started the service first, ran an archive, then rebooted the server.