Oneconnect for LDAP Virtual server

https://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html has some good information in the recommendations section, including:

 

• Avoid using a OneConnect profile for non-HTTP virtual servers that process more complex transactions, such as FTP or RTSP. Doing so may result in traffic disruption and session failure. Even for simple non-HTTP protocols, an iRule may be required to manage connection reuse.
• The OneConnect profile may be used with any TCP protocol, but only when applied to virtual servers that process simple request/response protocols where transaction boundaries are explicitly obvious, such as those in which each request and each response is contained within a single packet.
• Avoid using a OneConnect profile for encrypted traffic that is passed through the virtual server to the destination resources in the encrypted state and is not terminated at the BIG-IP system.

For more LDAP load balancing info, check out Collin Walker's article https://devcentral.f5.com/articles/unbind-your-ldap-servers-with-irules

 

in short, ldap is not simple request/response protocol (e.g. one transaction contains bind, search and unbind). so, to use oneconnect profile, you have to tell bigip when it can detach serverside connection. what Colin shows is an excellent example.

 

in the newer version, ASN1:: command is introduced which can simplify the irule as shown in article below.

 

BER and DER: Why Encoding and Decoding Matter by Colin Walker

 

https://devcentral.f5.com/articles/ber-and-der-why-encoding-and-decoding-matter

 

Thanks Shaggy and Nitass,

 

I will go through both links.

 

Thanks, Sachin

 

As mentioned before, LDAP works in a different way as HTTP. For a sent HTTP request you can expect an immediate answer which will be matched to the clients request (there is no kind of message or response ID). This type of multiplexing/demultiplexing will be done by OneConnect.

 

With LDAP you can send a query which keeps a server busy for a while and during this time your client may send new queries (new message IDs) through the same LDAP bind (authenticated connection between client and directory server). The server may respond asynchronous with replies containing a message ID allowing the client to match it to the open query. Finally the server my send i.e. a "search completed" or other response.

 

So the responses from the server may be distributed over multiple replies and finished by a status message.

 

Afaik, TMOS currently does not have a LDAP proxy functionality and OneConnect does not support LDAP. It would be required to write an own iRule to intercept the LDAP traffic. Samples are available to replay the LDAP bind. F5 Professional Services may help you to develop an LDAP proxy iRule.

 

As already mentioned by Nitass, in newer TMOS versions the Basic Encoding Rules (ASN) are available in iRules to simplify decoding of LDAP messages (structured in serialized type-length-value containers).

 

Happy new year! :)

 

Happy New Year to all,

 

Thanks to all for valuable inputs. So oneconnect is not going to help in reusing server side connection in our setup(LDAP). Is there any other way to proactively open few server-side connection and keep them open?

 

Thanks, Sachin

 

Is there any other way to proactively open few server-side connection and keep them open?

 

bigip itself is not an application. we are able to manage clientside and serverside connection (e.g. reusing serverside connection for multiple clientside connection, multiplexing clientside connections).

 

So oneconnect is not going to help in reusing server side connection in our setup(LDAP).

 

why?