Manual Chapter : BIG-IP Getting Started guide v3.0: Getting Started with a Basic Configuration

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 3.0 PTF-04, 3.0 PTF-03, 3.0 PTF-02, 3.0 PTF-01, 3.0.0
Manual Chapter


3

Getting Started with a Basic Configuration



Setting up a basic configuration

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.

  • Configure the virtual servers and the virtual server mappings
    The virtual servers are the backbone of the system configuration, and they define the groups of servers or other network equipment that the BIG/ip Controller load balances.
  • Allow access to ports and services
    The services and ports on a BIG/ip Controller are locked down and cannot accept connections until you specifically open them to network access. For each service that one or more of your virtual servers supports, you need to open the corresponding port number for network access. However, ports are automatically enabled when you use them in virtual server definition in the F5 Configuration utility.
  • Configure the timer settings
    The BIG/ip Controller supports several timer settings, but for a simple configuration, there are only two that you need to set. First you need to set the amount of time that idle connections are allowed to remain open. Second, you need to set the frequency at which the BIG/ip Controller checks nodes to make sure they are up and available to accept connections passed on by a virtual server.

    This chapter also covers additional configuration options that users typically add to a simple configuration, including:

  • Change the load balancing mode
    You can use an alternate load balancing mode.
  • Configure NATs or IP forwarding
    You can set up network address translation (NAT) or IP forwarding to allow direct connections to and from nodes.
  • Configure extended content verification service checking
    You can configure extended content verification (ECV) to allow the BIG/ip Controller to verify that a server is responding to requests.
  • Set up persistence
    You can set up persistence to accommodate e-commerce and other dynamic content sites that require returning clients to bypass load balancing and return to the same node to which they last connected.
  • Configure and synchronize redundant systems
    You can configure and set up redundant BIG/ip Controller systems.

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
oriented
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
Load balancing No No No Yes No

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.

Configuring virtual servers

The first step in a basic configuration is to configure virtual servers. Before you configure virtual servers, you need to know:

  • If standard virtual servers or wildcard virtual servers meet the needs of your network
  • Whether you need to activate optional virtual server properties

    Once you know which virtual server options are useful in your network, you can:

  • Define standard virtual servers
  • Define wildcard virtual servers

Using standard or wildcard virtual servers

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:

  • Standard virtual servers
    A standard virtual server represents a site, such as a web site or an FTP site, and it provides load balancing for content servers. The virtual server IP address should be the same IP address that you register with DNS for the site that the virtual server represents.
  • Wildcard virtual servers
    A wildcard virtual server load balances transparent network devices such as firewalls, routers, or cache servers. Wildcard virtual servers are configured with an IP address of 0.0.0.0, and sometimes with a virtual port of 0.

    Before you begin configuring the virtual servers, you should have the following information ready to enter:

  • The IP address and service name or port number of each virtual server you are configuring
  • The IP addresses and ports for each content server, firewall, cache server, or other device that the virtual servers will load balance

    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.

Using additional features with virtual servers

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.

Defining standard virtual servers

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.

To define a standard virtual server mapping in the F5 Configuration utility

  1. In the navigation pane, click Virtual Servers.
  2. On the toolbar, click Add Virtual Server.
    The Add Virtual Server screen opens.
  3. In the Address box, enter the virtual server's IP address or host name.
  4. In the Netmask box, type an optional netmask. If you leave this setting blank, the BIG/ip Controller uses a default netmask based on the IP address you entered for the virtual server. Use the default netmask unless your configuration requires a different netmask.
  5. In the Broadcast box, type the broadcast address for this virtual server. If you leave this box blank, the BIG/ip Controller generates a default broadcast address based on the IP address and netmask of this virtual server.
  6. In the Port box, either type a port number, or select a service name from the drop-down list.
  7. For Interface, select the external (destination processing) interface on which you want to create the virtual server. Select default to allow the F5 Configuration utility to select the interface based on the network address of the virtual server. If no external interface is found for that network, the virtual server is created on the first external interface. If you choose None, the BIG/ip Controller does not create an alias and generates no ARPs for the virtual IP address. In this case, the BIG/ip Controller accepts traffic on all interfaces.
  8. In Resources, click the Node List button.
  9. In the Node Address box, type the IP address or host name of the first node to which the virtual server maps. If you have already defined a node address, you can choose it from the list.
  10. In the Node Port box, type the node port number, or select the service from the drop-down list. Note that in typical applications, the node port is the same as the virtual server port. If you have already defined a node port, you can choose it from the list.
  11. Click the add button (>>) to add the node to the Current Nodes list for the virtual server.
  12. To add additional nodes to the virtual server mapping, type in a Node Address, Node Port, and click the add button (>>).
  13. To remove nodes from the virtual server mapping, click the node listed in the Current Nodes list and click the remove button (<<).
  14. After you have added or removed nodes from the Current Nodes list, click the Add button to save the virtual server.

