5

Working with Special Features

• Introducing special features
• Using advanced service check options
• Using advanced persistence options
• Using advanced redundant system features
• Using advanced Transparent Node mode options
• Using specialized load balancing modes
• Controlling network access and traffic flow with filters
• Working with more than two interface cards
• Optimizing large configurations
• Using alternative network configurations

Introducing special features

In addition to the basic setup features available on the BIG/ip Controller, a number of special setup features can be used to optimize your network. This chapter describes the special setup options available on the BIG/ip Controller. These features are optional, and may not be required in your implementation of the BIG/ip Controller. The following topics are described in this chapter:

• Advanced software-based features
• Alternative BIG/ip Controller hardware configurations
• Optimized large configurations
• Alternative network configurations

Using advanced service check options

You can use advanced service check options to verify that your content servers are functioning properly. There are two types of advanced service checks: Extended Content Verification (ECV) and Extended Application Verification (EAV). This section describes how to set up, and use, these types of service checking. This section also includes information for setting up EAV service checks for SQL based services.

Setting up advanced ECV service checks

In addition to verifying content on web servers, you can use Extended Content Verification (ECV) service checks to verify connections to mail servers and FTP servers through transparent nodes. If you want to set up ECV service checks through a transparent node to these types of servers, there are certain special issues that you need to address.

Configuring ECV for transparent nodes

You can set up ECV to verify that a transparent node is functioning properly. To check if a transparent node is functioning, you can add an entry to the /etc/bigd.conf file that allows you to retrieve content through the node.

You can use a text editor, such as vi or pico, to manually create the /etc/bigd.conf file, which stores ECV information. To create the entry for checking a transparent node, use the following syntax:

transparent <node ip>:<node port> http://www-address[:port][/path] ["recv_expr"]

You can also use the following syntax for this entry:

transparent <node ip>:<node port> <dest ip>[:dest port][/path] ["recv_expr"]

For more information about these configuration entries, please refer to Table 5.1.

Extended content verification configuration entries.

Configuration Entry	Description
transparent	Transparent is required at the beginning of the entry.
node ip	The IP address, in dotted decimal notation, of the transparent firewall or proxy. This IP cannot be a wild card IP (0.0.0.0). Note that the node must be defined as a node in a VIP definition. Typically this would be a wild card VIP (0.0.0.0). This entry can also be specified as a fully qualified domain name (FQDN). In order to use an FQDN, the BIG/ip Controller must be configured for name resolution.
node port	This entry is the node port to use for the ECV check. This port can be zero. This entry can be numeric or can use a well-known service name, such as http or smtp.
dest ip:dest port /URL	This is the combination of the destination, in dotted decimal notation, and port number of the destination against which the ECV service check is performed. The IP address cannot be a wild card (0.0.0.0). The port number is optional. The port can be specified as any non-zero numeric port number, or specified as a well-known port name, such as http or smtp. The URL is an optional standard HTTP URL. If you do not specify a URL, a default URL is retrieved using the HTTP 1.0 request format. This entry can also be specified using a complete URL with an embedded FQDN. This entry cannot be longer than 4096 bytes. In order to resolve an FQDN, the BIG/ip Controller must be configured for name resolution.
recv string	This string is optional. If you specify a string, the string you specify is used to perform standard ECV verification. This entry must be enclosed in quotation marks, and cannot be longer than 128 bytes.

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.

Introducing EAV service checks

Extended Application Verification (EAV) is a sophisticated type of service check typically used to confirm whether an application running on a node is responsive to client requests. To determine whether a node application is responsive, the BIG/ip Controller uses a custom program referred to as an external service checker. An external service checker program essentially provides the option to customize service check functionality for the BIG/ip Controller. It is external to the BIG/ip system itself, and is usually developed by the customer. For example, you can use an external service checker to verify Internet or intranet applications, such as a web application that retrieves data from a back-end database and displays the data in an HTML page.

An external service checker program works in conjunction with the bigdnode daemon, which verifies node status using node pings and service checks. If you configure external service check on a specific node, the bigdnode daemon checks the node by executing the external service checker program. Once the external service checker executes, the bigdnode daemon looks for output written by the external service checker. If the bigdnode daemon finds output from the external service checker, it marks the node up. If it does not find output from the external service checker, it marks the node down. Note that bigdnode does not actually interpret output from the external service checker; it simply verifies that the external service checker created output.

Note: External service checker programs are custom programs that are developed either by the customer, or by the customer in conjunction with F5 Networks.

Setting up EAV service checks

An Extended Application Verification service check is a service check that is performed by a custom application. There are four tasks required to implement EAV service checks on the BIG/ip Controller:

• Verify that your external service checker program meets certain requirements, such as creating a pid file.
• Install the external service checker program on the BIG/ip Controller.
• Allow EAV service checks in the BIG/ip configuration.
• Configure the specific nodes to use the EAV service check.

Verifying external service checker requirements

Extended Application Verification (EAV) is intended to provide maximum flexibility. The external service checker programs that you create can use any number of methods to determine whether or not a service or an application on a node is responsive. The external service checker must, however, meet the following minimum requirements:

• The external service checker must use a pid file to hold its process ID, and the pid file must use the following naming scheme:
  /var/run/pinger.<ip>..<port>.pid.
• As soon as the external service checker starts, if the pid file already exists, the external service checker should read the file and send a SIGKILL command to the indicated process.
• The external service checker must write its process ID to the pid file.
• If the external service checker verifies that the service is available, it must write standard output. If the external service checker verifies that the service is not available, it cannot write standard output.
• The external service checker must delete its pid file before it exits.

  The BIG/ip Controller includes a several sample external service checker scripts for HTTP, NNTP, SMTP, and POP3. These scripts can be found in the following location:

/usr/local/lib/pingers/sample_pinger

The sample service checker, shown in Figure 5.1, is included with the BIG/ip Controller.

 # these arguments supplied automatically for all external pingers:    
   # $1 = IP (nnn.nnn.nnn.nnn notation or hostname)    
   # $2 = port (decimal, host byte order)    
   # $3 and higher = additional arguments    
   #    
   # In this sample script, $3 is the regular expression    
   #    
       
   pidfile="/var/run/pinger.$1..$2.pid"    
       
   if [ -f $pidfile ]    
   then    
      kill -9 `cat $pidfile` > /dev/null 2>&1    
   fi    
       
   echo "___FCKpd___0quot; > $pidfile    
       
   echo "GET /" | /usr/local/lib/pingers/nc $1 $2 2> /dev/null | \ grep -E -i $3 > /dev/null    
       
   status=$?    
   if [ $status -eq 0 ]    
   then    
       echo "up"    
   fi    
   rm -f $pidfile  

Figure 5.1 The HTTP external service checker program

Installing the external service checker on the BIG/ip Controller

To install an EAV service check script, place it in the /usr/local/lib/pingers directory. This is the default location for external service checker applications. You can install external service checker applications to other directory locations if desired.

Allowing EAV service checks

Once you install an external service checker on the BIG/ip Controller, you need to add an entry to the /etc/bigd.conf file. The standard syntax of the /etc/bigd.conf file includes the following lines:

active [<node_ip>:]<port> ["<send_string>" ["<recv_pattern>"]]

reverse [<node_ip>:]<port> ["<send_string>" ["<recv_pattern>"]]

ssl [<node_ip>:]<port> ["<send_string>" ["<recv_pattern>"]]

To allow external service checking, you need to add the following entry to the /etc/bigd.conf file:

external [<node_ip>:]<port> [ <path> ]["<argument_string>"]

The <path> variable can be an absolute or a relative path to the external checker application. Absolute paths should begin with a slash ("/"). Other paths are relative to the directory default directory, /usr/local/lib/pingers.

The "<argument_string>" variable must consist of exactly one string in quotation marks. The string may include any number of arguments, delimited in the usual way by white space, for example:

active n1:80 "GET /" .html"

external n1:8000 "my_pinger -a 600 -b"

In the above example, the BIG/ip Controller uses HTTP to check port 80, but runs the script /usr/local/lib/pingers/my_pinger to check port 8000, with additional arguments.

In the following example, there are three nodes on which the BIG/ip Controller checks port 8000. The BIG/ip Controller runs a separate copy of the external service checker named my_pinger for each node:

external n1:8000 "my_pinger -a -b"

external 8000 "my_pinger -b"

In this example, the first entry specifies how to ping port 8000 on node n1. The second entry specifies how to ping port 8000 on any other node.

