F5 I-Rules to flightPATH

It’s a widely held belief among my colleagues at edgeNEXUS that whilst F5 LTM load balancers are extremely powerful and flexible the reliance on the use of iRules scripting to perform some time even the most basic of functions leads to unnecessary complexity.

You only have to do an online search for F5 iRules examples to discover the pain and angst that many IT professionals have to go through in the process of creating functional iRules.

Whilst it’s true the expansion of ‘Local Traffic Policies’ functionality in more recent F5 software releases has removed some of the need to create iRules for common HTTP header manipulation functions, there are many uses still stuck with legacy iRules in their system configuration.

Local Traffic Policies don’t appear to allow for manipulation HTML data although Stream policies do, they are rather clunky and difficult to control and by default affect traffic in either direction in the same way although this is not usually desirable.

This means reverting back to iRules to perform functions such as a http:// to https:// URL body text link replacement that may be required in conjunction with a http:// to https redirection which can be performed using Local Traffic Policies.

At edgeNEXUS we a justifiably proud of the power and yet simplicity of configuration of our flightPATH Layer 7 HTTP manipulation function.
If you are an existing F5 user making use of iRules for HTTP or HTML manipulation we would be delighted to have the opportunity to give you a demonstration of edgeNEXUS ALB-X load balancer and show how straightforward flightPATH is to configure to achieve some relatively complex functions. We would like to be put to the test to help translate your existing iRules functions to flightPATH rules.
As an example we have reproduced below a selection of F5 iRules with the equivalent edgeNEXUS flightPATH rule configuration screen shots.

Source IP content server steering

Here is an example of how iRules can be used to direct users from a certain IP address range to one Server Pool and those from another range to another Server Pool.

F5:

Name:	IP_Choice
Definition:	when HTTP_REQUEST { if { ( [IP::addr [IP::client_addr] equals 24.24.15.100] ) or ( [IP::addr [IP::client_addr] equals 10.1.1.2] ) } { pool pool2 } }

click here to enlarge

jetNEXUS:

Create a new flightPATH rule with name IP_Choice_Pool_1 via the Web GUI. Add a concise description to be able to identify what the function the flightPATH rule is performing.
Add a new Condition, selecting Source IP from the extensive drop down list. Select Does from the Sense drop down. One option is to select Start from the dropdown Check list (as an alternative you can use other options such as RegEx to provide more flexibility for the IP address ‘Value’). Enter the start IP range in the Value box.
Add a New Action. From the Action drop down box choose the Use Server option (there is also a Use Secure Server option if required). In the Target box enter the IP address and port of the required destination, this is usually another Virtual Service interface to allow for load balancing across another pool of real servers.

Migration made easy

It’s a widely held belief among my colleagues at edgeNEXUS that whilst F5 LTM load balancers are extremely powerful and flexible the reliance on the use of iRules scripting to perform some time even the most basic of functions leads to unnecessary complexity.

Source IP content server steering

F5:

jetNEXUS:

We would love to hear from you

Don’t take our word for it – take a free trial

Contact us

Try it now

Support

We would Love to Hear from You