RADIUS, anycast, and high availability

[Phil Mayers]

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>
> wrote:
>
>> 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:

Location 1
   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

Location 2
   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.