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@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