Hi,
We currently have two nodes with ISE 3.1 p7 in productive use for AnyConnect posturing and wired/wireless 802.1x authentication.
For testing and preparing future updates I created an empty, nonproductive test setup using same OVA template and installed patch bundle to be on the same software level than production:
- ISE-3.1.0.518b-virtual-SNS3615-SNS3655-600.ova
- ise-patchbundle-3.1.0.518-Patch7-23052004.SPA.x86_64.tar.gz
From there I tested the upgrade to ISE 3.2 p4 by first running the upgrade readyness tool and then applied the upgrade bundle and patch bundle in the same via web ui wizard:
- ise-upgradebundle-2.7.x-3.1.x-to-3.2.0.542b.SPA.x86_64.tar.gz
- ise-patchbundle-3.2.0.542-Patch4-23101514.SPA.x86_64.tar.gz
The whole upgrade took about 3 hours !!! Server hardware is a UCSB-B200-M3 blade and storage is Netapp A400 all-flash system. The VM has 16 CPU cores and 32 GB RAM. That made me to reconsider our upgrade plans - especially remembering what trouble we had in the past with this software. Instead of making software simpler, faster and more stable, Cisco added now Grafana and Kibana and made the software even more diverse and complex.
However, new day, new motivation, I was curious to peek into ISE 3.3. I downloaded the ISE 3.3 patch upgrade and patch bundle and tried to upgrade from ISE 3.2 p4 to ISE 3.3 p1:
- ise-upgradebundle-3.0.x-3.2.x-to-3.3.0.430a.SPA.x86_64.tar.gz
- ise-patchbundle-3.3.0.430-Patch1-23120402.SPA.x86_64.tar.gz
But I got disappointed when the configuration data upgrade check failed with a fresh and empty ISE that was running for less than a day. The configdb-upgrade.log does not give a hint why it is failing.
adnise01-test/admin#show logging application configdb-upgrade-20231212-075637.log
[...]
Tue Dec 12 08:16:59 UTC 2023 : Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Tue Dec 12 08:17:00 UTC 2023 : Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Tue Dec 12 08:17:00 UTC 2023 : Processing object type SCHEMA_EXPORT/TABLE/IDENTITY_COLUMN
Tue Dec 12 08:17:01 UTC 2023 : Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Tue Dec 12 08:17:23 UTC 2023 : Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_INDEX/INDEX
Tue Dec 12 08:17:25 UTC 2023 : Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Tue Dec 12 08:17:48 UTC 2023 : Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Tue Dec 12 08:18:06 UTC 2023 : Job "CEPM"."SYS_IMPORT_SCHEMA_01" successfully completed at Tue Dec 12 08:18:03 2023 elapsed 0 00:03:50
Tue Dec 12 08:18:06 UTC 2023 :
Tue Dec 12 08:18:06 UTC 2023 : Changing host config entry to standalone...
Tue Dec 12 08:18:06 UTC 2023 : ORACLE_SID : cpm11
Tue Dec 12 08:18:06 UTC 2023 : NODECNT :
Tue Dec 12 08:18:06 UTC 2023 : - Successful
Tue Dec 12 08:18:06 UTC 2023 : - Successful
Tue Dec 12 08:18:06 UTC 2023 :
Tue Dec 12 08:18:06 UTC 2023 : runDBClone method finished executing
Tue Dec 12 08:18:06 UTC 2023 : triggerUpgradeOnClonedInstance method started executing
Tue Dec 12 08:18:09 UTC 2023 : Modifying upgrade scripts to run on cloned database
Tue Dec 12 08:18:11 UTC 2023 : - Successful
Tue Dec 12 08:19:16 UTC 2023 :
Tue Dec 12 08:19:16 UTC 2023 : Running schema upgrade on cloned database
Tue Dec 12 08:27:08 UTC 2023 : - Failed
Tue Dec 12 08:27:08 UTC 2023 : ConfigDBUpgrade : Performing Clean-up
Tue Dec 12 08:27:32 UTC 2023 : copying back the scripts
Tue Dec 12 08:27:32 UTC 2023 : removing the directory
Tue Dec 12 08:27:32 UTC 2023 : ConfigDBUpgrade : Clean-up Completed
Is it just me getting frustrated by increasing software complexity and decreasing quality or are others facing the same problems?
Three hours upgrade time per node on decent fast hardware and storage. How are others doing that with a much bigger multinode environment?
Regards,
Bernd
