On Friday, February 17, 2012 06:08:00 AM Justin M. Streiner wrote: > I would also add "vendor-mandated obsolescence" to that > list. Cisco sunsets software in much the same way they > sunset hardware. They will make an end-of-life > announcement for software version XYZ, stating the dates > that engineering releases will stop, and the date that > TAC support will cease. In some environments, running > supportable code is less of an issue, but our > environment pretty much requires that we be in a > position to ask for vendor support if we determine we > need it, which puts some burden on us to remain > 'supportable'.
In my experience, it's always been the case that by the time code is EoL, we've likely already moved on, as we've been hit by a couple of bugs that have forced us to move anyway. That said, I understand that simpler environments may not find themselves in a similar position, and could end up running EoL code for much longer, even though it's riddled with known bugs. Upgrading IOS and IOS XE is easy. Upgrading IOS XR is a pain. Even more painful than upgrading Junos. So one might also consider "pain" vs. "benefit". > When we need to :) Well, I know one or two CCIE's who once advised a CEO that all routers must be rebooted once a year, as a standard, even though there was no technical reason to do so. That it was good business, and helped to get rid of the "dust" that had formed over time :-). 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/
