ServerIron ADX Server Load Balancing Guide
Release 12.0.00
June 15, 2009

Table of Contents Previous Next Print


Health Checks > Layer 7 Health Checks

Layer 7 Health Checks
You can configure the following Layer 7 health check parameters on a real server basis:
NOTE: The ServerIron ADX uses its own management IP address or a source IP address configured on the ServerIron ADX as the source IP address in the health check packets (as opposed to a virtual IP address). If the real servers are in the same subnet as the ServerIron ADX, then the health checks can use the ServerIron ADX’s management IP address. Otherwise, the health checks use a source IP address. See “Web Hosting with ServerIron ADX and Real Servers in Different Subnets”.
Enabling Layer 7 Health Check
All Layer 7 health checks are disabled by default. You can enable a health check globally or locally.
NOTE: The ServerIron ADX considers a Layer 7 health check to be disabled only if the health check is disabled on both the global and local levels. If the health check is enabled globally, locally, or both globally and locally, the ServerIron ADX considers the health check to be enabled. See “Configuring a Port Profile”.
To locally enable a Layer 7 health check, enter a command such as the following at the Real Server level of the CLI:
ServerIron(config-rs-jet)# port dns keepalive
Syntax: [no] port <port> keepalive
If you use the "no" parameter in front of the command, you are locally disabling the health check. The health checks are locally disabled by default.
The <port> parameter can have one of the following values:
NOTE: Specify the port number if the port is not one of the well-known names listed above.
Changing HTTP Keepalive Method, Value, and Status Codes
The ServerIron ADX supports two kinds of HTTP health checks:
HTTP status code health checks look at the status code returned in HTTP responses to keepalive requests.
HTTP content verification health checks look at the actual HTML contained in HTTP responses to keepalive requests.
The default URL page for HTTP keepalive requests used in HTTP health checks is “HEAD /1.0”. You can change the URL that the ServerIron ADX requests on a real server basis.
NOTE: For HTTP content verification health checks, you may want to change the default URL page for HTTP keepalive requests URL page, since a request for “HEAD /1.0” would not return a response containing HTML for content verification. You can specify a GET request for a page containing text that can be searched and verified. See “Configuring HTTP Content Matching Lists” for more information.
To configure the HTTP keepalive request to send a GET request for “sales.html”, enter the following commands:
ServerIron(config)# server real zip 207.96.3.251
ServerIron(config-rs-zip)# port http url "GET /sales.html"
ServerIron(config-rs-zip)# exit

