Specifying traffic destinations and address translations

The iRule commands described in Specifying statement commands instruct the BIG-IP to take direct action in some way. The following sections describe the subset of statement commands that either direct traffic to a specific destination or assign translation addresses for SNAT implementation.

For a complete list of statement commands, see Specifying statement commands.

Selecting a load balancing pool

Once you have specified a query within your iRule, you can use the pool command to select a load balancing pool to which you want the BIG-IP to send the packet. Figure 1 shows an example of this command.

Figure 1: Example of the pool command within an iRule

iRule my_iRule1 { 
    when HTTP_REQUEST 
    if { [IP::remote_addr] ends_with ".gif" } { 
        pool my_pool 
    } elseif { [HTTP::uri] ends_with ".jpg" } { 
        pool your_pool 
    } 
}

Selecting a specific server

As an alternative to the pool command, you can also write an iRule that directs traffic to a specific server within a pool. To do this, you use the node command. Figure 2 shows an example of this command.

Figure 2: Example of the node command within an iRule

iRule my_iRule1 { 
    when HTTP_REQUEST 
    if { [IP::remote_addr] ends_with ".gif" } { 
        node my_pool 
    } 
}

Selecting a cache pool

An iRule can contain a cache command that selects a pool based on HTTP header data. A cache command returns either the origin pool, the hot pool, or the cache pool. When the cache pool is selected, it is accompanied by the indicated node address and port. When an iRule returns both a pool and a pool member, the BIG-IP does not do any additional load balancing or persistence processing.

Figure 3 shows an example of an iRule containing a cache command.

iRule my_iRule 
    when HTTP_REQUEST{ 
    if { [HTTP::host] starts_with "abc" } { 
        cache { [HTTP::uri] ends_with "html" or [HTTP::uri] ends_with "gif" } { 
        origin_pool origin_server 
        cache_pool cache_servers 
        hot_pool cache_servers 
        hot_threshold 100 
        cool_threshold 10 
        hit_period 60 
        content_hash_size 1024 
    } else { 
        pool host named_servers 
    } 
}

Table 4 describes the cache command attributes and their syntax.

Attribute Description Required?
origin_pool Specifies a pool of servers with all the content to which requests are load balanced when the requested content is not cacheable, when all the cache servers are unavailable, or when you use the BIG-IP to redirect a missed request from a cache. Yes
cache_pool Specifies a pool of cache servers to which requests are directed to optimize cache performance. Yes
hot_pool Specifies a pool of servers that contain content to which requests are load balanced when the requested content is frequently requested (hot). If you specify any of the following attributes in this table, the hot_pool attribute is required. No
persist Specifies an expression that will be evaluated and used to persist to the same node within the cache pool. No
hot_threshold Specifies the minimum number of requests for content that cause the content to change from cool to hot at the end of the period (hit_period). No
cool_threshold Specifies the maximum number of requests for specified content that cause the content to change from hot to cool at the end of the period. No
hit_period Specifies the period in seconds over which to count requests for particular content before deciding whether to change the hot or cool state of the content. No
content_hash_size Specifies the number subsets into which the content is divided when calculating whether content is hot or cool. The requests for all content in the same subset are summed, and a single hot or cool state is assigned to each subset. This attribute should be within the same order of magnitude as the actual number of requests possible. For example, if the entire site is composed of 500,000 pieces of content, a content_hash_size of 100,000 would be typical. No

Redirecting HTTP requests

In addition to configuring an iRule to select a specific pool, you can also configure an iRule to redirect an HTTP request to a specific location, using the HTTP::redirect iRule command. The location can be either a host name or a URI.

For example, the string https://www.siterequest.com specifies that the HTTP request is to be redirected to a different protocol (https instead of the standard http).

Figure 5 shows an iRule that is configured to redirect an HTTP request.

iRule my_iRule 
    when HTTP_REQUEST {
    if { [HTTP::status] ends_with "404"} {
        [HTTP::redirect "http://www.siterequest.com"]
    } else {
        pool web_pool
    }
}

Assigning translation addresses for SNAT connections

The iRules feature includes the two statement commands snat and snatpool. Using the snat command, you can assign a specified translation address to an original IP address from within the iRule, instead of using the SNAT screens within the Configuration utility.

Using the snatpool command also assigns a translation address to an original IP address, although unlike the snat command, the snatpool command causes the BIG-IP to select the translation address from a specified SNAT pool that you previously created.