4

Getting Started with a Basic Configuration

• Setting up a basic configuration
• Configuring virtual servers
• Allowing access to ports and services
• Configuring the timer settings
• Changing the load balancing mode
• Configuring network address translations and IP forwarding for nodes
• Configuring Extended Content Verification service checking
• Configuring persistence for e-commerce and other dynamic content sites
• Configuring and synchronizing redundant systems
• Addressing general networking issues

Setting up a basic configuration

This chapter covers the three essential configuration tasks that all users need to do, 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 configuration. Then turn to Chapter 5, Working with Special Features, for details on using advanced features.

A basic configuration just 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 the simplest configuration, you need to do only the following three tasks. Other BIG/ip Controller settings, such as the load balancing mode, are either pre-configured or are not required for simple configurations.

• 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 services
  The services and ports on a BIG/ip controller are locked 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 to network access.
• Configure the timer settings
  The BIG/ip Controller supports several timer settings, but there are only two that you need to set for a simple configuration. 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 on to a simple configuration, including:

• Using an alternate load balancing mode
• Setting up network address translation (NAT) or IP forwarding to allow direct connections to and from nodes
• Configuring extended content verification (ECV) to allow the BIG/ip Controller to verify that a web server or mail server is responding to requests
• Setting 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 that they last connected to
• Setting up redundant BIG/ip Controller systems

Tip: When you set configuration options in 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 appropriate command.

The following table, Table 4.1, describes the different virtual server configurations available on the BIG/ip Controller.

Virtual server properties

	Security	Routable address (**) required	Protocols	NT Domain support	Active FTP support	Connections	Ports	Setup for spec- ific nodes or hosts
NAT	Medium	No	TCP, UDP	No	No	Not connetion oriented	Does not matter	Yes
SNAT	High	No	TCP, UDP	No	Yes	Outbound only	Does not matter	Yes, but can use wildcard
IP forwarding	Low	Yes	Any IP protocol	Yes	Yes	Not connetion oriented	Does not matter	No
Virtual server	High	No	TCP, UDP	No	Yes	Inbound only	Uses specific ports or wildcard	Yes, but can use wildcard

Note: The routable address column in Table 4.1 refers to whether or not routable addresses are required on the internal network.

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.
• If Transparent Node mode is necessary for your implementation.

  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 use a special wildcard IP address (0.0.0.0), and you can use them only if you have activated Transparent Node mode.

  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. You can also include VLAN tags in a virtual server definition (for details, see Setting up 802.1q VLAN trunk mode, on page 5-52).

Warning: If you use VLAN tags, you must consistently use VLAN tags throughout the configuration.

Using optional virtual server properties

When you define a virtual server, you can set optional virtual server properties, such as network address translation or extended content verification. If you are planning on using any of the following features, you may want to read the corresponding section before you actually begin the virtual server configuration process:

• Network address translations for nodes (see Configuring network address translations and IP forwarding for nodes, on page 4-23)
• Extended Content Verification service checking (see Configuring Extended Content Verification service checking, on page 4-30)
• Persistence for connections that should return to the node that they last connected to (see Configuring persistence for e-commerce and other dynamic content sites, on page 4-37)

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 actually add the special ssl keyword to the end of the command when you define the virtual server.

Activating Transparent Node mode

If you are load balancing only content servers, you can skip this step and immediately begin configuring virtual servers. If you are load balancing transparent firewalls, routers, cache servers, or proxy servers, you need to turn Transparent Node mode on before you begin configuring virtual servers. Transparent Node mode allows you to define special wildcard virtual servers that load balance transparent network devices.

Note that when Transparent Node mode is on, you can still configure standard virtual servers that load balance content servers, as well as non-transparent firewalls and proxy servers.

To activate Transparent Node mode 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 Advanced Properties screen opens.
3. Check the Transparent Node Mode box.
4. Click the Apply button.

To activate Transparent Node mode from the command line

Enter the following sysctl command:

  sysctl -w bigip.bonfire_mode=1  

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 your 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 External Interface, select the external 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 (see Reducing ARP traffic on the external network, on page 5-47 for details).
8. In the Node Address box, enter the IP address or host name of the first node to which the virtual server maps.
9. 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.
10. Click the Add button to save the virtual server settings.
    Once you click the Add button, you return to the Virtual Servers screen.