Configuring specific nodes to use EAV service check

The BIG/ip Controller performs the external service check at specified intervals. The BIG/ip Controller actually uses the service ping interval, which is set using the bigpipe tping_svc command.

The external service checker runs as root. The BIG/ip Controller starts an external service checker using the following shell command:

<path> <node_ip> <port> [ <additional_argument> ... ]

For the case of the example shown above, the appropriate command would be:

/usr/local/lib/pingers/my_pinger n1 8000 -a 600 -b

The BIG/ip Controller inserts the node IP and port number before the additional arguments that are specified in the /etc/bigd.conf file.

Note that the standard input and output of an external service checker are connected to bigdnode. The bigdnode does not write anything to the external service checker's standard input, but it does read the external service checker's standard output. If bigdnode is able to read any data from the external service checker program, the particular service is considered up.

EAV service check for SQL-based services

This section describes how to set up the BIG/ip Controller to perform EAV service checks on SQL-based services such as Microsoft SQL Server versions 6.5 and 7.0, and also Sybase.

The service checking is accomplished by performing an SQL login to the service. If the login succeeds, the service is considered up, and if it fails, the service is considered down. An executable program, tdslogin performs the actual login.

1. Test the login manually:

   cd /usr/local/lib/pingers

   ./tdslogin 192.168.1.1 1433 mydata user1 mypass1

   Replace the IP address, port, database, user, and password in this example with your own information.

   You should receive the message:

   Login succeeded!

   If you receive the connection refused message, verify that the IP and port are correct. See the Troubleshooting SQL based EAV service checks section for more tips.

2. Create and entry in the /etc/bigd.conf with the following syntax:

   external 192.168.1.1:1433 "/usr/local/lib/pingers/SQL_pinger" "mydata user1 mypass1"

   In this entry, mydata is the name of the database, user1 is the login name, and mypass1 is the password.

3. Add entries in the /etc/bigip.conf for the service checking:

   tping_svc 1433 5

   timeout_svc 1433 15

4. Reload the /etc/bigip.conf and restart bigd:

   bigpipe -f /etc/bigip.conf

   bigd

5. Verify that the service checking is being performed correctly: If the service is "UP", change the password in /etc/bigd.conf to an invalid password and restart bigd. The service should go down after the timeout period elapses.

   Correct the password and restart bigd and the service should go up again.

Troubleshooting SQL-based service checks

If you are having trouble, you should verify that you can login using another tool. For example, if you have Microsoft NT SQL Server version 6.5, there is a client program ISQL/w included with the SQL software. This client program performs simple logins to SQL servers. Use this program to test whether you can login using the ISQL/w program before attempting logins from the BIG/ip Controller.

Creating a test account for Microsoft SQL

On the SQL server, you can run the SQL Enterprise Manager to add logins. When first entering the SQL Enterprise Manager, you may be prompted for the SQL server to manage.

You can register servers by entering the machine name, user name, and password. If these names are correct, the server will be registered and you will be able to click on an icon for the server. When you expand the subtree for the server, there will be an icon for Logins.

Underneath this subtree, you can find the SQL logins. Here, you can change passwords or add new logins by right-clicking on the Logins icon. Click this icon to open an option to Add login. After you open this option, enter the user name and password for the new login, as well as which databases the login is allowed to access. You must grant the test account access to the database you specify in the EAV configuration.

Using advanced persistence options

In addition to the simple persistence option provided by the BIG/ip Controller, several advanced persistence options are available. These options include HTTP Cookie persistence, Destination Address Affinity (Sticky persistence), and Persist masking.

Using HTTP cookie persistence

You can set up the BIG/ip Controller to use HTTP cookie persistence. This method of persistence uses an HTTP cookie stored on a client's computer to allow the client to reconnect to the same server previously visited at a web site. This method of persistence can be used only with unencrypted HTTP 1.0 or 1.1 communication.

There are three types of cookie persistence available: Insert mode, Rewrite mode, and Passive mode. The mode you choose affects how the cookie is handled by the BIG/ip Controller when it is returned to the client.

Insert mode

If you specify Insert mode, the information about the server to which the client connects is written in the header of the HTTP response from the server. This mode creates a cookie, named BIGipServer, on the client computer that contains the information about the chosen server. The expiration date for the cookie is set based on the time-out configured on the BIG/ip Controller.

Rewrite mode

If you specify Rewrite mode, the BIG/ip Controller intercepts a cookie, named BIGipCookie, sent from the server to the client and rewrites the name of the cookie to BIGipServer. When the BIG/ip Controller rewrites the cookie, the server information and time-out value are reset.

Rewrite mode requires you to set up the cookie created by the server. In order for Rewrite mode to work, there needs to be a blank cookie coming from the web server for BIG/ip to rewrite. With Apache variants, the cookie can be added to every web page header by adding an entry in the httpd.conf file:

Header add Set-Cookie BIGipCookie=0000000000000000000000000000000000 00000000

(There should be 75 zeros in the cookie).

Passive mode

If you specify Passive mode, the BIG/ip Controller does not insert or search for existing cookies in the response from the server. It does not try to set up the cookie. In this mode, it is assumed that the server provides the cookie formatted with the correct node information and time-out.

In order for Passive mode to work, there needs to be a cookie coming from the web server with the appropriate node information in the cookie. With Apache variants, the cookie can be added to every web page header by adding an entry in the httpd.conf file:

Header add Set-Cookie: BIGipServer=184658624.20480.000; expires=Sat, 19-Aug-2000 19:35:45 GMT; path=/

In this example, 184658624 is the encoded node address and 20480 is the encoded port.

The equation for an address (a.b.c.d) is:

d*256^3 + c*256^2 + b*256 +a.

The way to encode the port is to take the two bytes that store the port and reverse them. So, port 80 becomes 80 * 256 + 0 = 20480. Port 1433 (instead of 5 * 256 + 153) becomes 153 * 256 + 5 = 39173.

To activate HTTP cookie persistence in the F5 Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers Properties screen opens.
2. Click Application Persistence.
   The Virtual Server Application Persistence screen opens.
3. Select HTTP Cookie Persistence.
4. Select the mode you want to use: Insert, Rewrite, or Passive. Each mode handles the cookie in a different manner (see the explanations preceding).
5. Select the time-out value in days, hours, minutes, and seconds. This value determines how long the cookie lives on the client computer before it expires.
6. Click Apply.

To activate HTTP cookie persistence from the command line

To activate HTTP cookie persistence from the command line, use the following syntax:

bigpipe vip <virt addr>:<service> define <node addr> [...<node addr>] special cookie <mode name> <timeout>

For the <mode name>, type Insert, Rewrite, or Passive. The <timeout> value for the cookie is written using the following format:

<days>d hh:mm:ss

Using destination address affinity (sticky persistence)

You can optimize your proxy server array with destination address affinity (also called sticky persistence). Address affinity directs requests for a certain destination to the same proxy server, regardless of which client the request comes from.

This enhancement provides the most benefits when load balancing caching proxy servers. A caching proxy server intercepts web requests and returns a cached web page if it is available. In order to improve the efficiency of the cache on these proxies, it is necessary to send similar requests to the same proxy server repeatedly. Destination address affinity can be used to cache a given web page on one proxy server instead of on every proxy server in an array. This saves the other proxies from having to duplicate the web page in their cache, wasting memory.

Warning: In order to prevent sticky entries from clumping on one server, use a static load balancing mode, such as Round Robin.

To activate destination address affinity in the F5 Configuration utility

You can only activate destination address affinity on wildcard virtual servers. For information on setting up a wildcard virtual server, see Defining wildcard virtual servers, on page 4-10. Follow these steps to configure destination address affinity:

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. Click the wildcard virtual server you want to configure.
   The Virtual Server Properties screen opens.
3. Click the Destination Address Affinity Enable box to enable destination address affinity.
4. In Destination Address Affinity Mask box, type in the mask you want to apply to sticky persistence entries.
5. Click the Apply button.

To activate sticky persistence from the command line

Use the following command to turn sticky persistence on for the virtual server:

bigpipe vip 0.0.0.0:<port> sticky enable

Use the following command to turn sticky persistence off for the virtual server:

bigpipe vip 0.0.0.0:<port> sticky disable

Use the following command to show whether the sticky persistence is on or off for the virtual server:

bigpipe vip 0.0.0.0:<port> sticky show

Use the following command to list sticky persistence entries for the specified virtual server.

bigpipe vip 0.0.0.0:<port> sticky dump

