Version 4 has been under heavy development for the past year. The goal is to enable new features and new capabilities. Well, we're making progress. :) As background, in v4 proxying has been replaced by a "radius" module. The "radius" module sends RADIUS packets and waits (asynchronously) for a response. You can create one "radius" module for each home_server. e.g. radius home_server_1 { ... ip, port, secret, etc. } This also means that proxy.conf goes away (sorry), and that home_server_pools get replaced with "unlang": Home server pool *type = load-balance` gets replaced with 'unlang' load-balance { home_server_1 home_server_2 home_server_3 } Even better, you can now add proxying *anywhere*: if (User-Name == "bob") { home_server_1 } else if (User-Name == "doug") { home_server_2 } Or you can proxy multiple times: if (User-Name == "bob") { home_server_1 home_server_2 } Or catch proxy failures: home_server_1 if (fail) { linelog } Or (even more magically), proxy to multiple destinations at the same time: parallel { home_server_1 home_server_2 home_server_3 } i.e. it sends packets t home_server_1, then 2, then 3. It waits until it receives responses (or timeouts) from all of them. It then continues with processing the request. We're still not recommending average people install v4. There are some caveats which means it's best suited for people who know those caveats. But, the long wait has been worth it, I think. Things which used to be impossible in previous versions of the server are now *trivial* to do. The next step is to finalize the functionality which creates child requests. e.g. originate-coa, but more standardized. Once that's done, you should be able to do something like: if (... bandwidth exceeded...) { create child Disconnect-Request send to NAS } Which mimics the "originate-coa" functionality, but in 3 unlang statements. You can also take an Access-Request, and create one (or more) Accounting-Requests which are sent to home servers. The "radius" module also supports a "fire and forget" method, so that you can send packets to home servers, and continue without waiting for a response. We hope to release an alpha of version 4 this fall. Alan DeKok.
noted the commit..was going to ask, and this timely email reminds me
Home server pool *type = load-balance` gets replaced with 'unlang'
load-balance { home_server_1 home_server_2 home_server_3 }
what about dealing with EAP - ie so that the request goes back to the the same home_server instance? how is EAP load-balanced backends or remote proxies dealt with ?
Or catch proxy failures:
home_server_1 if (fail) { linelog }
handy - but what about the logic that marks that server as dead/zombie? can that call to home_server_1 be avoided already if the state of that server is already known?
parallel { home_server_1 home_server_2 home_server_3 }
i.e. it sends packets t home_server_1, then 2, then 3. It waits until it receives responses (or timeouts) from all of them. It then continues with processing the request.
can it not carry on as soon as one reply gets back? PS 'trivial to do' if you know the language and the tool. please ensure you avoid the curse of knowledge ;-) alan
On Aug 29, 2017, at 8:14 AM, Alan Buxey <alan.buxey@gmail.com> wrote:
what about dealing with EAP - ie so that the request goes back to the the same home_server instance? how is EAP load-balanced backends or remote proxies dealt with ?
The "load-balance" keyword now takes an option: load-balance "%{Calling-Station-Id}" { home_server_1 home_server_2 ... } This is the same as the v3 proxying "keyed" load-balance . The difference is that it also works for SQL databases! load-balance "%{User-Name}" { sql1 sql2 ... } Which gets you pretty simple sharding... See raddb/README.md in the latest v4.0.x for more on proxying and the "Radius" module.
Or catch proxy failures:
home_server_1 if (fail) { linelog }
handy - but what about the logic that marks that server as dead/zombie? can that call to home_server_1 be avoided already if the state of that server is already known?
Mostly, yes... the difference in v4 is that the radius module deals with connections. i.e. home server state is per connection, not global. Right now, it tries hard to proxy requests. Which means sitting on them until either there's a timeout, or until the home server becomes alive again. But yes, it would be good to have an "early fail" configuration. "if down, don't add more requests, and just skip this home server"
parallel { home_server_1 home_server_2 home_server_3 }
i.e. it sends packets t home_server_1, then 2, then 3. It waits until it receives responses (or timeouts) from all of them. It then continues with processing the request.
can it not carry on as soon as one reply gets back?
That's reasonable, but requires some minor code changes.
PS 'trivial to do' if you know the language and the tool. please ensure you avoid the curse of knowledge ;-)
Well, it will all be well documented before v4 is released. The "trivial to do" means that in v3, it was impossible. In v4, it's 5 lines of configuration "parallel ...", followed by configuring 4 "radius" modules. Alan DeKok.
On Aug 29, 2017, at 8:14 AM, Alan Buxey <alan.buxey@gmail.com> wrote:
handy - but what about the logic that marks that server as dead/zombie? can that call to home_server_1 be avoided already if the state of that server is already known?
As of yesterday, yes. Just set "no_connection_fail = yes" in the radius module configuration.
parallel { home_server_1 home_server_2 home_server_3 }
i.e. it sends packets t home_server_1, then 2, then 3. It waits until it receives responses (or timeouts) from all of them. It then continues with processing the request.
can it not carry on as soon as one reply gets back?
As of yesterday yes: parallel { home_server_1 { ok = return } home_server_2 { ok = return } home_server_2 { ok = return } } Will return from the "parallel" section as soon as the first module returns "ok". There's more to do before 4.0 is ready for a general release, but I can see many people switching to it soon for the magical new features. :) Alan DeKok.
participants (2)
-
Alan Buxey -
Alan DeKok