Content Based Routing via iRule

@Mohamed

 

 

I'm sure that they explained it if they suggested it in an open case. I've always had a really good experience with F5 Tech Support when I ask questions. The OneConnect Wiki Page explains more about how it works as well.

 

 

Your question about keep-alives is covered in the second paragraph.

 

 

 

Without OneConnect enabled, persistence data is examined only in the first request of a Keep-Alive connection, so if multiple requests are sent on the same clientside Keep-Alive connection, LTM will persist them all to the same destination as the first unless a OneConnect profile is applied (even if logic contained in an iRule dictates otherwise).

 

 

To allow HTTP/1.0 clients to re-use backend connections, apply a OneConnect profile and an http profile with OneConnect transformations enabled (enabled in default http profile). With OneConnect transformations enabled, requests from HTTP/1.0 clients will be transformed into HTTP/1.1 requests using keepalives, allowing them to use OneConnect's HTTP/1.1 Keep-Alive connections as if they were v1.1 clients.

 

 

Clientside keepalives are not managed by OneConnect. LTM accepts keep-alive connections default and keepalive negotiation is managed by the client. The Max Requests option in the LTM http profile defaults to 0, allowing unlimited re-use of existing connections.

 

 

When using a OneConnect profile with an HTTP profile, if a pool member is marked down by a monitor and the pool setting for 'action on service down' is set to the default of none (no action taken), on the next HTTP request LTM will send a TCP reset to the client. Without both a OneConnect profile and an HTTP profile, LTM will allow client(s) to continue re-using the TCP connection for subsequent requests after the pool member has been marked down.