# -*- text -*- ###################################################################### # # This is a sample configuration for robust proxy accounting. # accounting packets are proxied, OR logged locally if all # home servers are down. When the home servers come back up, # the accounting packets are forwarded. # # This method enables the server to proxy all packets to the # home servers when they're up, AND to avoid writing to the # detail file in most situations. # # In most situations, proxying of accounting messages is done # in a "pass-through" fashion. If the home server does not # respond, then the proxy server does not respond to the NAS. # That means that the NAS must retransmit packets, sometimes # forever. This example shows how the proxy server can still # respond to the NAS, even if all home servers are down. # # This configuration could be done MUCH more simply if ALL # packets were written to the detail file. But that would # involve a lot more disk writes, which may not be a good idea. # # This file is NOT meant to be used as-is. It needs to be # edited to match your local configuration. # # $Id$ # ###################################################################### # (1) Define two home servers. home_server home1.example.com { type = acct ipaddr = 192.0.2.10 port = 1813 secret = testing123 # Mark this home server alive ONLY when it starts being responsive status_check = request username = "test_user_status_check" # Set the response timeout aggressively low. # You MAY have to increase this, depending on tests with # your local installation. response_window = 6 } home_server home2.example.com { type = acct ipaddr = 192.0.2.20 port = 1813 secret = testing123 # Mark this home server alive ONLY when it starts being responsive status_check = request username = "test_user_status_check" # Set the response timeout aggressively low. # You MAY have to increase this, depending on tests with # your local installation. response_window = 6 } # (2) Define a virtual server to be used when both of the # home servers are down. home_server acct_detail.example.com { virtual_server = acct_detail.example.com } # Put all of the servers into a pool. home_server_pool acct_pool.example.com { type = load-balance # other types are OK, too. home_server = home1.example.com home_server = home2.example.com # add more home_server's here. # If all home servers are down, try a home server that # is a local virtual server. fallback = acct_detail.example.com # for pre/post-proxy policies virtual_server = home.example.com } # (3) Define a realm for these home servers. # It should NOT be used as part of normal proxying decisions! realm acct_realm.example.com { acct_pool = acct_pool.example.com } # (4) Define a detail file writer. # See raddb/modules/detail.example.com # (5) Define the virtual server to write the packets to the detail file # This will be called when ALL home servers are down, because of the # "fallback" configuration in the home server pool. server acct_detail.example.com { accounting { detail.example.com } } # (6) Define a virtual server to handle pre/post-proxy re-writing server home.example.com { pre-proxy { # Insert pre-proxy rules here } post-proxy { # Insert post-proxy rules here # This will be called when the CURRENT packet failed # to be proxied. This may happen when one home server # suddenly goes down, even though another home server # may be alive. # # i.e. the current request has run out of time, so it # cannot fail over to another (possibly) alive server. # # We want to respond to the NAS, so that it can stop # re-sending the packet. We write the packet to the # "detail" file, where it will be read, and sent to # another home server. # Post-Proxy-Type Fail { detail.example.com } } # Read accounting packets from the detail file(s) for # the home server. # # Note that you can have only ONE "listen" section reading # detail files from a particular directory. That is why the # destination host name is used as part of the directory name # below. Having two "listen" sections reading detail files # from the same directory WILL cause problems. The packets # may be read by one, the other, or both "listen" sections. listen { type = detail filename = "${radacctdir}/detail.example.com/detail-*:*" load_factor = 10 } # All packets read from the detail file are proxied back to # the home servers. # # The normal pre/post-proxy rules are applied to them, too. # # If the home servers are STILL down, then the server stops # reading the detail file, and queues the packets for a later # retransmission. The Post-Proxy-Type "Fail" handler is NOT # called. # # When the home servers come back up, the packets are forwarded, # and the detail file processed as normal. accounting { # You may want accounting policies here... update control { Proxy-To-Realm := "acct_realm.example.com" } } }