[c-nsp] When do you upgrade IOS?

[Mark Tinka]

On Friday, February 17, 2012 05:55:09 AM Alan Buxey wrote:

> new features + bug fixes. keeping the firmware up to date
> should be part of the planning process - whatever
> network mgmt method you follow (FCAPS, ITIL, TMN, etc)
> upgrading should be part of planned actions - or one day
> you find your whole estate running very old.

If your policy, like ours, is to run the same release for 
the same hardware across the entire network, if for nothing 
else but consistency, then there is a lot of thinking to do 
before one decides to "keep code current".

> one
> advantage of keeping up to date is you read the release
> notes...and see things that make you think 'oooh! thas a
> cool feature'...and 'ooh! thats a bug that would hit us,
> glad we havent had that YET'  ;-)

We do this anyway, even though we won't be deploying that 
release. So we always know feature availability even though 
we're not running the code that has it.

> upgrades are done during advertised/known 'network at
> risk' period, this is early on a weekday morning before
> business hours/core hours.  we also found that buy
> keeping the IOS reasonably up to date...whenever another
> team has come to us asking for requirement/feature our
> switches tend to already have that available - eg
> energywise or LLDP

Again, a big challenge here is if you have a very large 
network, and your policy is to run the same release on all 
your boxes.

I know networks that are in constant upgrades, because 
they'll start working on boxes this month, and by the time 
they're done, several months later, they start again from 
the first to deploy the latest code. Of course, not having 
to do this means you'll end up running boxes with different 
releases, which may or may not be one's cup of tea.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20120219/4197e4ae/attachment.sig>