ServerIron(config)# server virtual-name-or-ip shoosh 207.96.4.250
ServerIron(config-vs-shoosh)# port http
ServerIron(config-vs-shoosh)# bind http zip http
ServerIron(config-vs-shoosh)# exit
Syntax: port http url “[GET | HEAD] [/]<URL-page-name>”
GET or HEAD is an optional parameter that specifies the request type. By default, HTTP keepalive uses HEAD to retrieve the URL page. You can override the default and configure the ServerIron ADX to use GET to retrieve the URL page.
The slash ( / ) is an optional parameter. If you do not set the GET or HEAD parameter, and the slash is not in the configured URL page, then ServerIron ADX automatically inserts a slash before retrieving the URL page.
To change the HTTP status codes that the ServerIron ADX considers normal (not indicative of a failure of the HTTP service), enter the following command.
ServerIron(config-rs-zip)# port http status-code 200 201 300 302
Syntax: port http status-code <range> [<range>[<range>[<range>]]]
The command in this example specifies two ranges (200 – 201 and 300 – 302). You can specify up to four ranges (total of eight values). To specify a single message code for a range, enter the code twice. For example to specify 200 only, enter the following command: port http status-code 200 200.
NOTE: When you change the status code ranges, the defaults are removed. As a result, you must specify all the valid ranges, even if a range also is within the default ranges. For example, if you still want codes 200 – 299 to be valid, you must specify them. For the defaults, see “3.8 HTTP Status Codes”.
Configuring HTTP Content Matching Lists
ServerIron ADX currently supports compound and simple content-matching statements under the match-list configuration. This enhancement adds support for "start" and "end" statements in the match-list configuration.
ServerIron(config)# http match-list m1
ServerIron(config-real-server-r1) down start "404"
ServerIron(config-real-server-r1) default up
ServerIron(config)# http match-list m2
ServerIron(config-real-server-r1) up end "found"
ServerIron(config-real-server-r1) default down
The first match list m1 would cause ServerIron ADX to mark the port failed if the text "404" is found at the beginning of the reply from the server. If the text is not found, the ServerIron ADX would mark the port UP, as the default configured is UP.
In the second example above, for match-list m2, ServerIron ADX would mark the port UP, if the text "found' is present at the end of the reply from the server.
An HTTP content verification health check is a type of Layer 7 health check in which the ServerIron ADX examines text in an HTML file sent by a real server in response to an HTTP keepalive request. The ServerIron ADX searches the text in the HTML file for user-specified selection criteria and determines whether the HTTP port on the real server is alive based on what it finds.
The selection criteria used in HTTP content verification is contained in a matching list that is bound to one or more real servers.
To configure a matching list, enter commands such as the following:
ServerIron(config)#http match-list m1
ServerIron(config-http-ml-m1)#down simple "404"
ServerIron(config-http-ml-m1)#down simple "File Not Found"
ServerIron(config-http-ml-m1)#exit
The first command sets the name of the matching list and enters the HTTP matching list CLI level. The first down statement looks for the text “404” in the HTML file sent from the real server in response to an HTTP keepalive request; the second down statement looks for the text “File Not Found.” If either of these text strings are found in the HTML file, the ServerIron ADX marks port 80 (HTTP) on the real server FAILED. If neither of the text strings are found, the ServerIron ADX marks the port ACTIVE.
Syntax: http match-list <matching-list-name>
Syntax: down I up simple <text> [log]
The down simple and up simple statements specify the selection criteria in the matching list.
NOTE: There is a limit of 200 selection criteria statements for all HTTP matching lists. That is, the total number of up and down statements in all HTTP matching lists on the ServerIron ADX must not exceed 200.
When an HTML file meets more than one set of selection criteria in a matching list, the ServerIron ADX takes one of the following actions:
ServerIron(config)# http match-list m2
ServerIron(config-http-ml-m2)# down simple "monkey"
ServerIron(config-http-ml-m2)# up simple "elephant"
ServerIron(config-http-ml-m2)# exit
The selection criteria in the matching list above would cause the ServerIron ADX to mark the port FAILED if the text "monkey" is found and ACTIVE if the text "elephant" is found. If the HTML file has the text "monkey" at the beginning and "elephant" at the end, the ServerIron ADX would mark port 80 on the real server FAILED, because "monkey" occurs first in the file.
ServerIron(config)# http match-list m3
ServerIron(config-http-ml-m3)# down simple "elephant"
ServerIron(config-http-ml-m3) #up simple "elephantine"
ServerIron(config-http-ml-m3)# exit
In this example, ServerIron ADX would mark the port FAILED if the text “elephant” is found and ACTIVE if the text “elephantine” is found. If the HTML file has the text “elephant” at the beginning and “elephantine” at the end, the ServerIron ADX would mark port 80 on the real server ACTIVE, because “elephantine” is longer than “elephant”.
The following is an example of a matching list that uses compound selection criteria, in which the beginning and ending parts of selection criteria are specified:
ServerIron(config)# http match-list m4
ServerIron(config-http-ml-m4)# up compound "monkey see" "monkey do" log
ServerIron(config-http-ml-m4)# down compound "500" "Internal Server Error" log
ServerIron(config-http-ml-m4)# down compound "503" "Service Unavailable" log
ServerIron(config-http-ml-m4)# default down
ServerIron(config-http-ml-m4)# exit
In this example, the default down command causes port 80 on the real server to be marked FAILED if none of the selection criteria are found in the HTTP response message.
Syntax: down | up compound <start> <end> [log]
Syntax: default down | up
In this matching list, the up and down commands include the compound parameter, which allows you to specify beginning and ending parts of a set of selection criteria. Text that begins with the first part and ends with the second part meets the selection criteria.
In this example, the up command specifies that if the HTML file sent from the real server in response to an HTTP keepalive request contains a text string that begins with the text “monkey see” and ends with the text “monkey do”, port 80 on the real server is marked ACTIVE. The down commands specify that if the HTML file contains a text string that begins with “500” and ends with “Internal Server Error” or begins with “503” and ends with “Service Unavailable”, the port is marked FAILED.
The default command specifies what happens if none of the HTML text in the HTTP response message meets the selection criteria. You can specify either up or down; the default is up. If the real server responds to the health check with a RST, the port is marked ACTIVE or FAILED depending on what was specified in the default statement in the matching list.
The log parameter causes the following Warning message to be logged when the selection criteria is met:
00d00h00m00s:W:HTTP match-list <matching-list> with compound pattern1 <start> and pattern2 <end> Alert: bring server down and Extract message: <text-between-start-and-end-pattern>
In the example, at the successful completion of an HTTP content verification health check, the following message would be logged; that is, if the HTML file sent from the real server in response to an HTTP keepalive request contains a text string that begins with the text “monkey see” and ends with the text “monkey do”:
ServerIron# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 1 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning

Dynamic Log Buffer (50 entries):
02d04h47m12s:W:HTTP match-list m4 with compound pattern1 "monkey see" and pattern2 "monkey do" Alert: bring server up and Extract message: This web page is configured correctly
Displaying HTTP Match Lists
To display the contents of matching lists configured on the ServerIron ADX, enter the following command:
ServerIron# show http match-list
http match-list m1
down simple "404"
down simple "File Not Found"
http match-list m4
default down
up compound "monkey see" "monkey do" log
down compound "500" "Internal Server Error" log
down compound "503" "Service Unavailable" log
Binding the Matching List to the Real Servers
To enable HTTP content verification on the ServerIron ADX, you bind the matching list to one or more real servers, by entering commands such as the following:
ServerIron(config)# server real-name rs1 192.168.1.1
ServerIron(config-rs-rs1)# port http content-match m4
ServerIron(config-rs-rs1)# port http url "GET/monkey.html"
ServerIron(config-rs-rs1)# exit
Syntax: server real-name <real-server-name> <ip-addr>
Syntax: port http content-match <matching-list-name>
Syntax: port http url “[GET | HEAD] [/]<URL-page-name>”
In this example, the port http content-match m4 command binds matching list m4 to real server rs1. HTTP response messages coming from real server rs1 are examined using the selection criteria in matching list m4.
The port http url command sets the method used for HTTP keepalive requests and the URL of the page to be retrieved. This command is used in HTTP content verification health checks because the default method and URL page for HTTP keepalive requests used in HTTP health checks, “HEAD /1.0”, does not return an HTML file that the ServerIron ADX can search and verify. You can instead specify the GET method, which does return an HTML file that can be examined using the matching list.
Configuring Scripted Health Checks
You can configure scripted health checks (also known as content checking), which are content verification health checks for ports that do not use one of the well-known port numbers recognized by the ServerIron ADX. Previous releases supported content verification health checks on port 80 only.
In a scripted health check, the ServerIron ADX opens a connection to a port on a real server by sending a SYN packet. The ServerIron ADX completes the three-way handshake and then waits for the server to send a packet containing ASCII strings in response. It then searches for the configured ASCII string in the received packet. The port on the real server is then marked ACTIVE or FAILED, based on configuration settings in the matching list. For example, a matching list can be configured to mark a port ACTIVE or FAILED if the string is found, or mark the port ACTIVE or FAILED if the string is not found.
If no response is received within the configured interval (the default is five seconds), the ServerIron ADX sends a RST and retries the health check. After the configured number of retries (the default is two retries), if the server still does not respond, the ServerIron ADX marks the server port FAILED.
A scripted health check can also be part of a health-check policy. In this case, the scripted health check checks the health of a configured port in the policy. The health-check policy can be evaluated to true or false depending on the response from the server.
To configure a scripted health check, do the following:
1.
2.
3.
Configuring a Port Profile
Port profiles enable you to globally configure the attributes for individual TCP/UDP ports. A scripted health check will not work on a TCP port that doesn’t have a profile, since the ServerIron ADX assumes any port without a profile is a UDP port, and will perform UDP health checking on the port. To use a scripted health check on a TCP port, you must create a port profile and explicitly identify the port as a TCP port.
The following commands configure a port profile for port 12345 and specify that the port is a TCP port. The nofastbringup command is necessary because it prevents the ServerIron ADX from marking a port ACTIVE until it passes both Layer 4 and Layer 7 health checks.
ServerIron(config)# server port 12345
ServerIron(config-port-12345)# tcp
ServerIron(config-port-12345)# no-fast-bringup
Syntax: server port <TCP/UDP-portnum>
Syntax: tcp | udp [keepalive <interval> <retries>]
Syntax: no-fast-bringup
Configuring a Matching List
The selection criteria used in a content verification health check is specified in a matching list that is bound to one or more real servers. The syntax used for creating a matching list for scripted health checks is the same as that used for creating a matching list for HTTP content verification health checks.
The following is an example of a matching list that will mark a port ACTIVE if the string “FTP service” is found in the response from the real server. If this text is not found, the port on the real server is marked FAILED.
ServerIron(config)# http match-list m1
ServerIron(config-http-m1-m1)# up simple "FTP service"
ServerIron(config-http-m1-m1)# default down
ServerIron(config-http-ml-m1)# exit
In this example, the default down command causes the port on the real server to be marked FAILED if the selection criteria is not found in the response from the server.
For information on the command syntax, see “Configuring HTTP Content Matching Lists”.
Binding the Matching List to the Real Server
To enable the scripted health check on the ServerIron ADX, you bind the matching list to one or more real servers. For example, to bind matching list m1 to real server R, enter commands such as the following:
ServerIron(config)# server real R 10.10.10.50
ServerIron(config-rs-R)# port 12345 content-check m1
Syntax: port <portnum> content-check <matching-list-name>
The <portnum> is a non-well-known port. You cannot specify a well-known port for a scripted health check.
The <matching-list-name> is a previously configured matching list. If the <matching-list-name> does not refer to an existing matching list, the port on the real server is marked FAILED when the health check is performed.
Using a Scripted Health Check in a Health-Check Policy
A scripted health check can be used in a health-check policy. A health-check policy is a group of one or more health checks attached to a real server port. When the scripted health check checks the health of a destination port specified in the policy, the health-check policy can be evaluated to true or false depending on the response from the server.
To use a scripted health check with a health-check policy, you configure a matching list, then configure the health-check policy.
For example, when the following matching list is used with a health-check policy, it will evaluate the policy to true if the string “FTP service” is found in the response from the real server. If this text is not found, the policy is evaluated to false.
ServerIron(config)# http match-list m1
ServerIron(config-http-m1-m1)# up simple "FTP service"
ServerIron(config-http-m1-m1)# default down
ServerIron(config-http-ml-m1)# exit
The default down command causes the policy to be evaluated to false if the selection criteria is not found in the response from the server. If the real server responds to the health check with a RST, the policy is evaluated to true or false depending on what was specified in the default statement in the matching list.
Configuring a Health Check Policy
The following commands create a health check policy for TCP port 1234 on VIP 10.10.10.10. Matching list m1 is bound to this policy.
ServerIron(config)# healthck check1 tcp
ServerIron(config-hc-check1)# dest-ip 10.10.10.10
ServerIron(config-hc-check1)# port 1234 content-check m1
ServerIron(config-hc-check1)# l7-check
Syntax: [no] healthck <element-name> <protocol>
Syntax: [no] dest-ip <ip-addr>
Syntax: [no] port <portnum> content-check <matching-list-name>
Syntax: [no] l7-check
Note that the dest-ip <ip-addr> command must be the first command entered for a health-check policy. If this is not the first command entered for the policy, an error message is displayed.
If the <matching-list-name> does not refer to an existing matching list, the policy is evaluated to false.
The l7-check command is required to ensure that the ServerIron ADX performs a Layer 7 health check. If this command is omitted, the ServerIron ADX performs only a Layer 4 health check, and not the scripted health check.
Scripted Healthcheck Enhancement on Real Servers
Previously, the ServerIron ADX would establish a TCP connection, waits for the real server to send an ASCII text, and then bring a server port up or down, based on the content match-list configured in a scripted health check policy.
In this release, the new content-check send option has been added to the existing port <port-name> command:
[no] port <port-name> content-check <match-list-name>
[no] port <port-name> content-check send "<string>"
When configured to send a string to the server, the ServerIron ADX establishes a TCP connection, and on receiving a SYN-ACK, sends the configured string to the server. The device then waits for the server to send ASCII text and then brings the server port up or down, based on the configured match-list policy.
ServerIron(config)# server real r1 10.10.1.31
ServerIron(config-rs-r1)# port 1234 keepalive
ServerIron(config-rs-r1)# port 1234 content-check m1
ServerIron(config-rs-r1)# port 1234 content-check send "how are you"
ServerIron(config-rs-r1)# exit
ServerIron(config)# http match-list m1
ServerIron(config-http-ml-m1)# up simple good
ServerIron(config-http-ml-m1)# default down
In this example, the ServerIron ADX sends a SYN packet to server 10.10.1.31, port 1234. On receiving a SYN-ACK from the server, the ServerIron ADX will send a TCP packet with the data "how are you". The ServerIron ADX then waits for the server. In the data of the TCP packets sent by the server, the ServerIron ADX will look for the pattern "good". If found, the ServerIron ADX marks the real server r1 port 1234 as UP, else it will mark the port as DOWN
NOTE: The l7-check command must be enabled, in order for the ServerIron ADX to send the script. If l4-check is configured, the ServerIron ADX will establish a TCP connection and then send a RST.
Binary Scripted Health Check
An existing scripted health check feature allows ServerIron to complete 3-way TCP handshake followed by sending of ASCII string and waiting for an appropriate response before marking real server health.
If the customer is running an application that can not interpret data in ASCII format then the above methodology will not help.
This enhancement allows ServerIron ADX to send binary data (carray format) after doing 3-way TCP handshake with the backend server. The ServerIron ADX would then mark the health of the server as pass or failed depending on the response content match (again in carry format).
A sample configuration is shown below:
server real rs1 10.1.1.1
port 1111 content-check-carray m1
port 1111 content-check-carray send “0xe1,0xe2,0xe3,0xe4”
port 1111 keepalive
http match-list m1
default down
up simple 0xca,0xcb,0xcd,0xce
NOTE: Sending of binary data after 3-way handhsake is not mandatory.
Scripted Health Check for UDP Ports
This feature enhances the TrafficWorks software to perform customizable scripted health checks for UDP protocol. in addition to the current TCP protocol, this feature is available on any out-of-band port and is able to utilize the existing L7 content check features.
ServerIron ADX surrently supports scripted health-checks on TCP ports. This features adds support for scripted health-checks on UDP ports.
When scripted health-check is configured on a UDP port, the ServerIron ADX will send out a UDP packet with the content-check-send data if configured, else it will send out a UDP packet. Then it expects a UDP reply, with ascii content and will do the content-check on the data received. It will mark the port UP/DOWN according to the configuration in the match-list.
If an ICMP mesg is received, then the port will be brought down.
Command Line Interface
There is no new CLI added for this feature. The CLI is the same as that used for scripted health-checks for TCP ports. Previously the CLI was restricted to TCP ports, while now that restriction has been removes.
ServerIron(config)# server real r1 10.10.1.31
ServerIron(config-rs-r1)# port 1234 keepalive
ServerIron(config-rs-r1)# port 1234 content-check m1
ServerIron(config-rs-r1)# port 1234 content-check send "how are you"
ServerIron(config)# http match-list m1
ServerIron(config-http-ml-m1)# up simple good
ServerIron(config-http-ml-m1)# default down
In the above example, ServerIron ADX will send and UDP packet containing the ascii string "How are you". On receiving the reply, ServerIron ADX will search for the string "good". If found, it will mark port 1234 UP, else will mark the port DOWN.
Configuring Server Port Health Check Policy
Server port policies help reduce the configuration required for health checks and provide more flexibility while configuring health checks.
Previously, ServerIron ADX allowed the use of Layer 7 health check parameters for known ports, such as HTTP, LDAP, SMTP, IMP4, POP3, NNTP, Telnet, and FTP, to check the health of unknown ports. For example, a configuration such as the following may be entered:
ServerIron(config)# server port 999
ServerIron(config-port-999)# tcp keepalive protocol smtp
In this release, health checks for SSL, RTSP, MMS, PNM, LDAPS have been added to check the health of unknown ports, using the server port-policy command.
The configuration of server port policies consists of two parts:
Configuring a Port Policy
To configure a port policy, do the following:
1.
ServerIron(config)# server port-policy p1
Syntax: server port-policy <policy-name>
Once the policy is named, the CLI changes to the configuration-port-policy level.
2.
ServerIron(config-port-policy-name)# port 8080
Syntax: ServerIron ADX(config-port-policy-name)# port <port-num>
3.
ServerIron(config-port-policy-name)# http
Syntax: protocol <protocol-value>
If the protocol is not configured, the policy cannot be bound to a real server port.
Enter a TCP or UDP port name or number for <protocol-value>. For TCP ports, enter FTP (port 21), HTTP (port 80), IMAP4 (port 143), LDAP (port 389), LDAPS (port 636), MMS (port 1755), NNTP (port 119), PNM (port 7070), POP3 (port 110), RTSP (port 554), SMTP (port 25), TELNET (port 23)
NOTE: Ports 20 and 21 both are FTP ports but on the ServerIron, the name "FTP" corresponds to port 21.
For UDP ports, enter DNS (port 53) or RADIUS (port 1812)
4.
ServerIron(config)# server port-policy pp1
ServerIron(config-port-policy-pp1)# keepalive-interval 5
Syntax: [no] keepalive-interval <seconds>
See “Configuring a Keepalive Interval Under a Port Policy” for more details.
5.
ServerIron(config-port-policy-name)# retries 5
Syntax: retries <num>
The default is 3 tries.
6.
ServerIron(config-port-policy-name)# protocol http url www.mycompanynet.com
Syntax: protocol <protocol-options>
Enter one of the following for <protocol-options>, specifying the values for the required parameters:
7.
ServerIron(config-port-policy-name)# l4-check
Syntax: l4-check
By default, Layer 7 health check is enabled; however, Layer 4 health check is not. You must enable Layer health check if you want to use that feature.
Binding the Policy
After the policy is configured, return to the configuration level and bind the policy to a real server port. For example:
ServerIron(config)# server real r1 10.10.1.101
ServerIron(config-rs-name)# port <port-num> use-port-policy <policy-name>
Syntax: server real <real-server-name> <real-server-ip-address>
Syntax: [no] port <port-num> use-port-policy <policy-name>
Enter the name of the policy you created for <policy-name>
Once a policy is bound to a real server port, the ServerIron ADX will use the values configured in the policy for health checks.
The ServerIron ADX sends a health check to the port configured in the policy; however, if you do not configure a port number in the policy, then the ServerIron ADX sends the health check to the port to which it is bound.
NOTE: The port policy configuration will take precedence over a port profile.
EXAMPLE 1
ServerIron(config)# server port-policy p1
ServerIron(config-port-policy-p1)# port 8080
ServerIron(config-port-policy-name)# protocol ssl
ServerIron(config-port-policy-name)# retries 5
ServerIron(config-port-policy-name)# exit
ServerIron(config)# server real r1 10.10.1.101
ServerIron(config-rs-r1)# port 1234 use-port-policy p1
ServerIron(config-rs-r1)# port 1234 keepalive
In Example 1, Port 1234 on Real Server 1 will be marked as up if the Layer 7 health check on Port 8080 on the server with the IP address of 10.10.1.101 passes.
EXAMPLE 2:
ServerIron(config)# server port-policy p2
ServerIron(config-port-policy-name)# protocol http
ServerIron(config-port-policy-name)# l4-check
ServerIron(config-port-policy-name)# exit
ServerIron(config)# server real r2 10.10.1.102
ServerIron(config-rs-r1)# port 1234 use-port-policy p2
In the example above, a port has not been configured for "policy p2"; therefore, the ServerIron ADX will use the port to which the policy is bound. Port 1234 of real server r2 will be marked as "UP" if the health check to port 1234 on the 10.10.1.101 Server passes the Layer 4 health-check.
EXAMPLE 3:
In the following example, Port Policy pp1 is configured with a keepalive interval of 5 seconds, while Port Policy pp2 has a keepalive interval of 30 seconds.
Port Policy pp1 is bound to Real Server rs1 port 8080 and Real Server rs2 port 9090; therefore, these two ports have a 5 second keepalive interval.
Port Policy pp2 is bound to Real Server rs3 port 8080 and Real Server rs4 port 9090. These two ports have a keepalive interval of 30 seconds.
ServerIron(config)# server port-policy pp1
ServerIron(config-port-policy-pp1)# keepalive-interval 5
ServerIron(config-port-policy-pp1)# protocol http
ServerIron(config-port-policy-pp1)# protocol http url "GET /abc.html"
ServerIron(config-port-policy-pp1)# retries 3
ServerIron(config-port-policy-pp1)# exit
ServerIron(config)# server port-policy pp2
ServerIron(config-port-policy-pp2)# keepalive-interval 30
ServerIron(config-port-policy-pp2)# protocol http
ServerIron(config-port-policy-pp2)# protocol http url "GET /xyz.html"
ServerIron(config-port-policy-pp2)# retries 2
ServerIron(config-port-policy-pp2)# exit
ServerIron(config)# server real rs1
ServerIron(config-rs-r1)# port 8080
ServerIron(config-rs-r1)# port 8080 use-port-policy pp1
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real rs2
ServerIron(config-rs-r2)# port 9090
ServerIron(config-rs-r2)# port 9090 use-port-policy pp1
ServerIron(config-rs-r2)# exit
ServerIron(config)#server# real rs3
ServerIron(config-rs-r3)# port 8080
ServerIron(config-rs-r3)# port 8080 use-port-policy pp2
ServerIron(config-rs-r3)# exit
ServerIron(config)# server real rs4
ServerIron(config-rs-r4)# port 9090
ServerIron(config-rs-r4)# port 9090 use-port-policy pp2
ServerIron(config-rs-r4)# exit
Configuring a Keepalive Interval Under a Port Policy
You can specify health check keepalive interval from under port-policy definition.
For example:
ServerIron(config)# server port-policy pp1
ServerIron(config-port-policy-pp1)# keepalive-interval 5
Syntax: [no] keepalive-interval <seconds>
Enter 1 - 120 for seconds.
EXAMPLE  
In the following example, real server rs1 port 8080 and real server rs2 port 9090 will have a keepalive interval of 5 seconds. Also, real server rs1 port 8080 and real server rs4 port 9080 will have a keepalive interval of 30 seconds.
ServerIron(config)# server port-policy pp1
ServerIron(config-port-policy-pp1)# keepalive-interval 5
ServerIron(config-port-policy-pp1)# protocol http
ServerIron(config-port-policy-pp1)# protocol http url "GET /abc.html"
ServerIron(config-port-policy-pp1)# retries 3
ServerIron(config-port-policy-pp1)# exit
 
