Forum Discussion
IRule to select IRule doesn't work even if the condition triggers
- Apr 26, 2021
To know what pool was selected, maybe you have lot of pool selection logic or possibly the default may have been selected too, to know what's happening in HTTP_REQUEST, use this,
when HTTP_REQUEST { if { [HTTP::header exists testing] } { log local0. "Pre Pool selected is [findstr [LB::server pool] "" 8 ]" pool pool-troubleshooting foreach aHeader [HTTP::header names] { log local0. "Post Pool selected is [findstr [LB::server pool] "" 8 ]" log local0. "Redirecting to troubleshooting pool HTTP REQUEST HEADER $aHeader: [HTTP::header value $aHeader]" } } }
So if you see your intended pool not selected, you can do this,
when LB_SELECTED { if { [LB::server pool] == "/Common/DEFAULT-POOLNAME-443" && [active_members pool-troubleshooting] > 0 } { pool pool-troubleshooting LB::reselect } }
To know what pool was selected, maybe you have lot of pool selection logic or possibly the default may have been selected too, to know what's happening in HTTP_REQUEST, use this,
when HTTP_REQUEST {
if { [HTTP::header exists testing] } {
log local0. "Pre Pool selected is [findstr [LB::server pool] "" 8 ]"
pool pool-troubleshooting
foreach aHeader [HTTP::header names] {
log local0. "Post Pool selected is [findstr [LB::server pool] "" 8 ]"
log local0. "Redirecting to troubleshooting pool HTTP REQUEST HEADER $aHeader: [HTTP::header value $aHeader]"
}
}
}
So if you see your intended pool not selected, you can do this,
when LB_SELECTED {
if { [LB::server pool] == "/Common/DEFAULT-POOLNAME-443" && [active_members pool-troubleshooting] > 0 } {
pool pool-troubleshooting
LB::reselect
}
}
Hei @jaikumar_f5
As I mentioned in other reply I used the priority at the moment before actually checking your response. But I find your response to be the best and helpful for troubleshooting any such scenario. Thanks for the help.
I'm selecting this as the best response but would like to check with you, if setting the priority is a bad idea in this case?
- jaikumar_f5Apr 29, 2021MVP
Setting the priority is not a bad idea. It's always the design & requirements that define whether that app requires multiple irules & priorities in it.
There are environments where multiple irules would be used for different purpose. Some irules would be specific to security related & some would be related to app flow based.
Most times, security rules must be honoured than letting the traffic to flow through. So some orgs use the default irule order or some use the priority concept.
Lower priority events will be 1st executed then the higher priority events triggers. Though the lower events logic may be selected when processed, if there's an event with higher priority, it will be processed too & would override the manipulation. The default priority is 500.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com