Very large environment depending on FreeRadius

Phil Mayers p.mayers at imperial.ac.uk
Thu Mar 15 09:58:44 CET 2012


On 03/15/2012 07:38 AM, Christiaan Rademan wrote:

> Can you please advice me on anything I should watch out for or plan for?

I'm sure others will chip in, but basically: don't worry about 
FreeRADIUS, worry about your SQL database.

FreeRADIUS itself can handle a truly enormous rate of authentication and 
accounting packets.

The problem people seem to run into at scale is the SQL database they're 
using for authentication (i.e. to read password) or accounting (i.e. 
write accounting records) is too slow, which means FreeRADIUS becomes 
slow. Then people get in a muddle and think adding hundreds of threads 
to the thread pool will help ("My database is slow... I know, I'll add 
MORE concurrent queries, that'll speed it up").

It's a particular problem if, after a couple of weeks, they've got 
100million rows in their accounting table and accounting takes seconds 
to complete, so ensure you're archiving regularly.

Assuming you're not doing any SQL activity for proxied packets, I don't 
think you need to worry too much about the, but DO ENSURE you are 
running 2.1.12, and not some earlier version.

With regards the local auth, you say you're using MySQL and sqlippool; 
you might want to check the list archives for this, there has been some 
discussion in the past. I don't use MySQL, but my understanding was that 
the required locking (to avoid handing the same IP out twice) was 
problematic in some fashion in MySQL.

Basically: run some test auths through the server and dump the SQL 
queries it generates. Then think about how those SQL queries will 
perform in a month, when your SQL DB is full of accounting records, or 
when 100 queries/sec come in.


More information about the Freeradius-Users mailing list