Configuring Http Return Code Checking; Understanding Http Return Code Checking - Cisco catalyst 6500 series Configuration Note

Content switching module
Hide thumbs Also See for catalyst 6500 series:
Table of Contents

Advertisement

Configuring HTTP Return Code Checking

Retries are the number of abnormal end sessions that the CSM will tolerate before removing a real server
Note
from service. The failed time is the number of seconds which the CSM waits before reattempting a
connection to a real server that was removed from service by inband health checking.
This example shows how to enable inband health monitoring for a server farm named geo:
Router(config-module-csm)# serverfarm geo
Router(config-slb-sfarm)# health retries 43 failed 160
Configuring HTTP Return Code Checking
These sections describe HTTP return code checking:

Understanding HTTP Return Code Checking

The return error code checking (return code parsing) feature is used to indicate when a server is not
returning web pages correctly. This feature extends the capability of CSM to inspect packets, parse the
HTML return codes, and act upon the return codes returned by the server.
After receiving an HTTP request from the CSM, the server responds with an HTTP return code. The
CSM can use the HTTP return error codes to determine the availability of the server. The CSM can be
configured to take a server out of use in response to receiving specific return codes.
A list of predefined codes (100 through 599) are in RFC 2616. For return code checking, some codes are
more usable than others. For example, a return code of 404 is defined as a URL not found, which may
be the result of the user entering the URL incorrectly. Error code 404 also might mean that the web server
has a hardware problem, such as a defective disk drive preventing the server from finding the data
requested. In this case, the web server is still alive, but the server cannot send the requested data because
of the defective disk drive. Because of the inability of the server to return the data, you do not want future
requests for data sent to this server. To determine the error codes you want to use for return code
checking, refer to RFC 2616.
When HTTP return code checking is configured, the CSM monitors HTTP responses from all balanced
HTTP connections and logs the occurrence of the return code for each real server. The CSM stores return
code counts. When a threshold for a return code is reached, the CSM may send syslog messages or
remove the server from service.
A default action, counting return codes, syslog messaging, or removing the real server from service or a
set of these actions can be applied to a server farm. You also can bind a single virtual group to multiple
server farms allowing you to reuse a single return code server farm policy on multiple server farms.
When you configure HTTP return code checking on a virtual server, the performance of that virtual
Note
server is impacted. Once return code parsing is enabled, all HTTP server responses must be parsed for
return codes.
Catalyst 6500 Series Content Switching Module Configuration Note
9-8
Understanding HTTP Return Code Checking, page 9-8
Configuring HTTP Return Code Checking, page 9-9
Chapter 9
Configuring Health Monitoring
OL-4612-01

Advertisement

Table of Contents
loading

This manual is also suitable for:

Catalyst 6000 series

Table of Contents