On 10 Mar 2016, at 23:26, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 10, 2016, at 5:43 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks@sath.nhs.uk> wrote:
Thanks Arran, So it seems that disabling "chase referals" might fix things, it's certainly a huge amount quicker and doesn't sit there binding until timeout. If, as part of the redundant-load-balance module handling, the "downed" server gets called, it waits for a search result from the dead server for the res_timeout figure, and then tries to get back it's required pool amount since it deleted the inviable connection, but it tries the same server.
The problem here is interaction between the FreeRADIUS fail-over and the LDAP referrals. FreeRADIUS assumes that an LDAP server is just an LDAP server. When AD sends a referral... many things can happen.
This is the bit I'd like to understand - it then waits "Connecting to..." for about 75-80 seconds before it idles out all the pooled connections, even if the idle option in mods-enabled/ldap is set to something quite a bit lower like 20 seconds. Is this expected?
idle_timeout means "used successfully, and then not used for a while". If it sits in "connecting to" for 75-80 seconds, you want just a connection timeout. There should be one in the LDAP module configuration.
It's in the pool {} section. I went through and standardized it, so it's the same for every module that supports a connection timeout. It's also documented in the pool section for every module. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2