What do you mean by "only one portmaster, not the whole chain"?
Port-Limit
is not designed for concurrency control. Its for Multi-Link (RFC 1717)
channels. Concurrency doesn't belong in the NAS, anways.
> Using harsh language will only make the abuser laugh...ditto for talking
> nicely...pmmon only works with radius device---what about non radius
> devices?
Charging them for the extra account will only make them stop.
What main-stream terminal servers do not support RADIUS? Any NAS that
I would use must, or its not a choice.
> The only real solution is to use existing utilities to code a program to
> check all of the terminal servers...Truthfully if one where able to hack a
> function into the radius source code I suspect that for larger providers
> the function would cause latency errors forcing the radius device to use
> the secondary authentication...
Are you suggesting the RADIUS server would poll the servers to verify?
Is that why the latency would come into effect? I don't follow the
latency errors issue?
> We're a system with over 4000 customers. 7pm at night and the
> authentication server as well as the mail server float between 50% to 90%
Hmmm At 10-to-1 thats 400 lines. If you have a 10% turnover per minute
(which is pretty high) thats 40 authentications/minute or less than 1
per second. If you are doing accounting on your authentcation server
(I don't recommend it) then its times three, or 120/minute.
With full concurrency control and port access control, RadiusNT running
on
a P100 w/40mb and SQL Server can authenticate (single thread) over 5
authentications per second, or 300 authentications per minute (over what
I
guessed per minute for you). Multi-Threaded is only limited by the
capacity of the RDBMS (more theads are not necessarily better).
(If this performance looks poor to you, running in text mode, like
most UNIX servers, RadiusNT auths ~20ms or around 50/second or
3000/minute).
A background program walks the terminal servers and cleans up any
mis-listed users. Since this is all Client/Server technology you can
just put a couple more RadiusNT machines onto the network and spread
your NAS load over them to really increase reliability. As you
grow you can add clients to suport the load. Scaleability.
The problem with everyone's login limiting schemes is that its
based on a SINGLE server or some archaic directory/file layout to
control users. Its not scaleable, has high latency, and inherent
problems. Use a true RDBMS solution (where the RDMBS vendor has
already solved all the problems you are trying to solve) and its
MUCH simpler and works.
> cpu utilization. With that much load we didn't want the process to run
> whenever radiusd was called. Since the program relies on system utilitites
> we set it up so it can only be called once. If its still running when its
> called again the newly called process exits. We ran into this problem when
> during busy hours the program would not finish because of the number of
> users online. Radius whether Livingston or Merit will have the same
> problem. I strongly doubt we'll ever see a radius code that prevents
> multiple logins.
With that load you need a better machine or better RADIUS server.
RadiusNT does NOT have this problem and we have customers with
10,000-20,000
customers running very smoothly. No RADIUS server can ever do
concurrency control accurately alone. It will always need something
else.
--
Dale E. Reed Jr. (daler@iea.com)
_________________________________________________________________
IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs
Internet Solutions for Today | http://www.emerald.iea.com