redundant-load-balance

[Alan DeKok]

On Jan 4, 2017, at 8:17 AM, Jonathan Gazeley <Jonathan.Gazeley at bristol.ac.uk> wrote:
> 
> Later, another LDAP server got itself in a funny state where it was up and responsive, accepting connections but timing out when FreeRADIUS tried to bind, with the message "Timed out while waiting for server to respond". For some reason, redundant-load-balance continued to send LDAP queries to the server even though it wasn't working properly.
> 
> How does rlm_ldap determine if a server is up or down, and what can I configure in my ldap modules or redundant-load-balance to ensure that if the LDAP server misbehaves in future, it will get marked as dead and cause redundant-load-balance to send queries to a different server?

   FreeRADUS tracks connections.  It assumes that if the connection is up and responsive, then the LDAP server is up.  If the connection is up but slow, FreeRADIUS assumes that the LDAP server is up and slow.

  There are few good ways to fix this problem.  Due to threading issues, the "redundant-load-balance" code doesn't remember data from previous requests.  We're looking at perhaps changing that in v4.

> Unfortunately as the event happened in the past I don't have debug logs - only the regular radius.log. We also don't know what caused the LDAP server to get into that state (our Windows guys are looking into it) so currently we can't recreate the problem, either.

  In short, if FreeRADIUS uses a database, you need to ensure that the database is up and responsive.  There is only so much that we can do in order to work around issues with broken databases.

  Alan DeKok.