NAME
radrelay -- Deprecated command.
DESCRIPTION
The functions of radrelay have been added to radiusd. One benefit is
that one instance of radiusd can read multiple detail files, among
others.
The rlm_sql_log module does something similar, but for SQL queries.
See it’s man page for details.
REPLICATION FOR BACKUPS
Many sites run multiple radius servers; at least one primary and one
backup server. When the primary goes down, most NASes detect that and
switch to the backup server.
That will cause your accounting packets to go the the backup server -
and some NASes don’t even switch back to the primary server when it
comes back up.
The result is that accounting records are missed, and/or the
administrator must jump through hoops in order to combine the different
detail files from multiple servers. It also means that the session
database ("radutmp", used for radwho and simultaneous use detection)
gets out of sync.
We solve this issue by "relaying" packets from one server to another,
so they both have the same set of accounting data.
See raddb/sites-available/buffered-sql for more information.
BUFFERING FOR HIGH-LOAD SERVERS
If the RADIUS server suddenly receives a many accounting packets, there
may be insufficient CPU power to process them all in a timely manner.
This problem is especially noticable when the accounting packets are
going to a back-end database.
Similarly, you may have one database that tracks "live" sessions, and
another that tracks historical accounting data. In that case,
accessing the first database is fast, as it is small. Accessing the
second database many be slower, as it may contain multiple gigabytes of
data. In addition, writing to the first database in a timely manner is
important, while data may be written to the second database with a few
minutes delay, without any harm being done.
See raddb/sites-available/copy-to-home-server for more information.
SEE ALSO
radiusd(8), rlm_sql_log(5)
AUTHOR
The FreeRADIUS Server Project
23 October 2007