Forum Discussion
tom_kleinpeter_
Nimbostratus
NimbostratusCookie hash persistence
I'm trying to keep the same user accounts going to the same members of a pool, even if they are accessing our site from different browsers and at different times of day (possibly hours apart). From reading the docs, it seems like the easiest way to do this is for my web site to set a cookie that is unique to the user, and then use cookie hash persistence on the BigIP. From my understanding, the BigIP will hash an identical cookie into the same member everytime (assuming the pool of members has not changed). Does this sound like the right approach?
Assuming this isn't too far off track, I have a few questions about this approach:
I assume because this is a hash function that the BigIP is not maintaining any state, correct? (we have a very large number of users)
What happens if the member of the pool that a cookie is hashed to goes down?
What happens if the pool itself is changed (new member is added, for instance) -- is everyone rehashed into a possibly different node?
Finally, I just wanted to confirm that the flow of events could be like this if the user does not have a cookie:
1. User connects with no cookie, bigIP load balances the connection to node A
2. node A sets user cookie, possibly handles several HTTP queries during the connection
3. User disconnects
4. Everytime the user reconnects now, the BigIP looks at the cookie and sends the user to node B
Thanks!
3 Replies
Your question is more a general BIG-IP persistence question, rather than an iRules question, but I'll try to give you some quick answers:
You are correct, all state for cookie persistence is maintained at the browser only.
A down node will cause the connection to be load balanced to an available node instead, as if no persistence token existed. The new node overwrite the persistence value in the existing persistence token with its own self-referencing value.
Changes to the pool membership will indeed cause changes in the resultant hash distribution.
Flow of events is correct, up to step 4, where I'm assuming you meant node A? Of course dependent on hash of Node A's cookie value resolving back to pool member NodeA, and on cookie expiry.
The LTM manual section on "passive cookie persistence" has the correct format for the initial cookie values you'd need to set for each user to hit a preferred node.
HTH
/d
tom_kleinpeter_I apologize if this is the incorrect forum, but I may have to write an IRule if the built in support does not work for me.
From the manual, it seems like cookie hash persistence is different from regular cookie persistence. That is why in my example I said node B, not node A. If the web server can set arbitrary data in the cookie, and the BigIP is just doing a hash on the cookie, then it seems totally possible the client would be sent to a different web server on the next connection.
Thanks!- You are correct about the possibility of the hash not evaluating to the server which set the cookie. Passive cookie persistence overcomes this flaw by having each server deterministically set the appropriate cookie value, which will in turn be decoded reliably by BIG-IP to send persistent connections to the inital server on subsequent requests.
And of course you're also right that there are myriad ways you can use any persistent value to achieve persistence with an iRule instead of using built-in features. If that's where you end up, I'm sure we can help with any additional questions that might arise.
Glad to be of assistance!
/d
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
