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
- hoolio
Cirrostratus
Ok, so maybe I've figured out part of what you're referring to: - 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. - 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. - 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.
- 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.
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