3

Working with Intelligent Traffic Control

Introducing Intelligent Traffic Control (ITC)

Intelligent traffic control (ITC) is a set of flexible features that increase the level of service and control over Internet traffic. In these features is the ability to identify specific traffic, based on HTTP request header data (URLs, HTTP host field, cookies), or IP header data (client source address, IP protocol) and send that traffic to a specific set of servers or devices that can best service the request. These features let you allocate server resources based on the type of application or content requested most. The following features are ITC features:

• Pools and members
• Load balancing rules

More flexible load balancing using pools and members

A load balancing pool is a group of nodes, or other network devices, that are mapped to corresponding virtual servers.

A pool is identified by a 1- to 31-character name. Each pool contains its own load balancing mode and persistence method. Also, a pool contains a member list, or list of network devices that handles connections sent to the pool.

The number of pools you can configure on the BIG-IP Controller is limited only by how much memory is installed on the controller. You can redefine an existing pool to change the load balancing mode, add new members, delete existing members, modify member configuration, persistence method, and reset member statistics. Deleting a pool also deletes the members in the pool. You can view statistics for a pool and its members. You can also reset statistics for an individual pool.

If a virtual server directly references a pool, no pool selection is necessary. If a virtual server references a rule, the BIG-IP Controller chooses a pool based on the criteria defined in the rule (for information about configuring rules, see Selecting a load balancing pool using a rule, on page 3-7). A pool can be referenced by a number of virtual servers or rules, or none at all. A virtual server has to reference at least one pool or rule, or it can reference multiple pools and rules.

Note: If a virtual server uses a pool, the pool may not be deleted from the BIG-IP Controller configuration. Also, a virtual server or a rule cannot be added to the BIG-IP Controller configuration if it references a pool that you have not yet defined. This means that pools must be added before, and deleted after, the virtual servers or rules that reference them.

Pools are independent, meaning that they can exist in the BIG-IP Controller configuration without being referenced by a virtual server or a rule. If a pool is not directly or indirectly associated with a virtual server, it is not used for load balancing.

Load balancing members

Each member in a pool is a server node or network device to which connections are load balanced. There are a number of load balancing modes specifically for use with pools. These modes are identical to the Global, Ratio, Priority, Least connections, Observed, and Predictive modes on the BIG-IP Controller with the exception that the new modes use the configuration, state, and statistics associated with each member in the pool.

The BIG-IP Controller supports five member load balancing modes. You can apply these load balancing modes directly in the pools you define. These modes are:

• ratio_member
  You can assign ratio values to each member in the pool with this load balancing mode. The ratio value is the proportion of total connections that the member should receive. The default ratio is 1. If all members use this default weight, the connections are distributed equally among the members in the pool.
• priority_member
  You can assign priority values to each member in the pool with this load balancing mode. Priority mode is a special type of round robin load balancing. In Priority mode, you define groups of nodes and assign a priority level to each group in the pool. The BIG-IP Controller begins distributing connections in a round robin fashion to all members in the highest priority group of the pool. If all the members in the highest priority group go down or hit a connection limit maximum, the BIG-IP Controller begins to pass connections on to members in the next lower priority group in the pool.
• least_conn_member
  You can use this load balancing mode to load balance connections to the member within the pool that has the least number of current connections. Least Connections mode works best in environments where the servers or other equipment you are load balancing have similar capabilities. In the case where more than one member refers to the same server node, the current number of connections to the member may not equal the actual total connections hosted by the node.
• observed_member
  Observed mode uses a combination of the logic used in the Least Connection and Fastest modes. In Observed mode, members are ranked based on a combination of the number of current connections and the response time. Members that have a better balance of fewest connections and fastest response time receive the greater proportion of the connections. Observed mode also works well in any environment, but may be particularly useful in environments where member performance varies significantly.
