cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to achieve session persistence through Persistence profile and iRule

SaiTeja
Nimbostratus
Nimbostratus

Hi,
We are trying to achieve sticky session based on header in the request.
This is the cofiguration we currently have in the setup:
A pool with loadbalancing algorithm as "Round Robbin" with 2 nodes.
Created an iRule with the following configuration where "sessionid" is the header based on which we need persistence.

 

when HTTP_REQUEST {
    if { [HTTP::header exists "sessionid"] } {
        persist uie [HTTP::header "sessionid"]
    }
}

 

Created a universal persistence profile based on the above iRule with a timeout of 1 hour.
Attached both iRule and persistence profile to VIP created over the required pool.

Expectation:
All the requests which are within persistence timeout with the same header value should be routed to same node in the pool.

Current Behaviour:
The requests which are well within timeout with same header value are routed to different nodes and the requests are failing.
Also, tried modifying iRule to config set in this KB, but that did not work as well: https://support.f5.com/csp/article/K7392
As the requests are within timeout and are still failing, I think the issue is not with timeout configuration and something with iRule. Can someone please help on how we modify the configuration in order to meet the requirement.

7 REPLIES 7

Have you seen this article:

https://support.f5.com/csp/article/K7964

I went through this article but we are sending the persistence parameter in the form of a header but this configuration has cookie in it, so was not sure if this would be helpful.

Please let me know if I am missing anything else

Mike757
Cirrus
Cirrus

If you want to read HTTP data, be sure to have an HTTP profile associated to the VS.

Also, if traffic is encrypted, you need Client/Server SSL profiles. 

/Mike/

We have a HTTP profile and Client/Server SSL profiles attached to the VS

Again why don't you just add one connect profile to test and exclude the most seen issue in the article "K7964: The BIG-IP system may appear to ignore persistence information for Keep-Alive connections" ?

You might be right, Nikoolayy, and indeed the first article mentioned by SaiTeja (K7392) does mention the use of OneConnect in conjunction with universal persistence as a best practice.

It might just be a matter of TMM instance relation to persistence entries - K23202610 gives you an idea of what I'm saying. Unfortunately I don't have field experience with universal persistence and I'm not sure if the behavior is the same on persistence types other than source address.

Maybe adding a bit of logging to the iRule would help understand what's going on.

/Mike/

Better check with the F5 sales as the F5 APM has SSO function to sign in to the backend servers after you authenticate to the F5 APM so maybe this help with the the pool members failover to not to again to authenticate as TCP RST could still be seen but the APM cookie should stay so when the user again connects to not need to authenticate to the APM and the APM to sign the user to the pool but if you want check with F5 Sales.

 

 

Authentication and SSO:

https://support.f5.com/csp/article/K08200035#link_02

 

 

f5 apm cookie:

https://support.f5.com/csp/article/K15387