11. To add additional nodes to the virtual server mapping, click the virtual server in the list.
    The Virtual Server Properties screen opens.
12. On the toolbar, click Add Node.
    The Add Node screen opens.
13. In the Add Node screen, type the IP address and port number for the node.
14. Click the Add button to save the node to the virtual server mapping.
    Once you click the Add button, you return to the Virtual Server Properties screen. Repeat steps 12 through 14 until you have defined all nodes that should be included in the virtual server mapping

To define a standard virtual server mapping on the command line

Enter 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 note that 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 essentially 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.

When you are load balancing transparent nodes, a client's destination IP address is going to be random--the client is looking to connect 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 providing a generic IP address of 0.0.0.0 that the BIG/ip Controller can use for address matching. For example, when the BIG/ip Controller does not find a 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 to one of the firewalls or routers that the wildcard virtual server load balances, which in turn forwards the client 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.

When you define transparent nodes that need to handle more than one type of service, such as a firewall or a router, we recommend that you define the node port number as 0.

Note: When you define a node with port 0, and you wish to perform a service check on that node, you must configure service check intervals and timeouts using port 0. Then, you can configure a simple TCP service check. See Service checking for wildcard servers and ports, on page 4-20, for more details.

Defining the wildcard virtual server mappings

All wildcard virtual server mappings must use an IP address of 0.0.0.0.

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 of 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 broadcast address based on the IP address and netmask 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 virtual server that handles all types of services.
7. For External Interface, choose the external interface on which you want to create the virtual server. Select default to allow the F5 Configuration utility to select an external interface to choose 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 creates no alias and generates no ARPs for the virtual IP address.
8. In the Node Address box, enter the address of the first node to which the virtual server maps.
9. In the Node Port box, type the node port number, or select the service from the drop-down list. Note that port 0 defines a node that handles all types of services.
10. Click the Add button to save the virtual server.
    Once you click the Add button, you return to the Virtual Servers screen.
11. To add additional nodes to the virtual server mapping, click a virtual server in the list.
    The Virtual Server Properties screen opens.
12. On the toolbar, click Add Node.
    The Add Node screen opens.
13. In the Add Node screen, enter the IP address and service or port number for the node.
14. Click the Add button to save the node to the virtual server mapping.
    Once you click Add, you return to the Virtual Server Properties screen. Repeat steps 12 through 14 until you have defined all nodes that should be included in the virtual server mapping.

To define a wildcard virtual server mapping on the command line

Enter the bigpipe vip command as shown below. Note that all wildcard virtual servers use 0.0.0.0 as the IP address.

  bigpipe vip 0.0.0.0:<port> define <node IP>:<port> \
 <node IP>:<port>...  <node IP>:<port>  

For example, the following command defines a wildcard virtual server that maps to three firewalls. Because the nodes are firewalls and need to handle a variety of services, both the virtual server and the nodes are defined using port 0.

  bigpipe vip 0.0.0.0:0 define 192.168.10.01:0 \
 192.168.10.02:0 192.168.10.03:0  

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 defined, you must allow access to each port that the virtual servers use.

Tip: Virtual servers using the same service actually share a port on the BIG/ip Controller. 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.

Note: To enable access to wildcard virtual servers, you must enable port 0.

To allow access to services in the F5 Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Server list opens and displays each virtual server's IP address and associated port number or service name.
2. Click the a virtual server in the list.
   The Virtual Server Properties screen opens.
3. In the Port box, click the port number or service name.
   The Global Virtual Port screen opens.
4. In the Global Virtual Port screen, check Enabled to open the port and allow access to the service.
5. Click the Apply button.
6. Return to the virtual server list by clicking Virtual Servers in the navigation pane.
7. Click the next virtual server in the list and repeat steps 2 through 7 until you have opened access to all the services that your virtual servers use.

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, if you are enabling 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

There are two essential timer settings that you need to configure:

• The node ping timer defines how often the BIG/ip Controller pings node addresses to verify whether a node is up or down, and also defines how long the BIG/ip Controller waits for a response from a node before determining that the node is unresponsive and should be marked down.
• The idle connection timer defines how long an inactive connection is allowed to remain open before the BIG/ip Controller reaps 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 on 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. Click the BIG/ip logo.
   The BIG/ip System Properties screen opens.