Use the following command to delete sticky entries for the specified virtual server:

bigpipe vip 0.0.0.0:<port> sticky clear

Use the following command to define the sticky mask for the virtual server:

bigpipe vip 0.0.0.0:<port> sticky mask <mask>

For example <mask> could be 255.255.255.0. To remove the sticky mask for the virtual server:

bigpipe vip 0.0.0.0:<port> sticky mask none

To show the sticky mask for the virtual server:

bigpipe vip 0.0.0.0:<port> sticky mask show

To clear all sticky connections on a BIG/ip Controller, issue the following bigpipe command:

bigpipe vip sticky clear

Using persist mask on a virtual server

The persist mask feature works only on virtual servers that implement simple persistence. By adding a persist mask, you identify a range of client IP addresses that will be managed as simple persistent connections when connecting to a virtual server.

Applying a persist mask

The complete syntax for the bigpipe vip persist mask command is:

bigpipe vip <virt addr>:<port> persist mask <ip> | none | show

Use the following syntax to specify a range of IP addresses to be included in persistence of the specified virtual port. The command adds a persist mask to a port:

bigpipe vip <virt addr>:<port> persist mask <ip>

For example, the following command would keep persistence information for addresses in the subnetwork 192.168.100 that connect to the virtual server 10.10.10.90:80's nodes:

bigpipe vip 10.10.10.90:80 persist mask 192.168.100.0

You can turn off a persist mask on a virtual server by using the none option in place of the ip mask. To turn off the persist mask that you set in the preceding example, use the following command:

bigpipe vip 10.10.10.90:80 persist mask none

To display all persist masks, use the show option:

bigpipe vip 10.10.10.90:80 persist mask show

Maintaining persistence across virtual servers that use the same virtual addresses

The BIG/ip Controller platform provides a similar persistence mode that is more granular. The BIG/ip Controller can maintain persistence for all connections requested by the same client, as long as the virtual server hosting each request uses the same virtual address. When this mode is turned on, the BIG/ip Controller attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same node only when the virtual server hosting the connection has the same virtual address as the virtual server hosting the initial persistent connection. Connection requests from the client that go to other virtual servers with different virtual addresses, or those connection requests that do not use persistence, are load balanced according to the currently selected load balancing mode.

Using the preceding example, if a BIG/ip Controller configuration includes the following virtual server mappings, where each virtual server uses persistence:

bigpipe vip v1:http define n1:http n2:http

bigpipe vip v1:ssl define n1:ssl n2:ssl

For example, a client makes an initial connection to v1:http and the BIG/ip Controller's load balancing mechanism chooses n1:http as the node. If the same client then connects to v1:ssl, the BIG/ip Controller starts tracking a new persistence session, and it uses the load balancing mode to determine which node should receive the connection request because the requested virtual server uses a different virtual address (v1) than the virtual server hosting the first persistent connection request (v1). However, if the client subsequently connects to v1:ssl, the BIG/ip Controller uses the persistence session established with the first connection to determine the node that should receive the connection request, rather than the load balancing mode. The BIG/ip Controller should send the third connection request to n1:ssl, which uses the same node address as the n1:http node that currently hosts the client's first connection with which it shares a persistent session.

Warning: In order for this mode to be effective, virtual servers that use the same virtual address, as well as those that use TCP or SSL persistence, should include the same node addresses in the virtual server mappings.

The system control variable bigip.persist_on_any_port_same_vip turns this mode on and off. To activate the persistence mode, type:

sysctl -w bigip.persist_on_port_same_vip=1

To deactivate the persistence mode, type:

sysctl -w bigip.persist_on_port_same_vip=0

Maintaining persistence across all virtual servers

You can set the BIG/ip Controller to maintain persistence for all connections requested by the same client, regardless of which virtual server hosts each individual connection initiated by the client. When this mode is turned on, the BIG/ip Controller attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same node. Connection requests from the client that do not use persistence are load balanced according to the currently selected load balancing mode.

For example, if a BIG/ip Controller configuration includes the following virtual server mappings, where each virtual server uses persistence:

bigpipe vip v1:http define n1:http n2:http

bigpipe vip v1:ssl define n1:ssl n2:ssl

bigpipe vip v2:http define n1:http n2:http

bigpipe vip v2:ssl define n1:ssl n2:ssl

Say that a client makes an initial connection to v1:http and the BIG/ip Controller's load balancing mechanism chooses n1:http as the node. If the same client subsequently connects to v1:ssl, the BIG/ip Controller would send the client's request to n1:ssl, which uses the same node address as the n1:http node that currently hosts the client's initial connection.

Warning: In order for this mode to be effective, virtual servers that use TCP or SSL persistence should include the same node addresses in the virtual server mappings.

The system control variable bigip.persist_on_any_vip turns this mode on and off. To activate the persistence mode, type:

sysctl -w bigip.persist_on_any_vip=1

To deactivate the persistence mode, type:

sysctl -w bigip.persist_on_any_vip=0

Using advanced redundant system features

In addition to the simple redundant features available on the BIG/ip Controller, several advanced redundant features are available. Advanced redundant system features provide additional assurance that your content is available if a BIG/ip Controller experiences a problem. These advanced redundant system options include:

• Mirroring connection and persistence information
• Gateway fail-safe
• Network-based fail-over
• Setting a specific BIG/ip Controller to be the active controller

Mirroring connection and persistence information

When the fail-over process puts the active controller duties onto a standby controller, your connection capability returns so quickly that it has little chance to be missed. By preparing a redundant system for the possibility of fail-over, you effectively maintain your site's reliability and availability in advance. But fail-over alone is not enough to preserve the connections and transactions on your servers at the moment of fail-over; they would be dropped as the active controller goes down unless you have enabled mirroring.

The mirror feature on BIG/ip Controllers is a specialized, ongoing communication between the active and standby controllers that duplicates the active controller's real-time connection or persistence information state on the standby controller. If mirroring has been enabled, fail-over can be seamless to such an extent that file transfers can proceed uninterrupted, customers making orders can complete transactions without interruption, and your servers can generally continue with whatever they were doing at the time of fail-over.

The mirror feature is intended for use with long-lived connections, such as FTP, Chat, and Telnet sessions. Mirroring is also effective for persistence information.

Warning: If you attempt to mirror all connections, the performance of the BIG/ip Controller may degrade.

Commands for mirroring

New commands that support mirroring capabilities are presented in overview in Table 5.2. For complete descriptions, syntax, and usage examples, see Appendix B, BIG/pipe commands.

Mirroring command in BIG/pipe

BIG/pipe command	Options
bigpipe mirror	Options for global mirroring
bigpipe vip mirror	Options for mirroring connection and persistence information on a virtual server.
bigpipe snat mirror	Options for mirroring secure NAT connections

Global mirroring on the BIG/ip Controller redundant system

Mirroring must be enabled on a redundant system at the global level before you can set mirroring of any specific types of connections or information. The syntax of the command for setting global mirroring is:

bigpipe mirror enable | disable | show

To enable mirroring on a redundant system, use the following command:

bigpipe mirror enable

To disable mirroring on a redundant system, use the following command:

bigpipe mirror disable

To show the current status of mirroring on a redundant system, use the following command:

bigpipe mirror show

Mirroring virtual server state

Mirroring provides seamless recovery for current connections, persistence information, SSL persistence, or sticky persistence when a BIG/ip Controller fails. When you use the mirroring feature, the standby controller maintains the same state information as the active controller. Transactions such as FTP file transfers continue as though uninterrupted.

Since mirroring is not intended to be used for all connections and persistence, it must be specifically enabled for each virtual server.

To control mirroring for a virtual server, use the bigpipe vip mirror command to enable or disable mirroring of persistence information, or connections, or both. The syntax of the command is:

bigpipe vip <virt addr>:<port> mirror [ persist | conn ] \
enable | disable

Use persist to mirror persistence information for the virtual server. Use conn to mirror connection information for the virtual server. To display the current mirroring setting for a virtual server, use the following syntax:

bigpipe vip <virt addr>:<port> mirror [ persist | conn ] show

If you do not specify either persist, for persistent information, or conn, for connection information, the BIG/ip Controller assumes that you want to display both types of information.

Mirroring SNAT connections

SNAT connections are mirrored only if specifically enabled. You can enable SNAT connection mirroring by specific node address, and also by enabling mirroring on the default SNAT address. Use the following syntax to enable SNAT connection mirroring on a specific address:

