Timeout problem behind load balancer
simon at polkaspots.com
Fri Jul 25 15:59:30 CEST 2014
That's the frustrating part. Despite being able to balance UDP connections,
you need to use an http check. There's not even a tcp option.
We've resorted to running nginx on the servers and if we decide to
production it, maybe we'll build something into monit to kill nginx if
radius dies. Hacky.
Essentially it's just checking if the server's up in our case. Which is
better than the round-robin stuff we have tried previously. Actually,
previously we used Amazon's route 53 to route the traffic but this also
needed a tcp / http check.
They claim they're not blocking outbound traffic other than the obvious
(smtp etc.) but I don't believe that currently.
If radius works when we hit the server without the load-balancer and then
mysteriously stops sending out, it would appear it is being blocked.
On 25 July 2014 14:06, Fajar A. Nugraha <list at fajar.net> wrote:
> On Fri, Jul 25, 2014 at 7:48 PM, Simon Morley <simon at polkaspots.com>
> > Agreed. So it would seem there is an issue getting the traffic back out
> > again as suspected.
> > We don't have a million users so I shan't bother looking at the F5s. Will
> > hassle Google again.
> > I suspect their health check is randomly removing the machines from the
> > balancers.
> I'm curious what they use for udp health check. Do they even have any?
> Is it something that aware of radius packets? Or is it just basic ping
> > Thanks
> > On 25 July 2014 13:24, Alan DeKok <aland at deployingradius.com> wrote:
> >> Simon Morley wrote:
> >> > I've discussed with Google and they're saying the connection isn't
> >> > closed and the load-balancer therefore puts the instance in
> >> > mode.
> >> UDP sessions aren't "closed". The google support guys don't seem to
> >> be competent.
> >> > Has anyone tried this successfully - either on GCE or other UDP load
> >> > balancer? Does anyone have any thoughts about how I could solve?
> >> F5 load balancers seem to work. But they are useful only when you're
> >> at Telco scale. i.e. 1M+ users. For pretty much everyone else, it
> >> doesn't matter.
> >> Alan DeKok.
> >> -
> >> List info/subscribe/unsubscribe? See
> >> http://www.freeradius.org/list/users.html
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> List info/subscribe/unsubscribe? See
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Freeradius-Users