You can use advanced service check options to verify that your content servers are functioning properly. There are two types of advanced service checks: Extended Content Verification (ECV) and Extended Application Verification (EAV). This section describes how to set up, and use, these types of service checking. This section also includes information for setting up EAV service checks for SQL based services.
In addition to verifying content on web servers, you can use Extended Content Verification (ECV) service checks to verify connections to mail servers and FTP servers through transparent nodes. If you want to set up ECV service checks through a transparent node to these types of servers, there are certain special issues that you need to address.
You can set up ECV to verify that a transparent node is functioning properly. To check if a transparent node is functioning, you can add an entry to the /etc/bigd.conf file that allows you to retrieve content through the transparent node.
You can use a text editor, such as vi or pico, to manually create the /etc/bigd.conf file, which stores ECV information. To create the entry for checking a transparent node, use the following syntax:
transparent <node ip>:<node port> <url> ["recv_expr"]
You can also use the following syntax for this entry:
transparent <node ip>:<node port> <dest ip>:<dest port>/<path>
For example, if you want to run a service check through the transparent firewall 10.10.10.101:80 to the node 10.10.10.53:80, the entry might look like this:
transparent 10.10.10.101:80 10.10.10.53:80/www/forms/survey.html
For more information about these configuration entries, please refer to Table 5.1.
|The transparent keyword is required at the beginning of the entry.|
|The IP address, in dotted decimal notation, of the transparent firewall or proxy. This IP cannot be a wild card IP (0.0.0.0). Note that the node must be defined as a node in a virtual server definition. Typically this would be a wild card virtual server (0.0.0.0). This entry can also be specified as a fully qualified domain name (FQDN). In order to use an FQDN, the BIG/ip Controller must be configured for name resolution.|
|This entry is the node port to use for the ECV check. This port can be zero. This entry can be numeric or can use a well-known service name, such as http.|
dest ip:dest port
|This is the combination of the destination, in dotted decimal notation, and port number of the destination against which the ECV service check is performed. The IP address cannot be a wild card (0.0.0.0). The port number is optional. The port can be specified as any non-zero numeric port number, or specified as a well-known port name, such as http.|
|The URL is an optional standard HTTP URL. If you do not specify a URL, a default URL is retrieved using the HTTP 1.0 request format. This entry can also be specified using a complete URL with an embedded FQDN. This entry cannot be longer than 4096 bytes. In order to resolve an FQDN, the BIG/ip Controller must be configured for name resolution.|
|This string is optional. If you specify a string, the string you specify is used to perform standard ECV verification. This entry must be enclosed in quotation marks, and cannot be longer than 128 bytes.|
Note: The /etc/bigd.conf file is read once at startup. If you change the file on the command line, you must reboot or restart bigd for the changes to take effect. If you make changes in the F5 Configuration utility, clicking the apply button makes changes and restarts bigd. See the BIG/ip Controller Reference Guide, System Utilities, for details.
New ECV syntax facilitates using ECV with transparent nodes. With it, you can test whether a transparent node is functioning properly by retrieving content through it. You can enable this feature in the F5 Configuration utility or from the command line. This section describes how to enable this feature from the F5 Configuration utility.
There are two procedures required to set up ECV through a transparent node. First, set up the frequency and timeout for the port:
After you configure the frequency and timeout settings for the port, set the specific settings for the transparent node:
Extended Application Verification (EAV) is a sophisticated type of service check typically used to confirm whether an application running on a node is responsive to client requests. To determine whether a node application is responsive, the BIG/ip Controller uses a custom program referred to as an external service checker. An external service checker program essentially provides the option to customize service check functionality for the BIG/ip Controller. It is external to the BIG/ip system itself, and is usually developed by the customer. However, the BIG/ip Controller ships with several external service check programs. These include service check programs for FTP, POP3, SMTP, NNTP, and SQL.
You can use an external service checker to verify Internet or intranet applications, such as a web application that retrieves data from a back-end database and displays the data in an HTML page.
An external service checker program works in conjunction with the bigd daemon, which verifies node status using node pings and service checks. If you configure external service check on a specific node, the bigd daemon checks the node by executing the external service checker program. Once the external service checker executes, the bigd daemon looks for output written by the external service checker. If the bigd daemon finds output from the external service checker, it marks the node up. If it does not find output from the external service checker, it marks the node down. Note that bigd does not actually interpret output from the external service checker; it simply verifies that the external service checker created output.
An Extended Application Verification service check is a service check that is performed on an application running on a host on the network connected to the BIG/ip Controller. You can create a custom application for this purpose. Complete the following four tasks to implement a custom EAV service check program on the BIG/ip Controller:
Extended Application Verification (EAV) is intended to provide maximum flexibility. The external service checker programs that you create can use any number of methods to determine whether or not a service or an application on a node is responsive. The external service checker must, however, meet the following minimum requirements:
The BIG/ip Controller includes a several sample external service checker scripts for HTTP, NNTP, SMTP, and POP3. These scripts can be found in the following location:
The sample service checker, shown in Figure 5.1, is included with the BIG/ip Controller.
# these arguments supplied automatically for all external pingers:
# $1 = IP (nnn.nnn.nnn.nnn notation or hostname)
# $2 = port (decimal, host byte order)
# $3 and higher = additional arguments
# In this sample script, $3 is the regular expression
if [ -f $pidfile ]
kill -9 `cat $pidfile` > /dev/null 2>&1
echo "___FCKpd___4quot; > $pidfile
echo "GET /" | /usr/local/lib/pingers/nc $1 $2 2> /dev/null | \ grep -E -i $3 > /dev/null
if [ $status -eq 0 ]
rm -f $pidfile
To install an EAV service check script, place it in the /usr/local/lib/pingers directory. This is the default location for external service checker applications. You can install external service checker applications to other directory locations if desired.
Once you install an external service checker on the BIG/ip Controller, you need to add an entry to the /etc/bigd.conf file.
To allow external service checking, you need to add the following entry to the /etc/bigd.conf file:
external [<node_ip>:]<port> [<path>]<pinger_name> \
The <path> variable can be an absolute or a relative path to the external checker application. Absolute paths should begin with a slash ("/"). Other paths are relative to the directory default directory, /usr/local/lib/pingers. The <pinger_name> argument is the name of the pinger script to use for service checking.
The "<argument_string>" variable must consist of exactly one string in quotation marks. The string may include any number of arguments, delimited in the usual way by white space, for example:
external n1:8000 my_pinger "-a 600 -b"
In the above example, the BIG/ip Controller uses HTTP to check port 80, but runs the script /usr/local/lib/pingers/my_pinger to check port 8000, with additional arguments.
In the following example, there are three nodes on which the BIG/ip Controller checks port 8000. The BIG/ip Controller runs a separate copy of the external service checker named my_pinger for each node:
external n1:8000 my_pinger "-a -b"
external 8000 my_pinger "-b"
In this example, the first entry specifies how to ping port 8000 on node n1. The second entry specifies how to ping port 8000 on any other node.
The BIG/ip Controller performs the external service check at specified intervals. The BIG/ip Controller actually uses the service ping interval, which is set using the bigpipe tping_svc command.
The external service checker runs as root. The BIG/ip Controller starts an external service checker using the following shell command:
<path> <node_ip> <port> [ <additional_argument> ... ]
For the case of the example shown above, the appropriate command would be:
/usr/local/lib/pingers/my_pinger n1 8000 -a 600 -b
The BIG/ip Controller inserts the node IP and port number before the additional arguments that are specified in the /etc/bigd.conf file.
Note that the standard input and output of an external service checker are connected to bigdnode. The bigdnode does not write anything to the external service checker's standard input, but it does read the external service checker's standard output. If bigdnode is able to read any data from the external service checker program, the particular service is considered up.
The BIG/ip Controller includes a several sample external service checker scripts for HTTP, NNTP, SMTP, POP3, and SQL. These scripts can be found in this location:
The following sections describe how to set up each of these service checkers.
This section describes how to set up the BIG/ip Controller to perform EAV service checks on FTP services.
The FTP pinger requires three arguments: a full path to the file on any given server, a user name, and a password. Here are example bigd.conf entries:
external 10.0.0.57:21 /usr/local/lib/pingers/FTP_pinger
"/pub/demo/file.txt anonymous firstname.lastname@example.org"
external 10.0.0.62:21 /usr/local/lib/pingers/FTP_pinger
"/pub/spool/incoming.doc carol carols_password"
The FTP pinger attempts to download the specified file to the /var/tmp directory. A successful retrieval of any file with the name indicated is considered a successful ping.
This section describes how to set up the BIG/ip Controller to perform EAV service checks on POP3 services.
The POP3_pinger for Post Office Protocol requires only two arguments, a user name and a password. This check is considered successful if it successfully connects to the server, logs in as the indicated user, and logs out again. Here are example bigd.conf entries:
external 10.0.0.57:109 /usr/local/lib/pingers/POP3_pinger "alice
external 10.0.0.57:109 /usr/local/lib/pingers/POP3_pinger "bob
This section describes how to set up the BIG/ip Controller to perform EAV service checks on SMTP services.
The SMTP_pinger for mail transport servers requires only one argument, a string identifying the server from which the EAV is originating. This is an extremely simple pinger that checks only that the server is up and responding to commands. It counts a success if the mail server it is connecting to responds to the standard SMTP HELO and QUIT commands. Here is an example bigd.conf entry:
external 10.0.0.57:25 /usr/local/lib/pingers/SMTP_pinger
This section describes how to set up the BIG/ip Controller to perform EAV service checks on NNTP services.
The NNTP_pinger for Usenet News requires only one argument, a newsgroup name to check for presence. If the NNTP server being queried requires authentication, the user name and password can be provided as additional arguments. This pinger counts a success if it successfully retrieves a newsgroup identification line from the server. Here are example bigd.conf entries, the second showing the optional login parameters:
external 10.0.0.57:119 /usr/local/lib/pingers/NNTP_pinger
external 10.0.0.62:119 /usr/local/lib/pingers/NNTP_pinger
"local.chat username password"
local.chat username password
This section describes how to set up the BIG/ip Controller to perform EAV service checks on SQL-based services such as Microsoft SQL Server versions 6.5 and 7.0, and also Sybase.
The service checking is accomplished by performing an SQL login to the service. If the login succeeds, the service is considered up, and if it fails, the service is considered down. An executable program, tdslogin performs the actual login.
./tdslogin 192.168.1.1 1433 mydata user1 mypass1
Replace the IP address, port, database, user, and password in this example with your own information.
You should receive the message:
If you receive the connection refused message, verify that the IP and port are correct. See the Troubleshooting SQL based EAV service checks section for more tips.
external 192.168.1.1:1433 "/usr/local/lib/pingers/SQL_pinger" "mydata user1 mypass1"
In this entry, mydata is the name of the database, user1 is the login name, and mypass1 is the password.
tping_svc 1433 5
timeout_svc 1433 15
bigpipe -f /etc/bigip.conf
Correct the password and restart bigd and the service should go up again.
If you are having trouble, you should verify that you can login using another tool. For example, if you have Microsoft NT SQL Server version 6.5, there is a client program ISQL/w included with the SQL software. This client program performs simple logins to SQL servers. Use this program to test whether you can login using the ISQL/w program before attempting logins from the BIG/ip Controller.
On the SQL Server, you can run the SQL Enterprise Manager to add logins. When first entering the SQL Enterprise Manager, you may be prompted for the SQL server to manage.
You can register servers by entering the machine name, user name, and password. If these names are correct, the server will be registered and you will be able to click on an icon for the server. When you expand the subtree for the server, there will be an icon for Logins.
Underneath this subtree, you can find the SQL logins. Here, you can change passwords or add new logins by right-clicking on the Logins icon. Click this icon to open an option to Add login. After you open this option, enter the user name and password for the new login, as well as which databases the login is allowed to access. You must grant the test account access to the database you specify in the EAV configuration.