
             Accounting replication with radrelay.


0. INTRODUCTION

   Often people 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.

   That means you miss accounting records or must jump through hoops
   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.

1. REPLICATION

   Radrelay is a program that does the equivalent of tail(1) on a
   accounting detail file. Each time the server writes a packet
   to this file, radrelay reads it and sends it to a remote radius
   server. If all works well, radrelay gets replies from the remote
   server as it should. When it reaches end-of-file, it locks the
   file, renames it to <filename>.work, and waits for all it's
   accounting requests to get answered. As soon as they are
   answered, <filename.work> is deleted.

   When radrelay starts up it first checks for <filename.work>
   before it starts processing the standard detail file. This
   ensures that no packets get lost.

   Even if the primary server is down for a day, or if the secondary
   server crashes and reboots, radrelay will buffer the accounting
   packets and send them to the remote accounting server.

   Radrelay checks the "Client-IP-Address" attribute in each record,
   and if it's the same as the remote server it will not replicate
   that record to prevent loops. That means you can point radrelay
   to the primary server on the backup host, and to the backup server
   on the primary host, to have complete records on both.

2. USAGE

   First, you have to make radiusd log to an extra, single detail file.
   In radiusd 1.6.5 you can use the command line argument "-F" multiple
   times - the first invocation will override the default detail file
   name/location, additional invocations will add detail files.
   It is also not very useful to have radwtmp on a backup server,
   so turn that off with "-w".

   I run radiusd as:

   radiusd -y -w -F %N/detail -F detail.rep

   This makes radiusd write the accounting records to the standard
   location _and_ to a single detail.rep file. Ofcourse writing to
   the standard location is optional - I usually enable it just so
   that I can keep an eye on it and see what accounting data is
   received by the server.

   Then I run 'radrelay' as:

   radrelay -a /var/log/radacct <server> detail.rep

   This makes radrelay replicate to the server <server>. It reads its
   input from "detail.rep", truncating it regulary - you shouldn't
   rotate it nightly, or clean it up by hand.

   <server> must have an entry in /etc/raddb/clients.


3. REPLICATION AND PROXYING

   If you have a primary and a backup server with identical configs
   that both proxy for certain realms to other radius servers, the
   remote server might end up with duplicate accounting info - the
   accounting packet is received by the backup server, proxied to
   the remote server and replicated to the primary server, then the
   primary server proxies the same packet to the remote radius server
   again because it doesn't know that that was already done.

   To prevent this scenario, Cistron Radius writes an extra attribute
   to the detail file if it has proxied the accounting packet, the
   vendor-specific attribute 'Cistron-Proxied-To'. It contains the
   address of the remote radius server. Radrelay replicates this
   attribute just like any other to the primary server. If the
   primary server wants to proxy an accounting packet to a remote
   radius server, it first checks the packet to see if the
   'Cistron-Proxied-To' attribute is present. If it is, and it
   contains the IP address of the remote radius server, it knows
   that it doesn't need to proxy this packet to the remote server
   once more. Problem solved!

4. NOTES

   Only attributes that are defined in the dictionary are replicated.
   Unknown attributes are simply ignored.

   Radrelay doesn't re-read its config files on a SIGHUP. It uses
   two config files - the dictionary (which can consist of multiple
   files ofcourse if you use $INCLUDE) and the "clients" file. If
   you modify one of those files you need to restart radrelay.


	$Id: README.radrelay,v 1.4 2001/12/19 21:09:01 miquels Exp $

