Forum Discussion
NimbostratusCookie persistence with multiple cookies (iRules/cookie persistence profile)
NimbostratusHello,
That iRule is of poor quality for a number of reasons, but let's look at the questions nevertheless.
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?
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.
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?
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.
So if client has all 3 cookies in one request:
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.
regards,
Tadaoki_237078Hi 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 ] > 0 } { pool pool_foo } } default { if { [active_members pool_bar ] > 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
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.
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
If you have a specific goal in mind, it's best to describe what you want to accomplish instead.
- Tadaoki_237078
Thank you again.
OK, one last question to make sure i got it right...
(I will of course go through the articles that you mentioned) With OneConnect profile(or iRule LB::detach -command) enabled, will the request be balanced according to the cookie(s) present after the uri-switching?
For example: cookies presented = BIGipServerpool_foo(foo_a), BIGipServerpool_bar(bar_b)
request1: URI="/foo*" ⇒ foo_a
request2: URI="/somethingelse" ⇒ bar_b
Thank you in advance,
Kai
