Hi,
> This will happen. There is sufficient buy-in from large telcos that
> it's necessary.
cool. it wasnt just me toking on the crack pipe too many times 8-)
Stefan, you hearing this? and you be thinking I crazy :-)
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
[EMAIL PROTECTED] wrote:
>> But there is no RADIUS "routing protocol"[1]. So that's that.
>
> s'funny that you should mention that - what with a hierarchical system.
> I thought it would be neat if a downstream system could notify the upstream
> about what realms it could deal with and - via a
Hi,
> This still means that requests will be sent to that home server,even
> if they're for an upstream realm that's dead. If there are multiple
> paths to the upstream realm, then those other paths won't be discovered.
>
> But there is no RADIUS "routing protocol"[1]. So that's that.
s'fu
Arran Cudbard-Bell wrote:
> That'd work. So when a server is marked as a Zombie Access-Requests
> still sent to it until the Zombie period has expired?
Yes. I also noticed that the current code doesn't send Status-Server
packets until "check_interval" time AFTER it's marked "dead". So we
have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan DeKok wrote:
> Arran Cudbard-Bell wrote:
>> Really in an system of chained proxy servers like EDUROAM you only want
>> to be testing first hop connectivity.
>
> Exactly.
>
>> Alan, do you think it might be a good idea to provide an option to
>
Peter Eriksson wrote:
> I wonder how low I can set things to lessen this issue. Perhaps set
> zombie_period and check_interval to one second...
That's not a good idea. It means that the server will be marked dead
MORE quickly.
>>> Best would probably be if FreeRadius kept a
>>> separate timeou
Arran Cudbard-Bell wrote:
> Really in an system of chained proxy servers like EDUROAM you only want
> to be testing first hop connectivity.
Exactly.
> Alan, do you think it might be a good idea to provide an option to
> disregard failures from standard authentication requests, and instead
> use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Eriksson wrote:
>
> Alan DeKok wrote:
>> Peter Eriksson wrote:
>>> The default setting seems to be less than optimal since if a remote site
>>> have problems with their home RADIUS servers then we risk having our
>>> local servers mark the upstr
Alan DeKok wrote:
> Peter Eriksson wrote:
>> The default setting seems to be less than optimal since if a remote site
>> have problems with their home RADIUS servers then we risk having our
>> local servers mark the upstream servers as "dead" since it's not
>> receiving answers for a specific 're
Peter Eriksson wrote:
> The default setting seems to be less than optimal since if a remote site
> have problems with their home RADIUS servers then we risk having our
> local servers mark the upstream servers as "dead" since it's not
> receiving answers for a specific 'realm'...
That's been a b
How have other EDUROAM sites configured their EDUROAM servers with
regard to timeout issues?
The default setting seems to be less than optimal since if a remote site
have problems with their home RADIUS servers then we risk having our
local servers mark the upstream servers as "dead" since it's no
11 matches
Mail list logo
