3.54. <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE>, <AuthBy LOADBALANCE>, <AuthBy HASHBALANCE>, <AuthBy EAPBALANCE>

These authentication methods are sub-types of <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.
These authentication methods understand all the same parameters as <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.
Note
See an example config file showing how to use various load balancing modules in goodies/proxyalgorithm.cfg in the Radiator distribution.

3.54.1. <AuthBy ROUNDROBIN>

<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.
The result of this algorithm is to distribute the load equally amongst all the currently operational remote RADIUS servers.
<AuthBy ROUNDROBIN> supports the same parameters as Section 3.42. <AuthBy RADIUS>.

3.54.2. <AuthBy VOLUMEBALANCE>

When using <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.
The result of this algorithm is to distribute the load amongst all the currently operational remote RADIUS servers, according to the relative values of their BogoMips values. For more information about configuring the BogoMips parameter, see Section 3.43.1. BogoMips.
<AuthBy VOLUMEBALANCE> supports the same parameters as Section 3.42. <AuthBy RADIUS>.

3.54.3. <AuthBy LOADBALANCE>

When using <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.
The result of this algorithm is to distribute the load until the BogoMips-weighted response time is the same for all servers. This allows the load balancing to adapt to the changes in the available processing capacity of a remote host.
For more information about configuring the BogoMips parameter, see Section 3.43.1. BogoMips.

Example

In this example, Radiator running by itself on a host distributes RADIUS requests to 3 remote servers. The second host has twice the processing power of the others, and therefore gets twice as many requests as the other 2.
....
# 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>

3.54.4. <AuthBy HASHBALANCE>

<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.
When using <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>.
The 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

3.54.5. <AuthBy EAPBALANCE>

<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.
CAUTION
When EAPBALANCE is used in a ServerFarm architecture to proxy requests to a set of back end RADIUS servers, the duplicate detection in the back end servers can be defeated by changes to requests made by the server farm. It is therefore essential that all the backend servers in such an architecture have the UseContentsForDuplicateDetection flag set in the receiving Client clauses.
Note
See an example config file showing how to use EAPBALANCE in goodies/eapbalance.cfg in the Radiator distribution.
<AuthBy EAPBALANCE> supports the same parameters as Section 3.42. <AuthBy RADIUS>.