To define a standard virtual server mapping on the command line

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 192.200.100.25:80 define 192.168.10.01:80 \
192.168.10.02:80 192.168.10.03:80

Defining wildcard virtual servers

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.

A note about wildcard ports

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.

Defining the wildcard virtual server mappings

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.

To define a wildcard virtual server mapping in the F5 Configuration utility

  1. In the navigation pane, click Virtual Servers.
  2. On the toolbar, click Add Virtual Server.
    The Add Virtual Server screen opens.
  3. In the Address box, type the wildcard IP address 0.0.0.0.
  4. In the Netmask box, type an optional netmask.
    If you leave this box blank, the BIG/ip Controller generates a default netmask address based on the IP address of this virtual server. Use the default netmask unless your configuration requires a different netmask.
  5. In the Broadcast box, type the broadcast address for this virtual server.
    If you leave this box blank, the BIG/ip Controller generates a default broadcast address based on the IP address and netmask of this virtual server.
  6. In the Port box, type a port number, or select a service name from the drop-down list. Note that port 0 defines a wildcard virtual server that handles all types of services. If you specify a port number, you create a port-specific wildcard virtual server. The wildcard virtual server only handles traffic for the port specified.
  7. For Interface, select the external (destination processing) interface on which you want to create the virtual server.
    If you choose None, the BIG/ip Controller does not create an alias and generates no ARPs for the virtual IP address (see the BIG/ip Controller Administrator Guide, Optimizing large configurations, on page 2-18, for details).
  8. In Resources, click the Node List button.
  9. In the Node Address box, type the IP address or host name of the first node to which the virtual server maps. If you have already defined a node address, you can choose it from the list.
  10. In the Node Port box, type the node port number, or select the service from the drop-down list. If you have already defined a node port, you can select it from the list. We recommend you choose a valid node port, such as 80, and then disabling address translation on the virtual server. This allows you to set up service checks for the node port.
  11. Click the add button (>>) to add the node to the Current Nodes list for the virtual server.
  12. To add additional nodes to the virtual server mapping, type in a Node Address, Node Port, and click the add button (>>).
  13. To remove nodes from the virtual server mapping, click the node listed in the Current Nodes list and click the remove button (<<).
  14. After you have added or removed nodes from the Current Nodes list, click the Add button to save the virtual server.

To turn off port translation for a wildcard virtual server in the F5 Configuration utility

After you define the wildcard virtual server with a wildcard port, you must disable port translation for the virtual server.

  1. In the navigation pane, click Virtual Servers.
    The Virtual Servers screen opens.
  2. In the virtual server list, click the virtual server for which you want to turn off port translation.
    The Virtual Server Properties screen opens.
  3. In the Enable Translation section, clear the Port box.
  4. Click the Apply button.

To define a wildcard virtual server mapping on the command line

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 \
192.168.10.02:80 192.168.10.03: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

Allowing access to ports and services

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.

To allow access to services in the F5 Configuration utility

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.

To allow access to services on the command line

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 the timer settings

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 node ping timer defines how often the BIG/ip Controller will ping node addresses to verify whether a node is up or down. It also defines how long the BIG/ip Controller waits for a response from a node before determining that the node is unresponsive and marking the node down.
  • The idle connection timer defines how long an inactive connection is allowed to remain open before the BIG/ip Controller deletes the record of the connection, closing it and disconnecting the client.

    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.

Setting the node ping 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 set the node ping timer in the F5 Configuration utility

  1. In the navigation pane, click the BIG/ip logo.
    The BIG/ip System Properties screen opens.
  2. In the Node Ping section of the table, in the Ping box, type the frequency (in seconds) at which you want the BIG/ip Controller to ping each node address it manages. A setting of 5 seconds is adequate for most configurations.
  3. In the Node Ping section of the table, in the Timeout box, type the number of seconds you want the BIG/ip Controller to wait to receive a response to the ping. If the BIG/ip Controller does not receive a response to the ping before the node ping timeout expires, the BIG/ip Controller marks the node down and does not use it for load balancing. A setting of 16 seconds is adequate for most configurations.

