---

A

bigpipe Command Reference

---

bigpipe commands

This chapter lists the various bigpipe commands, including syntax requirements and functional descriptions. Table A.1 outlines the conventions used in the command line syntax.

The following table provides a concise listing of the individual bigpipe commands, along with the page reference where you can find the detailed description.

-?

For certain commands, displays online help, including complete syntax, description, and other related information. For example, to see online help for the bigpipe service command, type:

b service -?

authz

Creates or displays the parameter values that make up an SSL proxy authorization model.

Options

The <name> variable represents the name of the authorization model being created.

The [method] parameter specifies the type of authorization model. Currently, the only valid value for this parameter is ldap.

The [cachetimeout <number>] parameter specifies the length of timeout for the cache.

The [ldap searchtype] parameter specifies the type of search that the proxy will do on the LDAP database in its attempt to authorize a client.

The [ldap servers <server list>] parameter specifies the LDAP servers being used for authorization.

class

Creates, shows, and deletes any classes, such as class AOL. Default classes are also shown.

The BIG-IP system includes a number of predefined lists. They are:

• AOL Network
• Image Extensions
• Non-routable addresses

These lists are located in the file /etc/default_classes.txt. When the bigpipe load command is issued, the lists are loaded. Unless modified by a user, these lists are not saved to the file bigip.conf.

The following are examples of class types defined with the class command. Note that string classes require escape characters in the syntax to keep from being interpreted literally by the UNIX system.

