Proxying accounting to create a 'tee'

[Arran Cudbard-Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/08/2009 16:46, John Morrissey wrote:
> On Sat, Aug 22, 2009 at 01:59:00AM +0100, Arran Cudbard-Bell wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 21/08/2009 21:15, John Morrissey wrote:
>>> On Sun, Aug 16, 2009 at 10:11:02AM +0200, Alan DeKok wrote:
>>>> volkov at ufamts.ru wrote:
>>>>> If home server does not respond, FR does not respond too -> NAS repeats
>>>>> request -> FR writes request data to SQL again.
>>>>
>>>>   So... configure the server to respond.  See the file
>>>> raddb/sites-available/decoupled-accounting
>>>
>>> Is decoupled-accounting (writing all detail to disk and replaying it
>>> serialized with a detail listener) the only way to configure FreeRADIUS to
>>> respond to the NAS?
>>
>> Yes. Otherwise it'll wait for the response from the proxy server, and
>> proxy the Accounting-Response from the proxy server back to the NAS. It's
>> the only way the NAS could be sure the remote server received the
>> Accounting-Request.
> 
> Right. I was hoping there was a way for robust-proxy-accounting to respond
> to the NAS when the proxy isn't responding, since the accounting request has
> been "successfully" processed (i.e., written to the detail log and saved for
> later proxying).

I don't think that's possible unfortunately... If you proxy the request from the server in which it was received (and not the detail listener), the server will never send a response directly. It will
instead just forward the Accounting-Response sent by the home server.

Hmm come to think of it I'm not sure there's actually a way to determine that a proxy is down from within unlang. So it may not even be possible to do the switch between proxying and detail writer...

I know it sounds a little clunky, but another option could be to use a chain of detail readers/writers? If you set the primary detail reader load factor to 100% the actual delay is likely to be pretty
minimal...

So you'd have:

NAS->Outer Server->Detail Writer (Primary)->Detail Reader->Detail Writer Queue 1
							 ->Detail Writer Queue 2
							 ->Detail Writer Queue n.

Detail Reader Queue 1 -> Proxy Server
Detail Reader Queue 2 -> Proxy Server
Detail Reader Queue n -> Proxy Server

That way the NAS always receives a response, and you get pseudo parallel Accounting requests going to the proxy server.

To balance between the detail writers you can use the load-balance unlang stanza, or just the expressions module with the modulo operator.


> 
>>> I'm adapting robust-proxy-accounting for our environment and can't
>>> figure out how (or if it's possible) to get FreeRADIUS to respond to the
>>> originating NAS when proxying fails and the detail is logged for later
>>> proxying.
>>
>> Yep that's a good idea if the data is time critical, it also allows
>> multiple requests to be forwarded in parallel.
> 
> nod, this is my preference. Unfortunately (as I mentioned above), I haven't
> been able to figure out if/how it's possible to have FreeRADIUS always
> respond to the NAS, even when the proxy isn't responding and accounting is
> spooled to the detail file for later processing.

I don't think it is. It'd be a nice thing to have, but I suspect quite hard to actually implement.

- -Arran

- -- 
Arran Cudbard-Bell <A.Cudbard-Bell at sussex.ac.uk>,
Systems Administrator (AAA),
Infrastructure Services (IT Services),
E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT
DDI+FAX: +44 1273 873900 | INT: 3900
GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqTs6EACgkQcaklux5oVKL8ngCfUe9KbYiyi9+sQbKOcrNyPcX7
jyQAnixL+xx6Jj64x+MtcWAW2GtskQRu
=nKD4
-----END PGP SIGNATURE-----