nikitha wrote:
When the request comes to the radius server, it goes one entry by entry in "users" file, ie., It connects to ldap-server-1 with the Ldap-Group tries from g1 till g20, and then connects to ldap-server-2 with Ldap-Group from "g21' till g50. If the user is part of Ldap-group "g50" it takes more time to return success, before itself the request times out, and received eap start again from wireless client.
Yes. The LDAP query results aren't cached.
If the "number of DEFAULT entry for ldap-server-1" is less than 10, then it works fine. If the default entry increases, the server takes more time to process.
Yes, the solution is to not configure so many queries that the server slows down.
I think redundant ldap server configuration is not correct or in some otherway we can fix it. Is it possible to configure the radius server in such a way that, try ldap-server-1 for the first policy, if its reachable then check it against the next policy.
For LDAP-Group checking, no.
If its not reachable mark this server as dead or whatever and ignore processing the next coming DEFAULT entries which matches with ldap-server-1 and try to process ldap-server-2 entries.
That may be possible with source code patches. i.e. If an LDAP server is marked "dead", don't try to contact it for a few seconds. That would help your configuration a lot. But your configuration is an artificial one that highlights a problem. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog