Dynamic Clients and ldap threads?
Running Free Radius 2.1.7 against a Novell eDirectory LDAP Database. We're using Dynamic Clients for approx 1200 NAS element devices and looking up the Elements in our LDAP database. Even though we have ldap_connections_number = 50 in the modules/ldap we have issues with the dynamic clients. We can increase the number higher but it doesn't seem to make any difference. Each element sends a heartbeat packet to FR once a second to make sure it's still alive which we capture very early on in the authorize second and send a reject. When we restart FreeRadius and since the LDAP server takes about 30 ms to reply to the dynamic client lookup any other heartbeat requests get rejected as unknown clients. Is the newer versions of FreeRadius use the multiple connections of ldap in a more efficient way so that the client lookups work more effectively. Our dynamic clients config is: server dynamic_client_server { authorize { if ("%{ldap:ldap:///ou=Elements,o=Identities?ou?sub?cn=%{Packet-Src-IP-Address}}") { update control { FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}" FreeRADIUS-Client-Shortname = "%{ldap:ldap:///ou=Elements,o=Identities?l?sub?cn=%{Packet-Src-IP-Address}}" FreeRADIUS-Client-NAS-Type = "other" FreeRADIUS-Client-Secret = "%{ldap:ldap:///ou=Elements,,o=Identities?ou?sub?cn=%{Packet-Src-IP-Address}}" } } ok } } Is the dynamic clients ldap lookups only single threaded, or have I done something incorrect with the configuration?
Peter Lambrechtsen wrote:
Even though we have ldap_connections_number = 50 in the modules/ldap we have issues with the dynamic clients. We can increase the number higher but it doesn't seem to make any difference.
Or, you can do fewer queries.
Each element sends a heartbeat packet to FR once a second to make sure it's still alive which we capture very early on in the authorize second and send a reject.
That's a REALLY bad idea. See RFC 2865 for why keep-alives are harmful. See RFC 5997 for a better approach.
Is the newer versions of FreeRadius use the multiple connections of ldap in a more efficient way so that the client lookups work more effectively.
No.
Our dynamic clients config is:
server dynamic_client_server { authorize { if ("%{ldap:ldap:///ou=Elements,o=Identities?ou?sub?cn=%{Packet-Src-IP-Address}}")
This can be cached in a temporary variable: update control { Tmp-String-0 = "%{ldap:....}" } if (Tmp-String-0 != "") { update control { ... FreeRADIUS-Client-Shortname = "%{control:Tmp-String-0}" ... } } The changes it from three LDAP lookup to one.
Is the dynamic clients ldap lookups only single threaded, or have I done something incorrect with the configuration?
The dynamic client lookups are single threaded. Changing that is hard. Alan DeKok.
On Mon, Aug 15, 2011 at 3:05 PM, Alan DeKok <aland@deployingradius.com>wrote:
Each element sends a heartbeat packet to FR once a second to make sure it's still alive which we capture very early on in the authorize second and send a reject.
That's a REALLY bad idea. See RFC 2865 for why keep-alives are harmful. See RFC 5997 for a better approach.
No arguments here with that... I'll have a read through the RFC's and escalate to our hardware vendor.. But I don't like my chances :(
Our dynamic clients config is:
server dynamic_client_server { authorize { if
("%{ldap:ldap:///ou=Elements,o=Identities?ou?sub?cn=%{Packet-Src-IP-Address}}")
This can be cached in a temporary variable:
update control { Tmp-String-0 = "%{ldap:....}" }
if (Tmp-String-0 != "") { update control { ... FreeRADIUS-Client-Shortname = "%{control:Tmp-String-0}" ... } }
The changes it from three LDAP lookup to one.
Cheers for that, I need to query two attributes from the object, one for the shared secret and the other for the client shortname. So I could reduce it from 3 to 2 queries. rlm_ldap doesn't seem to support multi-valued attributes as per http://wiki.freeradius.org/Rlm_ldap I could store both valued in a single attribute then used a # or something as a delimiter then I could use a regex to split the string... Might look into that.
Is the dynamic clients ldap lookups only single threaded, or have I done something incorrect with the configuration?
The dynamic client lookups are single threaded. Changing that is hard.
Yup.. I thought so... :( Is there any limit on the file size of the clients.conf and how many entries? or it will just take as long as it will take and get re-read each time I HUP the server. Many thanks for your insightful answers Alan :) Cheers Peter
Peter Lambrechtsen wrote:
No arguments here with that... I'll have a read through the RFC's and escalate to our hardware vendor.. But I don't like my chances :(
If they don't follow the RFCs, then all bets are off. Who the heck are these people?
Is there any limit on the file size of the clients.conf and how many entries? or it will just take as long as it will take and get re-read each time I HUP the server.
I've tested 2.x with 500K clients. It took ~8s to start the server, and the server used ~2G of RAM. But it worked. You could also try using the "dynamic_clients" module. Put the clients into a subdirectory instead of LDAP. That will solve the LDAP load problem.
Many thanks for your insightful answers Alan :)
It's what I do... Alan DeKok.
participants (2)
-
Alan DeKok -
Peter Lambrechtsen