10-17-2018 08:41 PM
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!
Solved! Go to Solution.
10-17-2018 08:52 PM
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.
10-18-2018 05:32 AM
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.
10-17-2018 08:52 PM
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.
10-18-2018 05:32 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide