Forum Discussion
mr_skater99_640
Nimbostratus
NimbostratusSession Persistence
Hi all,
We are a group of developers in a larger organisation and recently we have been involved in a project that has required us to work a lot closer with our network engineers to configure our F5's for what we need.
We have some reasonably complex irules that after a bit of trial and error are functioning well.
What we are after now is session persistence.
The default setup within our organisation usually sets persistence to one of the application generated cookies - in this case jsessionid (tomcat).
This is fine in most cases from what we are told but we have a bit of a problem using this.
The problem we are seeing is that this cookie is not present until the second request. So the users first request will go through to server A, and then the second request may go through to server A or to server B (depending on the load balancing setup). The problem with this is the user has a session that was now created on server A and that is not recognised by server B. So server B gives you a new jsessionid and the Load balancer can then again either keep you on the same server B or flick you to server A upon your next request.
So, what we would like to do is have persistence based on a cookie that is set by the F5 on initial request so that we avoid the above situation. There are other situations where a application generated cookie will change and could cause errors depending on the load balancing algorithm in use.
How do we set up the F5's to create and persist on a cookie that they generated?
We are also told by our network engineers that the persistence setting is per F5 vip and not per pool - however we have seen doco to the contrary on here and other places on the net.
I just dont think our network guys have had the time to fully investigate the full potential of these devices and what they can actually do.
Please any guidance offered or links to doco would be greatly appreciated!
Thanks,
Scott
2 Replies
bilsch_10068This is a pretty simple task. You will want to create an http persistence profile such as this:
profile persist cookiePersist {
defaults from cookie
mode cookie
cookie mode insert
cookie name "fooCookie"
cookie expiration 00:00:00
}
Then you will need to assign an http profile to your virtual ( likely you already have this ) and set the persistence profile on the virtual to your cookiePersist profile like this:
virtual someAppVirt {
(...)
rules
... blah, rules
profiles
blah, some profiles plus your http profile
persist cookiePersist
}
The down side to this approach is that the cookie will be held by the browser until the session is closed - and by session I mean browser. Not the logging off - you will have to find a way to expire that cookie if you want to prevent them from coming back to the same app server.
You can also do http session persistence off of the jsessionuid cookie, refer to this from the code share: http://devcentral.f5.com/wiki/default.aspx/iRules/Weblogic_JSessionID_Persistence.html- dennypayne
Employee
Posted By mr_skater99 on 03/22/2009 11:13 PM
We are also told by our network engineers that the persistence setting is per F5 vip and not per pool - however we have seen doco to the contrary on here and other places on the net.
The persistence setting in v9.x is on the vip, it was on the pool in v4.x. It is much more flexible to have it on the vip, since you can have multiple vips point to the same pool with different persistence settings.
I concur with bilsch's recommendation above to set cookie insert persistence on the vip. That should ensure that each client is sent to the server they originally connect to for their entire session.
Denny
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
