I've been tasked with ensuring our IOS versions are at "acceptable levels", the boss wants me to try and have every switch and router at the same level. Now forgetting memory and flash requirements have any of you done the same? Or do you employ a different strategy to upgrading IOS versions oin your environment? do you tier them depending on where they are physically located and what security level (Internet accessable, office switch located behind 10 other switches) or hardware type (3640, 3560, 2950)? Or do you just stick to GD deployments only? Or a combination of alll three?
It is good practice to run the same version of code as much as possible. It makes it easier to see which groups of devices need to be upgraded when a CERT is announced.
In our organization, we have well over 3000 Cisco devices and each family of hardware has a "minimum" version and a "recommended" version. The minimum version is the version that does not have any outstanding bugs or security vulnerabilities for the features that we use, and the recommended version is the version that is deployed on replaced or new installs. With the number of devices we have, upgrading to a new version is a huge investment in time and effort. I can't tell you how many times we have upgraded due to a CERT and before we are finished deploying it another CERT is announce and we have had to upgrade again.
We NEVER EVER EVER run "T" code unless we absolutely need it because of hardware or feature requirements. The following hardware models are families that we run the same version of code (but compiled for each different platforms)
3750's and 3560's switches
2924's, 3500's and 3550's switches
2800's and 3800's series routers
2600's, 3600's and 3700 series routers.
7200 series routers are a class by themselves, as are 6500's
Each family runs a version of code that is necessary for the features it needs. Our 2800's and 3800's that are deployed with VoIP run 12.4.17T code because we need SRST features only available in "T" code. 2800's and 3800's that don't need voice run 12.4.18. We do this because "T" code is only run where we MUST have it.
The minimum and recommended versions are not changed unless we need to. This is usually because of bug, a CERT or a new feature. We have some 1721 routers that still run 12.1 code.
Upgrading IOS versions can be hazardous to you health due to the number of bugs in IOS versions these days The rate at which Cisco yanks release will make this a challenge..
So do you homework on each target release by going thru release notes throughly to check for bugs that may be triggered in your environment.
Having a standard release per platform is probably not a bad idea; the problem will be finding a stable release to use.
and finally - if you expect to keep up with new releases - make sure you have plenty of spare RAM & flash
IOS just keeps getting bigger - but if you want to do "safe" upgrades with roll back if there are problems, then you should think about enough flash to keep 2 versions locally on the router (or 2 flash cards where you can - 6500s have slots for 3 cards now on Sup
720s, but someone nicked one recently - must have thought it would work in his camera or something.....)
>
thanks for your very detailed response. You said "The minimum version is the version that does not have any outstanding bugs or security vulnerabilities for the features that we use". How do I determine if any of the features we use has vunerabilities and if they affect us?
Also what is the difference between T releases and mainline?
thanks Merv and Stephen for your responses
In order to keeep my boss happy is there anyone else out there doing something else re policies?
IOS T train is the IOS software stream into which Cisco introduces new technology - new hardware and new software features
see also White Paper: Cisco IOS Reference Guide
formatting link
Once you decide on target IOS versions for all of your Cisco platforms you might want to post it for feedback
Be careful about picking the latest release of any IOS version.
Look at the release dates on the IOS software download page - the longer a release has been around ( and not "deferred") then the better the chance bugs have been detected and hopefully fixed.
Each version of IOS has a set of release notes that lists all known bugs, and the bug fixes in that release of code. This is one of the reasons we don't upgrade that often is because it is a very tedious process to go through all the release notes. CERT and security bugs can be found at
formatting link
Once we find a candidate code release, we first load it on a test router in our lab for a few days or weeks depending on how big of a change from the prior release. We then roll it out in a controlled release, running it on a few production routers, again for a few days or a few weeks before starting a rollout everywhere. For example, upgrading from 12.4.12 to 12.4.15 is probably only a few days in the lab and production testing, but 12.3.12 to
12.4.12 would probably be a few weeks. We then do a production rollout, starting with a small number, waiting a bit of time, and then the next group, with each group getting bigger, and less time between groups. This is done because it is possible that you can find weird or intermittent bugs that don't always see on every device. If we do find a bug, we want to find it before we roll it out everywhere.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.