ISE Design Question

[virtualpedia]

Hi,

I have a question regarding design a not so typical design.  I'm looking to deploy ISE, but due to pandemic, budget is very tight, so I have to make some sacrifices.   If I start with a small deployment (2 nodes, with Admin,MNT, PSN persona) on them, I know if I want to expand that later by deploying additional PSNs, I'd remove the PSN persona from the original 2 VMs and deploy new PSNs (up to 5). If I go that route, I'll eventually have to modify all NADs to point to the new IPs of the PSNs, which is cumbersome.

My question is, in the 2 node deployment, can I point my NADs to a hostname instead of an IP? So to clarify

VM1:  ise1.mydomain.com - 10.10.10.1  (primary Admin, Primary MNT, PSN)

VM2: ise2.mydomain.com - 10.10.10.2 (standby Admin, standby mnt, psn)

Can i create a dns record say, psn1.mydomain.com and point it to 10.10.10.1?   Then later on when it's time to expand the environment and add an additional PSN, I'll give that VM a hostname of psn1.mydomain.com and all I'll have to do is change the DNS record to point to the proper new IP

If there is a better way to accomplish this, I'm open for suggestions

[Greg Gibbs · Accepted solution]

Most network devices (including Catalyst switches) do not support configuring RADIUS servers by FQDN, only IPv4/v6 addresses.

One option to avoid reconfiguring all of you NADs when you need to scale the ISE deployment would be to deploy two new ISE VMs and move the PAN/MnT personas to those new VMs. That would leave the PSNs with the current IP addresses.

You would just need to change the DNS entries for your PANs to point to the new IP addresses. If you have any other systems using the current IP addresses for connectivity to the PAN/MnT nodes (for REST API, pxGrid, etc), you would need to change those, but that would normally be much less work.

Keep in mind that changing the hostname of an ISE node requires that node is in Standalone mode. You should use hostnames that do not need to change when you later scale the deployment to avoid having to remove the node from the cluster, change the hostname, restart ISE services, then add it back to the cluster.

A second option would be to use a load balancer and point the switches to that VIP for RADIUS servers.

[virtualpedia]

Hi @Greg Gibbs 

Thanks for the reply.  I did think of the load balancer as an option at first, but I only have 1 in one of the locations where I'll this deployed.

The second option is intriguing and I didn't think of that.  Can you help me with a little more understand the logistics of that?  If today, I deployed ise1.mydomain.com (primary) and ise2.mydomain.com (standby).  If than later deployed two new VMs (isepan1.mydomain.com and isepan2.mydomain.com), how would I move the PAN/MnT personas to them?  Sorry for the newbie question, but since there can only be 2 max pan/mnt, I'm not sure how I could move the PAN/MnT.  Would I need to do a restore?

[Peter Koltl]

Register 2 new nodes as PSNs 

You enable secondary Admin on a new node

then promote it to primary admin

then enable secondary admin on the other new node

enable primary monitoring on new node

etc.

I’m afraid the monitoring logs will not be transferred.

[virtualpedia]

Okay, so I'd add the new VMs as PSNs, and then once I get the Mnt/Admin personas on them, I'd remove the PSN persona?  Makes sense

You mentioned monitored logs wouldn't be transferred.  Why is that?  When I add the new VM as a the new secondary MnT, why wouldn't the primary replicate the logs to it?

[Damien Miller]

Monitoring node syslog's are maintained independently on each monitoring node. There is no log sync by design. With a dual MNT deployment, each PSN sends two copies of each log, one to MNT 1, and another to MNT 2. 

If you desired, and I do not recommend it, you could run a log backup, then restore those logs to the new MNT. Most don't bother and just let the logs build up. By default only 30 days are stored, you could just use the existing MNT as the primary until the secondary has been online for 30 days. 

[virtualpedia]

@Damien Miller that's right!!!! totally slipped my mind.   I'll just let the logs rebuild, no need to do a backup/restore

Thanks much