5

Working with Advanced Service Check Options

Introducing advanced service check options

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.

Setting up ECV service checks for transparent nodes

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.

Note: For information about setting up standard ECV service checks, see the BIG/ip Controller Getting Started Guide, Configuring Extended Content Verification service checking.

Configuring ECV for transparent nodes

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> 
["recv_expr"]

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 
"Company Survey"

For more information about these configuration entries, please refer to Table 5.1.

Extended content verification configuration entries.

Configuration Entry	Description
transparent	The transparent keyword is required at the beginning of the entry.
node ip	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.
node port	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.
url	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.
recv string	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.

Setting up ECV through transparent nodes with the F5 Configuration utility

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.

Note: You must have at least one wildcard virtual server configured in order to configure ECV through a transparent node.

To set up ECV through a transparent node using 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:

1. In the navigation pane, click plus sign (+) next to Nodes.
   The navigation tree expands to display Ports.
2. In the navigation pane, click Ports.
   The Global Node Port properties screen opens.
3. In the Port list, click the port you want to configure.
   The properties screen for the port opens.
4. In the Frequency (seconds) box, type in the interval (in seconds) at which the BIG/ip Controller performs a service check on the node.
5. In the Timeout (seconds) box, type in the time limit (in seconds) that a node has to respond to a service check issued by the BIG/ip Controller.
6. Click the Apply button.

   After you configure the frequency and timeout settings for the port, set the specific settings for the transparent node:

7. In the navigation pane, click Nodes.
   The Node Properties screen opens.
8. In the Node list, click the node you want to configure.
   The Node Properties screen opens.
9. In the Service Check Extended section, click the ECV button to enable ECV.
10. In the Type list, select Transparent.
    By default, the list is set to Transparent.
11. In the Dest-IP:Dest-Port/url box, you must type the destination IP address of the node you are checking on the other side of the transparent device. The port number/port name argument is optional. The URL entry is also optional. For more information about what to type in this box, see Table 5.1.
12. In the Receive String (optional) box, you can type an ECV check receive string. The receive string is optional.
13. Click the Apply button.

Introducing EAV service checks

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.

Note: Custom external service checker programs are custom programs that are developed either by the customer, or by the customer in conjunction with F5 Networks.

Warning: Active checks that look for a receive string only accept 5000 bytes from the server before assuming that the receive string is not in the content.

Setting up custom EAV service checks

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:

• If you use a custom EAV service check program, verify that your external service checker program meets certain requirements, such as creating a pid file.
• Install the external service checker program on the BIG/ip Controller.
• Allow EAV service checks in the BIG/ip configuration.
• Configure the specific nodes to use the EAV service check.

Verifying external service checker requirements

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 external service checker must use a pid file to hold its process ID, and the pid file must use the following naming scheme:
  /var/run/pinger.<ip>..<port>.pid.
• As soon as the external service checker starts, if the pid file already exists, the external service checker should read the file and send a SIGKILL command to the indicated process.
• The external service checker must write its process ID to the pid file.
• If the external service checker verifies that the service is available, it must write standard output. If the external service checker verifies that the service is not available, it cannot write standard output.
• The external service checker must delete its pid file before it exits.

  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:

  /usr/local/lib/pingers/sample_pinger

The sample service checker, shown in Figure 5.1, is included with the BIG/ip Controller.

Figure 5.1 The HTTP external service checker program

 # 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 
  #  

  pidfile="/var/run/pinger.$1..$2.pid"  

  if [ -f $pidfile ] 
  then  
      kill -9 `cat $pidfile` > /dev/null 2>&1 
  fi 

  echo "___FCKpd___4quot; > $pidfile  

  echo "GET /" | /usr/local/lib/pingers/nc $1 $2 2> /dev/null | \ grep -E -i $3 > /dev/null 

   status=$?   
   if [ $status -eq 0 ] 
   then  
      echo "up"  
  fi 
   rm -f $pidfile 

