Not how persistence works with an iRule “pool” command… but am wondering if it is not sending a request to a different pool member because if persistence.
I’d either combine the 2 irules into 1 or due to the fact that it’s the same event then you may want to use a priority to double ensure the irule no.2 fires the http_request event first
priority 100
when HTTP_REQUEST {
switch -glob [HTTP::uri] {
"/video/*" { pool VIDEO }
"/audio/*" {pool AUDIO}
"/text/*" {pool TEXT}
default {pool default_pool}
}
}
priority 10
when HTTP_REQUEST {
if { [HTTP::header "True-Client-IP"] equals "1.2.3.4"} {
log local0. " Requests from 1.2.3.4"
switch -glob [HTTP::uri] {
"/video/*" { pool VIDEO member video_a}
"/audio/*" {pool AUDIO member audio_a}
"/text/*" {pool TEXT member text_a}
default {pool default_pool member default_a}
}
}
}
@ Mohamed. the virtual server is cookie persistant. I cannot change it for business reasons. But does it mean persistance can override an iRule?
@ Nathan, prioritize two rules doesn’t solve it either. I haven’t tried to put two rules into one yet, do you mean cut rule_2 and paste it to the top of rule_1, and apply only one rule? will it change the flow ?
The iRule becomes effective straight away as it’s compiled as soon as you save it.
What Lies Beneath was right about OneConnect - apologies for not mentioning it myself. You may want to take a look at this askf5 KB article to see if this helps:
As nathan pointed out, you can use: pool member member.ip.address member.port to specify the specific member of a pool that you want to direct traffic to. The caveat is that you have to hard code it to the iRule.
This is because there is no simple way to get the BIG-IP to look at a pool, gather a list of members, designate a numeric value of membership, and then make a decision to direct traffic to something as generic as pool member 1, 2, etc.
What Lies Beneath’s suggestion could assist you with your automated testing. The OneConnect profile has several uses, but the one that will specifically help you in your automated testing is the ability to re-use existing connections and a deeper inspection of all incoming traffic allowing individual TCP Requests from the same source IP to be handled independently.
This is used in situations where you have a large amount of traffic coming into your BIG-IP from a NAT (or a service like Akamai) or a single testing server.
Without OneConnect enabled, persistence data is examined only in the first request of a Keep-Alive connection, so if multiple requests are sent on the same clientside Keep-Alive connection, LTM will persist them all to the same destination as the first unless a OneConnect profile is applied (even if logic contained in an iRule dictates otherwise).
@Mohamed Lrhazi
You can get strange behavior if you try and redirect traffic to a specific pool member after the initial load balancing decision has been made. The traffic will bounce back and forth between the Cookie Persistence pool member and the specified pool member.
If you capture the request initially like tqu is trying to do then the default cookie persistence should hold the traffic to the specified node for all remaining request.
If you are routing traffic to a different pool based on something like the [HTTP::uri] value then you should get another BIG-IP Cookie to hold the load balancing decision to the new pool’s pool member.
iRule’s can override and change persistence though see the command.
It’s hardly desirable but you could also try one other thing; setup three new pools, each containing only the single member you’d like used by IP 1.2.3.4 and then reference those in your iRule. It would be interesting to see if this worked or not.
I guess it’s the cookie persistent issue. Once I wait until cookie expired, no test fails at all.