You have a lot of switches and routers, more than you care to count. The IOS in each of them is now old and needs updating. You’re not looking forward to handling each one with a manual process. What are your options? Well, if you did five of them a day, you could do 25 per week. Ten a day would double that volume. Garnering support from a couple of team mates could get you to 75 to 150 per week. Even still, doing the upgrades is a painful process.
How do we make the task less painful? A good way to tackle something big is to decompose it into a set of smaller problems that can be independently tackled. If you have 500 network devices and a three-tier design, you may find that you still have about 200 edge switches of the same model, perhaps even with different IOS versions loaded. Here, you may need to inventory which devices have a given IOS version. NetMRI produces a useful inventory in that it shows the device models and the list of IOS versions running on all devices of that model. Other products have similar inventory reports. Using one of these reports, you can decide which devices to upgrade first. But that doesn’t remove the need to automate the upgrade process. Of course, having a standard network design for different classes of device makes it much easier to plan and implement your upgrades.
Automating the IOS upgrade process isn’t simple. There are a number of critical factors that should be taken into account.
- Is there enough flash memory for the upgrade?
- Can the new IOS fit into free space in flash, or must you delete the old version first?
- If there isn’t enough free memory and more than one IOS version is in flash, which version in flash should be deleted? Delete the oldest one, or the one that’s not being used? We’ve seen situations in which the oldest version in flash was the active running version. If you delete one of the two, is there then sufficient free memory in flash? Or should you make everything consistent and remove all IOS versions from flash and install the new version, giving you a consistent installation across all devices?
- Save the old IOS version prior to deleting it from flash, if you don’t already have a copy, in case you need to do a roll-back to the prior version.
- Save the current configuration to enable a roll-back. This is important for those upgrades in which the configuration will be re-written by the new IOS.
- Do a few ‘show’ commands to capture the state of key functions within the device, such as HSRP, routing protocols, number of routes, STP state, STP root bridge.
- Do the upgrade.
- Save the upgraded configuration.
- Execute the same ‘show’ commands as above and compare the results, identifying any devices that have not resumed the correct operational state.
Doing this much planning and preparation takes time. Fortunately, a lot of the preparation can be applied to multiple device classes.
The flexibility of doing all of the above functions dictates the need for a scripting tool like the one built into NetMRI. At CiscoLive, one of the Infoblox SEs told me that he was working on a script to help a customer do IOS upgrades on a large switched infrastructure. By incrementally testing the upgrade script on one device, then a few devices, then applying it across the network, it is not difficult to make sure that it works reliably. The result is a tool that saves a lot of customer time, employee stress, and implements the upgrades much faster than would be possible using manual methods.
How does this benefit the business? Automating IOS upgrades makes it easier to deploy new IOS features. An agile business is one that is leading its competition. Studies have found that the leading companies typically have a commanding lead over the other businesses in its category, so anything a business can do to be more agile than its competitors is beneficial to that business.
-Terry
_____________________________________________________________________________________________
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html
