(RADIATOR) Redback is sending too many Access-Requests
Hugh Irvine
hugh at open.com.au
Sat Dec 24 03:59:20 CST 2005
Hello Mishari -
What version of Radiator are you running? The latest is Radiator 3.13
(plus patches).
I don't know why you are seeing the error you are seeing, as a string
attribute should just print the string.
For the AddToReply you would use whatever you need to use to allow a
session to start on the Redback. Normally these sorts of systems send
back radius reply attributes to lock a user into a walled garden
where all they can do is see a web page that tells them what the
problem is.
If you are not confident with hooks and so on I would recommend not
trying to use this.
regards
Hugh
On 24 Dec 2005, at 18:58, Mishari Al-Faris wrote:
> 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.
>
>
>
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.
--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list