Forum Discussion

ccraddock_33000's avatar
ccraddock_33000
Icon for Nimbostratus rankNimbostratus
Nov 27, 2017

iRule and Cookie persistence

Hello DevCentral,

I am experiencing an issue where when my iRule is applied to my VS that has cookie persistence applied. Users are complaining that they are getting kicked out of their sessions randomly as they click through the web page. I believe what is happening is that when the the user establishes a connection with the VS, the iRule is not keeping track of which server in the pool the session was tied to. So when they click forward through the page the iRule will sometimes direct their request to the other pool member in the pool. How do I tell the iRule to make sure the user always hits the same server for the same session? Im reading about the "persist" option but am not quite sure how to write it into the iRule.

As a work around we disabled one of the web servers in the pool to guarantee all individual sessions go to the same pool member. Ive pasted the iRule syntax below. The iRule basically states "if the URI contains the word "resources" then send the request to the NGNX Pool (pool_atlprdngn170-a) , otherwise send it to the web pool (pool_atlprdweb170-a)."

Ive attached relevant configs below. Thanks:

ltm virtual virt_www.abc-xyz.com_443 {
        destination 10.110.8.37:https
        ip-protocol tcp
        mask 255.255.255.255
        persist {
            encrypted_cookie {
                default yes
            }
        }
        pool pool_atlprdweb170-a
        profiles {
            http { }
            prof_www.abc-xyz.com {
                context clientside
            }
            tcp { }
        }
        rules {
            irule_block_heartbeat_from_external_IPs
            irule_abc_net_only_any_sso_call
            irule_atlprdweb170-a
        }
        source 0.0.0.0/0
        source-address-translation {
            type automap
        }
        translate-address enabled
        translate-port enabled
        vs-index 114

ltm pool pool_atlprdweb170-a {
    members {
        atlprdweb17001:webcache {
            address 10.110.14.186
            session monitor-enabled
            state up
        }
        atlprdweb17002:webcache {
            address 10.110.14.187
            session monitor-enabled
            state down

    ltm rule irule_atlprdweb170-a {
        when HTTP_REQUEST {
     if { [HTTP::path] matches_regex "^/resources/.*" } {
       pool pool_atlprdngn170-a
     } else {
       pool pool_atlprdweb170-a
 }
application delivery
devops
iRules
LTM

8 Replies

Sort By
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Nov 27, 2017

    cookie persistence is passive and does not need iRule intervention. What kind of profile is prof_www.gsb-docs.com?

     

  • WithF5's avatar
    WithF5
    Icon for Nimbostratus rankNimbostratus
    Nov 27, 2017

    What you can try is activate the Match Accross... I would suggest you try Match Across services first... you have to activate it in the persistence profile.

     

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

     

    Depending on the bigip version you are using ,it is only possible enable that by TMSH.

     

  • ccraddock_33000's avatar
    ccraddock_33000
    Icon for Nimbostratus rankNimbostratus
    Nov 27, 2017

    WithF5,

     

    Thanks for this! I think the Match Across Pools option may be what I'm looking for. Again, what I think is happening is that everytime the user clicks through the web portal, the request is matching the iRule Logic, sometimes the request for the same session hits the same pool member, and sometimes it doesn't and gets redirected to the other pool member. Is there any way to see which pool member a particular session is assigned to?

     

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Nov 27, 2017

    you can decode the cookie values to determine destination. I think the likely issue is the lack of a oneconnect profile on your virtual server. Without oneconnect, the initial request in the tcp connection is load balanced to server A, and all subsequent requests within that tcp connection will also go to server A regardless of persistence because BIG-IP typically load balances connections, not requests. OneConnect overrides that behavior by effectively detaching the server side of the connection and forcing a load balancing decision on every request.

     

    You can read more about OneConnect and HTTP here.

     

  • WithF5's avatar
    WithF5
    Icon for Nimbostratus rankNimbostratus
    Nov 28, 2017

    If you go to tmsh and type "show sys connection" you can see all current connections on F5. It will show you 4 columns. The first column is the ip of the client, the second column is the VS that the client is reaching, the third column is the selfip that F5 is using to send the traffic to the pool member and the fourth column is the IP of the pool member...

     

    Be careful with this command, if F5 is receiving lots of connections it will show you several lines and it can load the CPU... I suggest you use grep to filter you search.

     

    If the answer is suitable for you, please, mark it as answer.

     

  • Kevin_Davies_33's avatar
    Kevin_Davies_33
    Icon for Nimbostratus rankNimbostratus
    Nov 28, 2017

    tmsh show sys connection has filters. Do not use this command without the filters. Don't feed tmsh show sys connection into grep as this will still list all the connections on the F5 and then pass them to grep. Use the builtin filters cs-server-addr, cs-client-addr and so on to limit the output from the command. cs is for clientside, ss is for serverside. See the help for the command.

     

  • Kevin_Davies's avatar
    Kevin_Davies
    Icon for MVP rankMVP
    Nov 28, 2017

    Please apply the oneconnect profile at the bottom of the virtual server properties window. Your iRule is attempting to load balance per http request so you will need this profile applied.

     

    • If the servers listed in two pools are the same then you can select the match across pools option in the persistence profile.