Showing results for 
Search instead for 
Did you mean: 

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!


2 Accepted Solutions

Accepted Solutions

Damien Miller
VIP Advisor VIP Advisor
VIP Advisor
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.

View solution in original post

Hi @Terence Lockette 


The result of a non static FQDN, the URL is https://ip:port/... so the client device will see  etc - at that point you're snookered because the cert that ISE presents to the user will not contain (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 :)

View solution in original post