Duplicating Accounting Requests / accounting to multiple locations
Hi, i'd like to forward accounting requests to multiple locations. We use radius accounting not just for billing/accounting but also monitoring, tr069 configuration and other stuff so we need multiple locations to send the information to. I have found the home_server_pool stuff but the policys avail show only load balancing or destination hashing which is not what i'd like to have. A "duplicate" policy would be what i was looking for. Acknowledge the packet to the sending NAS and sending requests to all final systems and waiting for their acknowlegde. A limit in queue or storage capacity would be acceptable e.g. max 1000 requests outstanding and front dropping afterwards. I have found the "copy-acct-to-home-server" virtual site which makes me wonder about the imposed delay by writing the accounting records to disk and reading again for forwarding. Sounds like a strange solution - a bit like UUCP store and forward copy ... Flo -- Florian Lohoff f@zz.de
Florian Lohoff wrote:
A "duplicate" policy would be what i was looking for. Acknowledge the packet to the sending NAS and sending requests to all final systems and waiting for their acknowlegde.
This can be done.
A limit in queue or storage capacity would be acceptable e.g. max 1000 requests outstanding and front dropping afterwards.
That's difficult to do.
I have found the "copy-acct-to-home-server" virtual site which makes me wonder about the imposed delay by writing the accounting records to disk and reading again for forwarding. Sounds like a strange solution - a bit like UUCP store and forward copy ...
Yes. It's the ONLY way to reliably replicate accounting packets. You need to handle the situation of the RADIUS server going down, or the home server being down for extended periods of time. Only logging to a file will handle that. Alan DeKok.
Hi, On Wed, Dec 14, 2011 at 05:45:17PM +0100, Alan DeKok wrote:
Florian Lohoff wrote:
A "duplicate" policy would be what i was looking for. Acknowledge the packet to the sending NAS and sending requests to all final systems and waiting for their acknowlegde.
This can be done.
A limit in queue or storage capacity would be acceptable e.g. max 1000 requests outstanding and front dropping afterwards.
That's difficult to do.
I see - i guess i have to write a radacct-duplicate-daemon myself.
I have found the "copy-acct-to-home-server" virtual site which makes me wonder about the imposed delay by writing the accounting records to disk and reading again for forwarding. Sounds like a strange solution - a bit like UUCP store and forward copy ...
Yes. It's the ONLY way to reliably replicate accounting packets. You need to handle the situation of the RADIUS server going down, or the home server being down for extended periods of time. Only logging to a file will handle that.
For most of my purposes i dont care about systems not available for a longer period as backend systems take care on synchronisation. In the past 15 years i have seen a lot of broken Radius implementations not sending Stop/Start or Accounting On/Off so relying on state by Radius is some kind of guesswork in my eyes. When talking about reliability you talk about fsync after every packet before acknowledge? Store and Forward for Mails is okay - but doing that with some 2000 Packets per seconds sounds wrong. Flo -- Florian Lohoff f@zz.de
Florian Lohoff wrote:
For most of my purposes i dont care about systems not available for a longer period as backend systems take care on synchronisation.
Then why replicate via RADIUS? Why not synchronise via the backend?
In the past 15 years i have seen a lot of broken Radius implementations not sending Stop/Start or Accounting On/Off so relying on state by Radius is some kind of guesswork in my eyes.
Yes.
When talking about reliability you talk about fsync after every packet before acknowledge?
No. The detail module doesn't fsync to disk. But it does do it's "best effort" to write to disk.
Store and Forward for Mails is okay - but doing that with some 2000 Packets per seconds sounds wrong.
So submit a patch which implements accounting replication which (a) doesn't write to disk, and (b) is robust in the event of temporary process/system failures. I don't think you can satisfy both requirements at the same time. What you CAN do is to bypass the detail file most of the time. See raddb/sites-available/robust-proxy-accounting Alan DeKok.
On Wed, Dec 14, 2011 at 07:13:05PM +0100, Alan DeKok wrote:
So submit a patch which implements accounting replication which (a) doesn't write to disk, and (b) is robust in the event of temporary process/system failures.
I don't think you can satisfy both requirements at the same time. What you CAN do is to bypass the detail file most of the time. See raddb/sites-available/robust-proxy-accounting
A NAS/BRAS does not satisfy this itself. Typically its something like 10 trys with 10 seconds. So after 100 Seconds the packet it gone. Storing is a no option on BRAS systems with 100K Subs and 10 Minute interim account which we did in the past. Flo -- Florian Lohoff f@zz.de
participants (2)
-
Alan DeKok -
Florian Lohoff