Forum Discussion

hoolio's avatar
hoolio
Icon for Cirrostratus rankCirrostratus
Aug 10, 2006

Pool 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's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    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's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    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
  • 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's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    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_95363's avatar
    unRuleY_95363
    Historic F5 Account
    To 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_18's avatar
    Deb_Allen_18
    Historic F5 Account
    We 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_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Ah, 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