raddb/sites-available/robust-proxy-accounting

   1 # -*- text -*-
   2 ######################################################################
   3 #
   4 #       This is a sample configuration for robust proxy accounting.
   5 #       accounting packets are proxied, OR logged locally if all
   6 #       home servers are down.  When the home servers come back up,
   7 #       the accounting packets are forwarded.
   8 #
   9 #       This method enables the server to proxy all packets to the
  10 #       home servers when they're up, AND to avoid writing to the
  11 #       detail file in most situations.
  12 #
  13 #       In most situations, proxying of accounting messages is done
  14 #       in a "pass-through" fashion.  If the home server does not
  15 #       respond, then the proxy server does not respond to the NAS.
  16 #       That means that the NAS must retransmit packets, sometimes
  17 #       forever.  This example shows how the proxy server can still
  18 #       respond to the NAS, even if all home servers are down.
  19 #
  20 #       This configuration could be done MUCH more simply if ALL
  21 #       packets were written to the detail file.  But that would
  22 #       involve a lot more disk writes, which may not be a good idea.
  23 #
  24 #       This file is NOT meant to be used as-is.  It needs to be
  25 #       edited to match your local configuration.
  26 #
  27 #       $Id$
  28 #
  29 ######################################################################
  30
  31 #  (1) Define two home servers.
  32 home_server home1.example.com {
  33         type = acct
  34         ipaddr = 192.0.2.10
  35         port = 1813
  36         secret = testing123
  37
  38         #  Mark this home server alive ONLY when it starts being responsive
  39         status_check = request
  40         username = "test_user_status_check"
  41
  42         #  Set the response timeout aggressively low.
  43         #  You MAY have to increase this, depending on tests with
  44         #  your local installation.
  45         response_window = 6
  46 }
  47
  48 home_server home2.example.com {
  49         type = acct
  50         ipaddr = 192.0.2.20
  51         port = 1813
  52         secret = testing123
  53
  54         #  Mark this home server alive ONLY when it starts being responsive
  55         status_check = request
  56         username = "test_user_status_check"
  57
  58         #  Set the response timeout aggressively low.
  59         #  You MAY have to increase this, depending on tests with
  60         #  your local installation.
  61         response_window = 6
  62 }
  63
  64 #  (2) Define a virtual server to be used when both of the
  65 #  home servers are down.
  66 home_server acct_detail.example.com {
  67         virtual_server = acct_detail.example.com
  68 }
  69
  70 #  Put all of the servers into a pool.
  71 home_server_pool acct_pool.example.com {
  72         type = load-balance     # other types are OK, too.
  73
  74         home_server = home1.example.com
  75         home_server = home2.example.com
  76         # add more home_server's here.
  77
  78         # If all home servers are down, try a home server that
  79         # is a local virtual server.
  80         fallback = acct_detail.example.com
  81
  82         # for pre/post-proxy policies
  83         virtual_server = home.example.com
  84 }
  85
  86 #  (3) Define a realm for these home servers.
  87 #  It should NOT be used as part of normal proxying decisions!
  88 realm acct_realm.example.com {
  89         acct_pool = acct_pool.example.com
  90 }
  91
  92 #  (4) Define a detail file writer.
  93 #   See raddb/modules/detail.example.com
  94
  95 #  (5) Define the virtual server to write the packets to the detail file
  96 #  This will be called when ALL home servers are down, because of the
  97 #  "fallback" configuration in the home server pool.
  98 server acct_detail.example.com {
  99         accounting {
 100                 detail.example.com
 101         }
 102 }
 103
 104 #  (6) Define a virtual server to handle pre/post-proxy re-writing
 105 server home.example.com {
 106         pre-proxy {
 107                 #  Insert pre-proxy rules here
 108         }
 109
 110         post-proxy {
 111                 #  Insert post-proxy rules here
 112
 113                 #  This will be called when the CURRENT packet failed
 114                 #  to be proxied.  This may happen when one home server
 115                 #  suddenly goes down, even though another home server
 116                 #  may be alive.
 117                 #
 118                 #  i.e. the current request has run out of time, so it
 119                 #  cannot fail over to another (possibly) alive server.
 120                 #
 121                 #  We want to respond to the NAS, so that it can stop
 122                 #  re-sending the packet.  We write the packet to the
 123                 #  "detail" file, where it will be read, and sent to
 124                 #  another home server.
 125                 #
 126                 Post-Proxy-Type Fail {
 127                         detail.example.com
 128                 }
 129         }
 130
 131
 132         #  Read accounting packets from the detail file(s) for
 133         #  the home server.
 134         #
 135         #  Note that you can have only ONE "listen" section reading
 136         #  detail files from a particular directory.  That is why the
 137         #  destination host name is used as part of the directory name
 138         #  below.  Having two "listen" sections reading detail files
 139         #  from the same directory WILL cause problems.  The packets
 140         #  may be read by one, the other, or both "listen" sections.
 141         listen {
 142                 type = detail
 143                 filename = "${radacctdir}/detail.example.com/detail-*:*"
 144                 load_factor = 10
 145         }
 146
 147         #  All packets read from the detail file are proxied back to
 148         #  the home servers.
 149         #
 150         #  The normal pre/post-proxy rules are applied to them, too.
 151         #
 152         #  If the home servers are STILL down, then the server stops
 153         #  reading the detail file, and queues the packets for a later
 154         #  retransmission.  The Post-Proxy-Type "Fail" handler is NOT
 155         #  called.
 156         #
 157         #  When the home servers come back up, the packets are forwarded,
 158         #  and the detail file processed as normal.
 159         accounting {
 160                 # You may want accounting policies here...
 161
 162                 update control {
 163                         Proxy-To-Realm := "acct_realm.example.com"
 164                 }
 165         }
 166
 167 }