On Tue, Feb 17, 2015 at 11:42 AM, Rui Ribeiro <ruyrybeyro@gmail.com> wrote:
Hi Alan,
Forgive my ignorance, but are you implying DHCP is keeping up with accounting data?
The OP asks about IP allocation during radius authentication, not really related to DHCP. However it is true that both can use the same module, e.g. rlm_sqlippool. For radius authentication case, rlm_sqlippool needs information from the NAS to determine whether an IP is being used or not. For example, see https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-confi... , look for "stop_clear" and "alive_update". When rlm_sqlippool allocates duplicate IP, it's possible that the server is misconfigured, or the NAS is not sending interim update fast enough so that rlm_sqlippool thinks the IP is "free" while in fact it is still being used.
I tried to write a script to identify users via a web page to give some accounting stats and quickly reached the conclusion it was not real time (i.e. if done immediately upon login it would often show the previous user). When in Meru training they also confirmed me the delay when receiving accounting data could be up to 3 minutes for their equipment, if I am not wrong, giving the delay from the top of my head.
So the idea I have is whilst accounting is very useful, it is not exactly real-time, correct?
How fast your backing store (e.g. db) is updated depends on a lot of factors, like how fast the NAS is sending out radius packets, how busy the db is, and whether you have something like decoupled accounting. So yes, there can be some delay if you're reading radacct table. The exact cause, and how long the delay is, depends on your setup. Running FR in debug mode can usually help identify it. -- Fajar