On Jul 11, 2009, at 12:14 PM, Ivan Kalik wrote:
I'm not using RADIUS as a backend for ISP gear. I am using a RADIUS
proxy to serve requests for service software, and when false failures
come back, customers get error boxes in their software and contact
our
support angry that our authentications are returning transient
errors. Furthermore, I consider it bad public face to return errors
to customers when they should not get them. Yes, customers can
always
retry, but we can also retry for them when know the reason is not due
to invalid information.
I think that you are going about it the wrong way. You wont proxy to
pretend that home server has not gone down. How about this - instead
of a
group of stand-alone load-balanced home servers create a (true) high
availability cluster. If your home server is always available this
issue
doesn't come up. And your customer always gets a response.
Well, if I get the proxy handling to function the way I am
envisioning, I effectively create a high-availability cluster with the
proxy as my availability manager. :)
But why not setup a high-availability cluster as a home server?
First, I already have an existing pool of dumb home servers that I
would like to continue using. Second, those home servers are
incredibly cheap and easily replaceable. A high-availability cluster
probably would not be. Third, if my home servers start having issues
with the load, the easiest thing to do to just add more dumb home
servers and update the proxies to spread that load out across the new
ones in addition to the old ones. Easy scaling. And why use a proxy
in the first place? I can use that proxy to work around a bunch of
different NASes not having the ability to use a pool of home servers.
I do not want the proxy to pretend that the home server has not gone
down (in fact, it very much needs to accept that any individual home
server may be down). I want it to hide the fact that a single home
server is not responding and not have that result in the entire pool
appearing to have gone down (if only for a single request). NASes
already handle the unreliability in the network by retransmitting
packets. I can have the proxy use that to its advantage by not giving
the NAS any clue that a single home server in the pool did not respond
to a request in a timely fashion (do this by sending retransmits to
another server). A proxy that does not respond to the initial request
because the initial request never got responded to by the home server,
but then responds to subsequent retransmits of that request because
the proxy transmitted them to a different home server that was up and
responding just appears as a slow RADIUS server to the NAS. My
customers do not really complain about login taking a long time (30s,
etc.), but they really complain when their client tells them their
login is not valid when they know it is.
Philip
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
