Manual Chapter : BIG-IP Administrator guide v3.3: Essential Configuration Tasks

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 3.3.1 PTF-06, 3.3.1 PTF-05, 3.3.1 PTF-04, 3.3.1 PTF-03, 3.3.1 PTF-02, 3.3.1 PTF-01, 3.3.1, 3.3.0
Manual Chapter


18

Essential Configuration Tasks



Determing which configuration tasks to do

Before you follow the instructions in this chapter, you need to browse through the prior chapters to find the specific load balancing solution you want to set up, such as basic web server load balancing. Each load balancing chapter describes the configuration tasks you need to complete to set up the solution, but it points you to this chapter for the actual configuration steps.

This chapter covers the four essential configuration tasks that all users must complete, regardless of the chosen load balancing solution. The chapter also includes optional configuration tasks that most users find they want to do. In the individual load balancing solution chapters, you can find information about which optional configuration tasks and advanaced features may be right for you.

Basic configuration tasks

  • Configure pools
    A pool contains a group of servers or other network equipment that the BIG-IP Controller load balances. The pool configuration includes key information such as the load balancing mode and the persistence mode. The nodes that you add to a pool are known as members.
  • Configure virtual servers
    The virtual servers reference pools of servers, or network devices, that you want to load balance.
  • Allow access to ports and services
    The services and ports on a BIG-IP Controller are locked down and cannot accept connections until you specifically open them to network access. For each service that one or more of your virtual servers supports, you need to open the corresponding port number for network access. However, ports are automatically enabled when you use them in virtual server definition in the Configuration utility.
  • Configure the timer settings
    The BIG-IP Controller supports several timer settings, but for a simple configuration, there are only two that you need to set. First, you need to set the amount of time that idle connections are allowed to remain open. Second, you need to set the frequency at which the BIG-IP Controller checks nodes to make sure they are up and available to accept connections passed on by a virtual server.

Optional configuration tasks

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

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

Warning: When you set configuration options in the Configuration utility, they are immediately saved to the appropriate configuration file. However, when you set configuration options using the bigpipe command line utility, they are temporarily stored in system memory, and are not saved to a configuration file unless you execute the bigpipe -s command. For more information about this command, see the BIG-IP Controller Reference Guide, bigpipe Command Reference.

Table 18.1 describes the different types of connection configurations available on the BIG-IP Controller.

Connection configuration options for the BIG-IP Controller
  NAT SNAT IP Forwarding Virtual server Forwarding virtual server
Security Medium High Low (see following note) High High
Routable addresses required on the internal network No No Yes No Yes
Protocols TCP and UDP TCP and UDP Any IP protocol TCP and UDP TCP and UDP
NT Domain support No No Yes No Yes
Active FTP support No Yes Yes Yes Yes
Connection origination Any direction One direction Any direction One direction One direction
Ports Does not matter Does not matter Does not matter Uses specific ports or wildcard Uses specific ports or wildcard
Setup for specific nodes or hosts Yes Yes, but can use wildcards No Yes, but can use wildcard Yes
Load balancing No No No Yes No

Note: Although IP forwarding does not require setup for specific hosts, the BIG-IP Controller supports IP filters that you can configure to restrict traffic.

Configuring a pool

The first step in a basic configuration is to configure a pool of network devices, such as servers, firewalls, or caches. A pool contains the load balancing and persistence attributes for the members of the pool.

You can define pools from the command line, or define one using the web-based Configuration utility. This section describes how to define a simple pool using each of these configuration methods.

To create a pool using the Configuration utility

  1. In the navigation pane, click Pools.
    The Pools screen opens.
  2. In the toolbar, click the Add Pool button.
    The Add Pool screen opens.
  3. In the Add Pool screen, configure the load balancing method, persistence attributes, and members for the pool.

    Configuration note

    · For additional information about configuring a pool, click the Help button.

To define a pool from the command line

To define a pool from the command line, use the following syntax:

bigpipe pool <pool_name> {lb_mode <lb_mode> member
<member_definition> ... member <member_definition>}

For example, if you want to create the pool my_pool, with two members using Round Robin (rr) load balancing, from the command line, you would type the following command:

bigpipe pool my_pool { lb_mode rr member 11.12.1.101:80 member
11.12.1.100:80 }

Configuring virtual servers

The second step in a basic configuration is to configure virtual servers. This means that you have already configured a pool of servers that you can reference with a virtual server. Before you configure virtual servers, you need to know:

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

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

  • Define standard virtual servers
  • Define wildcard virtual servers

Using standard or wildcard virtual servers

Virtual servers reference a pool you create that contains 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 a pool of 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 a pool of transparent network devices such as firewalls, routers, or cache servers. Wildcard virtual servers are configured with an IP address of 0.0.0.0, and sometimes with a virtual port of 0.

    Note that both the Configuration utility and the bigpipe command line utility accept host names in place of IP addresses, and also accept standard service names in place of port numbers.

Using additional features with virtual servers

After you create a pool and define a virtual server that references the pool, you can set up additional features, such as network address translation (NAT) or extended content verification (ECV). If you are planning on using any of these features, you may want to read the corresponding section before you actually begin the virtual server configuration process.

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 that are members of a pool. 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 3-DNS Controller in conjunction with the BIG-IP Controller, the 3-DNS Controller uses the IP address associated with the registered domain name in its own configuration. For details, refer to the 3-DNS Controller Administrator Guide.

