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 <h...@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. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator