Alexander Clouter wrote:
Alan DeKok <aland@deployingradius.com> wrote:
The conclusion, we should not be paying any attention to 'currently_outstanding' or 'fr_rand()' when there is EAP traffic; I decided to add the clause !HOME_POOL_LOAD_BALANCE; things now work.
What do you think of the following patch, I think there is sound reasoning behind it, however of course I am just a network monkey?
Nope. The solution is to fix the EAP module. Edit src/modules/rlm_eap.c, function eap_handler_cmp(). Delete the comparison that checks src_ipaddr.
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).
Agreed, these balancing methods were meant to give predictable load balancing, so that EAP requests could be shared between multiple authentication servers, without worrying about synchronising EAP session state. If they do not (by introducing randomness), then they are broken. Removing the SRC address limitation would only fix the issue if the intermediary servers all talked to the same 'last hop' server, and didn't attempt to implement some kind of (predictable) load balancing themselves. The fact that the NRPS all talk to the same ORPS by default (unless it's offline) is probably a *bad* thing, as it concentrates all the load onto one server. In practice it doesn't really matter as load is never high enough to warrant balancing, but technically balancing the requests in a predictable way would be the better thing to do.
The code already creates a unique State attribute for each EAP session. So it really doesn't need to check anything else.
If that solves the problem, we can put the fix into 2.1.8.
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.
In the 'eduroam' case, if we removed the national RADIUS servers, and lets say I delivered the packets straight to the remote end, nothing stops FreeRADIUS delivering half an EAP session to the wrong box which would result in an Access-Reject.
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.
Hmm no. For reliability it'd be better if the check is removed as well (i'm not sure why it's there are all TBH), else you'd still have compatibility issues with older versions of FreeRADIUS. I've actually seen what Alex is describing on our ORPS but assumed that it was the Remote ORPS at fault. As a precaution i've set our servers proxying behaviour back to fail-over, but many people will still have the client-based balancing option set. Thanks, Arran