BIG-IP Next: iRules pool routing

Update - We've heard your feedback! The product team is working hard to shift from a migration strategy to an upgrade process as an interim step to delivering the complete vision for BIG-IP Next. Details can be found on MyF5 in this solution. If you want to kick the tires on the current release of BIG-IP Next, read on!

If you use routing in iRules with the pool command in BIG-IP and you’re starting to kick the tires on BIG-IP Next in your lab environments, please note the pool reference is not just the pool name. For example, in classic BIG-IP, if I had a pool named myPool then the command in my iRule would just be pool myPool. In BIG-IP Next (as of this publish date, they are working on restoring the relative path) you will need these additional details:

• Tenant Name
• Application Name
• Pool Service Name

The format for the pool reference is then:

pool /app/myTenantName:ApplicationName/pool/PoolServiceName

Consider this partial AS3 declaration (stripped down to the necessary lines for brevity):

{
  "class": "ADC",
  "tenant2zBLVQCbR2unEw5ge6nVrQ": {
    "class": "Tenant",
    "testapp1": {
      "class": "Application",
      "pool_reference_test_7_testvip1": {
        "class": "iRule",
        "iRule": {
          "base64": ""
        }
      },
      "testpool1": {
        "class": "Pool"
      },
      "testpool2": {
        "class": "Pool"
      },
      "testpool2_service": {
        "class": "Service_Pool",
        "pool": "testpool2"
      },
      "testpool3": {
        "class": "Pool"        
      },
      "testpool3_service": {
        "class": "Service_Pool",
        "pool": "testpool3"
      },
      "testvip1": {
        "class": "Service_HTTP",
        "iRules": [
          "pool_reference_test_7_testvip1"
        ],
        "pool": "testpool1",
        "virtualAddresses": [
          "10.0.2.51"
        ],
        "virtualPort": 80
      }
    }
  }
}

In this case, there is a default pool (testpool1) attached to the virtual server, but the ones that will require routing in the iRule, testpool2 and testpool3, are not attached. They are mapped in the Service_Pool classes though, and that's what we need for the iRule. From this declaration, we need:

• Tenant Name: tenant2zBLVQCbR2unEw5ge6nVrQ
• Application Name: testapp1
• Service Pool Names: testpool2_service, testpool3_service

The original iRule then, as shown here:

when HTTP_REQUEST {
    if { [string tolower [HTTP::uri]] == "/tp2" } {
        pool testpool2 
        HTTP::uri /
    } elseif { [string tolower [HTTP::uri]] == "/tp3" } {
        pool testpool3
        HTTP::uri /
    }
}

Becomes:

when HTTP_REQUEST {
    if { [string tolower [HTTP::uri]] == "/tp2" } {
        pool /app/tenant2zBLVQCbR2unEw5ge6nVrQ:testapp1/pool/testpool2_service 
        HTTP::uri /
    } elseif { [string tolower [HTTP::uri]] == "/tp3" } {
        pool /app/tenant2zBLVQCbR2unEw5ge6nVrQ:testapp1/pool/testpool3_service
        HTTP::uri /
    }
}

When creating an application service in the Central Manager GUI, here’s the workflow I used:

1. Create the application service without the iRule, but with whatever pools you’re going to route to so that the pools and pool services are defined.
2. Validate the app and view results. This is where you’ll find your tenant and service pool names. The app’s name should be obvious as you set it!
3.  Go ahead and deploy; there isn’t a way here to save drafts currently.
4. Create or edit the iRule with the pool format above with your details.
5. Edit the deployment to reference your iRule (and the correct version), then redeploy.

This should get you where you need to be! Comment below or start a thread in the forums if you get stuck.