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 <[email protected]> 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
