CatOS 7.1(x) code - failed TFTP config push issues

Steve Shelp · ‎06-17-2010

All,

I have found that CatOS 7.1(1) & 7.1(2) running on multiple platforms (tested on WS-C4006 and WS-C6509 so far) does not properly work when trying to push a configuration change up to the device from a TFTP server. Our scripts (and I also executed each snmpset manually from the CLI to make sure it wasn't a script issue) can successfully push and pull configs on other CatOS versions on both 4000 and 6000 devices but so far has failed on every attempt for 7.1(1) & 7.1(2) code on multiple platforms. I can't find anything on CCO or the internet where someone has run into this before.

Anyone seen anything similar?

We do large scales changes on many networks during maintainence windows and not having these devices work via SNMP and forcing us to use the CLI is a big time factor that is hindering our productivity. Would like to know why these fail and if there is a workaround/solution? Or do they not support SNMP/TFTP config change methods for whatever reason?

When pushing a config change up to one of these devcie usign the 7.1.x code the status MIB will report back a 2 which means it was successful. But the change never shows up in the config. I'm simply trying to change the system contact in the config during my proof of concept until I found out what this issue is.

Thanks in advance for any and all help/sugeestions,

Steve

Joe Clarke · ‎06-19-2010

You have config_copy_mib as a tag, but exactly what are you using to do the SNMP-triggered copy? That is, what objects are you setting, and to what values are you setting them?

Steve Shelp · ‎06-21-2010

Joe,

First off thanks for any and all help that you can provide. Here are the OIDs that I hit to push a cfg from the TFTP server to the remote CatOS switch. I am successful in pushing changes to a 6509 running 6.5 code and 7.6(8) code but have failed to push to multiple models of CatOS devices running 7.1(1) or 7.1(2) code to date. I can pull the cfg from these 7.1(x) boxes without a problem. But for test purposes we have tried jsut simply changing the system contact to see if this works or not and like I said so far its has not yeilded any successful results for 7.1(x) code.

snmpwalk -c .1.3.6.1.4.1.9.5.1.3.1.1.17 <<<< se what slot the SUP module is located first

snmpwalk -c .1.3.6.1.4.1.9.5.1.5
!
snmpset -c .1.3.6.1.4.1.9.5.1.5.1.0 string
!
snmpset -c .1.3.6.1.4.1.9.5.1.5.2.0 string textfile.txt
!
snmpset -c .1.3.6.1.4.1.9.5.1.5.3.0 i 1
!
snmpset -c .1.3.6.1.4.1.9.5.1.5.4.0 i 2
!
snmpwalk -c .1.3.6.1.4.1.9.5.1.5.5

When we originally discovered this it was run through a script. but through testing out using the manaual process via CLI even manaually running the snmpsets and walks fail also.

Thanks in advance,

Steve

Joe Clarke · ‎06-21-2010

It looks like this may be CSCin08269. That bug was filed for "set boot system" commands, but I believe the fix is generic enough to fix the problem you are seeing (in 7.2(2) and higher). Unfortunately, there does not appear to be a workaround to this other than using direct CLI interaction.