Note: Use <AuthBy HASHBALANCE> with
new configurations and consider migrating current configurations from
<AuthBy EAPBALANCE> to <AuthBy
HASHBALANCE>. <AuthBy
HASHBALANCE> has better interoperability with different
RADIUS implementations.
<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.
