Re: Reemission bug in multi-threaded mode + FreeRADIUS 2.0 roadmap questions
<!-- DIV {margin:0px;}-->I apologize for being insistent, but I'm sending again this mail, as I did not receive a response since last week. We would like to have more precise information about what will be exactly in release 2.0 regarding FreeRADIUS retransmissions. This is important to us, because RADIUS retransmissions are a critical part of our system. Thanks a lot. Regards, Nicolas.
It seems that "request->proxy" is 0 when the condition is tested, thus, FreeRADIUS considers there is no proxy outstanding for this request.
Yes. It's an issue, but a minor one. The solution is to always make the server synchronous, which has been done in the CVS head.
Alan DeKok.
I agree this is a minor issue. Setting up the serveur in synchronous mode is much simpler, although I think we would lose a few features that we need. Detecting a proxy server is dead and failover to a backup server is important to us. In the current 1.1.3 version, failover is possible only in asynchronous mode. Will failover still be possible in the next release of FreeRADIUS ? Also, we need to detect that a given proxied request did not receive any response, in order to send back a specific response to the NAS (Reject or Accept). Would it be possible in synchronous mode ? Will the possibility to choose between synchronous and asynchronous remain in the CVS head, or do you plan to completely remove asynchronous mode ? One more point about synchronous mode : currently, timeout and retries parameters are global to FreeRADIUS in the "proxy server" configuration section. If the retransmission mode is synchronous, wouldn't these parameters have to be defined per NAS, for instance in the clients.conf file ? each NAS can have different values for these settings. Nicolas. ___________________________________________________________________________ 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
Chaigneau Nicolas <chaigneaun@yahoo.fr> wrote:
Setting up the serveur in synchronous mode is much simpler, although I think we would lose a few features that we need.
No.
Detecting a proxy server is dead and failover to a backup server is important to us. In the current 1.1.3 version, failover is possible only in asynchronous mode. Will failover still be possible in the next release of FreeRADIUS ?
Yes.
Also, we need to detect that a given proxied request did not receive any response, in order to send back a specific response to the NAS (Reject or Accept). Would it be possible in synchronous mode ?
Not right now. As always, patches are welcome.
Will the possibility to choose between synchronous and asynchronous remain in the CVS head, or do you plan to completely remove asynchronous mode ?
The asynchronous code has already been removed in the CVS head.
One more point about synchronous mode : currently, timeout and retries parameters are global to FreeRADIUS in the "proxy server" configuration section.
Those configurations have been removed in the CVS head.
If the retransmission mode is synchronous, wouldn't these parameters have to be defined per NAS, for instance in the clients.conf file ?
No. The settings are on the *NAS*, not in the clients.conf file on the server. If you want to change the settings log into the NAS. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Chaigneau Nicolas <chaigneaun@yahoo.fr> wrote:
Setting up the serveur in synchronous mode is much simpler, although I think we would lose a few features that we need.
No.
Detecting a proxy server is dead and failover to a backup server is important to us. In the current 1.1.3 version, failover is possible only in asynchronous mode. Will failover still be possible in the next release of FreeRADIUS ?
Yes.
Also, we need to detect that a given proxied request did not receive any response, in order to send back a specific response to the NAS (Reject or Accept). Would it be possible in synchronous mode ?
Not right now. As always, patches are welcome.
Will the possibility to choose between synchronous and asynchronous remain in the CVS head, or do you plan to completely remove asynchronous mode ?
The asynchronous code has already been removed in the CVS head.
One more point about synchronous mode : currently, timeout and retries parameters are global to FreeRADIUS in the "proxy server" configuration section.
Those configurations have been removed in the CVS head.
If the retransmission mode is synchronous, wouldn't these parameters have to be defined per NAS, for instance in the clients.conf file ?
No. The settings are on the *NAS*, not in the clients.conf file on the server. If you want to change the settings log into the NAS.
Let me illustrate our situation and let's see if the same can be achieved in synchronous mode. We operate a proxy radius for a DSL service in Greece. For each realm (around 5 realms) we maintain a primary and a backup radius server. What we don't want to happen is for the *NAS* to mark the *proxy* radius dead because one home proxy is not responding. That's where asynchronous mode comes useful. We set retry_delay * retry_times * number of home servers < retry_delay * retry_times on the NAS so that we can mark home servers and realms dead *before* the NAS marks the whole proxy radius service dead (which we want to avoid except if the proxy service itself is not available). How can we achieve a similar setup in synchronous mode?
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Let me illustrate our situation and let's see if the same can be achieved in synchronous mode. We operate a proxy radius for a DSL service in Greece. For each realm (around 5 realms) we maintain a primary and a backup radius server. What we don't want to happen is for the *NAS* to mark the *proxy* radius dead because one home proxy is not responding. That's where asynchronous mode comes useful. We set retry_delay * retry_times * number of home servers < retry_delay * retry_times on the NAS so that we can mark home servers and realms dead *before* the NAS marks the whole proxy radius service dead (which we want to avoid except if the proxy service itself is not available). How can we achieve a similar setup in synchronous mode?
Hi, I work with Nicolas who did send the first mail. We are facing the same problematic, as we are implementing a RADIUS proxy, interconnecting lots of access networks with lots of home networks. We are not directly linked to NASes, but with access networks RADIUS servers. We are developping a patch to allow timeout/retires to be configured for each realm, but onr can imagine a configuration per relationship (access network / home network) I think that synchronous is not bad, but for such implentations, a way must be find to allow FreeRADIUS to detect that the proxying failed, and maybe execute some module on such an event (post-proxy section?). On could think of attaching TO/retries (or expiration timer) to incoming requests, matching the NAS that originated the request, based on RADIUS attributes for example. 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 <garnoud@yahoo.co.uk> wrote:
I think that synchronous is not bad, but for such implentations, a way must be find to allow FreeRADIUS to detect that the proxying failed, and maybe execute some module on such an event (post-proxy section?).
Yes. Post-proxy section "noreply" would be useful. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Kostas Kalevras <kkalev@noc.ntua.gr> wrote:
What we don't want to happen is for the *NAS* to mark the *proxy* radius dead because one home proxy is not responding.
Exactly.
We set retry_delay * retry_times * number of home servers < retry_delay * retry_times on the NAS so that we can mark home servers and realms dead *before* the NAS marks the whole proxy radius service dead (which we want to avoid except if the proxy service itself is not available). How can we achieve a similar setup in synchronous mode?
By setting a "mark proxy dead after X seconds" configuration option. But the proxies retransmission timers for packets are not the same as the above configuration. That configuration item will have to be added, of course, and some code changed. But having the proxy originate packets at various intervals is not a good idea. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
--- Alan DeKok <aland@deployingradius.com>
By setting a "mark proxy dead after X seconds" configuration option. But the proxies retransmission timers for packets are not the same as the above configuration.
That sounds interesting. I suppose that this configuration could be a *per realm* parameter? 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 <garnoud@yahoo.co.uk> wrote:
That sounds interesting. I suppose that this configuration could be a *per realm* parameter?
Again, why per realm? The should be at least one setting: global. Then, maybe per *NAS* settings, because the timeouts may be different on each NAS. To put it another way, the problem is the NAS timing out and thinking you're dead because some home server is down. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
--- Alan DeKok <aland@deployingradius.com>:
Geoffroy Arnoud <garnoud@yahoo.co.uk> wrote:
That sounds interesting. I suppose that this configuration could be a *per realm* parameter?
Again, why per realm? The should be at least one setting: global. Then, maybe per *NAS* settings, because the timeouts may be different on each NAS.
To put it another way, the problem is the NAS timing out and thinking you're dead because some home server is down.
Ok, sorry for not being enough specific. I agree that it is linked to the NAS, or I whould say, the RADIUS client that initiated the original request, in the case where the request goes thourgh several proxies. We can imagine that several NAS with dirrent TO/retries are sending packets that comes to freeradius through a unique RADIUS proxy. Here is a quick sample of what RADIUS interconnections can be in our case. Our implemenation is *FreeRADIUS*. NAS1 | +->RADIUS Server 1 +->RADIUS Server A | | +->RADIUS proxy-->*FreeRADIUS* | ^ | +->RADIUS Server 2 | +->RADIUS Server B | | NAS2 | | +->RADIUS Server 3 | NAS3 In this case, we need to set the expiration time by identifying the network (1, 2 or 3) that originated the request (based on RADIUS attributes). As always, thank you for the answers you gave. 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
participants (4)
-
Alan DeKok -
Chaigneau Nicolas -
Geoffroy Arnoud -
Kostas Kalevras