free radius implementation for big ISP

[Mohamad A]

Brian,

Thanks for quick reply, considering your information, this is going to
be very challenging!
but as soon as I get confirmation about installing of FreeRadius from
my manger I'll come back to this mailing list with lots of questions.
:)

Regards
M

On 6 February 2011 15:09, Brian Candler <B.Candler at pobox.com> wrote:
> 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.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>