Applies To:

Show Versions Show Versions

Archived Manual Chapter: BIG-IP Reference guide v3.1: System Utilities
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.



6

System Utilities



sod

  sod [-help] [-tty00] [-tty01]

SOD Option Description
-help Prints help text.
-tty00 Use tty0 for fail-over monitoring.
-tty01 Use tty1 for fail-over monitoring.

Description

The switch-over daemon (sod) controls 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

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

BIOS COM UNIX
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.



bigd

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

Description

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. Table 6.2 contains the options available for bigd.

The bigd options

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.

Files

/etc/bigip.conf

/etc/rc.local

/etc/bigd.conf

/var/log/bigd

/var/log/messages

Configuring bigd

The configuration files in Table 6.3 contain configuration information for bigd.

bigd configuration files

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 configuration information for ECV and EAV service checks.

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:

  bigd

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

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 0.0.0.0:0 define n1:0

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 0.0.0.0:80 define p1:80 p2:80
  bigpipe vip 0.0.0.0:0  define fw1:0 fw2:0

Configure the /etc/bigd.conf as shown:

  transparent p1:80 www.yahoo.com:80 'GET /' 'Yahoo'
  transparent p2:80 www.yahoo.com:80 'GET /' 'Yahoo'
  transparent fw1:0 www.yahoo.com:80 'GET /' 'Yahoo'
  transparent fw2:0 www.yahoo.com:80 '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 http://www.yahoo.com/. 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.



big3d

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 agent 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 BIG/ip Controller detects iQuery requests on either port.

Firewall ports

The firewall ports 245 and/or 4353 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.

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)