This chapter covers the three essential configuration tasks that all users must complete, as well as the optional configuration tasks that most users find they want to do. Even if you want to use advanced features, such as IP filters or specialized load balancing modes, you start with the instructions in this chapter to set up your initial basic configuration.
A basic configuration sets up the BIG/ip Controller to do load balancing for one or more groups of content servers, firewalls, routers, or cache servers.
To set up a basic configuration, you need to do only the following three tasks.
This chapter also covers additional configuration options that users typically add to a simple configuration, including:
Warning: When you set configuration options in the F5 Configuration utility, they are immediately saved to the appropriate configuration file. However, when you set configuration options using the BIG/pipe command line utility, they are temporarily stored in system memory, and are not saved to a configuration file unless you execute the bigpipe -s command. For more information about this command, see the BIG/ip Controller Reference Guide, BIG/pipe Command Reference.
Table 3.1 describes the different types of connection configurations available on the BIG/ip Controller.
Connection configuration options for the BIG/ip Controller
|NAT||SNAT||IP Forwarding||Virtual server||Forwarding virtual server|
|Security||Medium||High||Low (see following note)||High||High|
|Routable addresses required on the internal network||No||No||Yes||No||Yes|
|Protocols||TCP and UDP||TCP and UDP||Any IP protocol||TCP and UDP||TCP and UDP|
|NT Domain support||No||No||Yes||No||Yes|
|Active FTP support||No||Yes||Yes||Yes||Yes|
|Connections||Not connection-oriented||Source processing||Not connection-oriented||Destination processing only||Connection
|Ports||Does not matter||Does not matter||Does not matter||Uses specific ports or wildcard||Uses specific ports or wildcard|
|Setup for specific nodes or hosts||Yes||Yes, but can use wildcards||No||Yes, but can use wildcard||Yes|
Note Although IP forwarding does not require setup for specific hosts, the BIG/ip Controller supports IP filters which you can configure to restrict traffic.
The first step in a basic configuration is to configure virtual servers. Before you configure virtual servers, you need to know:
Once you know which virtual server options are useful in your network, you can:
Virtual servers map to a group of content servers, firewalls, routers, or cache servers, and they are associated with one or more external interfaces on the BIG/ip Controller.
You can configure two different types of virtual servers:
Before you begin configuring the virtual servers, you should have the following information ready to enter:
Note that both the F5 Configuration utility and the BIG/pipe command line utility accept host names in place of IP addresses, and also accept standard service names in place of port numbers.
After you define a virtual server, you can set up additional features, such as network address translation (NAT) or extended content verification (ECV). If you are planning on using any of these features, you may want to read the corresponding section before you actually begin the virtual server configuration process:
Tip: If you prefer to use command line utilities for configuration tasks, you may find it more efficient to configure certain property settings at the time you define the virtual server. For example, to turn SSL persistence on using the bigpipe vip command, you add the special ssl keyword to the end of the command when you define the virtual server.
A standard virtual server represents a specific site, such as an Internet web site or an FTP site, and it load balances content servers. The IP address that you use for a standard virtual server should match the IP address that DNS associates with the site's domain name.
Note: If you are using a 3DNS Controller in conjunction with the BIG/ip Controller, the 3DNS Controller uses the IP address associated with the registered domain name in its own configuration. For details, refer to the 3DNS Controller Administrator Guide.
When you define a virtual server, you actually define the virtual server at the same time that you define the nodes which the virtual server uses for load balancing. The combination of the virtual server and the group of nodes that it load balances is referred to as the virtual server mapping.
Type the bigpipe vip command as shown below. Note that when you define a virtual server on the command line, you can define all nodes in the mapping at once. Also, you can use host names in place of IP addresses, and that you can use standard service names in place of port numbers.
bigpipe vip <virt IP>:<port> define <node IP>:<port> \
<node IP>:<port>... <node IP>:<port>
For example, the following command defines a virtual server that maps to three nodes:
bigpipe vip 22.214.171.124:80 define 192.168.10.01:80 \
Wildcard virtual servers are a special type of virtual server designed to manage network traffic for transparent network devices, such as transparent firewalls, routers, proxy servers, or cache servers. A wildcard virtual server manages network traffic that has a destination IP address unknown to the BIG/ip Controller. A standard virtual server typically represents a specific site, such as an Internet web site, and its IP address matches the IP address that DNS associates with the site's domain name. When the BIG/ip Controller receives a connection request for that site, the BIG/ip Controller recognizes that the client's destination IP address matches the IP address of the virtual server, and it subsequently forwards the client to one of the content servers that the virtual server load balances.
However, when you are load balancing transparent nodes, a client's destination IP address is going to seem random. The client is connecting to an IP address on the other side of the firewall, router, or proxy server. In this situation, the BIG/ip Controller cannot match the client's destination IP address to a virtual server IP address. Wildcard virtual servers resolve this problem by not translating the incoming IP address at the virtual server level on the BIG/ip Controller. For example, when the BIG/ip Controller does not find a specific virtual server match for a client's destination IP address, it matches the client's IP address to a wildcard virtual server. The BIG/ip Controller then forwards the client's packet to one of the firewalls or routers that the wildcard virtual server load balances, which in turn forwards the client's packet to the actual destination IP address.
When you configure wildcard virtual servers and the nodes that they load balance, you can use a wildcard port (port 0) in place of a real port number or service name. A wildcard port handles any and all types of network services.
A wildcard virtual server that uses port 0 is referred to as a default wildcard virtual server, and it handles traffic for all services. A port-specific wildcard virtual server handles traffic only for a particular service, and you define it using a service name or a port number. If you use both a default wildcard virtual server and port-specific wildcard virtual servers, any traffic that does not match either a standard virtual server or one of the port-specific wildcard virtual servers is handled by the default wildcard virtual server.
You can use port-specific wildcard virtual servers for tracking statistics for a particular type of network traffic, or for routing outgoing traffic, such as HTTP traffic, directly to a cache server rather than a firewall or router.
We recommend that when you define transparent nodes that need to handle more than one type of service, such as a firewall or a router, you specify an actual port for the node and turn off port translation for the virtual server.
Note: When you define a virtual server with port translation turned off, and you want to perform a service check on that node, you must configure service check intervals and timeouts using the port specified for the node. Then you can configure a service check. See Service checking for wildcard servers and ports, on page 3-18, for more details.
There are two procedures required to set up a wildcard virtual server. First, you must define the wildcard virtual server. Then you must turn port translation off for the virtual server.
After you define the wildcard virtual server with a wildcard port, you must disable port translation for the virtual server.
There are two commands required to set up a wildcard virtual server. First, you must define the wildcard virtual server. Then you must turn port translation off for the virtual server. To define the virtual server, use the bigpipe vip command:
bigpipe vip <virtual IP>:<port> define <node IP>:<port> \
<node IP>:<port>... <node IP>:<port>
After you define the virtual server, you can enable or disable port translation using the following command:
bigpipe vip <virtual IP>:<port> translate port enable | disable
For example, the following command defines a wildcard virtual server that maps to three nodes. Because the nodes are firewalls and need to handle a variety of services, the virtual server is defined using port 0 (or * or any). You can specify any valid non-zero port for the node port and then turn off port translation for that port. In this example, service checks ping port 80.
bigpipe vip 0.0.0.0:0 define 192.168.10.01:80 \
After you define the virtual server, turn off port translation for the port in the virtual server definition. In this example, port 80 is used for service checking. If you do not turn off port translation, all incoming traffic would be translated to port 80.
bigpipe vip 0.0.0.0:0 translate port disable
One of the security features of the BIG/ip Controller is that all ports on the controller are locked down and unavailable for service unless you specifically open them to network access. Before clients can use the virtual servers you have defined, you must allow access to each port that the virtual servers use.
This is the second task of the three essential tasks you must complete for a basic configuration. You must perform this task after you configure virtual servers and before you configure the timer settings.
Tip: Virtual servers using the same service actually share a port on the BIG/ip Controller. This command is global, you only need to open access to a port once; you do not need to open access to a port for each instance of a virtual server that uses it.
Any time you create a virtual server and define a port or service with the F5 Configuration utility, the port or service is automatically enabled.
Using the bigpipe port command, you can allow access to one or more ports at a time.
bigpipe port <port>... <port> enable
For example, in order to enable HTTP (port 80) and Telnet (port 23) services, you can enter the following bigpipe port command:
bigpipe port 80 23 enable
Warning: In order for FTP to function properly, you must allow both ports 20 and 21 (or ftp-data and ftp).
Configuring timer settings is the third task of the three essential tasks you must complete for a basic configuration. You must perform this task after you configure virtual servers and after you allow access to services and ports.
There are two essential timer settings that you need to configure:
The service check timer is optional, and you need to set it only if you want the BIG/ip Controller to check to see if a service, or even specific content, is available on a particular node. If you plan on using simple service checks, or ECV or EAV service checks, you need to set the service check timer.
The node ping timer is an essential setting on the BIG/ip Controller that determines how often the BIG/ip Controller checks node addresses to see whether they are up and available or down and unavailable. The node ping timer setting applies to all nodes configured for use by the BIG/ip Controller, and it is part of the BIG/ip Controller system properties.
To define node ping settings, you use two commands. First, you set the node ping frequency using the bigpipe tping_node command, and then you set the node ping timer using the bigpipe timeout_node command.
bigpipe tping_node <seconds>
bigpipe timeout_node <seconds>
For example, the following commands sets the ping frequency at 5 seconds, and the timer to 16 seconds, which should be adequate for most configurations.
bigpipe tping_node 5
bigpipe timeout_node 16
The BIG/ip Controller supports two timers for reaping idle connections, one for TCP traffic and one for UDP traffic. These timers are essential, and if they are set too high, or not at all, the BIG/ip Controller may run out of memory. Each individual port on the BIG/ip Controller has its own idle connection timer settings.
Warning: The BIG/ip Controller accepts UDP connections only if you set the UDP idle connection timer.
Use the bigpipe treaper to define a TCP idle connection timeout for one or more ports at a time. For HTTP connections we recommend only 60 seconds, but for other services such as Telnet we recommend higher settings. The default setting for this timer is 16 minutes (1005 seconds). Use the following syntax for this command.
bigpipe treaper <port>... <port> <seconds>
For example, the following command sets a 120 second time limit for idle connections on port 443:
bigpipe treaper 443 120
You can define a UDP idle connection timeout for one or more ports at a time using the bigpipe udp command.
bigpipe udp <port>... <port> <seconds>
For example, the following command sets a 120-second time limit for idle connections on port 53:
bigpipe udp 53 120
The service check feature is similar to node ping, but instead of testing the availability of a server, it tests the availability of a particular service running on a server. The service check timer affects the three different types of service checks: simple service check, ECV service check, and EAV service check. To set up simple service check, you need only set the service check timer as described below. To set up ECV service check or EAV service check, however, you need to configure additional settings (see Configuring Extended Content Verification service checking, on page 3-29).
Note that each individual service managed by the BIG/ip Controller has its own service check timer settings.
To define service check settings, you actually use a series of two commands. First, you set the service check frequency using the bigpipe tping_svc command, and then set the service check timer using the bigpipe timeout_svc command.
bigpipe tping_svc <port> <seconds>
bigpipe timeout_svc <port> <seconds>
For example, the following series of commands sets the service check frequency at 5 seconds, and the timer to 16 seconds, which is adequate for most configurations.
bigpipe tping_svc 80 5
bigpipe timeout_svc 80 16
When you configure a wildcard virtual server with a 0 port using nodes with standard ports, such as 80, with port translation turned off, the BIG/ip Controller uses the standard service check timeout values (e.g., port 80) to service check the port. For more information about setting the service check timer, see Setting the service check timer, on page 3-17
The simple keyword is being phased out in future releases. This information is provided in order to support existing configurations.
The simple keyword is necessary only if you specified a node port of 0. In previous versions of the BIG/ip Controller, this was the only way to set up a wildcard virtual server that handled connections for all services. However, we now recommend that you specify a node port and then turn off port translation for the virtual server.
To set up a simple service check for this type of virtual server, add the following entry to the /etc/bigd.conf file. Use the following syntax to set a check on a node where the check port is not the node port:
simple [<node addr>:]<node port> <check port>
For example, a wildcard server is defined with a wildcard port, like this:
bigpipe vip 0.0.0.0:0 define n1:0
In this case, you must use the simple keyword to designate the wildcard <server:><port> and <check port> for the service check:
simple n1:0 80
Changing the global load balancing mode is one of the optional tasks you can perform after you have completed the three main tasks of a basic configuration. This means you already have:
After you complete the basic tasks, you can change the global load balancing mode. The default global load balancing mode on the BIG/ip Controller is Round Robin, and it simply 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. If you want to use the Round Robin load balancing mode, you can skip this section, and begin configuring features that you want to add to the basic configuration.
However, if you are working with servers that differ significantly in processing speed and memory, you may want to switch to Ratio load balancing mode. In Ratio mode, the BIG/ip Controller 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 the ratio weight you define for each machine.
Tip: 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.
Note: The BIG/ip Controller also supports more advanced dynamic load balancing modes that may be suitable for your site. Refer to the BIG/ip Controller Administrator Guide, Working with Special Features, for more information about working with specialized load balancing modes.
If you want to switch from Round Robin to Ratio mode, you need to complete two separate configuration tasks:
Once you switch to Ratio load balancing mode, you need to set the ratio weight for each node address. Weights are a property of a node's IP address, and the default ratio weight for any given node address is 1.
The bigpipe ratio command sets the ratio weight for one or more node addresses:
bigpipe ratio <node IP>... <node IP> <ratio weight>
The following example defines ratio weights for three node addresses. The first command sets the first node to receive half of the connection load. The second command sets the two remaining node addresses to each receive one quarter of the connection load.
bigpipe ratio 192.168.10.01 2
bigpipe ratio 192.168.10.02 192.168.10.03 1
First, you should set the load balancing mode to Ratio. The load balancing mode is actually a property of the BIG/ip Controller system, and it applies to all virtual servers defined on the system.
To switch the system to Ratio mode, type the following BIG/pipe command:
bigpipe lb ratio
Configuring NATs and IP forwarding are optional tasks you can configure after you have completed the three main tasks of a basic configuration. This means you already have:
After you complete the basic tasks, you can configure network address translation and IP forwarding on the BIG/ip Controller.
The IP addresses that identify nodes on the BIG/ip Controller's internal network need not be routable on the external network. This protects nodes from illegal connection attempts, but it also prevents nodes (and other hosts on the internal network) from receiving direct administrative connections, or from initiating connections to clients, such as mail servers or databases, on the BIG/ip Controller's external interface (destination processing).
Using network address translation resolves this problem. Network address translations (NATs) assign to a particular node a routable IP address that the node can use as its source IP address when connecting to servers on the BIG/ip Controller's external interface. You can use the NAT IP address to connect directly to the node through the BIG/ip Controller, rather than having the BIG/ip Controller send you to a random node according to the load balancing mode. IP forwarding provides functionality similar to a NAT. If your network does not support NATs, you may want to consider using IP forwarding.
Note: In addition to these options, you can set up forwarding virtual servers which allow you to selectively forward traffic to specific addresses. The BIG/ip Controller maintains statistics for forwarding virtual servers. For more information about forwarding virtual servers, see the BIG/ip Controller Administrator Guide, Working with Special Features.
There are three configuration options on the BIG/ip Controller that you can use to control network access, and you need to identify which method is suitable for your needs:
Warning: NATs and SNATs do not support the NT Domain or CORBA protocols. Instead of using NATs or SNATs, you need to configure IP forwarding (see Setting up IP forwarding, on page 3-28).
When you define standard network address translations (NATs), you need to create a separate NAT for each node that requires a NAT. You also need to use unique IP addresses for NAT addresses; a NAT IP address cannot match an IP address used by any virtual or physical servers in your network. You can configure a NAT with the F5 Configuration utility or from the command line.
The bigpipe nat command defines one NAT for one node address.
bigppipe nat <node addr> to <NAT addr>
When you define secure network address translations (SNATs), you can assign a single SNAT address to multiple nodes. Note that a SNAT address does not necessarily have to be unique; for example, it can match the IP address of a virtual server.
SNAT addresses have global properties that apply to all SNATs that you define in the BIG/ip Controller configuration as well as to the SNAT mappings you define. You can configure SNATs in the F5 Configuration utility or from the command line.
The SNAT feature supports three global properties that apply to all SNAT addresses:
Configuring global properties for a SNAT requires that you enter three bigpipe commands. The following command sets the maximum number of connections you want to allow for each node using a SNAT.
bigpipe snat limit <value>
The following commands set the TCP and UDP idle connection timeouts:
bigpipe snat timeout tcp <seconds>
bigpipe snat timeout udp <seconds>
Once you have configured the SNAT global properties, you can configure SNAT address mappings. The SNAT address mappings define each SNAT address, and also define the node or group of nodes that uses the SNAT address. Note that a SNAT address does not necessarily have to be unique; for example, it can match the IP address of a virtual server. A SNAT address cannot match an address already in use by a NAT or another SNAT address.
The bigpipe snat command defines one SNAT for one or more node addresses.
bigpipe snat map <node addr>... <node addr> to <SNAT addr>
For example, the command below defines a secure network address translation for two nodes:
bigpipe snat map 192.168.75.50 192.168.75.51 to 192.168.100.10
If you do not want to translate addresses with a NAT or SNAT, you can use the IP forwarding configuration option. IP forwarding is an alternate way of allowing nodes to initiate or receive direct connections from the BIG/ip Controller's external network. IP forwarding exposes all of the node IP addresses to the external network, making them routable on that network. If your network uses the NT Domain or CORBA protocols, IP forwarding is an option for direct access to nodes.
To set up IP forwarding, you need to complete two tasks:
IP forwarding is a property of the BIG/ip Controller system, and it is controlled by the system control variable net.inet.ip.forwarding.
Use the standard sysctl command to set the variable. The default setting for the variable is 0, which is off. You want to change the setting to 1, which is on:
sysctl -w net.inet.ip.forwarding=1
To permanently set this value, you can use a text editor, such as vi or pico, to manually edit the /etc/rc.sysctl file. For additional information about editing this file, see the BIG/ip Controller Reference Guide, BIG/ip Controller System Control Variables.
Once you turn on IP forwarding, you probably need to change the routing table on the default router. Packets for the node addresses need to be routed through the BIG/ip Controller. For details about changing the routing table, refer to your router's documentation.
Extended content verification service checking is another feature you can configure after you have performed the three basic configuration tasks. Extended content verification service check is a special type of service check that actually retrieves content from a server. If the content matches the expected result, the BIG/ip Controller marks the node up and uses it for load balancing. If the content does not match, or if the server does not return content, the BIG/ip Controller marks the node down, and does not use it for load balancing.
You can set up ECV service check in the F5 Configuration utility, or you can use a text editor, such as vi or pico, to manually create the /etc/bigd.conf file, which stores ECV information.
ECV service check is most frequently used to verify content on web servers, although you can use it for more advanced applications, such as verifying firewalls or mail servers. This section focuses on setting up ECV for web servers. For details about using advanced ECV service check options, see the BIG/ip Controller Administrator Guide, Working with Advanced Service Check Options.
Note: It is important to note that the intervals and timeouts for service checks apply to EAV and ECV service checks. These timeouts are configured by setting the service check timers. For more information about setting these timers, see Configuring the timer settings, on page 3-13.
ECV service check is a property of both a node port and a node. If you define ECV service check settings for a node port, all nodes that use the port inherit the ECV service check settings. You can override these settings by defining ECV service check settings for the node itself.
There are actually three different types of ECV service check settings that you can define:
Warning: When the BIG/ip Controller checks content looking for a match, it reads through the content until the service check times out, or until the read reaches 5,000 bytes, whichever comes first. When you choose text, an HTML tag, or an image name to search for, be sure to pick one that appears in the first 5,000 bytes of the web page.
When you set up an ECV service check for a web server, you need to define a send string and a receive expression. A send string is the request that the BIG/ip Controller sends to the web server. Send strings typically request that the server return a specific web page, such as the default page for a web site. For example, the most common send string is "GET /" which simply retrieves the default HTML page for a web site. The receive expression is the text string that the BIG/ip Controller looks for in the returned web page.
Receive expressions use regular expression syntax, and they are not case-sensitive. Although regular expressions can be complex, you will find that simple regular expressions are adequate for most ECV service checks.
The corresponding receive string could be any simple text string included in your home page, such as text, HTML tags, or image names.
The send string below is probably the most common send string, and it retrieves the default HTML page for a web site. Note that all send strings are enclosed by quotation marks (" ") inside the /etc/bigd.conf file.
To retrieve a specific page from a web site, simply enter a fully qualified path name:
The most common receive expressions contain a text string that would be included in a particular HTML page on your site. The text string can be regular text, HTML tags, or image names. Note that all receive expressions are enclosed by quotation marks (" ").
For example, the following receive expression attempts to match the text Welcome, and it is useful for ECV reverse service checks:
The sample receive expression below searches for a standard HTML tag. Note that even though you are searching for an HTML tag, you still need to enclose the regular expression with quotation marks (" ").
You can also use null receive expressions, formatted as the one shown below. When you use a null receive expression, the BIG/ip Controller considers any content retrieved to be a match.
Null receive expressions are suitable only for ECV normal and ECV SSL. Note, however, that if you use them you run the risk of the BIG/ip Controller considering an HTML error page to be a successful service check.
Note: The regular expression syntax discussed here is not the same as the wildcard syntax that is commonly used in command shells. For more information about regular expression, see the man page for re_format. To view the man page for re_format, type man re_format at the command line.
In the F5 Configuration utility, you can set ECV service check options in the Global Node Port Properties screen, and also in individual Node Properties screens. Regardless of which screen you use to configure the options, the steps are the same.
You can set up ECV service check on the command line by creating an /etc/bigd.conf file in a text editor such as vi or pico. Each line in the /etc/bigd.conf file defines a send string and a receive expression for one node, or for one port. Remember that when you define a ECV service check for a port, all nodes that use the port inherit the service check settings.
Changes to the /etc/bigd.conf do not take effect until the system is rebooted, or bigd is restarted. To restart bigd, simply run the command bigd.
The BIG/ip Controller provides a command line tool that allows you to verify the syntax of the /etc/bigd.conf file before the system begins using it. Once you set up the file, we recommend that you test it before you reboot the system or restart the bigd daemon and begin using the file.
The /etc/bigd.conf file uses three different types of syntax for lines in the file that correspond to the three different types of service check that you can configure: ECV normal, ECV SSL, and ECV reverse. The following sections describe the syntax for each type, and provide some useful examples.
The line for a normal ECV service check begins with the keyword active. The <node IP> parameter is optional, and you need to include it only if you are defining ECV service check for a specific node.
active [<node IP>:]<port> "<send_string>" "<recv_expr>"
For example, the following line sets up a normal ECV service check for a node, where the BIG/ip Controller looks for the text Welcome in the default page for the site.
active 192.168.100.10:80 "GET /" "welcome"
The line for an SSL ECV service check begins with the keyword ssl. The <node IP> parameter is optional, and you need to include it only if you are defining ECV service check for a specific node.
ssl [<node IP>:]<port> "<send_string>" "<recv_expr>"
For example, the following line sets up an SSL ECV service check for a node port. Note that the receive expression is null. When you use a null receive expression, the BIG/ip Controller considers any retrieved content to be a match.
ssl 443 "GET /www/orders/order_form.html" ""
The line for a reverse ECV service check begins with the keyword reverse. The <node IP> parameter is optional, and you need to include it only if you are defining ECV service check for a specific node.
reverse [<node IP>:]<port> "<send_string>" "<recv_expr>"
For example, the following line sets up a reverse ECV service check for a node port. Note that the receive expression is null. When you use a null receive expression, the BIG/ip Controller considers any retrieved content to be a match.
reverse 80 "GET /" ""
You can test your ECV syntax in the bigd.conf file using the following bigd command:
This command parses the file, checks ECV syntax, reports any errors, and then exits.
Note: The /etc/bigd.conf file is read once at startup. If you change the file on the command line, you must reboot or restart bigd for the changes to take effect. If you make changes in the F5 Configuration utility, clicking the Apply button makes changes and restarts bigd. For more information about bigd, see the BIG/ip Controller Reference Guide, System Utilities.
Persistence is another feature you can configure after you have completed the three main tasks of a basic configuration. This means you already have:
If you are setting up an e-commerce or other type of dynamic content site, you may need to configure persistence on the BIG/ip Controller. Whether you need to configure persistence or not simply depends on how you store client-specific information, such as items in a shopping cart, or airline ticket reservations. For example, you may 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 turn on persistence, returning clients can bypass load balancing and instead can go to the node where they last connected in order to get to their saved information.
The BIG/ip Controller 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. The BIG/ip Controller supports two basic types of persistence:
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 Controller 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 Controller can successfully return the client to the appropriate node.
Note: The BIG/ip Controller also supports several advanced persistence modes. For more information about these advanced modes, see Working with Advanced Persistence Options, in the BIG/ip Controller Administrator Guide.
SSL persistence is a property of a virtual server, and to set it up for a given virtual server, you need to do two things:
On the command line, you actually set SSL persistence properties at the time you define the virtual server.
bigpipe vip <virt addr>:<port> define <node addr>:<port> \
special ssl <persist time>
For example, the following command sets SSL persistence for a virtual server, where the session ID record is valid for one hour (3600 seconds).
bigpipe vip v1:ssl define n1:ssl n2:ssl special ssl 3600
You can set simple persistence properties for both an individual virtual server, and for a port. Individual virtual server persistence settings can override those of the port. When you set simple persistence on a port, all virtual servers that use the given port inherit the port's persistence settings.
Persistence settings for virtual servers apply to both TCP and UDP persistence. Note that the persistence settings for the virtual server override the persistence settings defined for the port that the virtual server uses. 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.
· Timeout (seconds)
Set the number of seconds for persistence on the virtual server. This value overrides the persistence timeout set at the port level. (This option is not available if you are using rules.)
Set the persistence mask for the virtual server. The persistence mask determines persistence based on the portion of the client's IP address that is specified in the mask.
The bigpipe vip command sets simple persistence for one or more virtual servers. Note that a timeout greater than 0 turns persistence on, and a timeout of 0 turns persistence off.
bigpipe vip <virt IP>:<port> persist <timeout>
After you set the persistence timeout, you can specify a netmask. To set a persist mask, use the following syntax:
bigpipe vip <virt IP>:<port> persist mask <mask IP>
For example, the first command sets simple persistence for the virtual server, where the persistent connection information expires after one hour (3600 seconds). The second command sets a persist mask of 255.255.0.0.
bigpipe vip 192.168.100.10:80 persist 3600
bigpipe vip 192.168.100.10:80 persist mask 255.255.0.0
Defining persistence on a port requires only that you set the persistence timer; you do not actually have to turn the persistence on and off. When the persistence timer is set to 0, persistence is off. When it is set to a value greater than 0, persistence is on.
The bigpipe persist command sets simple persistence for one or more ports.
bigpipe persist <port>... <port> <seconds>
For example, the following command sets simple persistence for port 80, where the persistent connection information expires after one hour (3600 seconds).
bigpipe persist 80 3600
Another feature you can configure after you have performed the three basic configuration tasks is configuration synchronization.
Redundant BIG/ip Controller systems have special settings that you need to configure, such as interface fail-safe settings. One convenient aspect of configuring a redundant system is that once you have configured one of the controllers, you can simply copy the configuration to the other controller in the system using the configuration synchronization feature in the bigpipe command line tool or in the F5 Configuration utility.
There are two basic aspects about working with redundant systems:
Before you can use the bigpipe configsync command or the F5 Configuration utility to synchronize domestic HA redundant BIG/ip Controllers, you must first run the config_failover command. This command performs the following tasks:
To run the config_failover command, type the following command from the command line:
The config_failover utility prompts you for the root password of the other controller in the redundant system before it generates the security keys for the BIG/ip Controller.
Once you complete the initial configuration on the first controller in the system, you can synchronize the configurations between the active unit and the standby unit. When you synchronize a configuration, the following configuration files are copied to the other BIG/ip Controller:
If you use command line utilities to set configuration options, be sure to save the current configuration to the file before you use the configuration synchronization feature. Use the following bigpipe command to save the current configuration:
Warning: If you are synchronizing with a controller that already has configuration information defined, we recommend that you back up that controller's original configuration file(s).
You use the bigpipe configsync command to synchronize configurations. When you include the all option in the command, all the configuration files are synchronized between machines.
bigpipe configsync all
If you want to synchronize only the /etc/bigip.conf file, you can use the same command without any options:
For maximum reliability, the BIG/ip Controller supports failure detection on both internal and external interface cards. When you arm the fail-safe option on an interface card, the BIG/ip Controller monitors network traffic going through the interface. If the BIG/ip Controller detects a loss of traffic on an interface when half of the fail-safe timeout has elapsed, it attempts to generate traffic. An interface attempts to generate network traffic by issuing ARP requests to nodes accessible through the interface. Also, an ARP request is generated for the default route if the default router is accessible from the interface. Any traffic through the interface, including a response to the ARP requests, averts a fail-over.
If the BIG/ip Controller does not receive traffic on the interface before the timer expires, it initiates a fail-over, switches control to the standby unit, and reboots.
Warning: You should arm the fail-safe option on an interface only after the BIG/ip Controller is in a stable production environment. Otherwise, routine network changes may cause fail-over unnecessarily.
Each interface card installed on the BIG/ip Controller has a unique name, which you need to know when you set the fail-safe option on a particular interface card. You can view interface card names in the F5 Configuration utility, or you can use the bigpipe interface command to display interface names on the command line.
One of the required parameters for the bigpipe interface command is the name of the interface itself. If you need to look up the names of the installed interface cards, use the bigpipe interface command with the show keyword:
bigpipe interface show
To arm fail-safe on a particular interface, use the bigpipe interface command with the failsafe arm keyword and interface name parameter:
bigpipe interface timeout <seconds>
bigpipe interface <ifname> failsafe arm
For example, you have an external interface named exp0 and an internal interface named exp1. To arm the fail-safe option on both cards with a timeout of 30 seconds, you need to issue the following commands:
bigpipe interface timeout 30
bigpipe interface exp0 failsafe arm
bigpipe interface exp1 failsafe arm
You must address several network issues when you place a BIG/ip Controller in your network. These networking issues include routing, DNS configuration, and special sendmail considerations. You need to address these issues based on the type of hardware and software in your network. This section describes the following networking issues:
The BIG/ip Controller must communicate properly with network routers, as well as the servers, firewalls, and other routers that it manages. Because there is a variety of router configurations, and varying levels of direct control an administrator has over each router, you need to carefully review the router configurations in your own network. You may need to change some routing configurations before you put the BIG/ip Controller into production.
The BIG/ip Controller supports static route configurations, dynamic routing (via BGP4, RIP1, RIP2, and OSPF), and subnetting. However, the BIG/ip Controller is also designed to eliminate the need for you to modify routing tables on a router that routes to a BIG/ip Controller. Instead, the BIG/ip Controller uses Address Resolution Protocol (ARP) to notify routers of the IP addresses that it uses on each interface, as well as on its virtual servers.
The following sections address these common routing issues:
The BIG/ip Controller needs a route to the external network. For most configurations, this should be configured as the default route on the BIG/ip Controller.
Note: For multiple gateways to the external network, you can configure a last hop pool. For more information, see the BIG/ip Controller Administrator Guide, Using per-connection routing, on page 2-30.
During installation, you were prompted to configure a default route for the BIG/ip Controller. If you need to change the default route at this time, you can set a new default route by editing the /etc/netstart file.
The content servers being load balanced by the BIG/ip Controller need to have a default route set to the internal IP alias (source processing) of the BIG/ip Controller. For most configurations, this should be configured as the default route on the content server.
For information about setting the default route for your content servers, refer to the product documentation for your server.
If you need to configure the BIG/ip Controller to use one or more nodes that actually sit on a different logical network from the BIG/ip Controller, you need to assign one or more additional routes to get to those nodes. Set each node's default route in such a way that traffic goes back through the BIG/ip Controller internal interface.
In the following examples, the nodes are on 192.168.6/24 and the BIG/ip Controller internal interface is on 192.168.5/24. There are two possible situations which you may have to address:
If the nodes are on the same LAN as the BIG/ip Controller, you simply need to add an interface route for 192.168.6/24 to the BIG/ip Controller's internal interface. You can add this route to the bottom of the /etc/rc.local file using the following syntax:
route add -net 192.168.6 -interface exp1
Note: You must have the interface defined correctly in the /etc/hosts file in order to use this syntax.
If you have nodes on different LANs from the BIG/ip Controller, you need to add a static gateway route on the BIG/ip Controller itself. For example:
route add -net 192.168.6.0 -gateway 192.168.5.254
You also need to set the default route on the nodes to point to the router between the LANs. For example:
route add default -gateway 192.168.6.254
Finally, you need to set the default route on the router between the LANs to the BIG/ip Controller's shared alias. For example, type the command:
route add default -gateway 192.168.5.200
Note: These examples assume you are using a UNIX-based router. The exact syntax for your router may be different.
It is not really necessary to set the default route for nodes directly to the BIG/ip Controller, so long as the default path eventually routes through the BIG/ip Controller.
The GateD daemon allows the BIG/ip Controller to exchange dynamic routing updates with your routers. Setting up the GateD daemon is a three-part task:
Note: Configuring GateD on the BIG/ip Controller is not required. Most routing requirements for the BIG/ip Controller can be met without using GateD.
GateD relies on a configuration file, typically named /etc/gated.conf, which can be relatively simple, or can be very complex, depending on the routing needs of your network. The BIG/ip web server includes the GateD online documentation (in the F5 Configuration utility home page, under Online Documentation section, click GateD). Note that the GateD configuration guide details the process of creating the GateD configuration file, and also provides samples of common protocol configurations.
Once you create the GateD configuration file, you need to start the GateD daemon on the command line using the following command:
To start GateD each time the BIG/ip Controller starts, change the gated variable in the /etc/netstart file as shown below:
If you plan to use DNS in your network, you can configure DNS on the BIG/ip Controller. There are three different DNS issues that you may need to address when setting up the BIG/ip Controller:
When entering virtual addresses, node addresses, or any other addresses on the BIG/ip Controller, you can use the address, host name, or fully qualified domain name (FQDN).
The BIG/ip Controller looks up host names and FQDNs in the /etc/hosts file. If it does not find an entry in that file, then it uses DNS to look up the address. In order for this to work, you need to create an /etc/resolv.conf file. The file should have the following format:
search <DOMAIN_NAME_1> <DOMAIN_NAME_2>
In place of the <DNS_SERVER_1> parameter, use the IP address of a properly configured name server that has access to the Internet. You can specify additional name servers as backups by inserting an additional nameserver line for each backup name server.
If you configure the BIG/ip Controller itself as a DNS server, then we suggest that you choose its loopback address (127.0.0.1) as the first name server in the /etc/resolv.conf file.
Replace the <DOMAIN_NAME_1> and <DOMAIN_NAME_2> parameters with a list of domain names to use as defaults. The DNS uses this list to resolve hosts when the connection uses only a host name, and not an FQDN. When you enter domain names in this file, separate each domain name with a space, as shown.
A sample configuration file is shown in Figure 3.1.
Figure 3.1 Sample /etc/resolv.conf file
; example /etc/resolv.conf
nameserver 127.16.112.2 ;ip address of main DNS server
search mysite.com store.mysite.com
You can also configure the order in which name resolution checks are made by configuring the /etc/irs.conf file. You should set this file so that it checks the /etc/hosts file first, and then checks for DNS entries. See Figure 3.2, for an example of how to make the entry in the /etc/irs.conf file:
Figure 3.2 Sample entry for the /etc/irs.conf file
hosts local continue
The BIG/ip Controller is automatically configured as a DNS proxy or forwarder. This is useful for providing DNS resolution for servers and other equipment load balanced by the BIG/ip Controller.
To re-configure DNS proxy, you simply edit the /etc/named.boot file that contains these two lines:
In place of the <DNS_SERVER> parameter, use the IP addresses of one or more properly configured name servers that have access to the Internet.
You can also configure the BIG/ip Controller to be an authoritative name server for one or more domains. This is useful when DNS is needed in conjunction with internal domain names and network addresses for the servers and other equipment behind the BIG/ip Controller. Refer to the BIND documentation for more details.
If your network is currently configured to use rotary DNS, your node configuration may not need modification. However, you need to modify your DNS zone tables to map to a single IP address instead of to multiple IP addresses.
For example, if you had two Web sites with domain names of www.SiteOne.com and www.SiteTwo.com, and used rotary DNS to cycle between two servers for each Web site, your zone table might look like the one in Figure 3.3.
Figure 3.3 Sample zone table with two Web sites and four servers
www.SiteOne.com IN A 192.168.1.1
IN A 192.168.1.2
www.SiteTwo.com IN A 192.168.1.3
IN A 192.168.1.4
In the BIG/ip Controller configuration, the IP address of each individual node used in the original zone table becomes hidden from the Internet. We recommend that you use the Internet reserved address range as specified by RFC 1918 for your nodes. In place of multiple addresses, simply use a single virtual server associated with your site's domain name.
Using the above example, the DNS zone table might look like the zone table shown in Figure 3.4.
Figure 3.4 Sample zone table with two Web sites and two servers.
www.SiteOne.com IN A 192.168.100.231
www.SiteTwo.com IN A 192.168.100.232
Another optional feature you can set up when you configure the BIG/ip Controller is email. You can configure the BIG/ip Controller to send email notifications to you, or to other administrators. The BIG/ip Controller uses Sendmail as its mail transfer agent. The BIG/ip Controller includes a sample Sendmail configuration file that you can use to start with, but you will have to customize the Sendmail setup for your network environment before you can use it.
Before you begin setting up Sendmail, you may need to look up the name of the mail exchanger for your domain. If you already know the name of the mail exchanger, skip to Setting up Sendmail, on page 3-55.
You can use the nslookup command on the BIG/ip Controller or any workstation that is configured for DNS lookup. Once you find the primary IP address for your domain, you can find the mail exchanger for your domain.
The information returned includes the name of the mail exchanger. For example, the sample information shown in Figure 3.5 lists bigip.net as the preferred mail exchanger.
Figure 3.5 Sample mail exchanger information
bigip.net preference = 10, mail exchanger = mail.SiteOne.com
bigip.net nameserver = ns1.bigip.net
bigip.net nameserver = ns2.bigip.net
bigip.net internet address = 126.96.36.199
ns1.bigip.net internet address = 188.8.131.52
ns2.bigip.net internet address = 184.108.40.206
When you actually set up Sendmail, you need to open and edit a couple of configuration files. Note that the BIG/ip Controller does not accept email messages, and that you can use the crontab utility to purge unsent or returned messages, and that you can send those messages to yourself or another administrator.
0,15,30,45 * * * * root /usr/sbin/sendmail -q > /dev/null 2>&1
/usr/sbin/sendmail -bd -q30m
Now that you have completed the most basic configuration options for the BIG/ip Controller, you may want to review a couple of sample configurations that use the BIG/ip Controller for traffic management. The following examples are described in this section:
The most common application of the BIG/ip Controller is to distribute traffic across an array of web servers that host standard web traffic, including e-commerce traffic. However, a BIG/ip Controller can also control traffic distribution for other types of devices, such as cache servers, proxy servers, firewalls, and even routers.
The following sections provide you with two basic configuration examples that can help you plan your installation. These examples can also help you understand how people use some of the most popular BIG/ip Controller features to resolve specific issues or to enhance network performance in general.
First, we start with a basic configuration where a BIG/ip Controller load balances two sites: www.MySite.com and store.MySite.com. The www.MySite.com site provides standard web content, and the store.MySite.com site is the e-commerce site that sells items to www.MySite.com customers. In this scenario, the BIG/ip Controller provides simple load balancing for both sites.
To set up load balancing for these sites, you need to create two virtual servers, one for each site. Even though the sites are related and they may even share the same IP address, each requires its own virtual server because it uses a different port to support its particular protocol: port 80 for the HTTP traffic going to www.MySite.com, and port 443 for the SSL traffic going to store.MySite.com.
Figure 3.6 shows the topology for the sample configuration. Each site uses two of the three web servers to host its content. Both sites happen to share Server 2.
Note: Note that in this example, as in all examples in this guide, we use only non-routable IP addresses. In a real topology, the virtual server IP addresses would have to be routable on the Internet.
The virtual servers that you define always include three basic elements:
The BIG/ip Controller distributes connections among the three servers according to a user-specified load balancing mode. The most common mode is Round Robin, which simply distributes each new connection to the next server in line, eventually distributing the connections equally among all the servers.
In this type of configuration, you might want to take advantage of the following BIG/ip Controller features:
The next example is a configuration that might be found in a large corporate intranet. In this scenario, the BIG/ip Controller performs load balancing for two different types of connection requests:
To set up load balancing for this intranet example, you need to create three virtual servers: one that handles load balancing for the internal corporate web site, one that directs outbound HTTP traffic to the cache server, and one that handles load balancing for the firewalls.
Figure 3.7 shows the topology for the sample configuration. A standard virtual server handles the load balancing for the corporate intranet web site, Corporate.main.net. Wildcard Virtual Server 1 takes all of the outbound HTTP traffic and directs it to the cache server. Wildcard Virtual Server 2 handles all of the remaining traffic that actually has to go out to the Internet.
The wildcard virtual servers are a special type of virtual server, which accept traffic going to IP addresses unknown to the BIG/ip Controller, as all outside Internet addresses would be. When the BIG/ip Controller receives a connection request, it immediately tries to match the requested IP address to one of its virtual server IP addresses. If it cannot find a match among the standard virtual servers that it manages, it then looks for a wildcard virtual server. Wildcard virtual servers provide the default IP address of 0.0.0.0 that the BIG/ip Controller can use as a sort of catch-all IP address match.
There are actually two types of wildcard virtual servers, and this example shows both:
In this type of configuration, you might want to take advantage additional BIG/ip Controller features that are described in the BIG/ip Controller Administrator Guide and the BIG/ip Controller Reference Guide. These features include: