Migrate ISE from 2.4 to 3.1

Recently there have been many requests to upgrade Cisco ISE to 3.x. I usually recommend 3.1, because Cisco recommends that too. I recently supported a customer with an upgrade from 2.4 to 3.1, so I thought I could share my experience. I am also about to write a blog about upgrading ISE from 2.7 to 3.1, so see this as a prelude to what’s next. Maybe some of these things might be relevant for that as well.

Step 1: Upgrade from 2.4 to 3.0 and import configuration

Cisco Release Notes says that you have to have minimum ISE 2.6 to upgrade directly to 3.1. Therefore, you first either need to upgrade to 2.6, 2.7 or 3.0. If you have an ISE VM, and virtual resources available, you can spin up a fresh install of ISE 3.0 with the latest patch, then migrate to configuration from the ISE 2.4 node. Benefit of that is the quick and easy rollback option. (Just shut down the new 3.1 node and then start the 2.4 node again). The drawback might be that it takes a little longer to perform the upgrade. There is already a good blog on this procedure, so I don’t have to invent the wheel again: https://www.lookingpoint.com/blog/cisco-ise-3.0-major-upgrade

Note: Cisco release nodes doesn’t say if you can import config directly to an ISE 3.1 from a 2.4, Only that an upgrade from 2.4 to 3.1 is not supported. However, I have heard from colleagues that databases can get messed up and create a lot of bugs, so I wouldn’t recommend it.

The ISE Deployment

The customer only had a single virtualized ISE multifunction node. Redundancy is within the virtualization platform. I would still recommend using at least 2 nodes, because performing maintenence work (like upgrading ISE version) without causing too much downtime, becomes very complicated with only one node. If you have 2 nodes, you can mirror the config of the secondary node, while the primary node handles the authentications.

When you import configuration to a one node cluster like this, you might not want to include config like IP addresses, because you will start a conflict with the existing node. There is 2 ways to import config; with, or without ADE-OS config. ADE-OS config is the parameters you enter when setting up a fresh ISE node, like IP, GW, DNS Servers, and NTP.

Importing configuration data:

Importing configuration data with ADE-OS config (initial configuration like IP and DNS):

Caveats Discovered after importing configuration on the new 3.0 node

After the customer migrated the config to the new ISE node, the GUI became inaccessible. The webbrowser said “Oops , something went wrong, access id denied , pls contact your administrator.” It turns out that it was caused by more than just one thing. Apparently the security level in 2.4, was not as great as in later versions.

For a workaround to get to the GUI, start safe mode by running the following commands in CLI:

Caveat #1: Access Restriction suddenly started working

In ISE 2.4, (patch version not known) access restriction was configurable, but did now work. In ISE 3.0, it is working. And for the customers case, it was misconfigured.

Image from https://community.cisco.com/t5/network-access-control/cannot-access-ise-gui/td-p/3220198

Caveat #2: Admin Certificate CN or SAN does not match FQDN

The admin certificates Common Name or SAN=Subject Alternative Name did not match with the FQDN. I’m surprised this was even allowed in 2.4.

Caveat #3: The configured domain name did not match the DNS name

The Customer had a mismatch in the configured DNS name. It was something similar to this:

but should have been:

This is also surprising that it worked fine in 2.4.

Step 2: Upgrade from ISE 3.0 to ISE 3.1

Upgrading from 3.0 latest patch to 3.1 went smoothly. There is only one thing that might hit you if you have IPv6 disabled:

Caveats discovered when upgrading to ISE 3.1

Caveat #1: GUI not reachable if IPv6 is not activated

The customer did not hit this bug because IPv6 was enabled. I just found this out while troubleshooting. If you haven’t patched the ISE 3.1 system, this bug would have been hit if IPv6 wasn’t enabled:

https://bst.cisco.com/bugsearch/bug/CSCwa08018