ISE Migration with SDA Fabrics Deployed

[anthony.wild]

Hello Team,

We are posturing to migrate our ISE Environment onto new infrastructure in Azure. So far we have created the new 3.2 nodes, upgraded the existing premise deployment to 3.2, and absorbed the newly minted nodes running on Azure into the existing landscape. All of the non-SDA sites that have yet to be converted to SDA have been rolled over and pointed to the new cloud policy nodes.

Thus now, we are the critical juncture for the SDA sites. We have 13 sites/fabrics deployed and the issue that I foresee is that I cannot edit the IP inside of DNA Center. Meaning, I can't swap personas by promoting 2 nodes in the cloud to management and edit that IP in DNA, I can only delete the AAA Server and recreate it. So after deleting and adding it back in, I would have to go to each site level network design and ensure that the AAA IPs for Radius and TACACs are valid according to proximity/latency requirements. I do have a TAC case in, but am wondering if anyone else in the community has attempted this before. I'm not so much worried about the standard "dnac-client-radius-server" aaa groups, because we've updated/switched PSN's around in there and DNA seems to reconcile the change just fine. I'm more worried about Fabric Wireless deployments where DNA creates "dnac-rGrp-<SSID here>" uniquely generated aaa groups, and how well those will get updated.

Anyone else who has been through this before, comments and feedback much appreciated!

[anthony.wild]

I ended up answering my own question here. Just an FYI that the tasks I performed are neither documented, supported, approved, or otherwise "correct"... they just happened to work in my scenario. One caveat I will mention is that we utilize eWLC extensively, so I had the complexity of also accounting for the aaa statements that are generated by DNA against the AAA servers listed in the Wireless tab of Site Level Network Settings. These steps were performed on a 2.3.3.5 deployment, with a shift from ISE 3.0 on premise to ISE 3.2 in Azure Cloud. Steps I took were;

1. Create New ISE Environment Nodes. Set no roles.
2. Run Split Upgrade on current environment, start with secondary admin node.
3. Join upgraded node to new deployment and promote the old admin node to primary admin node.
4. Setup and join new deployment nodes as you would want them in the full target state. The database should be fully populated to all of the nodes so at this point I demoted the old admin node to be pxGrid only and setup two new admin nodes. Validate that all of your data is intact including policy sets, etc. Do not forget to consider certificates, AD join for the new nodes, etc. I had to regenerate the ISE Root CA at this point.
5. At this point you can deregister the old admin node that you used to seed the new deployment.
6. This is where it gets tricky.... Create a temporary AAA server inside DNA (not ISE, just AAA, as you can only have one ISE server present at a time).
7. Go to each site level and shift override the sites to the dummy AAA server. ***** In 2.3.3.5 this did NOT actually push any config to my switches. It just removed the dependency on the configured ISE server. As a last step, shift at the global/root level.
8. Remove external authentication dependency on ISE in DNA, FIRST ENSURING THAT YOU HAVE THE LOCAL LOGIN.
9. Remove ISE inside DNA.
10. Add new ISE Management IP inside DNA. Before you do, double check that your pxGrid and Management Nodes are how you want them to be. ****ENSURE THAT THE RADIUS SECRET MATCHES WHAT YOU ALREADY HAVE DEPLOYED! ENSURE THAT IF YOU USE TACACS THAT YOU ALSO SELECT THIS OPTION ***** I
11. Head back to Network Design and pick a test site. Toggle the Network Settings from the dummy AAA server back to ISE. Ensure that your radius and tacacs keys are correct, as required. As soon as I set this, DNA pushed config to my switch. **** IF YOU MAKE A MISTAKE WITH A BAD KEY, YOU MAY HAVE TO USE THE WebUI to get access back to your switch in order to open up vty access ***

Tip #1, If you are using Wireless and intend to use a VIP for things like CWA, be sure to add the PSNs to the AAA servers as second/third/etc options. Even though you have a VIP, DNA will use these servers to build the WEBAUTH_ACL, so you want to make sure they are included.

Tip #2, I had issues where DNA network-programmer was gridlocked and unable to push configuration to my switch due to the AAA dependency for fabric wireless after I updated the new PSN IPs. In this scenario, I established ssh access and ran a "no aaa new-model" to dump out all the AAA config. MAKE SURE THAT YOU FOLLOW THAT COMMAND with a "line vty 0 50" and "login local" and test access to the switch in another ssh console to make sure you still have local access before you close the conf t session. Then, resync the switch, wait for DNA to acknowledge the lack of AAA settings in the switch by observing "no aaa new-model" in the DNAC Device 360 Configuration View. Then, reprov the switch. That should be it.