F5 persistence configuration & Interim Accounting Updates hitting ISE

[ajc]

Hi everyone,

When we deployed F5 and ISE PSN's, we used the documentation provided by Cisco where the values were:

Source address – 180s

https_sticky – 3600s

radius_sticky – 3600s

Meraki Wireless default settings are configured as 10 minutes for interim accounting updates and I think it is too aggresive because our ISE deployment is getting hit by hundred thousand of records every 10 min. In fact, Cisco ISE BU suggested to completely remove those updates and just rely on session timeout. I am wondering if I should adjust those F5 persistence values to something higher and then adjust accordingly the accounting interim updates to something like every 7 hours x SSID so our ISE deployment is not overwhelmed by such significant amount of traffic.

Damien Miller, a regular contributor, indicated that F5 persistence configuration should be higher that interim accounting updates and I am looking for feedback about it.

thanks

Add tags

[Arne Bier]

The exact values that should be used for the timers will always be a "try it and see" approach because every network is different. It's true to say that persistence value should be larger than the interim, because that ensures that the LTM will send the traffic to the PSN that originally handled the session (and owns the endpoint).

The question of how often to send interim accounting updates depends on the reason for sending those in the first place. More frequent sending of Interims doesn't help ISE - because we're not trying to collect near real-time billing data - we simply need interims to help ISE for licensing and session management keepalives. If the Accounting Start was sent to ISE, then I think it's reasonable to send an Interim after 24 hours, or even 48 hours. ISE will maintain the session and license for 5 days if it doesn't hear anything after the Accounting Start. If the session dies before the interims are sent, then ISE will clean up the session database and release the license - no need for interims in that case.

I can't think of any reasons for setting an aggressive interim interval. In Service Provider networks, the RADIUS Accounting is used and analysed to create bllling/usage records. And for them, accuracy is important, especially if near real-time is required. If the NAS plays its part nicely and sends the Accounting Stop at the end of the session (and RADIUS server receives the UDP packet ...) then we have all the information we need anyway.

[ajc]

Hi Arne,

Thanks for replying. Let me give a try in our LAB and see what is the actual behavior when Interim update interval is greater than our current 1 hour F5 PSN persistence.

[Arne Bier · Accepted solution]

Hi @ajc 

I didn't say that the interim should be greater than the F5 persistence - it's the opposite. You want the LTM to send the RADIUS traffic to the same PSN for as long as possible. Therefore, interim < persistence

You could ask the F5 folks to increase the persistence value. If the persistence value were 8 hours, then you could send an interim every 4 hours. Which begs the question, why bother with interims in the first place?  What purpose does it serve?  

I know you're on Meraki, but on typical Cisco WLC gear (AireOS) you can set the interim to be 0 - which has a special meaning to say that it will only send an interim if there is an update to the endpoint's IP address (e.g. DHCP renew). But otherwise send nothing. And in IOS-XE the same thing can be done, but you can also set an absolute interval timer that will eventually send an interim - the best practice on switches is to send an update every 2880 minutes (2 days). Maybe Meraki has a similar option?

Do you you believe that you have wireless clients that hang around for more than 5 days straight and remain on the same AP for that entire time? If not, then I would not bother with interim accounting. Unless ... Meraki sends you DHCP probing data (Cisco Device Sensor) - which helps with endpoint profiling. But you don't even need that - ISE can glean DHCP information using the DHCP probe - then all you need to do is to send the DHCP requests to your ISE PSNs (again, to use a Cisco IOS analogy, it's the ip helper statement) - ISE doesn't respond to DHCP but it gathers the data in the client's Discovery packet (e.g. hostname etc)

[ajc]

Hi Arne, 

I got your point. I was just thinking about the case where I cannot modify the F5 persistence duration and what would be the behavior in our lab.

The problem that I am facing is that we have followed all recommendations from TAC regarding continuous high load error messages in Dashboard and I want to get rid of those "every 10 minutes" acct interim updates sent by Meraki AP from our 100K + active sessions, we do not need those messages at all as your clearly explained. I am expecting that removing those acct updates would help with the high load issue.

Meraki version 28 only allows you to configure an interim interval of around 545 minutes (I have no idea how they got into that value) and you cannot disable it. Version 29 allows you to disable it but we have not upgraded to that yet (we used to be full cisco wireless gear, now running Meraki). I know pretty good cisco wireless side.

Let me double check best practices from Cisco regarding F5 persistence duration and evaluate it that could affect our environment.

thanks

[Marcelo Morais]

Hi @ajc ,

 please take a look at How To: Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP., it might be of some help !!!

Hope this helps !!!