Alan DeKok <aland@deployingradius.com> wrote:
Alexander Clouter wrote:
Does mean that client-balance, client-port-balance and keyed-balance do not do as advertised on the tin though which I would want to grumble about being a Bad Thing(tm).
Err... that's not at all what I said. They work, and they have *nothing* to do with changes to the EAP module.
Sorry, they do not work as advertised. You clearly state (in proxy.conf) that as EAP is stateful you need to pick a sensible load-balancing algorithm. The config files tells me 'client-(port-)?balance' and intelligent use of 'keyed-balance' is a Good Idea(tm) for EAP traffic; which makes sense to me with my network monkey hat on. If I look at realms.c what I actually find is that the code does this up to the last three 'if' statements and then throws the baby out with the bathwater; reverting the whole thing to back to effectively 'load-balance'.
It is a receiver side only fix mind you that does not stop FreeRADIUS (or anything else) shifting packets to the wrong place. The fix is that you need to remove any uncertainty about where the traffic goes and having that load comparison[1] and an explicit call to a random shuffler royally breaks things by making things unpredictable.
The only random code in the "find home server' function hasn't changed in nearly 2 1/2 years.
...also can be read as it took 2.5 years for any of us to notice. :) I only noticed as I overhauled the mess that was my FreeRADIUS installation and noticed there were options other than 'fail-over' and 'load-balance' to pick from.
I would argue you actually want to keep the src_ipaddr check to pick up on upstream *broken* load balancers, unfortunately it's just currently FreeRADIUS does have a broken load balancer.
Could you be more specific?
F(client-ip_1) => x_1 F(client-ip_2) => x_2 When load balancing based on the client-ip: 'client-ip_1 == client-ip_2' therefore 'x_1 == x_2' FreeRADIUS does not do this, which is why EAP proxying breaks. This is akin to having two stateful firewalls and expecting TCP to function when you have asymmetrical routing taking place. I understand why those three 'if' statements are there and look like a good idea, however it morphs the fancier load balancing algorithms to just plain old boring 'load-balance' (the 'client' IP hashing is obliterated). As for keeping the 'src_ipaddr' check, I like it when tools I use in the network tell me when other stuff on the network is broken. The last thing I was is those tools to workaround buggy crap so I can make a business case to get them thrown off, replaced or fixed by the vendor. Having a warning telling me that a request was discarded as an upstream load-balancer is shafted is a Good Thing(tm). In this situation, without this enforcement, FreeRADIUS could (as MS IAS currently does and no doubt others) work around the issue, but you would get randomly failing EAP authentications when it turns out that for a proxy configuration (hopefully clear enough) that is: a --> m,n,o --> x,y a - me m,n,o - national proxies x,y - @realm I'm proxying The moment m,n or o start load-balacing, if I was to proxy to anything other than the same upstream proxy, my packet might start off arriving at 'x' and then suddenly go to 'y' when FreeRADIUS decides that fr_rand() function whats to get excited and get me using another proxy from the set [m,n,o]. Eeek! I would rather it *always* fails...looking at the logs it is hard to differentiate between the problem actually being with our RADIUS server or whether the issue is between the users keyboard and chair.
[1] obviously you still want the max outstanding check there, but you have to think of the case of (such as for us) where 'outstanding_sessions' is zero ~100% of the time
Maybe what you want is "pick the first live one, even if it's less used than the others".
Then I would want 'load-balance'; from reading what is in realms.c. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #191: Just type 'mv * /dev/null'.