Forum Discussion
Chris_Phillips
Nimbostratus
Nimbostratuscookie insert persist not working
Howdy,
I've got a pool of 4 JVMs (same IP, different port if that might be relevant) and am trying to use cookie insertion for the session persistence. This is principally because the connections are coming from any 1 of 5 standalone 8900's, which in turn have been load balanced by a standard 8900 HA pair. As such, stateful persistence mechanism would be instantly useless, as there is no guarentee which of the 2nd level of 8900's will receive the request. There is also an even high level of GTM potentially moving connections between two entire DC's each containing this architecture with a common end destination server farm.
My understanding is that the cookie insertion mechanism is totally stateless as the cookie value includes the ip and port to use, so there's no need for any session data to be held on any system, so any correctly configured LTM can always handle the request.
However... this is apparently not happening. In a sample of the logs on the server I can see the cookie is coming back in just fine:
2012-09-11 11:33:17 GET /service/userActivityHistory.app - '6012748' /service/userActivityHistory.app?command=userActivityHistoryResponse&alertId=3193244&hexUserID=303030303030303835333837383139&fromUserDetails=false&ruleID=10727&contextSiteId=UNKNOWN 200 'FB3416D24D5AEACD7BDD48240A74863' 10.3.8.2 'siteIdSelection=UNKNOWN; JSESSIONID=FB3416D24D5ADCD7BDD48240A74863; WT_FPC=id=72.15.129.210-4099525184.30213996:lv=1333023181739:ss=1333023181739; SESSION_ID=SMS_P1_0531::d2c92e24df4dc7347136ca83c8c74418; INTERNAL_USER=true; Identifier-Internal-SSO=PID,USERDOMAIN01\602748:2ynYDMzVImtMLaTng8knt/; t2_service_persist=222109962.37663.0000'
and the virtual servers are set up right:
profile persist t2_service_persist_cookie_pr {
defaults from cookie
mode cookie
cookie mode insert
cookie name "t2_service_persist"
cookie expiration immediate
}
virtual t2_service_apache_to_apps_85_vs {
pool t2_service_pool
destination 10.20.30.20:85
ip protocol 6
persist t2_service_persist_cookie_pr
profiles {
http {}
tcp-lan-optimized {}
}
vlans vlan123 enable
}
yet periodically the user will be sent to a different server and, not being known, get 302'd to a login page. Throughout this though the cookie value NEVER changes. it's always exactly the same, as it should be, yet is what... just being completely ignored?
Any clues?
Thanks
Chris
What_Lies_Bene1Cirrostratus
It's probably not a factor as you're using a session cookie but is the time on the 5 second level devices synchronised? Also, is there a chance that the clients are connecting to other Virtual Servers that use these same pool members? Lastly, can you check the logs on a server that's used when things break and see if the cookie is present and also decode it to see if it specifies that server or another?
Chris_PhillipsI believe they are syncs fairly well, ntp is running OK I understand.
These pool members are totally unique to this service, nothing else at all references them.
As above, the cookie is *always* there and *always* the same, even when it's hitting the wrong pool member.
Thanks- What_Lies_Bene1
OK, thanks. I've decoded the cookie as this;
[*] String to decode: 222109962.37663.0000
[*] Decoded IP: XX.XX.X1.13
[*] Decoded port: 8083
So do you see the cookie value change or is it the same one presented on all the JVMs? To put it another way, when things work, does the cookie decode and show the correct information for each JVM, in the logs? - Chris_Phillipsagain the cookie is *always* the same, even when it's hitting the wrong pool member.
hoolioHi Chris,
It looks like you don't have a OneConnect profile on the virtual server. This is necessary if you want LTM to parse each HTTP request on a TCP connection for persistence information. See this page for details:
https://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/oneconnect.html
Aaron- What_Lies_Bene1The cookie should be different for each JVM because the port used is different for each JVM pool member. So, can you please be explicit and state, do you see the same cookie value used for all four members of the pool when things are working or otherwise?
Regardless, I wonder if this issue might be coming into play somehow: http://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html?sr=24005434 - Chris_PhillipsOh hey Hoolio.
Interesting. It makes sense mostly, but I don't quite see why that would be causing the problem direclty though, as that connection is surely only used by a single client anyway..? I don't think there is any point in the equation where multiple cookies will pass over a single tcp connection. we have connection reuse by the client sure, but there's no oneconnect in use elsewhere, and wouldn't that be required if there was reuse of the connections between the two LTM tiers? Can't see where else multiple clients connections would get mixed up...? - Chris_Phillips
WLB... how much more explicit could I possibly be??? I've said three times now it's always the same regardlss of which member it hits... Thanks for looking anyway, appreciated.
Hmm, actually maybe it's our corporate proxy... not sure if this traffic passes through it or not.
I wanted to sound really annoyed and indignant that the cookie persistent docs really don't mention a oneconnect profile, but they totally do... ugh.
I think we're done here! :)