summaryrefslogtreecommitdiffstats
path: root/man/man8/radrelay.8
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:49:46 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:49:46 +0000
commit50b37d4a27d3295a29afca2286f1a5a086142cec (patch)
tree9212f763934ee090ef72d823f559f52ce387f268 /man/man8/radrelay.8
parentInitial commit. (diff)
downloadfreeradius-50b37d4a27d3295a29afca2286f1a5a086142cec.tar.xz
freeradius-50b37d4a27d3295a29afca2286f1a5a086142cec.zip
Adding upstream version 3.2.1+dfsg.upstream/3.2.1+dfsgupstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'man/man8/radrelay.8')
-rw-r--r--man/man8/radrelay.849
1 files changed, 49 insertions, 0 deletions
diff --git a/man/man8/radrelay.8 b/man/man8/radrelay.8
new file mode 100644
index 0000000..99e6573
--- /dev/null
+++ b/man/man8/radrelay.8
@@ -0,0 +1,49 @@
+.TH RADRELAY 8 "23 October 2007" "" "FreeRADIUS Daemon"
+.SH NAME
+radrelay -- Deprecated command.
+.SH DESCRIPTION
+The functions of \fIradrelay\fP have been added to \fIradiusd\fP. One
+benefit is that one instance of \fIradiusd\fP can read multiple detail
+files, among others.
+.PP
+The \fIrlm_sql_log\fP module does something similar, but for SQL
+queries. See it's man page for details.
+.SH "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 to 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.
+.SH "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 noticeable 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.
+.SH SEE ALSO
+.BR radiusd(8),
+.BR rlm_sql_log(5)
+.SH AUTHOR
+The FreeRADIUS Server Project