3

Working with Intelligent Traffic Control

• Introducing Intelligent Traffic Control (ITC)
• More flexible load balancing using pools and members

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 data (URLs, HTTP version, HTTP host field), cookies, or client source address 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

BIG/ip Controller version 3.0 increases load balancing flexibility by introducing the load balancing pool. A load balancing pool is a group of nodes, or other network devices, that are mapped to corresponding virtual servers.

In previous versions of the BIG/ip Controller, the commands used to create a virtual server with a node list resulted in a directly associated, node list "pool" with identical functions. You can still create node list style virtual servers in this version of the BIG/ip Controller. However, pools are more configurable than node lists. Pools may be configured independently and associated with virtual servers in many different ways.

Load balancing pools

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

You can configure up to 65,000 pools in BIG/ip Controller version 3.0. Adding a new pool also adds a member list with at least one member, and, if needed, the server nodes referenced by the members. You can redefine an existing pool to change the load balancing method, add new members, delete old members, modify member configuration, 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 rule is evaluated to select a pool (for information about configuring rules, see Selecting a load balancing pool using a rule (BIG/ip Controller HA versions only), on page 3-7). A pool can be referenced by a number of virtual servers or rules, or none at all. A virtual server may reference a single pool, a single rule, or a node list.

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 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. However, node lists are dependent. This means that they are added as part of a virtual server, and they are deleted when the virtual server is deleted. Node lists are created by using the standard virtual server syntax to create a virtual server with a node list.

Note: The bigpipe pool show command does not display node list virtual servers.

Load balancing members

Each member in a member list is a server node or network device to which connections are load balanced. There are three new load balancing methods you can use with pools. These methods are identical to the previous ratio, priority, and least connection methods on the BIG/ip Controller with the exception that the new methods use the configuration, state, and statistics associated with each member in the pool.

BIG/ip Controller, version 3.0 supports three new load balancing methods. You can apply these load balancing options directly in the pools you define. The new options are:

• ratio_member
  You can assign ratio weights to each node in the pool with this load balancing method. The ratio weight is the proportion of total connections that the node address should receive. The default ratio weight for a given node address is 1. If all node addresses use this default weight, the connections are distributed equally among the nodes in the pool.
• priority_member
  You can assign priority values to each node 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 a pool. The BIG/ip Controller begins distributing connections in a round robin fashion to all nodes in the highest priority group of the pool. If all the nodes in the highest priority group go down or hit a connection limit maximum, the BIG/ip Controller begins to pass connections on to nodes in the next lower priority group in the pool.
• least_conn_member
  You can use this load balancing method 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. Note that current member connections may be less than the current connection of the node to which the member refers in the case where more than one member refers to the same server node.

Defining pools

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

To define a pool in the /etc/bigip.conf

You can define a pool under the server pools section in the /etc/bigip.conf file. Figure 3.1 contains the syntax of a pool definition:

ure 3.1 Pool definition syntax

pool <pool_name> { 
 <lb_mode_specification>
 member <member_definition>
 member <member_definition>
 member <member_definition> ... 
 }

For example, the entry for a pool named my_pool that uses the ratio_member load balancing method, and has two members, might look like this in the /etc/bigip.conf (Figure 3.2):

Figure 3.2 An example entry for a pool named my_pool

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
 } 

It is important to note that the ratio and priority settings in the pool definition apply only for the member load balancing methods: ratio_member and priority_member.

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> member 
<member_definition> ... member <member_definition>}

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> [...] } 

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> | <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 method for this pool
member <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>]

To configure a pool in the F5 Configuration utility

1. Click Pools in the navigation pane.
   This opens the Pools screen.
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. Click on the load balancing method list and select the load balancing method you want to use for this pool.
5. Use the resources options to add nodes 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 method 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 method 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.

Selecting a load balancing pool using a rule (BIG/ip Controller HA versions only)

With BIG/ip Controller version 3.0, 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 3- 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 like:

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

Warning: Standard BIG/ip Controller persistence modes, such as application persistence, do not work with rules.

Pool selection based on HTTP request data

The rule tells what should happen when 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.3 shows a rule with an HTTP request variable that illustrates this example:

Figure 3.3 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 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 client IP address

In addition to the HTTP variables, you can also use the client_addr variable to select a pool. You can use this variable to load balance connections based on part of the client's address. For example, 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 you create named clients_from_206 pool. All other requests will load balance using a pool you create named other_clients_pool."

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

Figure 3.4 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 begins with a statement. An if statement allows the conditional evaluation of other statements. A use statement selects a load balancing pool.

A statement may do one of three things:

• Ask a true or false question and depending on the answer decide what to do next
• Discard the request
• Use 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, or operator, and one or two subjects, or 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 (literals)

Possible constant operands are:

• 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. For example, 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. Possible variable operands are:

• Client request source IP address with the client_addr variable.
• HTTP request strings (see HREF HTTP request string variables.)

  The client_address variable is replaced with an unmasked IP address literal. All HTTP request string variables are replaced with string literals.

Operators

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?	<string> matches_regex <regular_expression>
Are two strings identical?	<string> equals <string>
Is the second string a suffix of the first string?	<string> ends_with <string>
Is the second string a prefix of the first string?	<string> starts_with <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 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.

Configuring rules from the command line or in the F5 Configuration utility

You can create rules in the /etc/bigip.conf file, from the command line, or with the F5 Configuration utility. Each of these methods is described in this section.

To define a rule from the command line

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

  bigpipe rule <pool_name> { <if statement> | <use statement>}

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

To add a rule in the F5 Configuration utility

1. Click Rules in the navigation pane.
   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.

   Click the Add button to add the rule to the BIG/ip Controller configuration.

Configuring virtual servers that reference rules from the command line or in the F5 Configuration utility

In BIG/ip Controller version 3.0, you may use either backward compatible or a new more flexible syntax to define a virtual server. The new syntax allows a rule name in place of the node list.

The possibilities for defining a virtual server that references a rule are:

  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 3 to 31 characters. use rule <rule_name>

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

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

1. Click Virtual Severs in the navigation pane.
   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.

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> ) exist <variable> not <expression> <expression> <binary_operator> <expression>
Literal	<regex_literal> <string_literal> <address_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> ]
Dot notation longword	<0-255>.<0-255>.<0-255>.<0-255>
Variable	http_method http_version http_uri http_host http_cookie <cookie name> client_addr
Binary operator	or and equals starts_with ends_with matches_regex

A comparison of load balancing configuration from previous versions of the BIG/ip Controller

You can use the method from previous versions of the BIG/ip Controller to define a virtual server with a single node list virtual server. Node lists use the global load balancing method set on the BIG/ip Controller. The global method cannot be set to the ratio_member, priority_member, or least_conn_member load balancing modes. For an example of a node list, see Figure 3.5:

Figure 3.5 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 

You can share pools with a number of virtual servers in BIG/ip Controller version 3.0. For example, Figure 3.6 shows a rule shared by a number of virtual servers:

Figure 3.6 An example of a rule that references multiple pools

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