[RADIATOR] Gossip protocol + Status-Server request

[Stefan Paetow]

Hi Heikki, 

Thank you very much for that. I have one more question: Am I correct in assuming that if a server responds with an Access-Reject in response to a Status-Server message, it is still marked as alive? From what I understand, either Access-Accept or Access-Reject is acceptable in that regard?

With Kind Regards

Stefan Paetow
Federated Roaming Technical Specialist

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp at jabber.dev.ja.net
skype: stefan.paetow.janet


In line with government advice, at Jisc we’re now working from home and our offices are currently closed. Read our statement on coronavirus <https://www.jisc.ac.uk/about/corporate/coronavirus-statement>.

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
 

On 13/07/2021, 10:17, "radiator on behalf of Heikki Vatiainen" <radiator-bounces at lists.open.com.au on behalf of hvn at open.com.au> wrote:

    Didn't get the message through the list for some reason - replying 
    indirectly.

    When FarmSize is set, the workers message via Gossip backend (currently 
    Redis) about reachability of the next hop. By default all workers use 
    Status-Server probes. However, it's likely that this probing is 
    excessive, so you should try something like this:

    # see goodies/farmsize.cfg for a full example
    <Gossip>
        # Parameters
    </Gossip>

    <AuthBy RADIUS,RADSEC,HASHBALANCE,etc.>
        Gossip
        UseStatusServerForFailureDetect
        KeepaliveTimeout 5
        NoKeepaliveTimeoutForChildInstances
        # Other parameters
    </AuthBy>

    To summarise: with the above one worker (instance #1) does the probing 
    and uses Redis to keep the other workers informed about the next hop 
    reachability.

    Thanks,
    Heikki

    -- 
    Heikki Vatiainen <hvn at open.com.au>

    Radiator: the most portable, flexible and configurable RADIUS server
    anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
    EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
    DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
    _______________________________________________
    radiator mailing list
    radiator at lists.open.com.au
    https://lists.open.com.au/mailman/listinfo/radiator