Re: [RADIATOR] Status-Server changes in patches for Radiator 4.11
On 05/12/2014 02:22 PM, a.l.m.bu...@lboro.ac.uk wrote: Status-Server based failure detection needs two options specified in AuthBy RADIUS or Host within AuthBy RADIUS: - Flag: UseStatusServerForFailureDetect - Integer: KeepaliveTimeout numsec what is the interplay/interaction with RADSEC for this StatusServer method? It is similar to AuthBy RADIUS. That is, when there is no traffic, Status-Server is requested from the RadSec peer. If the peer does not respond, then it is marked as being down. This is similar to when Status-Server is not used and the peer does not reply to requests. Is this what you were thinking of? Here's a quick summary for those who are thinking if they should enable Status-Server or not. This is likely familiar to eduroam folks: In roaming scenarios Status-Server is better since the next hop can be just fine but there's a remote server which is dead and does not respond. However, if RadSec is used locally, then it might be better to rely on ignored requests when it is known that a server will stop responding when it has for example, lost its connection to the backend DB. 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
Re: [RADIATOR] Status-Server changes in patches for Radiator 4.11
Hi, Status-Server based failure detection needs two options specified in AuthBy RADIUS or Host within AuthBy RADIUS: - Flag: UseStatusServerForFailureDetect - Integer: KeepaliveTimeout numsec what is the interplay/interaction with RADSEC for this StatusServer method? cheers alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Status-Server changes in patches for Radiator 4.11
On 06/19/2013 10:35 AM, Heikki Vatiainen wrote: The patch set for Radiator 4.11 now has changes to make Status-Server based detection of failed Hosts more reliable especially when there is more than one Host defined for AuthBy RADIUS or its subclasses. These changes are now available for AuthBy RADSEC too. Status-Server based alive checking should now work similarly for both AuthBy RADIUS and its subclasses and AuthBy RADSEC when UseStatusServerForFailureDetect is enabled. Comments and test reports are welcome! Indeed. Especially reports against different RadSec implementations. Currently Proxy-State attribute is used in Status-Server probes, just as with any other requests over RadSec, and it would be good to hear if this is compatible with other RadSec implementations too. 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
[RADIATOR] Status-Server changes in patches for Radiator 4.11
The patch set for Radiator 4.11 now has changes to make Status-Server based detection of failed Hosts more reliable especially when there is more than one Host defined for AuthBy RADIUS or its subclasses. Using Status-Server for active probing is an alternative of using the lack of responses for normal requests from the next hop Host to detect failures. Status-Server is useful for proxying environments, such as eduroam, where the lack of response from the next hop Host may be caused by a server far away failing to respond. Basing failure detection on lack of responses for normal requests can help detecting authentication backend failures that are happening nearby. For example, when Radiator can not connect to an SQL database while it is otherwise working, it can ignore the request and the previous hop can then try another Host. Status-Server based failure detection needs two options specified in AuthBy RADIUS or Host within AuthBy RADIUS: - Flag: UseStatusServerForFailureDetect - Integer: KeepaliveTimeout numsec When UseStatusServerForFailureDetect is enabled only a valid response from the next hop Host will make it eligible for forwarding again. The other option specifies how frequently the Status-Server messages are sent when there is no other traffic to forward to the next hop Host. Status-Server uses Retries, RetryTimeout and other variables as defined in the reference manual 'Failure algorithm' section. The only difference is that FailureBackoffTime is not used. The failed Host will stay down until there is a valid response to a Status-Server probe (or in special cases, some other request generated by Hooks etc.). Please see the details and other changes in the patch set description. Comments and test reports are welcome! 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
