ISE 2.7 to 3.2 Migration Questions

[Chris Terry]

I plan on doing the backup and restore method of upgrading to ISE 3.2 from ISE 2.7. My current deployment is 6 VMs, 2 PANs and 4 PSNs.

Questions:
- For the upgrade I know it's required to switch to smart licensing and I'm currently using the traditional licensing. Would I just have the current licenses converted to smart licenses? Would that be done in the background, or would it impact the current deployment?
- In the guide it's required to update the Guest OS to RHEL 8. Would I be able to update the VMs prior to the upgrade maintenance window, or is the Guest OS version updated after the upgrade to 3.2? Would ISE 2.7 be able to run on RHEL 8 until the upgrade window?

[craiglebutt]

Hi Arnie

I've just started the same upgrade from 2.7 to 3.2.  But had to stop, we have several devices that used the Network Setup Assistant tool to onboard, soon as I deregistered and  took down the seconday PAN, these stopped working.

I rolled the change back and put the old PAN back on, but these devices wouldn't join again.  Would this PAN be the CA for the devices when joining?  I got a user to send me a snapshot, the subca is a PSN

[Arne Bier]

Ahhh .. BYOD deployments. When you have to consider the internal ISE CA, then there are additional steps required to safeguard the ISE Internal CA chain. You have to backup all those certs and then re-install them in the new ISE nodes. I don't have personal experience with such a rebuild involving BYOD but I can see this would pose an issue.  

When you took down the Secondary PAN, I would not have expected that existing clients could not connect using EAP, since the NAD (switch/WLC) should be pointing to the remaining ISE node.  Did you bring up the new VM with the same IP address as the old Secondary? If so, then perhaps that would black-hole the traffic, since, if a NAD is trying to talk to that new ISE node, there would be a RADIUS response on UDP/1812, but all Access-Requests would be rejected, since the Policy Set would not contain the logic you require.  In these cases where the PAN is also a PSN, and I am rebuilding it, I tend to change the RADIUS Ports to 10812 (Auth) and 10813 (Acct) so that NAD devices don't get a response from this new node. Don't worry about the port numbers - once the config restore has been done, the ports will be restored to 1812/1813. But it buys you some peace of mind while the node has no Policy Set config. The best approach would be to temporarily disable the IP of the new ISE node from all of your NAD devices, to prevent them from trying to talk to a half-baked ISE node.

[craiglebutt]

hi

I shut the old secondary down, then powered up the new one to build, this is when I got the calls.

No NAD are not pointing to this PAN for authentication, I just use this as a PSN now and then for testing.

Thats the bit that is thowing me off.

Cheers

[hslai]

@craiglebutt If you want to continue using the existing ISE internal CA chain to authenticate the clients, then please ensure the chain is intact, either in the ISE trusted certificates page or ISE internal CA certificates page. If you have re-generated the ISE internal CA chain, then need the old chain imported to ISE trusted certificates page and marked them trusted for client auth. If that does not work, then you might need to re-onboard the clients.

[GERALD LECAILLIER]

Hello,

Just a question, we have 5 nodes: 2 SNS PANs, 3 PSN (1 SNS and 2 VM). We are in 2.7 and go to 3.2

We have two days for downtime (weekend).

Is it better to restore 2.7 conf on new 3.2 as standalone, and then register the other.

Or is it bettre to register all the nodes (2 PAN, 3 PSN) and then restore the 2.7 conf on this deployment ?

Thanks

[Arne Bier]

If I recall correctly, you can’t restore a config from a previous ISE version onto a node that is in Primary mode. You must restore it on a standalone node. Build the deployment after restore and promotion of that PAN to Primary.

[ajc]

I just did that last December, I built a VM with ISE 2.7 patch 7 (standalone mode), restored my production 2.7 config backup into that VM, then installed patch 10 once the config backup restoration was completed and finally upgraded it to ISE 3.2 patch 4 via CLI. (I ran the URT file first before applying the upgrade one).

Once that node was ready, I proceeded to make it Primary PAN, Primary MNT and PSN and ran some testing before adding a 2nd Node to the deployment (now Primary MNT + PSN).

So far 3.2 has 2 issues: FTP as an external repository option does not work anymore no matter what you do. You must now use SFTP. 2nd, the CLI configuration for remote repositories is not synchronized with GUI and it does not work. You have to manually delete and recreate those external repositories on ISE 3.2

I have not seen any other issue, still checking.

[GERALD LECAILLIER]

So you didn't restore a 2.7 backup on 3.2 ise, as you ran the upgrade and URT from 2.7 to 3.2.

[ajc]

correct, I did not restore my 2.7 backup into a fresh installed ISE 3.2. I moved from 2.7 p10 into ISE 3.2 (cli upgrade) but first I ran the URT for ISE 3.2 in that ISE 2.7 p10 VM. Once that URT verification was completed and successful, I upgraded the 2.7 p10 VM.

My upgraded VM is running a pilot in production over a  3 x AP's network.

[Chris Terry]

I'm not sure what bug you might have ran into, but I was able to restore my ISE 2.7 backup straight to ISE 3.2 patch 4. It was new VMs for 3.2. FTP still works as normal for me. I did have to recreate the FTP repositories config via the GUI. Right after the restore the FTP repositories just didn't work and kept giving an error, but deleting them and adding them back fixed it.

[GERALD LECAILLIER]

Hello

In fact you need to promote your fresh ise to Primary, then restore previous version backup, then register the other nodes from your cluster.

https://www.cisco.com/c/en/us/td/docs/security/ise/3-1/upgrade_guide/HTML/b_upgrade_method_3_1.html#id_119620