bigpipe snat <node addr> [...<node addr>] mirror enable | disable

In the following example, the enable option turns on SNAT connection mirroring to the standby controller for SNAT connections originating from 192.168.225.100.

bigpipe snat 192.168.225.100 mirror enable

Use the following syntax to enable SNAT connection mirroring the default SNAT address:

bigpipe snat default mirror enable | disable

Using gateway fail-safe

Fail-safe features on the BIG/ip Controller provide network failure detection based on network traffic. Gateway fail-safe monitors traffic between the active controller and the gateway router, protecting the system from a loss of the internet connection by triggering a fail-over when the gateway is unreachable for a specified duration.

Enabling gateway fail-safe

Gateway fail-safe monitoring can be toggled on or off from the command line using the bigpipe gateway command.

For example, arm the gateway fail-safe using the following command:

bigpipe gateway failsafe arm

To disarm fail-safe on the gateway, enter the following command:

bigpipe gateway failsafe disarm

To see the current fail-safe status for the gateway, enter the following command:

bigpipe gateway failsafe show

Adding a gateway fail-safe check

You can set up a gateway fail-safe check using the gateway keyword and three parameters to define the check to the bigd daemon:

• the name or IP address of the router (only one gateway can be configured for fail-safe)
• the time interval (seconds) between pings sent to the router
• time-out period (seconds) to wait for replies before proceeding with fail-over

  To establish the parameters for gateway fail-safe monitoring, use the following syntax to add a line to the /etc/bigd.conf:

gateway <IP addr> <ping_interval> <timeout>

You could also specify the device instead of the device's IP address:

gateway <device> <ping_interval> <timeout>

For example, you could establish a router fail-safe check by placing either of the following lines into the /etc/bigd.conf file. Note that changes to this file are read only when bigd starts (at system boot, or when you restart it with the command bigd from a command line).

gateway 10.1.1.1 5 30

gateway router 5 30

Either of these two checks pings the router on IP address 10.1.1.1. at five second intervals, and if a ping goes unacknowledged for 10 seconds, the BIG/ip Controller fails over to the standby unit.

For more information about the bigd daemon and /etc/bigd.conf, see Appendix D, bigd.

Gateway fail-safe messages

The destination for gateway fail-safe messages is set in the standard syslog configuration (/etc/syslog.conf), which directs these messages to the file /var/log/bigd. Each message is also written to the BIG/ip Controller console (/dev/console).

Using network-based fail-over

Network-based fail-over allows you to configure your redundant BIG/ip Controller to use the network to determine the status of the active controller. Network-based fail-over can be used in addition to, or instead of, hard-wired fail-over.

Configuring network-based fail-over

To enable network-based fail-over, you need to change the settings of specific BIG/store database keys using the bigdba utility. To enable network-based fail-over, the bigip.Failover.Ethernet key must be set to one (1). To set this value to one, type this command to open the BIG/store database:

bigdba /var/f5/bigdb/user.db

At the bigdba prompt, type the following entry:

bigip.Failover.Network=1

Other keys are available to lengthen the delay to detect the fail-over condition on the standby controller, and to lengthen the heart beat interval from the active unit. To change the time required for the standby unit to notice a failure in the active unit, set the following value using the bigdba utility (the default is three seconds):

bigip.Cluster.StandbyTimeoutSec = <value>

To change the heart beat interval from the active BIG/ip Controller, change the following value using bigdba (the default is one second):

bigip.Cluster.ActiveKeepAliveSec = <value>

For more information about BIG/store and using bigdba, see Appendix D, bigd.

Setting a specific BIG/ip Controller to be the preferred active unit

Setting a preferred active controller means overlaying the basic behavior of a BIG/ip Controller with a preference toward being active. A controller that is set as the active controller becomes active whenever the two controllers negotiate for active status.

To clarify how this differs from default behavior, contrast the basic behavior of a BIG/ip Controller in the following description. Each of the two BIG/ip Controllers in a redundant system has a built-in tendency to try to become the active controller. Each system attempts to become the active controller at boot time; if you boot two BIG/ip Controllers at the same time, the one that becomes the active controller is the one that boots the first. In a redundant configuration, if the BIG/ip Controllers are not configured with a preference for being the active or standby controller, either controller can become the active controller by becoming active first.

The active or standby preference for the BIG/ip Controller is defined by setting the appropriate startup parameters for sod (the switch over daemon) in /etc/rc.local. For more details on sod startup and functioning, see Appendix D, sod.

The following example shows how to set the controller to standby:

echo " sod."; /usr/sbin/sod -force_slave 2> /dev/null

A controller that prefers to be standby can still become the active controller if it does not detect an active controller. It is not possible for both controllers in a redundant system to be in active mode or in standby mode at the same time.

This example shows how to set controller to active:

echo " sod."; /usr/sbin/sod -force_master 2> /dev/null

A controller that prefers to be active can still serve as the standby controller when it is on a live redundant system that already has an active controller. For example, if an active controller that preferred to be active failed over and was taken out of service for repair, it could then go back into service as the standby controller until the next time the redundant system needed an active controller, for example, at reboot.

Configuring advanced Transparent Node mode options

Transparent Node mode allows the BIG/ip Controller to perform load balancing on routers and router-like devices. There are several advanced configuration issues and options available if you run the BIG/ip Controller in this mode. These issues and options include:

• Port translation
• Node ping
• Configuring routes
• Using standard virtual servers
• Using FTP in Transparent Node mode
• Setting up ECV service checks for transparent devices

Warning: Before using Transparent Node mode: If you previously enabled the IP source checking system control variable, disable it by clearing the IP sourcecheck box.

Port translation

When you define nodes for wildcard virtual servers, you need to use the addresses of the transparent devices on the internal network of the BIG/ip Controller. If you specify port 0 in the node definition, the BIG/ip Controller does not perform port translation. If you use a non-zero port, the BIG/ip Controller performs port translation.

Node ping

The BIG/ip Controller's default node ping setting is ICMP ping. Some transparent devices may not be configured to accept ICMP pings. If the devices in your environment cannot be configured to respond to ICMP pings on their internal ports, you have two options:

• You can switch to TCP Echo ping.
• You can disable node ping entirely.

  If you disable node ping entirely, you may want to set the global properties for each node port to use service check. Service check confirms that the BIG/ip Controller can connect to a node port and establish communication with the service managed on that port. If there is no appropriate port on the device, you should disable service check as well.

Configuring routes for Transparent Node mode

You can configure the BIG/ip Controller to run a routing daemon, GateD, or to simply use default and static routes. Aside from the normal interface routes that the operating system automatically creates, the BIG/ip Controller needs only gateway routes to the internal networks (networks inside the firewall), to which the BIG/ip Controller is not directly connected. The BIG/ip Controller must use its external interface to reach these gateways. Note that the BIG/ip Controller does not need any routes to the nodes specified in the default wildcard virtual server.

Using standard virtual servers in Transparent Node mode

You can configure conventional virtual servers to handle traffic that needs to be routed to non-transparent devices. This feature is useful in resolving the following issues:

• Some client web browsers may be configured to use a non-transparent proxy.
• Certain email peers may be configured to use an SMTP gateway that is on the firewall. In this case, you may want to add only one firewall node to the virtual server in order to avoid maintaining two or more email configurations.
• You may want to load balance client connections that go to internal network servers.

Using FTP in Transparent Node mode

A default wildcard virtual server (0.0.0.0:0) does not handle FTP connection requests. If you need to accommodate FTP connection requests, you should configure two FTP-specific wildcard virtual servers: 0.0.0.0:20 and 0.0.0.0:21. Note that the BIG/ip Controller supports connections for non-default active ports on FTP proxy servers.

Setting up ECV service checks for transparent devices

You can set up ECV to verify that a transparent node is functioning properly. To check if a transparent node is functioning, you can add an entry to the /etc/bigd.conf file that allows you to retrieve content through the node.

You can use a text editor, such as vi or pico, to manually create the /etc/bigd.conf file, which stores ECV information. To create the entry for checking a transparent node, use the following syntax:

transparent <node ip>:<node port> http://www-address[:port][/path] ["recv string"]

You can also use the following syntax for this entry:

transparent <node ip>:<node port> <dest ip>[:dest port][/path] ["recv string"]

For more information about these configuration entries, please refer to Table 5.1.

Viewing final destination addresses in the printed connection table

