Forum Discussion
dennypayne
Jan 21, 2009Employee
I have found a "trick" to get around this behavior. If you set the pool name as a variable and then call the variable in the pool statement, the iRule doesn't seem to "know" about status anymore. I had a similar problem with this rule:
when HTTP_REQUEST {
If the QA cookie exists, go to the QA pool.
if { [HTTP::cookie exists "QAPilot"] } {
pool WWW-QA
}
else
{
pool WWW-GLOB
}
}
when LB_FAILED {
LB::reselect pool WWW-GLOB
}
However, we needed the VS to fail if WWW-GLOB was down, even if WWW-QA was up (due to OSPF route advertisement). Doing this fixed the problem (since WWW-GLOB was set as the default pool, if the "if" doesn't fire it will fall out to that):
when HTTP_REQUEST {
If the QA cookie exists, go to the QA pool.
if { [HTTP::cookie exists "QAPilot"] } {
set lb_pool "WWW-QA"
}
else
{
set lb_pool "WWW-GLOB"
}
pool $lb_pool
}
If load balancing fails to the QA pool, load balance to the PROD pool.
when LB_FAILED {
LB::reselect pool WWW-GLOB
}
Denny