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