IRule to select IRule doesn't work even if the condition triggers

Question

Problem Statement:Trying to create a I-Rule to forward traffic to a pool "pool-troubleshooting" in case a header is passed in a request, the "if" condition triggers as the logs are part of the loop but still the traffic goes to the default pool at Virtual server.BIG-IP 14.1.2&nbsp;IRule:&nbsp;when HTTP_REQUEST {&nbsp;if { [HTTP::header exists testing]&nbsp;} {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pool pool-troubleshooting&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;foreach aHeader [HTTP::header names] {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;log local0. "Redirecting to troubleshooting pool HTTP REQUEST HEADER $aHeader: [HTTP::header value $aHeader]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}}&nbsp;&nbsp;Logs:&nbsp;&nbsp;Rule troubleshooting-pool &lt;HTTP_REQUEST&gt;: Redirecting to troubleshooting pool HTTP REQUEST HEADER Host: example.com&nbsp;Rule troubleshooting-pool &lt;HTTP_REQUEST&gt;: Redirecting to troubleshooting pool HTTP REQUEST HEADER User-Agent: curl/7.68.0&nbsp;Rule troubleshooting-pool &lt;HTTP_REQUEST&gt;: Redirecting to troubleshooting pool HTTP REQUEST HEADER Accept: */*&nbsp;Rule troubleshooting-pool &lt;HTTP_REQUEST&gt;: Redirecting to troubleshooting pool HTTP REQUEST HEADER testing: True&nbsp;Rule troubleshooting-pool &lt;HTTP_REQUEST&gt;: Redirecting to troubleshooting pool HTTP REQUEST HEADER TLS-Version: TLSv1.2&nbsp;Rule troubleshooting-pool &lt;HTTP_REQUEST&gt;: Redirecting to troubleshooting pool HTTP REQUEST HEADER TLS-Cipher: EXXXXX&nbsp;Any help in troubleshooting will be appreciated. :)&nbsp;

jaikumar_f5 · Accepted Answer

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" &amp;&amp; [active_members pool-troubleshooting] &gt; 0 } {
pool pool-troubleshooting
LB::reselect
}
}

heino · Answer

There's the classic with checking the spelling of the pool, and if it is the right server in the pool. Checking if there's a preceeding or proceeding irule that "overwrites" your new settings. That aside. I see no actual issue with your irule. SuggestionsTry selecting the specific pool member: pool named_pool member named_member port even if there's only one serverUse the node command: node x.x.x.x 80 (or whatever port)Try reselecting the pool in a later event. when HTTP_REQUEST {
  set vtrouble False
&nbsp;
  if { [HTTP::header exists testing] } {      
           set vtrouble True
           foreach aHeader [HTTP::header names] {
           log local0. "Redirecting to troubleshooting pool HTTP REQUEST HEADER $aHeader: [HTTP::header value $aHeader]"
               }
       }
}
&nbsp;
when LB_SELECTED {
    if { $vtrouble == True} {
        LB::reselect pool pool-troubleshooting
    }
}I'm pretty sure there's a different reselect command, but I can't recall it. I mostly give above suggestions as I've run into a similar situation before, where changing the expression from pool to node solved the issue. No clue why. I had 30 other rules where I used the same pool command with a different pool.

sam_kal · Answer

Thanks for responding to the question and I got hint from your answer to check the proceeding and preceding rules. I assumed that moving rules up and down change their precedence but realized later that it was priority which basically defines that.

Tried first two options that didn't helped and then assigned a high priority to the condition/irule and it worked.

Thank you again.

sam_kal · Answer

Hei&nbsp;@jaikumar_f5​&nbsp;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_f5 · Answer

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.

Forum Discussion

IRule to select IRule doesn't work even if the condition triggers

5 Replies

Recent Discussions

import live updates from version x to version y

Tenant image upgrade

iRule editor partition button does not work

F5Access | MacOS Sonoma

Overwriting or adding LTM SSL Traffic cert and key using iControlREST

Related Content

Leveraging Ansible Rulebooks for Streamlined Event Triggers: Advantages and Benefits

Leverage F5 BIG-IP APM and Azure AD Conditional Access Easy button

iRules 101 - #13 - Nested Conditionals

Irule Trigger two times

condition irule OR not working