Advertisement

Powered by Squarespace
Popular Categories
Blog Posts
Discussion Activity
Cisco Live 365
« Cisco 'ip helper-address' and Windows DHCP Servers | Main | Cisco Embedded Event Manager (EEM) Config Diff Generator »
Tuesday
Jun042013

What factors drive a Cisco IOS upgrade?

In order of preference/priority, what factors do you consider in driving an upgrade (or downgrade) with Cisco IOS? If no compelling factors exist, how long would you allow a particular version of IOS to stay running? I’ve seen some switches with uptimes > 5 years.  And when upgrading, how is the specific IOS release identified as the upgrade target?

In order of preference/priority, best practice tends to dictate an upgrade based on these factors:

  • Vulnerabilities, vulnerabilities, vulnerabilities!
  • Bugs
  • Attaining new features not currently available— new cards/modules have a “first supported in” IOS version which could be higher than what you have running
  • Migrating away from retired release trains
  • Matching versions on more recently deployed and similar hardware

A device that is very critical to the infrastructure may not be as aggressively upgraded as one that is less critical. Consideration is given to the role of the device, the redundancy surrounding it, and the impact of the upgrade itself by the downtime incurred or by the possibility of having config feature behavior changes or different defaults when going between major versions. This is the necessity question that also touches on soft costs such as the time and resources to accomplish the upgrades measured against the weight given to each of the factors such as vulnerabilities.

A downgrade might be in order if:

  • Organization has a policy to only run tested/QA’d versions and new equipment came with a more recent release.
  • Org has a policy against running anything other than a GD (General Deployment).

In choosing the right target version for an upgrade,

  • Use Cisco’s Output Interpreter of “show version” to look for obvious issues/vulnerabilities/bugs.
  • Look for GD (General Deployment) releases and avoid DF (Deferred).
  • Use ED (Early Deployment) only when it contains must-have features not available elsewhere.
  • Avoid LD (Limited Deployment) when possible and use GD instead.

There are certainly arguments for going to an ED or LD version, but the desire, of course, is to get to the most stable version that meets requirements.

Question originally posed and self-answered on networkengineering.stackexchange.com.

20130604.1

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Textile formatting is allowed.