ISE Upgrade - best practices

[cisco.13]

Hello,

I prepared 2 ISE VM in v 3.1 + install the last Patch in view of a future upgrade Principal/Secondary.

The two ISE VMs have been prepared with two test IP addresses and hostname (ex. hostname_test.local)

I count :
- Stop the Secondary VM (old employment)
- Modify in CLI the IP address + hostname of the test VM with the IP and hostname of Secondary VM (with the correct IP and hostname) => as indicated by @Arne Bier https://community.cisco.com/t5/network-access-control/easiest-way-to-upgrade-a-two-node-deployment-2-4-to-3-0/m-p/4868298#M582694 Thank you Arne Bier.
- Restore ISE configuration
- Import certificate, join AD, ....
- Stop Primary (old employment)
- Modify in CLI the IP address + hostname of the test VM with the IP and the hostname of the Primary VM (with the correct IP and hostname)
- Join the VM to new deployment
- Promote Primary/Secondary

My question :
Should I remove all certificates with the test hostname? or is importing certificates enough?

Thank you

[Aref Alsouqi]

If you restore from the backup, that should restore the certificates as well.

[Arne Bier · Accepted solution]

Once you have the Deployment up and running, you can delete any System Certificates that are marked as Not Used. That should be the case after you have imported or created new Admin certs and any others (like EAP certs). 

[cisco.13]

Hello,

Thank you for your help @Arne Bier @Aref Alsouqi, the upgrade went well in general,

I encountered this bug: Bug CSCvt14248 => fixed by Cisco

When I "Promote to Primary", all the services on both nodes (Primary/Secondary) have restarted, so all authentication failed, normal? is there a way to circumvent this?

Thank you.

[Aref Alsouqi]

Out of interest, how Cisco TAC fixed that issue reported in the bug?

When you switch the PAN roles it is expected to restart ISE application services, but I don't think the whole nodes would restart. Either way, it is expected not to be able to serve any new authentication requests until the services are fully restarted.

[cisco.13]

Hello,

After taking root, and accessing a directory (CA certificate), he deleted several cert, key files: rm -f xxx, and stop/restart CA service.

I didn't expect the ise app services to restart on both nodes at the same time.

we have two nodes to avoid these problems, not clean

Regards

[Arne Bier]

yep this is normal for a Admin promotion to cause both Admin nodes to restart. Of course, in a distributed deployment (where PSNs are running as separate VMs/Appliances) this is not an issue. But if you only have two nodes doing everything (Admin/Monitoring/Services) then you put all your eggs in one basket. 

Other things that cause spontaneous restarts of the entire deployment (ALL NODES) are things like updating the Admin cert of the Active PAN.  I generally never update the Admin cert of the Active PAN. I would rather promote the Secondary and then update the Admin cert. 

Lastly, when you change things like TLS and SHA versions under the Security menu, it will also restart all nodes at the same time. Perhaps one day they will change this. 

[cisco.13]

Hello @Arne Bier ,

Thank you for this detail, very interesting

I am using EAP-TLS to authenticate clients, increasing the timeout (ex. 2 or 3 days) of EAP TLS Session Resume under:
- Settings > Protocols, and/or
- Policy > Policy Elements > Results > Authentication > Allowed Protocols

The client does not renew its authentication request during the upgrade window or when the services restart on both nodes?

Thanks.

[Arne Bier]

Session Resume is simply an optimisation to reduce the time and effort required to perform a full 802.1X authentication. If a wireless 802.1X supplicant roams from AP to AP, it will cause an 802.1X auth (unless some wireless optimisations are in place - but in general, a roam causes an 802.1X auth event) - to limit the impact on ISE, we enable Session Resume. If you reboot the PSN that the endpoint was registered on, then I believe the next re-auth will be a full one - but I might be wrong - either way, the auth might take a few milliseconds longer than if Session Resume was still active for that endpoint.