cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
443
Views
0
Helpful
2
Replies

IOS and ISE 2.3 - validated code for switches

MS-JK
Level 1
Level 1

Trying to select best image for switches in ISE 2.3 deployment. Looking at the validated / stable IOS selection document for ISE 2.3 and checking out the minimum AND validated code levels. SOME of these 'validated and tested' images are OLD all the way to early 2017. 

 

What is the recommendation? Go with the VALIDATED code level OR with LATEST STABLE for the switch model recommended in the software download section.

 

Compatibility doc: https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/compatibility/ise_sdt.html

 

Thanks for feedback!

2 Accepted Solutions

Accepted Solutions

Damien Miller
VIP Alumni
VIP Alumni

I like to take a hybrid approach to this following some basic high level steps. I've found that software validation is highly dependent on both the enterprise and ISE feature sets required.  Sometimes one causes a problem with the other. One environment will have no issues, while the other environment has one extra feature in use that combines to hit a bug. 

 

  1. Evaluate the minimum supported release for the feature set and platform. This usually takes in to account the ISE validated code you linked and possibly the TrustSec matrix if the project requires CTS features.
  2. Look at the Cisco software download page to see what the recommended "gold star" release is. If it is newer than the minimum feature set release, and also newer than the "validated", then it becomes a likely testing candidate. 
  3. Bug scrub the release notes (sometimes also bug tracker) to see if there is anything open of possibly fixed in version newer than the gold star.
  4. Pilot and test functionality, this usually begins in a lab if spare hardware is available, otherwise it becomes a production pilot.

View solution in original post

to follow on with what Damian said, my 2c worth is that Cisco's efforts to improve the stability within a release tend to increase with later patch releases.  It's a linear progression.  Unless of course you get unlucky and they break something that used to work - we've all been there and experienced that.  But in general, the code is like a good wine ... it gets better with age :-) 

I don't place any value on release notes.  I read them (with a glass of wine in one hand) and have a good laugh at the bug descriptions, and imagining the horror stories that went into those TAC cases.  However, if you are one of those victims, and you are tracking a bug that is supposedly fixed in a patch release, then of course you'll have a compelling reason to go with said patch release. 

Nothing ever changes - the old mantra of test, test, test seems to be the only thing that I can think of.  And that is a sad state of affairs that we have to test something that comes from a vendor.  We just accept it as "normal".  It's anything but normal. 

 

Attention to details and software quality assurance is not what it could be. 

View solution in original post

2 Replies 2

Damien Miller
VIP Alumni
VIP Alumni

I like to take a hybrid approach to this following some basic high level steps. I've found that software validation is highly dependent on both the enterprise and ISE feature sets required.  Sometimes one causes a problem with the other. One environment will have no issues, while the other environment has one extra feature in use that combines to hit a bug. 

 

  1. Evaluate the minimum supported release for the feature set and platform. This usually takes in to account the ISE validated code you linked and possibly the TrustSec matrix if the project requires CTS features.
  2. Look at the Cisco software download page to see what the recommended "gold star" release is. If it is newer than the minimum feature set release, and also newer than the "validated", then it becomes a likely testing candidate. 
  3. Bug scrub the release notes (sometimes also bug tracker) to see if there is anything open of possibly fixed in version newer than the gold star.
  4. Pilot and test functionality, this usually begins in a lab if spare hardware is available, otherwise it becomes a production pilot.

to follow on with what Damian said, my 2c worth is that Cisco's efforts to improve the stability within a release tend to increase with later patch releases.  It's a linear progression.  Unless of course you get unlucky and they break something that used to work - we've all been there and experienced that.  But in general, the code is like a good wine ... it gets better with age :-) 

I don't place any value on release notes.  I read them (with a glass of wine in one hand) and have a good laugh at the bug descriptions, and imagining the horror stories that went into those TAC cases.  However, if you are one of those victims, and you are tracking a bug that is supposedly fixed in a patch release, then of course you'll have a compelling reason to go with said patch release. 

Nothing ever changes - the old mantra of test, test, test seems to be the only thing that I can think of.  And that is a sad state of affairs that we have to test something that comes from a vendor.  We just accept it as "normal".  It's anything but normal. 

 

Attention to details and software quality assurance is not what it could be.