RADIUS, anycast, and high availability
p.mayers at imperial.ac.uk
Thu Jun 26 18:51:39 CEST 2014
On 26/06/14 17:35, Jason Healy wrote:
> On Jun 26, 2014, at 8:53 AM, Phil Mayers <p.mayers at imperial.ac.uk>
>> A lot depends on how stable the routing is, and how many next-hops
>> are present, as well as how your routers hash between multiple
>> next-hops e.g. ip or ip + port.
> Yeah, I’m just starting to look into this. We’re on Juniper gear
> (sorry Arran!) and I think it tries to maintain a stable path for the
This varies. iChip and Trio gear use different ECMP hashing algorithms.
> same IPs. In the worst case, we could just set them up with a route
> preference so everything goes to the primary until failure (rather
> than trying to load-balance). Our site isn’t big enough to have a
> load problem so this is mostly for availability.
Strongly recommend doing this. This is what we do.
To expand slightly, we have this:
server A - main IP, service IP1, radius IPs
server B - main IP, service IP2, radius IPs
service IPs float between servers with ucarp
static routes for radius IPs point at service IPs
NASes point at radius IPs
server C - BGP advertised radius IPs with low local-pref
This means we can fail over *between* servers in Location 1 by stopping
ucarp; good for maintenance. If the location fails entirely, traffic
falls back to the "DR" radius server.
More information about the Freeradius-Users