The BIG/pipe command line utility also offers a useful diagnostic tool that prints the list of current connections. Normally, the bigpipe dt command prints the client, virtual server, and node addresses. In Transparent Node Mode, the bigpipe dt command also prints the final destination address.

Using specialized load balancing modes

Load balancing is an integral part of the BIG/ip Controller. A load balancing mode defines, in part, the logic that a BIG/ip Controller uses to determine which node should receive a connection hosted by a particular virtual server. The BIG/ip Controller supports specialized load balancing modes that dynamically distribute the connection load, rather than following a static distribution pattern such as Round Robin. Dynamic distribution of the connection load is based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. The following section describes how each load balancing mode distributes connections, as well as how to set the load balancing mode on the BIG/ip Controller.

Understanding individual load balancing modes

Individual load balancing modes take into account one or more dynamic factors, such as current connection count. Because each application of the BIG/ip Controller is unique, and node performance depends on a number of different factors, we recommend that you experiment with different load balancing modes, and choose the one that offers the best performance in your particular environment.

Fastest mode

Fastest mode passes a new connection based on the fastest response of all currently active nodes. Fastest mode may be particularly useful in environments where nodes are distributed across different logical networks.

Least Connections mode

Least Connections mode is relatively simple in that the BIG/ip Controller passes a new connection to the node with the least number of current connections. Least Connections mode works best in environments where the servers or other equipment you are load balancing have similar capabilities.

Observed mode

Observed mode uses a combination of the logic used in the Least Connection and Fastest modes. In Observed mode, nodes are ranked based on a combination of the number of current connections and the response time. Nodes that have a better balance of fewest connections and fastest response time receive the a greater proportion of the connections. Observed mode also works well in any environment, but may be particularly useful in environments where node performance varies significantly.

Predictive mode

Predictive mode also uses the ranking methods used by Observed mode, where nodes are rated according to a combination of the number of current connections and the response time. However, in Predictive mode, the BIG/ip Controller analyzes the trend of the ranking over time, determining whether a node's performance is currently improving or declining. The nodes with better performance rankings that are currently improving, rather than declining, receive a higher proportion of the connections. Predictive mode works well in any environment.

Priority mode

Priority mode is a special type of round robin load balancing. In Priority mode, you define groups of nodes and assign a priority level to each group. The BIG/ip Controller begins distributing connections in a round robin fashion to all nodes in the highest priority group. If all the nodes in the highest priority group go down or hit a connection limit maximum, the BIG/ip Controller begins to pass connections on to nodes in the next lower priority group.

For example, in a configuration that has three priority groups, connections are first distributed to all nodes set as priority 3. If all priority 3 nodes are down, connections begin to be distributed to priority 2 nodes. If both the priority 3 nodes and the priority 2 nodes are down, connections then begin to be distributed to priority 1 nodes, and so on. Note, however, that the BIG/ip Controller continuously monitors the higher priority nodes, and each time a higher priority node becomes available, the BIG/ip Controller passes the next connection to that node.

Setting the load balancing mode

The load balancing mode is a system property of the BIG/ip Controller, and it applies to all standard and wildcard virtual servers defined in the configuration.

To set the load balancing mode in the F5 Configuration utility

1. In the navigation frame, click the BIG/ip logo.
   The BIG/ip System Properties screen opens.
2. In the Load Balancing Mode box, choose the desired load balancing mode.
3. Click Apply.

Warning: If you select Ratio mode or Priority mode, be sure to set the ratio weight or priority level for each node address in the configuration.

To set the load balancing mode on the command line

The command syntax for setting the load balancing mode is:

bigpipe lb <mode name>

Table 5.3 describes the valid options for the <mode name> parameter.

Options for the <mode name> parameter.

Mode Name	Description
priority	Sets load balancing to Priority mode.
least_conn	Sets load balancing to Least Connections mode.
fastest	Sets load balancing to Fastest mode.
observed	Sets load balancing to Observed mode.
predictive	Sets load balancing to Predictive mode.

Setting ratio weights and priority levels for node addresses

If you set the load balancing mode to either Ratio mode or Priority mode, you need to set a special property on each node address.

• Ratio weight
  The ratio weight is the proportion of total connections that the node address should receive. The default ratio weight for a given node address is 1. If all node addresses use this default weight, the connections are distributed equally among the nodes.
• Priority level
  The priority level assigns the node address to a specific priority group.

To set ratio weights and priority levels 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 Apply 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 and priority 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

Warning: If you set the load balancing mode to Ratio or Priority, you must define the ratio or priority settings for each node address. The value you define using the bigpipe ratio command is used as the ratio value if Ratio is the currently selected load balancing mode, and the same value is used as the priority level if Priority is the currently selected load balancing mode.

Controlling network access and traffic flow with filters

Filters control network traffic by setting whether packets are forwarded or rejected at the external network interface. Filters apply to both incoming and outgoing traffic. When creating a filter, you define criteria which are applied to each packet that is processed by the BIG/ip Controller. You can configure the BIG/ip Controller to forward or block each packet based on whether or not the packet matches the criteria.

The BIG/ip Controller supports two types of filters, IP filters and rate filters.

IP filters

Typical criteria that you define in IP filters are packet source IP addresses, packet destination IP addresses, and upper-layer protocol of the packet. However, each protocol has its own specific set of criteria that can be defined.

For a single filter, you can define multiple criteria in multiple, separate statements. Each of these statements should reference the same identifying name or number, to tie the statements to the same filter. You can have as many criteria statements as you want, limited only by the available memory. Of course, the more statements you have, the more difficult it is to understand and maintain your filters.

Configuring IP filters

When you define an IP filter, you can filter traffic in two ways:

• You can filter traffic going to a specific destination or coming from a specific destination, or both.
• The filter can allow network traffic through, or it can reject network traffic.

Defining an IP filter in the F5 Configuration utility

1. Click IP Filters in the navigation pane.
   The IP Filters screen opens.
2. In the IP Filters screen, click Add Filter.
   The Add IP Filter screen opens.
3. On the Add IP Filter screen, in the Name box, type a filter name.
4. From the Type list, choose Accept Packet to allow traffic, or Deny Packet to reject traffic.
5. In the Source IP Address box, only if you want the filter to be applied to network traffic based on its source, enter the IP address from which you want to filter traffic.
6. In the Source Port box, only if you want the filter to be applied to network traffic based on its source, enter the port number from which you want to filter traffic.
7. In the Destination IP Address box, enter the IP address to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
8. In the Destination Port box, enter the port number to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
9. Click Add to add the IP filter to the system.

Note: For information on configuring IP filters and rate filter on the command line, refer to the IPFW man page.

Rate filters and rate classes

In addition to IP filters, you can also define rates of access by using a rate filter. Rate filters consist of the basic filter and a rate class. Rate classes define how many bits per second are allowed per connection and the number of packets in a queue.

Configuring rate filters and rate classes

Rate filters are a type of extended IP filter. They use the same IP filter method, but they apply a rate class which determines the volume of network traffic allowed through the filter.

Tip: You must define at least one rate class in order to apply a rate filter.

Rate filters are useful for sites that have preferred clients. For example, an e-commerce site may want to set a higher throughput for preferred customers, and a lower throughput for random site traffic.

Configuring rate filters involves both creating a rate filter and a rate class. When you configure rate filters, you can use existing rate classes. However, if you want a new rate filter to use a new rate class, you must configure the new rate class before you configure the new rate filter.

To configure a new rate class in the F5 Configuration utility

1. Click Rate Filters in the navigation pane.
   The Rate Filters screen opens.
2. In the Rate Filters screen, click Add Class.
   The Rate Class screen opens.
3. On the Rate Class screen, in the Name box, type a rate class name.
4. In the Bits Per Second Allowed box, enter the maximum number of bits per second that you want the class to allow.
5. In the Minimum Number of Bits Outstanding box, enter the minimum number of bits required to be sent for processing from the queue at one time.
6. In the Queue Length (in Packets) box, enter the maximum number of packets allowed in the queue. Once the BIG/ip Controller fills the queue, it begins to drop subsequent packets received.
7. Click Add to add the rate class to the system.

Note: For information on configuring IP filters and rate filter on the command line, refer to the IPFW man page.

After you have added a rate class, you can configure rate filters for your system.

To configure a rate filter in the F5 Configuration utility

1. Click Rate Filters in the navigation pane.
   The Rate Filters screen opens.
2. In the Rate Filters screen, click Add Class.
   The Add Class screen opens.
