Forum Discussion
Thank's !
But I think it's better to swap irule order.
Because in this state, iRule1 match all time if 10.0.0.1 want to go on /uri1/test1. iRule1 don't have source IP condition.
I think it's better to have iRule2 more strict in first place and if it's not IP 10.0.0.1 or 10.0.0.2 iRule1 in second place match with.
regards
Jean_Mamèneyou are better off combining the two iRules rather than having 2 different rules because of iRule priority and unaccounted for behavior when jumping from one iRule to another. This is even more important because you have matches for the same destination URI path and having that in two locations will most likely cause unnecessary confusion in future troubleshooting and changes. In addition to that I would use a switch statement match with each path match having its own source IP match as an if statement within that string. Depending on how large your source IP list becomes for each URI path you might consider using a data-group to perform the matching and pool selection and a data group for URI matching for the overall URI match in the switch statement because of iRule line limits.
when CLIENT_ACCEPTED {
set DEFAULT_POOL [LB::server pool]
}
when HTTP_REQUEST {
set URI [string tolower [HTTP::uri]]
switch -glob $URI {
"/uri1/test1"
{
if { [IP::client_addr] eq 10.0.0.1 } {
pool pool1
} elseif { [IP::client_addr] eq 10.0.0.2 } {
pool pool2
} else {
pool pool1
}
}
"/uri2/test2"
{
pool pool2
}
"/uri3/test3"
{
pool pool3
}
"/uri4/test4"
{
pool pool4
}
default
{
pool $DEFAULT_POOL
}
}
}