Forum Discussion
NimbostratusTaking a massive HTTP redirect iRule and using a data policy instead
I am trying to take an iRule that has at least 500 or more redirects that sits on a VIP that is labeled as a 'redirect' VIP. We change the DNS record to point to the VIP and the iRule performs the redirect. The issue is that managing an iRule that large is tedious and dangerous because there are multiple users who modify the iRule weekly.
The alternative is to use a data policy or policies for redirects because it will be seemingly easier to manage. The problem I have run into is that I cannot create let's say 2 policies for redirects and assign them to the same VIP. I get an error: 010716fd:3 Virtual Server '%vip_name%' cannot contain policies with conflicting controls.
So the next step was to try and have one massive policy and use individual rules within the policy for the redirects, but the issue there is I am not clear on how to have multiple layers, like the host has one redirect, but a specific url path(s) with the same host has a separate redirect. Example: mysite.com redirects to yousite.com ; mysite.com/test redirects to testsite.com. The problem is adding all of the different redirect parameters in a single rule.
The only configuration I can get to work is creating a separate rule for each redirect element within the policy. Example: mysite.com redirects to yousite.com = rule 1 ; mysite.com/test redirects to testsite.com = rule 2. This would be difficult to manage because now I am splitting up one redirect into multiple rules if it isn't a simple host to new url redirect.
Just want to know if I can accomplish what I am trying to accomplish using a data policy, or if there is something else to look into.
Andy_McGrathCumulonimbus
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 }
Jules_M__GreenThank you very much for your response. We have also looked at using data groups as well. I believe this may work. I need to come up with a simple way, via form or API to simply creating the redirects and modifying the data group if this is the path we take. Again, thank you. Will look into this.