Forum Discussion
Ian_Stewart_390
Nimbostratus
NimbostratusiRules Pool Selection
Hi. 😃
We have an F5 BigIP-1500, running 9.04, configured with 4 virtual servers. (80/443 on IP1, 80/443 on IP2). Persistance is by cookie insertion, and is enabled across services. We have OneConnect enabled, and do compression based on browser and resource type.
We're in the process of moving from an older website infrastructure to a new one, so we have a URL based routing rule that moves people on to the new server when they access certain URLs. The rule is as follows:
when HTTP_REQUEST {
set my_uri [string tolower [HTTP::uri]]
set my_host [string tolower [HTTP::host]]
if { $my_uri contains "/iRuleURI/" } {
pool webnode_pool
log local0. "Directing to Webnode pool: $my_host $my_uri "
}
if { $my_uri contains "aspnet_client" } {
pool webnode_pool
log local0. "Directing to Webnode pool: $my_host $my_uri "
}
}
www.mywebsite1.com (HTTP/HTTPS) uses ecommerce_pool
www.mywebsite2.com (HTTP/HTTPS) uses webnode3_pool
-----------------------------------------------
I'm on www.mywebsite1.com/goodtimes.aspx
Button 1 makes a HTTP post to
www.mywebsite1.com/iRuleURI/otherpage.aspx.
Button 2 makes a HTTP POST to
www.mywebsite2.com/uri1/page.aspx
Clicking button 1 should route traffic to webnode_pool. (iRule)
Clicking button 2 should route traffic to webnode3_pool.
If, on hitting the page for the first time, I click button 1, it works correctly. Or, if I click button 2 it works correctly. However. If I click button 1, and close the popup-page, and then click button 2, it incorrectly posts my data to webnode_pool. This results in a 404 Page Not Found. Then, if I hit refresh, it correctly posts to webnode3_pool, and it works.
I have packet logs to show I'm not crazy, and this really is happening. In the described situation, the F5 creates a new TCP connection to the wrong pool, and makes a post that fails. Then I hit refresh, and it creates a new TCP connection to the RIGHT pool, and the post goes though.
Any ideas on why this might be happening? I called support, because this seemed like it might be a bug (having read your post), but they asked me to post here.
-Ian
6 Replies
- Well, the only thing obvious to me is that you saved your uri in lowercase, but then are comparing it to a string containing both upper and lowercase characters. Doesn't seem like that would ever match...
So, you may want to try changing your "/iRuleURI/" to "/iruleuri/". 
Ian_Stewart_390That's my own fault. =) The actual iRule is written correctly in that sense -- I changed the capitialization to camel case in order to try and make my post more readable. =)- The other thing I noticed is that your if's are not chained. Eg, it's not "if { expr } { body } elseif { expr } { body }"
So, if you happen to encounter a uri that contains both "iruleuri" and "aspnet_client" then the latter pool will always be used, though you might be expecting the former. You could test that by simply changing the second "if" to an "elseif" (and make sure there is either no whitespace either before the "elseif" or on the end of the preceding "}" line OR combine the "elseif" onto the preceding line). - Ian_Stewart_390Hi unRuleY,
Your point about the rules not being chained is valid -- I made that change. Also, thank you very much for your replies thus far. +) However, that change didn't fix the problem, nor would I expect it to because the iRule shouldn't fire on any of it's conditions in this case.
The URL on button 2 should not trigger any of the iRule if statements. And indeed if I turn those log statments on, I can see that the iRule doesn't fire. But the F5 still makes it's inital connection to the wrong pool. And then on the refresh, makes the right connection.
Can you think of any circumstance under which the F5 might not connect a virtual service to it's default pool after processing an iRule that didn't meet any of it's {if} statements?
-Ian - You may also want to look at this post: Click here
http://devcentral.f5.com/default.aspx?tabid=28&view=topic&forumid=5&postid=2066 - Ian_Stewart_390That was exactly it. I stole the "when CLIENT_ACCEPTED" and the final else from that other post, and it works great now.
It seemed to me to be redundant to be resetting the pool to default if the iRule wasn't firing on any conditions, but if this is a Behaving As Expected than that's different.
Thank you very much!
-Ian
