Re: Proxies and dead home servers

[Alan DeKok <aland@nitros9.org>]

Glen Zorn (gwz) wrote:
>>   I think that the second alternative is preferable to the first one.
> 
> Why?

  For reasons outlined elsewhere.  In short, failures in home server A
should not affect requests destined to home server B.

> I don't really understand your example but be that as it may, in a
> proxied system, neither proxies nor servers can be marked "dead" by a
> client for the reason that (using RADIUS alone) it is not possible for
> the client to know the state of another box on the network.

  I agree it's not possible to know with confidence the state of another
box on the network in RADIUS.  However, the state of the other box
doesn't really matter.  What is at issue is the proxies perception of
that state.

  If, as you say, the proxy can't tell the state of another box, then it
can't implement primary/secondary fail-over.  Since almost all RADIUS
clients and servers implement that, I suspect the covert admission is
that proxies *can* make decisions about the state of another box on the
network.

>  There are
> at least half a dozen things that could keep a response from arriving
> that have nothing at all to do with the health of any of the RADIUS
> entities.  What is down or up is a route to a realm; given that, it's
> not possible for a route to be erroneously marked as dead.  Note that
> routes to different realms are different routes, regardless of whether
> the first hop is the same or not.

  If the first hop is unresponsive to *any* request for extended
periods, then the issue of multiple realms is irrelevant.  That hop is
dead for all practical purposes.

  On top of that, there are no routes in RADIUS.  Requests get sent to
servers based on the key of (dst ip, dst port).  Individual servers may
forward requests based on internal decisions.  Network administrators
may have diagrams which describe hoe packets are routed.  But no machine
inside of the RADIUS "routing" cloud has access to that global routing
information.  In contrast, IP routers have that information available
through BGP/OSPF/whatever.

  I am very leery of talking about "routes" in a protocol which has
"routes" statically configured, and which has no way for "routers" to
exchange "routing" information.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>