Persistence using Http cookie insert

Hi Raj,

 

 

When using cookie insert persistence with a 0 timeout, LTM will only set the cookie in responses when a new load balancing selection is being made. This is expected behavior as the client should continue sending the same persistence cookie on each request for the duration that the browser is kept open.

 

 

The most common issue with cookie persistence is not having a OneConnect profile. Do you have a OneConnect profile added to the virtual server? This is necessary whenever you're doing per HTTP request persistence. If you're using SNAT on the serverside connection, you should use a /0 source mask on the OneConnect profile. If you're not doing source address translation on the serverside connection, create a custom /32 source mask OneConnect profile and add that to the virtual server.

 

 

See this wiki page for details on why this is necessary:

 

http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/oneconnect

 

 

Aaron

Hi Aaron,

 

 

Enabling oneconnect profile resolved the issue.

 

 

Thanks

 

Raj

Hi, I have a similar problem, however this time the issue seems to be with the F5 not inspecting the cookie. Is it possible to tie the cookie id allocated by the F5 to the actual Pool member?

 

Thanks

 

Hi Rickin,

 

 

Have you added a OneConnect profile to the virtual server? See above about whether to use a /0 or /32 source mask.

 

 

Aaron

Hi Aaron, thanks for your response. I am a Network guy who specialises in routing and switching so please ignore my ignorance in regards HTTP 1.1. I will give you a little history to the issue. Initially the Virtual server was configured as a Performance HTTP to allow for cookie persistance, however it was found that the end server connection count with OneConnect enabled (as is by default on PerformanceHTTP) ramped up exponentally with each new connection and then got stuck in TCP Time_Wait. we reconfigured the profile as a Standard profile with HTTP and again with Cookie Persistance - this took away the issue with the large number of connections on the server and them not clearing down.

 

 

I have been told that the Application server (Apache) POSTing/Calling HTTP requests to the VIP is using HTTPClient with a pool of connections (connection manager) but maintains cookies and conversational state in the core HttpClient object. HTTPClient also uses 1.1 persistance which I believe also does not work with OneConnect (is this correct?). http://hc.apache.org/httpclient-legacy/performance.html

 

 

The user is now complaining that when this particular "pool" configuration is used on the HTTPClient the connections made from within the pool to the VIP does not maintain the cookie persistancy expected.

 

 

Due to the massive amounts of traffic targetting this VIP I'm finding it extremely difficult to find the individual instances.

Also sorry should add that the Developer wants Session stickiness which I believe is set by default. So all HTTP GETS within a session should have the same cookie

Also sorry should add that the Developer wants Session stickiness which I believe is set by default. So all HTTP GETS within a session should have the same cookie