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? :)
Cheers
[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