On Mar 5, 2018, at 2:12 PM, mustafa mujahid <mustafa.mujahid@outlook.com> wrote:
Radius version : 2.2 (old, but reliable)
You should upgrade to 2.2.10.
Ive recently ran into a problem with our accounting Radius server which have seen smooth sailing for a long time. Basically every night at 8pm a stop request is generated for all users and then consequently a start to change the package assigned to the customer. Currently our Radius is serving 19000 customers. The problem we are facing is that the NAS which is basically a session and resource controller sends the accounting-requests but the accounting-responses are taking from around 7 to 10 seconds from the time the Acct-requests come in to be dispatched to the NAS as observed from wire shark, please see attachment.
The default configuration works, and doesn't take 10s to respond. So it must be something on your local system which is causing the problem.
The same is reflected in the radius accounting logs. The problem that occurs due to this is that the NAS when it doesn't receive the response in the given time keeps retrying, sending accounting-requests again and again and eventually errors with retries expired and fails.
That's what the NAS should do.
Should I increase the ''max_requests'' in radiusd.conf, currently it set to 2048. The comments say it should be 256 multiplied by the number clients. Now by clients does it mean the actual number of customers in my case or the number of NASs that connect to the Radius server. (Apologies for the lack of understanding)
The NASes. But changing that number won't help.
Accounting responses usually take milliseconds but I don't know why it's taking so long in this case. If I could be guided in how to troubleshoot this or any assistance in this regard would be greatly appreciated.
See this: https://wiki.freeradius.org/list-help You haven't said what you've configured FreeRADIUS to *do* with accounting packets, so it's difficult to help you. All we can say is that there is no magic "wait 10s" setting in the server. In general, delays are due to local issues. e.g. slow database, slow script your executing, etc. But you should ask a *good* question to get a good answer. Right now, vague questions get vague answers, which aren't overly helpful. Alan DeKok.