pool

Description

Causes the system to load balance traffic to the specified pool or pool member . In case only pool member is specified ,the system will load balance traffic to the specified pool member regardless of pool member monitor status. Pool member status may be determined by the use of the LB::status command. Server failure to respond may be caught in the LB_FAILED event. Failure to select a server because none are available may be caught in the LB_FAILED event or prevented by using the active_members command to test the number of active servers in the pool before sending traffic.)
Pool / member may be selected conditionally. If multiple conditions match, the last match will determine the pool/member to which this traffic is load balanced.

Syntax

pool <pool_name> [member <addr> [<port>]]
pool <pool_name> [member <addr>:<port>]

#v12 change for GTM pool - add CNAME
pool [CNAME] <poolName> [member <memberName>]

pool <pool_name> [member <addr> [<port>]]

  • Selects the specified member from the specified pool

pool <pool_name> [member <addr>:<port>]

  • Selects the specified member from the specified pool

Examples

To select a pool conditionally:
when CLIENT_ACCEPTED {
  if { [IP::addr [IP::client_addr] equals 10.10.10.10] } {
     pool my_pool
 }
}

To check pool member status before sending traffic:
when HTTP_REQUEST {
   if { [HTTP::uri] ends_with ".gif" } {
      if { [LB::status pool my_Pool member 10.1.2.200 80] eq "down" } {
         log "Server $ip $port down!"
         pool fallback_Pool
      } else {
         pool my_Pool member 10.1.2.200 80
      }
   }
}

To catch failure of selected pool member to respond:
when HTTP_REQUEST {
  if { [HTTP::uri] ends_with ".gif" } {
    pool my_Pool member 10.1.2.200 80
  }
}
when LB_FAILED {
  pool my_Pool
  LB::reselect
  log "Selected server [LB::server] did not respond. Re-selecting node from myPool"
}

In order to make this functionality work, one must precede the pool command with an LB::reselect command if a pool member has already been selected.

Comments

mm AT e-sport.com writes:

(re: LTM only) It seems as if the pool choice is persistent over multiple http requests (Keep-Alives). So if the rule selects pool x on the first request of the current connection, pool x is still selected for the second request. Additionally it seems to be sometimes not possible to change the pool at the second request. More information about that would be very appreciated ;) (mm AT e-sport.com)

doug-brenner AT uiowa DOT edu writes on 7/12/2006:

(re: LTM only) I also experienced the above issue (persistent pool selection over multiple http requests. By searching DevCentral, I was finally able to locate a solution that seems to work:
Here is the suggested code based on that posting:
when CLIENT_ACCEPTED {
   set default_pool [LB::server pool]
}
when HTTP_REQUEST {
   if { [HTTP::uri] starts_with "/sc/" } {
      pool pool_sc
   } else {
      pool $default_pool
   }
}

deb AT f5 DOT com writes on 10/25/2006:

(re: LTM only) Alternatively, you may enable a OneConnect profile to allow re-selection of the pool on subsequent requests over keepalive connections. This post contains a discussion of that and links to several related posts: http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=10032

rlandrito AT gmail DOT com writes on 8/24/2006:

(re: LTM only) At least as of 9.1.0, “port” is not an optional parameter if “member” is specified. If unspecified, the command seems to do nothing. For this version (and possibly others), the syntax should read:
pool <pool_name>
pool <pool_name> [member <addr> <port>]

j.calhoun AT f5 DOT com writes on 1/27/2009:

(re: GTM) Running 9.4.6 GTM, the “port” parameter is not optional if “member” is specified. As rlandrito saw with LTM back in 9.1.0, the command does nothing with member alone.

edh writes on 06/18/2010:

In 9.3.1 and 10.1, if you specify a pool with a member but no port, you actually get stuck to the selection of the last pool member in the list regardless of the pool member’s status. This means that you cannot select a pool member with any affinity to a particular IP address. What would be better would be that the member IP would act as a filter against the selection list. There are a number of use cases where that would be very useful!

The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.