An iRule basically is a script that executes against network traffic passing through an F5 appliance. iRules can write simple, network-aware pieces of code that will manipulate network traffic in a variety of ways. Regardless of whether you’re looking to do some form of custom persistence, setting custom settings for the TCP/UDP protocols or rate-limiting that isn’t currently available within the product’s built-in options, or looking to completely customize the user experience by granularly controlling the flow or even the contents of a given session/packets.
iRules can route, re-route, redirect, inspect, modify, delay, discard or reject, log or … do just about anything else with network traffic passing through a BIG-IP. The idea behind iRules is to make the BIG-IP nearly infinitely flexible. At the end of the day, iRules is a network-aware, customized language with which a user can add business and application logic to their deployment at the network layer.
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.
Once 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 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. Keep in mind though, that this does not necessarily mean that all traffic passing through the virtual 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.