To define a standard virtual server that references a pool using the Configuration utility

  1. In the navigation pane, click Virtual Servers.
    The Virtual Servers screen opens.
  2. On the toolbar, click Add Virtual Server.
    The Add Virtual Server screen opens.
  3. In the Add Virtual Server screen, configure the attributes that you want to use with the virtual server.

    Configuration note

    · For additional information about configuring a virtual server, click the Help button.

To define a standard virtual server mapping from the command line

Type the bigpipe vip command as shown below. If you have DNS configured, you can also use host names in place of IP addresses. You can use standard service names in place of port numbers.

bigpipe vip <virt IP>:<port> use pool <pool_name>

For example, the following command defines a virtual server that maps to the pool my_pool:

bigpipe vip 192.200.100.25:80 use pool my_pool

Defining wildcard virtual servers

Wildcard virtual servers are a special type of virtual server designed to manage network traffic for transparent network devices, such as transparent firewalls, routers, proxy servers, or cache servers. A wildcard virtual server manages network traffic that has a destination IP address unknown to the BIG-IP Controller. A standard virtual server typically represents a specific site, such as an Internet web site, and its IP address matches the IP address that DNS associates with the site's domain name. When the BIG-IP Controller receives a connection request for that site, the BIG-IP Controller recognizes that the client's destination IP address matches the IP address of the virtual server, and it subsequently forwards the client to one of the content servers that the virtual server load balances.

However, when you are load balancing transparent nodes, a client's destination IP address is going to seem random. The client is connecting to an IP address on the other side of the firewall, router, or proxy server. In this situation, the BIG-IP Controller cannot match the client's destination IP address to a virtual server IP address. Wildcard virtual servers resolve this problem by not translating the incoming IP address at the virtual server level on the BIG-IP Controller. For example, when the BIG-IP Controller does not find a specific virtual server match for a client's destination IP address, it matches the client's IP address to a wildcard virtual server. The BIG-IP Controller then forwards the client's packet to one of the firewalls or routers that the wildcard virtual server load balances, which in turn forwards the client's packet to the actual destination IP address.

A note about wildcard ports

When you configure wildcard virtual servers and the nodes that they load balance, you can use a wildcard port (port 0) in place of an actual port number or service name. A wildcard port handles any and all types of network services.

A wildcard virtual server that uses port 0 is referred to as a default wildcard virtual server, and it handles traffic for all services. A port-specific wildcard virtual server handles traffic only for a particular service, and you define it using a service name or a port number. If you use both a default wildcard virtual server and port-specific wildcard virtual servers, any traffic that does not match either a standard virtual server or one of the port-specific wildcard virtual servers is handled by the default wildcard virtual server.

You can use port-specific wildcard virtual servers for tracking statistics for a particular type of network traffic, or for routing outgoing traffic, such as HTTP traffic, directly to a cache server rather than a firewall or router.

We recommend that when you define transparent nodes that need to handle more than one type of service, such as a firewall or a router, you specify an actual port for the node and turn off port translation for the virtual server.

Note: When you define a virtual server with port translation turned off, and you want to perform a service check on that node, you must configure service check intervals and timeouts using the port specified for the node. After the timeouts are configured, you can configure a service check. See Service checking for wildcard servers and ports on page 18-18, for more details.

Defining the wildcard virtual server mappings

There are two procedures required to set up a wildcard virtual server. First, you must define the wildcard virtual server. Then you must turn off port translation for the virtual server.

To define a wildcard virtual server mapping using the 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 Add Virtual Server screen, configure the attributes for the virtual server.

    Configuration note

    · Note that port 0 defines a wildcard virtual server that handles all types of services. If you specify a port number, you create a port-specific wildcard virtual server. The wildcard virtual server only handles traffic for the port specified.

    For additional information about the options on this screen, click the Help button.

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

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

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

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To define a wildcard virtual server mapping from the command line

There are three commands required to set up a wildcard virtual server. First, you must define a pool that contains the addresses of the transparent devices. Next, you must define the wildcard virtual server. Then you must turn port translation off for the virtual server. To define the pool of transparent devices, use the bigpipe pool command. For example, you can create a pool of transparent devices called transparent_pool that uses the Round Robin load balancing mode:

bigpipe pool transparent_pool { lb_mode rr member
<member_definition>... member <member_definition> }

To define the virtual server, use the bigpipe vip command:

bigpipe vip <virtual IP>:<port> use pool <pool_name>

After you define the virtual server, you can enable or disable port translation using the following command:

bigpipe vip <virtual IP>:<port> translate port enable | disable

For example, you can create a pool of transparent devices called transparent_pool that uses the Round Robin load balancing mode:

bigpipe pool transparent_pool { lb_mode rr member 10.10.10.101:80
member 10.10.10.102:80 member 10.10.10.103:80 }

After you create the pool of transparent nodes, use the following command to create a wildcard virtual server that maps to the pool transparent_pool. Because the members are firewalls and need to handle a variety of services, the virtual server is defined using port 0 (or * or any). You can specify any valid non-zero port for the node port and then turn off port translation for that port. In this example, service checks ping port 80.

