Migrating F5 iRules to LoadMaster Hero Image

Migrating F5 iRules to LoadMaster

F5 Compare WUI Demo

Application Delivery Controllers are used extensively for intelligent traffic routing. Users benefit from optimized content delivery, for example by sending requests for multimedia content to specially configured servers. While F5 provides flexibility, it requires development and maintenance of scripts to inspect and manipulate HTTP traffic. Kemp’s LoadMaster Application Delivery Controllers (ADCs), on the other hand, have a simple to use, intuitive user interface which can be used to achieve the same results. When it comes to migrating scripted functionality from other Application Delivery Controllers (ADCs), including Cisco, Brocade and F5, Kemp has the expertise, a Beta version Migration Tool and offers free 30 Day Evaluation for a LoadMaster solution.

F5’s BIG-IP® local traffic management system uses iRulesTM scripting to manage network traffic. The syntax is based on the industry-standard Tools Command Language (Tcl), and allows traffic to be redirected by searching on any type of content. Thus, iRules allows customization of content switching to suit specific needs.

Typically an iRule will search either a header of a packet, or actual packet content, and then redirect the packet based on the result of that search. Scripts are written using the following iRule elements:

iRule Structure

  • Event declarations
  • Operators
  • iRule commands

These define how the rule is triggered and processed.

Kemps LoadMaster implements content switching, and can take action based on:

LoadMaster Method

  • Request URL
  • HTTP Header
  • Source IP address
  • Body of a request

Regular Expressions are used to process the content and requests can then be redirected to specific Real Servers based on the result. Unlike the scripting required for F5, content rules can be defined in the LoadMaster WUI or programmatically through available APIs.

Mapping iRules to the LoadMaster WUI

iRulesLoadMaster
When to apply a rule (trigger event)Defined in the Virtual Service
What to Compare (Operator)Host Header and/or URL
What to do (Command)Rewrite/redirect
Click Here for more details on iRule mapping

F5 iRule Breakdown

Typically the F5 iRule is broken into three parts:

  • When to apply the rule
  • What to compare
  • What to do

Refer to the sections below for further information on these parts.

When to apply the rule

These will typically determine where in the Virtual Service the Content Rule will be applied, i.e. Request or Response.

To get to the HTTP header modification Rule Management screen, go to Virtual Services > View/Modify Services > Modify > Advanced Properties > Show Header Rules.

Here you can add request and response rules.

Request Rules

when HTTP_REQUEST {
}

Virtual Services > View/Modify Services > Modify > Advanced Properties > Show Header Rules > Request Rules

Response Rules

when HTTP_RESPONSE {
}

Virtual Services > View/Modify Services > Modify > Advanced Properties > Show Header Rules > Response Rules

Redirect Rules

Redirect rules are different - redirect rules should be applied under:

Virtual Services > View/Modify Services > Modify > Advanced Properties > Show Selection Rules

The rule in this case will not change any headers but instead, cause the request to always fail. Using a second option under Not Available Redirection Handling, we can then add a redirect to take place when this forced fail happens.

What to compare

Typically this will include looking at host headers and/or URL and will be contained in the content rule we create.

What to do

In most cases this will result in a rewrite of the host header/URL or in the case of a redirect, the rule will simply do a compare and if the result is matched - do a “Fail on Match”. This can then be used to trigger a predefined 302 redirection handling in the Virtual Service.

URL/Host rewriting

URL

if {{HTTP::uri] equals "/exacttextmatch"}{
HTTP::uri "/newtext"
}

Virtual Services > View/Modify Services > Modify > Advanced Properties > Show Header Rules > Response Rules

Content Rule on the LoadMaster

Rule Name:
RewriteURL
Rule Type:
Modify URL
Match String:
exacttextmatch
Modified URL:
newtext
302 Redirecting

Is this case the procedure is different as we need to match on the specific host header or URL and then cause a 302 redirect inside the Virtual Service.

Host

if { [HTTP::host] equals "domain.com" } {

HTTP::redirect "http://www.newdomain.com/index.htm"

}

Content Rule on the LoadMaster

Rule Name
redirectdomain
Rule Type
Content Matching
Match Type
RegExpression
Header Field
host
Match String
domain.com
Fail on Match
<enable>

Apply the rule under:

Virtual Services > View/Modify Services > Modify > Advanced Properties > Show Selection Rules

In Advanced Properties of the Virtual Service - add a redirect in the Not Available Redirection Handling section.

Error Code:
302 Found
Redirect URL:
http://redirectdomain.com%s

Test:
Redirect domain.com to redirectdomain.com
C:\GNUwin32\bin>wget-1.12 domain.com/welcome.png
--2015-08-24 11:35:58--  http://domain.com/welcome.png
Resolving domain.com... 10.111.0.173
Connecting to domain.com|10.111.0.173|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://redirectdomain.com/welcome.png [following]
--2015-08-24 11:35:58--  http://redirectdomain.com/welcome.png
Resolving redirectdomain.com... 69.172.201.208
Connecting to redirectdomain.com|69.172.201.208|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `welcome.png.1'
 [ <=>                                   ] 1,556       --.-K/s   in 0s
URL based Redirect

For redirects based on the URL the procedure is the same except the rule will match on the URL (the Header field in the content rule can be left blank) rather than on hostname.

if { [HTTP::uri] starts_with "/sometext" } {

HTTP::uri "/newtext"

}

Content Rule on the LoadMaster

Rule Name
redirectdomain
Rule Type
Content Matching
Match Type
RegExpression
Header Field
<blank>
Match String
sometext
Fail on Match
<enable>

Apply the rule under:

Virtual Services > View/Modify Services > Modify > Advanced Properties > Show Selection Rules

In Advanced Properties of the Virtual Service - add a redirect in the Not Available Redirection Handling section.

Error Code: 302 Found

Redirect URL:http://%h/newtext

Test: Redirect URL containing /sometext to http://<domain>/welcome.png where <domain> is the domain in initial request.

C:\GNUwin32\bin>wget-1.12 domain.com/wrong.

--2015-08-24 11:32:30--  http://domain.com/wrong.png

Resolving domain.com... 10.111.0.173

Connecting to domain.com|10.111.0.173|:80... connected.

HTTP request sent, awaiting response... 302 Found

Location: http://domain.com/welcome.png [following]

--2015-08-24 11:32:30--  http://domain.com/welcome.png

Connecting to domain.com|10.111.0.173|:80... connected.

HTTP request sent, awaiting response... No data received.

Retrying.

--2015-08-24 11:32:31--  (try: 2)  http://domain.com/welcome.png

Connecting to domain.com|10.111.0.173|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 184946 (181K) [image/png]

Saving to: `welcome.
'
100%[======================================>] 184,946     --.-K/s   in 0.03s
For further migration advice please Submit a request

Start Powering Your Always-on Application Experience Today

30-Day Free Trial Contact Sales