Installing the external service checker on the BIG/ip Controller

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.

Allowing EAV service checks

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> \ 
["<argument_string>"]

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.

Command line arguments for EAV service checks

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.

Using the EAV pingers bundled with the BIG/ip Controller

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:

  /usr/local/lib/pingers/

The following sections describe how to set up each of these service checkers.

EAV service check for FTP

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 user@company.com"

  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.

To configure the FTP EAV check in the F5 Configuration utility

1. In the navigation pane, click Nodes.
   The Node Properties screen opens.
2. In the Extended section, click the EAV box to enable EAV service checking. The service check frequency and service check timeout must be set in order to access this option.
3. In the Type list, select the FTP service checker. The External Program Path is automatically filled in when you select a pinger from the list.
4. In the External Program Arguments box, type in the arguments required for the FTP service checker: a full path to the file on any given server, a user name, and a password. For example:

  /pub/demo/file.txt anonymous 
user@company.com

  /pub/spool/incoming.doc carol 
carols_password  

1. Click the Apply button.

EAV service check for POP3

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 
alices_password"

  external 10.0.0.57:109 /usr/local/lib/pingers/POP3_pinger "bob 
bobs_password" 

To configure the POP3 EAV check in the F5 Configuration utility

1. In the navigation pane, click Nodes.
   The Node Properties screen opens.
2. In the Extended section, click the EAV box to enable EAV service checking. The service check frequency and service check timeout must be set in order to access this option.
3. In the Type list, select the POP3 service checker. The External Program Path is automatically filled in when you select a service checker from the list.
4. In the External Program Arguments box, type in a user name and password. For example:

  alice alices_password

  bob bobs_password 

1. Click the Apply button.

EAV service check for SMTP

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 
"bigip@internal.net" 

To configure the SMTP EAV check in the F5 Configuration utility

1. In the navigation pane, click Nodes.
   The Node Properties screen opens.
2. In the Extended section, click the EAV box to enable EAV service checking. The service check frequency and service check timeout must be set in order to access this option.
3. In the Type list, select the SMTP service checker. The External Program Path is automatically filled in when you select a service checker from the list.
4. In the External Program Arguments box, type in a string identifying the server from which the EAV is originating. For example:

  bigip@internal.net 

1. Click the Apply button.

EAV service check for NNTP

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 
"comp.lang.java"

  external 10.0.0.62:119 /usr/local/lib/pingers/NNTP_pinger 
"local.chat username password" 

To configure the NNTP EAV check in the F5 Configuration utility

1. In the navigation pane, click Nodes.
   The Node Properties screen opens.
2. In the Extended section, click the EAV box to enable EAV service checking. The service check frequency and service check timeout must be set in order to access this option.
3. In the Type list, select the NNTP service checker. The External Program Path is automatically filled in when you select a service checker from the list.
4. In the External Program Arguments box, type in the news group name for which you want to check. If the NNTP server being queried requires authentication, you can provide the user name and password as additional arguments. For example:

  comp.lang.java

  local.chat username password 

1. Click the Apply button.

EAV service check for SQL-based services

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.

1. Test the login manually:

   cd /usr/local/lib/pingers

   ./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:

   Login succeeded!

   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.

2. Create and entry in the /etc/bigd.conf with the following syntax:

   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.

3. Add entries in the /etc/bigip.conf for the service checking:

   tping_svc 1433 5

   timeout_svc 1433 15

4. Reload the /etc/bigip.conf and restart bigd:

   bigpipe -f /etc/bigip.conf

   bigd

5. Verify that the service check is being performed correctly: If the service is UP, change the password in /etc/bigd.conf to an invalid password and restart bigd. The service should go down after the timeout period elapses.

   Correct the password and restart bigd and the service should go up again.

Troubleshooting SQL-based service checks

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.

Creating a test account for Microsoft SQL Server

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.