bigpipe vip 0.0.0.0:0 use pool transparent_pool

After you define the virtual server, turn off port translation for the port in the virtual server definition. In this example, port 80 is used for service checking. If you do not turn off port translation, all incoming traffic is translated to port 80.

bigpipe vip 0.0.0.0:0 translate port disable

Allowing access to ports and services

One of the security features of the BIG-IP Controller is that all ports on the controller are locked down and unavailable for service unless you specifically open them to network access. Before clients can use the virtual servers you have defined, you must allow access to each port that the virtual servers use.

This is the third task of the four essential tasks you must complete for a basic configuration. You must perform this task after you create a pool and a virtual server that references the pool, and before you configure the timer settings.

Tip: This command is global, you only need to open access to a port once; you do not need to open access to a port for each instance of a virtual server that uses it.

To allow access to services using the Configuration utility

Any time you create a virtual server and define a port or service with the Configuration utility, the port or service is automatically enabled.

To allow access to services from the command line

Using the bigpipe port command, you can allow access to one or more ports at a time.

bigpipe port <port>... <port> enable

For example, in order to enable HTTP (port 80) and Telnet (port 23) services, you can enter the following bigpipe port command:

bigpipe port 80 23 443 enable

Warning: In order for FTP to function properly, you must allow both ports 20 and 21 (or ftp-data and ftp).

Configuring the timer settings

Configuring timer settings is the fourth task of the four essential tasks you must complete for a basic configuration. You must perform this task after you configure virtual servers and after you allow access to services and ports.

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

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

    The service check timer is optional, and you need to set it only if you want the BIG-IP Controller to check to see if a service, or even specific content, is available on a particular node.

    Note: If you plan to use simple service checks, or ECV or EAV service checks, you need to set the service check timer.

Setting the node ping timer

The node ping timer is an essential setting on the BIG-IP Controller that determines how often the BIG-IP Controller checks node addresses to see whether they are up and available or down and unavailable. The node ping timer setting applies to all nodes configured for use by the BIG-IP Controller, and it is part of the BIG-IP Controller system properties.

Note: The ping interval should be set to occur about three times during every timeout period. For example, if you set the ping value to 5 seconds, we recommend that you set the timeout to 16 seconds.

To set the node ping timer using the Configuration utility

  1. In the navigation pane, click the BIG-IP Controller icon.
    The BIG-IP System Properties screen opens.
  2. In the Node Ping section of the table, in the Ping box, type the frequency (in seconds) at which you want the BIG-IP Controller to ping each node address it manages. A setting of 5 seconds is adequate for most configurations.
  3. In the Node Ping section of the table, in the Timeout box, type the number of seconds you want the BIG-IP Controller to wait to receive a response to the ping.

    Configuration notes

    · 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

    · For additional information about the options on this screen, click the Help button.

To set the node ping timer from the command line

To define node ping settings, you use two commands. First, you set the node ping frequency using the bigpipe tping_node command, and then you set the node ping timer using the bigpipe timeout_node command.

bigpipe tping_node <seconds>

bigpipe timeout_node <seconds>

For example, the following commands sets the ping frequency at 5 seconds, and the timer to 16 seconds, which should be adequate for most configurations.

bigpipe tping_node 5

bigpipe timeout_node 16

Setting the timer for reaping idle connections

The BIG-IP Controller supports two timers for reaping idle connections, one for TCP traffic and one for UDP traffic. These timers are essential, and if they are set too high, or not at all, the BIG-IP Controller may run out of memory. Each individual port on the BIG-IP Controller has its own idle connection timer settings.

Warning: The BIG-IP Controller accepts UDP connections only if you set the UDP idle connection timer.

To set the inactive connection timer using the Configuration utility

  1. In the navigation pane, click the expand button (+) next to Virtual Servers.
    The Virtual Server tree opens and displays the Ports option.
  2. Click Ports.
    The Global Virtual Ports screen opens.
  3. In the Global Virtual Ports screen, click the port number or service name for which you want to configure the idle connection timeout.

    Configuration notes

    · For the HTTP connections, we recommend setting the Idle Connection Timeout TCP to 60 seconds. For other services such as Telnet, higher settings may be necessary.

    · In the Idle Connection Timeout UDP box, type the number of seconds you want to elapse before the BIG-IP Controller drops UDP connections.

    · For additional information about the options on this screen, click the Help button.

To set TCP idle connection timers from the command line

Use the bigpipe treaper to define a TCP idle connection timeout for one or more ports at a time. For HTTP connections we recommend only 60 seconds, but for other services such as Telnet we recommend higher settings. The default setting for this timer is 16 minutes (1005 seconds). Use the following syntax for this command:

bigpipe treaper <port>... <port> <seconds>

For example, the following command sets a 120 second time limit for idle connections on port 443:

bigpipe treaper 443 120

To set UDP idle connection timers from the command line

You can define a UDP idle connection timeout for one or more ports at a time using the bigpipe udp command.

bigpipe udp <port>... <port> <seconds>

For example, the following command sets a 120-second time limit for idle connections on port 53:

bigpipe udp 53 120

Setting the service check timer

