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...
Cheers, Kai