29-Aug-201605:59 - last edited on 28-Nov-202215:01 by JRahm
Hi all,
I am loadbalancing LDAP using the iAPP (11.6.0 HF6). Because a lot of clients are using LDAP via some kind of proxy-server (all have the same IP, but different ports), I would like to set up a peristence using the source IP and the source port.
I am currently using an iRule which is connected to the ldap vs.
when CLIENT_ACCEPTED {
set client_remote "[IP::client_addr]:[TCP::client_port]"
persist hash ($client_remote) 300
log local0. "Connection: Client($client_remote)"
}
The iRule is working fine regarding the loadbalancing itself. My problem ist, that the entrys in the persistence table are not timing out. My table is just getting bigger and bigger.
Why is my timeout not working?
I did some research in devcentral and found out, that the "persist carp" might be a better way. Is that correct?
"persist carp" has no timeout and isn't stored in memory, so you won't pin connections to a pool member, rather every request will follow the load balancing method. This may or may not be a problem for your web apps.
29-Aug-201606:50 - last edited on 28-Nov-202215:03 by JRahm
Hi Fat,
your client may use different LDAP Proxy server instances on the same node (by using a different Destination_Port). But then the individual LDAP server instances will most likely use a random SRC_Port from the same SRC_IP for every single LDAP connection to your Virtual Server. This is causing your currently implemented persist hash command to set up many individual persistence records for each single hash(SRC_IP+SRC_IP) combination in your session table.
Using persit carp will just avoid the creation of session table entries, but its as useless as persist hash since it will cause the clients to get a Round Robin style selection for each individual LDAP connection. Effectively you can skip the persist at all, to get the very same Round Robin results...
If persistence is absolutely mandatory for your application, then you're forced to perform a simple SRC_IP persistence (with all its negative side effects). Another option (but much more complex) would be to inspect the initial "SIMPLE BIND" LDAP connects, extract the BIND username or "Base-DN" (requires ASN.1/BER parsing skills) and perform session persistence using the extracted LDAP information. Unfortunately there is no way around if you require Load-Balaincing for the traffic of these LDAP Proxies while still providing Session Persistence for individual Clients or the requested LDAP information.
Note: If you want to get an intro of LDAP ASN.1/BER parsing and want to recycle some iRule code to retrive the LDAP usernames/Base-DNs out of a BIND request, then feel free to take a look to one of my LDAP related iRules on CodeShare...
Have experienced problem that persistence table built up the number of entries until LLB ran out of memory, upgrade to version 12.1.0 (from 11.6) solved the problem.
My LDAP-Loadbalancing is working without any persistence at the moment. I had to increase the idle timeout, but it's working for two days now without experiencing any problems.
Besides I tried the hash-persistence after updating to 12.1.1. and there is no problem with the persistence table any more. The entrys in the persistence table are timing out as expected.
I know this is an old post and I'm not sure if you're still an active member of the community. I have the same need, to create a persistance profile based off of source IP and source port. Are you still using the same above code or have you switched to something different?
