Applies To:

Show Versions Show Versions

Manual Chapter: iRule Evaluation
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

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.

Note: When you make a change to an iRule with persistance, if there is already a connection in the connection table, the change does not take effect until the connection has expired. The same is true when you enable logging for the iRule and then change the iRule (or alter the logging message itself).

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 } }
Note: You make an event declaration in an iRule by using the when keyword, followed by the event name. The figure shows an example of an event declaration in an iRule.

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.

Note: If an iRule references a profile, Local Traffic Manager processes this type of iRule last, regardless of its order in the list of iRules assigned to a virtual server.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)