3. On the Rate Filter screen, in the Name box, type a name for the rate filter.
4. From the Rate Class list, choose a rate class. Note that you must have a rate class defined before you can proceed.
5. In the Source IP Address box, enter the IP address from which you want to filter traffic, only if you want the filter to be applied to network traffic based on its source.
6. In the Source Port box, enter the port number from which you want to filter traffic, only if you want the filter to be applied to network traffic based on its source.
7. In the Destination IP Address box, enter the IP address to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
8. In the Destination Port box, enter the port number to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
9. Click Add.

Note: For information on configuring IP filters and rate filter on the command line, refer to the IPFW man page.

Working with more than two interface cards

When you configure a BIG/ip Controller with more than two interface cards installed, you address the following issues:

• Additional interfaces should be configured.
• You need to specify an interface for each virtual address.
• You need to define an interface for NATs.
• You need to define an interface for SNATs.
• Verify routing with multiple NICs.
• Edit httpd.conf for network administration with the F5 web server.

Configuring additional interfaces with the First-Time Boot utility

The first step in configuring the BIG/ip Controller with additional interfaces is to run the First-Time Boot utility. This utility detects how many NICs are present in the BIG/ip Controller. If you have more than two NICs present, the utility prompts you to define additional external interfaces. The First-Time Boot utility prompts you for information to configure the F5 web server.

You can also designate one of your additional internal NICs with the route for which access is permitted for network administration using SSH (or Telnet for international users).

The First-Time Boot utility, /bin/config, detects and configures additional interfaces if they are present in the BIG/ip Controller.

Running the First-Time Boot utility

As Administrator with root-level permission, enter the following command from the command line:

/bin/config

After choosing and configuring the first external interface, you are prompted to configure additional external interfaces:

More external interfaces to configure? [y or n]

Type y to configure a second external interface. Type n if you want the remaining NICs to be set to internal. After you configure external interfaces, the First-Time Boot utility sets any remaining interfaces to internal by default.

When asked to configure the web server, you are prompted to define a domain name for the external and internal interfaces. If you have more than two NICs, an external interface and an internal interface are automatically chosen to be the web server's interfaces. Changing the domain name or configuring additional interfaces must be done manually by editing the httpd.conf file. For more information, refer to the Editing httpd.conf for network administration section Editing httpd.conf for network administration with the BIG/ip web server, on page 5-44.

If you already have the F5 web server configured from a previous install, you can choose to not replace your httpd.conf file. The script asks you if you want to replace your existing file. If you choose not to replace the file, you are asked to confirm your choice. When you choose Cancel, a message is displayed indicating that the configuration was not successful. This message only applies to the F5 web server configuration. Your BIG/ip configuration is still valid.

The First-Time Boot utility creates a new /etc/netstart script which supports more than two NICs. It also modifies the /etc/ethers and /etc/bigip.interfaces files.

Note: When you rerun the First-Time Boot utility, it does not replace or change your existing /etc/bigip.conf or your /etc/bigd.conf files.

You may need to edit the /etc/bigip.conf file using a text editor such as vi or pico to add the appropriate interface statements. For example, if you want to designate exp2 as an internal interface, add the following lines to your bigip.conf file:

interface exp2 internal

interface exp2 failsafe disarm

interface exp2 timeout 30.

Once you are done editing the bigip.conf file, reboot the BIG/ip Controller, or restart bigd by typing bigd on the command line and pressing Enter, in order to implement your changes.

Specifying an interface for a virtual address

When you define a virtual server on a BIG/ip Controller that has more than one external interface, you need to specify the external interface that the virtual server's address is associated with.

Warning: All virtual servers that share a virtual address must be associated with the same external interface.

To specify a virtual server interface in the F5 Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. In the toolbar, click Add Virtual Server.
   The Add Virtual Server screen opens.
3. In the Add Virtual Server screen, type in the properties for the virtual server you want to add including the address and port.
4. Click Add.

To specify a virtual server interface on the command line

You can define virtual servers with the bigpipe vip command. Normally, a virtual server is added to the external interface with a network address that matches the network of the virtual address. However, with multiple NICs, you can specify which external interface a virtual server is added to using the bigpipe vip command. To do this, add the <interface> argument to the command.

bigpipe vip <virt addr>:<port>[/<bitmask>] [<interface>] \
define <node addr>:<port> ... <node addr>:<port>

bigpipe vip <virt addr>:<port> [<interface>] [netmask <netmask> \
[broadcast <broadcast_ip>]] define <node addr>:<port> ... \
<node addr>:<port>

You can set the <interface> parameter to none if you want to prevent BIG/ip from issuing ARP requests for a specific virtual server. This has the same effect as using the sysctl variable bigip.vipnoarp, but on a server-by-server basis.

The following example shows how to define a virtual server that is added to a FDDI NIC.

bigpipe vip 210.12.150.100:80 /24 fpa0 define 192.158.11.100:80 \ 192.158.11.101:80 192.158.11.102:80

Specifying an interface for a NAT address

When you define a NAT address on a BIG/ip Controller that has more than one external interface, you need to specify the external interface that the virtual server's address is associated with.

To specify an interface for a NAT in the F5 Configuration utility

1. Click NATs in the navigation pane.
   The Network Address Translations (NATs) screen opens.
2. Click the NAT you want to configure.
   The NAT Properties screen opens.
3. In the External Interface list, choose the interface to which you want to assign this NAT.
4. Click Apply.

To specify an interface for a NAT on the command line

When mapping a network address translation with the bigpipe nat command, you must now specify which external interface a virtual IP address is added to by using the new <interface> parameter.

bigpipe nat <internal_ip> to <external_ip> [/<bitmask>] \ [<interface>]

bigpipe nat <internal_ip> to <external_ip> [<interface>] [netmask \
<netmask> [broadcast <broadcast_ip>] |/<bitmask>]

The following example shows how to define a NAT where the IP address represented by <external_ip> is added to an Intel NIC.

bigpipe nat 11.0.0.100 to 10.0.140.100/24 exp0

Specifying an interface for a SNAT address

When you define a SNAT address on a BIG/ip Controller that has more than one external interface, you need to specify the external interface that the virtual server's address is associated with.

Warning: All virtual servers that share a virtual address must be associated with the same external interface.

To specify an interface for a SNAT in the F5 Configuration utility

1. Click Secure NATs in the navigation pane.
   The Secure Network Address Translations (SNATs) screen opens.
2. Click the SNAT you want to configure.
   The SNAT Properties screen opens.
3. In the External Interface list, choose the interface to which you want to assign this SNAT.
4. Click Apply.

To specify an interface for a SNAT on the command line

When mapping a secure network address translation with the bigpipe snat command, you must specify which external interface a virtual IP address is added to by using the new <interface> parameter.

bigpipe snat <internal_ip> to <external_ip> [/<bitmask>] \ [<interface>]

bigpipe snat <internal_ip> to <external_ip> [<interface>] [netmask]
<netmask> [broadcast <broadcast_ip>] |/<bitmask>]

The following example shows how to define a SNAT where the IP address represented by <external_ip> is added to an Intel NIC.

bigpipe snat 11.0.0.100 to 10.0.140.100/24 exp0

Routing with multiple NICs

Use Router Discovery Protocol (RDP) for routing on a BIG/ip Controller with more than one interface. For router configuration information, please refer to documentation included with your router.

Editing httpd.conf for network administration with the BIG/ip web server

When you use the First-Time Boot utility, it configures the BIG/ip web server and saves your changes in the httpd.conf file. This file defines your virtual web servers for the external and internal interfaces that your IP addresses are mapped to. You must edit this file, using a text editor such as vi or pico, if you want to change access to specific interfaces. If you subsequently run the reconfig-httpd script (or config-httpd for international users), some or all your changes may be lost and you must edit your BIG/ip web server configuration file again. For an example of how to add a second virtual host to the BIG/ip web server, see this sample configuration of virtual hosts in an environment with more than two NICs: httpd.conf file.

Example configurations for more than two NICs

The following two scenarios for configuring your network with more than two NICs contain important details related to creating virtual servers.

• In the first scenario, you have one gateway, with two routers and two BIG/ip Controllers behind it.
• The second scenario involves two routers providing access into the network, with two BIG/ip Controllers behind them.

  Each scenario configuration has advantages and disadvantages related to how you set up your virtual servers, which are detailed in the following descriptions. For instructions on how to create virtual servers on specific interfaces, see Specifying an interface for a virtual address, on page 5-41

Configuration example: One gateway

