Forum Discussion
hoolio
Cirrostratus
Aug 10, 2006Pool selection in an iRule and VIP?
This is directed to Deb, but if anyone has more info, please feel free to comment.
I’ve seen you post a couple of times about iRules and the default pool for a VIP:Click here
In iRules where the pool is dynamically selected, the "default" pool for traffic that falls through the rest of the conditions will be the last pool selected by the rule, rather than the default pool that is defined on the virtual server.
So if you are conditionally choosing different pools, you probably DO want to include the "else" clause specifying the intended "default" pool.
/deb
I tried testing this to see exactly how this works, but so far, I haven’t been able to figure it out. I used a simple VIP, rule and set of one node pools to test:
when HTTP_REQUEST {
switch [HTTP::uri] {
"/pool1" {
log local0. "pool1"
pool http_pool_1
}
"/pool2" {
log local0. "pool2"
pool http_pool_2
}
"/pool3" {
log local0. "pool3"
pool http_pool_3
}
default {
log local0. "default: no action"
}
}
}And then I used a VIP with a different pool. Each time I made requests for /pool1, the request went to pool1’s node. I went back and forth through the pools in the rule and to the VIPs pool (using a URI that didn't match the switch cases), without any unexpected results.
Can you explain what you mean in your post?
Thanks,
Aaron
7 Replies
- hoolio
Cirrostratus
Ok, so maybe I've figured out part of what you're referring to:
If I remove the pool from the VIP configuration and make a request to the VIP that doesn't cause the rule to set a pool (like /nomatch), the request fails as expected. If I make a request for /pool1, the request is sent to pool1 as expected. If I make a request for /nomatch again, the request goes to the last pool selected by the rule, pool1 (!?).
I'm testing on 9.2.3, if it matters. This behavior is a bit strange. Is it expected?
Is there also a case where the VIP's pool configuration is ignored and requests are actually sent to the last pool selected by the VIP? If so, is that also by design?
Thanks,
Aaron - hoolio
Cirrostratus
I've seen a few people refer to this issue and had always been a bit concerned that I wasn't always specifying a default action.
It still seems like the behavior I saw is questionable. For a request that doesn't match any condition of the rule, I would expect it to be handled as if the rule wasn't attached to the VIP.
Is my logic off? If not, I'll escalate the issue.
Thanks,
Aaron - JRahm
Admin
Not necessarily, you could always build a class with some virtual server identifier mapped to the appropriate pool so that when requests come in, they can easily be served the appropriate content. - hoolio
Cirrostratus
I still say that regardless of how it's working now, if a condition in the rule isn't matched for a request, the past connections shouldn't affect the current one, and the request should be handled according to the VIP's configuration.
Is there a logical explanation for why the current behavior *should be* (as opposed to is) dependent on what happened on a previous connection?
Thanks,
Aaron - unRuleY_95363Historic F5 AccountTo more directly answer your question:Is there a logical explanation for why the current behavior *should be* (as opposed to is) dependent on what happened on a previous connection?Because it might be extremely difficult to determine what it should be reset to (EX: CLIENT_ACCEPTED event sets the default pool to something based on the network of the user). And also because it doesn't scale very well to protocols other than HTTP.
- Deb_Allen_18Historic F5 AccountWe do realize you're busy, so thanks for jumping in, unRuleY.
We can of course override the "default" pool whether defined in the rule or on the virtual with conditional code, such as choosing the pool for a specific connection based on connection details, as you mention.
I think the point we're trying to make is that it seems counterintuitive to ignore the VS-defined default pool in the absence of an explicit condition, instead defaulting to the last selected pool -- What is the relevance of the last selected pool if conditions have changed?
And could you please clarify your comment about scalability for non-HTTP protocols?
thanks!
/deb - Deb_Allen_18Historic F5 AccountAh, thanks for the clarification. So any invocation of the "pool" command is intended to re-define the default pool for that connection. Definitely makes sense given that context.
/deb
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
DevCentral Quicklinks
* 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
Discover DevCentral Connects