Whenever doing IOS upgrades on production devices, it is always best to have a fail-back plan. With most platforms, the best way to archieve this is with the ‘boot system’ command and altough not a new command, still good to cover.
The ‘boot system’ command is non-exclusive, and if multiple entries exist, the commands are tried top down. If the first is unsuccessful, the second will be tried. If the first is successful it is loaded. This is very handy, since it provides IOS-image redundancy, and a fail-back option.
What do I mean by IOS-image redundancy?
If you are using a bigger platform that has 2x Compact Flash Slots, by loading the same IOS image on both disks you can have image redundancy, incase one of the Compact Flash Cards bombs out, with the following config:
boot system flash disk0:s72033-adventerprisek9_wan-mz.122-33.SXI2.bin
boot system flash disk1:s72033-adventerprisek9_wan-mz.122-33.SXI2.bin
The same redundancy could be achieved by using a remote FTP/TFTP location as the second command.
.
This command however becomes most useful when doing IOS upgrades. Provided you have enough space to store a second IOS image, load the NEW IOS Image on that same disk, then by using the ‘boot system’ command, specify the path to the NEW IOS Image first and then the path to the current IOS Image:
boot system flash disk0:s72033-adventerprisek9_wan-mz.122-33.SXI2.bin
boot system flash disk0:s72033-adventerprisek9_wan-mz.122-18.SXF6.bin
Now looking at the example above, when the router reboots, the router will try to load 122-33.SXI2 first, if unsuccessful, then it will load the current (122-18.SXF6).