The service check feature is similar to node ping, but instead of testing the availability of a server, it tests the availability of a particular service running on a server. The service check timer affects the three different types of service checks: simple service check, ECV service check, and EAV service check. To set up simple service check, you need only set the service check timer as described below. To set up ECV service check or EAV service check, however, you need to configure additional settings (see Configuring Extended Content Verification service checking on page 18-28).

Note that each individual service managed by the BIG-IP Controller has its own service check timer settings.

To set the service check timer using the Configuration utility

  1. In the navigation pane, click the expand button (+) next to Nodes.
    The Nodes tree opens and displays the Ports option.
  2. Click Ports.
    The Global Node Ports screen opens.
  3. In the Global Node Port Properties screen, click the port for which you want to configure the service check timer

    Configuration notes

    · For the Frequency setting, we recommend 5 seconds for most configurations.

    · For the Timeout setting, we recommend 16 seconds for most configurations.

    · For additional information about the options on this screen, click the Help button.

To set the service check timer on the command line

To define service check settings, you actually use 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 sequence of commands sets the service check frequency at 5 seconds, and the timer to 16 seconds, which is adequate for most configurations.

bigpipe tping_svc 80 5

bigpipe timeout_svc 80 16

Service checking for wildcard servers and ports

When you configure a wildcard virtual server with a 0 port using nodes with standard ports, such as 80, with port translation turned off, the BIG-IP Controller uses the standard service check timeout values (port 80, for example) to service check the port. For more information about setting the service check timer, see Setting the service check timer on page 18-17.

Note: The simple keyword is being phased out in future releases. This information is provided in order to support existing configurations.

The simple keyword is necessary only if you specified a node port of 0. In previous versions of the BIG-IP Controller, this was the only way to set up a wildcard virtual server that handled connections for all services. However, we now recommend that you specify a node port and then turn off port translation for the virtual server.

To set up a simple service check for this type of virtual server, add the following entry to the /etc/bigd.conf file. Use the following syntax to set a check on a node where the check port is not the node port:

simple [<node addr>:]<node port> <check port>

For example, a wildcard server is defined with a wildcard port, like this:

bigpipe vip 0.0.0.0:0 define n1:0

In this case, you must use the simple keyword to designate the wildcard <server:><port> and <check port> for the service check:

simple n1:0 80

Changing the global load balancing mode

Changing the global load balancing mode is one of the optional tasks you can perform after you have completed the three main tasks of a basic configuration. This means you already have:

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

    After you complete the basic tasks, you can change the global load balancing mode. The default global load balancing mode on the BIG-IP Controller is Round Robin, and it simply passes each new connection request to the next server in line, eventually distributing connections evenly across the array of machines being load balanced. Round Robin mode works well in most configurations, especially if the equipment that you are load balancing is roughly equal in processing speed and memory. If you want to use the Round Robin load balancing mode, you can skip this section, and begin configuring features that you want to add to the basic configuration.

    However, if you are working with servers that differ significantly in processing speed and memory, you may want to switch to Ratio load balancing mode. In Ratio mode, the BIG-IP Controller distributes connections among machines according to ratio weights that you define, where the number of connections that each machine receives over time is proportionate to the ratio weight you define for each machine.

Tip: The default ratio weight for a node is 1. If you keep the default ratio weight for each node in a virtual server mapping, the nodes receive an equal proportion of connections as though you were using Round Robin load balancing.

Note: The BIG-IP Controller also supports more advanced dynamic load balancing modes that may be suitable for your site. These modes include specific member load balancing modes that you can assign to specific pools. Refer to the BIG-IP Controller Reference Guide, for more information about working with specialized load balancing modes.

Using Ratio mode

If you want to switch the load balancing method used in a pool from Round Robin to Ratio you must modify the pool specification using the Configuration utility or from the command line. You change the load balancing mode to ratio_member, and you must assign a ratio weight to each member of the pool.

Switching to Ratio mode

First, you should set the load balancing mode to Ratio. The load balancing mode is actually a property of the BIG-IP Controller system, and it applies to all virtual servers defined on the system.

To switch the system to Ratio mode using the Configuration utility

  1. In the navigation pane, click Pools.
    The Pools screen opens.
  2. In the toolbar, click the Add Pool button.
    The Add Pool screen opens.
  3. Use the resources options to set the Ratio value for each member in the pool. In the Ratio box, type in a number to assign a ratio to this node within the pool. For example, if you are using the ratio load balancing mode and you type a 1 in this box, the node will have a lower priority in the load-balancing pool than a node marked 2.

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To switch the pool to Ratio mode on the command line

To switch the pool use the modify keyword with the bigpipe pool command. For example, if you want change the pool my_pool, to use the ratio_member load balancing mode, you can type the following command:

bigpipe pool my_pool modify { lb_mode ratio_member member
11.12.1.101:80 ratio 1 priority 1 member 11.12.1.100:80 ratio 3
priority 1 }

Configuring NATs and IP forwarding for nodes

