Applies To:
Show VersionsBIG-IP versions 1.x - 4.x
- 4.5.14, 4.5.13, 4.5.12, 4.5.11, 4.5.10
5
Using the Universal Inspection Engine
- Introducing the Universal Inspection Engine
- Rule and pool examples for the Universal Inspection Engine
- Additional configuration options
Introducing the Universal Inspection Engine
The BIG-IP software contains the Universal Inspection Engine. The Universal Inspection Engine is a set of iRule syntax that provides the ability to create rules that make load balancing and persistence decisions based on arbitrary data within any TCP/IP connection.
This syntax provides the ability for the BIG-IP software to examine chunks of data, described as offsets and lengths of data, with respect to the TCP, UDP, or HTTP payload. This examination involves supporting arbitrary expressions that include full access to protocol headers such as TCP and also to TCP and UDP content.
To use the Universal Inspection Engine effectively, you need to:
- Review the function syntax.
- Choose the part of the packet you want the Universal Inspection Engine to examine.
- Review examples of iRule usage in this chapter.
Figure 5.1 The Universal Inspection Engine examines application content
Reviewing function syntax
To use the Universal Inspection Engine, it is imporant to understand the rule functions you can use as parts of expressions. A primary use of such expressions is to specify them within pool definitions, to either return a string for persistence, or to return a node to which the pool can send traffic directly. In addition to the standard expression syntax, the following functions are available:
- findstr() - Finds a string within another string and returns the string starting at the offset specified from the match.
- substr() - Returns the string starting at the offset specified.
- getfield() - Splits a string on a character and returns the string corresponding to the specific field.
- findclass() - Finds the member of a class that contains the result of the specified expression and returns that class member.
- decode_uri() - Evaluates the expression and returns a string with any %XX escape sequences decoded as per HTTP escape sequences defined in RFC2396.
- domain() - Parses and returns up to the specified number of trailing parts of a domain name from the specified expression.
- imid() - Used to parse the http_uri variable and user-agent header field for an i-mode identifier string that can be used for i-mode persistence.
There are a number of expressions that you can use primarily to directly select a particular node (pool member) within a pool. They are:
- node() - Returns a literal node address converted from a string representation of an address and port.
- mapclass2node - Represents a short-hand combination of the functions findclass(), findstr(), and node().
- wlnode() - Returns a literal node address converted from a specific BEA WebLogicTM string format, representing the application IP address and service, into a literal node address.
For a detailed list of arguments for these functions and standard expression syntax, see the BIG-IP Reference Guide, Chapter 5, iRules.
Identifying packet elements for load balancing and persistence
To use the Universal Inspection Engine effectively, you must understand the application that you want the Universal Inspection Engine to handle. You need to understand the protocol the application uses, and any information within the protocol that you can use for switching or persisting.
Before you create a rule using this syntax, you should identify the element, or elements, in the packet you want to use. One way to do this is to filter tcpdump output or use a network protocol analyzer to examine the packets you recieve on the wire.
Rule and pool examples for the Universal Inspection Engine
The following section includes examples of rules you can use in specific situations. Consider these as examples when you create rule expressions.
An example rule query for user IDs
The following rule example uses the findstr function to look in the URI for user IDs. If the Universal Inspection Engine finds the user ID field, the connection is sent to the pool A_Servers. If not, the connection goes to the pool B_Servers.
rule uri_string { if (findstr(http_uri, "?", 1) contains "userid=") { use pool A_Servers } else { use pool B_Servers } } |
An example rule using the getfield function
The following rule example looks in the URI for the specified query string (the portion following the question mark - ?) and if the first field is gold, the connection is sent to the pool A_Servers. If the text is not found in the specified location, the connection is sent to the pool Training.
rule uri_field { getfield (findstr(http_uri, '?', 1), ';', 1) == "gold") { use pool A_Servers } else { use pool Training } } |
Example rules using the tcp_content function
The following rule example waits until 38 bytes of TCP data are received and then checks for the string GOLD. If the content after 38 bytes of TCP data contains GOLD, the connection is sent to the pool A_Servers. If the text is not found in the specified location, the connection is sent to the pool Training.
rule content { if (tcp_content(38) contains "GOLD") { use pool A_Servers } else { use pool Training } } |
The following rule example also uses the tcp_content function to find the 4 bytes of the hex value specified after 38 bytes of TCP data are received, starting with the 31st byte. If the Universal Inspection Engine finds the hex value, the connection is sent to the pool A_Servers.
The following rule example uses the tcp_content attribute to find the SOCKS port value. If the Universal Inspection Engine finds the SOCKS port value in the packet, the connection is sent to the pool http_socks.
if (substr(tcp_content(4),2,2) == <0x0,0x50">) then use pool http_socks |
An example rule for finding a hex value specified
The following rule example uses the tcp_content attribute to find a hex value after receiving 8 bytes of TCP content, and then looking at the first data byte for the hex value specified. If the Universal Inspection Engine finds the value specified, the connection is sent to the pool A_Servers.
Examples of different ways to count bytes before making a decision
The http_content_collected attribute provides the ability to count a certain number of bytes before evaluating content. You can use the http_content_collected attribute with either the tcp_content or http_content attributes.
These examples can cause a connection to hang if 50 bytes are not received by the BIG-IP system.
In Figure 5.8 , the Universal Inspection Engine waits until at least 50 bytes are collected before evaluating the data. Note that this example works the same if you use http_content(50). If 50 bytes of data are accumulated and the content contains the word TEST, the connection is sent to the pool A_Servers.
In Figure 5.9 , the Universal Inspection Engine tries to find TEST with each new packet. Note that this example syntax is not the same as whey you use the syntax http_content(50). The connection is sent to the pool B_Servers if more than 50 bytes is received. If TEST is found in the first 50 bytes of data, the connection is sent to the pool A_Servers.
An example rule with the domain function
The following rule example uses the domain attribute to look for a specified domain, siterequest.com. If the Universal Inspection Engine finds the value specified, the connection is sent to the pool siterequest_servers.
rule use_domain { if (domain(http_host,2) == "siterequest.com") { use pool siterequest_servers } else { use pool public_servers } } |
Persistence example for RTSP on a pool with the getfield function
This is an example of using the getfield function in a pool definition to persist on the Real Server cookie value. The function waits until 300 bytes of TCP data are received and then counts in 6 fields, where : (a colon) is the terminator.
These settings may be different in your network environment.
pool stream_rtsp_pool { lb_method observed persist (getfield(tcp_content(300),':',6)) persist_timeout 10 member 172.16.0.150:554 member 172.16.10.150:554 } |
Persistence example for imid on a pool with the getfield function
This is an example of using the imid function in a pool definition to persist on an i-mode value.
These settings may be different in your network environment.
pool stream_imid_pool { lb_method observed persist imid persist_timeout 10 member 172.16.0.150:554 member 172.16.10.150:554 } |
Additional configuration options
Whenever you configure a BIG-IP system, you have a number of options:
- For a detailed list of arguments for these functions and standard expression syntax, see Chapter 5, iRules , in the BIG-IP Reference Guide.
- All configurations have health monitoring options. Refer to Chapter 11, Monitors , in the BIG-IP Reference Guide.
- When you create a pool, there is an option to set up persistence and a choice of load balancing methods. Refer to Chapter 4, Pools , in the BIG-IP Reference Guide.