EAP proxing with client-balance

[Arran Cudbard-Bell]

Alexander Clouter wrote:
> Alan DeKok <aland at 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20091010/d9a7c883/attachment.pgp>