Forum Discussion
Hello,
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,
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