Manual Chapter : BIG-IP Solutions Guide v4.5:Using the Universal Inspection Engine

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 4.6.1, 4.6.0, 4.5 PTF-08, 4.5 PTF-07, 4.5 PTF-06, 4.5 PTF-05, 4.5 PTF-04, 4.5 PTF-03, 4.5 PTF-02, 4.5 PTF-01, 4.5.9, 4.5.0
Manual Chapter


5

Using the Universal Inspection Engine


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.

Note


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.



Figure 5.2 An example query for user IDs


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.



Figure 5.3 An example rule with the getfield function


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.



Figure 5.4 An example rule searching for a text value at a specific location


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.



Figure 5.5 An example rule searching for a hex value at a specific location


rule content1 {
if (substr(tcp_content(38),30,4) == <0x01,0xe9,0x78,0x53>) {
use pool A_Servers
}
else {
log "Failed"
discard
}
}
 

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.



Figure 5.6 An example rule finding a SOCKS port value


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.



Figure 5.7 An example rule for searching for a hex value at a specified location


rule content2 {
if (substr(tcp_content(8),0,4) == <0xff,0xfd,0x26,0xff>) {
use pool A_Servers
}
else {
log "Discarded"
discard
}
}
 

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.

Warning


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.



Figure 5.8 An example rule that accumulates data before evaluating the content


rule count50 {
if (http_content_collected > 50) {
if (http_content contains "TEST") {
use pool A_Servers
}
else {
use pool B_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.



Figure 5.9 An example rule that evaluates data until 50 bytes are accumulated


rule countto50 {
if (http_content contains "TEST") {
use pool A_Servers
else if (http_content_collected < 50) {
accumulate
}
else {
use pool B_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.



Figure 5.10 An example rule for searching for a domain value


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.

Warning


These settings may be different in your network environment.



Figure 5.11 A pool configured with the getfield function


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.

Warning


These settings may be different in your network environment.



Figure 5.12 A pool configured with the imid function


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.