ServerIron(config)# server port-policy pp2
ServerIron(config-port-policy-pp2)# keepalive-interval 30
ServerIron(config-port-policy-pp2)# protocol http
ServerIron(config-port-policy-pp2)# protocol http url "GET /xyz.html"
ServerIron(config-port-policy-pp2)# retries 2
ServerIron(config-port-policy-pp2)# exit
After configuring the policy, bind it to a real server port. (See “Binding the Policy” for details.) For example:
 
ServerIron(config)# server real rs1
ServerIron(config-rs-rs1)# port 8080
ServerIron(config-rs-rs1)# port 8080 keepalive
ServerIron(config-rs-rs1)# port 8080 use-port-policy pp1
ServerIron(config-rs-rs1)# exit
 
ServerIron(config)# server real rs2
ServerIron(config-rs-rs2)# port 9090
ServerIron(config-rs-rs2)# port 9090 keepalive
ServerIron(config-rs-rs2)# port 9090 use-port-policy pp1
ServerIron(config-rs-rs2)# exit
 
ServerIron(config)# server real rs3
ServerIron(config-rs-rs3)# port 8080
ServerIron(config-rs-rs3)# port 8080 keepalive
ServerIron(config-rs-rs3)# port 8080 use-port-policy pp2
ServerIron(config-rs-rs3)# exit
 
