robust-proxy-accounting

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 the local configuration.

  1. Define two home servers:

    home_server home1.example.com {
    	type = acct
    	ipaddr = 192.0.2.10
    	port = 1813
    	secret = testing123
    	status_check = request
    	username = "test_user_status_check"
    	response_window = 6
    }
    
    home_server home2.example.com {
    	type = acct
    	ipaddr = 192.0.2.20
    	port = 1813
    	secret = testing123
    	status_check = request
    	username = "test_user_status_check"
    	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
    }
  3. Put all of the servers into a pool.

    home_server_pool acct_pool.example.com {
    	type = load-balance
    	home_server = home1.example.com
    	home_server = home2.example.com
    	fallback = acct_detail.example.com
    	virtual_server = home.example.com
    }
  4. Define a realm for these home servers. The realm should not be used as part of normal proxying decisions!

    realm acct_realm.example.com {
    	acct_pool = acct_pool.example.com
    }
  5. Define a detail file writer. See raddb/modules/detail.example.com

  6. Define the virtual server to write the packets to the detail file. This server 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
    	}
    }
  7. Define a virtual server to handle pre/post-proxy re-writing

    server home.example.com {
    	pre-proxy {
    
    	}
    
    	post-proxy {
    
    		Post-Proxy-Type Fail {
    			detail.example.com
    		}
    	}

    The next section reads accounting packets from the detail file(s) for the home server.

    Note that only one "listen" section can read 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 either or both of the "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, then the packets are forwarded and the detail file is processed as normal.

    	accounting {
    
    		update control {
    			Proxy-To-Realm := "acct_realm.example.com"
    		}
    	}
    
    }