Cisco ISE v2.4 to Cisco ISE on AWS v3.x

[wayne loh]

Hi Guys,

Does anyone has experience on the Cisco ISE v2.4 (On prem - virtual) to Cisco ISE v3.x on AWS? Existing ISE is configured to be 802.1x authentication both wired and wireless. Is there migration tool/steps possible or it has to be new setup and re-configure all the policies and settings?

Any advise would be appreciated!

Many thanks.

[marce1000 · Accepted solution]

 - FYI : https://community.cisco.com/t5/network-access-control/aws-and-ise-and-upgrades/m-p/4567645#M573351
                               But from 2.4 you can only go to 3.0 with backup restore method , 

 M.

[Marvin Rhoads · Accepted solution]

Spin up an ISE 3.0 VM as a staging system. Restore the backup from your current 2.4 system onto it. Then take a backup from 3.0 and restore it onto the 3.x (currently recommended 3.2 patch 4) system in AWS. Be sure to include backup of your system certificates and keys (assuming you are using CA-issued certificates). Adjust DNS accordingly to resolve the server name(s) to the new IP address(es). Of course your NADs need to point to the new PSN address(es).

[wayne loh]

Hi Marvin,

Basically we have 2 full ise node in the environment, running active and passive. For the staging system, do we need to have 2 full ise node v3.0 as well？Do we need to de-register the existing secondary node and do the backup of primary?

Thanks.  

[Marvin Rhoads]

No need to de-register before taking a backup. The staging node can be standalone.

[wayne loh]

Hi Marvin,

Well noted. As second opinion, do you think I should use the backup restore method or I should just setup from scratches, meaning build the new v3.3 and configure wireless with 802.1x. Which one to be more seemless looking at the short windows of period.

Thanks

[Marvin Rhoads]

It depends on a couple of things, mostly not directly ISE capability-wise. Like how comfortable are you with the existing configurations, how "clean" the existing configuration is, are you able to troubleshoot everything that might go wrong if you rebuild from new install etc.

Most people elect to backup and restore unless the current setup is very messy and not something they want to preserve.

[wayne loh]

Hi Marvin,

Always appreciate your prompt advise.

Yea that is what I think too. Backup restore will be more direct when come to migration. Let me sum up:

1) Backup existing data and operation config, cert and keys from PAN (No deregister is required)

2) Restore the backup config to staging ise v3.0 single node

3) Backup config data, cert and key from node v3.0

4) Restore above to v3.3 (different hostname and IP - the node will initially be standalone, before configuring to be PAN), add secondary node by register it

5) NAD and Test

Thanks.

[Marvin Rhoads · Accepted solution]

Correct summary.

Be sure to have new hostnames and IPs in your configured DNS (forward A records and reverse lookup PTR records). Your NADs will then have to point to the new addresses.

[wayne loh]

Appreciate the reply.

Will try out the approach above mentioned. How about your experience on any of the Cisco ISE cluster on AWS? I saw some aws cloud transformation (CF) to automate the 2 node across 2 availability zones with other components, to trigger and alert the failover. It doesnt seems like the traditional way of HA and failover (with hearthbeat) it seems complex. Is there a guide to setup the minimum to be HA on aws?

Thanks

[Greg Gibbs]

There is no difference in the way an ISE cluster handles redundancy and high-availability regardless of whether it is deployed in on-prem, private cloud, or public cloud environments (or across any combination). See the Admin Guide for information on Distributed ISE Deployments.