The Problem

You manage a number of web sites, and they are spread across servers in several different pools. You want to use a single public IP for all of these, so you need to make a pool selection based on the incoming Host header value. Moreover, one pool requires SNAT but the others do not. Finally, you need persistence for all landing sites but one.

The Configuration

ltm virtual vs-websites {
    ip-protocol tcp
    persist { cookie { } }
    pool default-web-pool
    profiles { http { } tcp { } }
    rules { by-host-pool-selector }

The Code

    switch [string tolower [HTTP::host]] {
        "" -
        "" {
            pool great-app-pool

        "" {
            pool great-app-dev-pool
            snat automap

        "" -
        "" - {
            pool fun-app-pool
            persist none


Notice that the Virtual Server to which this rule is applied does not have SNAT enabled, but does have Cookie Persistence enabled. The switch command's first argument normalizes the Host header value, changing it to all lower-case. See the "Analysis" section in iRule Recipe 1 to understand why this is necessary when performing comparisons on the Host header. If the (lower-case normalized) Host header has the value "" or "", then the pool selected will be "great-app-pool" (rather than the pool configured on the attached Virtual Server, which in this example is called "great-app-pool"). Notice that, if this branch is followed, then Cookie Persistence applies (because it is defined on the Virtual Server and this condition doesn't disable it) and SNAT is not used (because no SNAT is configured on the Virtual Server and it is not enabled in this code branch). To understand why the first matching case has a dash (-), and why that means this match uses the code for the following case, refer to the "Analysis" section of iRule Recipe 2. If the Host header has the value "", then the pool is "great-app-dev-pool" and Automap SNAT is enabled. Notice that, once again Cookie persistence applies in this case because it is defined on the Virtual Server, and is not disabled in the code. If the Host header is "" or "", then the pool used will be "fun-app-pool". In this case, the Cookie persistence is disabled (because of persist none), which means that no persistence will apply. Moreover, SNAT is not used because it is not configured on the Virtual Server and is not activated in the code. If the Host header matches none of these conditions, then the pool will be "default-web-pool", there will be no SNAT, and Cookie persistence will apply. That's because these are all configured on the Virtual Server, and no code overrides these settings.


In Recipe 2, I used the -glob flag with the switch command. Notice that I do not do so here. The -glob flag makes the switch slower (that is, it takes more processing cycles). So, if you are performing only exact string matching (and specifically, are not using glob-style matchers), then omit the -glob flag. Notice that the persist command can be used to enable or change persistence. This is beyond the scope of this article, but it's worth noting. Moreover, the snat command can be used to disable Automap SNAT, or it can be used to specify a specific SNAT address (and, optionally, port). If, however, you want to use a SNAT pool, use the snatpool command. However, if a SNAT pool is assigned to the Virtual Server, and you want to disable it for a particular condition, then you would still use snat none to disable use of the SNAT pool.