Following on from my previous post regarding using SNMP to initiate TFTP backups, it’s also possible to use SNMP to remotely upgrade IOS on a Cisco device.
I’ll reuse and extend the setup and configuration from the previous article so apply that first. The IOS device then needs the following additions:
router(config)#snmp-server view myview ciscoFlashOps included router(config)#snmp-server view myview lts.9 included router(config)#snmp-server system-shutdown |
The first command grants SNMP write access to allow us to manipulate the flash storage in the device. The remaining commands allow us to trigger a reload/reboot of the device remotely via SNMP.
On our “management station” we’ll need a few more MIB files installing under ~/mibs or wherever you put them:
- CISCO-FLASH-MIB
- ENTITY-MIB
- OLD-CISCO-TS-MIB
Update the $MIBS environment variables to include them, you’ll need something like the following:
# export MIBS=+CISCO-CONFIG-COPY-MIB:CISCO-FLASH-MIB:OLD-CISCO-TS-MIB |
Now, my devices don’t have enough flash storage to hold two IOS images so I normally have to delete the current version (which is loaded into memory, so it doesn’t affect the operation of the device) to free up space and then upload the new version, reload, and pray it works.
To find the filename of the current IOS image we can use the SNMP equivalent of dir flash:/:
# snmptable -v 3 -l authPriv -a MD5 -A authsecret -x DES -X privsecret -u myuser -Cb -Ci -Cw 80 192.0.2.254 ciscoFlashFileTable SNMP table: CISCO-FLASH-MIB::ciscoFlashFileTable index Size Checksum Status Name 1.1.1 576 bytes "0x0" valid / 1.1.2 16459360 bytes "0xDEADBEEF" valid c870-advsecurityk9-mz.124-15.T9.bin SNMP table CISCO-FLASH-MIB::ciscoFlashFileTable, part 2 index Type Date 1.1.1 directory ? 1.1.2 unknown ? |
The index is a composite of the flash device, partition and file, so 1.1.2 is the second file on the first partition of the first flash device. Unless you have multiple flash devices and/or partitions you can largely ignore these details, take a look at ciscoFlashDeviceTable & ciscoFlashPartitionTable if you want more information.
With the filename, we now need to construct a request to delete it. This sort of operation along with tasks such as erasing the flash, etc. uses the ciscoFlashMiscOpTable SNMP table. Using the same technique I demonstrated in the previous article insert a new row and activate it:
# snmpset -v 3 -l authPriv -a MD5 -A authsecret -x DES -X privsecret -u myuser 192.0.2.254 \ ciscoFlashMiscOpCommand.23 i delete \ ciscoFlashMiscOpDestinationName.23 s c870-advsecurityk9-mz.124-15.T9.bin \ ciscoFlashMiscOpEntryStatus.23 i createAndGo CISCO-FLASH-MIB::ciscoFlashMiscOpCommand.23 = INTEGER: delete(3) CISCO-FLASH-MIB::ciscoFlashMiscOpDestinationName.23 = STRING: c870-advsecurityk9-mz.124-15.T9.bin CISCO-FLASH-MIB::ciscoFlashMiscOpEntryStatus.23 = INTEGER: createAndGo(4) |
Note that I’m using createAndGo instead of active for the row status because it’s part of the same initial set request. Now check the table to see if the operation was successful:
# snmptable -v 3 -l authPriv -a MD5 -A authsecret -x DES -X privsecret -u myuser -Cb -Ci -Cw 80 192.0.2.254 ciscoFlashMiscOpTableSNMP table: CISCO-FLASH-MIB::ciscoFlashMiscOpTable
index Command DestinationName Status
23 delete c870-advsecurityk9-mz.124-15.T9.bin miscOpOperationSuccess
SNMP table CISCO-FLASH-MIB::ciscoFlashMiscOpTable, part 2
index NotifyOnCompletion Time EntryStatus
23 false 0:0:00:56.24 active |
It worked so checking the flash storage should confirm the file is now absent. Now we can upload the new IOS image, you’ll need to have it copied to /tftpboot on your TFTP server. This uses another SNMP table but the procedure is exactly the same, insert a row describing the operation we want to perform:
# snmpset -v 3 -l authPriv -a MD5 -A authsecret -x DES -X privsecret -u myuser 192.0.2.254 \ ciscoFlashCopyCommand.23 i copyToFlashWithoutErase \ ciscoFlashCopyProtocol.23 i tftp \ ciscoFlashCopyServerAddress.23 a 192.0.2.1 \ ciscoFlashCopySourceName.23 s c870-advsecurityk9-mz.124-24.T4.bin \ ciscoFlashCopyEntryStatus.23 i createAndGo CISCO-FLASH-MIB::ciscoFlashCopyCommand.23 = INTEGER: copyToFlashWithoutErase(2) CISCO-FLASH-MIB::ciscoFlashCopyProtocol.23 = INTEGER: tftp(1) CISCO-FLASH-MIB::ciscoFlashCopyServerAddress.23 = IpAddress: 192.0.2.1 CISCO-FLASH-MIB::ciscoFlashCopySourceName.23 = STRING: c870-advsecurityk9-mz.124-24.T4.bin CISCO-FLASH-MIB::ciscoFlashCopyEntryStatus.23 = INTEGER: createAndGo(4) |
Chances are this operation will take a minute or two to complete, keep checking ciscoFlashCopyTable until it completes:
# snmptable -v 3 -l authPriv -a MD5 -A authsecret -x DES -X privsecret -u myuser -Cb -Ci -Cw 80 192.0.2.254 ciscoFlashCopyTable
SNMP table: CISCO-FLASH-MIB::ciscoFlashCopyTable
index Command Protocol ServerAddress
23 copyToFlashWithoutErase tftp 192.0.2.1
SNMP table CISCO-FLASH-MIB::ciscoFlashCopyTable, part 2
index SourceName DestinationName RemoteUserName
23 c870-advsecurityk9-mz.124-24.T4.bin
SNMP table CISCO-FLASH-MIB::ciscoFlashCopyTable, part 3
index Status NotifyOnCompletion Time EntryStatus Verify
23 copyOperationSuccess false 0:0:05:03.71 active false
SNMP table CISCO-FLASH-MIB::ciscoFlashCopyTable, part 4
index ServerAddrType ServerAddrRev1 RemotePassword
23 ipv4 "192.0.2.1" ? |
With the new image uploaded it’s time for the coup de grâce, reloading the device:
# snmpset -v 3 -l authPriv -a MD5 -A authsecret -x DES -X privsecret -u myuser 192.0.2.254 \ tsMsgSend.0 i reload OLD-CISCO-TS-MIB::tsMsgSend.0 = INTEGER: reload(2) |
Your device should now reboot and after a short while come back up running the updated IOS image. You can confirm the source of the reboot request with the following:
router#show version | i reason Last reload reason: snmp shutdown request |
Powerful stuff. Needless to say, don’t make this accessible to the world with an SNMPv2 community of “private”.
[…] http://bodgitandscarper.co.uk/networks/using-snmp-to-upgrade-ios-on-cisco-devices/ […]