[RADIATOR] How to combine HASHBALANCE with AuthBy RadSec?
Heikki Vatiainen
hvn at open.com.au
Fri Oct 30 10:18:57 CDT 2015
On 14.9.2015 13.36, Tuure Vartiainen wrote:
>> On 09/08/2015 11:12 AM, Tuure Vartiainen wrote:
>>> We’ll add a Gossip support for RadSec later, probably to 4.16 patches, and look
>>> into implementing equivalent balancing support for RadSec as what there is currently
>>> for RADIUS:
>>>
>>> AuthEAPBALANCE.pm
>>> AuthHASHBALANCE.pm
>>> AuthLOADBALANCE.pm
>>> AuthVOLUMEBALANCE.pm
>>> AuthROUNDROBIN.pm
>>> AuthRADIUSBYATTR.pm
>>
>> Do you have time plan for this?
>>
>> I'm interested in early access to that code, I can offer my time for betatesting. I know Perl so I can also debug problems if necessary.
>>
>
> Not currently, I’ll get back to this after 4.16 has been released.
AuthBy RADSEC Gossip support is now in 4.16 patches. It's a little
different from AuthBy RADIUS. Main things are:
1) Messages looped back from Gossip can be handled by the sender radiusd
instance. Only the AuthBy RADSEC clause that originated the report will
ignore. With RADIUS, the looped back report was ignored by the
originating radiusd.
This allows the same radiusd instance have the same next hop defined in
multiple AuthBys while allowing the other AuthBys to see the change in
next hop reachability.
2) Next hop is recognised by its configured name and port. Using <Host
a.example.com> as an example, if the report tells a.example.com:2083 is
down, that's enough. The exact IP address that just became unreachable
does not need to match. With RADIUS, multihomed hosts were marked down
only if the report had matching IP.
The idea behind this is that the radiusd instances that share
information should be configured similarly so that 'a.example.com' means
the same next hop instance for each radiusd no matter which IP address
they got from the DNS.
Change 1) is likely something that AuthBy RADIUS could benefit from too.
Change 2) might be more useful for RadSec than plain RADIUS proxying?
What comes to the proxy algorithms, there's nothing in the patches yet.
We thought about adding them as configuration options instead of
creating separate modules. Most of the differences are just in
overriding the next hop selection algorithm for correct balancing.
Any comments and suggestions are welcome. The proxy algorithm changes
should start appearing in 4.16 patches soon.
Thanks,
Heikki
--
Heikki Vatiainen <hvn at open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
More information about the radiator
mailing list