EAP proxing with client-balance

Alexander Clouter alex at digriz.org.uk
Sat Oct 10 14:16:03 CEST 2009

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).
>  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.

For what it is worth, NAK? :)


[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

Alexander Clouter
.sigmonster says: <ahzz_> i figured 17G oughta be enough.

More information about the Freeradius-Devel mailing list