Manual Chapter : BIG-IP Administrator guide v2.1: System Utilities

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 2.1.4 PTF-01, 2.1.4, 2.1.3 PTF-04, 2.1.3 PTF-03, 2.1.3 PTF-02, 2.1.3 PTF-01, 2.1.3, 2.1.2 PTF-02, 2.1.2 PTF-01, 2.1.2, 2.1.1, 2.1.0
Manual Chapter


System Utilities


sod [-help] [-v] [-tty00] [-tty01] \
[-force_slave|-force_master][-print_state_time <interval>]

SOD Option Description
-help Prints this message.
-v Version information.
-tty00 Use tty0 for failover monitoring.
-tty01 Use tty1 for failover monitoring.
-force_slave Sod prefers slave state when other sod is live and set to force master.
-force_master Sod prefers master state when other sod is live and set to force slave.
-print_state_time <value> Slave prints the state of the serial lines at the specified interval.


The switch-over daemon (sod) controls functions the BIG/ip Controller fail-over functions. It has a command line interface for some functions.

Command line usage

The sod daemon is used as a command line utility for some of its functions.

To display the online help for sod:

sod -help

To display the sod version number:

sod -v

From the standby BIG/ip Controller, you can monitor and display the state of the active controller:

sod -print_state_time <seconds>

The seconds parameter specifies the interval in seconds for the serial line check to the active controller.

Daemon start up options

The sod daemon is configured in /etc/rc.local. You can configure the sod daemon in two ways:

  • Serial port(s) used for hardware fail-over cable connections
  • Forced fail-over role (active or standby) at boot

Note: Every time you change your sod daemon configuration, you need to reboot the BIG/ip Controller.

Note: In the examples in this section, sod starts the bigd daemon after sod startup completes, as has been the default configuration since BIG/ip version 1.8.2. This startup order is optimal, avoiding the possibility of creating certain suboptimal conditions at boot. For more information, see the F5 Labs Technical Note titled "Startup Sequence for Large Numbers of Nodes."

Fail-over cable port configuration in sod startup

The sod daemon startup line in /etc/rc.local accepts two optional parameters: -tty00 and -tty01. These parameters specify which of the two 9-pin serial ports (one of them may be a 25-pin serial port on older BIG/ip Controller models) is used as the fail-over cable connection. The default is -tty01. Use one (or none) of the -ttyxx options to configure a single fail-over cable. Use both options to configure two cables (redundant fail-over cables), as in the following example:

echo " sod (and bigd)."; /sbin/sod -tty00 -tty01 -- /
bigd ${bigdflags} 2> /dev/null

References to these fail-over cable connection ports in the sod startup line in /etc/rc.local are always made using the UNIX device name, while the hardware and BIOS settings for the ports use COM and serial port designations respectively.

9-pin serial port designations in BIOS, hardware, and UNIX operating system.
Port 2 (2f8 irq 3) COM2 /dev/tty01
Port 1 (3f8 irq 4) COM1 /dev/tty00

Note: The 9-pin serial port labeled "Terminal" is COM2.

Setting -forced_master and -forced_slave in sod startup

At boot, a BIG/ip Controller becomes the standby controller if an active controller is detected.

You can modify this behavior by setting the option -force_ slave or -force_master in the sod startup line in /etc/rc.local. In the following example, start sod on one BIG/ip Controller with the -force_slave option and sod on the other controller with the -force_master option to force one of the BIG/ip Controllers to become active at boot time.

  1. Determine which BIG/ip Controller you want to be the active controller.
  2. In a text editor, such as vi or pico, open the /etc/rc.local file on that BIG/ip controller .
    (The editors pico and vi are provided with BIG/ip.)
  3. Find the line in /etc/rc.local that starts the sod daemon.
    For example:

echo " sod (and bigd)."; /sbin/sod -- bigd ${bigdflags} /
2> /dev/null

  1. Add the -force_master command line argument.
    In this case, it should now say:

echo " sod (and bigd)."; /sbin/sod -force_master -- bigd /
${bigdflags} 2> /dev/null

Now set the other BIG/ip Controller to boot as standby. Follow the same procedure to edit the /etc/rc.local file on the standby controller, adding the -force_slave option to the sod startup line. For example, to edit the default line that starts sod on the controller you want to boot as standby:

echo " sod (and bigd)."; /sbin/sod -- bigd ${bigdflags} /
2> /dev/null

by adding the -force_slave option:

echo " sod (and bigd)."; /sbin/sod -force_slave -- bigd /
${bigdflags} 2> /dev/null

Reboot both BIG/ip controllers to start sod with the new configuration.


bigd [-d filename] [-n] [-s] [-v] [-V]


This daemon monitors services and nodes for the BIG/ip Controller. The bigd daemon provides service check functions for simple (node ping), extended content verification, and extended application verification service checks. Usage is supported for cases where the check port for a node is not the same as the node port.

Option Description
-d filename Check syntax of the specified configuration file, and then exit. This option cannot be used in conjunction with any other option.
-n Do not ping nodes.
-s TCP node ping (default is ICMP)
-v Print version number.
-V Print verbose output to message logs.







Configuring bigd

File Description
/etc/rc.local Starts bigd with the options specified.
/etc/bigip.conf Contains configuration information for timeout_svc and tping_svc.
/etc/bigd.conf Contains configuratoin information for ECV and EAV service checks.

Figure D.1 bigd configuration files.

Starting bigd

The standard way to start bigd is by configuring the sod startup line in /etc/rc.local :

echo " sod (and bigd)."; /sbin/sod -- bigd ${bigdflags} /
2> /dev/null

