RADIUS, anycast, and high availability
Hello all, We’re looking into using anycast and a group of servers for some of our stateless services (like DNS and NTP) to increase availability, as anycast “automatically” routes traffic to one machine in a group. I’m wondering if RADIUS is a good candidate for this as well. Being UDP-based is a good start, but I don’t know if the servers will get annoyed if (say) multiple packets in an EAP conversation don’t go to the same server. DNS is much simpler as its usually single-shot (request -> reply). Basically: has anyone else tried it? Or is this a Bad Idea and I just stick to regular multi-server with failover on the NAS? Thanks, Jason
Jason Healy wrote:
We’re looking into using anycast and a group of servers for some of our stateless services (like DNS and NTP) to increase availability, as anycast “automatically” routes traffic to one machine in a group. I’m wondering if RADIUS is a good candidate for this as well. Being UDP-based is a good start, but I don’t know if the servers will get annoyed if (say) multiple packets in an EAP conversation don’t go to the same server. DNS is much simpler as its usually single-shot (request -> reply).
Anycast will work for RADIUS under the following conditions: - only PAP, CHAP, or MS-CHAP is used - all RADIUS servers share the same list of clients - including the same shared secret for each client <-> IP pair
Basically: has anyone else tried it? Or is this a Bad Idea and I just stick to regular multi-server with failover on the NAS?
It will work. NAS failover is generally horrible. Alan DeKok.
Hi,
I dont’t know if the servers will get annoyed if (say) multiple packets in an EAP conversation don’t go to the same server.
yes. they will. they'll get very annoyed and drop/reject the request as it means nothing to them (there is no context or state etc known). ongoing packets mean nothing to another server, caching etc wouldnt be present.... however, with normal /typical anycast the same server would be used until theres a problem - like dead server, at which point you'd start using another server...which wouldnt be any different to having a dead server anyway. alan
On 26/06/14 13:18, Jason Healy wrote:
annoyed if (say) multiple packets in an EAP conversation don’t go to the same server.
Yes, that's absolutely a problem. All packets in an EAP conversation must go to the same server, and ideally all future EAP sessions to allow you take advantage of session resumption. However, see below.
Basically: has anyone else tried it? Or is this a Bad Idea and I just stick to regular multi-server with failover on the NAS?
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. Basically - if you're going to do this, ensure traffic to the anycast IP only reaches one server from every point during stable operation. During a routing change - which is presumably a failure event - packets will flow differently, but that doesn't matter because it's a failover event anyway. Having said all that - I personally would not use anycast for radius. Specify multiple servers on your NAS, and use some sort of sticky load balancing or active/standby failover of those IPs.
On Jun 26, 2014, at 8:53 AM, Phil Mayers <p.mayers@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 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.
Basically - if you're going to do this, ensure traffic to the anycast IP only reaches one server from every point during stable operation. During a routing change - which is presumably a failure event - packets will flow differently, but that doesn't matter because it's a failover event anyway.
Exactly. So long as the happy path is stable we can deal with a little weirdness around failures, as they would cause hiccups with regular NAS failover anyway. I’ll add it to my to-do list, then, and see if we can get it running. Thanks for the advice! Jason -- Jason Healy | jhealy@logn.net | http://www.logn.net/
On 26/06/14 17:35, Jason Healy wrote:
On Jun 26, 2014, at 8:53 AM, Phil Mayers <p.mayers@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.
On 26 Jun 2014, at 17:35, Jason Healy <jhealy@logn.net> wrote:
On Jun 26, 2014, at 8:53 AM, Phil Mayers <p.mayers@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!)
To be honest you probably made the right choice, even if it did cause an amusingly large amount of political fallout at HP :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
In article <xs4all.A06438D2-4935-406C-BC80-73C6DB2A3F48@logn.net> you write:
On Jun 26, 2014, at 8:53 AM, Phil Mayers <p.mayers@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 same IPs.
If you're on Juniper, you might want to look into this: http://www.slideshare.net/SkillFactory/02-34638420 page 27-30: L3-L4 load balancing with consistent hashing. You do need to inject routes from your radius servers, so use ExaBGP for that: https://github.com/Exa-Networks/exabgp Mike.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Jason Healy -
Miquel van Smoorenburg -
Phil Mayers