ServerIron(config)# server real rs4
ServerIron(config-rs-rs4)# port 9090
ServerIron(config-rs-rs4)# port 9090 keepalive
ServerIron(config-rs-rs4)# port 9090 use-port-policy pp2
Configuring DNS Health Check Method and Values
The keepalive time and number of retries are global parameters. However, you configure the DNS health checking methods and values on an individual server basis. You can set the following types of DNS health checks (none configured by default):
Address-based – The ServerIron ADX sends an address request for a specific domain name. If the server successfully responds with the IP address for the domain name, the server passes the health check.
Zone-based – The ServerIron ADX sends a Source-of-Authority (SOA) request for a specific zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check.
To configure the domain name for address-based DNS health checking, enter the following command:
ServerIron(config-rs-zip)# port dns addr_query "evil.mojo.com"
Syntax: [no] port dns addr_query "<name>"
To configure the zone name for zone-based DNS health checking, enter the following command:
ServerIron(config-rs-zip)# port dns zone mojo.com
Syntax: [no] port dns zone <zone-name>
Configuring RADIUS Health Check Values
You can define the RADIUS parameters that the ServerIron ADX sends to a RADIUS application port in the Layer 7 health check.
The RADIUS health check requests a specific user name, password, and authentication key from the RADIUS server. To specify these values, use one of the following methods.
To configure the parameters for a RADIUS health check, enter commands such as the following at the Real Server level of the CLI:
ServerIron(config-rs-rocket)# port radius username evil
ServerIron(config-rs-rocket)# port radius password woody
ServerIron(config-rs-rocket)# port radius key laser
Syntax: [no] port radius username <string>
Syntax: [no] port radius password <string>
Syntax: [no] port radius key <string>
Dropping Failed RADIUS Health Checks
With a valid response from RADIUS server (that is, user authentication pass or fail), ServerIron marks RADIUS health check as passed. However this may not be desired in some cases. The enhancement below enables ServerIron to mark RADIUS health check if failed authentication is received. (PW_ACCESS_REJECT).
ServerIron(config-rs-rocket)# server radius-fail-healthcheck-on-access-reject
Syntax: [no] server radius-fail-healthcheck-on-access-reject
Changing the LDAP Version
By default, the ServerIron ADX Layer 7 health check for LDAP ports tests for version 3 LDAP. You can change the version to 2 if needed.
To change the LDAP version the ServerIron ADX uses when checking the health of an LDAP port on a real server, enter a command such as the following at the Real Server level of the CLI:
ServerIron(config-rs-rocket)# port ldap 2
Syntax: [no] port ldap <num>
The <num> parameter specifies the version and can be 2 or 3. The default is 3.
Layer 7 Health Check for an Unknown Port
You can use Layer 7 health check parameters for the following known ports to check the health of unknown ports:
TCP ports:
UDP ports:
Configuring an Unknown TCP Port to Use Layer 7 TCP Health Checks
You can use the ServerIron ADX’s Layer 7 health check mechanism for the following TCP applications on any TCP port number:
The health check mechanisms for these ports are described in “Health Checks Overview”.
To configure an unknown TCP port to use the Layer 7 health check for one of the applications listed above, enter commands such as the following:
ServerIron(config)# server port 999
ServerIron(config-port-999)# tcp keepalive protocol smtp
These commands configure port profile parameters for port 999. The second command in the example makes the port a TCP port and assigns the SMTP Layer 7 health check to the port.
Syntax: [no] server port <TCP-portnum>
Syntax: [no] tcp keepalive protocol <TCP-port>
The protocol <TCP-port> parameter specifies the type of Layer 7 health you want to use for the port. You can specify one of the following:
Configuring an Unknown UDP Port to Use a Layer 7 Health Check
The ServerIron ADX can perform Layer 7 health checks on the DNS port (UDP port 53).
To configure an unknown UDP port to use the DNS Layer 7 health check:
Configure the Layer 7 health check on the DNS port (53). For configuration information, see “Configuring DNS Health Check Method and Values”. The unknown port uses the same health check parameters as the ones you configure for the DNS port. For example, if you configure an address-based DNS health check for a specific domain name, the ServerIron ADX requests the same domain name when checking the health of the unknown port.
Create a port profile for the unknown port and specify dns or 53 as the well-known port whose Layer 7 health check you want to use.
To configure an unknown port to use a Layer 7 health check, enter commands such as the following:
ServerIron(config)# server port 999
ServerIron(config-port-999)# udp keepalive protocol dns
Syntax: server port <UDP-portnum>
Syntax: udp keepalive protocol <UDP-portnum>
The protocol <UDP-port> parameter specifies the type of Layer 7 health you want to use for the port. You can specify dns or 53.

Health Checks > Layer 7 Health Checks

Table of Contents Previous Next Print
Copyright © 2009 Brocade Communications Systems, Inc.