To set the node ping timer on the command line

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

Setting the timer for reaping idle connections

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.

To set the inactive connection timer in the F5 Configuration utility

  1. In the navigation pane, click the plus (+) next to Virtual Servers.
    The Virtual Server tree opens and displays the Ports option.
  2. Click Ports.
    The Global Virtual Ports screen opens.
  3. In the Port box, click the port number or service name for which you want to configure the idle connections timeouts.
    The Global Virtual Port screen opens.
  4. In the Idle Connection Timeout TCP box, type the number of seconds you want to elapse before the BIG/ip Controller drops an idle TCP connection. For HTTP connections, 60 seconds should be adequate, but for other services such as Telnet, higher settings may be necessary.
  5. In the Idle Connection Timeout UDP box, type the number of seconds you want to elapse before the BIG/ip Controller drops UDP connections.
  6. Click the Apply button.

To set TCP idle connection timers on the command line

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

To set UDP idle connection timers on the command line

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

Setting the service check timer

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 set the service check timer in the F5 Configuration utility

  1. In the navigation pane, click the plus (+) next to Nodes.
    The Nodes tree opens and displays the Ports option.
  2. Click Ports.
    The Global Node Ports screen opens.
  3. Click the port you want to configure.
    The Global Node Port Properties screen opens.
  4. In the Frequency box, type the frequency (in seconds) at which you want the BIG/ip Controller to check the service on the node for all defined nodes using this port. Five seconds is adequate for most configurations.
  5. In the Timeout box, type the number of seconds you want the BIG/ip Controller to wait to receive a response to the service check. If the BIG/ip Controller does not receive a response to the service check before the timeout expires, the BIG/ip Controller marks the service on the node down and does not use it for load balancing. Sixteen (16) seconds is adequate for most configurations.
  6. Click the Apply button.

To set the service check timer on the command line

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

Service checking for wildcard servers and ports

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

Using the simple keyword

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

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:

  • Configured virtual servers
  • Configured access to ports and services
  • Configured the timer settings

    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.

Using Ratio mode

If you want to switch from Round Robin to Ratio mode, you need to complete two separate configuration tasks:

  • Define the ratio weight (percentage of connections to be handled) for each individual node address.
  • Set the load balancing mode to Ratio as described in the following section.

Setting ratio weights for node addresses in a virtual server mapping

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.

To set ratio weights in the F5 Configuration utility

  1. In the navigation pane, click Nodes.
  2. In the Nodes list, select the node for which you want to set the ratio weight.
    The Node Properties screen opens.
  3. In the Node Properties screen, select the Address of the node.
    The Global Node Address Properties screen opens.
  4. In the Ratio or Priority box, replace the default ratio weight with the ratio weight of your choice.
  5. Click the Apply button to save your changes.

To set ratio weights on the command line

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

Switching to Ratio mode

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 in the F5 Configuration utility

  1. In the navigation pane, click Virtual Servers.
    The Virtual Servers screen opens.
  2. In the Node List Load Balancing Method box, select Ratio (node address).

To switch the system to Ratio mode on the command line

To switch the system to Ratio mode, type the following BIG/pipe command:

 bigpipe lb ratio

Configuring NATs and IP forwarding for nodes

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:

  • Configured virtual servers
  • Configured access to ports and services
  • Configured the timer settings

    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:

  • Network Address Translation (NAT)
    A network translation address provides a routable alias IP address that a node can use as its source IP address when making or receiving connections to clients on the external network. You can configure a unique NAT for each node address included in a virtual server mapping.
    Note that NATs do not support port translation, and are not appropriate for FTP. You cannot define a NAT if you configure a default SNAT.
  • Secure Network Address Translation (SNAT)
    A secure network address translation provides functionality similar to that of firewalls. A SNAT defines a routable alias IP address that one or more nodes can use as a source IP address only when making connections to hosts on the external network. SNAT addresses support port translation, and they also prevent hosts on the external network from connecting directly to the node.
    Note that SNAT only supports TCP and UDP. SNAT also features support for both passive and active FTP. You cannot define a NAT if you define a default SNAT.
  • IP forwarding
    IP forwarding does not translate node addresses. Instead, it simply exposes the node's IP address to the BIG/ip Controller's external network and clients can use it as a standard routable address. When you turn IP forwarding on, the BIG/ip Controller acts as a router when it receives connection requests for node addresses. IP forwarding itself does not provide security features, but you can use the IP filter feature to implement a layer of security (see Setting up IP forwarding, on page 3-28) that can help protect your nodes.

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).