• predictive_member
  Predictive mode also uses the ranking methods used by Observed mode, where members are rated according to a combination of the number of current connections and the response time. However, in Predictive mode, the BIG-IP Controller analyzes the trend of the ranking over time, determining whether a member's performance is currently improving or declining. The members with better performance rankings that are currently improving, rather than declining, receive a higher proportion of the connections. Predictive mode works well in any environment.

Note: You should use the observed_member and predictive_member modes instead of the global observed and predictive load balancing modes. The observed_member and predictive_member modes distribute traffic more efficiently in cases where more than one member in a pool references the same node address.

Defining pools

You can define pools with the command line, or define them in the web-based Configuration utility. This section describes how to define a pool using each of these configuration methods.

To create a pool in the Configuration utility

1. In the navigation pane, click Pools.
   The Pools screen opens.
2. In the toolbar, click the Add Pool button.
   The Add Pool screen opens.
3. In the Pool Name box, type in the name you want to use for the pool.
4. In the load balancing mode list, select the load balancing mode you want to use for this pool.
5. In the Resources area, specify the nodes you want to add to the pool. To add a node to the pool, type the IP address in the Node Address box, type the port number in the Port box, and then type in the ratio or priority for this node. Finally, to add the node to the list, click the add ( >>) button.

   · Node Address
   Type in the IP address of the node you want to add to the pool.

   · Port
   Type in the port number of the port you want to use for this node in the pool.

   · Ratio
   Type in a number to assign a ratio to this node within the pool. For example, if you are using the ratio load balancing mode and you type a 1 in this box, the node will have a lower priority in the load balancing pool than a node marked 2.

   · Priority
   Type in a number to assign a priority to this node within the pool. For example, if you are using a priority load balancing mode and you type a 1 in this box, the node will have a lower priority in the load-balancing pool than a node marked 2.

   · Current Members
   This is a list of the nodes that are part of the load balancing pool.

6. Click the Apply button.

To configure a virtual server that references a pool in the Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. In the toolbar, click the Add Virtual Server button.
   The Add Virtual Server screen opens.
3. Add the attributes you want for the virtual server such as Address, Port, Unit ID, and Interface.
4. In the Resources section, click Pool.
5. In the Pool list, select the pool you want to apply to the virtual server.
6. Click the Apply button.

To define a pool from the command line

To define a pool from the command line, use the following syntax:

bigpipe pool <pool_name> {lb_mode <lb_mode_specification>
[ <persistence_specification> ] member <member_definition> ... member <member_definition>}

For example, if you want to create the pool my_pool, with two members using ratio_member load balancing, from the command line, you might type the following command:

bigpipe pool my_pool { lb_mode ratio_member member 11.12.1.101:80 ratio 1 priority 1 member 11.12.1.100:80 ratio 3 priority 1 }

Configuring a virtual server to use a load balancing pool

Use the following syntax to assign a virtual server to a load balancing pool. Note that you must create a pool before you can assign virtual servers to the pool.

bigpipe vip <virt ip>:<port> [ifname] [unit <ID>] use pool <pool_name>

For example, if you want to create a virtual server that references the pool my_pool from the previous example, the command might look like this:

bigpipe vip 11.12.1.53:80 use pool my_pool

To add or remove a pool member from the command line

To add or remove a pool member from the command line, use the following syntax:

bigpipe pool <pool_name> add | delete { <member_definition> [...] }

For example, if you want to add the member 11.12.1.103 to the pool my_pool, type the following command:

bigpipe pool my_pool add { member 11.12.1.103:80 ratio 2 \
priority 1 }

To modify a pool from the command line

To modify a pool from the command line, use the following syntax:

bigpipe pool <pool_name> modify { <lb_mode_specification> | <persistence_specification> | <member_definition> [...] }

Each of these elements is described in Table 3.1.

The elements that make up a pool

Command line element	Description
<pool_name>	The name you assign to the pool
<lb_mode_specification>	The load balancing mode for this pool
<persistence_specification>	The persistence specification for the pool
<member_definition>	A member definition. You can include a member definition for each node you want to add to the pool. The member definition consists of the following elements: <node_address>:<node_port> [ratio <ratio_value>] [priority <priority_value>]

