What is an iRule? An iRule is a script that you write if you want to make use of some of the extended capabilities of the BIG-IP that are unavailable via the CLI or GUI. iRules allow you to more directly interact with the traffic passing through the device. Using iRules, you can send traffic not only to pools, but also to individual pool members,ports, or URIs. You can parse the entire header and payload of the data as it is being passed through the BIG-IP and, at wire speed, execute an entire script of commands on that traffic. The following shows an example of a simple iRule. This iRule is triggered when a client-side connection has been accepted, causing the LTM system to send the packet to the pool my_pool, if the client’s address matches 10.10.10.10. Using a feature called the Universal Inspection Engine (UIE), you can write an iRule that searches either a header of a packet, or actual packet content, and then directs the packet based on the result of that search. iRules can also direct packets based on the result of a client authentication attempt. iRules can direct traffic not only to specific pools, but also to individual pool members, including port numbers and URI paths, either to implement persistence or to meet specific load balancing requirements. The syntax that you use to write iRules is based on the Tool Command Language (Tcl) programming standard.
How does an iRule work? iRule is first and foremost a configuration object, in F5 terms. It is entered into the system either via the GUI or CLI. There is also an iRules Editor available for download on DevCentral Every time you save your configuration all of your iRules are pre-compiled into what is referred to as “byte code”. Byte code is mostly compiled and has the vast majority of the interpreter tasks already performed, so that TMM can directly interpret the remaining object. This makes for far higher performance and as such increases scalability. Now that the iRule is saved and pre-compiled, it must then be applied to a virtual server before it can affect any traffic. An iRule that is not applied to a virtual server is effectively disabled. Once you’ve applied an iRule to a given virtual server, however, it will now technically be applied against all traffic passing through that virtual server. Keep in mind though, that this does not necessarily mean that all traffic passing through the virtual server in question will be affected. IRules are most often very selective in which traffic they affect, be it to modify, re-route or otherwise. This is done through both logical constructs within the iRules, but also through the use of events within the iRule itself.
Events are one of the ways in which iRules have been made to be network aware.
When would I use an iRule? The ideal time to use an iRule is when you’re looking to add some form of functionality to your application or app deployment, at the network layer, and that functionality is not already readily available via the built in configuration options in your BIG-IP
As an example, one of the most common uses of iRules when it was first introduced was to redirect all traffic from HTTP (port 80) to HTTPS (port 443) without affecting either the host or the requested URI for the connection. (See example below) This was and still is a very simple iRule, but it wasn’t at the time a feature available in the standard configuration options for BIG-IP.
when HTTP_REQUEST {
HTTP::redirect “https://[HTTP::host][HTTP::uri]”
}