b class string_class { \".abc\" ... } | '{ ".def" }'

b class numeric_class { 0 1 ... }

b class host_class { host 1.2.3.0 }

b class network_class { network 1.2.3.0 mask 255.255.255.0 }

Options

The <class name> variable specifies the name of a class. When creating a class, arguments to the <class name> variable can either be <ip member>, <string>, or <num>.

The <ip member> variable specifies the IP address of a member that is to be included in the specified class. The <ip member> option can be in the form of either host <ip addr> or network <ip addr> mask <ip addr>.

The <string> variable specifies one or more strings to be included in the specified class.

The <num> variable specifies one or more numeric values to be included in the specified class.

The <class name> show option displays the specified class.

The <value list> option lists the members that you want to add to a class.

The ip show option displays all classes that contain IP address members.

The string show option displays all classes that contain string values.

The value show option displays all classes that contain numeric values.

The show option with no other arguments displays all classes.

The <class name> delete option deletes the specified class.

config

Manages user configuration sets. A user configuration set (UCS) is the set of all configuration files that a user may edit to configure a BIG-IP system. A UCS file is an archive that contains all the configuration files in a UCS.

The config command allows you to save the system configuration to a UCS file, install the configuration from a UCS file, and synchronize the configuration with the other systems in a redundant system.

Options

The config save <file> option saves the currently running configuration to /config/bigip.conf and /config/bigip_base.conf, and creates the UCS file with the file name specified by <file>.

The config install <file> option unpacks and installs the UCS file specified by <file>, overwriting all configuration files, including the file /config/bigip.conf.

The config sync option saves the currently running configuration to the file /config/bigip.conf and copies the file /config/bigip.conf to the other BIG-IP unit in a redundant system.

The config sync all option creates a temporary UCS file and transfers it to the other BIG-IP unit.

The config sync running option saves the currently-running configuration to a temporary file and copies it to the other BIG-IP unit.

Saving configuration files to an archive

The config save <file> command saves all configuration files to a single archive file, <file>.ucs, on the local unit without copying it to the standby unit. By default, <file>.ucs is saved to the directory /user/local/ucs. An alternate location can be specified by expressing <file> as a relative or absolute path. For example:

b config save /user/local/config_backup/my_conf

This writes the file my_conf.ucs to the directory /user/local/config_backup.

Installing an archived configuration file

config install <file> reinstalls the archived configuration files saved as <file>.ucs to their working locations on the local unit.

If you use command line utilities to set configuration options, be sure to save the current configuration to the relevant files before you use the configuration synchronization feature. (Alternatively, if you want to test the memory version on the standby unit first, use bigpipe config sync running.) Use the following bigpipe command to save the current configuration:

b save

Note

---

A file named /usr/local/ucs/cs_backup.ucs is created prior to installing a UCS from a remote machine.

Synchronizing configuration files

config sync without the all option synchronizes only the basic configuration file /config/bigip.conf.

config sync all synchronizes the following configuration files:

• The common bigdb keys
• All common files in /config
• All common files in /etc

config sync running synchronizes the running version of /config/bigip.conf, which is the image that resides in memory as the system runs. This file is loaded into memory on the standby unit, it is not saved.

Note

---

The config sync command applies only to the BIG-IP system and not to 3-DNS.

config save <file> saves all configuration files to a single archive file, <file>.ucs, on the local unit without copying it to the standby unit. By default, <file>.ucs is saved to the directory /user/local/ucs. An alternate location can be specified by expressing <file> as a relative or absolute path. For example:

b config save /user/local/config_backup/my_conf

This writes the file my_conf.ucs to the directory /user/local/config_backup.

conn

Displays information about current client connections to virtual addresses and virtual servers. This command can also show connections that are active on the given BIG-IP system, as well as those that are standby connections for the peer BIG-IP system. By default, the dump command only shows items that are active on the given unit.

Options

The <client_ip>[:<client_service>] option specifies the IP address and the service of the system for which you want to display information.

The all option indicates that the action applies to all connections.

The verbose option displays all current connection information in verbose mode.

The mirror option displays information on standby connections.

The delete option searches for conections in which the specified IP address and service match the client-side source, and then deletes the connection.

Displaying all current connections

The following command displays all current client connections:

b conn dump

or

b conn all dump

The following output shows the source IP address, virtual server IP address, and node to which the client is connected.

This command can also show connections that are active on the given BIG-IP system, as well as those that are standby connections for the peer BIG-IP system. By default, the dump command only shows items that are active on the given unit.

Using verbose mode

The following command displays all current client connections, in verbose mode:

b conn dump verbose

The following shows sample output from this command:.

Displaying connections for a specific virtual server

Use the following syntax to display the current connections for a specific virtual server:

b conn <client_ip>[:<client_service>] dump

Note that the argument <client_service> refers to what is typically a five-digit number displayed in the output of this command.

Displaying standby connections

To view standby items, you must use the mirror qualifier, as follows.

b conn dump mirror

or

b conn dump verbose mirror

Deleting connections

To delete all current connections, you use the delete option as follows:

b conn delete

or

b conn all delete

When the delete option is specified, the b conn command searches for conections in which the specified address and service match the client-side source and then deletes the connection. The b conn command deletes the connection by sending a reset to both the client and the server.

If no service is specified, all connections in which the client-side source matches the IP address are deleted. If no IP address is specified, all connections are deleted.

The delete option does not differentiate between mirrored and normal connections. Thus, the option deletes any connections that were mirrored from an active unit.

Note

---

The delete option does not delete connections managed by the BIG-IP system hardware.

default_gateway

This command creates, shows, or deletes a pool of default gateways, with nodes in the pool corresponding to different routes. Connections originating from the system with a destination for which there is no other route choose a route from the default gateway pool. Note that the default gateway pool is not a last-hop pool for services running on the system.

There can be only one default gateway pool at any one time.

Defining a default gateway pool removes the need to define a default route. However, if a default route is defined, that route will be used when all the nodes in the default gateway pool are down.

Since the system performs route lookups on nodes as they are defined, the default gateway pool must be stored at the top of the bigip.conf file. Also, all nodes in the default gateway pool must reside on the same IP network as the system.

We recommend that all nodes in the default gateway pool have the same MTU.

As an alternative to using the default_gateway command, you can use the Setup utility, which allows you to create the default gateway pool at the time that you configure your base network.

Options

The use pool <pool_name> option specifies the name of the default gateway pool and must be 1-31 characters in length. Example: my_pool.

The show option shows the members of the default gateway pool.

The delete option deletes the default gateway pool.

failover

Switches the BIG-IP system or 3-DNS controller to be the standby unit in a redundant configuration. This command should be used with care, and is provided only for special situations. The BIG-IP system or 3-DNS Controller automatically switches between active and standby modes, without operator intervention.

Options

The standby option switches the BIG-IP system to the standby unit.

The show option displays the node on which the BIG-IP system is currently running.

The init option initializes the initial state of the BIG-IP system.

The failback option restorse an active-active configuration after a failure. This option is only valid when the BIG/store key Common.Bigip.Failover.ManFailBack has been created and set to a value of 1.

The linkdown <seconds> option specifies the amount of time to bring the interfaces down when the unit fails over to the standby unit. Used to prompt peer switch appliances into resetting and relearning their ARL tables after a failover.

Changing failover state

Before you switch the current mode, first determine which mode the BIG-IP system or 3-DNS Controller is running using the command above. In an active/standby or active-active configuration, run the following command to switch the system to be the standby unit:

b failover standby

Displaying failover status

Show the status of the BIG-IP system or 3-DNS Controller with the following command:

b failover show

Initializing failover state

You can use the bigpipe failover init command to refresh the parameters of the failover mechanism with any new configuration data entered into the bigdb database.

b failover init

Restoring an active-active configuration after failure

This command will only work when the BIG/store key Common.Bigip.Failover.ManFailBack has been created and set to a value of one.

In an active-active configuration, run the following command after you issue the bigpipe failover standby command. This allows the inactive unit to resume handling connections:

b failover failback

Note

---

The failback command is only applicable if you are running a redundant system in active-active mode.

Specifies the length of time that a BIG-IP unit in a VLAN group should keep its links down when they are dropped during a switch from active to standby mode. The value is specified in tenths of seconds. Thus, a value of 50 is equivalent to 5 seconds. By default, this feature is disabled, with a value of 0. The following command specifies a value of 5 seconds:

b global set standby_link_down_time = 50

global

audit

This variable logs all create, delete, and modify actions on the BIG-IP system.

auto_lasthop

When this variable is enabled, it automatically designates the lasthop router inside IP address as a lasthop route for replies to inbound traffic. If auto_lasthop is disabled, the lasthop router inside IP address must be specified as a lasthop pool. The default setting is enable.

broadcasts

This variable controls the acceptance or rejection of IP broadcast packets by the BIG-IP system.

fastest_max_idle_time

Sets the number of seconds a node can be left idle by the fastest load balancing mode. This forces the BIG-IP system to send fewer connections to a node that is responding slowly, and also allows the BIG-IP system to periodically recalculate the response time of the slow node.

fastflow_active

You can use this variable to control additional enhancements that speed packet flow for TCP connections when the packets are not fragmented. In most configurations, these software enhancements are automatically turned on, and do not require any additional configuration.

However, you may want to turn off these enhancements for individual virtual servers that use IPFW rate filters. With the speed enhancements on, IPFW only examines the first SYN packet in any given connection. If you want to filter all packets, you should turn the speed enhancements off. To do this, you first set the global state of the system on, and then you turn the feature off for individual virtual servers that use IPFW rate filtering. You can also change the settings for these enhancements from the command line or in the Configuration utility.

There are three global states you can set with fastflow_active. The default state is auto. The global states are:

• off
• auto
• on

The additional speed enhancements are globally disabled if the sysctl variable fastflow_active is off or if fastflow_active is set to auto and an IPFW rate filter exists in the configuration.

To provide the benefits of software acceleration for virtual servers that do not use rate filtering and turn off software acceleration for virtual servers that use IPFW rate filtering, you can set the global variable fastflow_active to on with the following command:

b global fastflow_active on

After you set the sysctl variable, use the following bigpipe command to disable software acceleration for virtual servers that use IPFW rate filtering:

b virtual <ip>:<port> accelerate disable

gateway failsafe

Turns the gateway fail-safe feature on and off. This command is supported only for redundant systems.

The typical use of gateway fail-safe is a setup where active and standby BIG-IP units use different routers as gateways to the Internet. Fail-over is triggered if the gateway for the active unit is unreachable.

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

b global gateway failsafe arm

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

b global gateway failsafe disarm

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

b global gateway failsafe show

ip forwarding

Enables IP forwarding for the BIG-IP system. IP forwarding exposes all of the node IP addresses to the external network, making them routable on that network. The default setting is disabled.

l2_aging_time

Specifies a time period after which dynamic entries in the L2 forwarding table are flushed out if the MAC address is no longer present on the network. The default value is 300 seconds.

memory_reboot_percent

The value you type, 80 or higher, is the percentage of memory that is in use before the BIG-IP system automatically reboots. The default value for this variable is 97. To disable this feature, set the value to 0.

mirror

Enables mirroring functions globally for the BIG-IP system. The mirror feature duplicates the active unit's real-time connection or persistence information state on the standby unit for smooth transition to the inactive unit at fail-over. The default setting is enabled.

mirror_vlan_forwarding

This variable is used to forward packets from a mirror-target VLAN to a source VLAN, after an intrustion detection system has attempted to terminate a connection.

msrdp no_session_dir

This variable is used to implement Windows Terminal Server persistence for those Windows servers on which the Session Directory service is not available.

open_3dns_ports

This variable is required only when running one or more separate 3-DNS Controllers in the network. It does not apply to running the 3-DNS software module on the BIG-IP system itself. The variable is disabled on the BIG-IP system when the 3-DNS Controller is not present in the network configuration. (See the 3-DNS Administrator Guide for more information.)

open_corba_ports

This variable enables and disables the CORBA ports that allow administrative CORBA connections. The default setting is disabled.

open_failover_ports

This variable enables or disables network failover when a VLAN has port lockdown enabled.

The following command enables network failover:

b global open_failover_ports enable

The following command disables network failover:

b global open_failover_ports disable

open_ftp_ports

This variable enables or disables ports for FTP access, and the default setting is disable.

The following command open the FTP ports (20 and 21) to allow administrative FTP connections, which is useful for BIG-IP units that do not support encrypted communications.

b global open_ftp_ports enable

The following command closes FTP ports:

b global open_ftp_ports disable

open_radius_ports

This variable is required for RADIUS authentication. Enabling this variable allows the kernel to safely send UDP traffic on external, locked-down ports, without compromising the shared RADIUS secret sent between client and server.

open_rsh_ports

This variable enables or disables ports for RSH access, and it is useful for BIG-IP units that do not support encrypted communications, or for connecting to 3-DNS Controllers that do not support encrypted communication. (See the 3-DNS Administrator Guide for more information.)

The default setting is disable.

The following command opens the RSH ports (512, 513, and 514) to allow RSH connections:

b global open_rsh_ports enable

The following command closes RSH ports:

b global open_rsh_ports disable

open_snmp_ports

This variable enables and disables the SNMP ports that allow administrative SNMP connections. The default setting is disabled.

open_ssh_ports

This variable enables or disables ports for SSH access on BIG-IP units that support encrypted communication. The default setting is enable.

The following command opens the SSH port (22) to allow encrypted administrative connections:

b global open_ssh_port enable

The following command closes the SSH port:

b global open_ssh_port disable

open_telnet_port

This variable enables or disables ports for Telnet access, and the default setting is disable.

The following command sets this variable to open the Telnet port (23) to allow administrative Telnet connections. This is useful for BIG-IP units that do not support encrypted communications, or for a unit that needs to communicate with the 3-DNS software. (See the 3-DNS Administrator Guide for more information.)

The following command opens the Telnet port:

b global open_telnet_port enable

The following command closes the Telnet port:

b global open_telnet_port disable

persist across_services

When this variable is enabled, all simple persistence connections from a client IP address that go to the same virtual address also go to the same node (matches the client address and the virtual IP address but not the virtual port).

The default setting for this variable is disabled.

persist across_virtuals

When this variable is enabled, all simple persistent connections from the same client IP address are sent to the same node (matches the client IP address but not the virtual address or virtual port the client is using). The default setting for this variable is disabled.

persist map_proxies

The default setting for the map proxies for the persistence variable is enable. The AOL proxy addresses are hard-coded. This enables you to use client IP address persistence with a simple persist mask, but forces all AOL clients to persist to the same server. All AOL clients will persist to the node that was picked for the first AOL client connection received.

The class B networks, 195.93 and 205.188, are mapped to 152.163 for persistence. For example, client 195.93.3.4 would map to 152.63.3.4 for persistence records only. This mapping is done prior to applying the persist mask. Use bigpipe pool persist dump to verify that the mapping is working.

We recommend that in addition to setting this sysctl variable, you set a persist mask of 255.255.0.0 so that all the AOL addresses map to a common address. For example, Table A.2 is an example of how setting this variable and a persist mask of 255.255.0.0 would map a sample set of client addresses.

persist timer

The following command forces the persistent connection timer to reset on each packet for persistent sessions.This is the default value.

b global persist timer timeout

The following command resets the timer only when the persistent connection is initiated.

b global persist timer limit

Note

---

For SSL persistence, the timer is always reset on each packet.

reaper hiwater

Used to prevent denial-of-service attacks, this variable specifies a high-watermark threshold for determining when unestablished connections through the BIG-IP system will no longer be allowed. The value of this variable represents a percentage of memory utilization. Once memory utilization has reached this mark, connections are disallowed until the available memory has been reduced to the low-watermark threshold. For example, the following command specifies that connections will no be allowed when memory utilization reaches 95%:

b global reaper hiwater 95

Setting this value to 100 disables the feature. See also reaper lowater .

reaper lowater

Used to prevent denial-of-service attacks, this variable specifies a low-watermark threshold for determining at what point adaptive reaping becomes more aggressive. For example:

b global reaper lowater 85

The default setting for this variable is 85. Setting this value to 100 disables the feature. See also reaper hiwater .

self_conn_timeout

This variable is used as a tracking mechanism for UDP connections. After the number of seconds specified by this variable has expired, the UDP connection terminates. The default value for this variable is 5.

snats any_ip

When this variable is disabled, the BIG-IP system attempts to forward an any-IP packet originating from a member of a SNAT, instead of rejecting that packet.

sslproxy akamaizer filename

This variable specifies the SSL proxy akamaizer filename. The default file name is /config/akamai.conf.

sslproxy akamaizer service

This variable specifies the SSL proxy akamaizer service. The default service is 0, representing no service.

sslproxy failover

This variable causes the SSL proxy to initiate an automatic failover, in the event of a fatal failure of a cryptographic hardware module. Two settings are allowed--enable and disable. The default setting is disable.

Note that this use of this variable depends on the type of hardware module, as not all hardware modules respond to failures in the same way.

sslproxy serverssl cache size

This variable specifies the maximum size of the server-side SSL session cache. The default value is 20,000 entries. A value of 0 disallows session caching. Note that this value is for server-side cache size only. Client-side cache size is configured on a per-proxy basis, using the bigpipe proxy command.

sslproxy serverssl cache timeout

This variable specifies a timeout value for the server-side SSl session cache. Note that this value is for the server-side cache timeout only. Client-side cache timeout is configured on a per-proxy basis, using the bigpipe proxy command.

sslproxy strict resume

This variable allows the SSL proxy to either resume or not resume the SSL sessions after an unclean shutdown. The two settings are enable and disable. The default setting is disable, which causes the SSL proxy to allow uncleanly shut down SSL sessions to be resumed.

sslproxy unclean shutdown

This variable causes the SSL proxy to perform either a clean or an unclean shutdown of all SSL connections. The default setting is enable, which causes the SSL proxy to perform unclean shutdowns. To force the SSL proxy to perform clean shutdowns, you use the disable option.

sticky table_limit

This is the maximum number of sticky entries allowed to accumulate on the BIG-IP system when using destination address affinity (sticky persistence). When the maximum value is reached, the BIG-IP system stops accumulating sticky entries. The default value for this entry is 2048.

verbose_log_level

This variable specifies logging levels for both TCP and UDP traffic. To set this logging level, specify a number. The default setting is 0, representing no logging. Table shows the result of providing various values on the command line.

For example, the following command turns on port denial logging for both TCP and UDP traffic. This logs TCP and UDP port denials to the virtual server address and the BIG-IP address.

b global verbose_log_level 15

The following command turns logging off altogether:

b global verbose_log_level 0

vlangroups

Enables layer 2 operation for VLAN groups. By default, VLAN groups are a hybrid of layer 2 proxy ARP with layer 3 forwarding. Using this variable, you can change the way that VLAN groups operate. Available settings for this variable are:

opaque
A proxy ARP with layer 3 forwarding. The command line syntax for enabling this setting is:

b global vlangroups opaque

translucent
Layer 2 forwarding with locally-unique bit, toggled in ARP response across VLANs. This is the default setting.

transparent
Layer 2 forwarding with the original MAC address of the remote system preserved across VLANs. The command-line syntaxfor enabling this setting is:

b global vlangroups transparent

vlans lookup

Enables VLAN-keyed connections. VLAN-keyed connections are used when traffic for the same connection must pass through the BIG-IP system several times, on multiple pairs of VLANs (or in differenct VLAN groups). The default setting is enable. To disable this feature, use the following command:

b global vlans lookup disable

vlans unique_mac

This variable is used to circumvent problems caused by problematic switch appliances that do not keep per-VLAN L2 forwarding tables. When set to enable, this variable causes VLANs to assume the MAC address of the first non-hidden member interface. When set to disable, a single MAC address is used for all VLANs.

The default setting for server appliances is enable. The default setting for switch applicances is disable.

If a non-default setting is used, you must set the variable before you load any VLANs. Also, you must reload the base configuration after changing the setting of this variable.

webadmin_port

Specifies the port number used for administrative web access. The default port for web administration is port 443.

web aggregate

This variable provides fine-grained control of client aggregation. Possible settings are:

all
Causes all clients, regardless of IP address, to be piggy-backed on established idle connections to servers.

ip
This is the default setting. Causes all clients with the same IP address to be piggy-backed on established idle connections to servers.

port
Causes only requests from both the same client source IP address and source port to be aggreagated. This behavior is required for enabling non-compliant HTTP implementations to use keep-alives.

none
Establishes a connection to back-end servers with each new request in the front-end stream, regardless of the viability of idle connections.

web aggregate timeout

This variables allows you to configure a timeout value, in seconds, for the idle HTTP connection reaper. The minimim timeout value allowed is 1. The maximum timeout value is INT_MAX, currently defined as 2147483647. The default timeout value is 5.

web escapes

This variable decodes "%" escape characters in URIs before comparison, using a rule. The variable can be set to decode or ignore. The default setting is ignore.

web parse

The first option to this variable disables both aggregation and keep-alive parsing, reverting the BIG-IP system to its pre-4.0 behavior. The default setting is all.

-h and -help

Displays the bigpipe command syntax or usage text for all current commands.

Note

---

More detailed man pages are available for some individual bigpipe commands. To display detailed online help for the bigpipe command, type: man bigpipe.

interface

Displays the names of installed network interface cards and, for each interface, sets properties such as MAC address, media options, duplex mode, and status, resets interface statistics, enable or disable interfaces, and change driver name mappings.

Options

The <interface_name> variable is a name such as 3.1, where 3 is the physical slot number holding the network interface hardware and 1 is the physical port number on that interface on that hardware.

The show [verbose] option displays the current status, settings, and network statistics for the specified interface. The verbose argument provides more detailed information. If no interface is specified, this option displays information for all interfaces.

The media show option displays information about the media type for the specified interface.

The duplex show option displays the duplex mode of the specified interface.

The media <media_type> option is a valid media type for the specified interface. Examples include auto, 100baseTX, and 10baseT. Note that only certain combinations of media type and duplex mode are valid for any particular type of interface.

The duplex full | half | auto option sets the duplex mode of the specified interface.

The stats reset option resets the statistics for the specified interface.

The enable | disable option enables or disables the specified interface.

The renames <driver_name> option changes the mapping from the interface's driver name to its physical location name. The <driver_name> option is the network interface name in the form of driver and unit number, such as exp0 and bs1. Note that this is the old-style network interface name.

Displaying interface information

To display the status, settings, and statistics for all interfaces on the BIG-IP system, use the following command.

b interface show [verbose]

To display the status, settings, and statistics for a specific interface on the BIG-IP system, use the following command-line syntax.

b interface <interface_name> show [verbose]

Note that if the verbose argument is used, the output provides additional information on status. If the verbose argument is not used, the output focuses on statistics.

To display the media type for an interface, use the following command-line syntax,

b interface <interface_name> media show

To display the duplex mode for an interface, use the following command-line syntax.

b interface <interface_name> duplex show

Setting the media type

The media type may be set to the specific media type for the interface card or it may be set to auto for auto detection. If the media type is set is set to auto and the card does not support auto detection, the default type for that interface will be used, for example 1000BaseTX.

To set the media type, use the following command-line syntax.

b interface <interface_name> media <media_type>

Setting the duplex mode

Duplex mode may be set to full, half duplex, or auto. If the media type does not allow duplex mode to be set, this will be indicated by an onscreen message. If media type is set to auto, or if setting duplex mode is not supported, the duplex setting will not be saved to the bigip.conf file.

To set the duplex mode, use the following command-line syntax.

b interface <interface_name> duplex full | half | auto

Resetting statistics

You can reset interface statistics for all interfaces or for a specific interface.

To reset statistics for all interfaces, use the following command.

b interface stats reset

To reset statistics for a specific interface, use the following command-line syntax:

b interface <interface_name> stats reset

Enabling or disabling an interface

Enabling or disabling an interface allows you to control whether the interface receives and sends packets. If an interface begins to behave strangely, you disable and then enable the interface to effectively reset it.

To enable or disable an interface, use the following command-line syntax.

b interface <interface_name> enable | disable

Changing driver name mapping

You can change the mapping from an interface's driver name to its physical location name, using the following syntax.

b interface <interface name> renames <driver name>

load

Resets all of the BIG-IP system settings and then loads the configuration settings, by default from the /config/bigip.conf and /config/bigip_base.conf files.

For testing purposes, you can save a test configuration by renaming it to avoid confusion with the boot configuration file. To load a test configuration, use the load command with the <filename> parameter. For example, if you renamed your configuration file to /config/bigtest.conf, the command would be:

b load /config/bigtest.conf

The command checks the syntax and logic, reporting any errors that would be encountered if the command executed.

You can type b load - in place of a file name, to display the configuration on the standard output device.

b save -

Use the load command together with the verify command to validate the specified configuration file. For example, to check the syntax of the configuration file /config/altbigpipe.conf, use the following command:

b verify load /config/altbigip.conf

The -log option will cause any error messages to be written to /var/log/bigip in addition to the terminal.

maint

Toggles a BIG-IP system into and out of maintenance mode. When in maintenance mode, a BIG-IP system accepts no new connections, but it does allow existing connections to complete.

The maint command interactively prompts you to enter or exit the maintenance mode.

b maint

If the BIG-IP system is already in maintenance mode, the maint command takes the BIG-IP system out of maintenance mode. If the BIG-IP system is in maintenance mode for more than 20 minutes, that BIG-IP system immediately begins to accept new connection requests.

If the BIG-IP system has been in maintenance mode for more than 20 minutes, it automatically updates all network ARP caches; this process normally takes a few seconds. However, you can speed up the process by reloading the configuration file, using the following command:

b -f /config/bigip.conf

makecookie

Creates a cookie template similar to the templates shown in Figure A.3 and Figure A.4 . The command generates a cookie string with encoding automatically added for the Passive mode of cookie persistence. The comand-line syntax is as follows:

b makecookie <server_address:service> [ > <file>].

To create your cookie using the sample string above, simply enter the actual pool names and the desired expiration date and time.

merge

Loads the BIG-IP system configuration from the file specified in the <file_name> variable, without resetting the current configuration.

mirror

For the BIG-IP Application Switch, you can copy traffic from any port or set of ports to a single, separate port. This is called port mirroring. You should attach a sniffer device to the target port, called the mirror-to port, for debugging and/or monitoring.

Options

The <mirror_to_interface> variable specifies the port to which you want one or more ports to be mirrored.

The show option displays a specific mirror-to interface. If no interface is specified, this option displays all mirror-to interfaces.

The interfaces add <interface_list> variable specifies one or more ports that you want to mirror to the mirror-to port.

The interfaces delete <interface_list> variable specifies one or more ports that you want to delete from a port mirror.

The delete option deletes the specified mirror-to interface.

Displaying port mirroring

Using the argument, you can display all mirror-to interfaces or a specific mirror-to interface.

To display all mirror-to interfaces, type the following command:

b mirror show

To display a specific mirror-to interface, use the following command-line syntax:

b mirror <mirror_to_interface> show

Creating a port mirror

Creating a port mirror consists of specifying a mirror-to port and adding to it one or more ports (that is, a port list) to be mirrored. The bigpipe syntax for setting up port mirroring is:

b mirror <mirror_to_interface> interfaces add <interface_list>

For example, you could type the following command:

b mirror 3.24 interfaces add 3.1 3.3 3.10

Deleting interfaces from a port mirror

The bigpipe syntax for deleting interfaces from a port mirror is as follows:

b mirror <mirror_to_interface> interfaces delete <inteface_list>

For example, you could type the following command:

b mirror 3.24 interfaces delete 3.10

Deleting a port mirror

The bigpipe syntax for deleting a port mirror is:

b mirror <mirror_to_interface> delete

For example, you could type the following command:

b mirror 3.24 delete

monitor

Defines a health monitor. A health monitor is a configuration object that defines how and at what intervals a node is pinged to determine if it is up or down. Once a monitor is defined, instances of the monitor are created for a node or nodes, one instance per node, using the bigpipe node command.

Monitors verify services and connections of node servers. The icmp or tcp_echo monitors may be used to monitor node addresses. If the node server or node address fails to respond in the specified timeout period, it will be markedas down. When a node server or node address is marked as down, traffic is no longer directed to it.

Several steps are needed to create a monitor and associate it with a node server or node address. A monitor must be created, based on a monitor template that the BIG-IP system provides. In some cases, a monitor template is directly usable. Once a monitor is created, the node address or node server is associated with the monitor, creating a monitor instance.

Options

The <monitor_name> variable specifies the name you want to use for the monitor you are creating or managing.

The <monitor_template> variable specifies the health monitor template you want to use to create your monitor. For a list of templates that you can specify, see Monitor templates, on page A-43 .

The <attr> variable specifies an attribute of the monitor to which you want to assign a value. For a list of monitor attributes, see Monitor templates, on page A-43 .

The <attr_value> variable specifies the value of the attribute specified with the <attr> option.

The show all option displays all existing monitors.

The show option displays the specified monitor.

The delete option deletes the specified monitor.

The enable | disable option enables or disables the specified monitor.

The instance <ip address>:<service> option enables or disables a monitor instance for the specified IP address and port.

The instance <ip address> option enables or disables a monitor instance for the specified IP address.

Creating a monitor

Creating a monitor simply names and sets the options for a monitor, based on a monitor template. The options may be obtained from a predefined set of default options or the option values may be specified on the command line during creation.

Options include destination address, interval time, timeout value, send string, and receive string, etc. Options can be changed later using the modify option.

The following is an example of a command to create an http monitor:

b monitor my_http '{ use http send "GET /my.html" recv "TESTING" }'

The command above creates a monitor with the name my_http, based on the http template. The send and recv strings are modified from the default values. The interval, timeout, destination address, username, and passwd configuration options are not specified on the command line because the monitor will use the default values.

Note that single quotes are used when entering monitor commands on the command line, to prevent the command shell from attempting to interpret the double quotes within the monitor definition.

Modifying a monitor

If you want to change the default values of certain options, such as interval and timeout, you can use syntax as in the following example:

b monitor my_http '{ interval <seconds> timeout <seconds> }'

Creating a monitor instance

Creating a monitor instance simply associates a monitor or group of monitors with a node address or node server.

Each monitor template contains a destination address option. Almost always, this is the meta character string "*:*", which causes the BIG-IP system to create the monitor instance using the IP address and port supplied on the command line. For example, the destination address option dest in the tcp monitor template looks as follows:

monitor tcp {

# type tcp
interval 5
timeout 16
dest *:*
send ""
recv ""

}

We can create two instances of this monitor by entering the following command:

b node 10.10.10.10:80 10.10.10.12:80 monitor use tcp

The dest *:* attribute in the tcp monitor causes the two monitor instances to be created, substituting the IP address and port combination supplied on the command line into the destination address. In other words, there are two monitor instances created, one that communicates with address 10.10.10.10:80, and one that communicates with 10.10.10.12:80. The node 10.10.10.10:80 depends on the monitor instance 10.10.10.10:80. If the monitor instance cannot get a response from node 10.10.10.10:80, then the node is marked as down. The same is true for node 10.10.10.12:80.

It is also possible to enter explicit addresses into a monitor. For example, the following shows a monitor called exp_tcp that specifies an explicit destination address:

monitor exp_tcp {

# type tcp
use "tcp"
interval 5
timeout 16
dest 10.10.10.24:80
send ""
recv ""

}

In this case, the following command causes one monitor instance to be created, one that communicates with address 10.10.10.24:80:

b node 10.10.10.10:80 10.10.10.12:80 monitor use exp_tcp

In this case, the nodes 10.10.10.10:80 and 10.10.10.12:80 depend on the health of node 10.10.10.24:80. If that node does not respond, both 10.10.10.10:80 and 10.10.10.12:80 are marked as down.

The following is another example of specifying a destination address on the command line:

b node '*:http' monitor use my_http

The command above creates a monitor instance for all node addresses with a service of http. Note that it is necessary to enter the single quotes when entering this command on the command line to prevent the shell from interpreting the special character *.

Modifying a monitor instance

The enable/disable attribute can be changed within a monitor instance. For example:

b monitor instance 10.20.3.2:http disable

This command disables a monitor instance for a node server. The monitor will not attempt to establish a connection with the service until it is later enabled.

Deleting a monitor

To delete a monitor, use the bigpipe monitor command with the delete option, as in the following example:

b monitor my_http delete

Deleting a monitor instance

To delete a monitor instance, use the bigpipe node command with the delete option, as in the following example:

b node '*:http' monitor delete

Displaying monitor templates

To display a specific monitor template, use the following command-line syntax:

b monitor <monitor template> show

When you issue the above command, the BIG-IP system displays the specified template.

To display all monitor templates, use the following command:

b monitor show all

Displaying monitor instances

Using the bigpipe node command, you can display the status of a monitor instance, along wiht the corresponding node status. For example:

bigpipe node 192.168.200.50:http monitor show

To see this information for all monitor instances, use the following command:

b node monitor show

Monitor templates

Table A.4 lists the monitor templates and shows the template-specific attribute sets for each.

Table A.5 on the next page defines the attributes used in the monitor templates.

-n

Used with other commands, such as bigpipe virtual, to display services and IP addresses numerically rather than by service name and host name, respectively. For example, type the following command to display services numerically:

b -n virtual

Figure A.5 shows an example of output that uses IP address instead of host names.

nat

Defines a network addtress translation (NAT), which is an IP address, routable on the external network, that a node can use to initiate connections to hosts on the external network and receive direct connections from clients on the external network. The nat command command defines a mapping between the IP address of a server behind the BIG-IP system <orig_addr> and an unused routable address on the network in front of the BIG-IP system <trans_addr>.

The primary reason to define a NAT is to allow one of the servers in the server array behind the BIG-IP system to initiate communication with a computer in front of or external to the BIG-IP system.

Options

The <orig addr> variable is the originating IP address.

The <trans addr> variable is the translated IP address.

The unit <unit ID> option specifies a unit ID, currently 1 or 2. The default unit ID is set to 1.

The delete option deletes a NAT from the BIG-IP system.

The stats reset option resets statistics for the specified NAT.

The vlans <vlan_list> option lists the existing VLANs on which access to the NAT is enabled or disabled. A NAT is accessible on all VLANs by default.

The vlans delete all option deletes the specified NAT for all VLANs.

The vlans show option displays the VLANs on which the specified NAT is enabled.

Defining a NAT

Use the following syntax to define a NAT:

bigpipe nat <orig ip> to <trans ip> [unit <id>] [arp disable] \
[vlans <vlan name>... disable]

The node behind the BIG-IP system with the IP address specified by <orig ip> has a presence in front of the BIG-IP system as IP address <trans ip>.

For example:

b nat 11.0.0.100 to 10.0.140.100

Deleting a NAT

Use either of the following commands to permanently delete one or more NATs from the BIG-IP system configuration:

b nat <orig_addr>... <orig_addr> delete

b nat <trans_addr>... <trans_addr> delete

Additional Restrictions

The nat command has the following additional restrictions:

• A virtual server cannot use the IP address defined in the <trans ip> parameter.
• A NAT cannot use the IP address of a BIG-IP system.
• The IP address defined in the <orig ip> parameter must be routable to a specific server behind the BIG-IP system.
• A NAT cannot use an orignating or translated IP address defined fo and used by a SNAT or another NAT.
• You must delete a NAT before you can redefine it.

node

Displays information about nodes and allows you to set properties for nodes, and node addresses. Nodes may be identified using wildcard notation. Thus * represents all nodes on the network, *.80 represents all port 80 nodes, 11.11.11.1:* represents all nodes with address 11.11.11.1.

Options

The <node_ip>[:<service>] variable is an IP address of the node address.

The enable | disable options enable or disable traffic for one or more specified IP addresses.

The limit <max_conn> option defines the maximum number of connections allowed for one or more specified nodes.

The stats reset option resets statistics for the specified node.

The up | down option causes a node to change to the "forced up" or "forced down" state.

The monitor use <monitor_name> option associates one or more specified monitors with the specified node.

The monitor show | delete option shows or deletes a monitor instance running on the specified node.

Displaying nodes

You can display information about a specified node. For example, the following command displays information about node 192.168.200.50:20:

b node 192.168.200.50:20 show

Note that the show keyword is optional.

The resulting information displayed is as follows:

NODE 192.168.200.50 UP CHECKED

| (cur, max, limit, tot) = (0, 0, 0, 0)

| (pckts,bits) in = (0, 0), out = (0, 0)

+- PORT 20 UP CHECKED

(cur, max, limit, tot) = (0, 0, 0, 0)

(pckts,bits) in = (0, 0), out = (0, 0)

Modifying nodes

Use the following syntax to set the maximum number of connections allowed for one or more nodes:

b node <ip addr>:<port>... <ip addr>:<port> limit <limit>

Note that to remove a connection limit, you also issue the above command, but you set the <limit> variable to zero.

Use the following syntax to set the maximum number of connections allowed for one or more IP addresses:

b node <ip addr>... <ip addr> limit <limit>

Note that to remove a connection limit, you also issue the above command, but you set the <limit> variable to zero.

Use the following syntax to enable or disable traffic for one or more IP addresses:

b node <ip addr>... <ip addr> enable

b node <ip addr>... <ip addr> disable

Note

---

For information on using the bigpipe node command to associate a node with a health monitor, see monitor.

pool

Displays, creates, modifies, or deletes a pool definition. You can use pools to group members together with a common load-balancing mode and persistence mode.

Options

The <pool name> variable is a string from 1 to 31 characters, for example, new_pools.

The <member_definition> variable specifies the IP address of the member node being added to the pool.

The <cookie name> variable specifies a cookie name, which must be 1-31 characters in length.

The lb_method <lb_method_specification> option specifies the load balancing mode that the BIG-IP system is to use for the specified pool.

The persist <persist_mode_specification> option specifies the persistence type that BIG-IP system is to use for the specified pool.

The select <expression> option specifies the data to be used to directly select a node in the pool.

The min_active_members <min_value> option specifies the minimum number of members that must remain available for traffic to be confined to a priority group when using priority-based activation.

The fallback option specifies HTTP redirection, using a set of format strings. You can use these strings to indicate unchanged host names, ports, and URI paths. For more information, see Specifying HTTP redirection .

The forward option specifies that the pool is to be a forwarding pool.

The snat disable option specifies that SNAT connections are to be disabled for that pool.

The mirror option mirrors a persistence record over to a standby unit. The persistence record identifies the connections to be persisted.

Displaying a pool

Using the bigpipe pool command, you can display specific pools or all pools, and display persistence within a pool.

Use the following syntax to display all pools:

bigpipe pool show

Use the following syntax to display a specific pool, such as cgi_pool:

bigpipe pool cgi_pool show

Use a c ommand such as the following to display persistence within a pool:

bigpipe pool cgi_pool persist show

Creating a pool

To create a pool, use command-line syntax such as the following:

bigpipe pool cgi_pool { lb_method rr member 10.2.3.11:http \
member 10.2.3.12:http }

This command creates a pool with two members 10.2.3.11 and 10.2.3.12, and both members use the round robin load balancing method.

If the lb_method option is not set, it defaults to round robin.

To create a pool using simple persistence, use command-line syntax such as the following:

bigpipe pool cgi_pool { lb_method rr persist_mode simple \
simple_timeout 100 simple_mask 255.255.255.0 \
member 10.20.3.11:http member 10.20.3.12:http }

This command creates a pool with two members, 10.20.3.11 and 10.20.3.12.

Both members use the round robin load balance method. Also, a simple persistence timeout of 100 seconds will be used with this pool. Note that an optional persistence mask may be specified with simple persistence.

Modifying a pool

You can modify a pool to change the defined attributes, such as adding or deleting members, changing the load balancing method, or changing the type of persistence being used.

The following example adds a new member to the existing pool cgi_pool:

bigpipe pool cgi_pool add { member 10.20.3.2:http }

The following example deletes a member from the existing pool cgi_pool:

bigpipe pool cgi_pool delete { member 10.20.3.2:http }

Deleting a pool

You can delete a pool altogether. For example, the following command deletes the pool cgi_pool:

bigpipe pool cgi_pool delete

Note that all references to a pool must be removed before a pool can be deleted.

Specifying HTTP redirection

To specify HTTP redirection (also known as fallback), you can use a set of format strings to indicate unchanged host names, ports, and URI paths. These format strings are as follows:

• %h
  Host name, as obtained from the Host: header of the client
• %p
  Port, from the virtual server listening port
• %u
  URI path, as obtained from a GET/POST request

For example, the following command configures a pool to redirect an HTTP request from http://www.siterequest.com:8080/sample.html to https://www.siterequest.com:443/sample.html:

bigpipe pool my_pool fallback https://%h:443/%u

To indicate that the host name, port, and URI path remain unchanged, you would use the following command:

bigpipe pool my_pool fallback %h:%p/%u

Specifying a load balancing mode

The load balancing modes are specified as values of the attribute lb_mode. The lb_mode values are shown in Table A.6 .

For more information about the load balancing modes, see Chapter 4, Pools .

power

Allows the user to query for the status of two power supplies in a redundant power supply configuration. Failover from one power supply to the other occurs transparently to the user.

Options

The [show] option displays the status of the two power supplies, as follows:

b power [show]
top power supply: active
bottom power supply: down!

proxy

proxy

Creates, deletes, modifies, or displays the SSL or content converter proxy definitions on the BIG-IP system. For detailed information about setting up the SSL Accelerator feature, see the BIG-IP Solutions Guide, Chapter 11, Configuring an SSL Accelerator. For detailed information about setting up the content converter feature, see the BIG-IP Solutions Guide, Chapter 16, Configuring a Content Converter.

Options

The <clientssl> <enable | disable> option enables and disables the client-side SSL connection feature for the proxy being defined. If this option is omitted, the default is to have SSL enabled for all client-side connections.

The <clientssl key> <clientside key file name> option specifies a key file to be used as the private key corresponding to the clientside cert file specified by the <clientssl cert> option. This option is required when clientside SSL is enabled.

The <clientssl cert> <clientside cert file name> option specifies a certificate file to be used as the public key corresponding to the client-side key file specified by the <clientssl key> option. This certificate is used as a server certificate when the proxy authenticates itself to clients. This option is required when client-side SSL is enabled.

The <clientssl chain> <clientside chain file name> option specifies a chain file to be used to complete the certificate chain corresponding to the clientside cert file specified by the <clientssl cert> option. Certificates from this file are used as necessary to build up the certificate chain. This option is not required, even when client-side SSL is enabled.

The <clientssl ca file> <clientside CA file name> option specifies a CA file to be used primarily to authenticate client certificates, but also to complete the certificate chain corresponding to the client-side certificate file specified by the <clientssl cert> option. See also the <clientssl chain> option. The CA file may contain more than one certificate. This option is not required, even when client-side SSL is enabled.

The <clientssl ca path> <clientside CA path> option specifies a path to a directory with certificate files to be used primarily to authenticate client certificates, but also to complete the certificate chain corresponding to the clientside cert file specified by the <clientssl cert> option. See also the <clientssl chain> and <clientssl ca file> options. Unlike the <clientssl ca file> option, only the first certificate in certificate files with valid symbolic links generated by the <make> option will be examined (the Makefile in the /config/bigconfig/ssl.crt/ directory should be used). This option is not required, even when client-side SSL is enabled.

The <clientssl client cert ca> <clientside client cert CA file name> option specifies a CA file containing one or more certificates to be advertised to clients as those CAs trusted for client authentication. Note that this list of CAs has no effect on and can be completely different from those actually used to authenticate clients; see the <clientssl ca file> option. If this option is not specified, no list of trusted CAs will be advertised to clients, which may prevent some clients from connecting when client certificates are requested or required.

The <clientssl cipher insert> [<enable | disable>] option enables and disables the prepending of an HTTP header containing the negotiated client cipher information. This header takes the form of "SSLClientCipher: <cipher>, version=<SSL-protocol-version>, bits=<cipher-strength-bits>". If this option is omitted, the default is to have client cipher insertion disabled.

The options <clientssl client cert insert> ([versionnum] [serial] [sigalg] [issuer] [validity] [subject] [subpubkey] [x509ext] [whole] [hash])+ enable the prepending of HTTP headers containing the client certificate information.

The <clientssl sessionid insert> ([initial] [current])+ option enables the prepending of HTTP headers containing the initial and/or current SSL session ID. These headers take the form of "SSLClientSessionID: <InitialSessionID>" and "SSLClientCurrentSessionID: <CurrentSessionID>" respectively, where the <InitialSessionID> and <CurrentSessionID> options are the hexadecimal representation of the corresponding SSL session ID. If this option is omitted, the default is to have client session ID insertion disabled.

The <clientssl ciphers> <list> option uses the <list> option to determine the set of ciphers available for client-side SSL negotiation. See <http://www.openssl.org/docs/apps/ciphers.html> for the format of <list>.

The <clientssl invalid> [SSLv2] [SSLv3] [TLSv1] option specifies the SSL protocol versions that should not be used for client-side SSL negotiation.

If the <clientssl client cert> <request|require|ignore> option is set to request or require, all clients will be asked for a client certificate. If this option is omitted or set to ignore, the default is to disable requesting a client certificate. If this option is set to require, clients not presenting a valid and trusted client client certificate will not be permitted to establish a SSL connection. See also the <clientssl ca file> and <clientssl client cert ca> options.

If the <clientssl authenticate> <once|always> option is omitted or set to once, clients will be authenticated at most once for each SSL session. If this option is set to always, clients will be required to authenticate themselves (as directed by the <clientssl client cert> option) with each connection to the proxy.

The <clientssl authenticate depth> <num> option specifies the maximum number of certificates that will be traversed in a client certificate chain. If the certificate has not been verified in <num> steps, it will fail authentication. If this option is omitted, the default value is 9.

The <clientssl cache size> <num> option specifies the maximum number of entries in the client-side SSL session cache. If this option is omitted, the default value is 20000.

The <clientssl cache timeout> <num> option specifies the maximum lifetime of entries in the client-side SSL session cache in seconds. If this option is omitted, the default value is 300.

The <serverssl> <enable | disable> option enables and disables the server-side SSL connection feature for the proxy being defined. If this option is omitted, the default is to have SSL disabled for all server-side connections.

The <serverssl key> <serverside key file name> option specifies a key file to be used as the private key corresponding to the server-side certificate file specified by the <serverssl cert> option. This option is not required, even when server-side SSL is enabled.

The <serverssl cert> <serverside cert file name> option specifies a certificate file to be used as the public key corresponding to the server-side key file specified by the <serverssl key> option. This certificate will be used as a client certificate when the proxy is asked to authenticate itself to servers. This option is not required, even when server-side SSL is enabled.

The <serverssl chain> <serverside chain file name> option specifies a chain file to be used to complete the certificate chain corresponding to the server-side certificate file specified by the <serverssl cert> option Certificates from this file will be used as necessary to build up the certificate chain. This option is not required, even when server-side SSL is enabled.

The <serverssl ca file> <serverside CA file name> option specifies a CA file to be used primarily to authenticate server certificates, but also to complete the certificate chain corresponding to the server-side certificate file specified by the <serverssl cert> option. See also the <serverssl chain> option. The CA file may contain more than one certificate. This option is not required, even when server-side SSL is enabled.

The <serverssl ca path> <serverside CA path> option specifies a path to a directory with certificate files to be used primarily to authenticate server certificates, but also to complete the certificate chain corresponding to the server-side certificate file specified by the <serverssl cert> options. See also the <serverssl chain> and <serverssl ca file> options. Unlike the <serverssl ca file> option, only the first certificate in certificate files with valid symbolic links generated by the <make> option are examined (the Makefile in the /config/bigconfig/ssl.crt/ directory should be used). This option is not required, even when server-side SSL is enabled.

The <serverssl ciphers> <list> option determines the set of ciphers available for server-side SSL negotiation. See the file http://www.openssl.org/docs/apps/ciphers.html for the format of <list>.

The <serverssl invalid> [SSLv2] [SSLv3] [TLSv1] option specifies the SSL protocol versions that should not be used for server-side SSL negotiation.

The <serverssl server cert> <require|ignore> option determines whether server certificates will be verified. If this option is set to require, all server certificates will be verified. If this option is set to ignore, server authentication only fails when a server presents an expired or malformed certificate. If this option is omitted, the default is to require verified server certificates. See also the <serverssl ca file> option.

The <serverssl authenticate depth> <num> option specifies the maximum number of certificates that will be traversed in a server certificate chain. If the certificate has not been verified in <num> steps, it fails authentication. If this option is omitted, the default value is 9.

The <akamaize> <enable | disable> option enables Akamaization for the proxy being defined. If this option is omitted from the definition, then the default is to have Akamaization disabled.

The <header insert> <quoted string> option specifies a string to be prepended to the block of HTTP headers supplied with each client request. This string should take the standard HTTP header form of "<field>:<value>".

The <redirects rewrite> matching | all [enable] option enables the rewriting of HTTP 301, 302, 303, 305, or 307 redirects' Location field to "Location: https://...". When matching is specified, only a redirect with a URI in the Location field matching the URI requested by the client will be rewritten. When all is specified, redirects are rewritten whether or not the URIs match. The port number specified in the redirect is also rewritten when it does not match the port of the proxy.

The <lasthop pool> <none | lasthop pool name> option specifies a lasthop pool to be used for the proxy. If this option is omitted, the default is to have no lasthop pool.

The <arp> <enable | disable> option enables and disables the arp for this proxy address. If this option is omitted, the default is to have arp enabled.

The <vlans> <vlan name> [<vlan name>...] <enable|disable> option enables and disables proxy access on existing VLANs. A proxy is accessible on all VLANs by default.

Creating a proxy server

The following example creates an SSL proxy:

bigpipe proxy 10.2.3.1:https target virtual 12.2.3.1:http \
key my.key cert my.crt

In this example, the BIG-IP system creates an SSL proxy, along with the key my.key and the certificate my.crt. As shown in the syntax listed above, many options are available when creating an SSL proxy, such as the server-side SSL proxy option and features related to client authentication.

Deleting a proxy server

You can delete an existing proxy server, using the following command-line syntax:

bigpipe proxy <ip>:<service> delete

ratio

For the ratio load-balancing mode, this command sets the weight or proportions for one or more node addresses. For the priority load balancing mode, the command sets the priority level. Note that multiple node addresses can have the same priority level setting.

Options

The <node_ip> variable specifies an IP address of a specific node.

The <weight> variable specifies a whole number. The default weight for any node address is 1.

The show option displays the ratio weights for the specified node addresses.

Displaying ratio settings

To display the current ratio settings for all node address that have ratio settings, use the following command:

b ratio [show]

The following output is displayed:

192.168.200.51 ratio = 3

192.168.200.52 ratio = 1

To display the ratio settings for specific node addresses, use the following command-line syntax:

b ratio <node addr> ... <node addr> [show]

Modifying ratio settings

The following command sets the ratio to 3 for the node address specified:

b ratio 192.168.103.20 3

reset

Clears the configuration values and counter values from memory.

Warning

---

Use this command with caution. All network traffic stops when you run this command.

Typically, this command is used on a standby BIG-IP system prior to loading a new /config/bigip.conf file that contains new service enable and timeout values.

For example, you can execute the following commands on a standby BIG-IP systems:

b reset

b load <filename>

This sequence of commands ensures that only the values set in the <filename> specified are in use.

Note

---

This command does not delete any externally-stored classes. For information on how to delete externally-stored classes, see Chapter 5, iRules .

rule

Creates, deletes, or displays the rules on the BIG-IP system. Rules allow a virtual server to access any number of pools on the BIG-IP system. Based upon a simple or complex expression a pool can be selected through a rule. For more detailed information about using rules, see Chapter 5, iRules .

Note

---

Before you define a rule, you must define the pool or pools that you want the rule to reference.

Rule statements

The <rule_name> variable specifies the name of a rule.

The <pool_name> variable specifies the name of a pool to be associated with the specified rule.

The <if statement> variable asks a true or false question and, depending on the answer, takes some action.

A <discard statement> variable discards the request. This statement must be conditionally associated with an if statement.

A <use pool statement> variable uses a selected pool for load balancing. This statement must be conditionally associated with an if statement.

A <redirect statement> variable sends traffic to a specific destination, rather than to a pool for load balancing.

A <cache statement> variable uses a selected pool for load balancing. This statement can be conditionally associated with an if statement. For attributes that you can use within a cache statement, see Cache statement attributes .

A <log statement> variable logs a message to the Syslog facility. The statement does this by performing variable expansion on the message as defined for header_insert.

An <accumulate statement> variable terminates rules processing until another another packet containing additional data is received from the originating client. This statement is useful with the http_content and tcp_content rule variables, when not enough data has been received to be successfully evaluated.

Cache statement attributes

Figure A.7 shows the attributes that can be used as arguments within cache statements.

Functions

The iRules feature offers a set of functions that you can use within rule expressions. You can specify two kinds of functions within rules--functions that return a string, and functions that return a node name.

Functions that return a string

The following functions within expressions are used primarily to implement persistence within a pool. These functions therefore return a string that you specify. Table A.8 lists and describes these functions.

Functions that return a node name

The following functions within expressions are used to directly select a particular node (pool member) within a pool. Table A.9 lists and describes these functions.

Variable operands

Table A.10 lists the variable operands that can be used within rule statements. For more information, see Chapter 5, iRules .

Binary Operators

The binary operators that can be used within rule statements are as follows:

• or
• and
• contains
• matches
• equals
• starts_with
• ends_with
• matches_regex
• one of
• redirect to

Creating a rule

Rules are generally added to an existing bigip.conf file. Note that the rule body should not be enclosed with single quotes in the bigip.conf file. For example:

In this example, if the http_uri string ends with "cgi", then the members of pool cgi_pool are used. Otherwise, the members of pool another_pool are used.

If the rule is defined on the bigpipe command line, you can either surround each pair of parentheses in single quotation marks ('), or place a pair of single quotation marks around the braces. These two methods of defining a rule on the command line are shown as follows:

b rule <name> if '{ <if_stmt> | <use_stmt> | <discard_stmt> | <redirect_stmt> | <log_stmt> | <accumulate_stmt> | <cache_stmt> }'

Or, you can type the same rule using the following syntax:

b rule <name> if { '(<if_stmt>)' | '(<use_stmt>)' | '(<discard_stmt>)' | '(<redirect_stmt>)' | '(<log_stmt>}'| '(<accumulate_stmt>)' | '(<cache_stmt>)' }

For example:

b rule my_pool { if '(client_addr == 10.12.12.10)' { use pool '(pool_A80)' } }

b rule your_pool '{ if (client_addr == 10.12.12.10) { use pool (pool_B80) } }'

Associating a rule with virtual server

Associate a rule with a virtual server using the following format:

bigpipe virtual 10.20.2.101:http use rule cgi_rule

Deleting a rule

Delete a rule using the following format:

bigpipe rule cgi_rule delete

Displaying a rule

Display all rules using the following syntax:

bigpipe rule show

Or to display a specific rule:

bigpipe rule <rule name> show

save

Writes the current BIG-IP system configuration settings from memory to the configuration files named /config/bigip.conf and /config/bigip_base.conf. (config/bigip.conf stores high level configuration settings, such as pools, virtual servers, NATs, SNATs, and proxies. /config/bigip_base.conf stores low level configuration settings, like, VLANs, non-floating self IP addresses, and interface settings.)

You can type b save <filename>, or a hyphen character (-) in place of a file name, to display the configuration on the standard output device.

b [base] save -

If you are testing and integrating BIG-IP units into a network, you may want to use multiple test configuration files. Use the following syntax to write the current configuration to a file name that you specify:

b [base] save <filename>

For example, the following command saves the current configuration from memory to an alternate configuration file named /config/bigip.conf2.

b save /config/bigip.conf2

self

Defines a self IP address on a BIG-IP system or 3-DNS Controller. A self IP address is an IP address mapping to a VLAN or VLAN group and their associated interfaces on a BIG-IP system or 3-DNS Controller. A one true self IP address is assigned to each interface on the unit as part of first time boot configuration, and also a floating (shared) self IP address for units in a redundant system. Additional self IP addresses may be created for health checking, gateway failsafe, routing, or other purposes. These additional self IP addresses are created using the self command.

Options

The <ip_addr> variable specifies an IP address to assign to the BIG-IP system or 3-DNS Controller.

The vlan <vlan_name | vlangroup_name> option specifies the VLAN or VLAN group to which the self IP address is being assigned.

The netmask <ip mask> option specifies an IP mask used to set the network of the self IP address.

The broadcast <broadcast_addr> option specifies the broadcast address.

The unit <id>option specifies an optional unit ID, 1 or 2. The default value is 1.

The floating option enables or disables a floating self IP address.

The snat automap option enables or disables SNAT automapping on the specified self IP address. Once snat automap is enabled, the self IP address can be used as the translation address when SNAT automapping is enabled for a VLAN.

Creating self IP addresses

The following are examples of using the bigpipe self command to create self IP addresses:

b self 10.1.0.1 vlan external netmask 255.255.0.0

b self 10.2.0.1 vlan internal netmask 255.255.0.0

For a redundant configuration, the IP addresses that are shared by the two units are configured as floating IP addresses. For example:

b self 10.1.1.1 vlan external netmask 255.255.0.0 floating enable

b self 10.2.1.1 vlan internal netmask 255.255.0.0 floating enable

To create self IP addresses that are shared between the two units in an active-active configuration, assign a unit number to each self IP address, as in the following examples:

b self 10.1.1.1 vlan external netmask 255.255.0.0 unit 1\ floating enable

b self 10.1.1.2 vlan external netmask 255.255.0.0 unit 2\ floating enable

b self 10.2.1.1 vlan internal netmask 255.255.0.0 unit 1\ floating enable

b self 10.2.1.2 vlan internal netmask 255.255.0.0 unit 2\ floating enable

service

Enables and disables network traffic on services, and also sets connection limits and timeouts. An idle connection is one in which no data has been received or sent for the number of seconds specified by the service timeout command.

The default timeout value for tcp services is 1005, and 60 seconds for udp services. For idle connection reaping to be effective, you should set the timeout value to be greater than the configured timeout for the service daemons installed on your nodes.

You can use port numbers or service names (for example, www, http, or 80) for the <service> parameter. Note that the settings you define with this command control the service for all virtual servers that use it. By default, all services are disabled.

Options

The <service> variable specifies any valid port number, between 1 and 65535, inclusive, or any valid service name in the /etc/services file.

The <limit> variable specifies the maximum number of simultaneous connections to be allowed to the service for all virtual servers. To turn off a connection limit for a service, specify a value of 0.

The <seconds> variable specifies the number of seconds until a connection to the service times out.

snat

The snat command creates and deletes secure network address translation (SNATs), and displays information about them. A SNAT defines one or more addresses that nodes can use as a source IP address when initiating connections to hosts on the external network. Note that clients cannot use SNAT addresses to connect directly to nodes.

This command also allows you to set properties on a SNAT. A SNAT defines the relationship between an externally visible IP address, or translated address, and a group of internal IP addresses, or orginating address, of individual servers at your site.

Options

The <orig addr> variable specifies an originating IP address, that is, an address that is behind the BIG-IP system.

The <trans addr> variable specifies a translated IP address, that is, an address that is outside the BIG-IP system.

The <ip addr> variable can specify either an originating or a translated address.

The <vlan name> variable specifies the name of an existing VLAN on which access to the SNAT is enabled or disabled. By default, a SNAT is accessible on all VLANs.

The <id> variable specifies a unit ID, currently 1 or 2. The default unit ID value is 1.

The <limit> variable specifies a connection limit.

The <seconds> variable specifies the number of seconds for timeout.

The auto option enables SNAT automapping.

Defining a SNAT

SNATs map one or more originating addresses to a single translated address. Use the following syntax to define one or many orginating addresses to translated address maps:

b snat map <orig addr> [<orig addr>... ] to <trans addr>

For example, the following command maps a SNAT, which has two clients, to a single translated address:

b snat map 192.140.100.10 192.140.100.20 to 192.168.11.22

You can set the following properties on a SNAT:

• A connection limit (limit option)
• A tcp timeout value (timeout tcp option)
• A udp timeout value (timeout udp option)
• Connection mirroring (mirror option)
• ARP enable or disable
• A VLAN deny access list

Deleting SNAT

Use the following command-line syntax to permanently delete one or more SNATs from the BIG-IP system configuration:

b snat <ip addr>... <ip addr> delete

stp

The BIG-IP Application Switch provides Spanning Tree Protocol (STP) implementation for loop resolution in configurations where one or more external switches is connected in parallel with the BIG-IP system. This feature allows you to configure two or more interfaces on the platform as an STP domain. For interfaces in the STP domain, the spanning tree algorithm identifies the most efficient path between the network segments, and establishes the switch associated with that path as the root. Links forming redundant paths are shut down, to be re-activated only if the root fails.

The STP domain should contain all ports that are connected in parallel to an external switch where there are nodes on the link capable of generating or receiving traffic. You will want a second domain if there is an additional switch or switches connected in parallel with additional BIG-IP interfaces.

Options

The <stp_name> variable specifies an arbitrary name for the spanning tree protocol (STP) domain.

The <interface_name> variable specifies an interface name, for example, 3.1.

The show option displays the interfaces that make up the STP domain.

summary

Displays a summary of current usage statistics. The output display format for the summary command is shown in Figure A.7 . You can find detailed descriptions of each of statistic displayed by the summary command in Chapter 17, Administering the BIG-IP System .

For more information on the out put of the bigpipe summary command, see Chapter 17, Administering the BIG-IP System .

trunk

The trunk command aggregates links (individual physical interfaces) to form a trunk. This link aggregation increases the bandwidth of the individual NICs in an additive manner. Thus, four fast Ethernet links, if aggregated, create a single 400 Mb/s link. The other advantage of link aggregation is link failover. If one link in a trunk goes down, traffic is simply redistributed over the remaining links.

A trunk must have a controlling link and acquires all the attributes of that controlling link from Layer 2 and above. Thus, the trunk automatically acquires the VLAN membership of the controlling link but does not acquire its media type and speed. Outbound packets to the controlling link are load balanced across all of the known-good links in the trunk. Inbound packets from any link in the trunk are treated as if they came from the controlling link.

A maximum of eight links may be aggregated. For optimal performance, links should be aggregated in powers of two. Thus, ideally, you will aggregate two, four, or eight links. Gigabit and fast ethernet links cannot be placed in the same trunk.

For more information on interface naming, see Chapter 3, Post-Setup Tasks .

Options

The <controlling link> variable specifies the name of the interface chosen to be the controlling link for the trunk. Any attributes of the controlling link at layer 2 and above, such as membership in a VLAN, apply to the trunk.

The <link> variable specifies an interface name, for example 3.1.

The show option displays information and statistics for the trunk, on a single line.

The <verbose> option, used with the show option, displays the information and statistics for the trunk in wordier form.

The delete option deletes the specified interface.

unit

The unit number on a system designates which virtual servers use a particular unit in an active-active redundant configuration. You can use the bigpipe unit command to display the unit number assigned to a particular BIG-IP system. For example, to display the unit number of the unit you are on, type the following command:

b unit show

To display the unit number of the other unit in a redundant system, type in the following command:

b unit peer show

Note

---

If you use this command on a redundant system in active/standby mode, the active unit shows as unit 1 and 2, and the standby unit has no unit numbers.

Tip

---

The bigpipe unit peer show command is the best way to determine whether the respective state mirroring mechanisms are connected.

verbose

Used to modify the verbose log level. This command is an alternative to using the bigpipe global verbose_log_level command.

Table A.11 compares use of the bigpipe verbose command to use of the bigpipe global verbose_log_level command.

verify

Parses the command line and checks syntax without executing the specified command. This distinguishes between valid and invalid commands

Use the verify command followed by a command that you want to validate:

b verify virtual 10.10.10.100:80 use pool my_pool

The command checks the syntax and logic, reporting any errors that would be encountered if the command executed.

Use the verify command together with the load <filename> command to validate the specified configuration file. For example, to check the syntax of the configuration file /config/altbigpipe.conf, use the following command:

b verify load /config/altbigip.conf

version

Displays the version of the BIG-IP operating system and the features enabled.

For example, for a BIG-IP HA system, the bigpipe version command displays the output shown in Figure A.8

.

virtual

Creates and deletes virtual servers, and displays information about them. This command also allows you to set properties on a virtual server, such as connection mirroring, connection limits, and timeouts.

A virtual server defines the relationships between an externally visible IP address that clients use to connect to your site, and the internal IP addresses of individual member servers that actually provide services for your site.

Options

The <virtual addr> variable specifies the IP address of the virtual server.

The <virtual port> variable specifies a port number or service name.

The <bitmask> variable specifies a number representing the bits that are the network part. of the virtual IP address.

The <vlan name> variable specifies the name of an existing VLAN for which you want to enable or disable access. By default, a virtual server is accessible on all VLANs.

The <id> variable specifies a unit id, currently 1 or 2. The default value for the unit ID is 1.

The <ip addr> variable specifies the IP address, of the form 10.20.30.40.

The use pool <pool name> option specifies the name of an existing server pool.

The <rule name> variable specifies the name of an existing rule that the virtual server should reference.

The translate port option enables, disables, or shows port translation for a virtual server.

The svcdown_reset option enables, disables, or shows the ability of the BIG-IP system to automatically reset connections when a service becomes unavailable.

The translate addr option enables, disables, or shows address translation for a virtual server.

The lasthop pool option allows you to specify a pool to which to send connections back, instead of using the same router from which the connection was received.

The mirror conn option enables, disables, or shows the mirroring of connections in active/standby configurations.

The conn rebind option enables, disables, or shows dynamic connection rebinding.

The stats reset opton resets statistics for a virtual server.

The accelerate option enables, disables, or shows FastFlow acceleration, that is, increased speed of packet flow for TCP connections when the packets are not fragmented.

The arp option causes the BIG-IP system to respond to ARP requests for the virtual server address and send a gratuitous ARP request for router table updates.

The any_ip option allows you to configure a virtual server to load balance IP traffic other than TCP and UDP traffic, such as IPSEC traffic.

Defining a virtual server using pools and rules

To associate a pool of members with a virtual server, use a command such as the following:

b virtual 10.20.2.102:http use pool cgi_pool

To associate a rule with a virtual server, use a command such as the following:

b virtual 10.20.2.102:http use rule cgi_rule

Defining a virtual server with a wildcard port

Use the following command-line syntax to define an individual virtual server and the node or nodes to which the virtual server maps. Note that this syntax allows wildcard ports:

b virtual <virt addr> use pool <pool name> | rule <rule name>

You can also create multiple wildcard servers, one per VLAN. To create a wildcard server for a VLAN, use the following syntax:

bigpipe virtual <vlan_name> use pool <pool_name>

Deleting a virtual server

Use the following command-line syntax to permanently delete one or more virtual servers from the BIG-IP system configuration:

b virtual <virt addr>:<port>... <virt addr>:<port> delete

vlan

This command creates, displays and modifies settings for VLANs. VLANs are part of the base configuration.

When creating a VLAN, a tag value (VLAN ID) for the VLAN is automatically chosen unless it is specified on the command line. If a tag is specified on the command line and that tag number is 0, the vlan command creates an empty VLAN.

A VLAN can have both tagged and untagged interfaces. An interface can be added to a single VLAN as an untagged interface. Also, an interface can be added to multiple VLANs as a tagged interface.

The vlan command defines VLANs, VLAN mappings, and VLAN properties. By default, each interface on a BIG-IP system or 3-DNS Controller is an untagged member of a VLAN. The lowest-numbered interface is assigned to the external VLAN, the interface on the main board is assigned to the admin VLAN, and all other interfaces are assigned to the internal VLAN.

Options

The <vlan name> variable specifies a VLAN name, 1-15 characters in length.

The tag <tag number> option specifies a valid VLAN tag number, in the range 0-4095. Note that if 0 is specified as the tag number, the vlan command creates an empty VLAN.

The interfaces add [tagged] option specifies that the interfaces specified with the <if_list> argument are to be added to the specified VLAN, as either tagged or untagged interfaces.

The interfaces delete option deletes all interfaces for the specified VLAN.

The <if_list> variable specifies a list of interfaces to be added to a VLAN.

The interfaces show all option shows all interfaces for the specified VLAN.

The port_lockdown option enables or disables connection to the BIG-IP system through the specified VLAN.

The proxy_forward option enables or disables proxy forwarding, for purposes of L2 forwarding.

The failsafe option allows you to arm, disarm, or show the failsafe mechanism for redundant systems.

The timeout <timeout> option specifies a timeout value for the failsafe mechanism.

The snat automap option enables SNAT automapping for the specified VLAN.

The rename <new_vlan_name> option specifies the name to which you want to rename the specified VLAN.

The <if_name> variable specifies an interface name.

The mac_masq <MAC address> option specifies a MAC address, such as 0:a0:be:ef:1f:3a, that will be shared by both BIG-IP units in a redundant system.

The l2_agingtime <seconds> option specifies the value in seconds of L2 forwarding time.

The fdb option adds the specified interfaces as entries in the L2 forwarding table.

The port_lockdown option enables or disables connection to the BIG-IP system through the specified VLAN.

vlangroup

The vlangroup command defines a VLAN group, which is a grouping of two or more VLANs belonging to the same IP network for the purpose of allowing L2 packet forwarding between those VLANs.

The VLANs between which the packets are to be passed must be on the same IP network, and they must be grouped using the vlangroup command. For example:

b vlangroup network11 { vlans add internal external }

A self IP address must be assigned to the VLAN group using the following command:

b self <ip_addr> vlan network11

L2 forwarding must be enabled for the VLAN group using the VLAN proxy_forward attribute. This attribute is enabled by default when the VLAN group is enabled.

Options

For a description of the bigpipe vlangroup command options, see Options .

---