Configuring NATs and IP forwarding are optional tasks you can configure after you have completed the three main tasks of a basic configuration. This means you already have:

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

    After you complete the basic tasks, you can configure network address translation and IP forwarding on the BIG-IP Controller.

    The IP addresses that identify nodes on the BIG-IP Controller's internal network need not be routable on the external network. This protects nodes from illegal connection attempts, but it also prevents nodes (and other hosts on the internal network) from receiving direct administrative connections, or from initiating connections to clients, such as mail servers or databases, on the BIG-IP Controller's external interface (destination processing).

    Using network address translation resolves this problem. Network address translations (NATs) assign to a particular node a routable IP address that the node can use as its source IP address when connecting to servers on the BIG-IP Controller's external interface. You can use the NAT IP address to connect directly to the node through the BIG-IP Controller, rather than having the BIG-IP Controller send you to a random node according to the load balancing mode. IP forwarding provides functionality similar to a NAT. If your network does not support NATs, you may want to consider using IP forwarding.

    Note: In addition to these options, you can set up forwarding virtual servers which allow you to selectively forward traffic to specific addresses. The BIG-IP Controller maintains statistics for forwarding virtual servers. For more information about forwarding virtual servers, see the BIG-IP Controller Reference Guide.

    There are three configuration options on the BIG-IP Controller that you can use to control network access, and you need to identify which method is suitable for your needs:

  • Network Address Translation (NAT)
    A network translation address provides a routable alias IP address that a node can use as its source IP address when making or receiving connections to clients on the external network. You can configure a unique NAT for each node address included in a virtual server mapping.

    NATs do not support port translation, and are not appropriate for FTP. You cannot define a NAT if you configure a default SNAT.
  • Secure Network Address Translation (SNAT)
    A secure network address translation provides functionality similar to that of firewalls. A SNAT defines a routable alias IP address that one or more nodes can use as a source IP address only when making connections to hosts on the external network. SNAT addresses support port translation, and they also prevent hosts on the external network from connecting directly to the node.

    SNAT only supports TCP and UDP. SNAT also features support for both passive and active FTP. You cannot define a NAT if you define a default SNAT.
  • IP forwarding
    IP forwarding does not translate node addresses. Instead, it simply exposes the node's IP address to the BIG-IP Controller's external network so that clients can use it as a standard routable address. When you turn IP forwarding on, the BIG-IP Controller acts as a router when it receives connection requests for node addresses. IP forwarding itself does not provide security features, but you can use the IP filter feature to implement a layer of security (see Setting up IP forwarding on page 18-27) that can help protect your nodes.

Warning: NATs and SNATs do not support NT Domain or CORBA IIOP. Instead of using NATs or SNATs, you need to configure IP forwarding (see Setting up IP forwarding on page 18-27).

Defining a standard network address translation (NAT)

When you define standard network address translations (NATs), you need to create a separate NAT for each node that requires a NAT. You also need to use unique IP addresses for NAT addresses; a NAT IP address cannot match an IP address used by any virtual or physical servers in your network. You can configure a NAT with the Configuration utility or from the command line.

To configure a NAT using the 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. Use the fields provided on the Add Nat screen to configure a NAT.

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To configure a NAT from the command line

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

bigppipe nat <node addr> to <NAT addr>

Defining a secure network address translation (SNAT)

When you define secure network address translations (SNATs), you can assign a single SNAT address to multiple nodes. Note that a SNAT address does not necessarily have to be unique; for example, it can match the IP address of a virtual server.

SNAT addresses have global properties that apply to all SNATs that you define in the BIG-IP Controller configuration as well as to the SNAT mappings you define. You can configure SNATs in the Configuration utility or from the command line.

Setting SNAT global properties

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

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

To configure SNAT global properties from the Configuration utility

  1. In the navigation pane, click Secure NATs.
    The Secure Network Address Translations screen opens.
  2. In the Secure Network Address Translation screen, configure a SNAT.

    Configuration notes

    · To turn connection limits off, type 0 in the Connection Limit box to turn connection limits off. If you turn connection limits on, keep in mind that each SNAT can support only 50,000 simultaneous connections.

    · The UDP Idle Connections value should not be set to 0.

    · For additional information about the options on this screen, click the Help button.

To configure SNAT global properties from the command line

Configuring global properties for a SNAT requires that you enter three bigpipe commands. The following command sets the maximum number of connections you want to allow for each node using a SNAT.

bigpipe snat limit <value>

The following commands set the TCP and UDP idle connection timeouts:

bigpipe snat timeout tcp <seconds>

bigpipe snat timeout udp <seconds>

Configuring SNAT address mappings

Once you have configured the SNAT global properties, you can configure SNAT address mappings. The SNAT address mappings define each SNAT address, and also define the node or group of nodes that uses the SNAT address. Note that a SNAT address does not necessarily have to be unique; for example, it can match the IP address of a virtual server. A SNAT address cannot match an address already in use by a NAT or another SNAT address.

To configure a SNAT mapping using the 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. To Configure the SNAT, fill in the fields on the screen.

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To configure a SNAT mapping from the command line

The bigpipe snat command defines one SNAT for one or more node addresses.

bigpipe snat map <node addr>... <node addr> to <SNAT addr>

For example, the command below defines a secure network address translation for two nodes:

bigpipe snat map 192.168.75.50 192.168.75.51 to 192.168.100.10

Setting up IP forwarding

