(RADIATOR) Redback is sending too many Access-Requests

[Mishari Al-Faris]

Hello Hugh,

Thanks for the response, and here's what I have in my dictionary regarding
the Calling-Station-Id attribute:
ATTRIBUTE       Calling-Station-Id              31      string

It was that way when I installed it, never touched it.

As for the Redback, we currently have the "maximum" outstanding auth
requests set to 50. I believe the default is 250. I'm worried that if we
increase it that we'll be getting even more Auth requests. Also, for the
throttleing example you mentioned, what is the "AddToReply ...." containing?
do I need it to append the "session-timeout"? or is it for whatever I want?
I apologize but I'm not confident enough in using hooks.

<Handler .....>

        AuthByPolicy ContinueWhileIgnore

        <AuthBy INTERNAL>
                RequestHook file:"throttle.pl"
                AddToReply .....   <=== Is this needed? and what shoul dit
contain?
        </AuthBy>

        # normal AuthBy
        <AuthBy .....>
                .....
        </AuthBy>

</Handler>
**

On 12/20/05, Hugh Irvine <hugh at open.com.au> wrote:
>
>
> Hello Mishari -
>
> Radiator uses the operating system UDP queue - and removes one
> request from the queue at a time.
>
> The time that you see the request in the debug time is the time the
> request is de-queued and processed - the log messages appear during
> request processing in "real" time.
>
> Note that this is a well known problem with DSL systems and Cisco for
> example has recently introduced radius request rate limiting in their
> software - you should check with Redback to see whether they support
> a similar feature.
>
> You will also find an example hook in "goodies/hooks.txt" (Radiator
> 3.13) that implements conditional rate limiting which may be useful.
>
> For the error you show below, Calling-Station-Id should be defined as
> string in the dictionary. What does your dictionary contain?
>
> regards
>
> Hugh
>
>
> On 20 Dec 2005, at 16:28, Mishari Al-Faris wrote:
>
> > Hello All,
> >
> > Our Redback is sending us Access-Requests for DSL users way too
> > frequently, can reach up to 1-2 requests/sec. Ofcourse the Timeout
> > and Retry timers on Redback are set for reasonable values like 1
> > retry after 30 second timeout. All the requests coming to Radiator
> > are being accepted, yet still sometimes when too many users are
> > that way our customers begin complaining about error "718" (the
> > computer you're dialing is not responding), in other words, the
> > requests are not being accepted fast enough.
> >
> > We saw that after locking and unlocking the DSL port coming to
> > Redback's ATM interface that the user is able to login once and the
> > requests stop.
> >
> > Trying to trouble shoot this, I was wondering does Radiator have a
> > queue for the requests its handling? and if its possible to check
> > its status at a point in time? Also, when I enable Trace 4 and see
> > an access-request appear in the log, does that mean Radiator only
> > received it at that exact instant? (being reasonably close again,
> > not talking absolute exactness) or does it only appear in the log
> > after it had acknowledged the request from the Redback?
> >
> > I ask this because when we get "718" errors with users and I try to
> > login myself, and ask a friend to have an eye on the Radiator log
> > to see when the request concerning me arrives.
> >
> > Also, we get these in the logfile:
> > Tue Dec 20 08:27:36 2005: ERR: There is no value named /
> > rb01/11/0/27/675 for attribute Calling-Station-Id. Using 0.
> > Tue Dec 20 08:27:36 2005: ERR: There is no value named /
> > rb01/11/0/27/675 for attribute Calling-Station-Id. Using 0.
> >
> > Is there a way to stop this please?
> >
> > Thanks so much for you patience in reading this,
> > Mishary Al-Faris
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/
> radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20051224/f4ab55a4/attachment.html>