This syntax starts bigd after the boot configuration in /etc/bigip.conf has been loaded and started. This is the optimal sequence for startup if you use ping aliases. If bigd is started before sod when ping aliases are defined, node pinging starts before ping aliases have been loaded.

You can also start and restart bigd on the command line with options:


This is the best way to restart bigd if you make changes to the /etc/bigd.conf file. This method stops any existing bigd processes and restarts the daemon using the configuration in /etc/rc.local and /etc/bigd.conf.

Setting the node ping parameters used by bigd

Node ping uses the timeout_node and tping_node parameters (set in /etc/bigip.conf) to set the length of time between pings and the length of time to wait for a ping response before timeout.

Setting service check parameters used by bigd

Simple and extended service checks use the timeout_svc and tping_svc parameters (set in /etc/bigip.conf) to set the length of time between checks and the length of time to wait for a check response before timeout.

Extended service checks also use data from the /etc/bigd.conf file. There are seven ways to use Extended Content Verification and Extended Application Verification to check status. The different checks are listed in Table

Keywords in /etc/bigd.conf
Keyword in bigd.conf Usage
ssl ECV
active ECV, ECV on nodes w/wildcard ports
reverse ECV fails check if string is found
external EAV
gateway router ping
transparent transparent node mode
simple wildcard ports simple check

Service checking for wildcard servers and ports

The simple keyword is necessary to perform simple service checks on nodes with wildcard ports. Use the following syntax to set a check on a node where the check port is not the node port:

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

For example, if a wildcard server is defined with a non-wildcard port

bigpipe vip define n1:0

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

simple n1:0 80

Use the following variation on the active keyword syntax to configure ECV on nodes with wildcard ports:

active <node addr>:0 <check port> [<send string> [<regexp>]]

This syntax is only allowed when the node port is 0. When the node port is 0, this is the only syntax that is allowed.

To support EAV on nodes with wildcard ports, an additional variation on the "external" command in the /etc/bigd.conf file is added:

external <node addr>:0 <check port> [<program name> [<arguments>]]

This syntax is only allowed when the node port is 0. When the node port is 0, this is the only syntax that is allowed.

When this syntax is used, the calling convention for the external pinger is changed to:

<program name> <node addr> <check port> <arguments>

Service checking through transparent nodes

The /etc/bigd.conf file supports ECV for transparent nodes. This is done by checking a destination through the particular transparent node you want to check.

The following syntax is supported in the /etc/bigd.conf file for ECV through a transparent node:

transparent <node_ip>:<port> <site_ip>:<port> [<send_string> [<recv_expr>]]

The bigdnode program uses this syntax to make the appropriate socket option settings for the ECV check.

The following example shows how to set up an ECV check through a transparent node. The following virtual servers are defined for this example:

bigpipe vip define p1:80 p2:80

bigpipe vip define fw1:0 fw2:0

Configure the /etc/bigd.conf as shown:

transparent p1:80 'GET /' 'Yahoo'

transparent p2:80 'GET /' 'Yahoo'

transparent fw1:0 'GET /' 'Yahoo'

transparent fw2:0 'GET /' 'Yahoo'

Tip: Note that Wildcard Ports in virtual server definitions no longer require a defined service check port with the node if you do not want port translation. Instead, '0' is used to indicate that port translation should not take place.

In this example, node p1:80 is tested by getting the web page The web request is routed through p1. The transparent node fw2:0 is tested by getting the same web page (still on port 80), routed through fw1.


The big3d daemon answers 3DNS Controller system queries. 3DNS uses big3d to collect information about the network path between the BIG/ip Controller and the client requesting a connection. The big3d utilities calculate performance data, and return the data to the requesting 3DNS Controller. The 3DNS Controller uses the path information for its own dynamic load balancing.

You can start or stop the big3d process without affecting any other processes on the BIG/ip Controller.

If you no longer want to run the big3d process on the BIG/ip Controller, stop the process and remove the corresponding start line from /etc/rc.local. The only reason you might want to do this is if your installation once used 3DNS but no longer uses it.

Warning: When the big3d daemon on the BIG/ip Controller is stopped, the 3DNS Controller can no longer provide dynamic load balancing for the virtual servers that run on the BIG/ip Controller. This may affect pool definitions on the 3DNS Controller.

big3d hardware and software compatibility

The version of the big3d daemon, the BIG/ip Controller, and the 3DNS Controller that sends requests to it must be compatible. Any time you upgrade the BIG/ip Controller or the 3DNS Controller, check to make sure the versions of big3d are compatible.

Installing big3d

Run the big3d install script on the 3DNS Controller to install the correct version of big3d on the BIG/ip Controller, and add the auto start info to the BIG/ip Controller /etc/rc.local file. This sets up the proper fail-over configuration, so that if the BIG/ip Controller is rebooted or fails over, big3d starts automatically on the standby BIG/ip Controller.

Services and port configurations

Communication between the 3DNS Controller and big3d daemon on the BIG/ip Controller depends on the proper management of specific ports.

Outbound iQuery requests

The port used by the iQuery protocol to pass queries and results between the 3DNS Controller and big3d is now registered with the IANA as port 4353.

In previous versions of the BIG/ip Controller, outbound iQuery traffic service used port 245. Current releases of BIG/ip and 3DNS Controller software enable both of these ports by default, and the big3d daemon on the BIP/ip Controller detect iQuery requests on either port.

Firewall ports

The firewall ports 245 and/or 4353 ports must allow traffic between the BIG/ip Controller and the 3DNS Controller.

Warning: Firewalls between the 3DNS and BIG/ip Controllers must allow traffic on one or both of these ports. If the firewall rejects iQuery traffic, then 3DNS cannot provide dynamic load balancing for the virtual servers that run on the BIG/ip Controller, which may affect pool definitions on the 3DNS.