2. 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 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 actually use a series of 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 series of 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 Virtual Servers.
   The Virtual Server list opens and displays each virtual server's IP address and associated port number or service name.
2. Click a virtual server in the list.
   The Virtual Server Properties screen opens.
3. In the Port box, click the port number or service name.
   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.
7. Return to the virtual server list by clicking Virtual Servers in the navigation frame.
8. Click the next virtual server in the list and repeat steps 2 through 7 until you have opened access to all the services that your virtual servers use.

To set TCP idle connection timers on the command line

You can define a TCP idle connection timeout for one or more ports at a time using the bigpipe treaper command. For HTTP connections we recommend only 60 seconds, but for other services such as Telnet we recommend higher settings.

  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 80:

  bigpipe udp 80 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 check: 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 4-30).

Note that each individual node managed by the BIG/ip Controller has its own service check timer settings.

Note: When you define a node with port 0, and you wish to perform a service check on that node, you must configure service check intervals and timeouts using port 0. Then, you can configure a simple TCP service check. See Service checking for wildcard servers and ports, on page 4-20.

To set the service check timer in the F5 Configuration utility

1. In the navigation frame, click Nodes.
   The Nodes screen opens.
2. Click a node in the list.
   The Node Properties 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.
7. Return to the list of nodes by clicking Nodes in the navigation pane.

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

The simple keyword is necessary to perform simple service checks on nodes with wildcard ports. 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, if a wildcard server is defined with a non-wildcard port

  bigpipe vip 0.0.0.0:0 define n1:0  

then to configure the check on it, use the simple keyword to designate the wildcard <server:><port> and <check port>:

  simple n1:0 80  

Changing the load balancing mode

The default load balancing mode 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 on 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 set, where the number of connections that each machine receives over time is proportionate to the ratio weight you defined 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 sophisticated dynamic load balancing modes that may be suitable for your site. Refer to Chapter 5, Using specialized load balancing modes, 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 do two separate configuration tasks:

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

Switching to Ratio mode

The first task you should do is to 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. Click the BIG/ip logo.
   The BIG/ip System Properties screen opens.
2. In the Load Balancing Mode box, choose Ratio.

To switch the system to Ratio mode on the command line

Enter the following bigpipe command:

  bigpipe lb ratio  

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 a 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, click the node for which you want to set the ratio weight.
   The Node Properties screen opens.
3. In the Address box, click the node address or host name.
   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  

Configuring network address translations and IP forwarding for nodes

The IP addresses that identify nodes on the BIG/ip Controller's internal network need not be routable on the BIG/ip Controller's 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.

Network address translation resolves this problem. Network address translations (NATs) assign 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 is a feature that provides similar functionality, and you may want to use it if your network does not support NAT.

There are actually three configuration options, 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.
• 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.
• 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 essentially 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 4-28) that can help protect your nodes.