Defining a standard network address translation (NAT)

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.

To configure a NAT in the F5 Configuration utility

  1. In the navigation pane, click NATs.
    The Network Address Translations screen opens.
  2. On the toolbar, click Add NAT.
    The Add Nat screen opens.
  3. In the Node Address box, type the IP address of the node.
  4. In the NAT Address box, type the IP address that you want to use as the node's alias IP address.
  5. In the NAT Netmask box, type an optional netmask. If you leave this box blank, the BIG/ip Controller generates a default broadcast address based on the IP address and netmask of this virtual server.
  6. In the NAT Broadcast box, type the broadcast address. If you leave this box blank, the BIG/ip Controller generates a default broadcast address based on the IP address and netmask of this NAT.
  7. In the Interface box, you can select an external interface (destination processing) on which the NAT address is to be used. Note that this setting only applies if the BIG/ip Controller has more than one external interface.
  8. Click the Apply button.

To configure a NAT on the command line

The bigpipe nat command defines one NAT for one node address.

 bigppipe nat <node addr> to <NAT addr>

Defining a secure network address translation (SNAT)

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.

Setting SNAT global properties

The SNAT feature supports three global properties that apply to all SNAT addresses:

  • Connection limits
    The connection limit applies to each node that uses a SNAT, and each individual SNAT can have a maximum of 50,000 simultaneous connections.
  • TCP idle connection timeout
    This timer defines the number of seconds that TCP connections initiated using a SNAT address are allowed to remain idle before being automatically disconnected.
  • UDP idle connection timeout
    This timer defines the number of seconds that UDP connections initiated using a SNAT address are allowed to remain idle before being automatically disconnected. This value should not be set to 0.

To configure SNAT global properties in the F5 Configuration utility

  1. In the navigation pane, click Secure NATs.
    The Secure Network Address Translations screen opens.
  2. In the Connection Limit box, type the maximum number of connections you want to allow to each node using a SNAT. To turn connection limits off, set the limit to 0. If you turn connection limits on, keep in mind that each SNAT can support only 50,000 simultaneous connections.
  3. In the TCP Idle Connections box, type the number of seconds that TCP connections initiated by a node using a SNAT are allowed to remain idle.
  4. In the UDP Idle Connections box, type the number of seconds that UDP connections initiated by a node using a SNAT are allowed to remain idle. This value should not be set to 0.
  5. Click the Apply button.

To configure SNAT global properties on the command line

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>

Configuring SNAT address mappings

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.

To configure a SNAT mapping in the F5 Configuration utility

  1. In the navigation pane, click Secure NATs.
    The Secure Network Address Translations screen opens.
  2. On the toolbar, click Add SNAT.
    The Add SNAT screen opens.
  3. In the Translation Address box, type the IP address that you want to use as the alias IP address for the node(s).
  4. In the Interface box, you can select the external interface (destination processing) on which the SNAT address is to be used. Note that this setting applies only if your BIG/ip Controller has more than one destination processing interface.
  5. In the Original Address box, type the IP address of the node or nodes that are assigned to the SNAT. Click the add button (>>) to add the address to the Current List.
  6. To remove an address from the Current List, click the remove button (<<).
  7. Click the Apply button.

To configure a SNAT mapping on the command line

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

Setting up IP forwarding

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:

  • Turn IP forwarding on
    The BIG/ip Controller uses a system control variable to control IP forwarding, and its default setting is off.
  • Verify the routing configuration
    You probably have to change the routing table for the router on the BIG/ip Controller's external network. The router needs to direct packets for nodes to the BIG/ip Controller, which in turn directs the packets to the nodes themselves.

Turning on IP forwarding

IP forwarding is a property of the BIG/ip Controller system, and it is controlled by the system control variable net.inet.ip.forwarding.

To set the IP forwarding system control variable in the F5 Configuration utility

  1. In the navigation pane, click the BIG/ip logo.
    The BIG/ip System Properties screen opens.
  2. On the toolbar, click Advanced Properties.
    The BIG/ip System Control Variables screen opens.
  3. Check the Allow IP Forwarding box.
  4. Click the Apply button.

