Applies To:
Show Versions
BIG-IP AAM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
BIG-IP APM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
BIG-IP GTM
- 11.6.3, 11.6.2, 11.6.1
BIG-IP Link Controller
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
BIG-IP Analytics
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
BIG-IP LTM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
BIG-IP PEM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
BIG-IP AFM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
BIG-IP DNS
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0
BIG-IP ASM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0, 12.1.6, 12.1.5, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.3, 11.6.2, 11.6.1
About iRule evaluation
In a basic system configuration where no iRule exists, Local Traffic Manager directs incoming traffic to the default pool assigned to the virtual server that receives that traffic. However, you might want Local Traffic Manager to direct certain kinds of connections to other destinations. The way to do this is to write an iRule that directs traffic to that other destination, contingent on a certain type of event occurring. Otherwise, traffic continues to go to the default pool assigned to the virtual server.
iRules are therefore evaluated whenever an event occurs that you have specified in the iRule. For example, if an iRule includes the event declaration CLIENT_ACCEPTED, then the iRule is triggered whenever Local Traffic Manager accepts a client connection. Local Traffic Manager then follows the directions in the remainder of the iRule to determine the destination of the packet.
Event types
The iRule command syntax includes several types of event declarations that you can specify within an iRule. For example:
- Global events, such as CLIENT_ACCEPTED
- HTTP events, such as HTTP_REQUEST
- SSL events, such as CLIENTSSL_HANDSHAKE
- Authentication events, such as AUTH_SUCCESS
For a complete list of iRule events and their descriptions, see the F5 Networks DevCentral web site, http://devcentral.f5.com.
iRule context
For every event that you specify within an iRule, you can also specify a context, denoted by the keywords clientside or serverside. Because each event has a default context associated with it, you need only declare a context if you want to change the context from the default.
The example shows my_iRule1, which includes the event declaration CLIENT_ACCEPTED, as well as the iRule command IP::remote_addr. In this case, the IP address that the iRule command returns is that of the client, because the default context of the event declaration CLIENT_ACCEPTED is clientside.
when CLIENT_ACCEPTED { if { [IP::addr [IP::remote_addr] equals 10.1.1.80] } { pool my_pool1 } }Similarly, if you include the event declaration SERVER_CONNECTED in an iRule as well as the iRule command IP::remote_addr, the IP address that the iRule command returns is that of the server, because the default context of the event declaration SERVER_CONNECTED is serverside.
The preceding example shows what happens when you write an iRule that uses the default context when processing iRule commands. You can, however, explicitly specify the clientside and serverside keywords to alter the behavior of iRule commands.
Continuing with the previous example, the following example shows the event declaration SERVER_CONNECTED and explicitly specifies the clientside keyword for the iRule command IP::remote_addr. In this case, the IP address that the iRule command returns is that of the client, despite the server-side default context of the event declaration.
when SERVER_CONNECTED { if { [IP::addr [IP::addr [clientside {IP::remote_addr}] equals 10.1.1.80] } { discard } }iRules assignment to a virtual server
When you assign multiple iRules as resources for a virtual server, it is important to consider the order in which you list them on the virtual server. This is because Local Traffic Manager processes duplicate iRule events in the order that the applicable iRules are listed. An iRule event can therefore terminate the triggering of events, thus preventing Local Traffic Manager from triggering subsequent events.
