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.
Paulius
MVP
MVPRonnie110755 The for box allows you to set the expiration time of the cookie in the formatting [Nd][HH:MM[:SS]] and I do not have documentation on this but it was retrieved from me typing in giberish into that box and the error provided me what that field is for and the formatting for the expiration of the cookie.
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.
John_AlamEmployee
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
- Ronnie110755
So, this is all good as cookies go and very clear. My issue is more towards the implementation of persistence as it pertains to Local Traffic Policies and the way it was presented (worded) in the GUI and CLI. The presentation made me question if there are any differences between persistence applied at the virtual server level and persistence applied in the traffic policy rules.
i.e. in the General Propertis for Cookie Persistence it is referred to as 'expiration' in the traffic policy rule it is referred to as 'for'. Me, being a curious person, had to determine if this meant something different.
At this point, there does not appear to be any differences between the two. What is very clear is the flexibility provided by being able to apply persistence on a per rule basis, where it is needed. I just wish there was clearer documentation specific to the topic.
Thank You John!
- John_Alam
Thanks for pointing that out. We will pass this along to the UI and documentation people.
- Paulius
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.
- 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