To set the IP forwarding system control variable on the command line

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.

Addressing routing issues for IP forwarding

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.

Configuring Extended Content Verification service checking

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 properties

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:

  • ECV normal
    An ECV normal service check requires that the BIG/ip Controller mark a node up (available for load balancing) when the retrieved content matches the expected result. For example, if the home page for your web site included the words Welcome home, you could set up an ECV service check to look for the string "Welcome home". A match for this string would mean that the web server is up and available.
  • ECV SSL
    An ECV SSL service check performs the same function as an ECV normal service check, but it is designed to work with secure servers that use the SSL protocol, rather than standard servers using HTTP. The BIG/ip Controller uses SSL version 3, as do popular web browsers, but it is backward-compatible for web servers that support only version 2.
  • ECV reverse
    In contrast, an ECV reverse service check requires that the BIG/ip Controller mark a node down (not available for load balancing) when the retrieved content matches the expected result. For example, if the content on your web site home page is dynamic and changes frequently, you may prefer to set up a reverse ECV service check that looks for the string "Error". A match for this string would mean that the web server was down.

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.

Writing regular expressions for ECV service checks

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.

Sample send strings

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.

 "GET /"

To retrieve a specific page from a web site, simply enter a fully qualified path name:

 "GET /www/support/customer_info_form.html"

Sample receive expressions

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:

 "welcome"

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 (" ").

 "<HEAD>"

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.

Setting up ECV service check in the F5 Configuration utility

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.

To set up ECV service check in the F5 Configuration utility

  1. In the navigation pane, click Nodes.
    The Nodes screen opens.
  2. Select a node from the list.
    The Node Properties screen opens.
  3. If you want to configure ECV service check options, stay in this screen. If you want to configure ECV service check options for the port that the node uses, click the port number listed next to the IP address of the node.
  4. Click the ECV button.
  5. In the Type box, choose the type of ECV service check you want to set up: normal, reverse, or SSL.
  6. In the Send String box, type the send string that requests the web page. Note that the F5 Configuration utility automatically places quotation marks around the string itself. For example, the following string retrieves the default HTML page for the site.
     GET /
  7. In the Receive Rule box, type the receive expression that the BIG/ip Controller should look for in the returned web page. For example, the following receive expression looks for a text string in a web page:
     Welcome home!
  8. Click the Apply button.

Manually configuring and testing the /etc/bigd.conf file

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.

Setting up the /etc/bigd.conf 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.

To set up an ECV normal service check

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"

To set up ECV SSL service check

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" ""

To set up ECV reverse service check

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 /" ""

Testing /etc/bigd.conf syntax

To test /etc/bigd.conf syntax

You can test your ECV syntax in the bigd.conf file using the following bigd command:

 /sbin/bigd -d 

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.

Configuring persistence for e-commerce and other dynamic content sites

Persistence is another feature you can configure after you have completed the three main tasks of a basic configuration. This means you already have:

  • Configured virtual servers
  • Configured access to ports and services
  • Configured the timer settings.

    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:

  • SSL persistence
    SSL persistence is a type of persistence that tracks SSL connections using the SSL session ID, and it is a property of individual virtual servers. 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 Controller still recognizes the connection as being persistent based on the session ID.
  • Simple persistence
    Simple persistence supports TCP and UDP protocols, and it 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 Controller checks to see if that client previously connected, and if so, returns the client to the same node.

    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.

Setting up SSL persistence

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:

  • Turn SSL persistence on.
  • Set the SSL session ID timeout, which determines how long the BIG/ip Controller stores a given SSL session ID before removing it from the system.

To configure SSL persistence in the F5 Configuration utility

  1. In the navigation pane, click Virtual Servers.
    The Virtual Server screen opens and displays each virtual server's IP address and associated port number or service name in the Current List.
  2. Click the appropriate virtual server in the list.
    The Virtual Server Properties screen opens.
  3. In the Application Persistence box, click None. If you have already configured an application persistence method, the name of the method displays in this box.
    The Virtual Server Application Persistence screen opens.
  4. Click the SSL Persistence button.
  5. In the Timeout box, type the number of seconds that the BIG/ip Controller should store SSL sessions IDs before removing them from the system.
  6. Click the Apply button.

To configure SSL persistence on the command line

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

Setting up simple persistence

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.

Setting simple persistence on virtual servers

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.

