Taking a massive HTTP redirect iRule and using a data policy instead

Hi Jules,

If you are looking to move from an iRule to Traffic Policy then think you will need a single policy with multiple rules. From my personal experience a large policy is harder to manage and difficult to test compared to an iRule.

What I get from your question is that really you have a large iRule with is managed and edited by multiple users, so you need some form of control.

My last role as part of an iRule Development team we managed a very large number of iRules independently from the base F5 configuration. To do this we kept all iRules in git version source control (vsc) repositories (we used Gerrit but any GIT based system can work) and used Jenkins for CI to run automated testing based on the TesTCL unit testing framework.

The following code share is how to setup a basic local development environment: https://devcentral.f5.com/s/articles/iRules-Development-Environment

This might be to extreme for what you need but the general idea behind using a version-source control (like GIT) to store configuration allows for changes to use an automated workflow process which could include automated testing and peer review before being deployed to any F5 devices. You can even look at using something like Ansible or Terraform instead of using direct configuration stored and edited.

I highly recommend looking at this approach over the longer term.

Shorter term I would recommend a review and rewrite of the iRule in question to utilise Data-Groups. If done correctly then all redirects can be placed into one or more Data-Groups with a simple iRule just referencing them to find the correct location to redirect a client request to.

This would allow for edits to be made to the Data-Groups only while leaving the iRule untouched most of the time.

As an example the following iRule and Data-Group is a good starting point, you will likely need to edit it to improve on it and make it fit your needs:

ltm rule redirect{
    when HTTP_REQUEST {
        # Takes Hostname + Path and performs Data Group match
        set redirectUrl [class match "[HTTP::host][HTTP::path]" starts_with redirectLookup]
 
        # If match found in Data Group redirectUrl will not be blank
        if {redirectUrl != ""} {
            HTTP::redirect redirectUrl
        } else {
            # No match found log and redirect to some error page
            log local0.info "Redirect for '[HTTP::host][HTTP::path]' was not found in data group 'redirectLookup'"
            HTTP::redirect https://errorsite.com/redirect-error-page.html
        }
    }
}
 
ltm data-group internal redirectLookup {
    records {
        mysite.com/test {
            data https://testsite.com
        }
        mysite.com/ {
            data https://yousite.com
        }
    }
    type string
}