It is important to note that the ratio and priority settings in the pool definition apply only for the ratio_member and priority_member load balancing modes and do not apply when the load balancing mode is ratio or priority.

Note: For detailed information about the persistence_specification, see Introducing advanced persistence options, on page 6-1

Selecting a load balancing pool using a rule

You can create a rule that references two or more load balancing pools. In other words, a rule selects a pool for a virtual server. A rule is referenced by 1- to 31-character name. When a packet arrives that is destined for a virtual server that does not match a current connection, the BIG-IP Controller can select a pool by evaluating a virtual server rule to pick a node pool. The rule is configured to ask true or false questions such as:

• HTTP header load-balancing: Does the packet data contain an HTTP request with a URI ending in cgi?
• IP header load balancing: Does the source address of the packet begin with the octet 206?

Pool selection based on HTTP request data

The rule specifies what action the BIG-IP Controller takes depending on whether a question is answered true or false. The rule may either select a pool or ask another question. For example, you may want a rule that states if the packet data contains an HTTP request with a URI ending in cgi, then load balance using the pool cgi_pool. Otherwise, load balance using the pool default_pool.

Figure 3.1 shows a rule with an HTTP request variable that illustrates this example:

Figure 3.1 A rule based on an HTTP header variable

 rule cgi_rule { 
      if (http_uri ends_with "cgi") { 
         use ( cgi_pool )  
      }  
      else { 
         use ( default_pool ) 
      }  
   } 

Load balancing normally happens right after the BIG-IP Controller receives a packet that does not match a current connection. However, in the case of an HTTP request, the first packet is a TCP SYN packet that does not contain the HTTP request. In this case, the BIG-IP Controller proxies the TCP handshake with the client and begins evaluating the rule again when the packet containing the HTTP request is received. When a pool has been selected and a server node selected, the BIG-IP Controller proxies the TCP handshake with the server node and then passes traffic normally.

Pool selection based on IP packet header information

In addition to the HTTP variables, you can also use IP packet header information such as the client_addr or ip_protocol variables to select a pool. For example, if you want to load balance based on part of the client's IP address, you may want a rule that states:

"All client requests with the first byte of their source address equal to 206 will load balance using a pool named clients_from_206 pool. All other requests will load balance using a pool named other_clients_pool."

Figure 3.2 shows a rule based on the client IP address variable that illustrates this example:

Figure 3.2 A rule based on the client address variable

 rule clients_from_206_rule { 
      if ( client_addr equals 206.0.0.0 netmask 255.0.0.0 ) {  
         use ( clients_from_206 )
      } 
       else { 
         use ( other_clients_pool )  
       } 
  }  

Statements

A rule consists of statements. Rules support three kinds of statements:

• An if statement asks a true or false question and, depending on the answer, decides what to do next
• A discard statement discards the request
• A use statement uses a selected pool for load balancing

  The three possible statements expressed in command line syntax are:

if (<question>) {<statement>} [else {<statement>}]

discard

use ( <pool_name> )

Questions (expressions)

A question or expression is asked by an if statement and has a true or false answer. A question or expression has two parts: a predicate (operator), and one or two subjects (operands).

There are two types of subjects (operands); some subjects change and some subjects stay the same.

• Changing subjects are called variable operands.
• Subjects that stay the same are called constant operands.

  A question, or expression, asks questions about variable operands by comparing their current value to constant operands with relational operators.

Constant operands

Possible constant operands are:

• IP protocol constants, for example:
  UDP or TCP
• IP addresses expressed in masked dot notation, for example:
  206.0.0.0 netmask 255.0.0.0
• Strings of ASCII characters, for example:
  "pictures/bigip.gif"
• Regular expression strings

Variable operands (variables)

Since variable operands change their value, they need to be referred to by a constant descriptive name. The variables available depend on the context in which the rule containing them is evaluated. Possible variable operands are:

• IP packet header variables, such as:
  • Client request source IP address with the client_addr variable. The client_address variable is replaced with an unmasked IP address.
  • IP protocol, UDP or TCP, with the ip_protocol variable. The ip_protocol variable is replaced with either the UDP or TCP protocol value.
• HTTP request strings (see HTTP request string variables, on page 3-12). All HTTP request string variables are replaced with string literals.

The evaluation of a rule is triggered by the arrival of a packet. Therefore, variables in the rule may refer to features of the triggering packet. In the case of a rule containing questions about an HTTP request, the rule is evaluated in the context of the triggering TCP SYN packet until the first HTTP request question is encountered. After the proxy, the rule continues evaluation in the context of the HTTP request packet, and variables may refer to this packet. Before a variable is compared to the constant in a relational expression, it is replaced with its current value.

In a rule, relational operators compare two operands to form relational expressions. Possible relational operators and expressions are described in Table 3.2:

The relational operators

Expression	Relational Operator
Are two IP addresses equal?	<address> equals <address>
Do a string and a regular expression match?	<variable_operand> matches_regex <regular_expression>
Are two strings identical?	<string> equals <string>
Is the second string a suffix of the first string?	<variable_operand> ends_with <string>
Is the second string a prefix of the first string?	<variable_operand> starts_with <string>
Does the first string contain the second string?	<variable_operand> contains <literal_string>

In a rule, logical operators modify an expression or connect two expressions together to form a logical expression. Possible logical operators and expressions are described in Table 3.3:

The logical operators

Expression	Logical Operator
Is the expression not true?	not <expression>
Are both expressions true?	<expression> and <expression>
Is either expression true?	<expression> or <expression>

HTTP request string variables

HTTP request variables are referred to in command line syntax by a predefined set of names. Internally, an HTTP request variable points to a method for extracting the desired string from the current HTTP request header data. Before an HTTP request variable is used in a relational expression, it is replaced with the extracted string. The allowed variable names are:

http_method
The http_method is the action of the HTTP request. Common values are GET or POST.

http_uri
The http_uri is the URL, but does not include the protocol and the fully qualified domain name (FQDN). For example, if the URL is "http://www.url.com/buy.asp", then the URI is "/buy.asp".

http_version
The http_version is the HTTP protocol version string. Possible values are HTTP/1.0 or HTTP/1.1.

http_host
The http_host is the value in the Host: header of the HTTP request. It indicates the actual FQDN that the client requested. Possible values are a FQDN or a host IP address in dot notation.

http_cookie <cookie name>
The HTTP cookie header is value in the Cookie: for the specified cookie name. An HTTP cookie header line can contain one or more cookie name value pairs. The http_cookie <cookie name> variable evaluates to the value of the cookie with the name <cookie name>.

For example, given a request with the following cookie header line:

Cookie: green-cookie=4; blue-cookie=horses

The variable http_cookie blue-cookie evaluates to the string horses. The variable http_cookie green-cookie evaluates to the string 4.

http_header <header_tag_string>
The variable http_header evaluates the string following an HTTP header tag that you specify. For example, you can specify the http_host variable with the http_header variable. In a rule specification, if you wanted to load balance based on the host name "andrew" it might look like this:

if ( http_header "Host" starts_with "andrew" ) { use ( andrew_pool ) } else { use ( main_pool ) }

Configuring rules

You can create rules from the command line or with the Configuration utility. Each of these methods is described in this section.

To add a rule in the Configuration utility

1. In the navigation pane, click Rules.
   This opens the Rules screen.
2. In the toolbar, click the Add Rule button.
   The Add Rule screen opens.
3. In the Rule Name box, type in the name you want to use for the rule.
4. In the Text box, type in a rule. Note that you should not enclose the rule with curly braces { } as you do when you create a rule directly in the bigip.conf file.
5. You can type in the rule as an unbroken line, or you can use the Enter key to add line breaks.
6. Click the Add button to add the rule to the BIG-IP Controller configuration.

To define a rule from the command line

To define a rule from the command line, use the following syntax:

