Cookie persistence with multiple cookies (iRules/cookie persistence profile)

Question

Hi all,
I have some questions regarding cookies and how they are handled by iRules and/or profiles:

ltm rule /Common/rule_foobar { 
    when HTTP_REQUEST {     
        if { [HTTP::cookie exists "BIGipServerpool_foo"] } {
            if { [active_members pool_foo ] &gt; 0 } {
                pool pool_foo
            }
            return
        } elseif { [HTTP::cookie exists "BIGipServerpool_bar"] } {
            if { [active_members pool_bar ] &gt; 0 } {
                pool pool_bar
            }
            return
        }
        switch -glob [HTTP::uri] {
        "/foo*" {
           if { [active_members pool_foo ] &gt; 0 } {
               pool pool_foo
           }
        }
        default {
           if { [active_members pool_bar ] &gt; 0 } {
               pool pool_bar
           }
       }
   }
}

Question 1:
Let's say we have an iRule like the one above, and pool_foo and pool_bar have 2 members each called foo_a, foo_b and bar_a, bar_b(respectively). 
If the client has a cookie called  "BIGipServerpool_foo", he/she will be directed to pool_foo(right?),
and if the cookie contains information for foo_a, then he/she will get load-balanced to foo_a?
(and foo_b if the cookie contains information about foo_b?)

Is it possible for the client to have a cookie( or a cookie-pair) containing information for both foo_a and foo_b?
And what happens with the traffic when he/she has? 
(Or is it only possible to have one cookie per pool (and not members)?)

Question 2:
If the Virtual Server associated with the iRule, has a cookie persistence profile configured, 
does the cookie handling part of the iRule mean anything??
And again, what will happen if the client access with more than one cookie(a AND b) and the processor is the profile and not the iRule?

Thank you in advance,
Kai

hannes_rapp · Answer

Hello,&nbsp;
That iRule is of poor quality for a number of reasons, but let's look at the questions nevertheless. &nbsp;
1. Is it possible for the client to have a cookie( or a cookie-pair) containing information for both foo_a and foo_b? And what happens with the traffic when he/she has? &nbsp;
If you mean in scenario of a default cookie persist profile, then no. Cookie has one specific name and any additional cookie insertions would just over-ride the first one. Then the cookie inspected by persistence profile can also be "invalid". I.e., If it's intentionally crafted to contain junk information with tools like Fiddler. That would just get TCP RST in response only affecting the client who provided malformed cookie. Otherwise, it sure is possible for your client to have BIGipServerpool_foo and BIGipServerpool_bar cookies in one request. Client can have either intentionally or unintentionally set two cookies along with one request. Observing that iRule, the second condition is evaluated with ELSEIF, this means it only gets evaluated in case the IF condition before it provided no match. So if client has both cookies, BIGipServerpool_foo and BIGipServerpool_bar, he will always end up in pool foo. &nbsp;
2. If the Virtual Server associated with the iRule, has a cookie persistence profile configured,does the cookie handling part of the iRule mean anything?? And again, what will happen if the client access with more than one cookie(a AND b) and the processor is the profile and not the iRule?&nbsp;
I recommend to look at persistence function as a flag to bypass load balancing to default pool, and nothing else. In turn, you can bypass the persistence mapping itself. The way it plays out is that client is allocated a persistence cookie as set in persist profile but your control is not limited in any way by the presence of persistence cookies or profiles.&nbsp;
So if client has all 3 cookies in one request:&nbsp;
Persistence cookie mapped to a cookie persistence profile, let's say "BIGIP-POOL", then those "BIGipServerpool_foo" and "BIGipServerpool_bar" cookies. He will still end up in pool foo, regardless of where BIGIP-POOL pointed the connection to.&nbsp;
regards,&nbsp;

hannes_rapp_162 · Answer

Hello,&nbsp;
That iRule is of poor quality for a number of reasons, but let's look at the questions nevertheless. &nbsp;
1. Is it possible for the client to have a cookie( or a cookie-pair) containing information for both foo_a and foo_b? And what happens with the traffic when he/she has? &nbsp;
If you mean in scenario of a default cookie persist profile, then no. Cookie has one specific name and any additional cookie insertions would just over-ride the first one. Then the cookie inspected by persistence profile can also be "invalid". I.e., If it's intentionally crafted to contain junk information with tools like Fiddler. That would just get TCP RST in response only affecting the client who provided malformed cookie. Otherwise, it sure is possible for your client to have BIGipServerpool_foo and BIGipServerpool_bar cookies in one request. Client can have either intentionally or unintentionally set two cookies along with one request. Observing that iRule, the second condition is evaluated with ELSEIF, this means it only gets evaluated in case the IF condition before it provided no match. So if client has both cookies, BIGipServerpool_foo and BIGipServerpool_bar, he will always end up in pool foo. &nbsp;
2. If the Virtual Server associated with the iRule, has a cookie persistence profile configured,does the cookie handling part of the iRule mean anything?? And again, what will happen if the client access with more than one cookie(a AND b) and the processor is the profile and not the iRule?&nbsp;
I recommend to look at persistence function as a flag to bypass load balancing to default pool, and nothing else. In turn, you can bypass the persistence mapping itself. The way it plays out is that client is allocated a persistence cookie as set in persist profile but your control is not limited in any way by the presence of persistence cookies or profiles.&nbsp;
So if client has all 3 cookies in one request:&nbsp;
Persistence cookie mapped to a cookie persistence profile, let's say "BIGIP-POOL", then those "BIGipServerpool_foo" and "BIGipServerpool_bar" cookies. He will still end up in pool foo, regardless of where BIGIP-POOL pointed the connection to.&nbsp;
regards,&nbsp;

tadaoki_237078 · Answer

Hi Hannes,
Thank you very much for your answer!
Ok, so you can only have one cookie per pool regarding the default cookie persistence profile.
What if I have the default cookie persistence profile configured for the VS,
and the iRule is modified as follows (and pool_foo and pool_bar still have 2 members 
each called foo_a, foo_b and bar_a, bar_b(respectively)):

ltm rule /Common/rule_foobar { 
    when HTTP_REQUEST {     
        switch -glob [HTTP::uri] {
        "/foo*" {
            if { [active_members pool_foo ] &gt; 0 } {
                pool pool_foo
            }
        }
        default {
            if { [active_members pool_bar ] &gt; 0 } {
                pool pool_bar
            }
        }
    }
}

For each http request, depending on the uri it will be directed to pool_foo or pool_bar.
Let's say the client makes a request with uri="/foo*", and that he/she has a cookie for pool member "foo_a" of pool_foo. Will the request get load-balanced according to the cookie(i.e foo_a) 
, or the load-balancing method(e.g round-robin)?
Thank you in advance,
Kai

tadaoki_237078 · Answer

Hi Hannes,
Thank you very much for your answer!
Ok, so you can only have one cookie per pool regarding the default cookie persistence profile.
What if I have the default cookie persistence profile configured for the VS,
and the iRule is modified as follows (and pool_foo and pool_bar still have 2 members 
each called foo_a, foo_b and bar_a, bar_b(respectively)):

ltm rule /Common/rule_foobar { 
    when HTTP_REQUEST {     
        switch -glob [HTTP::uri] {
        "/foo*" {
            if { [active_members pool_foo ] &gt; 0 } {
                pool pool_foo
            }
        }
        default {
            if { [active_members pool_bar ] &gt; 0 } {
                pool pool_bar
            }
        }
    }
}

For each http request, depending on the uri it will be directed to pool_foo or pool_bar.
Let's say the client makes a request with uri="/foo*", and that he/she has a cookie for pool member "foo_a" of pool_foo. Will the request get load-balanced according to the cookie(i.e foo_a) 
, or the load-balancing method(e.g round-robin)?
Thank you in advance,
Kai

hannes_rapp · Answer

If you enable OneConnect profile on your Virtual Server, your BigIP will start balancing individual HTTP requests, and that would result in all /foo* GET or POST requests being balanced between foo_a and foo_b. Without OneConnect, either foo_a or foo_b will get all /foo* requests to itself for the entire TCP session. This happens because by default BigIP balances TCP connections, not individual HTTP requests. I'm assuming you use no OneConnect. Having a foo_a cookie means you already landed in foo_a at least once, and therefore all your /foo* requests will land on foo_a for the entire session. Persistence cookie is transparent and useless here. Load-balancing occurs for the very first /foo* GET request where either foo_a or foo_b is selected, and no load-balancing occurs at all for any /foo* requests thereafter.&nbsp;
If you want to understand persistence and balancing in detail, I recommend you look into articles which explain the topics in detail. My explanation may not include all the information and "what-ifs". Cookie Persistence
OneConnect&nbsp;
If you have a specific goal in mind, it's best to describe what you want to accomplish instead.&nbsp;

Forum Discussion

Cookie persistence with multiple cookies (iRules/cookie persistence profile)

8 Replies

Recent Discussions

F5 terminal - help to run commands - disk space full

vulnerabilities-CVE-2020-16150 & CVE-2013-0169

google autenticator broken barcode

Error while running ansible

ASM instance creation

Related Content

Decoding the IPv4 address from the persistence cookie

Disable cookie persistance in irule

Setting up persistence in F5 XC

How to generate the persistence cookie with an iRule

SOCKS5 SSL Persistence