EAPTLS Stress test: 2.1.7

[Alan DeKok]

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.