bigpipe rule <rule_name> ' { <if statement> | <use statement>} '

For more information about the elements of a rule, see Table 3.5, on page 3-15.

Configuring virtual servers that reference rules

Using either the Configuration utility or the command line, you can define a virtual server that references a rule.

To configure a virtual server that references a rule in the Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. Add the attributes you want for the virtual server such as Address, Port, Unit ID, and Interface.
3. In the Resources section, click Rule.
4. In the Rule list, select the rule you want to apply to the virtual server.
5. Click the Apply button.

To configure a virtual server that references a rule from the command line

There are several elements required for defining a virtual server that references a rule from the command line:

bigpipe vip <virt_serv_key> { <vip_options> <rule_name_reference> }

Each of these elements is described in Table 3.4:

The command line rule elements

Rule element	Description
<virt_serv_key>	A virtual server key definition: <virtual_address>:<virt_port> [<interface_name>] [unit <ID>]
<vip_options>	Virtual server options such as IP netmask and broadcast address. For more information, see the BIG-IP Controller Reference Guide, BIG/pipe Command Reference.
<rule_name_reference>	A rule name reference. Rule names are strings of 1 to 31 characters. use rule <rule_name>

Note: You must define a pool before you can define a rule that references the pool.

Table 3.5 contains descriptions of all the elements you can use to create rules.

The elements you can use to construct rules

Rule element	Description
Rule definition	rule { <statement> }
Statement	<use_statement> <if_statement> discard
Use statement	use ( <pool_name> )
If statement	if ( <expression> ) { <statement> } [ else { <statement> } ]
Expression	<literal> <variable> ( <expression> ) exists <variable> not <expression> <expression> <binary_operator> <expression>
Literal	<regex_literal> <string_literal> <address_literal> <constant_literal>
Regular expression literal	A string of 1 to 63 characters enclosed in quotes that may contain regular expressions
String literal	A string of 1 to 63 characters enclosed in quotes
Address literal	<dot_notation_longword> [ netmask <dot_notation_longword> ]
Constant literal	UDP TCP
Dot notation longword	<0-255>.<0-255>.<0-255>.<0-255>
Variable	http_method http_version http_uri http_host http_cookie <cookie name> http_header <header_tag_string> client_addr ip_protocol
Binary operator	or and equals starts_with ends_with matches_regex

Additional rule examples

This section includes additional examples or rules. The following rule examples are included:

• Cookie rule
• Language rule
• Cacheable contents rule
• AOL rule
• Protocol specific rule

Cookie rule

This example is a cookie rule that load balances based on the user ID that contains the word VIP.

Figure 3.3 An example cookie rule

 if ( exists http_cookie "user-id" and  
       http_cookie "user-id" contains "VIP" ) {  
     use ( vip_pool )  
  } 
   else {
     use ( other_pool )
   } 

Language rule

This is an example of a rule that load balances based on the language requested by the browser:

