What are the consequences of a low Acct-Interim-Interval?
Maybe I'm overthinking it, but we have currently the interval set to 300 seconds. What happens if I set this permanently to 15 seconds? Based on currently logged in users (around 700 users at a time), the database, as well as the freeradius process (CPU/Memory), will be a lot more utilised than before due to an increased number of updates. post-auth { update reply { Acct-Interim-Interval = 15 } Is there an industry standard value that is considered fair? Or can I go as low as 15 seconds without fearing scalability issues? Many Thanks, Houman
On Oct 16, 2019, at 2:58 PM, Houman <houmie@gmail.com> wrote:
Maybe I'm overthinking it, but we have currently the interval set to 300 seconds. What happens if I set this permanently to 15 seconds?
Most NASes will ignore it. From RFC 2869: The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 600, and careful consideration should be given to its impact on network traffic. Most NASes will set 300s as the minimum. There is very little benefit to setting it lower than that.
Based on currently logged in users (around 700 users at a time), the database, as well as the freeradius process (CPU/Memory), will be a lot more utilised than before due to an increased number of updates.
post-auth { update reply { Acct-Interim-Interval = 15 }
Is there an industry standard value that is considered fair? Or can I go as low as 15 seconds without fearing scalability issues?
Why would it be 15s? There's no real benefit. Alan DeKok.
Thanks for the explanation, Alan. The benefit for 15s would be to identify users that have overstayed their welcome and kick them out sooner. preacct { update control { &Current-Timestamp := "%l" } update request { &Expires-Timestamp := "%{sql:SELECT UNIX_TIMESTAMP(expires_at) FROM main_db.`user` WHERE main_db.`user`.username ='%{User-Name}'}" } if (&control:Current-Timestamp > &request:Expires-Timestamp) { update disconnect { &User-Name = "%{User-Name}" } } I suppose 300 seconds is still fair. Expired users can still enjoy their stay for a few more minutes but get eventually disconnected. Having said that my NAS works fine in the test environment with even 10 seconds. But I was worried that I'm overdoing it, hence I thought I double-check with you here. Thanks, Houman On Wed, 16 Oct 2019 at 22:37, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 16, 2019, at 2:58 PM, Houman <houmie@gmail.com> wrote:
Maybe I'm overthinking it, but we have currently the interval set to 300 seconds. What happens if I set this permanently to 15 seconds?
Most NASes will ignore it. From RFC 2869:
The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 600, and careful consideration should be given to its impact on network traffic.
Most NASes will set 300s as the minimum. There is very little benefit to setting it lower than that.
Based on currently logged in users (around 700 users at a time), the database, as well as the freeradius process (CPU/Memory), will be a lot more utilised than before due to an increased number of updates.
post-auth { update reply { Acct-Interim-Interval = 15 }
Is there an industry standard value that is considered fair? Or can I go as low as 15 seconds without fearing scalability issues?
Why would it be 15s? There's no real benefit.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 16, 2019, at 3:28 PM, Houman <houmie@gmail.com> wrote:
The benefit for 15s would be to identify users that have overstayed their welcome and kick them out sooner.
That's what Session-Timeout is for. You can set a timeout to 3600s (or to anything else you want). You then know that people are allowed to be in for 3600s, and that they will be kicked off the network after that. They can then re-authenticate, at which time you can determine if they are allowed back on the network. Playing games with Acct-Interim-Interval is just a hack. Use the standard RADIUS solutions instead of fragile hacks. Alan DeKok.
Hi Alan, That's a fair point, but I don't think this works with my NAS. I have set it to 10 seconds for testing purposes. I was expecting it to retry the auth after the session runs out. But it remains entirely disconnected instead. post-auth { update reply { Acct-Interim-Interval = 300 Session-Timeout = 10 } } Cheers, Houman On Wed, 16 Oct 2019 at 23:35, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 16, 2019, at 3:28 PM, Houman <houmie@gmail.com> wrote:
The benefit for 15s would be to identify users that have overstayed their welcome and kick them out sooner.
That's what Session-Timeout is for. You can set a timeout to 3600s (or to anything else you want). You then know that people are allowed to be in for 3600s, and that they will be kicked off the network after that. They can then re-authenticate, at which time you can determine if they are allowed back on the network.
Playing games with Acct-Interim-Interval is just a hack. Use the standard RADIUS solutions instead of fragile hacks.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 16, 2019, at 4:54 PM, Houman <houmie@gmail.com> wrote:
That's a fair point, but I don't think this works with my NAS. I have set it to 10 seconds for testing purposes. I was expecting it to retry the auth after the session runs out. But it remains entirely disconnected instead.
In general the NAS doesn't retry. The end-user does (or their system). And a 10s timeout might work, but it's generally low. If you set it to ~300, then the authentication might restart. Again, the RADIUS server is *not* in control here. It can advise the NAS / end user to do something, but they are free to ignore the RADIUS servers recommendations. This is one of the key concepts which is very hard to make people understand: No amount of poking the RADIUS server will make the NAS do something. Alan DeKok.
And a 10s timeout might work, but it's generally low. If you set it to ~300, then the authentication might restart.
But if I set Session-Timeout to 300 then I haven't gained anything, because Acct-Interim-Interval is already set to 300. My hope was to run the conditionals in preacct sooner than 300s intervals without increasing the traffic.
On Oct 17, 2019, at 9:55 AM, Houman <houmie@gmail.com> wrote:
And a 10s timeout might work, but it's generally low. If you set it to ~300, then the authentication might restart.
But if I set Session-Timeout to 300 then I haven't gained anything, because Acct-Interim-Interval is already set to 300.
My hope was to run the conditionals in preacct sooner than 300s intervals without increasing the traffic.
If you want to check every 5s what people are doing, then RADIUS isn't the way to do it. As I've tried to make clear, RADIUS wasn't designed to do this, and it is very likely to not work. You should use something else to monitor traffic on the system which sees the traffic. That's what everyone else does if they need "live" status of a session. You've spent a lot of time trying to hammer a square peg into a round hole. I suggest another approach. Alan DeKok.
participants (2)
-
Alan DeKok -
Houman