- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2018 08:00 PM - edited 08-23-2018 08:01 PM
I wanted to discuss an issue I found out in the field regarding load balancing radius for ISE. Specifically around the persistence and where I think the published configuration could be amended to help others. I only have Citrix Netscalers at my disposal right now, so my tests are limited to that platform. It looks like the F5 guide is much more thorough and covers this issue with attribute fallback.
If we reference the published load balancing guides for Netscalers, ACE, or BRKSEC-3699, the suggested persistence config is using AVP 31 - calling station ID.
ex. add lb vserver radius-auth RADIUS 172.16.0.16 1812 -rule "CLIENT.UDP.RADIUS.ATTR_TYPE(31)" -cltTimeout 120
This works fine for radius client authentications since client authentications typically include radius attribute 31. The breakdown appears when you start leveraging TrustSec features and the NADs are trying to provision a cts pac. The pac provisioning process uses radius but does not include radius attribute 31. Persistence fails because AVP 31 is not found in any of the pac provisioning packets and thus you get very inconsistent results. Eventually a switch running 16.6.4 will provision a pac but the stars have to align just right for the magic to happen. The F5 config guide discusses and solves this with the irule using calling station id if available then falling back to NAS IP.
Testing has indicated a simple way to address this with Citrix LBs. By changing the persistence to compound both attribute 4 (NAS IP) and attribute 31 (calling station ID), the pac provisioning requests persist properly. Load balancing for client auth still occurs in a fashion that spreads load out evenly, and it presents no issues with pac requests missing AVP 31.
The ammended config looks like -rule "CLIENT.UDP.RADIUS.ATTR_TYPE(31)+CLIENT.UDP.RADIUS.ATTR_TYPE(4)"
With TrustSec gaining more widespread support I'm hoping the help others avoid the same issue if they go to the Netscaler guide/breakout presentation without also reading the F5 guide.
Solved! Go to Solution.
- Labels:
-
Identity Services Engine (ISE)
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2018 04:39 AM
Thanks for sharing. These types of experiences probably expand your understanding of load balancers and such. I have a good deal of respect for anyone who can configure a load balancer properly - to me it's just a black box. Once you start messing around with F5 iRules you turn into a part time developer and looking through reams of debugs to figure out what's going on.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2018 04:39 AM
Thanks for sharing. These types of experiences probably expand your understanding of load balancers and such. I have a good deal of respect for anyone who can configure a load balancer properly - to me it's just a black box. Once you start messing around with F5 iRules you turn into a part time developer and looking through reams of debugs to figure out what's going on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2018 11:55 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2018 01:40 PM - edited 11-26-2018 01:43 PM
I think you could mimic the same logic of the F5 iRule (if exists / else) by using ALT vs joining them together (+).
-rule "CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT CLIENT.UDP.RADIUS.ATTR_TYPE(4)"
