Forum Discussion

rajesh1's avatar
rajesh1
Icon for Nimbostratus rankNimbostratus
Jun 02, 2011

Persistence using Http cookie insert

Hi,

 

 

We are having the issue with virtual server configured with persistence profile - Cookie (Http cookie insert method) and expiration set to session cookie (default).

 

 

Its been observed , for some request the F5 cookie is not appended and causing internal server error.

 

 

 

I am running bigip version - 10.2.0.

 

 

Any thoughts why there are no cookies appended for some of the requests.
  • 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
  • Excuse the double post above. One more thing that comes to mind is that if the HTTPClient pooling is not used then there seems to be no issue. The application server hosts both internal connections from internal users (no pooling on HTTP Client) and also web users (where http pooling is used). So internal users seem to be fine, only seems to be an issue with the external internt connections which utilise the HTTPClient pool configuration. Again apologies for my ignorance when it comes to http 1.1 and this HTTPClient Pool concept.