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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
