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.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
