Table of contents: Radiator® AAA Server
3.53 - <AuthBy DYNADDRESS>
3.55 - <AuthBy LDAPRADIUS>
<AuthBy
RADIUS> but they also do load distribution and balancing.
They allow you to proxy RADIUS requests to any number of remote RADIUS
servers and to distribute the RADIUS load amongst those servers. Further,
if any remote server fails to reply to a proxied request, the remote
server is marked as unavailable until the
FailureBackoffTime expires. During that period, no
requests are proxied to that remote RADIUS server.<AuthBy RADIUS>. For more information, see
Section 3.42. <AuthBy RADIUS>. The only
difference between them and <AuthBy RADIUS> is
the algorithm for choosing which remote host to proxy to and how the
received and dropped responses provide feedback for the host selection
algorithm.goodies/proxyalgorithm.cfg in the Radiator
distribution.<AuthBy ROUNDROBIN> distributes
RADIUS requests to the servers. The first incoming RADIUS request is
proxied to the first server listed, the next to the second listed and so
on, until the list is exhausted. Then it starts again at the top of the
list. If at any time a proxied request does not receive a reply from a
remote server, that server is marked as unavailable until
FailureBackoffTime seconds has elapsed. Meanwhile
that request is retransmitted to the next host due to be used.<AuthBy
ROUNDROBIN> supports the same parameters as Section 3.42. <AuthBy RADIUS>.<AuthBy VOLUMEBALANCE>,
the incoming RADIUS requests are distributed between all the listed hosts
according to the relative values of their BogoMips attributes. BogoMips is
a relative measure of the processing power of that host. A
Host with a BogoMips rating of 2 receives twice as
many request as one with the default BogoMips rating of 1. If at any time
a proxied request does not receive a reply from a remote server, that
server is marked as unavailable until
FailureBackoffTime seconds has elapsed. Meanwhile,
that request is retransmitted to the next host due to be used.<AuthBy
VOLUMEBALANCE> supports the same parameters as Section 3.42. <AuthBy RADIUS>.<AuthBy LOADBALANCE>,
the incoming RADIUS requests are distributed between all the listed hosts
according to the relative values of their BogoMips attributes and the time
the remote server takes to process requests. BogoMips is intended to be a
relative measure of the processing power of that host. A
Host with a BogoMips rating of 2 receives twice as
many requests as the one with the default BogoMips rating of 1. Every
request that is proxied and receives a reply has its turnaround time,
which is measured in microseconds. A sliding average response time over
the last 10 request is calculated. Requests are proxied to the server that
is currently responding fastest. If at any time a proxied request does not
receive a reply from a remote server, that server is marked as unavailable
until FailureBackoffTime seconds has elapsed.
Meanwhile, that request is retransmitted to the next host due to be
used.....
# Proxy all requests to remote hosts inside our network:
<Handler>
<AuthBy VOLUMEBALANCE>
# If a host fails, do not send to it again
# for 100 seconds
FailureBackoffTime 100
# Default values for all hosts. You can change
# them for a single host in a Host clause
Secret mysecret
RetryTimeout 1
Retries 1
# Hosts to send to are listed below
<Host 203.63.154.2>
</Host>
<Host 203.63.154.3>
BogoMips 2
</Host>
# This host has non-standard ports
<Host 203.63.154.4>
AuthPort 1647
AcctPort 1648
</Host>
</AuthBy>
</Handler>
<AuthBy HASHBALANCE> distributes
RADIUS requests among a set of RADIUS servers so that multiple related
requests from the same user go to the same server unless that server
fails. This prevents the requests being distributed among multiple
servers, which is prone to problems with authentication methods that use
multiple messages, such as EAP.<AuthBy
HASHBALANCE>, a hash number is calculated for each incoming
request. That hash number is based on number of attributes in the incoming
request. It is used to select which host to use. If the selected Host is
unavailable, then the next one on the Host list is used in sequence until
the Host list is exhausted. This results in a random distribution of
requests among the available server, and the same server handles all the
requests related to a single user.<AuthBy
HASHBALANCE> supports the same parameters as Section 3.42. <AuthBy RADIUS>.HashAttributes parameter specifies which attributes
in the incoming request is used to select the server. The default value is
shown below. It is suitable for most use cases.HashAttributes %{Request:Calling-Station-Id}:%n
<AuthBy EAPBALANCE> is similar to
<AuthBy HASHBALANCE> in the aspect that it is
intended to ensure all EAP requests relating to a single session always go
to the same target RADIUS server. It uses the RADIUS State attribute to
track EAP sessions, and therefore relies on all the RADIUS clients
supporting the State attribute similarly. The target server for the first
EAP request in a session is chosen in the same was as <AuthBy
HASHBALANCE>. If you are unsure, try <AuthBy
HASHBALANCE> with new configurations
first.<AuthBy EAPBALANCE> is useful in
installations where all RADIUS clients are known to support the RADIUS
State attribute similarly. This usually covers the network managed by a
single organisation, but is likely to not work with Eduroam or other
roaming services where remote or intermediate proxies may add, change, or
remove the State attribute. With these services, <AuthBy
HASHBALANCE> with the default HashAttributes setting should
ensure correct operation.UseContentsForDuplicateDetection flag set in the
receiving Client clauses.goodies/eapbalance.cfg in the Radiator
distribution.<AuthBy EAPBALANCE>
supports the same parameters as Section 3.42. <AuthBy RADIUS>.