free radius implementation for big ISP

[Brian Candler]

On Sun, Feb 06, 2011 at 02:13:40PM +0330, Mohamad A wrote:
> 1. Handling about 100,000 acc requests and 10,000 auth requests hourly!

I know a freeradius installation much bigger than that.

You can scale freeradius easily: a multicore machine with lots of RAM will
be able to handle hundreds of requests per second (depending on whether it's
using in-RAM tables or mysql queries or whatever), and you can scale
horizontally by adding more RADIUS servers.

For your 200K users you might want to use mysql or LDAP as your source of
authorization and authentication data. You can scale that using replication.

> 2. Accounting

Of course. Using something like rlm_log_sql you can write the 'INSERT'
statements to a log file, then periodically collect them and push them into
your accounting DB.  Using that approach, the accounting DB doesn't become a
real-time bottleneck.

For real-time accounting (i.e. "which user is on this IP address right
now"?) support for Redis has just been added. It should appear in 2.1.11.

> 3. Control and limit user traffic.

That's a function of the NAS. The RADIUS server is not involved, except in
sending attributes to control that activity. FreeRADIUS can send whatever
attributes you like.

> 4. Control and limit user concurrent logins.

That's a bit trickier but doable. I believe there are example configs for
doing this using mysql, and you could use the new Redis support for it too.

But (1) it is difficult to scale, because there will have to be a central
real-time database updated when people connect and disconnect; and (2) this
service is designed to prevent people logging in under certain
circumstances, and therefore can become a source of increased user problems
and support calls.

You have to decide whether the "abuse" of multiple concurrent logins is
outweighed by the risks of accidentally locking out legitimate users (e.g. 
because of lost accounting packets showing that the users' previous session
has ended)

IMO a better solution is just to analyse accounting logs periodically, and
identify people logging in concurrently.  Then you can send them a gentle
warning to mend their ways, and if they persist then you terminate them
under the T&Cs of the service you provide them.

> 5. CoA for changing user speed over different times of day.
> 6. CoA to disconnect user when the account validation is over (eg.
> Traffic quota exceeds).

radclient can send the CoA packets, but the actual logic of *when* to send
them is entirely outside of FreeRADIUS. You would need your own systems to
do that.

Your NAS might support an attribute to disconnect the user once a certain
amount of traffic has been sent or received (similar to Session-Timeout,
which disconnects them after a certain number of seconds)

> 7. Calculate traffic usage differently depending on day-time (ie. our
> service in nights does not calculate any traffic or some times as half
> for users).

FreeRADIUS doesn't "calculate traffic usage". You need to build a system to
do that, using accounting records as the raw input.

> 8. Tracking online users and disconnect user if Accounting packet is
> not received in prefixed amount of time (currently 10 mins).

That seems a strange requirement. If you have configured your NAS to send
periodic interim updates, and the NAS hasn't sent one for 2 or 3 times the
update interval, then the reason is almost certainly that the user has
disconnected anyway.

Anyway, this falls into the same as CoA above. You can use radclient to send
the disconnect packet (or more standard, use SNMP to do this), but the
systems to work out if and when to do this are your own.

> 9. Spliting database traffic over multiple servers.

Yes that's easy. Multiple RADIUS servers can point to different database
backends; a single RADIUS server can also share load between multiple
database backends using a "load-balance" section. "man unlang" for more
info.

> 10. Designing one interface to manage all users.

Building user management is your problem. This encompasses everything from
CRM (contact info), signup, rating, billing and payment collection,
selfcare, mapping products to RADIUS attributes, product upgrades, service
termination, and so on.

FreeRADIUS doesn't even provide you with a user management API, that's up to
you too.  For example, if you put your user radius data into a mysql
database, you might expose some stored procedures that the higher-level
systems can call to add/delete/modify a user; or you might have a separate
system which takes SOAP or JSON requests and turns them into mysql inserts
and updates.

> Do you really suggest to switch to FreeRadius or stick to the current
> problematic solution ?

FreeRADIUS is a comprehensive, reliable and flexible toolkit for building
RADIUS servers and clients.  It can query databases for generating RADIUS
responses, but the way you enter and manage that data is out of its scope. 
Hence depending on what your existing solution does for you, you may find
you have to build quite a lot more around FreeRADIUS to make the complete
solution.

HTH,

Brian.