IMC
cancel
Showing results for 
Search instead for 
Did you mean: 

Backing up Cisco MDS switches using iMC v7.3

 
cttripp1
Occasional Advisor

Backing up Cisco MDS switches using iMC v7.3

I have iMC v7.3 running and cannot get it to back up my Cisco MDS 9000-series switches.  The switches are being monitored by iMC without any issues.  Both SNMP and SSH are validated by iMC.  When I try to backup any MDS switch, the backup fails with an error message of "Failed to obtain the device version."  

I've seen some posts where backups to NX-OS devices do not work because of incorrect sysIOD information in iMC, but my version of iMC correctly identifies the switch as a Cisco MDS switch.

I do not have this issue with Cisco IOS devices.  I also used to have Cisco Nexus 5K switches being backed up by iMC, but I do not recall these having any backup issues.

Any ideas?  The MDS switches were never being backed up in the past, so this is a new issue for me.

5 REPLIES 5
jguse
HPE Pro

Re: Backing up Cisco MDS switches using iMC v7.3

Which transfer protocol are you attempting to use here? If it isn't TFTP (default but incompatible with SSH), then it should probably be SCP, and needs to be manually configured as transfer mode for these devices via Configuration Center > Options > File Transfer Mode.

Can you provide the SysOID of the Cisco MDS 9000 please? If it isn't found in iMC\server\conf\adapters\ICC\Cisco\adapter-index.xml, it may need to be added in there to use the correct adapter scripts (probably CiscoNX7K or CiscoIOSGeneric).

Best regards,
Justin Guse

Working @ HPE
cttripp1
Occasional Advisor

Re: Backing up Cisco MDS switches using iMC v7.3

The default transfer protocol is SFTP, but I did try testing using TFTP under the 'Single Device Transfer Mode'.  That did not work, even though I can copy the startup config using TFTP by logging into the switch and using the "copy startup-config tftp://IMC_SERVER_IP.  I'm not sure why it works from the switches command line but not when iMC tries to back it up.

iMC reports an error of "Failed to copy files from the root directory of the TFTP server to the system installation directory /server/data/cfgbak."

The sysIOD is 1.3.6.1.4.1.9.12.3.1.3.651

I have four MDS switches and they all report that same sysIOD.

 

jguse
HPE Pro

Re: Backing up Cisco MDS switches using iMC v7.3

The incompatibility with TFTP and SSH is likely due to security policies of businesses requiring that IMC does not allow the use of an insecure transfer protocol when it's stated that they want to use a secure protocol for CLI. That's just my two cents about it though.

That SysOID 1.3.6.1.4.1.9.12.3.1.3.651 isn't in the Cisco adapter-index.xml, so you should add it. Try adding it under CiscoIOSGeneric category, saving it and then restarting the "imccfgbakdm" process in IMC Deployment Monitoring Agent.

Then try setting the Single Device Transfer Mode for one of the devices to SCP, and give it a try. SCP in IMC uses pscp and doesn't require any additional configuration, plus it's supported by the CiscoIOSGeneric adapter. Unless you want to use TFTP - but then please configure Telnet CLI access instead.

Best regards,
Justin Guse

Working @ HPE
cttripp1
Occasional Advisor

Re: Backing up Cisco MDS switches using iMC v7.3

Adding the sysoid and using SCP didn't work.  The MDS switch sees the iMC server logging in (I can see the login with the "show users" command on the MDS), but with both the running and startup config backups, iMC reports the failure "Failed to copy files from the home directory of the SCP client to the system installation directory /server/data/cfgbak."

jguse
HPE Pro

Re: Backing up Cisco MDS switches using iMC v7.3

Do you see the configuration files being uploaded into /server/tmp directory? If it failed to copy the files, either the file does not exist (was not actually uploaded), or one with the same name exists arleady in the /server/data/cfgbak, or there was an issue processing the file.

If you still can't progress further, I'd suggest getting DEBUG logs for the imccfgbakdm process (via System Configuration > Log Configuration and then reproducing the issue) and opening a support case so it can be investigated properly.

Best regards,
Justin Guse

Working @ HPE