We are running into some challenges configuring a new environment for
Eduroam.
Recently we have moved away from 2 servers running multiple radiator
processes to a multiple VMs behind an F5 load balancer. This has been
working well for our wireless infrastructure but has been posing challenges
as w
On 27/07/2016 18:14, Barry Ard wrote:
> We are running into some challenges configuring a new environment for
> Eduroam.
>
> Recently we have moved away from 2 servers running multiple radiator
> processes to a multiple VMs behind an F5 load balancer. This has been
> working well for our wireless
Thanks Shaun. This is good reading.
Barry
On Wed, Jul 27, 2016 at 11:38 AM, shaun gibson wrote:
> On 27/07/2016 18:14, Barry Ard wrote:
>
> > We are running into some challenges configuring a new environment for
> > Eduroam.
> >
> > Recently we have moved away from 2 servers running multiple ra
DSR load balancing assumes the real servers know about the load balanced VIP
and is generally configured on a loopback.
The problem with this I think is that Radiator responds with a source address
of where the packet leaves. (at least that’s been my experience). Most clients
will probably igno
On 27/07/16 19:32, Robert Blayzor wrote:
> DSR load balancing assumes the real servers know about the load balanced VIP
> and is generally configured on a loopback.
>
> The problem with this I think is that Radiator responds with a source address
> of where the packet leaves. (at least that’s bee
As a general network design we try to stay away from multihomed servers
as much as possible as the server admins lack networking/routing
know-how which leads to failing connectivity all the time.
Direct server return has its own share of problems which is why we don't
use it anymore but this is pr
On 27.07.2016 21:32, Robert Blayzor wrote:
> The problem with this I think is that Radiator responds with a source
> address of where the packet leaves. (at least that’s been my
> experience).
Yes, this happens by default when BindAddress is not configured.
The default is to bind the RADIUS list
In my experience this is not the case. It will LISTEN on those addresses for
sure. But it’s return packets are always sourced from the primary IP address of
the outgoing interface. DSR will work, but the clients will receive a response
from an IP address that is not of the configure RADIUS serve
This may be the case now, but pretty sure we went down this road YEARS ago and
even with BindAddress, packets were still being sourced from the main IP
address. In the mailing list archives this argument may exist. I vaguely
remember being told by Hugh that it was not possible in Perl at the tim