[RADIATOR] RADSEC resources...
Heikki Vatiainen
hvn at open.com.au
Tue Mar 29 14:28:22 CDT 2011
On 03/25/2011 04:27 PM, Alan Buxey wrote:
> just wondering what the impact on a RADIATOR server is for RADSEC clients
> that are running in persistant TCP connection mode (as they seem to do by default)...
> how many of them can I operate in such a fashion against RADIATOR (4.7 with patches)
> or should they not be run in this mode?
I would say this mode is preferred compared to establishing TLS sessions
per request. Especially when requests are part of EAP session
establishment for various TLS tunnelling protocols.
> will it starve the resources of the RADIATOR for other tasks or will the server
> just spawn more children from the thread (hence my question about numbers).
It will not spawn automatically, but you could try server farm if you
think the number of clients should be split among Radiator servers.
> dont want to find things go rapidly melty/wrong/shunoky when I reach
> some mahical figure one afternoon......
Well, I do not know if anyone has hit RadSec imposed limit yet. Usually
the problems seem to come from LDAP, SQL or some other processing or
from AuthByPolicies which run through many AuthBys for each request.
If the server is doing just proxying, then RadSec might be the limiting
factor at some point, but for authenticating server, the limiting factor
could also be the authentication backend.
It would be interesting to hear about number of clients and
authentication events if you plan to add a large number of clients.
Yours,
Heikki
--
Heikki Vatiainen <hvn at open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
More information about the radiator
mailing list