Figure 3.4 An example of a rule that load balances based on the language requested by the browser

 if ( exists http_header "Accept-Language" ) {  
     if ( http_header "Accept-Language" equals "fr" ) {  
        use ( french_pool ) 
      }  
     else {
        if ( http_header "Accept-Language" equals "sp" ) {  
           use (spanish_pool )  
        }  
        else {  
           use ( english_pool )  
         } 
      }  
    else {  
     use ( english_pool )  
  } 

Cache content rule

This is an example of a rule that you can use to send cache content, such as gifs, to a specific pool.

Figure 3.5 An example of a cache content rule

 if ( http_uri ends_with "gif" or 
        http_uri ends_with "html" ) { 
     use ( cache_pool )  
  }  
  else { 
      use ( server_pool ) 
  } 

AOL rule

This is an example of a rule that you can use to load balance incoming AOL connections.

Figure 3.6 An example of an AOL rule

 port 80 443 enable 

   pool aol_pool { 
      lb_mode priority_member  
     member 12.0.0.31:80 priority 4 
      member 12.0.0.32:80 priority 3  
     member 12.0.0.33:80 priority 2   
      member 12.0.0.3:80 priority 1  
  } 
  pool other_pool {  
     lb_mode priority_member  
     member 12.0.0.31:80 priority 2  
     member 12.0.0.32:80 priority 2  
     member 12.0.0.33:80 priority 2 
      member 12.0.0.3:80 priority 1 
  } 
  pool aol_pool_https { 
     lb_mode priority_member  
     member 12.0.0.31:443 priority 4   
     member 12.0.0.32:443 priority 3  
     member 12.0.0.33:443 priority 2  
     member 12.0.0.3:443 priority 1  
  } 
  pool other_pool_https{  
     lb_mode priority_member 
     member 12.0.0.31:443 priority 2  
     member 12.0.0.32:443 priority 2  
     member 12.0.0.33:443 priority 2 
     member 12.0.0.3:443 priority 1  
  }  
  rule aol_rule {   
     if (    client_addr equals 152.163.128.0 netmask 255.255.128.0  
           or client_addr equals 195.93.0.0    netmask 255.255.254.0  
           or client_addr equals 205.188.128.0 netmask 255.255.128.0 ) {  
        use ( aol_pool )  
      }  
      else { 
        use ( other_pool)  
     }  
  }  
   rule aol_rule_https {  
     if (    client_addr equals 152.163.128.0 netmask 255.255.128.0 
           or client_addr equals 195.93.0.0    netmask 255.255.254.0  
           or client_addr equals 205.188.128.0 netmask 255.255.128.0 ) {  
         use ( aol_pool_https ) 
      } 
      else { 
        use ( other_pool_https)  
      }  
   }  
   vip 15.0.140.1:80  { use rule aol_rule }  
   vip 15.0.140.1:443 { use rule aol_rule_https special ssl 30 }

IP protocol specific rule

This is an example of a rule that you can use to send TCP DNS to the pool tcp_pool and UDP DNS to the pool udp_pool.

Figure 3.7 An example of an IP protocol rule

 rule myrule {     
      if ( ip_protocol equals UDP ) {    
        use ( udp_pool )    
      }    
      else {     
         use ( tcp_pool )    
      }      

Comparing load balancing configurations

You can use the method from previous versions of the BIG-IP Controller to define a virtual server with a single node list. However, with this version of the BIG-IP Controller, node list virtual servers are being phased out. Node lists use the global load balancing mode set on the BIG-IP Controller. The global mode cannot be set to the ratio_member, priority_member, least_conn_member, observed_member, or predictive_member load balancing modes. For an example of a node list, see Figure 3.8:

Figure 3.8 The node list method of defining virtual servers

   lb ratio    
   vip 15.0.140.1:80 {    
       define 12.0.0.44:80 12.0.0.45:80    
   }    
   ratio {    
       12.0.0.44    
   } 1    
   ratio {    
       12.0.0.45    
   } 2     

In contrast to a node list virtual server, you can share pools with a number of virtual servers on the BIG-IP Controller. For example, Figure 3.9 shows the gif_pool shared by two virtual servers:

Figure 3.9 An example of a pool shared by two virtual servers

   pool cgi_pool {    
       lb_mode ratio_member    
       member 12.0.0.44:80 ratio 1    
       member 12.0.0.45:80 ratio 2    
   }    
   pool gif_pool {    
       lb_mode ratio_member    
       member 12.0.0.44:80 ratio 1    
       member 12.0.0.45:80 ratio 3    
   }    
   rule http_rule {    
       if ( http_uri ends_with "gif" ) {    
           use ( gif_pool )    
       }    
       else {    
           use ( cgi_pool )    
       }    
   }    
       
   vip 15.0.140.1:80 {     
       netmask 255.255.0.0 broadcast 15.0.255.255    
       use rule http_rule    
   }    
   vip 15.0.140.2:80 {    
       netmask 255.255.0.0 broadcast 15.0.255.255    
       use pool gif_pool     
   }