leopold wrote:
Another test case we did was stressing one freeradius server (no loadbalancers in the middle) and it could cope gracefully with load of 200 eaptls authentications/sec, but when we increased load to 300 auth/sec things when really bad 1. We could reproduce constantly this error Wed Sep 30 17:33:28 2009 : Error: rlm_eap: Failed to store handler Wed Sep 30 17:33:28 2009 : Error: rlm_eap: Failed to store handler Wed Sep 30 17:33:28 2009 : Error: rlm_eap: Failed to store handler
Hmm... the only thing I can suggest is to increase the "max_sessions" parameter in eap.conf.
Yes I understand your point regarding radius dropping/not responding to invalid eaptls messages and that it causes client retries and even more load on radius infrastructure, but unfortunately due to own bussiness requirements we can't send Access-Reject to a user/machine that "tries" to present a valid certificate during load conditions. We view a failure for a valid client as outage.
Well... that's a failure unusual requirement.
At some point when no answer is received from radius a valid client will retry and get to network, on the other hand when receiving Access-Reject client state machine goes into a state when retry timeout is too long and it will cause client machine outage.
And will the NAS think that the RADIUS server is down?
We think when client presents invalid certificate (signed by untrusted CA or expired certificate or revoked) then it should get Access-Reject which is good, but when error is cause by load or other infrastructure or network problems we feel that not responding in a better choice. Unfortunately there is no other reply code in radius protocol in addition to Access-Reject that says Access-CriticalError that indicates that sort of error condition.
That is an issue with the protocol.
If we still want to proceed with Do-Not-respond path, do you think it is doable?
It may work. Alan DeKok.