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