Load Balancer Persistence /w Radius Accounting

[Damien Miller]

I'm looking for some clarification in regards to configuring radius persistence on load balancers in conjunction with radius accounting interim timers.  It has been suggested that we look at doing some tuning in this area. 

I have checked with the load balancer team and they currently have "-cltTimeout 120" which Citrix's guide indicates to be 2 minutes.  I looked at the sample config for ISE with Citrix and it seems these values may have been taken from this document. It looks like this persistence timer is configurable all the way up to 31536000s/525600min but my concern would be connection limit exhaustion if set too high. 

Citrix Netscaler 1000V Load Balancing Config for ISE

The wired environment is already configured with "aaa accounting update newinfo periodic 55" which doesn't line up with guidelines or the timeout.  It was suggested that we look at pushing this value to 1440 or even 2880.  I'm curious what the recommendation would be when dealing with large load balanced environments?  The caution at the bottom of the second image is somewhat ominous.

[hslai]

If resources on the load balancer an issue, I would suggest to separate based on connection types (wired, wireless, and VPN). And, separate use cases that requiring persistency (e.g. posture) and those not.

[Damien Miller]

I spoke to the load balancing team since this post and they said that the Citrix consultant in the past mentioned the timers could be set as high as we needed.  They were not concerned about connections but is something I would still want to watch.  They did not express concerns with setting to 2880 min / 172800 seconds.

My concern now is more what we should be looking at for large environments.  The "caution: using the aaa accounting update periodic command can cause heavy congestion with many users" is a concern.  We are looking at this because it was noted that we have a very large number of accounting packets coming in.  Is there a threshold we should be staying under from an acocunting perspective, say 1000 packets per seconds etc?  Where do we draw the line?

What's the alternative with large environments other than breaking them up?

[hslai]

From ISE point of view, it's best to reduce as much as possible all the un-neccessary authentications and accountings.

I think the threshold would be comparable to PAP auth @ ISE 2.4 RADIUS Performance

[Damien Miller]

This hasn't really clarified it all that well for me so maybe I should rephrase. 

1. Why is 1440 minutes being suggested, why not something like 7150 minutes/4.97 days? If ISE waits 5 days to purge inactive sessions that it has not seen a stop message for, then why use shorter?

2. If we are being given a "caution: using aaa accounting update periodic can cause heavy congestion when many users are logged in to the network", what's the alternative beyond tuning this value to be as long as possible? 

[hslai]

On 1, this number is somewhat arbitrary. I also prefer it a longer internal.

On 2, during the first logins, the aaa accounting update periodic is not really used. Avoid using "newinfo" unless you are using IOS device sensor.