Configuring CSM Scripts
Available Languages
Table Of Contents
Using TCL Scripts with the CSM-S
Example for Writing a Probe Script
Example for Writing Standalone Scripts
TCL Script Frequently Asked Questions (FAQs)
Using TCL Scripts with the CSM-S
This chapter describes how to configure content switching and contains these sections:
•
TCL Script Frequently Asked Questions (FAQs)
The CSM-S allows you to upload and execute Toolkit Command Language (TCL) scripts on the CSM-S. Using TCL scripts, you can write customized TCL scripts to develop customized health probes or standalone tasks.
The TCL interpreter code in CSM-S is based on Release 8.0 of the standard TCL distribution. You can create a script to configure health probes (see the "Configuring Probes for Health Monitoring" section) or perform tasks on the CSM-S that are not part of a health probe. The CSM-S periodically executes the scripts at user-configurable intervals.
Before CSM-S Release 3.1(1a), you could not configure a health probe for a protocol that did not include the basic health-monitoring code. You can now write probes to customize the CSM-S for your specific application. CSM-S Release 3.2 supports UDP socket functions. TCL is a widely used scripting language within the networking community. TCL also has huge libraries of scripts developed that can easily be found from various sites.
The CSM-S currently supports two script modes:
•
As part of a script probe, the script is executed periodically, and the exit code that is returned by the executing script indicates the relative health and availability of specific real servers. Script probes operate similarly to other health probes available in the current implementation of CSM-S software.
•
For your convenience, sample scripts are available to support the TCL feature. Other custom scripts will work, but these sample scripts are supported by Cisco TAC. The file with sample scripts is located at this URL:
http://www.cisco.com/cgi-bin/tablebuild.pl/cat6000-intellother
The file containing the scripts is named: c6slb-script.3-3-1.tcl.
Loading Scripts
Scripts are loaded onto the CSM-S through script files. A script file may contain zero, one, or more scripts. Each script requires 128 KB of stack space. Because there can be a maximum of 50 health scripts, the maximum stack space for script probes is 6.4 MB. Standalone scripts may also be running, which would consume more stack space.
Examples for Loading Scripts
Scripts can be loaded from a TFTP server, bootflash, slot0, and other storage devices using the script file [file-url] command.
This example shows how to load a script:
Router(config)# module csm 4Router(config-module-csm)# script file tftp://192.168.1.1/httpProbe.testThe script name is either the filename of the script or a special name encoded within the script file. Each script file may contain a number of scripts in the same file. To run the script or create a health probe using that script, you must refer to the script name, not the script file from which the script was loaded.
In order to identify each relevant script, each script must start with a line:
#!name = script_nameThis example shows a master script file in which the scripts are bundled:
#!name = SCRIPT1puts "this is script1"!name = SCRIPT2puts "this is script2"This example shows how to find the scripts available in a master script file:
Router(config)# configure terminalRouter(config-t)# module csm 4Router(config-module-csm)# script file tftp://192.168.1.1/script.masterRouter(config-module-csm)# endThis example shows three scripts available from the script.master file:
Router(config)# show module csm 4 file tftp://192.168.1.1/script.masterscript1, file tftp://192.168.1.1/script.mastersize = 40, load time = 03:49:36 UTC 03/26/93script2, file tftp://192.168.1.1/script.mastersize = 40, load time = 03:49:36 UTC 03/26/93To show the contents of a loaded script file, use this command:
Router(config)# show module csm slot script full_file_URL codeThis example shows how to display the code within a named script:
router1# show module csm 6 script name script1 codescript1, file tftp://192.168.1.1/script.mastersize = 40, load time = 03:04:36 UTC 03/06/93#!name = script1One major difference between a standalone script task and a script probe is that the health script is scheduled by the health monitoring CSM-S module. These conditions apply:
•
•
•
•
Reloading TCL Scripts
After a script file has been loaded, the scripts in that file exist in the CSM-S independent of the file from which that script was loaded. If a script file is subsequently modified, use the script file command to reload the script file and enable the changes on the CSM-S. (Refer to the Content Switching Module with SSL Command Reference for more information.) For example:
router(config)# module csm 4router(config-module-csm)# no script file tftp://192.168.1.1/script.masterrouter(config-module-csm)# script file tftp://192.168.1.1/script.masterLoading script.master from 192.168.1.1 (via Vlan100): !!!!!!!!!!!!!!![OK - 74804 bytes]router(config-module-csm)# endThe no script file command removes the script file command from the running configuration. This command does not unload the scripts in that file and does not affect scripts that are currently running on the CSM-S. You cannot unload scripts that have been loaded. If a loaded script is no longer needed, it is not necessary to remove it.
TCL Scripts and the CSM-S
The CSM-S Release 1.1(1) TCL script feature is based on the TCL 8.0 source distribution software. CSM-S TCL is modified so that it can be interrupted to call another process unlike the standard TCL library, allowing for concurrent TCL interpreter execution. The CSM-S TCL library does not support any standard TCL file I/O command, such as file, fcopy, and others.
Table 12-1 lists the TCL commands that are supported by the CSM-S.
Table 12-2 lists the TCL command not supported by the CSM-S.
Table 12-2 TCL Commands Not Supported by the CSM-S
cd
fcopy
file
open
seek
source
tell
filename
load
package
Table 12-3 lists the TCL commands specific to the CSM-S.
Table 12-3 CSM-S Specific TCL Commands
disable_real serverfarmName realIp port ,-1 | all probeNumId probeNameId
Disables a real server from the server farm by placing it in the PROBE_FAIL state. This command returns a 1 if successful and returns a 0 if it fails, as follows:
disable_real SF_TEST 1.1.1.1 -1 10 cisco
Note
enable_real serverfarmName realIp port ,-1 | all probeNumId probeNameId
Enables a real server from the PROBE_FAIL state to the operational state. This command returns a 1 if successful and returns a 0 if it fails, as follows:
enable_real SF_TEST 1.1.1.1 -1 10 ciscoNote
gset varname value
Allows you to preserve the state of a probe by setting a variable that is global to all probe threads running from the same script. This command works properly only for probe scripts, not for standalone scripts.
Variables in a probe script are only visible within one probe thread. Each time a probe exits, all variables are gone. For example, if a probe script contains a 'gset x 1 ; incr x', variable x would increase by 1 for each probe attempt.
•
•
•
socket -graceful host A.B.C.D port
By default, all CSM-S script probes close the TCP socket by sending a reset. This action is taken to avoid the TIME_WAIT state when the CSM-S initializes an active TCP close.
Due to the limitation of 255 sockets available on vxworks, when there are too many probes running at the same time, the CSM-S can run out of system resources and the next probe attempt will fail when opening the socket.
When the socket -graceful command is entered, the CSM-S closes TCP connections with a FIN instead of a reset. Use this command only when there are fewer then 250 probes on the system, as follows:
set sock [socket -graceful 192.168.1.1 23]ping [numpacket] host A.B.C.D
This command is currently disabled in CSM-S release 3.2.
Allows you to ping a host from a script. This command returns a 1 if successful and returns a 0 if it fails, as follows:
set result [ping 3 1.1.1.1]Note
xml xmlConfigString
Sends an XML configuration string to the CSM-S from a TCL script. This command works only when the XML server is enabled on the CSM-S. Refer to the XML configuration section.
This command returns a string with the XML configuration result, as follows:
set cfg_result [ xml {<config><csm_module slot="6"><serverfarm name="SF_TEST"></serverfarm></config>}]
The UDP command set allows Scotty-based TCL scripts to run on the CSM-S. Scotty is the name of a software package that allows you to implement site-specific network management software using high-level, string-based APIs. All UDP commands are thread safe (allowing you to share data between several programs) like the rest of the CSM-S TCL commands.
Table 12-4 lists the UDP commands used by the CSM-S.
Probe Scripts
The CSM-S supports several specific types of health probes, such as HTTP health probes, TCP health probes, and ICMP health probes when you need to use a diverse set of applications and health probes to administer your network. The basic health probe types supported in the current CSM-S software release often do not support the specific probing behavior that your network requires. To support a more flexible health-probing functionality, the CSM-S now allows you to upload and execute TCL scripts on the CSM-S.
You can create a script probe that the CSM-S periodically executes for each real server in any server farm associated with a probe. Depending upon the exit code of such a script, the real server is considered healthy, suspect, or failed. Probe scripts test the health of a real server by creating a network connection to the server, sending data to the server, and checking the response. The flexibility of this TCL scripting environment makes the available probing functions possible.
After you configure each interval of time, an internal CSM-S scheduler schedules the health scripts. Write the script as if you intend to perform only one probe. You must declare the result of the probe using the exit command.
A health script typically performs these actions:
•
•
•
•
•
•
You can use the new probe probe-name script command for creating a script probe in Cisco IOS software. This command enters a probe submode that is similar to the existing CSM-S health probe submodes (such as HTTP, TCP, DNS, SMTP, and so on.). The probe script submode contains the existing probe submode commands failed, interval, open, receive, and retries.
A new script script-name command was added to the probe script submode. This command can process up to five arguments that are passed to the script when it is run as part of the health probe function.
Example for Writing a Probe Script
This example shows how a script is written to probe an HTTP server using a health script:
Router(config)# !name = HTTP_TEST# get the IP address of the real server from a predefined global array csm_envset ip $csm_env(realIP)set port 80set url "GET /index.html HTTP/1.0\n\n"# Open a socket to the server. This creates a TCP connection to the real serverset sock [socket $ip $port]fconfigure $sock -buffering none -eofchar {}# Send the get request as definedputs -nonewline $sock $url;# Wait for the response from the server and read that in variable lineset line [ read $sock ]# Parse the responseif { [ regexp "HTTP/1.. (\[0-9\]+) " $line match status ] } {puts "real $ip server response : $status"}# Close the socket. Application must close the socket once the# is over. This allows other applications and tcl scripts to make# a good use of socket resource. Health monitoring is allowed to open# only 200 sockets simultaneously.close $sock# decide the exit code to return to control module.# If the status code is OK then script MUST do exit 5000# to signal successful completion of a script probe.# In this example any other status code means failure.# User must do exit 5001 when a probe has failed.if { $status == 200 } {exit 5000} else {exit 5001}Environment Variables
Health probe scripts have access to many configured items through a predefined TCL array. The most common use of this array is to find the current real server IP addresses of the suspect during any particular launch of the script.
Whenever a script probe is executed on the CSM-S, a special array called csm_env is passed to the script. This array holds important parameters that may be used by the script.
Note
Table 12-5 lists the members of the csm_env array.
Exit Codes
The probe script uses exit codes to signify various internal conditions. The exit code information can help you troubleshoot your scripts if they do not operate correctly. You can only use the exit 5000 and exit 5001 exit codes. A probe script indicates the relative health and availability of a real server using the exit code of the script. By calling exit (5000), a script indicates that the server successfully responded to the probe. Calling exit (5001) indicates that the server did not respond correctly to the health probe.
When a probe script fails and exits with 5001, the corresponding server is marked as PROBE_FAILED and is temporarily disabled from the server farm. The CSM-S continues to probe the server. When the probe successfully reconnects and exits with 5000, the CSM-S marks the server's status as OPERATIONAL and enables the server from the server farm again.
In addition to script exit 5001, these situations can cause a script to fail and mark the suspect PROBE_FAILED:
•
•
•
Table 12-6 shows all exit codes used in the CSM-S.
EXIT_MSG Variable
For debugging purposes, it is a good practice to set the script debug information in a special variable named EXIT_MSG. Using the EXIT_MSG variable, you can track the script execution point by entering specific Cisco IOS show commands.
This example shows how to use the EXIT_MSG variable to track script exit points to detect why a script is not working:
set EXIT_MSG "opening socket"set s [socket 10.2.0.12 80]set EXIT_MSG "writing to socket"puts -nonewline $sock $urlUse the show module csm slot tech script command to check the EXIT_MSG variable.
This example shows that the EXIT_MSG was set to "opening socket" because EXIT_MSG is the last command that the script runs before the exit:
router1# show module csm 4 tech scriptSCRIPT CONTROLLER STATS: ==========================================================================SCRIPT(0xcbcfb50) stat blk(0xcbcfbb0): TCL_test.tclcbcfb50CMDLINE ARGUMENT:curr_id 1 argc 0 flag 0x0::type = PROBEtask_id = 0x0: run_id = 512 ref count = 2task_status = TASK_DONE run status = OKstart time = THU JAN 01 00:15:47 1970end time = THU JAN 01 00:17:02 1970runs = 1 +0resets = 1 +0notrel = 0 +0buf read err = 0 +0killed = 0 +0panicd = 0 +0last exit status= 4000 last Bad status = 4000Exit status history:Status (SCRIPT_ABORT) occured #(1) last@ THU JAN 01 00:17:02 1970**TCL Controller:------------------------tcl cntrl flag = 0x7fffffff#select(0) close_n_exit(0) num_sock(1)MEM TRACK last alloc(0) last size(0) alloc(0) size(0)hm_ver (1) flag(0x0) script buf(0xcbf8c00) new script buf(0x0) lock owner(0x0) sig taskdel:0 del:0 syscall:0 syslock:0 sig_select script ptr (0xcbf88f0) id(0)Config(0xcbcdd78) probe -> 10.1.0.105:80tclGlob(0xcbad050) script resource(0xcbcfa28)#Selects(0) Close_n_exit(0) #Socket(1)OPEN SOCKETS:Last erroInfo = couldn't open socket: host is unreachablewhile executing"socket 10.99.99.99 80 "(file "test.tcl" line 2)Last errorCode = 65Last panicInfo =EXIT_MSG = opening socketRunning Probe Scripts
To run a probe script, you must configure a script probe type, and then associate a script name with the probe object (refer to the Catalyst 6500 Series Content Switching Module Command Reference).
To load, create, attach the script to a server farm and virtual server, run the probe scripts, and then display the results, perform theses steps:
Step 1
router1# conf tEnter configuration commands, one per line. End with CNTL/Z.router1(config)# module csm 6router1(config-module-csm)# script file tftp://192.168.10.102/csmTcl.tclLoading csmTcl.tcl from 192.168.10.102 (via Vlan100): ![OK - 1933 bytes]Step 2
router1(config-module-csm)# probe test1 scriptrout(config-slb-probe-script)# script CSMTCLrout(config-slb-probe-script)# interval 10rout(config-slb-probe-script)# exitStep 3
router1(config-module-csm)# serverfarm testrouter1(config-slb-sfarm)# real 10.1.0.105router1(config-slb-real)# insrouter1(config-slb-real)# probe test1router1(config-slb-sfarm)# exitStep 4
router1(config-module-csm)# vserver testrouter1(config-slb-vserver)# virtual 10.12.0.80 tcp 80router1(config-slb-vserver)# serverfarm testrouter1(config-slb-vserver)# insrouter1(config-slb-vserver)# exitAt this point, the script probe should be set up. You can use the show module csm slot tech probe command to ensure that the scripts are running.
Step 5
router1(config-module-csm)# serverfarm testrouter1(config-slb-real)# no probe test1router1(config-slb-sfarm)# exit
The examples that follow show how to verify the results of the script commands.
This example shows how to display script information:
router1# show module csm 6 scriptCSMTCL, file tftp://192.168.10.102/csmTcl.tclsize = 1933, load time = 03:09:03 UTC 01/01/70This example shows how to display information about probe scripts:
router1# show module csm 6 probeprobe type port interval retries failed open receive---------------------------------------------------------------------TEST1 script 10 3 300 10 10router1#This example shows how to display detailed information about a specific probe script:
router1# show module csm 6 probe name TEST1 detailprobe type port interval retries failed open receive---------------------------------------------------------------------TEST1 script 10 3 300 10 10Script: CSMTCLreal vserver serverfarm policy status------------------------------------------------------------------------------10.1.0.105:80 TEST1 TEST (default) OPERABLErouter1#This example shows how to display probe information for real servers:
router1# show module csm 6 probe realreal = 10.1.0.105:80, probe = TEST1, type = script,vserver = TEST, sfarm = TESTstatus = FAILED, current = 03:26:04 UTC 01/01/70,successes = 1, last success = 03:15:33 UTC 01/01/70,failures = 4, last failure = 03:26:04 UTC 01/01/70,state = Unrecognized or invalid responsescript CSMTCLlast exit code = 5001Debugging Probe Scripts
To debug a script probe, you can do the following:
•
In the verbose mode, the puts command causes each probe suspect to print a string to the CSM-S console. When there are many suspects running on the system, lots of output resources are required or the CSM-S console might hang. It is very important to make sure that this feature is enabled only when a single suspect is configured on the system.
•
Each probe suspect contains its own EXIT_MSG variable. This variable allows you to trace the status of a script and check the status of the probe.
This example shows how to use the EXIT_MSG variable in a script:
set EXIT_MSG "before opening socket"set s [ socket $ip $port]set EXIT_MSG " before receive string"gets $sset EXIT_MSG "before close socket"close $sIf a probe suspect fails when receiving the message, you should see EXIT_MSG = before you receive the string.
•
This command shows you the current active probe suspects in the system:
router1# show module csm 6 probe realreal = 10.1.0.105:80, probe = TEST1, type = script,vserver = TEST, sfarm = TESTstatus = FAILED, current = 04:06:05 UTC 01/01/70,successes = 1, last success = 03:15:33 UTC 01/01/70,failures = 12, last failure = 04:06:05 UTC 01/01/70,state = Unrecognized or invalid responsescript CSMTCLlast exit code = 5001
Note
•
This command shows the current probe status (for both the standard and script probe):
router1# show module csm 6 tech probeSoftware version: 3.2(1)--------------------------------------------------------------------------- Health Monitor Statistics ---------------------------------------------------------------------Probe templates: 1Suspects created: 1Open Sockets in System : 8 / 240Active Suspect(no ICMP): 0 / 200Active Script Suspect : 0 / 50Num events : 1Script suspects: 1Healthy suspects: 0Failures suspected: 0Failures confirmed: 1Probe attempts: 927 +927Total recoveries: 3 +3Total failures: 6 +6Total Pending: 0 +0•
router1# show module csm 6 tech scriptSCRIPT(0xc25f7e0) stat blk(0xc25f848): TCL_csmTcl.tclc25f7e0CMDLINE ARGUMENT:curr_id 1 argc 0 flag 0x0::type = PROBEtask_id = 0x0: run_id = 521 ref count = 2task_status = TASK_DONE run status = OKstart time = THU JAN 01 03:51:04 1970end time = THU JAN 01 03:51:04 1970runs = 13 +11resets = 13 +11notrel = 0 +0buf read err = 1 +1killed = 0 +0panicd = 0 +0last exit status= 5001 last Bad status = 5001Exit status history:**TCL Controller:------------------------tcl cntrl flag = 0x7fffffff#select(0) close_n_exit(0) num_sock(2)MEM TRACK last alloc(0) last size(0) alloc(0) size(0)hm_ver (3) flag(0x0) script buf(0xc25ad80) new script buf(0xc25ad80)lock owner(0x0) sig taskdel:0 del:0 syscall:0 syslock:0 sig_selectscript ptr (0xc25f038) id(0)Config(0xc2583d8) probe -> 10.1.0.105:80tclGlob(0xc257010)SCRIPT RESOURCE(0xc25af70)-------#Selects(0) Close_n_exit(0) #Socket(2)OPEN SOCKETS:Persistent Variables--------------------x = 11Last erroInfo =Last errorCode =Last panicInfo =EXIT_MSG = ping failed : invalid command name "ping"The last exit status displays the exit code number as shown in Table 12-6.
The Persistent Variables information is set by the gset varname value command (as described in the "CSM-S Specific TCL Commands" section).
The erroInfo lists the error that is generated by the TCL compiler. When the script has a TCL runtime error, the TCL interpreter stops running the script and stores the error information in the erroInfo variable.
The EXIT_MSG (see the "EXIT_MSG Variable" section) displays detailed debug information for each probe suspected of failure. Because the output may be lengthy, you can try to filter the keyword first as shown in this example:
router1# show module csm slot tech script inc keywordStandalone Scripts
A standalone script is a generic TCL script that loads and runs in the CSM-S. Because the standalone script is not configured like the probe script, and it is not attached to a server farm, the script will not be scheduled by the CSM-S as a periodically run task. To run the task, you must use the script task command.
The csm_env environment variables are not applied to a standalone script. You may use the exit command, however, if the exit code does not have special meaning for standalone scripts as it does in the probe script.
Example for Writing Standalone Scripts
This example shows how a generic TCL script can be written:
#!name = STD_SCRIPTset gatewayList "1.1.1.1 2.2.2.2"foreach gw $gatewayList {if { ![ ping $gw ] } {puts "-WARNING : gateway $gw is down!!"}}Running Standalone Scripts
A standalone script is a TCL script that will be run once as a single task unlike script probes. The script will run and exit when it is finished. The standalone script will not be run by the CSM-S periodically unless you configure this script as a task. The script file command may be stored in the startup configuration so that it will run when the CSM-S boots. The script continues to run while the CSM-S is operating.
To run standalone scripts, perform these steps:
Step 1
router1# conf tEnter configuration commands, one per line. End with CNTL/Z.router1(config)# module csm 6router1(config-module-csm)# script file tftp://192.168.10.102/stdcsm.tclLoading stdcsm.tcl from 192.168.10.102 (via Vlan100): ![OK - 183 bytes]Step 2
router1(config-module-csm)# script task 1 STD_SCRIPTStep 3
You can remove the old task and run it again as follows:
router1(config-module-csm)# no script task 1 STD_SCRIPTrouter1(config-module-csm)# script task 1 STD_SCRIPTYou also can start a new task by giving it a new task ID as follows:
router1(config-module-csm)# script task 2 STD_SCRIPTStep 4
router1(config-module-csm)# no script task 1 STD_SCRIPTStep 5
router1#sh mod csm 6 scriptSTD_SCRIPT, file tftp://192.168.10.102/stdcsm.tclrouter1#sh mod csm 6 script tasktask script runs exit code status--------------------------------------------------------------------------1 STD_SCRIPT 1 4000 Not Ready2 STD_SCRIPT 1 4000 Not Ready
To display information about a specific running script, use the show module csm slot script task index script-index detail or the show module csm slot script name script-name code commands.
Debugging Standalone Scripts
Debugging a standalone script is similar to debugging a probe script. See the "Debugging Probe Scripts" section. You can use the puts command in the script to help debugging, because running multiple threads do not cause problems.
TCL Script Frequently Asked Questions (FAQs)
These are some frequently asked questions about TCL scripting for the CSM-S:
•
The Vxworks support application has 255 file descriptors that are divided across all applications, for example, standard input and output, and any socket connections (to or from). When developing standalone scripts, you must be extremely careful when opening a socket. We recommend that you close a socket as soon as the operation is complete because you may run out of resources. The health monitoring module controls the number of open sockets by controlling the number of actively running scripts. Standalone scripts do not have this control.
Memory, although a consideration, is not a big limiting factor because the module generally has enough memory available. Each script uses a 128-KB stack, and the rest of the memory is allocated at runtime by the script.
The script tasks are given the lowest priority in the system so that the real-time characteristics of the system remain more or less the same while executing scripts. Unfortunately, scripts that have low priority also mean that if the system is busy doing non-TCL operations, all TCL threads may take longer to complete. This situation may lead to some health scripts being terminated and the unfinished threads marked as failed. To prevent scripts being failed, all script probes should have a retry value of 2 or more. You may want to use native CSM-S probes (for example, HTTP or DNS) whenever possible. The scripted health probes should be used to support nonsupported applications.
TCL supports both synchronous and asynchronous socket commands. Asynchronous socket commands return immediately without waiting for true connections. The internal implementation of the asynchronous script version involves a much more complicated code path with many more system calls per each such command. This condition generally slows down the system by causing some critical resources to wait while other commands are processing system calls. We do not recommend using the asynchronous socket for scripted probes unless this is a definite requirement. However, you may use this command in a standalone system.
•
You can run a sniffer on the real server side of the network. Also, you can use the following show commands to determine if probes are running on the CSM-S.
–
router1# show module csm 6 tech proberouter1#sh mod csm 6 tech probeSoftware version: 3.2(1)-------------------------------------------------------------------------------- Health Monitor Statistics -------------------------------------------------------------------------------Probe templates: 8Suspects created: 24Open Sockets in System : 10 / 240Active Suspect(no ICMP): 2 / 200Active Script Suspect : 2 / 50Num events : 24Script suspects: 24Healthy suspects: 16Failures suspected: 0Failures confirmed: 8Probe attempts: 321 +220Total recoveries: 16 +0Total failures: 8 +2Total Pending: 0 +0–
router1# show module csm 6 probe realreal = 10.12.0.108:50113, probe = SCRIPT2_2, type = script,vserver = SPB_SCRIPT2, sfarm = SCRIPT2_GOOD, policy = SCRIPT2_GOOD,status = OPERABLE, current = 22:52:24 UTC 01/04/70,successes = 18, last success = 22:52:24 UTC 01/04/70,failures = 0, last failure = 00:00:00 UTC 01/01/70,state = Server is healthy.script httpProbe2.tcl GET /yahoo.html html 1.0 0last exit code = 5000real = 10.12.0.107:50113, probe = SCRIPT2_2, type = script,vserver = SPB_SCRIPT2, sfarm = SCRIPT2_GOOD, policy = SCRIPT2_GOOD,status = OPERABLE, current = 22:52:42 UTC 01/04/70,successes = 19, last success = 22:52:42 UTC 01/04/70,failures = 0, last failure = 00:00:00 UTC 01/01/70,state = Server is healthy.script httpProbe2.tcl GET /yahoo.html html 1.0 0last exit code = 5000You can also close the socket using FIN in place of reset (RST).
•
A UDP probe must receive an "icmp port unreachable" message to mark a server as PROBE_FAIL. When a remote host is down or not responding, the UDP probe does not receive the ICMP message and the probe assumes that the packet is lost and the server is healthy.
Because the UDP probe is a raw UDP probe, the CSM-S is using a single byte in the payload for probe responses. The CSM-S does not expect any meaningful response from the UDP application. The CSM-S uses the ICMP Unreachable message to determine if the UDP application is not reachable.
If there is no ICMP unreachable reply in the receive timeout, the CSM-S assumes that the probe is operating correctly. If the IP interface of the real server is down or disconnected, the UDP probe by itself would not know that the UDP application is not reachable. You must configure the ICMP probe in addition to the UDP probe for any given server.
Workaround: Always configure ICMP with a UDP type of probe.
•
Sample scripts are available to support the TCL feature. Other custom scripts will work, but these sample scripts are supported by Cisco TAC. The file with sample scripts is located at this URL:
http://www.cisco.com/cgi-bin/tablebuild.pl/cat6000-intellother
The file containing the scripts is named: c6slb-script.3-3-1.tcl.
•
The TCL 8.0 command reference is located at this URL:
http://www.tcl.tk/man/tcl8.0/TclCmd/contents.html
The TCL UDP command reference is located at this URL:
http://wwwhome.cs.utwente.nl/~schoenw/scotty/
Feedback