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 WebLogic^TM string format, representing the application IP address and service, into a literal node address.

Note

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.

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.

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.

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.

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.

Warning

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.

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

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

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.