To configure simple persistence for virtual servers in the F5 Configuration utility

  1. In the navigation pane, click the plus Virtual Servers.
    The Virtual Server screen opens.
  2. Select the virtual server for which you want to configure simple persistence.
    The Virtual Server Properties screen opens.
  3. In the Persistence section, type the following information:

    · 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.)

    · Mask
    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.

  4. Click the Apply button.

To configure simple persistence for virtual servers on the command line

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

Setting simple persistence on ports

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.

To configure simple persistence for ports in the F5 Configuration utility

  1. In the navigation pane, click the plus (+) next to Virtual Servers.
    The Virtual Server tree opens and displays the Ports option.
  2. Click Ports.
    The Global Virtual Ports screen opens.
  3. In the Port box, select the port number or service name for which you want to configure the simple persistence.
    The Global Virtual Port screen opens.
  4. In the Simple Persistence (seconds) box, type the number of seconds that you want the BIG/ip Controller to store persistent connection information.
  5. Click the Apply button.

To configure simple persistence for ports on the command line

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

Configuring and synchronizing redundant systems

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:

  • Synchronizing configurations between two controllers
  • Configuring fail-safe settings for the interfaces

Preparing to use the synchronization command

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:

  • Checks for a fail-over IP address for the other controller in BIG/db.
  • Verifies that the AllowHosts entry in the /etc/sshd_config file includes the IP address of the other controller in the redundant configuration.
  • Runs the ssh-keygen command which creates the security keys for the controller.
  • Shares the security keys with the other controller in the redundant system.

    To run the config_failover command, type the following command from the command line:

 config_failover

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.

Synchronizing configurations between controllers

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:

  • The common keys in BIG/db
  • /etc/bigip.conf
    The /etc/bigip.conf file stores virtual server and node definitions and settings, including node ping settings, the load balancing mode, and NAT and SNAT settings.
  • /etc/bigd.conf
    The /etc/bigd.conf file stores service check settings.
  • /etc/hosts.allow
    The /etc/hosts.allow file stores the IP addresses that are allowed to make administrative shell connections to the BIG/ip Controller.
  • /etc/hosts.deny
    The /etc/hosts.deny file stores the IP addresses that are not allowed to make administrative shell connections to the BIG/ip Controller.
  • User account files
  • /etc/ipfw.conf and /etc/ipfw.filt
    The /etc/ipfw.conf and /etc/ipfw.filt files store IP filter settings.
  • rc.sysctl
    The rc. sysctl file contains system control variable settings.
  • /etc/rateclass.conf
    The /etc/rateclass.conf file stores rate class definitions.
  • /etc/ipfwrate.conf and /etc/ipfwrate.filt
    The /etc/ipfwrate.conf and /etc/ipfwrate.filt files store IP filter settings for filters that also use rate classes.
  • /etc/snmpd.conf
    The /etc/snmpd.conf file stores SNMP configuration settings.

    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:

    bigpipe -s

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).

To synchronize the configuration in the F5 Configuration utility

  1. In the navigation pane, click the BIG/ip logo.
    The BIG/ip System Properties screen opens.
  2. On the toolbar, click the Sync Configuration button.
    The Sync Configuration screen opens.
  3. Click the Synchronize button.

To synchronize the configuration on the command line

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:

 bigpipe configsync

Configuring fail-safe settings

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.

Arming fail-safe on an interface

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.

To arm fail-safe on an interface in the F5 Configuration utility

  1. In the navigation pane, click NICs (network interface cards).
    The Network Interface Cards list opens and displays each installed NIC.
  2. Select an interface name.
    The Network Interface Card Properties screen opens.
  3. Check Arm Failsafe to turn on the fail-safe option for the selected interface.
  4. In the Timeout box, type the maximum time allowed for a loss of network traffic before a fail-over occurs.
  5. Click the Apply button.

To arm fail-safe on an interface 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

Addressing general networking issues

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:

  • Addressing routing issues
    There are a variety of routing configuration issues that you need to address. If you did not create a default route with the First-Time Boot utility, you must configure a default route for the BIG/ip Controller. You also must set up routes for the nodes that the BIG/ip Controller manages. You may also want to configure GateD, which allows dynamic routing information to automatically be updated on the BIG/ip Controller.
  • Configuring DNS on the BIG/ip Controller
    You may need to configure the BIG/ip Controller for DNS resolution or for DNS proxy, and you may even need to convert from rotary or round robin DNS.
  • Configuring email on the BIG/ip Controller
    There are some special requirements that you need to take into account when configuring email on the BIG/ip Controller.

