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.
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
| iRules | LoadMaster |
|---|---|
| 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
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
