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