Forum Discussion

SaiTeja's avatar
Icon for Nimbostratus rankNimbostratus
Aug 24, 2022

Unable to achieve session persistence through Persistence profile and iRule

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.


    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.

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:
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.

8 Replies

    • SaiTeja's avatar
      Icon for Nimbostratus rankNimbostratus

      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

  • 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. 


    • SaiTeja's avatar
      Icon for Nimbostratus rankNimbostratus

      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" ?

  • 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:



    f5 apm cookie:


  • If you managed to get the needed answers, please flag the question as answered.