[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