Applies To:

Show Versions Show Versions

Manual Chapter: Writing iRules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

18 
You can use iRules to manage your network traffic within the BIG-IP® Link Controller system. Using syntax based on the industry-standard Tools Command Language (Tcl), the iRules feature not only allows you to select pools based on header data, but also allows you to direct traffic by searching on any type of content data that you define. Thus, the iRules feature significantly enhances your ability to customize your content switching to suit your exact needs.
The remainder of this introduction presents an overview of iRules, lists the basic elements that make up an iRule, and shows some examples of how to use iRules to direct traffic to a specific destination such as a pool or a particular node.
Important: For complete and detailed information on iRules syntax, see F5 Networks DevCentral web site, http://devcentral.f5.com. For information on standard Tcl syntax, see http://tmml.sourceforge.net/doc/tcl/index.html.
An iRule is a script that you write if you want individual connections to target a pool other than the default pool defined for a virtual server. iRules allow you to more directly specify the destinations to which you want traffic to be directed. Using iRules, you can send traffic not only to pools, but also to individual pool members, ports, or URIs.
The iRules you create can be simple or sophisticated, depending on your content-switching needs. Figure 18.1 shows an example of a simple iRule.
Figure 18.1 Example of an iRule
This iRule is triggered when a client-side connection has been accepted, causing the BIG-IP system to send the packet to the pool my_pool, if the clients address matches 10.10.10.10.
The syntax that you use to write iRules is based on the Tool Command Language (Tcl) programming standard. Thus, you can use many of the standard Tcl commands, plus a robust set of extensions that the BIG-IP system provides to help you further increase load balancing efficiency.
iRules are event-driven, which means that the BIG-IP system 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 the BIG-IP system to trigger that iRule whenever that event occurs. An example of an event declaration that can trigger an iRule is CLIENT_ACCEPTED, which triggers an iRule when a client has established a connection as shown in Figure 18.2.
An iRule operator compares two operands in an expression. In addition to using the Tcl standard operators, you can use the operators listed in Table 18.1.
Table 18.1 iRule operators
Relational operators
contains
matches
equals
starts_with
ends_with
matches_regex
Logical operators
An iRule command within an iRule causes the BIG-IP system to take some action.
Statement 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. For more information, see Using iRule commands.
Utility commands are functions that are useful for parsing and manipulating content, such as the command in the following example.
Figure 18.3 Example of the pool command within an iRule
As described in the previous section, iRule commands instruct the BIG-IP system to take direct action in some way. The following sections show examples of iRule commands that either direct traffic to a specific destination or assign translation addresses for SNAT implementation.
Once you have specified a query within your iRule, you can use the pool command to select a load balancing pool to which you want the BIG-IP system to send a request. Figure 18.4 shows an example of this command.
Figure 18.4 Example of the pool command within an iRule
As an alternative to the pool command, you can also write an iRule that directs traffic to a specific server. To do this, you use the node command. Figure 18.5 shows an example of this command.
Figure 18.5 Example of the node command within an iRule
The iRules feature includes the two statement commands snat and snatpool. Using the snat command, you can assign a specified translation address to an original IP address from within the iRule, instead of using the SNAT screens within the Configuration utility, as shown in Figure 18.6.
Using the snatpool command also assigns a translation address to an original IP address, although unlike the snat command, the snatpool command causes the BIG-IP system to select the translation address from a specified SNAT pool that you previously created, as shown in Figure 18.7.
Figure 18.6 Example of using the snat command to assign a SNAT translation IP address
Figure 18.7 Example of using the snatpool command to assign a SNAT translation address
1.
On the Main tab, expand Local Traffic, and click iRules.
The iRules screen opens.
3.
In the Name box, type a 1- to 31-character name.
4.
In the Definition box, type the syntax for your iRule.
5.
Click Finished.
Important: Once you have created an iRule, you need to configure a virtual server to reference the iRule. For information on configuring a virtual server to reference an iRule, see Chapter 6, Configuring Virtual Servers.
In a basic system configuration where no iRule exists, the BIG-IP system directs incoming traffic to the default pool assigned to the virtual server that receives that traffic. However, you might want the BIG-IP system 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 the BIG-IP system accepts a client connection. The BIG-IP system then follows the directions in the remainder of the iRule to determine the destination of the packet.
Assign the iRule to a virtual server.
When an iRule is assigned to virtual server, this means that the virtual server references the iRule, similar to the way that a virtual server references a pool or a profile.
The iRules feature includes several types of event declarations that you can make in an iRule. Specifying an event declaration determines when the BIG-IP system evaluates the iRule. The following sections list and describe these event types. Also described is the concept of iRule context and the use of the when keyword.
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.
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.
For example, Figure 18.8 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.
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.
Figure 18.8 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, Figure 18.9 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 serverside default context of the event declaration..
You make an event declaration in an iRule by using the when keyword, followed by the event name. The previous figure shows an example of an event declaration in an iRule.
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 the BIG-IP system 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 the BIG-IP system from triggering subsequent events.
Note: If an iRule references a profile, the BIG-IP system processes this type of iRule last, regardless of its order in the list of iRules assigned to a virtual server.
Some of the commands available for use within iRules are known as statement commands. Statement commands enable the BIG-IP system to perform a variety of different actions. For example, some of these commands specify the pools or servers to which you want the BIG-IP system to direct traffic. Other commands specify translation addresses for implementing SNAT connections. Still others specify objects such as data groups or a persistence profiles.
Using iRules commands, you can query for specific data contained in the header or content of a request or response, or you can manipulate that data. Data manipulation refers to inserting, replacing, and removing data, as well as setting certain values found in headers and cookies.
For example, using the IP::idle_timeout command within in iRule, you can query for the current idle timeout value that is set in a packet header and then load balance the packet accordingly. You can also use the IP::idle_timeout command to set the idle timeout to a specific value of your choice.
iRule query and manipulation commands are grouped into categories called namespaces. Except for commands in the global namespace, each iRule query or manipulation command includes the namespace in its command name. For example, one of the commands in the IP namespace is IP::idle_timeout.
The BIG-IP system includes a number of utility commands that you can use within iRules. You can use these commands to parse and retrieve content, encode data into ASCII format, verify data integrity, and retrieve information about active pools and pool members.
When you are writing an iRule, you might want that iRule to know the value of a particular profile setting so that it can make a more-informed traffic management decision. Fortunately, the iRules feature includes a command that is specifically designed to read the value of profile settings that you specify within the iRule.
Not only can iRules read the values of profile settings, but they can also override values for certain settings. This means that you can apply configuration values to individual connections that differ from the values the BIG-IP system applies to most connections passing through a virtual server.
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. The BIG-IP system 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, as shown in Figure 18.10, and an event triggers that iRule, the BIG-IP system overrides the values of those profile settings, using the value specified within the iRule instead.
Chapter 15, Enabling Session Persistence, describes how to enable session persistence by configuring a persistence profile and assigning it to a virtual server. As described in that chapter, the BIG-IP system applies those persistence profile settings to every applicable session that passes through the virtual server.
The BIG-IP system includes a special iRule command, persist, for implementing the types of session persistence described in Chapter 15, Enabling Session Persistence. You simply type the persist command in your iRule, specifying a persistence type.
You can use the persist none, srcaddr, and destaddr commands in any circumstance, even if a corresponding persistence profile is not configured and assigned to the virtual server. For information on assigning a persistence profile to a virtual server, see Chapter 6, Configuring Virtual Servers.
Data groups are useful when writing iRules. A data group is simply a group of related elements, such as a set of IP addresses for AOL clients. When you specify a data group along with the matchclass command or the contains operator, you eliminate the need to list multiple values as arguments in an iRule expression
The BIG-IP system includes an iRule command called matchclass, 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 matchclass command, the BIG-IP system knows that the string following the identifier is the name of a data group.
For example, using the matchclass 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. Figure 18.11 shows this type of iRule. In this case, the matchclass command simply indicates that the object named aol is a collection of values (that is, a data group).
Figure 18.11 An iRule based on the matchclass command
Note that an expression such as [IP::remote__addr] equals matchclass $::aol is true if the expression is true with at least one specific value in the data group.
When using the matchclass command within an iRule, you can specify any of three types of data groups:
1.
On the Main tab, expand Local Traffic, and click iRules.
The iRules screen opens.
2.
On the menu bar, click Data Group List.
4.
In the Name box, type a unique name for the data group, such as my_address_group.
5.
In the Type box, select Address.
The screen expands to show more settings.
6.
7.
In the Address box, type the first IP address for the data group. If you are creating a network data group, also enter a network mask in the Mask box.
8.
Click Add.
The entry appears in the Address Records box.
10.
Click Finished.
A string data group contains a list of strings, such as *.jpg or *.gif. The following procedure creates a string data group.
1.
On the Main tab, expand Local Traffic, and click iRules.
The iRules screen opens.
2.
On the menu bar, click Data Group List.
4.
In the Name box, type a unique name for the data group, such as my__images.
5.
In the Type box, select String.
The screen expands to show the string-specific settings.
6.
In the String box, type the first string for the data group.
7.
Click Add.
The entry appears in the String Records box.
9.
Click Finished.
1.
On the Main tab, expand Local Traffic, click iRules.
The iRules screen opens.
2.
On the menu bar, click Data Group List.
4.
In the Name box, type a unique name for the data group, such as my__integer_group.
5.
In the Type box, select Integer.
The screen expands to display the Records section.
6.
In the Integer box, type the first integer for the data group.
7.
Click Add.
The entry appears in the Integer Records box.
9.
Click Finished.
When you create data groups, the BIG-IP system automatically saves them in their entirety in the bigip.conf file. This type of storage is known as in-line storage.
When any data in the data group needs to be updated, the entire data group must be reloaded. In general, in-line storage uses additional system resources due to extensive searching requirements on large data groups. Also, in-line storage requires you to reload entire data groups when incrementally updating data. For these reasons, the BIG-IP system offers you the ability to store you data groups externally, that is, outside of the bigip.conf file.
You have the option to store data groups in another location on the BIG-IP system, that is, outside of the bigip.conf file. Such data groups are called external data groups. The default location for storing external data groups is the /config directory. Because the data group is stored externally in another location, the bigip.conf file itself contains only meta-data for the data group. The data in an externally-stored data group file is stored as a comma-separated list of values (CSV format).
Creating external data groups is useful because data does not need to be sorted when being loaded. Instead, data is stored in a hash-table in the kernel. This storage method translates to improvements in performance when an iRule uses a large data group to direct traffic to a pool.
1.
On the Main tab, expand Local Traffic, and click iRules.
The iRules screen opens.
2.
On the menu bar, click Data Group List.
4.
In the Name box, type the name of the existing data group that you want to store in an external location.
5.
In the Type box, select (External File).
The screen expands to display the Records section.
If you do not want to store your data group in the default external location (/config), use the Path / Filename box to specify a path name and file name for the external location, for example, /home/my_address_group.
This file name should match the name that you assigned to the data group itself.
If you want to store your data group in the default external location (/config), leave the Path / Filename box empty.
7.
In the File Contents box, select the file type that pertains to the data group (Address, String, or Integer).
8.
Click Finished.
The BIG-IP system stores the data in an external data group file in comma-separated lists, and the formats of any data values, such as IP addresses, match the formats used in the bigip.conf file. Figure 18.12 shows the contents of the data group file /home/ip2.data group.
network 195.93.32.0 mask 255.255.255.0,
network 195.93.33.0 mask 255.255.255.0,
network 195.93.34.0 mask 255.255.255.0,
network 195.93.48.0 mask 255.255.255.0,
network 195.93.49.0 mask 255.255.255.0,
network 195.93.50.0 mask 255.255.255.0
1.
On the Main tab, expand Local Traffic, and click iRules.
The iRules screen opens.
2.
On the menu bar, click Data Group List.
3.
Click the name of a data group.
This displays the properties of that data group.
1.
On the Main tab, expand Local Traffic, and click iRules.
The iRules screen opens.
2.
On the menu bar, click Data Group List.
3.
Click the name of a data group.
This displays the properties of that data group.
5.
Click Add.
6.
Click Update.
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)