Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) RADIUS - Blocking multiple logins by same user (fwd)
Dan Merillat writes:
>
> MegaZone writes:
> > Once upon a time Dan Merillat shaped the electrons to say...
> > >That's the hard part... Question, is RADIUS accounting guarenteed to get
> > >there, eventually? (As long as the NAS stays up, anyway.)
> >
> > I think we do something like hold up to 150 packets in buffer and keep tryi
ng
Um, ok... something is wrong here, since the message in my sent-mail isn't
cropped like this. Aha! there is a single period on the next line, so
someone's relay didn't quote it properly. Boy, I bet THAT generated
some SMTP errors.
MegaZone writes:
> Once upon a time Dan Merillat shaped the electrons to say...
> >That's the hard part... Question, is RADIUS accounting guarenteed to get
> >there, eventually? (As long as the NAS stays up, anyway.)
>
> I think we do something like hold up to 150 packets in buffer and keep trying
> Of course, BOTH the primary and secondary would need to be down.
And, for most configurations I've seen, that would mean that BOTH primary
and secondary auth are down as well. Not all, but most.
> >Hmm... we still need a resource management protocol... for things like
> >bandwidth allocation with dial-to-frame ISDN, how many lines on a single
> >connection someone can have using analog MPP or MP+...
>
> The how many lines is covered with 'Port-Limit' - which is stardard. Though
> I don't think Ascend has added that to their NAS yet.
Yea, but how to limit number of ports across your boxes?
> Bandwith allocation sounds like BAP/BACP territory.
True.
Ok, someone help me out here, what, besides number of concurrent calls,
is RADIUS unable to implement that you really need? If it's just
concurrent sessions, I think the accounting hack I described would solve
it...
--Dan
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>