Addressing routing 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:

  • Routing from a BIG/ip Controller to a gateway to the external network
  • Routing from content servers to the BIG/ip Controller
  • Routing from a BIG/ip Controller to content servers that are on different logical networks
  • Setting up dynamic routing with GateD

Routing from a BIG/ip Controller to a gateway to the external net

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.

To change the default route

  1. Open the /etc/netstart file in a text editor, such as vi or pico.
  2. Change the default route entry using the following syntax:
     defroute="<router IP>"
  3. Save and close the file.
  4. Reboot the BIG/ip Controller.

Routing from content servers to the BIG/ip Controller

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.

Routing between a BIG/ip Controller and content servers on different logical networks

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:

  • 192.168.5/24 and 192.168.6/24 are on the same LAN (either sharing media or with a switch or hub between them).
  • 192.168.5/24 and 192.168.6/24 are on two different LANs with a router between them.

Case 1: Same LAN

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.

Case 2: Different LANs

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.

Setting up dynamic routing with GateD

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:

  • You need to create the GateD configuration file, /etc/gated.conf.
  • You need to start the GateD daemon.
  • You need to edit the /etc/netstart file.

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.

To create the GateD configuration file

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.

To immediately start the GateD daemon on the BIG/ip Controller

Once you create the GateD configuration file, you need to start the GateD daemon on the command line using the following command:

 bigip# gated

To enable starting GateD each time the BIG/ip Controller starts

To start GateD each time the BIG/ip Controller starts, change the gated variable in the /etc/netstart file as shown below:

 gated=YES

Configuring DNS on the BIG/ip Controller

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:

  • Configuring DNS resolution on the BIG/ip Controller
  • Configuring DNS proxy
  • Converting from rotary or round robin DNS

Configuring DNS resolution

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:

 nameserver <DNS_SERVER_1>
 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.0.0.1
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    
hosts dns

Configuring DNS proxy

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:

 forwarders <DNS_SERVERS> 
 options forward-only

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.

Converting from rotary or round robin DNS

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

Configuring Email

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.

Finding the mail exchanger for your domain

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.

To find the mail exchanger

  1. First you need to identify the default server name for your domain. From a workstation capable of name resolution, type the following on the command line:
     nslookup
  2. The command returns a default server name and corresponding IP address:
    Default Server: <server name>
    Address: <server addr>
  3. Next, use the domain name to query for the mail exchanger:
     set q=mx
    <domain name>

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 = 192.17.112.1
ns1.bigip.net internet address = 192.17.112.2
ns2.bigip.net internet address = 192.17.112.3

Setting up Sendmail

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.

To set up and start Sendmail

  1. Copy /etc/sendmail.cf.off to /etc/sendmail.cf.
  2. To set the name of your mail exchange server, open the /etc/sendmail.cf and set the DS variable to the name of your mail exchanger. The syntax for this entry is:
     DS<MAILHUB_OR_RELAY>
  3. Save and close the /etc/sendmail.cf file.
  4. To allow Sendmail to flush outgoing messages from the queue for mail that cannot be delivered immediately, open the /etc/crontab file, and change the last line of the file to read:
     0,15,30,45 * * * *   root /usr/sbin/sendmail -q > /dev/null 2>&1
  5. Save and close the /etc/crontab file.
  6. To prevent returned or undelivered email from going unnoticed, open the /etc/aliases file and create an entry for root to point to you or another administrator at your site.
     root: networkadmin@SiteOne.com
  7. Save and close the /etc/aliases file.
  8. You now need to run the newaliases command to generate a new aliases database that incorporates the information you added to the /etc/aliases file.
  9. To turn Sendmail on, either reboot the system or type the following command:
     /usr/sbin/sendmail -bd -q30m

Basic configuration examples

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:

  • A basic e-commerce and web server combination
  • A simple intranet

    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.

A basic web site and e-commerce configuration

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.

Setting up the topology

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.

Figure 3.6 A basic configuration

