Applies To:
Show VersionsBIG-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
4
Pools
- Introducing pools
- Managing pools
- Load balancing methods
- Setting persistence
- Redirecting HTTP requests
- Inserting and erasing HTTP headers
- Configuring the Quality of Service (QoS) level
- Configuring the Type of Service (ToS) level
- Disabling SNAT and NAT connections
- Enabling a forwarding pool
- Configuring a clone pool
Introducing pools
A load balancing pool is the primary object in the high-level network. When you create a pool, the members of the pool become visible nodes on the high-level network, and can acquire the various properties that attach to nodes.
A pool is a set of devices grouped together to receive traffic according to a load balancing method. Pools are associated with a specific virtual server. Thus, traffic coming into a virtual server is normally directed to one of the associated pools. As an option, you can redirect traffic to a different pool using the BIG-IP system's iRules feature. For more information on iRules, see Chapter 5, iRules .
Once a pool receives traffic, either directly from a virtual server or through a rule, the pool can optionally perform a number of different operations, such as inserting a header into an HTTP request, setting the Quality of Service or Type of Service level within a packet, or redirecting a request to a fallback destination.
Perhaps the most useful and flexible feature with respect to pools, however, is the BIG-IP system's Universal Inspection Engine (UIE). The UIE allows a pool to make load-balancing decisions based on information contained either in headers, or in the content of a packet. Thus, a pool can perform load-balancing operations such as sending traffic to a specific node within the pool, or enabling persistence based on any string or node that you define.
Required pool attributes
When creating a basic pool, you must specify two pool attributes. Table 4.1 lists and describes these required attributes.
Required Attribute |
Description |
---|---|
Pool name |
The most basic attribute you can configure for a pool is the pool name. Pool names are case-sensitive and may contain letters, numbers, and underscores (_) only. Reserved keywords are not allowed. Each pool that you define must have a unique name. |
Member IP address |
For each pool that you create, you must specify the nodes that are to be members of that pool. Nodes must be specified by their IP addresses. |
A third attribute, the load balancing method, is required; however, the BIG-IP system automatically specifies a default mode when you create the pool. For more information, see Load balancing methods .
Optional pool attributes
You create a pool using the Configuration utility or the bigpipe pool command. When you create the pool, you assign a pool name and specify a number of attributes, such as the members of the pool, the load balancing method you want the BIG-IP system to use to select pool members, and the type of persistence required, if any. You can also configure the pool to send certain types of traffic to a specific member of that pool.
When creating a pool, you can configure several optional pool attributes. Table 4.2 lists the optional attributes you can configure for a pool.
Pool Attribute |
Description |
---|---|
Load balancing method |
You can define a specific load balancing method for a pool, and you can configure priority-based member activation. Various pools can be configured with different load balancing methods. |
Persistence method |
You can assign a pre-defined persistence type to a pool, or you can specify an expression that enables persistence on any string. You can also specify an expression that directly selects a node within a pool. |
HTTP redirection |
You can redirect HTTP requests to a fallback host, protocol, port, or URI path. |
HTTP header insertion |
You can configure a pool to insert a header into an HTTP request. For example, the header could include an original client IP address, to preserve the address during a SNAT connection. |
HTTP header erase |
You configure a pool to erase the contents of a header in an HTTP request. This is useful when headers contain sensitive information that you do not want to forward over a network. |
Quality of Service (QoS) level |
You can configure a pool to set a specific QoS level within a packet, based on the targeted pool. |
Type of Service (ToS) level |
You can configure a pool to set a specific ToS level within a packet, based on the targeted pool. |
Disabling of SNAT and NAT connections |
You can configure a pool so that SNATs and NATs are automatically disabled for any connections using that pool. |
Forwarding |
You can configure a forwarding pool, which causes a connection to be forwarded, using IP routing, instead of load balanced. Creating a forwarding pool allows you to use pool-based features for traffic that should be forwarded. |
Mirroring |
The mirror attribute mirrors a persistence record over to a standby unit. A persistence record identifies the connections to be persisted. |
Clone pool |
The clone pool attribute is used for intrusion detection. When the attribute is enabled, a regular pool has a clone pool configured for it. |
A full description of these attributes begins with the section Load balancing methods .
Managing pools
You can manage pools using either the web-based Configuration utility or the command-line interface. This section describes how to create, delete, modify, or display a pool, using each of these configuration methods.
Creating a pool
You can create either a basic pool, specifying just a pool name and pool members, or you can create a pool specifying multiple attributes, such as persistence types, header insertion, and Quality of Service/Type of Service levels.
To create a pool using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - Click the Add button.
The Add Pool screen opens. - In the Add Pool screen, fill in the fields to create the new pool and configure its attributes.
- Click Done.
To create a pool from the command line
To define a pool and configure its attributes from the command line, use the following syntax:
b pool <pool_name> { member <member_definition> ... member <member_definition> }
For example, if you want to create the pool my_pool with two members, you type the following command:
b pool my_pool { member 11.12.1.101:80 member 11.12.1.100:80 }
Table 4.3 lists all pool attributes and shows the syntax that you use to configure them with the bigpipe pool command.
Pool Attribute |
Syntax |
---|---|
Pool name |
A string from 1 to 31 characters, for example: new_pool |
Member definition |
member <ip_address>:<service> [ratio <value>] [priority <value>] |
load balancing method |
lb_method [rr | ratio | fastest | least_conn | predictive | observed | ratio_member | fastest_member | least_conn_member | observed_member | predictive_member | dynamic_ratio] |
persistence type |
persist [ simple | cookie | ssl | sip | sticky | msrdp | <expression> ] persist_timeout [<timeout_value>] select [<expression>] |
fallback host specification |
fallback <fallback_host> |
fallback protocol specification |
fallback <fallback_protocol> |
fallback port specification |
fallback <fallback_port> |
fallback path specification |
fallback <fallback_path> |
header insert and erase |
header_insert <quoted string> |
link_qos to client level |
link_qos to client <level> |
link_qos to server level |
link_qos to server <level> |
ip_tos to client level |
ip_tos to client <level> |
ip_tos to server level |
ip_tos to server <level> |
snat disable |
snat <ip address> disable |
nat disable |
nat <ip address> disable |
forward |
forward |
clone pool |
clone before | clone after <pool_name> |
Modifying a pool
In addition to adding nodes to a pool or deleting nodes from a pool, you can also modify pool attributes. You can add a new member to a pool, change the load-balancing mode, or delete a member from a pool.
To modify the attributes of a pool, you can use either the Configuration utility or the bigpipe pool command.
To modify a pool using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click on the name of the pool that you want to modify.
This displays the properties of that pool. - Change any of the pool attributes shown.
- Click Apply.
To modify a pool from the command line
The following example shows how to change the default load-balancing mode from Round Robin to Predictive and add two new members to the pool:
b pool <pool_name> { lb_method predictive member 11.12.1.101:80 member 11.12.1.100:80 }
Deleting a pool
You can delete an existing pool, using either the Configuration utility or the bigpipe pool command.
To delete a pool using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, locate the pool that you want to delete and click the Delete button.
A confirmation dialog box appears. - Click OK.
To delete a pool from the command line
To delete a pool, use the following syntax:
b pool <pool_name> delete
You must remove all references to a pool before you can delete a pool.
Displaying a pool
Displaying a pool means looking at the properties of that pool. You can look at the properties of an existing pool using either the Configuration utility or the bigpipe pool command.
To display a pool using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click on the name of the pool that you want to modify.
This displays the properties of that pool.
To display one or more pools from the command line
Use the following command to display all pools:
b pool show
Use the following command syntax to display a specific pool:
b pool <pool_name> show
The following sections describe the various pool attributes that you can configure for a pool.
Load balancing methods
Load balancing is an integral part of the BIG-IP system. Configuring load balancing on the BIG-IP system means determining your load balancing scenario, that is, which node should receive a connection hosted by a particular virtual server. Once you have decided on a load balancing scenario, you can specify the appropriate load balancing method for that scenario.
A load balancing method is an algorithm or formula that the BIG-IP system uses to determine the node to which traffic will be sent. Individual load balancing methods take into account one or more dynamic factors, such as current connection count. Because each application of the BIG-IP system is unique, and node performance depends on a number of different factors, we recommend that you experiment with different load balancing methods, and select the one that offers the best performance in your particular environment.
The default load balancing method on the BIG-IP system is Round Robin, which simply passes each new connection request to the next server in line. All other load balancing methods take server capacity and/or status into consideration.
If the equipment that you are load balancing is roughly equal in processing speed and memory, Round Robin mode works well in most configurations. If you want to use the Round Robin mode, you can skip the remainder of this section, and begin configuring other pool attributes that you want to add to the basic pool configuration.
If you are working with servers that differ significantly in processing speed and memory, you may want to switch to Ratio mode or to one of the dynamic modes, described in this section.
Round Robin
This is the default load balancing method. Round Robin mode passes each new connection request to the next server in line, eventually distributing connections evenly across the array of machines being load balanced. Round Robin mode works well in most configurations, especially if the equipment that you are load balancing is roughly equal in processing speed and memory.
Ratio
The BIG-IP system distributes connections among machines according to ratio weights that you define, where the number of connections that each machine receives over time is proportionate to a ratio weight you define for each machine. This is a static load balancing method, basing distribution on static user-assigned ratio weights that are proportional to the capacity of the servers.
Load balancing calculations may be localized to each pool (member-based calculation) or they may apply to all pools of which a server is a member (node-based calculation). Member-based calculation is specified by the extension ratio_member. This distinction is especially important; in Ratio Member mode, the actual ratio weight is a member attribute in the pool definition, whereas in Ratio mode, the ratio weight is an attribute of the node.
Dynamic ratio
Dynamic Ratio mode is like Ratio mode except that ratio weights are based on continuous monitoring of the servers and are therefore continually changing.
This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time.
Dynamic Ratio mode is used specifically for load balancing traffic to RealNetworks® RealSystem® Server platforms, Windows® platforms equipped with Windows Management Instrumentation (WMI), or any server equipped with an SNMP agent such as the UC Davis SNMP agent or Windows 2000 Server SNMP agent. To implement Dynamic Ratio load balancing, you must first install and configure the necessary server software for these systems. For more information, see Configuring Dynamic Ratio load balancing .
Fastest
Fastest mode passes a new connection based on the fastest response of all currently active nodes. Fastest mode may be particularly useful in environments where nodes are distributed across different logical networks.
Load balancing calculations may be localized to each pool (member-based calculation) or they may apply to all pools of which a server is a member (node-based calculation). The variant of the mode using member-based calculation is distinguished by the extension fastest_member.
Least Connections
Least Connections mode is relatively simple in that the BIG-IP system passes a new connection to the node 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.
This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time.
Load balancing calculations may be localized to each pool (member-based calculation) or they may apply to all pools of which a server is a member (node-based calculation). The variant of the mode using member-based calculation is distinguished by the extension least_conn_member.
Observed
Observed mode uses a combination of the logic used in the Least Connection and Fastest modes. In Observed mode, nodes are ranked based on a combination of the number of current connections and the response time. Nodes that have a better balance of fewest connections and fastest response time receive a greater proportion of the connections. Observed mode also works well in any environment, but may be particularly useful in environments where node performance varies significantly.
This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time.
Load balancing calculations may be localized to each pool (member-based calculation) or they may apply to all pools of which a server is a member (node-based calculation). The variant of the mode using member-based calculation is distinguished by the extension observed_member.
Predictive
Predictive mode also uses the ranking methods used by Observed mode, where nodes are rated according to a combination of the number of current connections and the response time. However, in Predictive mode, the BIG-IP system analyzes the trend of the ranking over time, determining whether a node's performance is currently improving or declining. The nodes 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.
This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time.
Load balancing calculations may be localized to each pool (member-based calculation) or they may apply to all pools of which a server is a member (node-based calculation). The variant of the mode using member-based calculation is distinguished by the extension predictive_member.
Setting the load balancing method for a pool
A load balancing method is specified as a pool attribute when a pool is defined and may be changed by changing this pool attribute. For information about configuring a pool, see Managing pools . The following example describes how to configure a pool to use Ratio Member load balancing. Note that for Ratio Member mode, in addition to changing the load balancing attribute, you must assign a ratio weight to each member node.
The default ratio weight for a node is 1. If you keep the default ratio weight for each node in a virtual server mapping, the nodes receive an equal proportion of connections as though you were using Round Robin load balancing.
To configure the pool and load balancing method using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - The next action depends on your intent:
- If you are adding a new pool, click the Add button.
The Add Pool screen opens. - If you are changing an existing pool, click the pool name in the Pool Name list.
The Pool Properties screen opens.
- If you are adding a new pool, click the Add button.
- In the Add Pool screen or Pool Properties screen, configure the pool attributes. For additional information about defining a pool, click the Help button.
Round Robin is the default load balancing method and never needs to be set unless you are returning to it from a non-default mode.
To switch a pool to ratio_member mode using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click a pool name.
This displays the properties of that pool. - In the Current Members list, click the member you want to edit.
- Click the Back button (<<) to pull the member into the resources section.
- Change or add the ratio value for the member.
- Click the Add button (>>) to add the member to the Current Members list.
- Click Done.
To switch a pool to Ratio Member mode from the command line
To switch a pool to ratio_member load balancing, use the modify keyword with the bigpipe pool command. For example, if you want to change the pool my_pool to use the ratio_member load balancing method and to assign each member its ratio weight, you can type the following command:
b pool my_pool modify { lb_method ratio_member member 11.12.1.101:80 ratio 1 member 11.12.1.100:80 ratio 3}
If you set the load balancing method to Ratio (as opposed to Ratio Member), you must define the ratio settings for each node address.
Setting ratio weights for node addresses
The default ratio setting for any node address is 1. If you use the Ratio (as opposed to Ratio Member) load balancing method, you must set a ratio other than 1 for at least one node address in the configuration. If you do not change at least one ratio setting, the load balancing method has the same effect as the Round Robin load balancing method.
To set ratio weights using the Configuration utility
- In the navigation pane, click Nodes.
- In the Nodes list, click the Node Addresses tab.
The Node Addresses screen opens. - In the Node Addresses screen, click the Address of the node.
The Global Node Address screen opens. - In the Ratio box, type the ratio weight of your choice.
- Click the Apply button to save your changes.
To set ratio weights from the command line
The bigpipe ratio command sets the ratio weight for one or more node addresses:
b ratio <node_ip> [<node_ip>...] <ratio weight>
For example, the following command sets the ratio weight to 3 for a specific node address:
b ratio 192.168.103.20 3
The <weight> parameter must be a whole number, equal to or greater than 1.
Displaying ratio weights for node addresses
To display the ratio weights for one or more members using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the name of the pool.
This displays the properties of that pool. - In the Current Members list, view the r number following each IP address.
To display the ratio weights for one or more node addresses from the command line
The following command displays the current ratio weight settings for all node addresses.
b ratio show
The command displays the output shown in Figure 4.1 .
The following command syntax displays the ratio setting for one or more node addresses:
b ratio <node_ip> [...<node_ip>] show
Configuring Dynamic Ratio load balancing
You can configure Dynamic Ratio load balancing for pools that consist of RealNetworks® RealServer servers, Windows servers equipped with Windows Management Instrumentation (WMI), or any server equipped with an SNMP agent such as the UC Davis SNMP agent or Windows 2000 Server SNMP agent.
To implement Dynamic Ratio load balancing, the BIG-IP system provides a special monitor plugin file and a health monitor template for each type of server (except for a server equipped with an SNMP agent. In this case, the BIG-IP system needs to provide the monitor template only).
For each server, the monitor plugin must be installed on the server, while the monitor template is used to create a monitor that resides on the BIG-IP system. Once created, the monitor communicates directly with the server plugin.
Table 4.4 shows, for each server type, the required monitor plugin and the corresponding health monitor templates.
Server Type |
Monitor Plugin |
BIG-IP Monitor Template |
---|---|---|
RealServer Windows server |
F5RealMon.dll |
real_server |
Windows server with WMI |
F5Isapi.dll |
wmi |
Windows 2000 Server server |
SNMP agent |
snmp_dca and snmp_dca_base |
Configuring RealSystem Server systems
For RealSystem Server systems, the BIG-IP system provides a monitor plugin that gathers the necessary metrics when the plugin is installed on the RealSystem Server system. Configuring a RealSystem Server for Dynamic Ratio load balancing consists of four tasks:
- Installing the monitor plugin on the RealSystem server
- Configuring a real_server health check monitor on the BIG-IP system
- Associating the health check monitor with the server to gather the metrics
- Creating or modifying the server pool to use Dynamic Ratio load balancing
To install the monitor plugin on a RealSystem Server system (Windows version)
Use the following procedure to install the monitor plugin on a Windows RealSystem Server system.
- Download the monitor plugin F5RealMon.dll from the BIG-IP system. The plugin is located in /usr/contrib/f5/isapi. (The URL is https://<bigip_address>/doc/rsplugin/f5realmon.dll.)
- Copy f5realmon.dll to the RealServer Plugins directory. (For example, C:\Program Files\RealServer\Plugins.)
- If the RealSystem Server process is running, restart it.
To install the monitor plugin on a RealSystem Server system (UNIX version)
- From the BIG-IP CD, copy the file F5RealMonsrc.tgz from the directory downloads/rsplugins.
- Download the RealSystem Server SDK from <<http://proforma.real.com/rnforms/resources/server/realsystemsdk/index.html>>
- Use the UNIX utilities gunzip and tar to uncompress the file F5RealMonsrc.tgz, as follows:
gunzip F5ReaMonsrc.tgz
tar -xpf F5RealMonsrc.tar
A list of files appears that includes two makefiles, linux-2.0-libc6-i386.mak and sunos-5.7-sparc.mak, for Linux and SunOS systems respectively.
- In both makefiles, change the paths that point to the SDK location.
- Type one of the following commands, depending on your operating system:
make -f linux-2.0-libc6-i386.mak (for Linux)
make -f sunos-5.7-sparc.mak (for Sunos)
This creates a source file for the RealSystem Server plugin, F5RealMon.so.
- Move the F5RealMon.so plugin to the Plugins/ directory under the RealServer home directory.
- Start RealSystem Server.
To configure a real_server monitor for the server node
Using the Configuration utility or the bigpipe command, create a health-check monitor using the real_server monitor template. The real_server monitor template is shown in the Figure 4.2 .
monitor type real_server { interval 5 timeout 16 dest *.12345 method "GET" cmd "GetServerStats" metrics "ServerBandwidth:1.5,CPUPercentUsage,MemoryUsage, TotalClientCount" agent "Mozilla/4.0 (compatible: MSIE 5.0; Windows NT) } |
The real_server monitor template can be used as is, without modifying any of the attributes. Alternatively, you can add metrics and modify metric attribute values. To do this, you need to create a custom monitor. For example:
b monitor my_real_server '{ use real_server metrics "ServerBandwidth:2.0" }'
The complete set of server-specific metrics and metric attribute default values is shown in Table 4.5 .
Metric |
Default Coefficient |
Default Threshold |
---|---|---|
ServerBandwidth (Kbps) |
1.0 |
10,000 |
CPUPercentUsage |
1.0 |
80 |
MemoryUsage (Kb) |
1.0 |
100,000 |
TotalClientCount |
1.0 |
1,000 |
RTSPClientCount |
1.0 |
500 |
HTTPClientCount |
1.0 |
500 |
PNAClientCount |
1.0 |
500 |
UDPTransportCount |
1.0 |
500 |
TCPTransportCount |
1.0 |
500 |
MulticastTransportCount |
1.0 |
500 |
The metric coefficient is a factor determining how heavily the metric's value counts in the overall ratio weight calculation. The metric threshold is the highest value allowed for the metric if the metric is to have any weight at all. To understand how to use these values, it is necessary to understand how the overall ratio weight is calculated. The overall ratio weight is the sum of relative weights calculated for each metric. The relative weights, in turn, are based on three factors:
- the value for the metric returned by the monitor
- the coefficient value
- the threshold value
Given these values, the relative weight is calculated as follows:
w=((threshold-value)/threshold)*coefficient
You can see that the higher the coefficient, the greater the relative weight calculated for the metric. Similarly, the higher the threshold, the greater the relative weight calculated for any metric value that is less than the threshold. (When the value reaches the threshold, the weight goes to zero.)
Note that the default coefficient and default threshold values shown in Table 4.5 are metric defaults, not template defaults. The template defaults take precedence over the metric defaults, just as user-specified values in the custom real_server monitor take precedence over the template defaults. For example, in Figure 4.2 , the template specifies a coefficient value of 1.5 for ServerBandwidth and no value for the other metrics. This means that the template will use the template default of 1.5 for the ServerBandwidth coefficient and the metric default of 1 for the coefficients of all other metrics. However, if a custom monitor my_real_server were configured specifying 2.0 as the ServerBandwidth coefficient, this user-specified value would override the template default.
The syntax for specifying non-default coefficient or threshold values is:
<metric>:<coefficient |<*>:<threshold>
The following examples show how to specify a coefficient value only, a threshold value only, and a coefficient and a threshold value, respectively.
b monitor my_real_server '{ use real_server metrics CPUPercentUsage:1.5 }'
b monitor my_real_server '{ use real_server metrics CPUPercentUsage:*:70 }'
b monitor my_real_server '{ use real_server metrics CPUPercentUsage:1.5:70 }'
Metric coefficient and threshold are the only non-template defaults. If a metric not in the template is to be added to the custom monitor, it must be added to the metric list:
b monitor my_real_server '{ use real_server metrics "HTTPClientCount" }'
To associate the monitor with the member node
Associate the custom health check monitor with the server node, creating an instance of the monitor for that node:
b node <node_addr> monitor use my_real_server
To set the load balancing method to Dynamic Ratio
Create or modify the load balancing pool to which the server belongs to use Dynamic Ratio load balancing:
b pool <pool_name> { lb_method dynamic_ratio <member definition>... }
Configuring Windows servers with WMI
For Windows running Windows Management Instrumentation (WMI), the BIG-IP system provides a Data Gathering Agent F5Isapi.dll for the server. Configuring a Windows platform for Dynamic Ratio load balancing consists of four tasks:
- Installing the Data Gathering Agent F5Isapi.dll on the server
- Configuring a wmi health check monitor on the BIG-IP system
- Associating the health check monitor with the server to gather the metrics
- Creating or modifying the server pool to use Dynamic Ratio load balancing
To install the Data Gathering Agent (F5Isapi) on the server
- Download the Data Gathering Agent (F5Isapi.dll) from the BIG-IP system. The plugin is located in /usr/contrib/f5/isapi. (The URL is https://<bigip_address>/doc/isapi/f5isapi.dll.)
- Copy f5isapi.dll to the directory C:\Inetpub\scripts.
- Open the Internet Services Manager.
- In the left pane of the Internet Services Manager, open the folder <machine_name>\Default Web Site\Script, where <machine_name> is the name of the server you are configuring. The contents of Scripts folder opens in the right pane.
- In the right pane, right click F5Isapi.dll,and select Properties.
The Properties dialog box for F5Isapi.dll opens. - Deselect Logvisits. (Logging of each visit to the agent quickly fills up the log files.)
- Click the File Security tab.
The File Security options appears. - In the Anonymous access and authentication control group box, click Edit.
The Authentication Methods dialog box opens. - In the Authentication methods dialog box, clear all check boxes, then select Basic Authentication.
- In the Authentication methods dialog box, click OK to accept the changes.
- In the Properties dialog box, click Apply.
The WMI Data Gathering Agent is now ready to be used.
To configure a wmi monitor for the server node
Using the Configuration utility or the bigpipe command, create a health check monitor using the wmi monitor template. The wmi monitor template is shown in Figure 4.3 .
monitor type wmi { interval 5 timeout 16 dest *:12346 username "" password "" method "POST" urlpath "/scripts/F5Isapi.dll" cmd "GetCPUInfo, GetDiskInfo, GetOSInfo" metrics "LoadPercentage, DiskUsage, PhysicalMemoryUsage:1.5, VirtualMemoryUsage:2.0" post "<input type='hidden' name='RespFormat' value='HTML'>" agent "Mozilla/4.0 (compatible: MSIE 5.0; Windows NT) } |
The monitor template contains default values for all the attributes. These are template defaults. In creating a custom monitor from the template, the only default values you are required to change are the null values for user name and password. For example:
b monitor my_wmi '{ use wmi username "dave" password "$getm" }'
You may also add commands and metrics and modify metric attribute values. The complete set of commands, associated metrics, and metric attribute default values are shown in Table 4.6 .
Command |
Metric |
Default Coefficient |
Default Threshold |
---|---|---|---|
GetCPUInfo |
LoadPercentage (%) |
1.0 |
80 |
GetOSInfo |
PhysicalMemoryUsage (%) |
1.0 |
80 |
VirtualMemoryUsage (%) |
1.0 |
80 |
|
NumberRunningProcesses |
1.0 |
100 |
|
GetDiskInfo |
DiskUsage (%) |
1.0 |
90 |
GetPerfCounters |
TotalKBytesPerSec |
1.0 |
10,000 |
ConnectionAttemptsPerSec |
1.0 |
500 |
|
CurrentConnections |
1.0 |
500 |
|
GETRequestsPerSec |
1.0 |
500 |
|
PUTRequestsPerSec |
1.0 |
500 |
|
POSTRequestsPerSec |
1.0 |
500 |
|
AnonymousUsersPerSec |
1.0 |
500 |
|
CurrentAnonymousUsers |
1.0 |
500 |
|
NonAnonymousUsersPerSec |
1.0 |
500 |
|
CurrentNonAnonymousUser |
1.0 |
500 |
|
CGIRequestsPerSec |
1.0 |
500 |
|
CurrentCGIRequests |
1.0 |
500 |
|
ISAPIRequestsPerSec |
1.0 |
500 |
|
CurrentISAPIRequests |
1.0 |
500 |
|
GetWinMediaInfo |
AggregateReadRate |
1.0 |
10,000 Kbps |
AggregateSendRate |
1.0 |
10,000 Kbps |
|
ActiveLiveUnicastStreams |
1.0 |
1000 |
|
ActiveStreams |
1.0 |
1000 |
|
ActiveTCPStreams |
1.0 |
1000 |
|
ActiveUDPStreams |
1.0 |
1000 |
|
AllocatedBandwidth |
1.0 |
10,000 Kbps |
|
AuthenticationRequests |
1.0 |
1000 |
|
AuthenticationsDenied |
1.0 |
100 |
|
AuthorizationRequests |
1.0 |
1000 |
|
AuthorizationsRefused |
1.0 |
100 |
|
ConnectedClients |
1.0 |
500 |
|
ConnectionRate |
1.0 |
500 |
|
HTTPStreams |
1.0 |
1000 |
|
HTTPStreamsReadingHeader |
1.0 |
500 |
|
HTTPStreamsStreamingBody |
1.0 |
500 |
|
LateReads |
1.0 |
100 |
|
PendingConnections |
1.0 |
100 |
|
PluginErrors |
1.0 |
100 |
|
PluginEvents |
1.0 |
100 |
|
SchedulingRate |
1.0 |
100 |
|
StreamErrors |
1.0 |
100 |
|
StreamTerminations |
1.0 |
100 |
|
UDPResendRequests |
1.0 |
100 |
|
UDPResendsSent |
1.0 |
100 |
For more information about the metric coefficients and thresholds, refer to the description accompanying Table 4.5, real_server monitor metrics . Note that for a wmi monitor, you can add commands. To do this, simply add them to the cmd list.
To associate the monitor with the member node
Associate the custom health check monitor with the server node, creating an instance of the monitor for that node:
b node <node_addr> monitor use my_wmi
To set the load balancing method to Dynamic Ratio
Use the following syntax to create or modify the load balancing pool to which the server belongs to use Dynamic Ratio load balancing:
b pool <pool_name> { lb_method dynamic_ratio <member definition>...}
Configuring an SNMP agent
The BIG-IP system includes an SNMP data collecting agent that can query remote SNMP agents of various types, including the UC Davis agent and the Windows 2000 Server agent. Configuring a server to use its SNMP agent for Dynamic Ratio load balancing consists of three tasks:
- Configuring a health check monitor, using either the Configuration utility or the bigpipe command
- Associating the health check monitor with the server to gather the metrics
- Creating or modifying the server pool to use Dynamic Ratio load balancing
The BIG-IP system provides two templates that you can use to create a health monitor for a server that uses an SNMP agent. These two monitor templates are:
Use this template when you want to use default values or specify new values for CPU, memory, and disk metrics. When using this template, you can also specify values for other types of metrics that you wish to gather.
Use this template when you want to use default values or specify values for metrics other than CPU, memory, and disk usage. When using this template, values for CPU, memory, and disk metrics are omitted.
For a description of these templates and the default values for each metric, see Chapter 11, Monitors .
Figure 4.4 shows a monitor based on the snmp_dca monitor template. This monitor uses the default metric values. You can optionally specify variables for user-defined metrics.
monitor my_snmp_dca '{ use snmp_dca interval 10 timeout 30 dest *:161 agent_type "UCD" cpu_coefficient "1.5" cpu_threshold "80" mem_coefficient "1.0" mem_threshold "70" disk_coefficient "2.0" disk_threshold "90" USEROID ".1.3.6.1.4.1.2021.4.6.0" USEROID_COEFFICIENT "1.0" USEROID_THRESHOLD "90" }' |
Figure 4.5 shows a monitor based on the snmp_dca_base monitor template. This monitor uses the default metric values. The values shown are default values, except for the value of USEROID, which is user-defined.
monitor my_snmp_dca_base '{ use snmp_dca_base interval 10 timeout 30 dest *:161 USEROID ".1.3.6.1.4.1.2021.4.6.0" USEROID_COEFFICIENT "1.0" USEROID_THRESHOLD "90" }' |
Note that in the preceding examples, the user-defined variables are specified as USEROID, USEROID_COEFICIENT, and USEROID_THRESHOLD. You can create any variable names you want. Although the values shown in the examples are entered in uppercase, uppercase is not required.
To configure a monitor based on either the snmp_dca or snmp_dca_base template, you can use either the Configuration utility or the bigpipe command.
The default agent type specified in the snmp_dca template is UC Davis. When configuring a monitor for a Windows 2000 server, you must change the agent type to Windows 2000.
To configure an SNMP monitor using the Configuration utility
- In the Navigation pane, click Monitors.
- Click the Add button.
This displays the Configure Monitor Name and Parent screen. - Enter a unique name for the monitor in the Name box and select a template from the Inherits from box.
- If you want the monitor to include CPU, memory, disk, and user metrics, select the snmp_dca template.
- If you want the monitor to include user metrics only, select the snmp_dca_base template.
- Click Next.
This displays the Configure Basic Properties screen. - Retain or change the values in the Interval and Timeout boxes.
- Click Next.
This displays the Configure EAV SNMP DCA Monitor screen. - Retain or change the values for CPU, memory, and disk use. Also note that in the snmp_dca template, the default value for the Agent Type property is UCD. To configure a monitor for a Windows 2000 agent, change this value to WIN2000.
- Click Next.
This displays the Configure EAV Variables screen. - If you are specifying user-defined metrics, configure the EAV variables by specifying a unique name and a value for each Name/Value pair.
The three variables (that is, Name/Value pairs) correspond to OID, coefficient, and threshold. Note that if the value of the OID variable is an absolute value, verify that the user-defined threshold value is also an absolute value. If the threshold value is not absolute, the BIG-IP system might not factor the value into the load calculation. The default user-defined threshold value is 90. - Click Next.
This displays the Configure Destination Address and Service (Alias) screen. We recommend that you use the default values shown here. - Click Done.
To configure an SNMP monitor using the bigpipe command
When configuring an SNMP monitor using the bigpipe command, you can use the default CPU, memory, and disk coefficient and threshold values specified in the templates, or you can change the default values. Optionally, you can specify coefficient and threshold values for gathering other types of data. Note that if the monitor you are configuring is for a type of SNMP agent other than UC Davis, you must specify the agent type as an argument to the bigpipe command.
The following command-line examples show various ways to configure an SNMP monitor. Note that although arguments for user-defined metrics are shown in uppercase, uppercase is not required.
To configure a monitor for a UC Davis SNMP agent, using default CPU, memory, and disk use values, use the bigpipe monitor command, as in the following example.
b monitor my_snmp_dca '{ use snmp_dca }'
To configure a monitor for a UC Davis SNMP agent, using all default CPU, memory threshold, and disk use values and specifying a non-default memory coefficient value, use the bigpipe monitor command, as in the following example.
b monitor my_snmp_dca '{ use snmp_dca mem_coefficient "1.5" }'
To configure a monitor for a UC Davis SNMP agent, using default CPU, memory threshold, and disk use values and specifying non-default memory coefficient and user values, use the bigpipe monitor command, as in the following example.
b monitor my_snmp_dca '{ use snmp_dca mem_coefficient "1.5" USEROID ".1.3.6.1.4" USEROID_COEFFICIENT "1.5" USEROID_THRESHOLD "80" }'
To configure a monitor for a UC Davis SNMP agent, omitting CPU, memory, and disk use values, and using default user coefficient and user threshold values (1.0 and 90 respectively), use the bigpipe monitor command, as in the following example.
b monitor my_snmp_dca '{ use snmp_dca_base USEROID ".1.3.6.1.4" }'
To configure a monitor for a UC Davis SNMP agent, omitting CPU, memory, and disk use values, and specifying non-default user values, use the bigpipe monitor command, as in the following example.
b monitor my_snmp_dca_base '{ use snmp_dca_base USEROID ".1.3.6.1.4" USEROID_COEFFICIENT/ "1.5" USEROID_THRESHOLD "80" }'
To configure a monitor for a Windows 2000 SNMP agent, using default CPU, memory, and disk use values, use the bigpipe monitor command, as in the following example.
b monitor my_win2000_snmp_dca '{ use snmp_dca agent_type "WIN2000" }'
To associate the health check monitor with the member node
Use the following syntax to associate the custom health check monitor with the server node and create an instance of the monitor for that node:
b node <node_addr> monitor use my_snmp_dca
To set the load balancing method to Dynamic Ratio
Use the following syntax to create or modify the load balancing pool to which the server belongs to use Dynamic Ratio load balancing:
b pool <pool_name> { lb_method dynamic_ratio <member definition>... }
Priority-based member activation
You can load balance traffic across all members of a pool or across only members that are currently activated according to their priority number. In priority-based member activation, each member in a pool is assigned a priority number that places it in a priority group designated by that number. With all nodes available (meaning they are enabled, marked up, and have not exceeded their connection limit), the BIG-IP system distributes connections to all nodes in the highest priority group only, that is, the group designated by the highest priority number. The min_active_members value determines the minimum number of members that must remain available for traffic to be confined to that group. If the number of available nodes in the highest priority group goes below the minimum number, the BIG-IP system also distributes traffic to the next higher priority group, and so on.
The configuration shown in Figure 4.6 has three priority groups, 3, 2, and 1. Connections are first distributed to all nodes with priority 3. If fewer than two priority 3 nodes are available, traffic is directed to the priority 2 nodes as well. If both the priority 3 group and the priority 2 group have fewer than two nodes available, traffic is directed to the priority 1 group as well. The BIG-IP system continuously monitors the higher priority groups, and each time a higher priority group once again has the minimum number of available nodes, the BIG-IP system again limits traffic to that group.
Setting persistence
If you are setting up an e-commerce or other type of transaction-oriented site, you might need to configure persistence on the BIG-IP system. Persistence is one of the pool attributes listed in Table 4.2 .
Whether you need to configure persistence or not depends on how you store client-specific information, such as items in a shopping cart or airline ticket reservations. For example, you might store the airline ticket reservation information in a back-end database that all nodes can access, or on the specific node to which the client originally connected, or in a cookie on the client's machine.
If you store client-specific information on specific nodes, you need to configure persistence. When you enable persistence, returning clients can bypass load balancing and instead can go to the node where they last connected in order to access their saved information.
The BIG-IP system tracks information about individual persistent connections, and keeps the information only for a given period of time. The way in which persistent connections are identified depends on the type of persistence assigned to the pool.
You enable persistence by assigning a persistence attribute to a pool, either through the Configuration utility or the bigpipe pool command. Two attributes are available for you to assign--the persist attribute (formerly known as the persist_mode attribute) and the select attribute.
Because the persist_mode attribute is backward-compatible, there is no need to change existing instances of the attribute name from persist_mode to persist in the bigip.conf file.
Persistence types
You can choose from several types of persistence when configuring a pool. The first type listed below, universal persistence, is the most flexible type of persistence. By including an expression in your pool definition, you can persistence on anything within the header or the content of a packet.
The other persistence types are pre-defined, meaning that the element on which the persistence is based cannot be changed.
The persistence types are:
- Universal persistence
Universal persistence allows you to write an expression that defines what to persist on in a packet. The expression, written using the same expression syntax that you use in rules, defines some sequence of bytes to use as a session identifier. - Simple persistence
Simple persistence supports TCP and UDP protocols, and tracks connections based only on the client IP address. - HTTP cookie persistence
HTTP cookie persistence uses an HTTP cookie stored on a client's computer to allow the client to reconnect to the same server previously visited at a web site. - SSL persistence
SSL persistence is a type of persistence that tracks SSL connections using the SSL session ID. Even when the client's IP address changes, the BIG-IP system still recognizes the connection as being persistent based on the session ID. - SIP Call-ID persistence
SIP persistence is a type of persistence used for proxy servers that receive Session Initiation Protocol (SIP) messages sent through UDP. SIP is a protocol that enables real-time messaging, voice, data, and video. - Destination address affinity (sticky persistence)
Destination address affinity directs requests for a certain destination to the same proxy server, regardless of which client the request comes from. - WTS persistence
Windows Terminal Server (WTS) persistence tracks connections between clients and servers in WTS client-server configurations.
All persistence methods are attributes of pools.
Table 4.7 lists the types of persistence, the attribute you assign to enable that persistence type, and the value you assign to the attribute.
Persistence Type |
Required Attribute |
Attribute Value |
---|---|---|
Universal |
persist or select |
<expression> |
Simple |
persist |
simple |
HTTP cookie |
persist |
cookie |
SSL |
persist |
ssl |
SIP Call-ID |
persist |
sip |
Destination Address Affinity (sticky) |
persist |
sticky |
WTS |
persist |
msrdp |
The following sections describe the various types of persistence.
Universal persistence
Universal persistence is based on a user-written expression within a pool definition that defines some sequence of bytes to use as a session identifier. Expressions defined for this type of persistence must be either a single function or variable name, or enclosed in parentheses. (For the complete syntax of expressions, see Chapter 5, iRules .)
Universal persistence allows you to persist on anything within the header or the content of a packet, or to directly specify the node (pool member) to which the pool should send a packet. The following sections describe these persistence types.
Directing traffic based on any data in the connection
By assigning the persist attribute to a pool, you can enable persistence based on any data that you specify within an expression. The expression can include one or more of the following functions.
Because these functions are part of the basic rules syntax, the parameters for these functions, and examples of their use, are fully described in Chapter 5, iRules .
- 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() - Parses the http_uri variable for an i-mode identifier string that can be used for i-mode persistence.
An example of this type of persistence is i-mode persistence. i-mode is a service that gives mobile phone users wireless Web browsing and email capabilities. i-mode persistence is implemented using a function that allows the BIG-IP system to perform persistence on an i-mode session identifier in the query of string of a URI. Using this persistence type eliminates the need to establish a predefined relationship between a session identifier and a pool.
Two different search strings could result in the two return strings being hashed to the same key, and stored as one key in the hash table. If this happens, one of the two requests could persist to the wrong pool member. To avoid this problem, make sure that you write expressions that return unique string values.
Figure 4.7 shows an example of /etc/bigip.conf file entries for persistence based on expressions used as hashes for pool members. Note that this example includes an entry for i-mode persistence.
To enable persistence for pools based on any data in a connection using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - Select the pool for which you want to configure simple persistence.
The Pool Properties screen opens. - Click the Persistence tab.
The Persistence Properties screen opens. - In the Persistence Type section, click the Expression button.
Type the following information:
- Timeout (seconds)
Set the number of seconds for persistence on the pool. (This option is not available if you are using rules.) - Expression
Using the allowed rule functions, type an expression that defines the data on which to persist in the connection.
- Timeout (seconds)
- Click the Apply button.
To enable persistence based on any data in a connection from the command line
To enable a pool to direct traffic to a specific node, use the following command line syntax:
b pool <pool_name> modify ( persist <expr> persist_timeout <timeout> )
For detailed descriptions of the functions that specify any data in a connection, see Chapter 5, iRules .
Directing traffic to a specific node
By assigning the select attribute to a pool, you can specify an expression that returns the node address of a pool member. This type of expression includes one of the following functions.
Because these functions are part of the basic rules syntax, the parameters for these functions, and examples of their use, are fully described in Chapter 5, iRules .
- node() - Returns a literal node address converted from either a string representation of an address and port or a literal number representing the node address as an integer.
- mapclass2node - Represents a short-hand combination of the functions findclass(), findstr(), and node().
- wlnode() - Returns a literal node address converted from either a string representation of an address and port, a literal number representing the node address as an integer, or a literal node address.
Figure 4.8 shows an example of the /etc/bigip.conf file entries that show expressions that select specific node addresses for persistence.
To enable persistence by selecting a specific node using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the pool name for which you want to configure simple persistence.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence Properties screen opens. - In the Node Select Expression box, type an expression that defines a specific node.
- Click the Apply button.
To enable persistence by selecting a specific node from the command line
To enable a pool to direct traffic to a specific node, use the following command line syntax:
b pool <pool_name> modify ( select <expr> )
For detailed descriptions of the functions that directly select a node, see Chapter 5, iRules .
Simple persistence
Simple persistence tracks connections based only on the client IP address. When a client requests a connection to a virtual server that supports simple persistence, the BIG-IP system checks to see if that client previously connected, and if so, returns the client to the same node.
You might want to use SSL persistence and simple persistence together. In situations where an SSL session ID times out, or where a returning client does not provide a session ID, you may want the BIG-IP system to direct the client to the original node based on the client's IP address. As long as the client's simple persistence record has not timed out, the BIG-IP system can successfully return the client to the appropriate node.
Persistence settings for pools apply to all protocols. When the persistence timer is set to a value greater than 0, persistence is on. When the persistence timer is set to 0, persistence is off.
To configure simple persistence for pools using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the pool name for which you want to configure simple persistence.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence Properties screen opens. - In the Persistence Type section, click the Simple button.
Type the following information:
- Timeout (seconds)
Set the number of seconds for persistence on the pool. (This option is not available if you are using rules.) - Mask
Set the persistence mask for the pool. The persistence mask determines persistence based on the portion of the client's IP address that is specified in the mask.
- Timeout (seconds)
- Click the Apply button.
To configure simple persistence for pools from the command line
You can use the bigpipe pool command with the modify keyword to set simple persistence for a pool. Note that a timeout greater than 0 turns persistence on, and a timeout of 0 turns persistence off.
b pool <pool_name> modify {persist simple simple_timeout <timeout> simple_mask <ip_mask>}
For example, if you want to set simple persistence on the pool my_pool, type the following command:
b pool my_pool modify { persist simple simple_timeout 3600 simple_mask 255.255.255.0 }
Using a simple timeout and a persist mask on a pool
The persist mask feature works only on pools that implement simple persistence. By adding a persist mask, you identify a range of client IP addresses to manage together as a single simple persistent connection when connecting to the pool.
To apply a simple timeout and persist mask using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pools list, click the pool for which you want to set up simple persistence.
The properties screen opens. - Click the Persistence tab.
The Persistence screen opens. - Select Simple mode.
- In the Timeout box, type the timeout in seconds.
- In the Mask box, type the persist mask you want to apply.
- Click the Apply button.
To apply a simple timeout and persist mask from the command line
The complete syntax for the command is:
b pool <pool_name> modify { [<lb_mode_specification>] persist simple simple_timeout \ <timeout> simple_mask <dot_notation_longword> }
For example, the following command would keep persistence information together for all clients within a C class network that connect to the pool my_pool:
b pool my_pool modify { persist simple simple_timeout 1200 simple_mask 255.255.255.0 }
You can turn off a persist mask for a pool by using the none option in place of the simple_mask mask. To turn off the persist mask that you set in the preceding example, use the following command:
b pool my_pool modify { simple_mask none }
To display all persistence information for the pool named my_pool, use the show option:
b pool my_pool persist show
HTTP cookie persistence
You can set up the BIG-IP system to use HTTP cookie persistence. This method of persistence uses an HTTP cookie stored on a client's computer to allow the client to reconnect to the same server previously visited at a web site.
There are four types of cookie persistence available:
- Insert mode
- Rewrite mode
- Passive mode
- Hash mode
Insert mode
If you specify Insert mode, the information about the server to which the client connects is inserted in the header of the HTTP response from the server as a cookie. The cookie is named BIGipServer<pool_name>, and it includes the address and port of the server handling the connection. The expiration date for the cookie is set based on the timeout configured on the BIG-IP system.
To activate Insert mode using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the pool name for which you want to set up Insert mode.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence screen opens. - Click the Active HTTP Cookie button.
- Select Insert mode from the Method list.
- Type the timeout value in days, hours, minutes, and seconds. This value determines how long the cookie lives on the client computer before it expires.
- Click the Apply button.
To activate Insert mode from the command line
To activate Insert mode from the command line, use the following syntax:
b pool <pool_name> { <lb_mode_specification> persist cookie cookie_mode insert \ cookie_expiration <timeout> <member definition> }
The <timeout> value for the cookie is written as <days>d hh:mm:ss.
Rewrite mode
If you specify Rewrite mode, the BIG-IP system intercepts a Set-Cookie, named BIGipCookie, sent from the server to the client, and overwrites the name and value of the cookie. The new cookie is named BIGipServer <pool_name> and it includes the address and port of the server handling the connection.
Rewrite mode requires you to set up the cookie created by the server. In order for Rewrite mode to work, there needs to be a blank cookie coming from the web server for the BIG-IP system to rewrite. With Apache variants, the cookie can be added to every web page header by adding an entry in the httpd.conf file:
Header add Set-Cookie BIGipCookie=0000000000000000000000000...
(The cookie must contain a total of 120 zeros.)
For backward compatibility, the blank cookie may contain only 75 zeros. However, cookies of this size do not allow you to use rules and persistence together.
To activate Rewrite mode cookie persistence using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the pool name for which you want to set up Rewrite mode.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence screen opens. - Click the Active HTTP Cookie button.
- Select Rewrite mode from the Method list.
- Type the timeout value in days, hours, minutes, and seconds. This value determines how long the cookie lives on the client computer before it expires.
- Click the Apply button.
To activate Rewrite mode cookie persistence from the command line
To activate Rewrite mode from the command line, use the following syntax:
b pool <pool_name> { <lb_mode_specification> persist cookie cookie_mode rewrite cookie_expiration <timeout> <member definition> }
The <timeout> value for the cookie is written using the following format:
<days>d hh:mm:ss
Passive mode
If you specify Passive mode, the BIG-IP system does not insert or search for blank Set-Cookies in the response from the server. It does not try to set up the cookie. In this mode, the server provides the cookie formatted with the correct node information and timeout.
In order for Passive mode to work, there needs to be a cookie coming from the web server with the appropriate node information in the cookie. With Apache variants, the cookie can be added to every web page header by adding an entry in the httpd.conf file:
Header add Set-Cookie: "BIGipServer my_pool=184658624.20480.000; expires=Sat, 19-Aug-2002 19:35:45 GMT; path=/"
In this example, my_pool is the name of the pool that contains the server node, 184658624 is the encoded node address and 20480 is the encoded port. You can generate a cookie string with encoding automatically added using the bigpipe makecookie command:
b makecookie <server_address:service> [ > <file> ]
The command above prints a cookie template, similar to the following two examples below, to the screen or the redirect file specified.
Set-Cookie:BIGipServer[poolname]=336268299.20480.0000; path=/
Set-Cookie:BIGipServer[poolname]=336268299.20480.0000; expires=Sat, 01-Jan-2002 00:00:00 GMT; path=/
To create your cookie from this string, type the actual pool names and the desired expiration date and time.
Alternatively, you can perform the encoding using the following equation for address (a.b.c.d):
d*(256^3) + c*(256^2) + b*256 +a
The way to encode the port is to take the two bytes that store the port and reverse them. So, port 80 becomes 80 * 256 + 0 = 20480. Port 1433 (instead of 5 * 256 + 153) becomes 153 * 256 + 5 = 39173.
To activate Passive mode cookie persistence using the Configuration utility
After you set up the cookie created by the web server, you must activate Passive mode on the BIG-IP system.
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pools Name list, click the pool name for which you want to set up Passive mode.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence screen opens. - Select Passive HTTP Cookie mode.
- Click the Apply button.
To activate Passive mode cookie persistence from the command line
After you set up the cookie created by the web server, you must activate Passive mode on the BIG-IP system. To activate HTTP cookie persistence from the command line, use the following syntax:
b pool <pool_name> { <lb_mode_specification> persist cookie cookie_mode passive <member \ definition> }
Passive mode does not require a <timeout> value.
Hash mode
If you specify hash mode, the hash mode consistently maps a cookie value to a specific node. When the client returns to the site, the BIG-IP system uses the cookie information to return the client to a given node. With this mode, the web server must generate the cookie. The BIG-IP system does not create the cookie automatically as it does with Insert mode.
To configure the cookie persistence hash option using the Configuration utility
Before you follow this procedure, you must configure at least one pool.
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the pool name for which you want to set up hash mode persistence.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence screen opens. - Click the Cookie Hash button.
Set the following values (see Table 4.8 for more information):
- Cookie Name
Type the name of an HTTP cookie being set by the Web site. This could be something like Apache or SSLSESSIONID. The name depends on the type of web server your site is running. - Hash Values
The Offset is the number of bytes in the cookie to skip before calculating the hash value. The Length is the number of bytes to use when calculating the hash value.
- Cookie Name
- Click the Apply button.
To configure the hash cookie persistence option from the command line
Use the following syntax to configure the hash cookie persistence option:
b pool <pool_name> { <lb_mode_specification> persist cookie cookie_mode hash \
cookie_name <cookie_name> cookie_hash_offset <cookie_value_offset> \ cookie_hash_length <cookie_value_length> <member definition> }
The <cookie_name>, <cookie_value_offset>, and <cookie_value_length> values are described in Table 4.8 .
Hash mode values |
Description |
---|---|
<cookie_name> |
This is the name of an HTTP cookie being set by a Web site. |
<cookie_value_offset> |
This is the number of bytes in the cookie to skip before calculating the hash value. |
<cookie_value_length> |
This is the number of bytes to use when calculating the hash value. |
SSL persistence
SSL persistence is a type of persistence that tracks SSL connections using the SSL session ID, and it is a property of each individual pool. Using SSL persistence can be particularly important if your clients typically have translated IP addresses or dynamic IP addresses, such as those that Internet service providers typically assign. Even when the client's IP address changes, the BIG-IP system still recognizes the connection as being persistent based on the session ID.
You may want to use SSL persistence and simple persistence together. In situations where an SSL session ID times out, or where a returning client does not provide a session ID, you may want the BIG-IP system to direct the client to the original node based on the client's IP address. As long as the client's simple persistence record has not timed out, the BIG-IP system can successfully return the client to the appropriate node.
You can set up SSL persistence from the command line or using the Configuration utility. To set up SSL persistence, you need to do two things:
- Turn SSL persistence on.
- Set the SSL session ID timeout, which determines how long the BIG-IP system stores a given SSL session ID before removing it from the system.
Do not use the SSL persistence attribute to enable persistence on pools that load balance traffic resulting from SSL proxies on which SSL termination is enabled. To enable persistence for connections terminated by an SSL proxy, see Chapter 7, SSL Accelerator Proxies .
To activate SSL persistence from the command line
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the appropriate pool name.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence screen opens. - Click the SSL button.
- In the Timeout box, type the number of seconds that the BIG-IP system should store SSL session IDs before removing them from the system.
- Click the Apply button.
To activate SSL persistence from the command line
Use the following syntax to activate SSL persistence from the command line:
b pool <pool_name> modify { persist ssl ssl_timeout <timeout> }
For example, if you want to set SSL persistence on the pool my_pool, type the following command:
b pool my_pool modify { persist ssl ssl_timeout 3600 }
To display persistence information for a pool
To show the persistence configuration for the pool:
b pool <pool_name> persist show
To display all persistence information for the pool named my_pool, use the show option:
b pool my_pool persist show
SIP Call-ID persistence
Session Initiation Protocol (SIP) is an application-layer protocol that manages sessions consisting of multiple participants, thus enabling real-time messaging, voice, data, and video. With SIP, applications can communicate with one another by exchanging messages through TCP or UDP. Examples of such applications are internet conferencing and telephony, or multimedia distribution.
SIP Call-ID persistence is a new type of persistence available for server pools. You can configure Call-ID persistence for proxy servers that receive Session Initiation Protocol (SIP) messages sent through UDP.
The BIG-IP system currently supports persistence for SIP messages sent through UDP only.
When activating SIP Call-ID persistence for a server pool, you can specify the following:
- The name of the server pool (required)
- A timeout value for persistence records (optional)
To activate SIP Call-ID persistence, you can use either the Configuration utility or the bigpipe pool command.
To activate SIP persistence using the Configuration utility
- Start the Configuration utility.
- In the Navigation pane, click Pools.
The Pools screen opens. - Select a pool name.
- Click the Persistence tab.
- Click the button for SIP persistence.
- Click the Apply button.
To activate SIP persistence from the command line
Use the following syntax to activate SIP Call-ID persistence from the command line.
bigpipe pool <pool name> { persist sip [sip_timeout <timeout>] }
To display the contents of the hash table
To display the contents of the SIP persistence hash table, use the bigpipe command as follows:
bigpipe sip dump
Destination address affinity (sticky persistence)
You can optimize your proxy server array with destination address affinity (also called sticky persistence). Destination address affinity directs requests for a certain destination IP address to the same proxy server, regardless of which client the request comes from.
This enhancement provides the most benefits when load balancing caching proxy servers. A caching proxy server intercepts web requests and returns a cached web page if it is available. In order to improve the efficiency of the cache on these proxies, it is necessary to send similar requests to the same proxy server repeatedly. Destination address affinity can be used to cache a given web page on one proxy server instead of on every proxy server in an array. This saves the other proxies from having to duplicate the web page in their cache, wasting memory.
To activate destination address affinity using the Configuration utility
You can only activate destination address affinity on pools directly or indirectly referenced by wildcard virtual servers. For information on setting up a wildcard virtual server, see Chapter 6, Virtual Servers . Follow these steps to configure destination address affinity.
- In the navigation pane, click Pools.
The Pools screen opens. - In the Pool Name list, click the pool name for which you want to set up destination address affinity.
This displays the properties of that pool. - Click the Persistence tab.
The Persistence screen opens. - Click the Destination Address Affinity button to enable destination address affinity.
- In the Mask box, type in the mask you want to apply to sticky persistence entries.
- Click the Apply button.
To activate destination address affinity from the command line
Use the following command to activate sticky persistence for a pool:
b pool <pool_name> modify { persist sticky sticky_mask <ip address> }
Use the following command to delete sticky entries for the specified pool:
b pool <pool_name> sticky clear
To show the persistence configuration for the pool:
b pool <pool_name> persist show
WTS persistence
This release includes an updated version of the BIG-IP system Windows Terminal Server (WTS) persistence feature. WTS persistence provides an efficient way of load balancing traffic and maintaining persistent connections between Windows® clients and servers that are running the Microsoft® Terminal Services service. The recommended scenario for enabling the BIG-IP system WTS persistence feature is to create a load balancing pool that consists of members running Windows .NET Server 2003, Enterprise Edition, where all members belong to a Windows cluster and participate in a Windows session directory.
Servers running Windows .NET Server 2003, Enterprise Edition, with the Terminal Services service enabled, are referred to in this chapter as Terminal Servers.
Benefits of WTS persistence
Without WTS persistence, Windows Terminal Servers, when participating in a session directory, map clients to their appropriate servers, using redirection when necessary. If a client connects to the wrong server in the cluster, the targeted server checks its client-server mapping and performs a redirection to the correct server.
When BIG-IP system WTS persistence is enabled, however, a Windows Terminal Server participating in a session directory always redirects the connection to the same BIG-IP virtual server, instead of to another server directly. The BIG-IP system then sends the connection to the correct Windows Terminal Server. Also, when WTS persistence is enabled on a BIG-IP system and the servers in the pool participate in a session directory, the BIG-IP system load balances a Terminal Services connection according to the way that the user has configured the BIG-IP system for load balancing. Thus, the use of Windows Terminal Servers and the Session Directory service, combined with the BIG-IP WTS persistence feature, provides more sophisticated load balancing and more reliable reconnection when servers become disconnected.
Server Platform issues
By default, the BIG-IP system with WTS persistence enabled load balances connections according to the way that the user has configured the BIG-IP system for load balancing, as long as Session Directory is configured on each server in the pool. Because Session Directory is a new feature that is only available on Windows .NET Server 2003, Enterprise Edition platforms, each server in the pool must therefore be a Windows .NET Server 2003, Enterprise Edition server if you want to use WTS persistence in default mode. Also, each client system must be running the remote desktop client software that is included with any .NET Enterprise server or Windows XP system.
If, however, you want to enable WTS persistence but your server platforms are running older versions of Windows (on which Session Directory is not available), you can enable WTS persistence in non-default mode. This causes the BIG-IP system to connect a client to the same Windows server by way of the user name that the client provides. You can enable WTS persistence in this way by setting a global variable on the BIG-IP system, called msrdp no_session_dir, which disables Session Directory on any pool created with the msrdp attribute. Note that enabling WTS persistence in non-default mode (that is, with no Session Directory available on the servers) is less preferable than the default mode, because it provides limited load-balancing and redirection capabilities.
The following sections describe how to enable WTS persistence with and without Windows Session Directory.
Configuring WTS persistence with Session Directory
To enable WTS persistence in the default mode, you must configure Session Directory on each Windows Terminal Server in your load balancing pool. In addition to configuring Session Directory, you must perform other Windows configuration tasks on those servers. However, before you configure your Windows Terminal Servers, you must configure your BIG-IP system, by performing tasks such as creating a load-balancing pool and designating your Windows Terminal Servers as members of that pool.
The following two sections describe the BIG-IP system configuration tasks that are required to enable WTS persistence in default mode for a Windows client-sever configuration running Windows Terminal Services.
Configuring WTS persistence on the BIG-IP system
To configure WTS persistence on the BIG-IP system, you must perform the following tasks.
- Enable TCP service 3389
- Create a pool with WTS persistence enabled
- Create a virtual server
The following sections describe these tasks.
To enable TCP service 3389
To enable TCP service 3389, use the following command:
b service 3389 tcp enable
Optionally, you can map this port from 3389 to 443 in order to allow traffic to pass more easily through a firewall.
To create a pool with WTS persistence enabled
To create a pool that is configured for WTS persistence, use the bigpipe pool command, as in the following example. Remember that the pool members must already be members of a Windows cluster.
b pool my_cluster_pool { persist msrdp member 11.12.1.101:3389 member 11.12.1.100:3389 }
To create a virtual server
To create a virtual server that uses the pool my_cluster_pool, use the bigpipe virtual command, as in the following example:
b virtual 192.200.100.25:3389 use pool my_cluster_pool
Configuring WTS persistence without Session Directory
When a server has no Session Directory, the server cannot share sessions with other servers, and therefore cannot perform any redirections when a connection to a server becomes disconnected. In lieu of session sharing, Windows clients provide data, in the form of a user name, to the BIG-IP system to allow the BIG-IP system to consistently connect that client to the same server. Enabling WTS persistence to behave in this way is the non-default mode.
To configure WTS persistence when the servers do not have Session Directory
- Perform the BIG-IP system configuration tasks that are described in Configuring WTS persistence on the BIG-IP system .
- Set a BIG-IP system global variable, msrdp no_session_dir. Setting this global variable disables Session Directory on all pools on which the msrdp attribute is set. To set the msrdp no_session_dir global variable, use the following command-line syntax:
b global msrdp no_session_dir enable
- Verify that the Terminal Services service is running on each Windows server in your load-balancing pool.
To implement WTS persistence, you must also configure your Windows Terminal Servers. For more information, see the BIG-IP Solutions Guide.
Persistence options
When setting up persistence, you can enable either of the following two options:
- Persistence across virtual servers with the same address
Persistence across virtual servers with the same address causes the BIG-IP system to maintain persistence only when the virtual server hosting the connection has the same virtual address as the virtual server hosting the initial persistent connection. - Persistence across all virtual servers
Persistence across all virtual servers causes the BIG-IP system to maintain persistence for all connections requested by the same client, regardless of which virtual server hosts each individual connection initiated by the client.
The following two sections describe these two persistence options.
Maintaining persistence across virtual servers that use the same virtual addresses
When this mode is turned on, the BIG-IP system attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same node only when the virtual server hosting the connection has the same virtual address as the virtual server hosting the initial persistent connection. Connection requests from the client that go to other virtual servers with different virtual addresses, or those connection requests that do not use persistence, are load balanced according to the load balancing method defined for the pool.
A BIG-IP system configuration could include the following virtual server mappings, where the virtual server v1:http references the http_pool (contains the nodes n1:http and n2:http) and the virtual server v1:ssl references the pool ssl_pool (contains the nodes n1:ssl and n2:ssl). Each virtual server uses persistence:
b virtual v1:http use pool http_pool
b virtual v1:ssl use pool ssl_pool
b virtual v2:ssl use pool ssl_pool
However, if the client subsequently connects to v1:ssl, the BIG-IP system uses the persistence session established with the first connection to determine the node that should receive the connection request, rather than the load balancing method. The BIG-IP system should send the third connection request to n1:ssl, which uses the same node address as the n1:http node that currently hosts the client's first connection with which it shares a persistent session.
For example, a client makes an initial connection to v1:http and the load balancing mechanism assigned to the pool http_pool chooses n1:http as the node. If the same client then connects to v2:ssl, the BIG-IP system starts tracking a new persistence session, and it uses the load balancing method to determine which node should receive the connection request because the requested virtual server uses a different virtual address (v2) than the virtual server hosting the first persistent connection request (v1). In order for this mode to be effective, virtual servers that use the same virtual address, as well as those that use TCP or SSL persistence, should include the same node addresses in the virtual server mappings.
To activate persistence for virtual servers that use the same address using the Configuration utility
- In the navigation pane, click System.
The Network Map screen opens. - Click the Advanced Properties tab.
The BIG-IP System Control Variables screen opens. - Click the Allow Persistence Across All Ports for Each Virtual Address check box. (To disable this persistence mode, clear the check box.)
- Click the Apply button.
To activate persistence for virtual servers that use the same address from the command line
The global variable persist_across_services turns this mode on and off.
To activate the persistence mode, type:
b global persist_across_services enable
To deactivate the persistence mode, type:
b global persist_across_services disable
Maintaining persistence across all virtual servers
You can set the BIG-IP system to maintain persistence for all connections requested by the same client, regardless of which virtual server hosts each individual connection initiated by the client. When this mode is turned on, the BIG-IP system attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same node. Connection requests from the client that do not use persistence are load balanced according to the currently selected load balancing method.
The following examples show virtual server mappings, where the virtual servers v1:http and v2:http reference the http1_pool and http2_pool (both pools contain the nodes n1:http and n2:http) and the virtual servers v1:ssl and v2:ssl reference the pools ssl1_pool and ssl2_pool (both pools contain the nodes n1:ssl and n2:ssl). Each virtual server uses persistence:
b virtual v1:http use pool http1_pool
b virtual v1:ssl use pool ssl1_pool
b virtual v2:http use pool http2_pool
b virtual v2:ssl use pool ssl2_pool
For example, suppose that a client makes an initial connection to v1:http, and the BIG-IP system load balancing mechanism chooses n1:http as the node. If the same client subsequently connects to v1:ssl, the BIG-IP system would send the client's request to n1:ssl, which uses the same node address as the n1:http node that currently hosts the client's initial connection. What makes this mode different from maintaining persistence across virtual servers that use the same virtual address, is that if the same client subsequently connects to v2:ssl, the BIG-IP system would send the client's request to n1:ssl, which uses the same node address as the n1:http node that currently hosts the client's initial connection.
In order for this mode to be effective, virtual servers that use pools with TCP or SSL persistence should include the same member addresses in the virtual server mappings.
To activate persistence across all virtual servers using the Configuration utility
- In the navigation pane, click the System icon.
The Network Map screen opens. - Click the Advanced Properties tab.
The BIG-IP System Control Variables screen opens. - Click the Allow Persistence Across All Virtual Servers check box to activate this persistence mode.
- Click the Apply button.
To activate persistence across all virtual servers from the command line
The global variable persist_across_virtuals turns this mode on and off.
To activate the persistence mode, type:
b global persist_across_virtuals enable
To deactivate the persistence mode, type:
b global persist_across_virtuals disable
Redirecting HTTP requests
Another attribute of a pool is HTTP redirection. HTTP redirection allows you to configure a pool so that HTTP traffic is redirected to another protocol identifier, host name, port number, or URI path. For example, if all members of a pool are unavailable (that is, the members are disabled, marked down, and have exceeded their connection limit), the HTTP request can be redirected to the fallback host, with the HTTP reply Status Code 302 Found.
When configuring a pool to redirect HTTP traffic to a fallback host, you can use an IP address or a fully-qualified domain name (FQDN), or you can use a special format string included in the BIG-IP system. These format strings can also be used for specifying protocol identifiers, ports, and URIs.
The following two sections describe these two ways of redirecting HTTP requests. Following these two sections is a description of a related feature, which allows you to configure a server to rewrite the specified HTTP redirection.
Using IP addresses and fully qualified domain names
When redirecting traffic to a fallback host, you can specify the fallback host as an IP address or as a fully qualified domain name (FQDN). In either case, it may include a port number. The example in Figure 4.9 redirects the request to http://redirector.siterequest.com.
pool my_pool { fallback "redirector.siterequest.com" member 10.12.10.1:80 member 10.12.10.2:80 member 10.12.10.3:80 } |
The HTTP redirect mechanism is not a load balancing method. The redirect URL may be a virtual server pointing to the requested HTTP content, but this is not implicit in its use.
Table 4.9 shows how different fallback host specifications are resolved.
Requested URL |
Fallback Host Specification |
Redirect URL |
---|---|---|
http://www.siterequest.com/ |
fallback.siterequest.com |
http://falback.siterequest.com/ |
http://www.siterequest.com/ |
fallback.siterequest.com:8002 |
http://fallback.siterequest.com:8002/ |
http://www.siterequest.com:8001 |
fallback.siterequest.com |
http://fallback.siterequest.com/ |
http://www.siterequest.com:8001/ |
fallback.siterequest.com:8002 |
http://fallback.siterequest.com:8002/ |
http://www.siterequest.com/sales |
fallback.siterequest.com |
http://fallback.siterequest.com/sales |
http://192.168.101.3/ |
fallback.siterequest.com |
http://fallback.siterequest.com/ |
http://192.168.101.3/sales |
fallback.siterequest.com |
http://fallback.siterequest.com/sales |
http://www.siterequest.com/sale |
192.168.101.5 |
http://192.168.101.5/sales |
http://192.168.101.3/sales/default.asp?q=6 |
fallback.siterequest.com |
http://fallback.siterequest.com/sales/default.asp?q=6 |
Using format strings (expansion characters)
To allow HTTP redirection to be fully configurable with respect to target URI, the following format strings are available. These strings can be used within both pools and rules. (For more information on using HTTP redirection format strings within rules, see Chapter 5, iRules .)
Table 4.10 lists and defines the format strings that you can use to specify HTTP redirection.
Format String |
Description |
---|---|
%h |
host name, as obtained from the Host: header of the client |
%p |
Port, from the virtual server listening port |
%u |
URI path, as obtained from a GET/POST request |
An example of a fallback host string is https://%h/sample.html. In this string, specifying https as the protocol identifier causes the traffic to be redirected to that protocol instead of the standard http protocol. Also, the string sample.html causes the traffic to be redirected to that URI instead of to the standard URI specified in the HTTP header, which would normally be represented in the fallback string as %u.
Table 4.11 shows some sample redirection specifications, their explanations, and their resulting redirection.
Redirection string |
Explanation |
Resulting redirection |
---|---|---|
%h:%p/%u |
No redirection (preserve host name, port, and path) |
http://www.siterequest.com:8080/sample |
%h/unavailable |
change path, remove port |
http://www.siterequest.com/unavailable |
https://%h/unavailable |
Specify https as protocol, remove port, change path |
https://www.siterequest.com/unavailable |
www.siterequest.com:8080/%u |
Change host name and port, preserve path |
http://www.siterequest.com:8080/sample |
https://1.2.3.4:443/%u/unavilable.html |
Specify https as protocol, change host name, port, and path |
https://1.2.3.4:443/sample/unavailable.html |
ftp://1.2.3.4:%p/unavailable/%u |
Specify ftp as protocol, change host name and path |
ftp://1.2.3.4:8080/unavailable/sample |
rtsp://%h:554/streamingmedia/%u |
Specify rtsp as protocol, change port and path |
rtsp://www.siterequest.com:554/streamingmedia/sample |
The example in Figure 4.10 shows a pool configured to redirect an HTTP request to a different protocol (https) host name (1.2.3.4), port number (443), and path (unavailable.html).
pool my_pool { |
Rewriting HTTP redirection
Sometimes, a client request is redirected from the HTTPS protocol to the HTTP protocol, which is a non-secure channel. If you want to ensure that the request remains on a secure channel, you can cause that redirection to be rewritten so that it is redirected back to the HTTPS protocol. Also, through the rewriting of redirections, you can rewrite a port number or a URI path.
You can rewrite HTTP redirections in either of two ways:
- You can create an SSL Accelerator proxy and configure the rewriting of HTTP redirections as a proxy option. For more information, see Chapter 7, SSL Accelerator Proxies .
- If your web server is an IIS server, you can configure that server, instead of your SSL proxy, to rewrite any HTTP redirections. Part of this IIS server configuration includes the installation of a special BIG-IP system filter, redirectfilter.dll, on the IIS server. The following section provides this IIS configuration procedure.
To install the filter for rewriting HTTP redirection
To install the ISAPI filter (redirectfilter.dll) for use with a Microsoft Internet Information Server (IIS) version 4.0 or 5.0, follow these steps.
- Copy the filter DLL to an appropriate folder, such as the SCRIPTS or CGI-BIN subdirectory.
- Open the Internet Service Manager (MMC).
- Select the appropriate level for the ISAPI filter:
- If you intend to use the ISAPI filter with all Web sites, select the ServerName icon.
- If you intend to use the ISAPI filter with a specific Web site, select the icon for that Web site (for example, the default Web site).
- Right-click the level (icon) that you selected.
- Select Properties from the displayed menu.
- Click the ISAPI Filters tab.
Note: To configure an ISAPI filter for all Web sites, first click the Edit button that is next to the Master Properties of the WWW Service.
- Click Add.
- Type a name for the ISAPI filter.
- Click Browse and select the ISAPI filter that you copied in step 1.
- Click OK.
- Stop the IISADMIN service. To do this, either type net stop iisadmin /y at a command prompt, or use the Services applet that is located in Control Panel (in Windows NT 4.0) or Administrative Tools (in Windows 2000).
- Start the World Wide Web Publishing Service by typing net start w3svc at a command prompt, or by using the Services applet that is located in Control Panel (in Windows NT 4.0) or Administrative Tools (in Windows 2000).
- Repeat the previous step for any other services that were stopped in step 11.
- Browse back to the ISAPI Filters tab (by following steps 1-5) and verify that the filter is loaded properly. You should see a green arrow that is pointing up under the Status column.
The ISAPI Filters tab specifies a load order, with the filter at the top of the list loading first. Normally Sspifilt.dll, the ISAPI filter for SSL, is at the top of the list to allow any other filters to access data before IIS encrypts and transmits or decrypts and receives TTPS traffic.
Inserting and erasing HTTP headers
When configuring a pool, you can set options to either insert headers into HTTP requests or erase the content of headers from HTTP requests. You configure these options using the pool attributes header insert and header erase. The following section describe these attributes.
Inserting headers into HTTP requests
An optional attribute of a pool is HTTP header insertion. Using this attribute, you can configure a pool to insert a header into an HTTP request. The HTTP header being inserted can include a client IP address. Including a client IP address in an HTTP header is useful when a connection goes through a secure network address translation (SNAT) and you need to preserve the original client IP address.
The header insertion must be specified in the pool definition as a quoted string. Optionally, you can include rule variables in the quoted string. For example, the pool definition shown in Figure 4.11 uses the rule variable client_addr to represent the original client IP address of an HTTP request.
pool my_pool { header insert "OrigClientAddr:${client_addr}" member 10.0.0.1:80 member 10.0.0.2:80 member 10.0.0.3:80 } |
The rule variables that can be used for header insertion are:
- client_addr
- client_port
- server_addr
- server_port
- link_qos
- ip_qos
For more information on these rule variables, see Chapter 5, iRules .
Figure 4.12 shows a pool that inserts a header, using all of the above rule variables.
The above header insertion string inserts the following header into an HTTP request.
GET /index.html HTTP/1.0 ClientSide: 10.0.0.1:3340 -> 10.0.0.101:80 tos=16 qos=0 Host: www.yahoo.com Connection: Keep-Alive |
If the rule variable specified is not a valid variable, the invalid variable name is inserted directly into the HTTP request, with no substitution.
In addition to inserting a client IP address into an HTTP request, you can configure an SSL Accelerator proxy to insert other types of headers into HTTP requests. Examples of headers that an SSL proxy can insert are: information on client certificates, cipher specifications, and client session IDs. For more information on rule variables and on configuring an SSL proxy to insert headers into HTTP requests, see Chapter 5, iRules and Chapter 7, SSL Accelerator Proxies .
To insert a header into an HTTP request using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - Click the Add button.
The Add Pool screen opens. - In the Add Pool screen, type a string into the Header Insert box.
- Click Done.
To insert a header from the command line
To insert a header from the command line, use the following syntax, where <quoted string> is the header to insert:
b pool <pool_name> header insert <quoted string>
Erasing header content from HTTP requests
Another optional attribute of a pool is the header erase attribute. Using this attribute, you can configure a pool to erase the contents of a header from an HTTP client request. When you use this attribute, the BIG-IP system erases the contents of the specified header and replaces that content with blank spaces. The header itself is retained.
With this feature, you can erase headers from HTTP requests before forwarding the requests over the network. Such headers might contain sensitive information, such as user IDs or telephone numbers, that must be erased before the information is forwarded.
The client header with the contents to be erased must be specified in the pool definition as a quoted string.
To erase the contents of a client header using the Configuration utility
- In the navigation pane, click Pools.
The Pools screen opens. - Click the Add button.
The Add Pool screen opens. - In the Add Pool screen, type a header name into the Header to Erase box.
- Click Done.
To erase the contents of a client header from the command line
To erase the contents of a header from the command line, use the following syntax, where <quoted string> is the name of the header:
b pool <pool_name> header erase <quoted string>
Configuring the Quality of Service (QoS) level
Another attribute of a pool is the Quality of Service (QoS) level. The QoS level is a means by which network equipment can identify and treat traffic differently based on an identifier. As traffic enters the site, the BIG-IP system can set the QoS level on a packet, based on the QoS level defined in the pool to which the packet is sent. The BIG-IP system can also apply a rule that sends the traffic to different pools of servers based on the Quality of Service level.
The BIG-IP system can tag outbound traffic (the return packets based on an HTTP GET) based on the QoS value set in the pool. That value is then inspected by upstream devices and given appropriate priority. Based on a rule, the BIG-IP system can examine incoming traffic to see if it has a particular QoS or ToS tag in the header. The BIG-IP system can then make a rule-based load balancing decision based on that tag.
Figure 4.14 shows how to configure a pool so that a QoS level is set for a packet sent to that pool. In this example, the QoS tag, represented by the link_qos variable, is set to 3 when sending packets to the client, and set to 4 when packets are sent to the server.
pool http_pool { link_qos to client 3 link_qos to server 4 } |
In addition to configuring a pool to set the QoS level on a packet, you can configure a rule that selects a pool based on the existing QoS value within the packet. For more information, see Chapter 5, iRules .
Configuring the Type of Service (ToS) level
Another attribute of a pool is the Type of Service (ToS) level. The ToS level, also known as the DiffServ value, is a means by which network equipment can identify and treat traffic differently based on an identifier. As traffic enters the site, the BIG-IP system can set the ToS level on a packet, based on the ToS level defined in the pool to which the packet is sent. The BIG-IP system can also apply a rule and send the traffic to different pools of servers based on the ToS level.
The BIG-IP system can tag outbound traffic (the return packets based on an HTTP GET) based on the ToS value set in the pool. That value is then inspected by upstream devices and given appropriate priority. Based on a rule, the BIG-IP system can examine incoming traffic to see if it has a particular ToS tag in the header. The BIG-IP system can then make a rule-based load balancing decision based on that tag.
Figure 4.15 shows how to configure a pool so that a ToS level is set for a packet sent to that pool. In this example, the ToS tag, represented by the ip_tos variable, is set to 16 when sending packets to the client, and set to 16 when packets are sent to the server.
pool http_pool { ip_tos to client 16 ip_tos to server 16 } |
If you change the ip_tos to client or ip_tos to server level on a pool, existing connections continue to use the previous setting.
In addition to configuring a pool that sets the ToS level on a packet, you can configure a rule that selects a pool based on the existing ToS value within the packet. For more information, see Chapter 5, iRules .
Disabling SNAT and NAT connections
When configuring a pool, you can specifically disable any secure network address translations (SNATs) or network address translations (NATs) for any connections that use that pool. By default, this setting is enabled.
For general information on SNATs and NATs, see Chapter 10, Address Translation: SNATs, NATs, and IP Forwarding .
The example in Figure 4.16 shows the syntax for disabling SNAT and NAT translation for any connections that use the pool my_pool.
pool my_pool { snat disable nat disable member 10.1.1.1:80 member 10.1.1.2:80 } |
To disable a SNAT or NAT connection for a pool using the Configuration utility
- In the navigation pane, click Pools.
- Click the Add button.
- Clear the Enable SNATs check box. (By default, this box is checked.)
- Click Done.
To disable a SNAT or NAT connection for a pool from the command line
b pool <pool_name> modify { snat disable }
One case in which you might want to configure a pool to disable SNAT or NAT connections is when you want the pool to disable SNAT or NAT connections for a specific service. In this case, you could create a separate pool to handle all connections for that service, and then configure the snat disable or nat disable attribute on that pool.
The following procedure creates an automapped SNAT for a VLAN, creates a pool that disables SNAT or NAT connections, and then directs a wildcard virtual server using port 162 to send connections to the newly-defined pool.
To disable SNAT connections that use a specific service
- Enable SNAT automapping on the self IP address for VLAN my_vlan. For example:
b self 192.168.33.14 vlan my_vlan snat automap enable
- Create an automapped SNAT for the VLAN my_vlan.
For example:
b snat map my_vlan to auto
- Create a forwarding pool with the snat disable attribute defined. For example:
b pool snat_disable_pool { snat disable forward }
Note: For information on forwarding pools, see Enabling a forwarding pool .
- Create a wildcard virtual server for the VLAN my_vlan, specifying port 162 and the pool snat_disable_pool. For example:
b virtual my_vlan :162 use pool snat_disable_pool
Figure 4.17 shows the resulting entries in the /config/bigip.conf file.
# self IP addresses
self 192.168.33.14 {
vlan my_vlan
netmask 255.255.255.0
broadcast 192.168.33.255
snat automap enable
}
# server pools
pool snat_disable_pool {
snat disable
forward
}
# virtual servers
virtual servers:162 unit 1 {
use pool snat_disable_pool
translate addr disableFigure 4.18 shows an example of a rule that sends SNAT connections to a pool that disables SNAT connections on a range of ports, defined in the class IP_Port_Range.
Enabling a forwarding pool
A forwarding pool is a pool that specifies that a connection should be forwarded, using IP routing, instead of load balanced. In many cases, this eliminates the need to create a forwarding virtual server.
Forwarding pools are typically used with wildcard virtual servers or network virtual servers only. When you enable forwarding on a pool, you can apply any feature that can be configured on a pool to a forwarding connection.
A pool configured for forwarding has no members. Also, this type of pool cannot be the default gateway pool.
Figure 4.19 shows an example of a pool configured for forwarding.
pool my_pool { link_qos to client 5 link_qos to server 5 forward } |
To configure a pool for forwarding using the Configuration utility
- In the navigation pane, click Pools.
- Click the Add button.
- Click the forwarding button. If you enable forwarding, you cannot enter a list of pool members.
- Click Done.
To configure a pool for forwarding from the command line
b pool <pool_name> { forward }
If you want to enable IP forwarding for a virtual server, see Chapter 6, Virtual Servers .
Configuring a clone pool
When the clone pool attribute is enabled, all network traffic that a pool receives is replicated and sent to a node in the clone pool. The clone pool feature is used for detecting intrusion.
The BIG-IP system can replicate the packets either before or after translating the destination IP address.
You enable the clone pool feature using either the Configuration utility or the bigpipe pool command.
Configuring a clone pool using the Configuration utility
- In the navigation pane, click Pools.
- Click a pool name.
The properties of the pool are displayed. - In the clone pool box, select Before or After from the list box.
- Click Apply.
Configuring a clone pool from the command line
Use the following command syntax to configure a clone pool:
b pool [ clone before | clone after ] <pool_name>