iRules

iRules^® are made up of these basic elements:

• Event declarations
• Operators
• iRule commands

iRules^® are event-driven, which means that Local Traffic Manager™ triggers an iRule based on an event that you specify in the iRule. An event declaration is the specification of an event within an iRule that causes Local Traffic Manager to trigger that iRule whenever that event occurs. Examples of event declarations that can trigger an iRule are HTTP_REQUEST, which triggers an iRule whenever the system receives an HTTP request, and CLIENT_ACCCEPTED, which triggers an iRule when a client has established a connection.

   when HTTP_REQUEST {
  if { [HTTP::uri] contains "aol" } {
     pool aol_pool
  } else {
     pool all_pool
 }
}
  

An iRule operator compares two operands in an expression.

For example, you can use the contains operator to compare a variable operand to a constant. You do this by creating an if statement that represents the following: "If the HTTP URI contains aol, send to pool aol_pool."

An iRule command within an iRule causes Local Traffic Manager™ to take some action, such as querying for data, manipulating data, or specifying a traffic destination. The types of commands that you can include within iRules^® are:

Statement commands

These commands cause actions such as selecting a traffic destination or assigning a SNAT translation address. An example of a statement command is pool <name>, which directs traffic to the named load balancing pool.

Commands that query or manipulate data

Some commands search for header and content data, while others perform data manipulation such as inserting headers into HTTP requests. An example of a query command is IP::remote_addr, which searches for and returns the remote IP address of a connection. An example of a data manipulation command is HTTP::header remove <name>, which removes the last occurrence of the named header from a request or response.

Utility commands

These commands are functions that are useful for parsing and manipulating content. An example of a utility command is decode_uri <string>, which decodes the named string using HTTP URI encoding and returns the result.

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.

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
  } 
 }

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.

The iRules^® feature includes a command called PROFILE. When you specify the PROFILE command in an iRule and name a profile type and setting, the iRule reads the value of that particular profile setting. To do this, the iRule finds the named profile type that is assigned to the virtual server and reads the value of the setting that you specified in the PROFILE command sequence. The iRule can then use this information to manage traffic.

For example, you can specify the command PROFILE::tcp idle_timeout within your iRule. Local Traffic Manager™ then finds the TCP profile that is assigned to the virtual server (for example, my_tcp) and queries for the value that you assigned to the Idle Timeout setting.

Some of the iRule commands for querying and manipulating header and content data have equivalent settings within various profiles. When you use those commands in an iRule, and an event triggers that iRule, Local Traffic Manager™ overrides the values of those profile settings, using the value specified within the iRule instead.

For example, an HTTP profile might specify a certain buffer size to use for compressing HTTP data, but you might want to specify a different buffer size for a particular type of HTTP connection. In this case, you can include the command HTTP::compress_buffer_size in your iRule, specifying a different value than the value in the profile.

The BIG-IP^® system includes an iRule command called class, with a match option, which you can use to select a pool based on whether the command being used in the iRule represents a member of a specific data group. When you use the class command, the BIG-IP system knows that the string following the identifier is the name of a data group.

For example, using the class command, you can cause the BIG-IP system to load balance all incoming AOL connections to the pool aol_pool, if the value of the IP::remote_addr command is a member of the data group AOL. In this case, the class match command simply indicates that the object named aol is a collection of values (that is, a data group).

when CLIENT_ACCEPTED {
  if { [class match [IP::remote_addr] equals aol] } { 
     pool aol_pool
  } else {
     pool all_pool
 }
}

With Local Traffic Manager™, you can store data groups in two ways, either in-line or externally.

With these iRule commands, you can reference the new iFile from within an iRule:

• [ifile get IFILENAME]
• [ifile listall]
• [ifile attributes IFILENAME]
• [ifile size IFILENAME]
• [ifile last_updated_by IFILENAME]
• [ifile last_update_time IFILENAME]
• [ifile revision IFILENAME]
• [ifile checksum IFILENAME]
• array set [file attributes IFILENAME]

ltm rule ifile_rule {
     when HTTP_RESPONSE {
     # return a list of iFiles in all partitions
     set listifiles [ifile listall]
     log local0. "list of ifiles: $listifiles"
  
     # return the attributes of an iFile specified
     array set array_attributes [ifile attributes      "/Common/ifileURL"]     
     foreach {array attr} [array get array_attributes ] {
     log local0. "$array : $attr"
     }
  
     # serve an iFile when http status is 404.
     set file [ifile get "Common/ifileURL"]
     log local0. "file: $ifile"
     if { [HTTP::status] equals "404" } {
       HTTP:Respond 200 ifile "/Common/ifileURL"
  
    }
  }
  }