Warning: NATs and SNATs do not support the NT Domain or CORBA protocols. Instead, you need to configure IP forwarding (see Setting up IP forwarding, on page 4-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.

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 for this. 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 External Interface box, you can choose the external interface on which the NAT address is to be used. Note that this setting only applies if your BIG/ip Controller has more than one external interface card.
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. The SNAT address itself, however, must be a unique IP address that does not match an IP address used by any virtual or physical servers in your network.

SNAT addresses have global properties that apply to all SNATs defined in the configuration.

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.

To configure SNAT global properties in the F5 Configuration utility

1. In the navigation frame, 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 each node using a SNAT. Note that 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 TCP connections initiated by a node using a SNAT are allowed to remain idle.
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

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 Node Addresses box, type the IP address of the node or nodes that are assigned to the SNAT. If you are typing multiple node addresses, separate each individual address with a semicolon.
4. In the SNAT Address box, type the IP address that you want to use as the alias IP address for the node(s).
5. In the External Interface box, you can choose the external interface on which the NAT address is to be used. Note that this setting only applies if your BIG/ip Controller has more than one external interface card.
6. 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 translations for two nodes:

  bigpipe snat map 192.168.75.50 192.168.75.51 to 192.168.100.10  

Setting up IP forwarding

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 essentially 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 your only option for direct access to nodes.

To set up IP forwarding, you need to do 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.
• Address routing issues
  You probably have to change the routing table for the router on the BIG/ip Controller's external network. The router needs to direct connection requests for nodes to the BIG/ip Controller, which in turn directs the requests to the nodes themselves.

Turning IP forwarding on

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. 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 Appendix C, Setting BIG/ip system control variables.

Addressing routing issues for IP forwarding

Once you turn IP forwarding on, you probably need to change the default router's routing table. Connection requests 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 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. The following section focuses on setting up ECV for web servers. For details about using advanced ECV service check options, see Setting up advanced ECV service checks, on page 5-3.

Note: It is important to note that the intervals and timeouts for simple 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 4-15.

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 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 5000 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. 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. For example, the most common send string is "GET /" which simply retrieves the default HTML page for a web site. The corresponding receive string could be any 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 double quotation marks.

  "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 double quotation marks.

For example, the following receive expression looks 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 double 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.

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 configure the options in, the steps are the same.

To set up ECV service check in the F5 Configuration utility

1. In the navigation frame, click Nodes.
   The Nodes screen opens.
2. Click a node in 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 or service name in the Port box.
4. In the Type box, choose the type of ECV service check you want to set up: ECV normal, ECV reverse, or ECV SSL.
5. In the First 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 /  

1. In the Second String 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!  

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

  reverse 80 "GET /" ""  

Testing /etc/bigd.conf syntax

To test /etc/bigd.conf syntax

You can test your /etc/bigd.conf file syntax using the following bigd command:

  /sbin/bigd -d   

This command parses the file, compiles any regular expressions, 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. See Appendix D, bigd, for details.

Configuring persistence for e-commerce and other dynamic content sites

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 sophisticated 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 Using advanced persistence options, on page 5-11.

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 three things:

• Turn SSL persistence on.
• Set the SSL persistence timer, which determines how long the BIG/ip Controller considers a given SSL session ID to be valid.
• 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.

Tip: If you want to turn persistence on for an existing virtual server, you may want to use the F5 Configuration utility, instead of the BIG/pipe command line utility. In the F5 Configuration utility, you simply set virtual server properties, whereas on the command line you need to redefine the virtual server itself.

To configure SSL persistence in the F5 Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Server list opens and displays each virtual server's IP address and associated port number or service name.
2. Click the first virtual server in the list.
   The Virtual Server Properties screen opens.
3. Check the Enable Session ID Persistence box.
4. In the Persistence Time box, type the number of seconds that the BIG/ip Controller should consider SSL session IDs to be valid.
5. In the Session ID 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 Virtual Servers.
   The Virtual Server list opens and displays each virtual server's IP address and associated port number or service name.
2. Click a virtual server.
   The Virtual Server Properties screen opens.
3. In the Timeout box, type the number of seconds that you want the BIG/ip Controller to store persistent connection information.
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>... <virt IP>:<port> persist <timeout>  

For example, the following command sets simple persistence for the virtual server, where the persistent connection information expires after one hour (3600 seconds).

  bigpipe vip 192.168.100.10:80 persist 3600  

Setting simple persistence on ports

Defining persistence on a port requires you only to 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 Virtual Servers.
   The Virtual Server list opens and displays each virtual server's IP address and associated port number or service name.
2. Click any virtual server that uses the port for which you want to turn persistence on.
   The Virtual Server Properties screen opens.
3. In the Port box, click the port number.
   The Global Virtual Port Properties screen opens.
4. In the Simple Persistence 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

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 config sync feature.

There are two aspects about working with redundant systems:

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

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:

• /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/bigip.interfaces
  The /etc/bigip.interfaces file stores interface configuration information, such as failsafe timeouts.
• /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/netstart
  The /etc/netstart file stores basic system start up settings.
• /etc/ipfw.conf
  The /etc/ipfw.conf file stores IP filter settings.
• /etc/rateclass.conf
  The /etc/rateclass.conf file stores rate class definitions.
• /etc/ipfwrate.conf
  The /etc/ipfwrate.conf file stores 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 config sync feature.

Warning: If you are synchronizing to 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. Click the BIG/ip logo.
   The BIG/ip System Properties screen opens.
2. On the toolbar, click the Sync Configuration 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. The way in which it attempts to generate traffic depends on whether it is an external or an internal interface.

• External interface
  For external interfaces, the BIG/ip controller attempts to generate network traffic by issuing ARP requests for the default router. Any traffic through the interface, including a response to the ARP request, averts a fail-over.
• Internal interface
  For internal interfaces, the BIG/ip controller attempts to generate network traffic by pinging each node address included in its configuration. Any traffic through the interface, including a reply to one or more of the pings, averts a fail-over.

  If the BIG/ip Controller cannot generate 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. Also note that you cannot arm fail-safe on an internal interface card before you have configured virtual servers and nodes.

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. Click 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, enter the maximum time allowed for a loss of network traffic before a fail-over occurs.
5. In the Shared IP Alias box, enter the IP address shared for the corresponding interface on both BIG/ip controllers.
6. 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 <ifname> failsafe arm  

  bigpipe interface timeout <seconds>  

For example, say you have an external interface named exp0 and an internal interface named exp1. To arm the fail-safe option on both cards, you need to issue the following two commands:

  bigpipe interface exp0 failsafe arm  

  bigpipe interface exp1 failsafe arm  

Addressing general networking issues

When you install and configure the BIG/ip Controller, you may need to address one or more of the following networking issues:

• Addressing routing issues
  There are a variety of router configuration issues that you may need to address. You need to configure a default route for the BIG/ip Controller, and you may also need to 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 sendmail on the BIG/ip Controller
  There are some special requirements that you need to take into account when configuring Sendmail 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.

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 are 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 its external interfaces 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 internetwork
• 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.

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

1. Save and close the file.
2. Reboot the BIG/ip Controller.

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 /etc/rc.local file using the following syntax:

  route add -net 192.168.6 -interface exp1  

Note: You must have the interface defined correctly in the /etc/hosts file in order to use this syntax.

If you are working with a redundant system, you need to set up an additional shared IP alias in the /etc/bigip.interfaces file using the following syntax:

  <ifname> <ip address> <netmask> <broadcast address>  

For example, an additional shared IP alias entry in the /etc/bigip.interfaces for the interface exp1 might look like this:

  "exp1" "192.168.6.254" "255.255.255.0" "192.168.6.255"  

Note that you should always include shared IP aliases in the /etc/bigip.interfaces file, so that each BIG/ip Controller in the redundant system knows to use them when it is active, and not use them when it is standby.

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 you 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 enable 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 enable 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 Sendmail

You can configure the BIG/ip controller to send email notifications to you, or to other administrators. 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 Configuring Sendmail.

Finding the mail exchanger for your domain

You can use the nslookup command on any workstation that is configured for 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:

  bigip: /etc# nslookup  

1. The command returns a default server name and corresponding IP address:
   Default Server: <server name>
   Address: <server
2. 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 4.1 lists bigip.net as the preferred mail exchanger.

 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

Figure 4.1 Sample mail exchanger information

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>  

1. Save and close the /etc/sendmail.cf file.
2. 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  

1. Save and close the /etc/crontab file.
2. 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  

1. Save and close the /etc/aliases file.
2. 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.
3. To turn Sendmail on, either reboot the system or type the following command:

  /usr/sbin/sendmail -bd -q30m  

Configuring 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 <DOMAIN_NAME_1> <DOMAIN_NAME_2> with a list of domain names to use as defaults. This list is used to resolve hosts when only a host name, and not an FQDN, is used. When you enter domain names in this file, separate each domain name with a space.

An sample configuration file is shown in Figure 4.2 below.

  ; 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   

Figure 4.2 Sample /etc/resolv.conf file

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.conf file first, and then checks for DNS entries. See Figure 4.3, make the following entry in the /etc/irs.conf file:

 hosts           local   continue    
   hosts           dns  

Figure 4.3 Sample entry for the /etc/irs.conf file

Configuring DNS proxy

You can configure the BIG/ip controller as a DNS proxy or forwarder. This is useful for providing DNS resolution for servers and other equipment behind the BIG/ip controller that might want to lookup a domain name or IP address.

To configure DNS proxy, you simply create a /etc/named.boot file that contains only 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 phony domain names and network numbers for the servers and other equipment behind the BIG/ip Controller. Refer 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 4.4:

 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  

Figure 4.4 Sample zone table with two Web sites and four servers

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 4.5

 www.SiteOne.com  IN A 192.168.100.231    
   www.SiteTwo.com  IN A 192.168.100.232  

Figure 4.5 Sample zone table with two Web sites and two servers.