topic Re: Split ISE distributed design to two separate deployments in Network Access Control

Split ISE distributed design to two separate deployments

Muli — Fri, 02 Apr 2021 23:14:26 GMT

We have ISE 2.7 distributed design deployed and working fine with PSN split in two time zones:

PAN x 2

MnT x 2

PSN x 8

I want to split the current network and want to take out 4 PSN from this setup and want to administer these four PSN by deploying 2 new PAN and MnT nodes. So the final ISE network design will have following two separate ISE entities:

Network 1 (old)

#########

PAN x 2

MnT x 2

PSN x 4

Network 2 (new)

###########

PAN x 2 (new ip address and license)

MnT x 2 ( new ip address and license

PSN x 4 ( using old ip address and license)

Key goal here is that:

1. Network 2 above must use existing configuration, certificates from Network 1 to avoid configuring everything from scratch

2. Reduce any downtime or minimal impact during migration or split.

Can some one please advise what is the best approach to achieve this ?

Re: Split ISE distributed design to two separate deployments

Marcelo Morais — Fri, 02 Apr 2021 23:55:32 GMT

Hi @Muli

my suggestion:

1. backup your ISE Cube 01 (12x Nodes)
2. export the Certificate
3. de-register your PSN 08
Note: at this point PSN 08 has all the configuration of  your ISE Cube 01 and is a Standalone
4. install the new Nodes (8x Nodes) on the new Site
5. register the new Nodes to PSN 08
Note: at this point PSN 08 is the Primary PAN of the ISE Cube 02
6. promote one of the new Nodes to Primary PAN
7. install certificates
8. backup the ISE Cube 02
9. start de-register PSNs from ISE Cube 01 (05, 06 and 07)
10. backup the ISE CUBE 01

Hope this helps !!!

Re: Split ISE distributed design to two separate deployments

Mike.Cifelli — Mon, 05 Apr 2021 17:00:01 GMT

Can some one please advise what is the best approach to achieve this ?

1. Network 2 above must use existing configuration, certificates from Network 1 to avoid configuring everything from scratch

Here is a rough overview of steps I have taken to migrate from one cluster to another (note: hosts were VMs, and used the same hostnames):

Generate config backup from network 1 (old) setup PAN*

Old cluster:

disabled pan failover
promoted pan2 to primary
unjoined pan1 from AD
exported certificates
deregistered pan1 from cluster

enabled nic on new pan1 in 2.7 cluster
shut nics on old pan1 in 2.4 cluster
changed IP address on new pan on nic 1 (services restart)
added nic 2 and added underlay ip address (services restart)
added static routes via CLI for additional nic
started system restore
kicked off restore & successfully worked ~35 minutes for this instance
re-joined node to AD
setup node as primary node with right personas

started psn1 migration
exported certs
unjoined ad
deregistered from old cluster
shut nics
added nics to new psn1
changed ip addresses and added appropriate static routes
registered with new pan
setup proper personas
synced with new pan
joined to AD
*verified radius live logs to determine it is servicing clients

...and continue process for additional PSNs & lastly move 2nd PAN (now new primary of old cluster)

2. Reduce any downtime or minimal impact during migration or split.

PSN x 8; I want to split the current network and want to take out 4 PSN from this setup

-As long as your NADs have entries and the ability to talk to all 8 PSNs for AAA purposes you should have no issues de-registering 4 PSNs from network 1 setup. If you are concerned here are a couple of options that will aide in eliminating downtime:

You can setup a AAA server group and put the 4 PSNs that will stay at the top (highest priorities), and the 4 you will remove at the bottom. See here for more: AAA Server Priority explained with New Radius Server Command Line - Cisco

Another option is you could implement a long reauth timer/window via Authz profiles to ensure during the cutover that clients are not re-auth'ing inside your cutover window.

Few things to note:

every ip change restarts services
changing personas restarts services

I would suggest engaging TAC too to ensure you are covered if you hit any bumps during the migration. Good luck & HTH!