Unable to Send Config Changes to ISR 4321 via SNMP

[Joel Jackson]

I'm trying to use the following snmpset commands to send config changes to a 4321 that doesn't seem to have crypto keys generated for ssh. The file rtr-cfg.config just enables telnet. I know the commands work since I tested them on a different device and the commands were pushed.

snmpset -c RWCommunitySTR -v 2c TargetDeviceIP 1.3.6.1.4.1.9.9.96.1.1.1.1.2.668 i 1
snmpset -c RWCommunitySTR -v 2c TargetDeviceIP 1.3.6.1.4.1.9.9.96.1.1.1.1.3.668 i 1
snmpset -c RWCommunitySTR -v 2c TargetDeviceIP 1.3.6.1.4.1.9.9.96.1.1.1.1.4.668 i 4
snmpset -c RWCommunitySTR -v 2c TargetDeviceIP 1.3.6.1.4.1.9.9.96.1.1.1.1.5.668 a tftp-server-ip
snmpset -c RWCommunitySTR -v 2c TargetDeviceIP 1.3.6.1.4.1.9.9.96.1.1.1.1.6.668 s "rtr-cfg.config"
snmpset -c RWCommunitySTR -v 2c TargetDeviceIP 1.3.6.1.4.1.9.9.96.1.1.1.1.14.668 i 1

Are the oids different for 4321s??

[Ben Walters]

The 4321 supports those OIDs but have you tried it multiple times with the same number at the end of the OIS string (668?)

There is a timeout limit of 5 minutes so maybe something went wrong the first time and now you have to use a different random number to upload the file.

Did you check out this guide?

https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/15217-copy-configs-snmp.html#app

They also use the 1.3.6.1.4.1.9.9.96.1.1.1.1.14.x value of 4 instead of 1, maybe give that a go?

Hopefully this helps.

[Joel Jackson]

Yes I've tried it numerous times. There is a way to check the status of the copy using the oid:

.1.3.6.1.4.1.9.9.96.1.1.1.1.10 (ccCopyState) 

It sits at a state of 2 for a little while then goes to 4 (failed)

I tried using 4 (createAndGo) like you suggested and got an inconsitentValue error.

[Ben Walters]

You should be able to check the status of the failure with

1.3.6.1.4.1.9.9.96.1.1.1.1.13

It might give you some insight into why it failed.

[Joel Jackson]

That OID returns 3 (timeout). I never even see the tftp attempt begin in wireshark. Also I tested on another 4321 and the commands work as expected on that one so this seems like an issue specific to this router. I'm suppose I'll do some more investigating, maybe do the TFTP from the local subnet and see if that works. I will report back if I find the root cause.

[Joel Jackson · Accepted solution]

I figured it out! I was trying to do the config transfer via tftp. In the config on another router that has this same issue (except that I can already ssh into it), I found the following command:

ip tftp source-interface gigabitEthernet 0 (the management port which is not connected nor is it configured)

Since there is no cable connected to this interface, tftp will not work. I looked at the copy of the config I have for the router I'm trying to get into and it's pointing to this interface as well. It doesn't appear that FTP nor SCP are supported either even though the options are present for the OID. In this case I will have to send a console cable out and have them connect it to our branch server  unfortunately. Glad I can have some closure on why it did not work though.