Ciscoworks Config Retrieval failure

[emulder5]

We are having an issue retrieving configs from a set of 6500 switches. These devices are not accessable through telnet or ssh directly, but we do have snmp access to the devices, and TFTP access back to our Ciscoworks server. We have our Configuration Managment transport setting set up for TFTP, Telnet (because other devices do use telnet). However, when attempting to sync the config archive for one of these devices, it fails. A packet trace reveals the following communications:

- snmpget to the device for the SysUptime (device responds successfully)

then a telnet connection is attempted from Ciscoworks to the device, which fails, and the sync archive job fails.

I understand that Ciscoworks should be sending an snmpset to trigger the TFTP push back to the Ciscoworks server, but I'm not seeing any evidence of this happening.

Sound familiar to anyone?

thanks,

Eric

[kyawzawhtut]

Do you set the SNMP RW access as well? I think you need to have RW access to be able to do it if not using Telnet. Not sure though.

No harm trying to set SNMP RW with access list.

Cheers!

[emulder5]

Indeed we do have the RW string set as well. What is mainly throwing me off, is that I don't see any attempt from Ciscoworks to do the SNMP set that is to trigger the TFTP push. thx

[Joe Clarke]

You must make sure you have a read-write community string or an SNMP user with proper read-write access configured in CiscoWorks for SNMP/TFTP to work. However, for IOS switches, RME will attempt to use telnet/SSH to retrieve the vlan.dat configuration from the switch. This is not changeable. Therefore, you can expect to get partial failures on these devices if telnet or SSH is not available. However, if you are running newer versions of IOS in which the VLAN/VTP configuration is in the running config, these errors can be ignored as you aren't using vlan.dat anyway.

[emulder5]

Our RW community string is set, and unfortunately the config retrieval completely fails. I'm not seeing any evidence of the snmpset to tftpAction object in the Cisco-Stack-MIB which I think would be used to trigger the TFTP.

code is CatOS -

System Boot Image File is 'bootflash:cat6000-sup2k8.7-6-9.bin'

thanks,

Eric

[sirbaughmf]

Did you get this figured out, I am seeing the same issue.

thanks,

Marcie

[Joe Clarke]

If you're seeing the exact same issue, the next thing to check would be the protocol order for config fetch under RME > Admin > Config Mgmt. If TFTP is the first protocol, then RME should be using an SNMP SET operation to trigger the transfer.

To debug this further, enable ArchiveMgmt debugging RME > Admin > System Preferences > Loglevel Settings, reproduce the problem, then look at the dcmaservice.log for errors.

[sirbaughmf]

I am still on RME 3.5....I am not seeing System Preferences?

[Joe Clarke]

Then this may not be the same problem. Please start a new thread, and include the exact version or RME, switch type and version, and the error you are seeing in the GUI.

[sirbaughmf]

ok, but can you tell me where to change the logging for now....

[Joe Clarke]

The logging for config management cannot be changed in the GUI. You have to modify NMSROOT/www/classpath/com/cisco/nm/config/archive/config.properties, set DEBUG_LEVEL to 5, then restart ChangeAudit and JRunProxyServer. The log files will depend on the server OS.