IOS Upgrading "Policy"

Discussion in 'Cisco' started by dhodgson7@gmail.com, Nov 21, 2007.

  1. Guest

    Hi folks,

    I've been tasked with ensuring our IOS versions are at "acceptable
    levels", the boss wants me to try and have every switch and router at
    the same level. Now forgetting memory and flash requirements have any
    of you done the same? Or do you employ a different strategy to
    upgrading IOS versions oin your environment? do you tier them
    depending on where they are physically located and what security level
    (Internet accessable, office switch located behind 10 other switches)
    or hardware type (3640, 3560, 2950)? Or do you just stick to GD
    deployments only? Or a combination of alll three?

    Any help from anyone would be a great help to me.

    many thanks
    Dave
    , Nov 21, 2007
    #1
    1. Advertising

  2. Thrill5 Guest

    It is good practice to run the same version of code as much as possible. It
    makes it easier to see which groups of devices need to be upgraded when a
    CERT is announced.

    In our organization, we have well over 3000 Cisco devices and each family of
    hardware has a "minimum" version and a "recommended" version. The minimum
    version is the version that does not have any outstanding bugs or security
    vulnerabilities for the features that we use, and the recommended version is
    the version that is deployed on replaced or new installs. With the number
    of devices we have, upgrading to a new version is a huge investment in time
    and effort. I can't tell you how many times we have upgraded due to a CERT
    and before we are finished deploying it another CERT is announce and we have
    had to upgrade again.

    We NEVER EVER EVER run "T" code unless we absolutely need it because of
    hardware or feature requirements. The following hardware models are
    families that we run the same version of code (but compiled for each
    different platforms)
    3750's and 3560's switches
    2924's, 3500's and 3550's switches
    2800's and 3800's series routers
    2600's, 3600's and 3700 series routers.

    7200 series routers are a class by themselves, as are 6500's

    Each family runs a version of code that is necessary for the features it
    needs. Our 2800's and 3800's that are deployed with VoIP run 12.4.17T code
    because we need SRST features only available in "T" code. 2800's and 3800's
    that don't need voice run 12.4.18. We do this because "T" code is only run
    where we MUST have it.

    The minimum and recommended versions are not changed unless we need to.
    This is usually because of bug, a CERT or a new feature. We have some 1721
    routers that still run 12.1 code.

    <> wrote in message
    news:...
    > Hi folks,
    >
    > I've been tasked with ensuring our IOS versions are at "acceptable
    > levels", the boss wants me to try and have every switch and router at
    > the same level. Now forgetting memory and flash requirements have any
    > of you done the same? Or do you employ a different strategy to
    > upgrading IOS versions oin your environment? do you tier them
    > depending on where they are physically located and what security level
    > (Internet accessable, office switch located behind 10 other switches)
    > or hardware type (3640, 3560, 2950)? Or do you just stick to GD
    > deployments only? Or a combination of alll three?
    >
    > Any help from anyone would be a great help to me.
    >
    > many thanks
    > Dave
    Thrill5, Nov 21, 2007
    #2
    1. Advertising

  3. Merv Guest

    On Nov 21, 1:32 am, "Thrill5" <> wrote:
    > It is good practice to run the same version of code as much as possible. It
    > makes it easier to see which groups of devices need to be upgraded when a
    > CERT is announced.
    >
    > In our organization, we have well over 3000 Cisco devices and each family of
    > hardware has a "minimum" version and a "recommended" version. The minimum
    > version is the version that does not have any outstanding bugs or security
    > vulnerabilities for the features that we use, and the recommended version is
    > the version that is deployed on replaced or new installs. With the number
    > of devices we have, upgrading to a new version is a huge investment in time
    > and effort. I can't tell you how many times we have upgraded due to a CERT
    > and before we are finished deploying it another CERT is announce and we have
    > had to upgrade again.
    >
    > We NEVER EVER EVER run "T" code unless we absolutely need it because of
    > hardware or feature requirements. The following hardware models are
    > families that we run the same version of code (but compiled for each
    > different platforms)
    > 3750's and 3560's switches
    > 2924's, 3500's and 3550's switches
    > 2800's and 3800's series routers
    > 2600's, 3600's and 3700 series routers.
    >
    > 7200 series routers are a class by themselves, as are 6500's
    >
    > Each family runs a version of code that is necessary for the features it
    > needs. Our 2800's and 3800's that are deployed with VoIP run 12.4.17T code
    > because we need SRST features only available in "T" code. 2800's and 3800's
    > that don't need voice run 12.4.18. We do this because "T" code is only run
    > where we MUST have it.
    >
    > The minimum and recommended versions are not changed unless we need to.
    > This is usually because of bug, a CERT or a new feature. We have some 1721
    > routers that still run 12.1 code.
    >
    > <> wrote in message
    >
    > news:...
    >
    > > Hi folks,

    >
    > > I've been tasked with ensuring our IOS versions are at "acceptable
    > > levels", the boss wants me to try and have every switch and router at
    > > the same level. Now forgetting memory and flash requirements have any
    > > of you done the same? Or do you employ a different strategy to
    > > upgrading IOS versions oin your environment? do you tier them
    > > depending on where they are physically located and what security level
    > > (Internet accessable, office switch located behind 10 other switches)
    > > or hardware type (3640, 3560, 2950)? Or do you just stick to GD
    > > deployments only? Or a combination of alll three?

    >
    > > Any help from anyone would be a great help to me.

    >
    > > many thanks
    > > Dave



    Upgrading IOS versions can be hazardous to you health due to the
    number of bugs in IOS versions these days
    The rate at which Cisco yanks release will make this a challenge..

    So do you homework on each target release by going thru release notes
    throughly to check for bugs that may be triggered in your environment.

    Having a standard release per platform is probably not a bad idea; the
    problem will be finding a stable release to use.
    Merv, Nov 21, 2007
    #3
  4. stephen Guest

    "Merv" <> wrote in message
    news:...
    > On Nov 21, 1:32 am, "Thrill5" <> wrote:
    > > It is good practice to run the same version of code as much as possible.

    It
    > > makes it easier to see which groups of devices need to be upgraded when

    a
    > > CERT is announced.
    > >
    > > In our organization, we have well over 3000 Cisco devices and each

    family of
    > > hardware has a "minimum" version and a "recommended" version. The

    minimum
    > > version is the version that does not have any outstanding bugs or

    security
    > > vulnerabilities for the features that we use, and the recommended

    version is
    > > the version that is deployed on replaced or new installs. With the

    number
    > > of devices we have, upgrading to a new version is a huge investment in

    time
    > > and effort. I can't tell you how many times we have upgraded due to a

    CERT
    > > and before we are finished deploying it another CERT is announce and we

    have
    > > had to upgrade again.
    > >
    > > We NEVER EVER EVER run "T" code unless we absolutely need it because of
    > > hardware or feature requirements. The following hardware models are
    > > families that we run the same version of code (but compiled for each
    > > different platforms)
    > > 3750's and 3560's switches
    > > 2924's, 3500's and 3550's switches
    > > 2800's and 3800's series routers
    > > 2600's, 3600's and 3700 series routers.
    > >
    > > 7200 series routers are a class by themselves, as are 6500's
    > >
    > > Each family runs a version of code that is necessary for the features it
    > > needs. Our 2800's and 3800's that are deployed with VoIP run 12.4.17T

    code
    > > because we need SRST features only available in "T" code. 2800's and

    3800's
    > > that don't need voice run 12.4.18. We do this because "T" code is only

    run
    > > where we MUST have it.
    > >
    > > The minimum and recommended versions are not changed unless we need to.
    > > This is usually because of bug, a CERT or a new feature. We have some

    1721
    > > routers that still run 12.1 code.
    > >
    > > <> wrote in message
    > >
    > > news:...
    > >
    > > > Hi folks,

    > >
    > > > I've been tasked with ensuring our IOS versions are at "acceptable
    > > > levels", the boss wants me to try and have every switch and router at
    > > > the same level. Now forgetting memory and flash requirements have any
    > > > of you done the same? Or do you employ a different strategy to
    > > > upgrading IOS versions oin your environment? do you tier them
    > > > depending on where they are physically located and what security level
    > > > (Internet accessable, office switch located behind 10 other switches)
    > > > or hardware type (3640, 3560, 2950)? Or do you just stick to GD
    > > > deployments only? Or a combination of alll three?

    > >
    > > > Any help from anyone would be a great help to me.

    > >
    > > > many thanks
    > > > Dave

    >
    >
    > Upgrading IOS versions can be hazardous to you health due to the
    > number of bugs in IOS versions these days
    > The rate at which Cisco yanks release will make this a challenge..
    >
    > So do you homework on each target release by going thru release notes
    > throughly to check for bugs that may be triggered in your environment.
    >
    > Having a standard release per platform is probably not a bad idea; the
    > problem will be finding a stable release to use.


    and finally - if you expect to keep up with new releases - make sure you
    have plenty of spare RAM & flash

    IOS just keeps getting bigger - but if you want to do "safe" upgrades with
    roll back if there are problems, then you should think about enough flash to
    keep 2 versions locally on the router
    (or 2 flash cards where you can - 6500s have slots for 3 cards now on Sup
    720s, but someone nicked one recently - must have thought it would work in
    his camera or something.....)
    >

    --
    Regards

    - replace xyz with ntl
    stephen, Nov 21, 2007
    #4
  5. Guest

    On Nov 21, 2:32 pm, "Thrill5" <> wrote:
    > It is good practice to run the same version of code as much as possible. It
    > makes it easier to see which groups of devices need to be upgraded when a
    > CERT is announced.
    >
    > In our organization, we have well over 3000 Cisco devices and each family of
    > hardware has a "minimum" version and a "recommended" version. The minimum
    > version is the version that does not have any outstanding bugs or security
    > vulnerabilities for the features that we use, and the recommended version is
    > the version that is deployed on replaced or new installs. With the number
    > of devices we have, upgrading to a new version is a huge investment in time
    > and effort. I can't tell you how many times we have upgraded due to a CERT
    > and before we are finished deploying it another CERT is announce and we have
    > had to upgrade again.
    >
    > We NEVER EVER EVER run "T" code unless we absolutely need it because of
    > hardware or feature requirements. The following hardware models are
    > families that we run the same version of code (but compiled for each
    > different platforms)
    > 3750's and 3560's switches
    > 2924's, 3500's and 3550's switches
    > 2800's and 3800's series routers
    > 2600's, 3600's and 3700 series routers.
    >
    > 7200 series routers are a class by themselves, as are 6500's
    >
    > Each family runs a version of code that is necessary for the features it
    > needs. Our 2800's and 3800's that are deployed with VoIP run 12.4.17T code
    > because we need SRST features only available in "T" code. 2800's and 3800's
    > that don't need voice run 12.4.18. We do this because "T" code is only run
    > where we MUST have it.
    >
    > The minimum and recommended versions are not changed unless we need to.
    > This is usually because of bug, a CERT or a new feature. We have some 1721
    > routers that still run 12.1 code.
    >
    > <> wrote in message
    >
    > news:...
    >
    > > Hi folks,

    >
    > > I've been tasked with ensuring our IOS versions are at "acceptable
    > > levels", the boss wants me to try and have every switch and router at
    > > the same level. Now forgetting memory and flash requirements have any
    > > of you done the same? Or do you employ a different strategy to
    > > upgrading IOS versions oin your environment? do you tier them
    > > depending on where they are physically located and what security level
    > > (Internet accessable, office switch located behind 10 other switches)
    > > or hardware type (3640, 3560, 2950)? Or do you just stick to GD
    > > deployments only? Or a combination of alll three?

    >
    > > Any help from anyone would be a great help to me.

    >
    > > many thanks
    > > Dave


    Hi Thrill5,

    thanks for your very detailed response. You said "The minimum
    version is the version that does not have any outstanding bugs or
    security
    vulnerabilities for the features that we use". How do I determine if
    any of the features we use has vunerabilities and if they affect us?

    Also what is the difference between T releases and mainline?

    thanks Merv and Stephen for your responses

    In order to keeep my boss happy is there anyone else out there doing
    something else re policies?

    thanks
    Dave
    , Nov 22, 2007
    #5
  6. Merv Guest


    > Also what is the difference between T releases and mainline?



    IOS T train is the IOS software stream into which Cisco introduces new
    technology - new hardware and new software features

    see also White Paper: Cisco IOS Reference Guide

    http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a008018305e.shtml


    Once you decide on target IOS versions for all of your Cisco
    platforms
    you might want to post it for feedback

    Be careful about picking the latest release of any IOS version.

    Look at the release dates on the IOS software download page -
    the longer a release has been around ( and not "deferred")
    then the better the chance bugs have been detected and hopefully
    fixed.
    Merv, Nov 22, 2007
    #6
  7. Thrill5 Guest

    "Merv" <> wrote in message
    news:...
    >
    >> Also what is the difference between T releases and mainline?

    >
    >
    > IOS T train is the IOS software stream into which Cisco introduces new
    > technology - new hardware and new software features
    >
    > see also White Paper: Cisco IOS Reference Guide
    >
    > http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a008018305e.shtml
    >
    >
    > Once you decide on target IOS versions for all of your Cisco
    > platforms
    > you might want to post it for feedback
    >
    > Be careful about picking the latest release of any IOS version.
    >
    > Look at the release dates on the IOS software download page -
    > the longer a release has been around ( and not "deferred")
    > then the better the chance bugs have been detected and hopefully
    > fixed.
    >
    >

    Each version of IOS has a set of release notes that lists all known bugs,
    and the bug fixes in that release of code. This is one of the reasons we
    don't upgrade that often is because it is a very tedious process to go
    through all the release notes. CERT and security bugs can be found at
    http://tools.cisco.com/security/center/home.x

    Once we find a candidate code release, we first load it on a test router in
    our lab for a few days or weeks depending on how big of a change from the
    prior release. We then roll it out in a controlled release, running it on a
    few production routers, again for a few days or a few weeks before starting
    a rollout everywhere. For example, upgrading from 12.4.12 to 12.4.15 is
    probably only a few days in the lab and production testing, but 12.3.12 to
    12.4.12 would probably be a few weeks. We then do a production rollout,
    starting with a small number, waiting a bit of time, and then the next
    group, with each group getting bigger, and less time between groups. This
    is done because it is possible that you can find weird or intermittent bugs
    that don't always see on every device. If we do find a bug, we want to find
    it before we roll it out everywhere.
    Thrill5, Nov 23, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tyler Cobb
    Replies:
    6
    Views:
    18,590
    Tyler Cobb
    Oct 19, 2005
  2. Mike Rahl
    Replies:
    1
    Views:
    1,234
    Trendkill
    May 30, 2007
  3. Al
    Replies:
    2
    Views:
    1,709
  4. Tyler Cobb
    Replies:
    1
    Views:
    722
    dawnad
    Oct 9, 2005
  5. Geoffrey Sinclair

    Policy map using policy map

    Geoffrey Sinclair, Jul 27, 2009, in forum: Cisco
    Replies:
    1
    Views:
    522
    bod43
    Jul 27, 2009
Loading...

Share This Page