Forum Discussion
Andrea_Knapp_28
Nimbostratus
NimbostratusSession intermixing issue - due to Cookie not being sent every call?
we are currently having issues with our v9.3 implementation when we go into production we have session intermixing issues with users who are behind a proxy. Tech Support has stated that there is a difference between v4.5.13 and v9.3 in how the cookie is presented.
This is what tech support has stated :
"In version 4, if the client makes a request and includes the BigIP persistence cookie in the cookie list, the BigIP reads the cookie and load balances accordingly. However, the BigIP continues to set the same cookie in subsequent HTTP 200 responses to the requestor.
In version 9, if the client makes a request and includes the BigIP persistence cookie in the cookie list, the BigIP reads the cookie and load balances accordingly. However, in version 9 the BigIP does not continue to set the same cookie in subsequent HTTP 200 responses"
Their suggestion was to use an iRule in which the cookie is examined everytime and then reinserted back to the customer in v9.3. Here is the iRule that they provided
when HTTP_REQUEST {
if { [HTTP::cookie exists "BIGipServerP_HTTP"] } {
If the cookie does exist, let's grab the contents.
set old_cookie [HTTP::cookie BIGipServerP_HTTP]
}
}
when HTTP_RESPONSE {
Now re-insert it
HTTP::cookie insert name BIGipServerP_HTTP value $old_cookie
set new_cookie [HTTP::cookie BIGipServerP_HTTP ]
}
In which the value for BIGipServerP_HTTP is the same value as the persistent profile cookie that is set for that virtual.
I tried the iRule as written above but it completely broke the site. I believe it broke the site because the rule is based on having a cookie already. If the cookie does not exist how does it get created?
To get it to some what work we had to change it to the following:
when HTTP_REQUEST {
if { [HTTP::cookie exists "BIGipServerP_HTTP"] } {
If the cookie does exist, let's grab the contents.
set old_cookie [HTTP::cookie BIGipServerP_HTTP]
} else {set old_cookie 0}
}
when HTTP_RESPONSE {
Now re-insert it
HTTP::cookie insert name BIGipServerP_HTTP value $old_cookie
set new_cookie [HTTP::cookie BIGipServerP_HTTP ]
}
This is still causing issues as we now can get to the site, but sessions are expiring
Since I am not proficient in creating iRules I need some assistance. I believe what needs to happen is that the cookie needs to be inserted. Is there are way to do the following:
if the cookie exists set to old_cookie
if not then use persitent profile BIGipServerP_HTTP
if old_cookie exists then re-insert and send back to customer.
Thank you,
Andrea
7 Replies
hoolioCirrostratus
Hello,
Are you using a session cookie (ie no timeout) on the persistence profile? If so, the BIG-IP shouldn't need to set the persistence cookie on every response. The client should continue to present the session cookie in every request to the VIP regardless of whether it's been set in every response. The reason you'd want to set the cookie in every response is if there was an expiration time on the cookie. Re-setting the cookie on each request would tell the client to continue sending the cookie in subsequent requests until the new timeout expired.
With that said, do you have a specific reason for thinking that setting the cookie on every response will fix the persistence failures? If so, it's simple enough to check for the cookie in requests and set it again in the response. The persistence profile will dictate that the cookie is set on the first response to a request without the cookie. If you don't have a specific reason, I'd suggest looking at other potential configuration and/or pool issues first. For instance, do you have a OneConnect profile enabled on the virtual server? This will ensure that each request on a TCP connection will be parsed for persistence decisions even if the request is going to the same pool as the previous request on the same TCP connection. Also, do you see the pool members being marked down? This will cause persistence failures because the original node can't be used for subsequent requests.
Aaron
Andrea_Knapp_28Hi Aaron,
We are curently using no timeout on our persistence profile. We also have OneConnect enabled with a 255.255.255.255 netmask.
F5 support has suggested this as a solution to our issue with sessions being intermingled with users that reside behind a proxy. My team and I are very skeptical that this will solve the issue, but we are doing our due diligence and running this is our test servers. The objective for this iRule is to create the same likeness that we have in 4.5.13 for 9.3.
Also, no pool members are being marked down.
Have you ever heard of anyone having issues with users that have session intermingling when upgrading to v9.X?
Thanks,
Andrea- hoolioI suppose anything is possible. This poster (Click here) found their issue was fixed by setting the cookie on every response.
Here is a cleaned up version which saves the cookie in the request and inserts it if the response doesn't already contain a persistence cookie. I didn't test it, but it looks right.
Can you give this a shot?
Aaronwhen HTTP_REQUEST { Determine the persistence cookie name. This assumes it hasn't been customized in the persistence profile. If it has been customized, just hardcode the name here instead. set persist_cookie_name BIGipServer[LB::server pool] Save persistence cookie value if it exists in the request if {[HTTP::cookie exists $persist_cookie_name]} { If the persistence cookie is present in the request, save the value set old_cookie_value [HTTP::cookie value BIGipServer$pool_name] } } when HTTP_RESPONSE { If the response doesn't already have a persistence cookie and the request did, insert the value from the request if {not ([HTTP::cookie exists $persist_cookie_name]) and [info exists old_cookie_value]}{ HTTP::cookie insert name $persist_cookie_name value $old_cookie_value } } - hoolioActually, it would make more sense to explicitly unset the value for the request cookie if it's not present, so you don't get a stale value. Can you try this version instead?
Aaronwhen HTTP_REQUEST { Determine the persistence cookie name. This assumes it hasn't been customized in the persistence profile. If it has been customized, just hardcode the name here instead. set persist_cookie_name BIGipServer[LB::server pool] Save persistence cookie value if it exists in the request if {[HTTP::cookie exists $persist_cookie_name]} { If the persistence cookie is present in the request, save the value set old_cookie_value [HTTP::cookie value BIGipServer$pool_name] } else { If the cookie wasn't present in this HTTP request, unset the variable so it's not available for subsequent requests on the same TCP connection. unset old_cookie_value } } when HTTP_RESPONSE { If the response doesn't already have a persistence cookie and the request did, insert the value from the request if {not ([HTTP::cookie exists $persist_cookie_name]) and [info exists old_cookie_value]}{ HTTP::cookie insert name $persist_cookie_name value $old_cookie_value } } 
David_RemingtonEmployee
Posted By aknapp on 03/12/2008 1:25 PM
Hi Aaron,
We are curently using no timeout on our persistence profile. We also have OneConnect enabled with a 255.255.255.255 netmask.
F5 support has suggested this as a solution to our issue with sessions being intermingled with users that reside behind a proxy. My team and I are very skeptical that this will solve the issue, but we are doing our due diligence and running this is our test servers.
Andrea,
There is actually a very good reason why you would be seeing this in v9 but not in v4.
Basically, in v9 the cookie is only inserted on the very first request in a keep-alive session. Once it establishes the flow to the server it bypasses the persistence processing for that tcp session. But, most proxy servers use keep-alives to improve performance--sometimes even sending requests from multiple users down the same keep-alive session.
In v4, oneconnect was enabled by default, turning it off was a box-level decision, and the cookie persistence logic was invoked for every http request. In v9 oneconnect is only enabled if you are using a fasthttp virtual server or if you add a oneconnect profile to a standard virtual server with an http profile.
Turning on OneConnect in v9 will cause load-balancing to occur for each http request instead of each tcp connection--which ensures that the persistence mechanisms are invoked.
I have multiple customers who have made this same issue go away by mere application of a oneconnect profile but please feel free to follow up if your situation is unique. I love iRules, but I like built-in features better.
This article by Deb says what I just said, only probably much better:
http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/OneConnect.html- hoolioHi David, I think Andrea was saying she was skeptical that setting a session-based persistence cookie on every response would fix the problem. She mentioned that they were already testing with a OneConnect profile with a /24 netmask but the failure was still occurring.
Andrea, I would suggest capturing tcpdumps of the failure occurring with the OneConnect profile enabled and taking those traces back to F5 support. You might also try capturing traces with OneConnect and an iRule to set the cookie on every response if it's not already present. Either way, support should help you diagnose the issue.
Aaron 
marcus_63918Andrea - wondering if you ever found the fix for your problem?
We have basic cookie persistence enabled and, in rare cases, the browser doesn't seem to be returning the cookie with every request (which is odd, because other cookies make it through with the same timeouts implying that cookies and clock settings are correct on the client's browser). This happens to about 3 users a day out of about 4000.
I see people suggesting enabling one-connect which we currently have turned off, but I don't understand how that will matter if the cookie isn't present at all in the headers submitted by the client? ie: It's not a matter of the LTM parsing the cookie and sending the user to the proper node, but a matter of the cookie not being there at all.
Thoughts?
Marcus