The virtual servers that you define always include three basic elements:

  • virtual IP address
    This is the IP address that is registered with DNS and associated with your site's domain name. In our example, both www.MySite.com and store.MySite.com use the same IP address: 192.168.200.10. Both domain names would presumably have to be registered with DNS to resolve to that IP address.
  • Port
    The port that hosts the specific service supported by your site. In our example, we have two different sites that support two different ports: port 80 and port 443.
  • Servers that host your site
    The list of physical servers that actually host your site connections. For a given server, you list each IP address and port number pair, referred to as a node, that the server handles. Even though our example includes only three servers, it actually has four nodes:
    • Server 1 hosts only one node: 192.168.100.1:80.
    • Server 2 hosts two nodes, one for each service it supports: 192.168.100.2:80 and 192.168.100.2:443.
    • Server 3 hosts only one node: 192.168.100.3:443.

      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.

Using additional features

In this type of configuration, you might want to take advantage of the following BIG/ip Controller features:

  • Extended Content Verification
    Verifies that the web servers are not only up and running, but also able to send valid content to clients. For example, you could use Extended Content Verification to make sure that www.MySite.com returns its home page rather than an HTTP 404 error.
  • Persistence
    Allows returning e-commerce customers to bypass load balancing and connect to the back-end server to which they originally connected that may contain user-specific information. In our example, store.MySite.com provides the ability for users to fill a shopping cart, disconnect from the site, and then return up to 24 hours later to purchase the items. When the user returns to purchase the items, the user may need to go to the same back-end server, depending on how the e-commerce site is set up.
  • Network Address Translation
    Allows you to make direct administrative connections to the web servers through the BIG/ip Controller. If your administrative workstation is on the network connected to the BIG/ip Controller's external interface, and administrative workstations frequently are, this feature is essential.
  • Secure Network Address Translation (SNAT)
    Allows you to make map internally routable IP addresses to an externally routable IP address. SNATs do not allow incoming connections.

A basic intranet configuration

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:

  • Connections to the company's intranet web site
    The load balancing for the company's intranet web site is similar to basic Internet web site load balancing. The BIG/ip Controller simply load balances the two web servers that host the company intranet web site.
  • Connections to hosts on the Internet
    In this example, the BIG/ip Controller provides load balancing for connections bound for the Internet. However, the example shows a somewhat sophisticated setup where the BIG/ip Controller actually intercepts HTTP traffic and directs it to a special cache server. Only clients using protocols other than HTTP, such as FTP or SMTP email, get load balanced to one of the two firewalls that lead to the Internet. This greatly reduces the number of concurrent connections that the firewalls have to maintain. Clients looking to retrieve web content get the content from the cache server itself, instead of the actual web site host. If the cache server does not have the content that the client is looking for, the cache server retrieves the content from the real web site on behalf of the client and then forwards it to the client.

Setting up the topology

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.

Figure 3.7 A basic intranet configuration

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:

  • Port-specific wildcard virtual servers
    A port-specific wildcard virtual server uses the default IP address, but it has a specific port number, and it only handles traffic associated with that port number. In our preceding example, the port-specific wildcard virtual server captures all outbound traffic that uses port 80 and directs it to the cache server.
  • Default wildcard virtual servers
    A default wildcard virtual server is one that uses only port 0. Port 0, like the 0.0.0.0 IP address, is a catch-all match for outgoing traffic that does not match any standard virtual server or any port-specific wildcard virtual server. Default wildcard virtual servers typically handle traffic only for firewalls or routers. In the preceding example, the default wildcard virtual server load balances the intranet's firewalls that connect to the Internet.

Using additional features

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:

  • State mirroring
    This feature is available only for redundant BIG/ip Controller systems, and it greatly enhances the reliability of your network. A redundant system runs two BIG/ip Controllers at the same time. One unit actively handles all connection requests, and the other unit acts as a standby that immediately takes over if the active unit fails and reboots. The state mirroring feature allows the standby unit to maintain all of the current connection and persistence information. If the active unit fails and the standby unit takes over, all connections continue, virtually uninterrupted. This is especially useful for long-lived connections, such as FTP connections which would otherwise have to re-establish an entire transfer session.
  • Destination address affinity
    Allows the BIG/ip Controller to cache content on specified cache servers by sending all requests for the same server to the same node. This avoids caching the same content on multiple cache servers. Because the above example includes only one cache server, you would not actually implement this feature in that example. However, the destination address affinity feature is very useful for users who work with multiple cache servers in a similar intranet scenario. Caching specific information on the same cache server saves disk space on your cache servers.
  • IP address filtering
    Allows you to deny connections going to or coming from specific IP addresses. This feature is useful if you are experiencing denial-of-service attacks from hostile sources. You can set up an IP filter to ignore traffic coming in from the hostile IP address.