Are there any downsides to using Cisco ISE 2.3 or later behind a load balancer?

[Terence Lockette]

Hello all,

I wanted to pose this question to the community to see what kind of feedback I'd get.  I understand that the recommended solution for multiple PSNs is to place them behind a load balancer.  However, are there any downsides or potential problems I could run into by doing so?  Things I have in mind are advance features such as using SGTs, pxGrid, and any other feature that is known to be an issue when used behind a load balancer.  I'm asking specifically for version 2.3 or later.

Your feedback is greatly appreciated!

Terence

[Damien Miller · Accepted solution]

In my opinion the biggest downside comes with troubleshooting. Anytime you add another device in the path it's one more potential area you need to consider. Part of this comes with the configuration of the load balancer itself. There are no shortage of problems that can occur when the load balancer isn't set up right. Typically these are all sorted pretty early on during testing, and from then on it's usually a non issue. It's usually pretty quick to rule out the load balancer once you're familiar with them.

As far as services go, I would not load balance pxgrid v2 (2.4) or SXP. I would deploy both of these services with standard node redundancy in active/active form.

Using ISE for TrustSec or SDA has only a slight difference that you need to be aware of with the persistence configuration. The CTS pac provisioning process does not include the calling station ID radius attribute. If you're using the Cisco Community ISE LB guides then you need to add compound persistence such as calling station ID + Nas ip to address this. I made a post addressing this with the Citrix config example. The F5 guide addresses this with a persistence fallback irule.

When dealing with a large deployment I will always choose a load balancer. I think the config and HA simplicity it brings outweighs the potential added troubleshooting steps.
I wouldn't hesitate to consider load balancing, set up right it works great.

[Arne Bier]

Ditto to what @Damien Miller  already pointed out.  Nothing will prepare you for this as much as the fun and joy of a real world deployment.  But there is a lot of collateral that you can read (e.g. if you're doing F5 then Cisco has plenty of great stuff to read up on).

I would add another small curveball.  The load balancer can also perform SSL offload and I ran into one case where the ISE Guest Portal certs were replaced because they had expired, yet, the end user still got the old expired cert (browser warning).  it took a while to realise that the F5 was still presenting the old cert!  So it had to be updated there too.  Watch out for that if you're doing SSL Bridging (I think that's what they call it).

Other crazy topics are things like GTM (Global Traffic Manager) which is like a DNS server on steroids.  Can be a great help for Guest Portals again to allow the F5 to load balance across multiple data centres and figure out which PSN to maintain persistence to (because guest.mycompany.com must resolve to SOMETHING - that something has to be deterministic - if you're load balancing across data centres (i.e. two VIPs essentially) then you have to steer the end user to the correct VIP.

It helps having a load balancer SME on board when doing complex jobs.

[Terence Lockette]

Thank you Arne and @Damien Miller.  This information really helps in considering whether to put our PSNs behind our NetScaler.  Even though we're using a distributed deployment, our environment is relatively small compared to other organizations within the healthcare industry.  So I'm trying to decide if putting them behind a load balancer will make sense for us and doing the extra work to move them since our LB is in our DMZ.  That means opening ports in the firewall and so forth.  At this point, it's the HA/failover and using a single static FQDN for both PSNs for the guest hotspot URL redirect that would make sense for this.

Based on a conversation I had with TAC, they said as long as both PSNs stayed up, I could use a single static FQDN for hotspot portal by creating two A records with the same name pointing to each PSN IP.  The first PSN on my NADs will authenticate clients and if that goes down, then the next will be used to authenticate for the same FQDN.  The issue with this is that if a client authenticates to the hotspot portal and then that PSN goes down, that session ID is tied to it and the new PSN will have no knowledge of it to keep the guest process going.  Therefore, the client will need to terminate (either manually or an ISE admin deleting the endpoint) and start over.  This is, obviously, not a good user experience if this scenario was to play out.

At this point, it's either allow ISE to dynamically resolve the PSN via the PTR and not use static FQDN or place them behind a load balancer.  Thanks for your feedback on this question.  But I do want to ask one more as it relates to the dynamic resolution for the URL redirect.

When not using static FQDN, the URL is https://ip:port/... and will resolve to the IP of the PSN authenticating the client.  Question: If my PSNs are in part of our internal domain (internal.org) but I want to use them in our public domain (public.org) and I have a zone for each domain on our DNS servers, is there a way to resolve the public resource records for the PSNs instead of the private?  In other words, no static FQDN defined in the AuthZ profile so when a client authenticates, DNS will return the public record rather than the internal.

[Terence Lockette]

@Arne Bier and @Damien Miller,

I was just thinking about my last question from my previous post.  My guess is that I would have to reconfigure both PSNs to be part of the public domain instead of the private domain (ip domain-name private.org) and then likely replace my certs, correct?

[Arne Bier]

I just saw your reply to your own question.  Yip - you're right.  You can unconfigure an ISE node with the

"application reset-config"

command and then you have the chance to set the hostname etc.  it's effectively a complete rebuild of the ISE node.  If it's patched then you retain that - but config is blown out of the water.

[Arne Bier · Accepted solution]

Hi @Terence Lockette 

The result of a non static FQDN, the URL is https://ip:port/... so the client device will see https://ise-box-01.internal.org:8443?fhfhkshfs  etc - at that point you're snookered because the cert that ISE presents to the user will not contain .internal.org (or at least, no public CA will make a cert for you using that private domain).  This is why you need to perform the "translation" of internal domain to public domain using the static override in the AuthZ.

I hope that makes sense :)