Forum Discussion
Ronnie110755
Altostratus
AltostratusTraffic Policies: More detailed information on Actions
I am in a situation where I need to employ Session Persistence via cookie insert method in a traffic policy rule. I understand the cookie insert session persistence , that's not a problem but there ...
Ronnie110755 I would say your assumptions are probably a good guess because that's how all other cookie insert works on the F5, or at least the ones that I have used. You should be able to test this fairly easy though by configuring the traffic policy with the defaults and then access the site to see what it returns in the response cookie. I believe the cookie insert does indeed work at the VS level because you have to associate the policy to the VS that you want to use the configured policy. From my understanding you have 3 ways to insert a cookie for cookie persistence. The first is through and HTTP profile, an iRule, and the method you are using which is local traffic policy. As far as when the cookie is inserted that is dependent on what you choose for that last field in the traffic policy. I know my method probably isn't the best method of discovery but sometimes when documentation is limited you do what you have to so you can figure it out. Thank you for the appreciation on that approach but always remember to not do this on a critical VS and try it on something that doesn't matter or configure a new VS for testing only which I always recommend.
The BIGipserver cookie is inserted by the persistence profile attached at the virtual server level. If you don't want that, you can remove the profile. You can then create your own cookie name using policy or irule.
Cookies inserted by the server in the HTTP Response are not really cookies, they are "Set-Cookie" headers that instruct the browser to form a cookie and send it back in the next resquest. It is iimportant to highlight the difference.
A policy or an iRule on the BIGIP virtual server can insert either a real cookie into the request or a "Set-Cookie" header into the response. In the request it would be simulating browser returning a cookie. In the response it would be simulating server Setting a cookie.
HTH
Thanks for pointing that out. We will pass this along to the UI and documentation people.
Ronnie110755Altostratus
AltostratusThank You Paullus!
Interesting method of discovery. I like it. Now this leads to more questions i.e. I guess it would be an option to leave the named and for fields blank, One would supply a value for the name if the organization does not want to use the default BIGipServer cookie? And not supply a for Value if one would want to expire the cookie/'close the session' when the browser closes? A yes answer for both seems reasonable.
A question also just came to mind. Using a Traffic Policy with a large number of rules doing uri path routing to destination pools. Could cookie insert method for session persistence be set at the virtual server level. This also seems reasonable since the cookie is set on the response from the server.
Paulius
MVP
MVPRonnie110755 I would say your assumptions are probably a good guess because that's how all other cookie insert works on the F5, or at least the ones that I have used. You should be able to test this fairly easy though by configuring the traffic policy with the defaults and then access the site to see what it returns in the response cookie. I believe the cookie insert does indeed work at the VS level because you have to associate the policy to the VS that you want to use the configured policy. From my understanding you have 3 ways to insert a cookie for cookie persistence. The first is through and HTTP profile, an iRule, and the method you are using which is local traffic policy. As far as when the cookie is inserted that is dependent on what you choose for that last field in the traffic policy. I know my method probably isn't the best method of discovery but sometimes when documentation is limited you do what you have to so you can figure it out. Thank you for the appreciation on that approach but always remember to not do this on a critical VS and try it on something that doesn't matter or configure a new VS for testing only which I always recommend.
- Ronnie110755
I was going to construct this traffic policy rule on in the CLI to see if that would provide any hints (On My Lab Devices 😁 ) since I did not get to the point yet of being able to pass any traffic to see what happens. Sometimes the CLI provides more info than the GUI. My biggest issue here is the lack of documentation when it applies to persistence in traffic policy rules. Overall, when you get past what 'for' implies (why 'timeout' wasn't specified, or something similar is beyond me) it all makes sense as cookies go. I imagine the effort to document every line of 'code' is daunting to say the least as a result sometimes it is a challenge to get to the exact interpretation.
Thanks Paulius