If you do not want to translate addresses with a NAT or SNAT, you can use the IP forwarding configuration option. IP forwarding is an alternate way of allowing nodes to initiate or receive direct connections from the BIG-IP Controller's external network. IP forwarding exposes all of the node IP addresses to the external network, making them routable on that network. If your network uses the NT Domain or CORBA IIOP, IP forwarding is an option for direct access to nodes.

To set up IP forwarding, you need to complete two tasks:

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

Turning on IP forwarding

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

To set the IP forwarding system control variable using the Configuration utility

  1. In the navigation pane, click the BIG-IP Controller icon.
    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.

    Configuration note

    · For additional information about the options on this screen, click the Help button.

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

Use the standard sysctl command to set the variable. The default setting for the variable is 0, which is off. You want to change the setting to 1, which is on:

sysctl -w net.inet.ip.forwarding=1

To permanently set this value, you can use a text editor, such as vi or pico, to manually edit the /etc/rc.sysctl file. For additional information about editing this file, see the BIG-IP Controller Reference Guide, BIG-IP Controller System Control Variables.

Addressing routing issues for IP forwarding

Once you turn on IP forwarding, you probably need to change the routing table on the other routers in the network. Packets for the node addresses need to be routed through the BIG-IP Controller. For details about changing the routing table, refer to your router's documentation.

Configuring Extended Content Verification service checking

Extended content verification service checking is another feature you can configure after you have performed the three basic configuration tasks. Extended content verification service check is a special type of service check that actually retrieves content from a server. If the content matches the expected result, the BIG-IP Controller marks the node up and uses it for load balancing. If the content does not match, or if the server does not return content, the BIG-IP Controller marks the node down, and does not use it for load balancing.

You can set up ECV service check using the Configuration utility, or you can use a text editor, such as vi or pico, to manually create the /etc/bigd.conf file, which stores ECV information.

ECV service check is most frequently used to verify content on web servers, although you can use it for more advanced applications, such as verifying firewalls or mail servers. This section focuses on setting up ECV for web servers. For details about using advanced ECV service check options, see the Reference Guide.

Note: It is important to note that the intervals and timeouts for service checks apply to EAV and ECV service checks. These timeouts are configured by setting the service check timers. For more information about setting these timers, see Configuring the timer settings, on page 18-13.

ECV service check properties

ECV service check is a property of both a node port and a node. If you define ECV service check settings for a node port, all nodes that use the port inherit the ECV service check settings. You can override these settings by defining ECV service check settings for the node itself.

There are three different types of ECV service check settings that you can define:

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

Warning: When the BIG-IP Controller checks content looking for a match, it reads through the content until the service check times out, or until the read reaches 5,000 bytes, whichever comes first. When you choose text, an HTML tag, or an image name to search for, be sure to pick one that appears in the first 5,000 bytes of the web page.

Writing send and receive strings for ECV service checks

When you set up an ECV service check for a web server, you need to define a send string and a receive expression. A send string is the request that the BIG-IP Controller sends to the web server. Send strings typically request that the server return a specific web page, such as the default page for a web site. For example, the most common send string is "GET /" which simply retrieves the default HTML page for a web site. The receive expression is the text string that the BIG-IP Controller looks for in the returned web page.

Receive expressions use regular expression syntax, and they are not case-sensitive. Although regular expressions can be complex, you will find that simple regular expressions are adequate for most ECV service checks.

The corresponding receive string could be any simple text string included in your home page, such as text, HTML tags, or image names.

Sample send strings

The send string below is probably the most common send string, and it retrieves the default HTML page for a web site. Note that all send strings are enclosed by quotation marks (" ") inside the /etc/bigd.conf file.

"GET /"

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

"GET /www/support/customer_info_form.html"

Sample receive expressions

The most common receive expressions contain a text string that would be included in a particular HTML page on your site. The text string can be regular text, HTML tags, or image names. Note that all receive expressions are enclosed by quotation marks (" ").

For example, the following receive expression attempts to match the text Welcome, and it is useful for ECV reverse service checks:

"welcome"

The sample receive expression below searches for a standard HTML tag. Note that even though you are searching for an HTML tag, you still need to enclose the regular expression with quotation marks (" ").

"<HEAD>"

You can also use null receive expressions, formatted as the one shown below. When you use a null receive expression, the BIG-IP Controller considers any content retrieved to be a match.

""

Null receive expressions are suitable only for ECV normal and ECV SSL. Note, however, that if you use them you run the risk of the BIG-IP Controller considering an HTML error page to be a successful service check.

Note: The regular expression syntax discussed here is not the same as the wildcard syntax that is commonly used in command shells. For more information about regular expression, see the man page for re_format. To view the man page for re_format, type man re_format at the command line.

Setting up ECV service check using the Configuration utility

Using the Configuration utility, you can set ECV service check options in the Global Node Port Properties screen, and also in individual Node Properties screens. Regardless of which screen you use to configure the options, the steps are the same.

