Hi all, I have a question regarding radrelay. 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. 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? 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... 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 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? ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
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...
What happens if I plug radrelay (1_1_x) on a FreeRADIUS, having N remote servers for each given realm. Would I get approximately the same behaviour? ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Geoffroy Arnoud wrote:
What happens if I plug radrelay (1_1_x) on a FreeRADIUS, having N remote servers for each given realm. Would I get approximately the same behaviour?
You would need N copies of the detail file, and N radrelays, but yes, that would work. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
--- Alan DeKok <aland@deployingradius.com> a écrit :
Geoffroy Arnoud wrote:
What happens if I plug radrelay (1_1_x) on a FreeRADIUS, having N remote servers for each given realm. Would I get approximately the same behaviour?
You would need N copies of the detail file, and N radrelays, but yes, that would work.
I mean having: - One FreeRADIUS receiving input acct/auth, forwarding auth and logging acct - One radrelay forwarding acct to another FreeRADIUS, with all the realms defined - The last FreeRADIUS performing async forwarding, retransmissions and dead server detection In that case, only one radrelay is required? Thanks for your answers Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Geoffroy Arnoud wrote:
I mean having: - One FreeRADIUS receiving input acct/auth, forwarding auth and logging acct - One radrelay forwarding acct to another FreeRADIUS, with all the realms defined - The last FreeRADIUS performing async forwarding, retransmissions and dead server detection
I'm not sure what you mean by that... Your previous messages were somewhat clearer. If you want to proxy accounting data to home server A, or if it's down, B, or if it's down, C... then the server already supports that. It's *not* a function of radrelay, it's a function of the server. Radrelay will read the detail file, and send the accounting packets to one RADIUS server. That server will be configured with N home servers, in a fail-over relationship. It will take care of failing over from one server to another, and radrelay won't even know. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Geoffroy Arnoud wrote:
I mean having: - One FreeRADIUS receiving input acct/auth, forwarding auth and logging acct - One radrelay forwarding acct to another FreeRADIUS, with all the realms defined - The last FreeRADIUS performing async forwarding, retransmissions and dead server detection
I'm not sure what you mean by that... Your previous messages were somewhat clearer.
If you want to proxy accounting data to home server A, or if it's down, B, or if it's down, C... then the server already supports that. It's *not* a function of radrelay, it's a function of the server.
Yes, the server does this, but not for only one request. Once server A is detected dead, the accounting request is discarded, no? So the accounting request is not tried on server B. FreeRADIUS needs another accounting-request. With the proposed architecture, When request is discarded, radrelay would not have acct-response, and would therefore try again, this time the FreeRADIUS would fallback to server B and so on. In theory, no Accounting request is lost for the remote severs Regards, Geoffroy ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Geoffroy Arnoud wrote:
Yes, the server does this, but not for only one request. Once server A is detected dead, the accounting request is discarded, no? So the accounting request is not tried on server B. FreeRADIUS needs another accounting-request.
Yes.
With the proposed architecture, When request is discarded, radrelay would not have acct-response, and would therefore try again, this time the FreeRADIUS would fallback to server B and so on. In theory, no Accounting request is lost for the remote severs
Retransmits are the responsibility of the NAS. In this case, radrelay. As I said previously, radrelay doesn't do this in all situations. There may be temporary work-arounds in 1.1.x, but the real solution is to fix radrelay. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
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.
Yes.
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.
Yes.
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 home server.
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...).
Yes.
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. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (2)
-
Alan DeKok -
Geoffroy Arnoud