> Hmmm... An interesting thought. Yet another problem created by dynamic
> addressing. (Never one of my favorite methods, as even without this
> problem, it seems to create more problems than it solves, but that's
> another topic) Anyway, those 10 friends need to make darn sure they
I personally agree in some ways, and disagree in others. It's horribly
inefficient, and it doesn't work well between POPs. (Unless you want to
have the routing nightmare from hell, and even then it's horrible). But
statics certainly have their appeal. But they're as good as verboten as
far as ISP dialup use is concerned.
> Relative to the number of concerns I've seen expressed about other problems,
> I have to say that it isn't as significant as those other issues. Again,
> we're talking about engineering resource allocation. Those resources right
> now are better spent on things like PRI, classless routing, and OSPF.
Agreed. There's no way to work around CIDR with a perl script. :)
> Yes and no. The solution you proposed, as you point out, doesn't scale.
> All of Livingston's products to date DO.
I use a slightly different solution than the one I suggested, but it
still involves checking the users online. If you modify the checker to
perform concurrent logins on the portmasters at the same time, then it
would scale quite well - I'd estimate you could handle 10-20 portmasters
without too much worry that way, and they could be scattered all over
geograhically.
While 20 portmasters isn't a huge batch, 600 phone lines is probably
more than 90% of livingston's ISP clients have. The other 10% (if that!)
have the resources to come up with their own solution if they really need
to.
(Did we just switch sides of the argument? :)
> The PortMasters do lots of neat stuff without RADIUS and about 50% of
> Livingstons customers don't use RADIUS.
> critical. Something on the order of 75% consider PRI important.
> If you were in charge of engineering and faced numbers like that,
> which project would you follow?
I'm not arguing there. But I don't think that it should be left
entirely by the wayside, especially since it's a software solution and
doesn't require any help (well, possibly. There are ways it could be
implimented more easily with some hardware mods, but that would probably
break the RADIUS protocol) from the hardware department. Since the two
are separate, I see concurrency control as a very high priority for the
RADIUS daemon development. Perhaps not on the scheme of things as far as
the portmaster box is concerned, but as far as software goes.
> Can I presume since you ignored the remainder of my message that you're not
> using UNIX or that you're more concerned about PPP users?
I do use UNIX, but I'm more concerned about a solution which applies
to all of my dialin users, not just shell users. I don't care how many
times a shell user logs in to the shell, I'm purely concerned about phone
line resource management. To have an effective way of dealing with that,
I need a solution which applies equally to all dialin users. I have that
now, but it's not, IMHO, "The Right Way" to do it. Better to deny users
access when they log on with a message informing them they've exceeded
their number of logins than to kick them off with an email. And for
those of us who are stuck with Livingston radius for other reasons
(menuing), it's the right way to go.
-Dave Andersen
-- angio@aros.net Complete virtual hosting and business-oriented system administration Internet services. (WWW, FTP, email) http://www.aros.net/ http://www.aros.net/about/virtual "There are only two industries that refer to their customers as 'users'."