When your network is configured with one gateway to the Internet, and has two routers connected to two BIG/ip Controllers behind that gateway, we recommend that you connect the first router to one of the external interfaces on each BIG/ip Controller and the other router to the remaining external interfaces on each BIG/ip Controller for maximum redundancy.

If the gateway is running OSPF, it maintains redundancy by ensuring that there is only one path from your network to the Internet. In the unlikely event that the active router should fail, OSPF determines that the router is not functioning properly, and sends subsequent connections to the second router. Existing connections will persist by going through the second router. Under such conditions, when you create a virtual server, we recommend that you create it to use the default interface.

By using the default interface, the virtual server is guaranteed to handle connections in an efficient manner by cooperating with OSPF's attempts to compensate for the failed router. Otherwise, if the virtual server is configured to use one specific external interface, there is no way for connections to arrive at the virtual server when the router leading to it fails.

Configuration example: Two gateways

When your network is configured with two routers to the Internet, and has two BIG/ip Controllers behind them, we also recommend that you connect the first router to one of the external interfaces on each BIG/ip Controller and the other router to the remaining external interfaces on each BIG/ip Controller. However, in this configuration, you have two entry points into your network, one through each router.

You have the flexibility to decide how you want clients to access various web sites on your virtual servers based on how the virtual servers are created. For example, your research department uses an intranet site to exchange information and that sensitive material needs to be protected. You can limit access to the virtual server that hosts the research intranet by creating the virtual server to accept connections through a specific external interface, such as exp1. Then, by restricting access to the external interface to only your researchers, you guarantee that the information is protected. On the other hand, you want your employees, including the researchers, to have access to the Human Resources information on the intranet.

You would then create the virtual server that hosts the Human Resources intranet using the default external interface so that any employee connecting from any location can make a connection to that virtual server.

Optimizing large configurations

The BIG/ip Controller supports up to 40,000 virtual servers and nodes combined. Larger configurations on a BIG/ip Controller, such as those that exceed 1,000 virtual servers or 1,000 nodes, introduce special configuration issues. To ensure a high performance level, you need to change certain aspects of the BIG/ip Controller's management of virtual servers and nodes. The following steps can be taken to optimize a large configuration.

• Reduce ARP traffic on the external network
• Reduce the number of node pings and service checks issued by the BIG/ip Controller

Reducing ARP traffic on the external network

The BIG/ip Controller maintains an IP alias on its external interface for each virtual address that it manages. IP aliases are broadcast on the network when a virtual server is defined, and also each time a BIG/ip Controller switches from standby mode to active mode in a redundant system. Each time a new IP alias is defined, the router on the external network must issue an ARP request for that virtual server's address. If you have defined thousands of virtual addresses in the BIG/ip Controller configuration, the corresponding ARP requests may lead to a significant increase in network traffic.

This type of configuration also increases fail-over recovery time in BIG/ip redundant systems. When a fail-over occurs, the BIG/ip Controller that becomes the active machine creates an IP alias for each virtual server that it manages. Normally, this process takes less than one second. However, if the BIG/ip Controller has 8,000 virtual servers, this process can take as long as 90 seconds. The active BIG/ip Controller is unresponsive during the time it creates the IP aliases, and it cannot begin processing connections until the IP aliasing is complete.

To ensure a fast fail-over process, and to help reduce the amount of ARP requests a router must make, you should run the BIG/ip Controller in VIP-NoArp mode. In VIP-NoArp mode, the BIG/ip Controller does not create IP aliases for virtual servers. Instead, network traffic bound for virtual servers configured on the BIG/ip Controller are routed using the BIG/ip Controller's external interface as a gateway. Configuring VIP-NoArp mode is a two-step process:

• On the router, you must configure a gateway to the virtual servers using the BIG/ip Controller's external interface IP address.
• On the BIG/ip Controller itself, you must change the vip_no_arp system control variable. Note that you can use either the F5 Configuration utility, or the BIG/pipe command line utility, to change system control variables.

Note: You can enable VIP-NoArp mode only if you have the ability to add a route to your router. Note that in redundant systems, you need to use the shared external IP address as the gateway address for the virtual servers configured on the BIG/ip Controller.

Configuring the router

In the router configuration, you need to define a static route as the gateway for each virtual address managed by the BIG/ip Controller. The static route should set the gateway address to the IP address for the external interface on the BIG/ip Controller. For example, if the shared external address of a BIG/ip redundant system is 11.0.0.100, and all virtual servers configured on the BIG/ip redundant system use IP addresses 11.0.1.50 through 11.0.1.55, you need to configure the router to use 11.0.0.100 as a gateway to the 11.0.1.* subnet. Such a definition on a UNIX-like router would read:

route add -net 11.0.1.0 gw 11.0.0.100

Activating VIP-NoArp mode in F5 Configuration utility

In the F5 Configuration utility, the VIP-NoArp mode setting is under BIG/ip sysctl configuration. To turn the VIP-NoArp mode on, simply check the Disable IP Aliases on Virtual Servers box. To turn VIP-NoArp mode off, clear the Disable IP Aliases on Virtual Servers box.

Warning: We recommend that you do not toggle this mode on or off while the virtual servers are defined. Resetting the variable at that time may result in system anomalies.

Activating VIP-NoArp mode on the command line

You can activate VIP-NoArp mode in one of two ways:

• You can edit the /etc/rc.sysctl file in a text editor, and then reboot the system.
• You can immediately enable or disable the mode using sysctl commands.

  If you choose to edit the /etc/rc.sysctl file, you simply need to add the following line to the file to activate VIP-NoArp mode:

sysctl -w bigip.vipnoarp=1

To deactivate VIP-NoArp mode, you can either comment the line out, or delete it from the /etc/rc.sysctl file altogether. Once you edit the file, the changes do not take affect until you reboot the system.

To immediately activate VIP-NoArp mode, type the following on the command line:

bigpipe -f /dev/null

sysctl -w bigip.vipnoarp=1

bigpipe -f /etc/bigip.conf

To immediately deactivate VIP-NoArp mode, type the following on the command line:

bigpipe -f /dev/null

sysctl -w bigip.vipnoarp=0

bigpipe -f /etc/bigip.conf

Warning: We recommend that you do not toggle the VIP-NoArp mode on or off while the virtual servers are defined. Resetting the sysctl variable at that time may lead to a system crash.

Reducing the number of node pings and service checks issued by the BIG/ip Controller

The BIG/ip Controller checks node status at user-defined intervals in two different ways:

• The BIG/ip Controller can issue a node ping to all node addresses that it manages. If the BIG/ip Controller receives a response to a node ping from a specific node address, all nodes associated with that node address are marked up and available for connections. The node ping can be either ICMP or TCP.
• The BIG/ip Controller can also perform a service check. For each node that uses service check, the BIG/ip Controller connects to the node and attempts to establish a connection with the service configured on the node port. If the BIG/ip Controller is able to establish a connection with the service, the BIG/ip Controller marks the node up. If the BIG/ip Controller cannot establish a connection with the service, the BIG/ip Controller marks the node down. It is important to note that the node is marked down, even if the node's address is able to respond to the BIG/ip Controller's simple node ping.

  If a BIG/ip Controller's configuration includes thousands of nodes, the node pings and service checks begin to take up more resources on both the BIG/ip Controller and the servers than is preferred. You can significantly reduce the number of node pings and service checks in configurations that have a group of node addresses which are all IP aliases on the same server. For each group of node addresses that points to a given server, you can select one node address out of the group to represent all node addresses in the group. The representative node address is referred to as the node alias. When the BIG/ip Controller issues a node ping or service check, it sends the ping or performs the service check only on the node alias, rather than on all nodes in the group. If the BIG/ip Controller receives a valid response before the time-out expires, it marks all nodes associated with the node alias as up and available to receive connections. If the BIG/ip Controller does not receive a valid response before the time-out expires, it marks all of the nodes associated with the node alias as down.

An important note about service checks

You can set the BIG/ip Controller to use a node alias for nodes that are configured for service checks; however, there are some limitations to this implementation. Service checks are port-specific, unlike node pings which are merely sent to a node address. If you assign a node alias to a node that uses service check, the node alias must be configured to support the port number associated with the node. If the node alias is not configured properly, the BIG/ip Controller can not establish a conversation with the service that the specific node supports, and the service check is invalid.

Note: If you have configured different ports on each node to handle a specific Internet service and you want to use IP aliases, you can use BIG/pipe commands to work around the situation. Refer to the BIG/pipe Command Reference in Appendix B for more information about the bigpipe alias command.

