(RADIATOR) Accounting setup

[Hugh Irvine]

Salut Robert -

I have many customers using the approach of running an instance of  
Radiator on the SQL server and proxying the accounting requests to it.

This works very well, especially as RADIUS over UDP is much more  
light-weight than running multiple SQL connections.

It is also very easy to configure with an AuthBy RADIUS clause  
instead of an AuthBy SQL clause.

I generally recommend keeping local copies of the accounting requests  
in daily flat files, and also keeping copies of any requests that do  
not get a response from the accounting server. This gives you  
complete copies of your accounting data in flat files which you can  
then archive at your convenience. The files containing any missed  
accounting requests can also be used directly to load the accounting  
data into the database when it becomes available using the  
radimportacct utility provided for this purpose in the goodies  
directory.

The configuration file would look something like this:

......

<Handler Request-Type = Accounting-Request>
	.....
	<AuthyBy RADIUS>
		.....
		AcctFailedLogFileName %L/failed-accounting-%Y-%m-%d
	</AuthBy>

	AcctLogFileName %L/accounting-%Y-%m-%d

</Handler>


hope that helps

BTW - we can provide contract consulting services for design,  
implementation, training and so on as required.

cordialement

Hughes


On 20 Mar 2007, at 00:41, Robert von Bismarck wrote:

> Hello,
>
> I need some professional advice here, regarding our "next-gen"  
> accounting setup for our ADSL/dialup network.
> Currently we run three radius servers that have one authentication  
> and one accounting instance each. Each server is co-located at the  
> telco exchange point where we host our LNS and NAS equipment.
> The current accounting instance is using an AuthBySQL statement,  
> that sends the data to a central MySQL-4 instance via mysql. This  
> server is getting quite old, and will be replaced soon by a master- 
> slave-replication MySQL-5 "cluster". Some guys around here have  
> been asking if it would make more sense to actually run the radius  
> process directly on the database servers, as there have been no  
> outages of the radiator instances, unless there was some planned  
> maintenance, or network issues.
>
> We came up with following setups during the planning phase :
>
> 1) do as currently, have radiator on the AAA servers send  
> accounting data to the db server over mysql connections
> 2) run a radiator instance on the DB server and have the network  
> equipment connect to that
> 3) do both, using an AuthByGroup using radius as primary transport
> 4) same as 3) using sql as primary transport
> 5) run a local "slave" mysql, replicated to the cluster, with local  
> accounting instance.
>
> Which of those would be considered as being best practice ? It's  
> certain that we can't do extensive testing, as this is a production  
> network handling about 10-12'000'000 requests per month, and we  
> expect a new wholesale customer that will possibly double this  
> number by end of the year.
>
> Our current platform is :
> Three P4 Xeon, dual-cpu, 2.8Ghz with 2Gb RAM, for the AAA servers
> One P4 Xeon dual-cpu, 2.6Ghz with 4Gb RAM for the db server,  
> running on software RAID5.
> These are running under SuSE Linux 9.3 with MySQL 4.0 for the DB  
> and local OpenLDAP replicas for the authentication.
>
> The new accounting platform will be :
> Two quad-core 2Ghz Xeon, 4Gb RAM and a hardware RAID 0+1 on SCSI or  
> SAS (depending on  budget :)
> This will run CentOS 4.4 and mysql 5.
>
> Thank you for any advice,
>
> Robert von Bismarck
> Senior systems engineer UNIX
> RHCT
>
> VTX SERVICES SA
> Une société du groupe Smart Telecom
> ================================================================
> Tél. direct : 021 721 12 55 - Mobile : 079 541 37 28
> Av. de Lavaux 101 - 1009 Pully
> http://www.vtx.ch - robert.von bismarck at smart-telecom.ch
> ----------------------------------------------------------------
> VTX, votre partenaire telecom proche de vous !
> ----------------------------------------------------------------
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.



--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.