Forum Discussion

William_Them_99's avatar
William_Them_99
Icon for Nimbostratus rankNimbostratus
Mar 01, 2006

Changing pool from the default

 

We have a virtual server with a default pool. For certain URIs on this virtual server, however, we need it to use a pool other than the default.

 

 

We have used the "pool" command after some IF logic to handle this, but we are seeing strange behavior and trying to debug from all angles. It seems that sometimes after the specific URI is sent to the non-default pool, subsequent requests still go to that non-default pool when they should go to the default, but the weird thing is that this does not happen every time.

 

 

Is it possible that the BIGIP sometimes caches the pool reassignment? Is there an iRule command to reset the virtual server back to the default pool?

 

 

Thanks.

 

 

-Bill
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    I've had several instances where the default pool definition was not consistently honored after traversing a conditional rule.

     

     

    I now usually explicity refer traffic to the default pool in an "else" statement, rather than allowing the traffic to just fall out of the rule into the default pool.

     

     

    This is supposed to work, but proven unreliable:

     

     

    default pool = y

     

    if {[HTTP::uri] contains "x" }{

     

    pool x

     

    }

     

     

    This consistently seems to work:

     

     

    if {[HTTP::uri] contains "x" }{

     

    pool x

     

    } else {

     

    pool y

     

    }

     

     

    which is unfortunate since it makes the resulting rule less flexlible.

     

     

    HTH

     

    /deb
  • Thanks for your response.

     

     

    In our situation, we can't quite do the straight IF-ELSE for the pool...somewhere down within the WHEN HTTP_REQUEST block, we have this code

     

     

    
    if {[HTTP::uri] starts_with "/logins"} { 
      log local0. "within logins check"
      switch [HTTP::host] { 
            
        "" 
        { 
          log local0. "redirecting login to logins-pool"
          pool logins-pool
        }
        
        default { log local0. "in switch default"}
      }
            
    }

     

     

     

    So, to try to use your suggestion, I just put another switch statement at the very beginning of the HTTP_REQUEST to just select the default pool for each virtual server...which I thought would sort of reset things. I still see the same behavior on an intermittent basis though....hmmmm.
  • There is also unRuleY's response here (Click here):

     

     

    http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=6493

     

     

    Is there a way to use LB::detach to get around this?
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Since this is a confusing topic, I thought I would try to give some more explanation. At one point, we actually had numerous discussions about how/when the selection might get reset back to the default pool. However, the conclusion of those discussions were that it was pretty much impossible to determine all the cases when the user would want this behavior and when they wouldn't.

    The default pool is merely the pool that is initially selected upon receiving the client connection. All subsequent pool selections must be explicitly made. So, since HTTP can make multiple requests on a single connection, the subsequent requests may end up going to whatever pool the previous request might have chosen. Since this is case, it is always best to have an explicit case for all requests.

    It's also important to understand that using OneConnect also has an impact on how this behavior works. If there is not a OneConnect profile, then each request on a connection will continue to use the same load-balanced pool member as the last request unless the pool selection has actually changed. If there is a OneConnect profile, then each request will be re-load balanced to a new pool member (within the currently selected pool). You could also use the LB::detach command to force the same behavior as happens with the OneConnect profile, however this has more to do with the load-balanced pool member than with the selected pool.

    This is done this way because there are a number of examples where it is impossible to know when connection should be reset to the default pool. HTTP is only the simple case and iRules where made to handle many cases like dealing with custom protocols where it's up to the rule to define when the connection should be detach or a new pool selected.

    I'll finish with reminding everyone that you can select a pool several times and that the last pool selection is always the one that is used. So, it is very easy to simply add a pool command at the top of the HTTP_REQUEST event to resets to the default pool. Here is a generic example of how to do this for any virtual:
    when CLIENT_ACCEPTED priority 900 {
       set default_pool [LB::server pool]
    }
    when HTTP_REQUEST priority 100 {
       pool $default_pool
    }

    This rule could be used in combination with any other rule and would have the behavior of resetting each subsequent request to whatever the default pool is for the virtual server.

    Good luck.