Setting up node aliases in the F5 Configuration utility

In the F5 Configuration utility, each node address has a set of properties associated with it, including the Node Alias property. Note that before you define a node alias for a specific node address, you may want to check the properties for each node that uses the node alias. The node alias must support each port used by a node that is configured for service check, otherwise the service check results are invalid.

1. Select Nodes in the System tree to display the Virtual Servers page.
2. In the Node Properties table, click the node address.
3. In the Node Address Properties page, type the node alias in the Node Alias box.
4. Click Apply.

Setting up node aliases using the BIG/pipe command line utility

The BIG/pipe command line utility allows you to set node aliases for multiple nodes at one time. With the bigpipe alias command, you can do three things:

• View all node aliases defined in the current configuration
• View the node alias associated with a specific node address
• Define a node alias for one or more node addresses

  For details about working with the bigpipe alias command, refer to the BIG/pipe Command Reference in Appendix B.

Using alternative network configurations

There are a number of alternative network configurations you can use with the BIG/ip Controller. These network configurations include IEEE 802.1q VLAN trunk mode and out of path routing.

Setting up 802.1q VLAN trunk mode

The BIG/ip Controller supports VLANs based on the IEEE 802.1q Trunk mode on BIG/ip Controller internal interfaces. VLAN tags are not supported on the external interfaces. You can define a single VLAN tag for each IP address defined for each BIG/ip Controller internal interface. This includes node network addresses, administrative addresses, shared administrative aliases, and additional aliases.

Warning: In order for 802.1q VLAN trunk mode to operate on a BIG/ip Controller interface, all IP addresses on that interface must have a VLAN tag.

In order to use VLAN tags, you must edit /etc/netstart. Additionally, if you plan to use VLAN tags on a redundant BIG/ip system, you must edit /etc/bigip.interfaces.

Adding VLAN tag definitions to /etc/netstart

The VLAN tag ID for the network needs to be specified at the time the network address is defined for a particular internal interface. This is done by extending the additional_xxx definition for the internal interface (where xxx is the interface name, such as exp0, exp1, or hmc0). For example, if you have an internal interface IP defined as:

ipaddr_exp1="10.1.1.1"

netmask_exp1="255.0.0.0"

linkarg_exp1="media 100BaseTX,FDX"

additional_exp1="broadcast 10.255.255.255"

To define a VLAN tag ID 12 for this network (10.0.0.0), extend the additional_exp1 definition in the following manner:

additional_exp1="broadcast 10.255.255.255 vlan 12"

Do this for each internal interface for which you want to define a VLAN tag ID.

Adding VLAN tag definitions to /etc/bigip.interfaces

For a redundant configuration, this file contains the shared IP addresses for the internal and external interfaces for BIG/ip. If you plan to use VLAN tags on a redundant BIG/ip system, you must edit the /etc/bigip.interfaces file.

For example, based on the previous example, the default /etc/bigip.interfaces file would contain the following line:

"exp1" "10.1.1.10" "255.0.0.0" "10.255.255.255"

This line is extended with the same VLAN tag defined for its primary address, in this case 12:

"exp1" "10.1.1.10" "255.0.0.0" "10.255.255.255" "12"

Configuring multiple VLANs on one interface

In order to set up multiple VLANs on the same interface, you need to add a new IP address for the interface. The BIG/ip Controller only supports one VLAN ID per network.

For example, to support an additional network, 12.0.0.0, with a VLAN tag ID of 15 on the same interface, add the following line to your /etc/netstart file after the ifconfig command:

/sbin/ifconfig exp1 add 12.1.1.1 netmask 255.0.0.0 media 100BaseTX,FDX broadcast 12.255.255.255 vlan 15

Note that you must add a shared address to the /etc/bigip.interfaces file in a redundant BIG/ip scenario:

"exp1" "12.1.1.10" "255.0.0.0" "12.255.255.255" "15"

To enable or disable VLAN tags on the command line

Once you have added VLAN tags, you can use the bigpipe interface command to enable, disable, or show the current settings for the interface. To globally enable or disable the VLAN tags for your internal interface, use the following syntax:

bigpipe interface <ifname> vlans [ enable | disable | show ]

For example, use the following command to enable VLAN tags on the interface exp1:

bigpipe interface exp1 vlans enable

Using ifconfig to add another VLAN

You must use ifconfig to define an additional VLAN tag associated with a network. For example, use the following command to add the VLAN tag on the network:

ifconfig exp1 add <address> netmask <mask> broadcast <address> vlan <tag>

You can also use ifconfig to display VLAN information for the interface exp1 with the following command:

ifconfig exp1

Using netstat to view VLAN tags

You can also use the netstat utility to display VLAN tag information with the route table for the BIG/ip Controller. Use the following syntax to display VLAN tag information with netstat:

netstat -nrT

Warning: 802.1q VLAN tags are currently supported only on Intel EtherExpressPro NICs and Packet Engines GNIC-2 NICs.

Out of path routing

Out of path routing allows you to route outgoing server traffic around the BIG/ip Controller directly to an outbound router. This method of traffic management increases the outbound throughput of the BIG/ip Controller by taking the outbound server traffic off of the BIG/ip Controller.

With out of path routing, the BIG/ip Controller must be configured so that it does not translate the IP address or port of incoming packets. This is important because packets are not translated when they are outbound to the router. To avoid translation of incoming, or destination packets, the BIG/ip Controller must be in Transparent Node mode and configured with a wildcard virtual server on the external interface.

The following tasks are required to configure the BIG/ip Controller to use out of path routing:

• Set up Transparent Node mode on the BIG/ip Controller.
• Define a wildcard virtual server on an external interface.
• Set the route through the BIG/ip Controller.
• Set the idle connection time-out value to remove stale connections.

Configuring Transparent Node mode

You can use the F5 Configuration utility, or edit the /etc/rc.sysctl file with a text editor, to set the BIG/ip Controller to Transparent Node mode.

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

To activate Transparent Node mode from the command line

1. Enter the following sysctl command:

sysctl -w bigip.bonfire_mode=1

1. Save the /etc/rc.sysctl file using the following command:

/etc/rc.sysctl -s

Defining an external virtual server

After you configure Transparent Node mode on the BIG/ip Controller, you can configure a wildcard virtual server for the external interface. A wildcard virtual server does not translate packets, which is key to Out of path routing.

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 setting blank, the BIG/ip Controller uses the default netmask. 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. Choose default to allow the F5 Configuration utility 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.
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 Add to save the virtual server.
    Once you click Add, 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, enter the IP address and service or port number for the node.
14. Click Add 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 15 until you have defined all nodes that should be included in the virtual server mapping, and then complete the task with step 16.
15. If you have defined all nodes for the virtual server mapping, click Apply to save 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 nodes. 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

Setting the route through the BIG/ip Controller

A route must be defined through the BIG/ip Controller on the outbound router in your network configuration. This route should be the IP address (or alias) for the server, or servers, for which you want to set up Out of path routing.

For information about how to define this route, please refer to the documentation provided with your router.

Setting the idle connection time-out

With Out of path routing, the BIG/ip Controller cannot track the normal FIN/ACK sequences made by connections. Normally, the BIG/ip Controller shuts down closed connections based on this sequence. With Out of path routing, the idle connection time-out must be configured to clean up closed connections. You need to set an appropriate idle connection time-out value so that valid connections are not disconnected, and closed connections are cleaned up in a reasonable time.

To set the idle connection time-out in the F5 Configuration utility

1. In the navigation pane, click Virtual Servers.
2. In the Virtual Servers list, click wildcard virtual server you created for Out of path routing.
   The Virtual Server Properties screen opens.
3. In the Port box, click the port.
   The Global Virtual Port Properties screen opens.
4. In the Idle connection timeout TCP (seconds) box, type a time-out value for TCP connections. The recommended time-out setting is 10 seconds.
5. In the Idle connection timeout UDP (seconds) box, type a time-out value for TCP connections. The recommended time-out setting is 10 seconds.
6. Click Apply.

To set the idle connection time-out in the /etc/bigip.conf file

To set the idle connection time-out in the /etc/bigip.conf file, edit the following lines:

treaper <port> <seconds>

udp <port> <seconds>

The <seconds> value is the number of seconds a connection is allowed to remain idle before it is terminated. The <port> value is the port on the wildcard virtual server for which you are configuring out of path routing. The recommended value for the TCP and UDP connection time-outs is 10 seconds.