[c-nsp] When do you upgrade IOS?

Phil Mayers p.mayers at imperial.ac.uk
Fri Feb 17 04:12:22 EST 2012


On 02/16/2012 09:45 PM, Rick Martin wrote:

> 1.    What drives you to upgrade code on critical routers&  switches?

I think this it to an extent site- and platform-dependent. The latter 
particularly so, as the evolution of an IOS train is BU dependent.

Bearing in mind our main platform is 6500/sup720, we have actually 
shifted a bit over time.

Originally, we found a "good" release and stuck with it. In particular, 
we were on the 12.2(18)SXF train, and no/few new features appeared; 
rather than upgrade we were waiting for 12.2(33)SX? (and in particular, 
MPLS NSF and 6vPE).

However, in fairly short order (<12 months) we had a few occasions where 
bugs kicked in that would have been avoided on a pro-active upgrade 
schedule (memory leaks taking a core box down in the middle of the day; 
CEF corruption; etc.)

We then moved to a pro-active upgrade strategy. This has worked well; 
when a new release comes out, we test in the lab, then test on a "quiet" 
router, then roll out to the rest of the network. We aim to finish this 
process within 8 weeks, and keep consistent IOS on a given platform 
within the network.

This process has taken us all the way through to SXJ2 without issues.

A special case is our datacentre network, where overly strict (in my 
opinion) change management means we can only upgrade once or twice a 
year unless a serious bug hits. When those "slots" are approaching, we 
check to ensure there isn't a new IOS we could test/deploy, so that we 
can be "new".

I used to buy into the "if it ain't broke don't fix it" model of 
upgrading IOS, but I'm not sure I do any more - frequently, IOS bugs 
will be announced that were fixed a couple of releases ago, and parties 
who have remained current have nothing to do.

> 2.    Do you upgrade code on a fixed schedule if not driven to by some other immediate requirement?

As above, once code is deployed anywhere, we stage it everywhere and aim 
for <8 weeks to do this.

We generally aim to be <6 months behind a new release, but we don't 
follow that slavishly. If it's buggy crap, we'll skip it.


More information about the cisco-nsp mailing list