radrelay in 1.1.x and in 2.x
aland at deployingradius.com
Thu Mar 8 11:56:39 CET 2007
Geoffroy Arnoud wrote:
> There's a program named radrelay in branch_1_1 and there's a way
> of launching FreeRADIUS in HEAD that is called 'radrelay'.
> It seems that the difference between them is that radrelay program
> disappeared to be merged with radiusd.
> Are the behaviours of radrelay program and radiusd/radrelay different.
The functionality is similar, the behaviors are different.
In 1.1.x, if you want to log to a "detail" file, and then later write
that information to SQL, you would need a radiusd to write the detail
file, radrelay to read it, and another radiusd to accept the packets
from radrelay, and write them to SQL.
In 2.0, the two "radrelay + radiusd" programs have been replaced with
"radiusd -n radrelay". With slightly more work, all of that could be
replaced by one copy of radiusd, which would be much better.
> It seems that radrelay program sends the request to only one radius
> server until it gets a response and that the requests are sent
> to the same server.
> For radiusd/radrelay, it seems that the behaviour is configurable
> with modules and so on, but, is the proxy behaviour different?
No. FreeRADIUS can send a packet to one home server, and only one
> My problem is that I would like to send accounting requests the
> more reliably as possible. I mean that if I have 3 remote
> servers for a given realm and that at east one is available,
> I want my accounting request to be sent to the alive server.
> FreeRADIUS could try the first remote server, if dead, try
> the second server, if dead try the last server...
That failover is already part of radiusd. The re-transmission of
accounting requests when there's no response SHOULD be part of the new
"integrated radrelay" code, but it isn't there yet. It shouldn't be too
hard to add, though...
> For accounting, this has 2 main advantages:
> - If at least one remote server is up, the request is delivered
> - If several remote servers are dead, they are all marked dead
> with only one accounting request
It will take more than that. You don't want to mark a server dead if
it doesn't respond to *one* packet. But I do know what you mean...
> For authentication request, our position is that synchronous proxy
> is the best approach - given that dead server timers can evolve
> to become very flexible (per NAS, based on RADIUS request content...).
> Maybe this is not very complicated to implement, with a well
> written module and a small modification of proxy code
> in request_list.c?
That code is being re-written in the CVS head. It will be infinitely
better than what's there now. i.e. simpler, smaller, easier to
understand, and with more functionality.
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
More information about the Freeradius-Devel