To set up ECV service check using the Configuration utility

  1. In the navigation pane, click Nodes.
    The Nodes screen opens.
  2. Select a node from the list.
    The Node Properties screen opens.
  3. If you want to configure ECV service check options, stay in this screen.

    If you want to configure ECV service check options for the port that the node uses, click the port number listed next to the IP address of the node.
  4. Click the ECV button.
  5. In the Type box, choose the type of ECV service check you want to set up: normal, reverse, or SSL.
  6. In the Send String box, type the send string that requests the web page. Note that the Configuration utility automatically places quotation marks around the string itself. For example, the following string retrieves the default HTML page for the site:

    GET /

  7. In the Receive Rule box, type the receive expression that the BIG-IP Controller should look for in the returned web page. For example, the following receive expression looks for a text string in a web page:

    Welcome home!

  8. Click the Apply button.

    Configuration note

    · For additional information about the options on this screen, click the Help button.

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

You can set up ECV service check on the command line by creating an /etc/bigd.conf file in a text editor such as vi or pico. Each line in the /etc/bigd.conf file defines a send string and a receive expression for one node, or for one port. Remember that when you define a ECV service check for a port, all nodes that use the port inherit the service check settings.

Changes to the /etc/bigd.conf do not take effect until the system is rebooted, or bigd is restarted. To restart bigd, simply run the command bigd.

The BIG-IP Controller provides a command line tool that allows you to verify the syntax of the /etc/bigd.conf file before the system begins using it. Once you set up the file, we recommend that you test it before you reboot the system or restart the bigd daemon and begin using the file.

Setting up the /etc/bigd.conf file

The /etc/bigd.conf file uses three different types of syntax for lines in the file that correspond to the three different types of service check that you can configure: ECV normal, ECV SSL, and ECV reverse. The following sections describe the syntax for each type, and provide some useful examples.

To set up an ECV normal service check

The line for a normal ECV service check begins with the keyword active. The <node IP> parameter is optional, and you need to include it only if you are defining an ECV service check for a specific node.

active [<node IP>:]<port> "<send_string>" "<recv_expr>"

For example, the following line sets up a normal ECV service check for a node, where the BIG-IP Controller looks for the text Welcome in the default page for the site.

active 192.168.100.10:80 "GET /" "welcome"

To set up ECV SSL service check

The line for an SSL ECV service check begins with the keyword ssl. The <node IP> parameter is optional, and you need to include it only if you are defining ECV service check for a specific node.

ssl [<node IP>:]<port> "<send_string>" "<recv_expr>"

For example, the following line sets up an SSL ECV service check for a node port. Note that the receive expression is null. When you use a null receive expression, the BIG-IP Controller considers any retrieved content to be a match.

ssl 443 "GET /www/orders/order_form.html" ""

To set up ECV reverse service check

The line for a reverse ECV service check begins with the keyword reverse. The <node IP> parameter is optional, and you need to include it only if you are defining ECV service check for a specific node.

reverse [<node IP>:]<port> "<send_string>" "<recv_expr>"

For example, the following line sets up a reverse ECV service check for a node port. Note that the receive expression is null. When you use a null receive expression, the BIG-IP Controller considers any retrieved content to be a match.

reverse 80 "GET /" ""

Testing /etc/bigd.conf syntax

To test /etc/bigd.conf syntax

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

/sbin/bigd -d

This command parses the file, checks ECV syntax, reports any errors, and then exits.

Note: The Big-IP Controller reads the /etc/bigd.conf file once at startup. If you change the file from the command line, you must reboot or restart bigd for the changes to take effect. If you make changes in the Configuration utility, clicking the Apply button makes changes and restarts bigd. For more information about bigd, see the BIG-IP Controller Reference Guide, System Utilities.

Configuring persistence for e-commerce and other dynamic content sites

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

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

    If you are setting up an e-commerce or other type of dynamic content site, you may need to configure persistence on the BIG-IP Controller. Whether you need to configure persistence or not simply depends on how you store client-specific information, such as items in a shopping cart, or airline ticket reservations. For example, you may store the airline ticket reservation information in a back-end database that all nodes can access; or on the specific node to which the client originally connected; or in a cookie on the client's machine.

    If you store client-specific information on specific nodes, you need to configure persistence. When you turn on persistence, returning clients can bypass load balancing and instead can go to the node where they last connected in order to get to their saved information.

    The BIG-IP Controller tracks information about individual persistent connections, and keeps the information only for a given period of time. The way in which persistent connections are identified depends on the type of persistence. The BIG-IP Controller supports two basic types of persistence:

  • SSL persistence
    SSL persistence is a type of persistence that tracks SSL connections using the SSL session ID, and it is a property of each individual pool. Using SSL persistence can be particularly important if your clients typically have translated IP addresses or dynamic IP addresses, such as those that Internet service providers usually 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 the BIG-IP Controller Reference Guide, Setting up persistence for a pool.

Setting up SSL persistence

SSL persistence is a property of a pool. You can set up SSL persistence from the command line or using the Configuration utility. To set up SSL persistence, you need to do two things:

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

To configure SSL persistence using the Configuration utility

  1. In the navigation pane, click Pools.
    The Pools screen opens.
  2. Click the appropriate pool in the list.
    The Pool Properties screen opens.
  3. In the toolbar, click the Persistence button.
    The Pool Persistence screen opens.
  4. Click the SSL Persistence button.
  5. In the Timeout box, type the number of seconds that the BIG-IP Controller should store SSL sessions IDs before removing them from the system.
  6. Click the Apply button.

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To configure SSL persistence from the command line

Use the following syntax to activate SSL persistence from the command line:

bigpipe pool <pool_name> modify { persist_mode ssl ssl_timeout
<timeout> }

For example, if you want to set SSL persistence on the pool my_pool, type the following command:

bigpipe pool my_pool modify { persist_mode ssl ssl_timeout 3600 }

Setting up simple persistence

You can set simple persistence properties for a pool. Pool 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 for a pool

Persistence settings for pools apply to both TCP and UDP persistence. When the persistence timer is set to a value greater than 0, persistence is on. When the persistence timer is set to 0, persistence is off.

To configure simple persistence for pools using the Configuration utility

  1. In the navigation pane, click Pools.
    The Pools screen opens.
  2. Select the pool for which you want to configure simple persistence.
    The Pool Properties screen opens.
  3. In the toolbar, click the Persistence button.
    The Pool Persistence Properties screen opens.
  4. In the Persistence Type section, click the Simple Persistence button.
    Type the following information:

    · Timeout (seconds)
    Set the number of seconds for persistence on the pool. (This option is not available if you are using rules.)

    · Mask
    Set the persistence mask for the pool. The persistence mask determines persistence based on the portion of the client's IP address that is specified in the mask.

  5. Click the Apply button.

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To configure simple persistence for pools from the command line

You can use the bigpipe pool command with the modify keyword to set simple persistence for a pool. Note that a timeout greater than 0 turns persistence on, and a timeout of 0 turns persistence off.

bigpipe pool <pool_name> modify { persist_mode ssl ssl_timeout
<timeout> simple_mask <ip_mask> }

For example, if you want to set SSL persistence on the pool my_pool, type the following command:

bigpipe pool my_pool modify { persist_mode ssl ssl_timeout 3600
simple_mask 255.255.255.0 }

Configuring and synchronizing redundant systems

Another optional feature you can configure after you have performed the three basic configuration tasks is configuration synchronization.

Redundant BIG-IP Controller systems have special settings that you need to configure, such as interface fail-safe settings. One convenient aspect of configuring a redundant system is that once you have configured one of the controllers, you can simply copy the configuration to the other controller in the system using the configuration synchronization feature in the bigpipe command line tool or in the Configuration utility.

There are two basic aspects to working with redundant systems:

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

Preparing to use the synchronization command

Before you can use the bigpipe configsync command or the Configuration utility to synchronize domestic HA redundant BIG-IP Controllers, you must first run the config_failover command. This command performs the following tasks:

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

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

    config_failover

    The config_failover utility prompts you for the root password of the other controller in the redundant system before it generates the security keys for the BIG-IP Controller.

Synchronizing configurations between controllers

Once you complete the initial configuration on the first controller in the system, you can synchronize the configurations between the active unit and the standby unit. When you synchronize a configuration, the following configuration files are copied to the other BIG-IP Controller:

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

    If you use command line utilities to set configuration options, be sure to save the current configuration to the file before you use the configuration synchronization feature. Use the following bigpipe command to save the current configuration:

    bigpipe -s

Warning: If you are synchronizing with a controller that already has configuration information defined, we recommend that you back up that controller's original configuration file(s).

To synchronize the configuration using the Configuration utility

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

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To synchronize the configuration from the command line

You use the bigpipe configsync command to synchronize configurations. When you include the all option in the command, all the configuration files are synchronized between machines.

bigpipe configsync all

If you want to synchronize only the /etc/bigip.conf file, you can use the same command without any options:

bigpipe configsync

Configuring fail-safe settings

For maximum reliability, the BIG-IP Controller supports failure detection on both internal and external interface cards. When you arm the fail-safe option on an interface card, the BIG-IP Controller monitors network traffic going through the interface. If the BIG-IP Controller detects a loss of traffic on an interface when half of the fail-safe timeout has elapsed, it attempts to generate traffic. An interface attempts to generate network traffic by issuing ARP requests to nodes accessible through the interface. Also, an ARP request is generated for the default route if the default router is accessible from the interface. Any traffic through the interface, including a response to the ARP requests, averts a fail-over.

If the BIG-IP Controller does not receive traffic on the interface before the timer expires, it initiates a fail-over, switches control to the standby unit, and reboots.

Warning You should arm the fail-safe option on an interface only after the BIG-IP Controller is in a stable production environment. Otherwise, routine network changes may cause fail-over unnecessarily.

Arming fail-safe on an interface

Each interface card installed on the BIG-IP Controller has a unique name, which you need to know when you set the fail-safe option on a particular interface card. You can view interface card names in the 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 using the Configuration utility

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

    Configuration note

    · For additional information about the options on this screen, click the Help button.

To arm fail-safe on an interface from the command line

One of the required parameters for the bigpipe interface command is the name of the interface itself. If you need to look up the names of the installed interface cards, use the bigpipe interface command with the show keyword:

bigpipe interface show

To arm fail-safe on a particular interface, use the bigpipe interface command with the failsafe arm keyword and interface name parameter:

bigpipe interface timeout <seconds>

bigpipe interface <ifname> failsafe arm

For example, you have an external interface named exp0 and an internal interface named exp1. To arm the fail-safe option on both cards with a timeout of 30 seconds, you need to issue the following commands:

bigpipe interface timeout 30

bigpipe interface exp0 failsafe arm

bigpipe interface exp1 failsafe arm