Health Checking On Load Balancers

Health Checking On Load Balancers: More
Art Than Science

March 6, 2012 8 Comments
One of the trickiest aspects of load balancing (and load balancing has lots of tricky aspects) is
how to handle health checking. Health checking is of course the process where by the load
balancer (or application delivery controller) does periodic checks on the servers to make sure
theyre up and responding. If a server is down for any reason, the load balancer should detect this
and stop sending traffic its way.
Pretty simple functionality, really. Some load balancers call it keep-alives or other terms, but its
all the same: Make sure the server is still alive.
One of the misconceptions about health checking is that it can instantly detect a failed server. It
cant. Instead, a load balancer can detect a server failure within a window of time. And that
window of time is dependent upon a couple of factors:
Interval (how often is the health check performed)
Timeout (how often does the load balancer wait before it gives up)
Count (some load balancers will try several times before marking a server as down)
As an example, take a very common interval setting of 15 seconds, a timeout of 5
seconds, and a count of 2. If I took a shotgun to a server (which would ensure that its
down), how long would it take the load balancer to detect the failure?
In the worst case scenario for time to detection, the failure occurred right after that last
successful health check, so that would be about 14 seconds before the first failure was
even detected. The health check fails once, so we wait another 15 seconds before the
second health check. Now thats two down, and weve got a server marked as down.

So thats about 29 seconds at a worst case scenario, or 16 seconds on a best case scenario.
Sometimes server administrators hear that and want you to tune the variables down, so
they can detect a failure quicker. However, thats about as low as they go.
If you set the interval for more than 15 seconds, depending on the load balancer, it can
unduly burden the control plane processor with all those health checks. This is especially
true if you have hundreds of servers in your server farm. You can adjust the count down
to 1, which is common, but remember a server would be marked down on just a single
health check failure.
The worst value to tune down, however, is the timeout value. I had a client once tell me
that the load balancer was causing all sorts of performance issues in their environment. A
little bit of investigating, and it turned out that they had set the timeout value to 1 second.
If a server didnt come up with the appropriate response to the health check in 1 second,
the server would be marked down. As a result, every server in the farm was bouncing up
and down more than a low-rider in a Dr Dre video.
As a result, users where being bounced from one server to another, with lots of TCP
RSTs and re-logging in (the application was stateful, requiring users being tied to a
specific server to keep their session going). Also, when one server took 1.1 seconds to
respond, it was taken out of rotation. The other servers would have to pick up the slack,
and thus had more load. It wasnt long before one of them took more than a second to
respond. And it would cascade over and over again.
When I talked to the customer about this, they said they wanted their site to be as fast as
possible, so they set the timeout very low. They didnt want users going onto a slow
server. A noble aspiration, but the wrong way to accomplish that goal. The right way
would be to add more servers. We tweaked the timeout value to 5 seconds (about as low
as I would set it), and things calmed down considerably. The servers were much happier.
So tweaking those knobs (interval, timeout, count) are always a compromise between
detecting a server failure quickly, and giving a server a decent chance to respond as well
as not overwhelming the control plane. As a result, its not an exact science. Still, there
are guidelines to keep in mind, and if you set the expectations correctly, the
server/application team will be a lot happier.
FAQ # 67 How does healthchecking work?
Essentially healthchecking works by requesting something and examining the response.
Healthchecking can be done at different layers of the TCP/IP stack. The higher in the
stack, the better the quality of the healthcheck at determining overall application health.
At Layer 3, LoadMaster can use ICMP Ping. This will send a ping request to the server.
If we receive a ping response, the server is considered healthy. This however only
checks that the server is running, not the application.
At Layer 4, LoadMaster can use TCP Connection. This will attempt to open a TCP
connection to the server on the selected port. If the server completes the TCP
handshake, the server is considered healthy. This checks that the application is at least
accepting connections, but does not check that the application is functioning properly.
At Layer 7, there are a variety of protocol specific healthchecks. These will open a TCP
connection to the server and begin application level communication. Once the server
responds with good data, the server is considered healthy. This checks that the
application is up and functioning properly.
For HTTP and HTTPS healthchecks, you can specify some of the parameters used to
make the request. These parameters are URL, method, version, hostname as well as
additional headers. These parameters are assembled as follows:
< Method> <URL> HTTP/<Version>
If HTTP/1.1 is specified, you can also set the hostname as a header if your server
requires this.
< Method> <URL> HTTP/<Version> Host: <Hostname>
The default healthcheck looks like this:
HEAD / HTTP/1.0
Using the following settings, the healthcheck would look like this:
Method: GET URL: /healthcheck.html Version: 1.1 Hostname: example.com
GET /healthcheck.html HTTP/1.1 Host: example.com
If LoadMaster receives a 200, 301, 302 or 401 status code as a response, the server is
considered healthy. You can get more granular if you specify the method to be GET.
You can then specify a regular expression which is compared to the first 4KB of the
response. If it matches, the server is considered healthy. This feature requires a 200
response code with content to be returned
Health Check
Blackboard recommends monitoring Tomcat, Apache (Linux), and IIS (Windows) for liveliness to ensure
that the load balancer is sending traffic to application servers that are able to handle the traffic.
Health Check Interval
When performing a health check, it is important to set a health check interval that is frequent enough to
maintain the health of the application, but not so frequent that it affects performance. When a health
check fails for a specific application server, the load balancer redistributes the traffic that was bound for
that server to the remaining available servers. This interval should be optimized to ensure that healthy
nodes do not inadvertently fail the health check during a full garbage collection by the JVM. Blackboard
considers intervals such as one minute or .1 seconds as extreme values and recommends that they be
avoided. Blackboard recommends starting with a health check interval of 20 seconds and blocking traffic
to a node after three failures (60 seconds).
Server load balancing for application high-availability

Load balancing is a staple solution in virtually every data center. However, todays application delivery
controllers (ADCs) represent a considerable evolution from simple server load balancing. Arrays 64-bit
multi-core SpeedCore architecture supports massive throughput and millions of concurrent connections
for scaling application availability without impacting application performance.
In addition, integrated traffic management and application acceleration functions including SSL
acceleration, adaptive compression, dynamic caching, connection multiplexing, content routing and
quality-of-service provide unparalleled control over application traffic and the ability to significantly
improve application performance.
For organizations deploying enterprise applications including Microsoft SharePoint, Microsoft Exchange
or SAP, or managed service applications such as eClinicalWorks, Array load balancing solutions have
undergone extensive certification testing and ship with configuration templates and deployment guides
that take the time and guess work out of application delivery.
Available as dedicated appliances, virtualized multi-tenant appliances or virtual load balancers tuned for
VMware and Citrix hypervisors, Array load balancers are equally at home in the data center and the
cloud. Feature parity across platforms and unmatched performance, flexibility and management
integration make Arrays application delivery solutions ideal for public cloud service offerings and private
cloud environments.
Whether you are responsible for a single application or Website, a large Internet property or a public or
private cloud, Array server load balancing delivers the performance, scalability, features and value
essential for accelerating your business.

Big Data Solutions
Cloud Platform
Support & Resources
Get Started
Documentation
Wiki Home
Server Images
Supported OS's
API
Network Devices
Customer Wiki
How To's & Tutorials
API Libraries
API Tools
Support Overview
Knowledgebase
FAQs
System Status
Printable version
Wiki Search

Contents
[hide]
1 Key Features
2 Data Center Availability
3 API
4 Recommended Use
5 Comparison of DLB and GoGrid F5
6 Dynamic Load Balancer
6.1 Load Balancer Algorithm
6.1.1 Weighted Round Robin
6.1.2 Weighted Least Connect
6.1.3 Source Address Hashing
6.1.3.1 Notes on Weighting
6.2 Load Balancer Persistence
6.2.1 None
6.2.2 Session Cookie
6.2.3 IP Subnet
6.3 Health Checker Options
6.3.1 HTTP
6.3.2 Connect
6.3.3 SSL
6.4 Health Checker Responses
6.5 Health Checker Options
6.5.1 Interval
6.5.2 Timeout
6.5.3 Response String
6.6 Listeners
6.6.1 Load Balancer: DLB1, Listener: Web Traffic 1
6.6.2 Load Balancer: DLB1, Listener: Web Traffic 2
6.7 Real IPs (Real Servers)
6.7.1 Weights
6.7.2 External Servers
6.8 VIP
6.9 Monitoring Statistics
7 User Manual
8 Pricing
9 Getting Help
10 Frequently asked Questions

Load balancing is a crucial element to any network that is required to maintain high availability while
gracefully handling sudden spikes in traffic. In the event of a sudden increase in traffic, the load balancers
prevent the web, application, and database servers from becoming overloaded by distributing the traffic
evenly across servers. If a web server fails, the load balancers will divert any traffic away from that server,
maintaining the availability of your website and applications.
GoGrid provides Dynamic Load Balancing (DLB) services using state-of-the-art distributed architecture
that was built from the ground up by our engineering team. Using a unique predictive algorithm, the DLB
distributes traffic across all the real servers based on assigned weights and on the logic used by the
algorithm. Using intelligent health checks, you can monitor all servers in the pool so in the event a server
or the application on the server fails, requests are automatically and seamlessly forwarded to other
servers.
If you are looking for information on our legacy F5 Load Balancers, it can be found here: F5 Load
Balancer
Key Features
Self-healing, distributed architecture
Available for all GoGrid accounts
Our load balancers can be easily provisioned using the management console or API
Multiple algorithms, persistence and health check options
Static IP assigned to the load balancer outside of the customer IP space
Dynamically edit the DLB configurations including server weights for optimal traffic management
Support for X-Forward-For header field standard
Multiple listeners per DLB
Load Balance Any IP (even those outside of GoGrid)
Data Center Availability
Dynamic Load balancers are currently available in our US-West-1, US-East-1, and EU-West-1 data
centers.
API
Use API:GoGrid_Load_Balancer_API_v2 to manage your load balancers.
Recommended Use
The DLB works well for moderate to high web (HTTP) and TCP traffic. It is a low-cost, scalable option that
is also self-healing. This is intended for local load balancing and not global load balancing (DNS based).
Although you can balance any IP address, you may experience latency depending on the location of the
real server. This product does not route traffic to the server closest to the end user - the balance any IP
feature is intended to handle fail-over scenarios. This product is recommended for applications with the
following resource requirements.
Bandwidth requirements of no more than 200 Mbps
Concurrent connections up 1,000
Transactions per second up 1,000
Talk to the Solutions Architects if you have an application that requires a high amount of bandwidth or
large number of concurrent connections.
Comparison of DLB and GoGrid F5

Dynamic Load Balancer
When creating a Dynamic Load Balancer, you will need to create all the associated objects in order for it
function correctly. You will first create and name your DLB, then create and associate a Listener (where
you will configure the algorithm, persistence, and health checker) and the pool of real servers. Since this
is an object model, this means that you can re-use the objects. For example, you have two DLBs in the
EU-West-1 deta center. They both forward HTTP traffic and use the same ports, algorithm and
persistence but just have different real server pools. You only need to define one listener object which
you can associate with the two DLBs. Note that objects are data center specific so you can only re-use
objects in the same data centers.
The DLB will have a Virtual IP (VIP) associated with it that is not one of your GoGrid public IPs. This will
be automatically assigned but only after you associate at least one real server.
The DLB is designed to be highly available, so if the infrastructure that it is running on runs into issues, it
is designed to automatically fail-over. You do not have to configure this. The VIP will remain the same
and all your configurations carry over.
You can imagine the relationship of the objects as detailed below.

NOTE: A maximum of ten load balancers are allowed per data center. File a ticket with support if you
require more.

Load Balancer Algorithm
Weighted Round Robin
Weighted Round Robin load balancing takes all incoming connections and routes them one at a time,
server by server, based on the weight assigned to the server, with each server taking turns. This
algorithm is dynamic, which means server weights may be adjusted on the fly to manage newly spun up
servers, for example. If you have two servers with equal weight, incoming connections will alternate
between them. If you have four servers, and server A has double the weight of the other servers, then
connections will be routed to server A more often than server B, server C, and server D before beginning
the cycle again. This is a good balancing method for routing HTTP traffic or other types of connections
with short durations.
Weighted Least Connect
Weighted Least Connect load balancing will route incoming connections to the server with the lowest
load on it based on the weight assigned to the server. Connections are sent to each server depending on
the total number of concurrent sessions on the servers and the weight. If you have two servers, the first
with 24 sessions running and the second with 12 sessions running, then incoming connections will be
routed to server B until the ratio of connections changes, assuming equal weight on both servers. This
algorithm is dynamic, which means server weights may be adjusted on the fly. Use of this algorithm is
recommended where very long sessions are expected, but is not well suited for protocols using short
sessions such as HTTP.
Source Address Hashing
The source IP address is hashed and divided by the total weight of the running servers to designate
which server will receive the request. This setup ensures the same client IP address will always reach the
same server as long as no server goes down or up. If the hash result changes due to the number of
running servers changing, many clients will be directed to a different server. This may occur when, for
example, the health checker adds or removes servers from a pool. This balancing method can be used to
implement a best-effort, un-guaranteed type of persistence for non-HTTP connections or for HTTP clients
that refuse to set session cookies. If persistence is set to "None", then this means that the association
between the source IP and the real is maintained over time. It is also used when load balancing FTP
traffic or attempting to maintain customer details stored in a particular real server to the same source IP
address.
Notes on Weighting
See Weights under the Real Servers section.
Load Balancer Persistence
Use Persistence if you want to associate a client with a real server. Once persistence information
exists, the load balancer will follow the persistence rule and ignore the algorithm. We offer two
different persistence options - it comes down to a decision of whether you want to persist using the target
(session cookie) or source (IP subnet).
None
None is the default option and will cause the selected algorithm to determine the routing.
Session Cookie
Persist based on server cookie. This option is only valid for Load Balancers with "protocol" set to "http"
and will set persistence based on the destination address. It will only be active for the current session.
You can set the name of the cookie if you want something other than lbcookie.
IP Subnet
Clients in the same /24 IP subnet will be routed to the same server for a limited period of time (over the
previous 30 minutes). This option sets persistence based on source address and is the only persistence
method you can use if you cannot accept cookies (such as if you sending TCP traffic). Note that the
persistence is based on the subnet and not a specific IP address.
Health Checker Options
The Health Checker is used to determine the health of the real servers. If the test against the server fails,
the server is assumed to be unavailable and is moved out of rotation. If the next test is successful, the
server is then put back into the rotation. In the management console, servers who have failed health
checks are marked in red while successful checks are in green. You can associate one health checker
per Listener.
HTTP
This test verifies that the web server is responding. It checks both the port and the path specified in the
health check. Specify this under "URI" (the default is /). You can also specify the hostname of the web
server if you want to use HTTP 1.1. If this is left blank, then it will use HTTP 1.0. This option works well for
regular non-encrypted traffic if you select the HTTP protocol.
Connect
This test is for a successful IP connection. It does not use the Health Checker parameters (such as the
path and hostname) because it is only checking the port. This is a good choice for non-web servers such
as databases or email. You can use this if you select the TCP protocol.
SSL
This test is for an SSL connection on the real server. It verifies that clients can open an encrypted
connection to the server, but not that the server is returning correct results (such as successfully serving
web pages). It does not use the Health Checker parameters (such as the path and hostname) because it
is only checking the port. Use this option if youre doing SSL pass-through (protocol set to TCP and
sending encrypted traffic).
Health Checker Responses
The Health Checker tracks responses from the real servers. On the management console, this is
represented by "traffic lights": green means a positive response and the real server is able to send and
receive traffic, yellow means an unknown response and the real server may or may not send or receive
traffic, and red means that the real server is in error and has been pulled out of the pool. There are also
specific codes returned that are visible on hover.

UNK - unknown
INI - initializing
L7OKC - check conditionally passed on layer 7, for example 404 with disable-on-404
L4OK - check passed on layer 4, no upper layers testing enabled
L6OK - check passed on layer 6
L7OK - check passed on layer 7
SOCKERR - socket error
L4TOUT - layer 1-4 timeout
L4CON - layer 1-4 connection problem, for example "Connection refused" (tcp rst)
L6TOUT - layer 6 (SSL) timeout
L6RSP - layer 6 invalid response - protocol error
L7TOUT - layer 7 (HTTP/SMTP) timeout
L7RSP - layer 7 invalid response - protocol error
L7STS - layer 7 response error, for example HTTP 5xx

NOTE: If you have more than one listener against a real server pool, if only one health checker reports a
failure that real server is out of the pool.
Health Checker Options
Users can also configure other options on the health checker. These options determine the behavior of
the health checker. Note that if you are also using the API, that code uses milliseconds, whereas the
management console presents the value in seconds.
Interval
The interval is how long the health checker will wait after it receives a response from the real servers. The
default is every 10 seconds, but you can go as low as 4 seconds and as high as 300 seconds.
Timeout
The timeout setting is how long the health checker will wait for a response from a real server before
considering it "failed." The default is 5 seconds, but you can go as low as 2 seconds and as high as 60
seconds. If you set your timeout above the interval you'll increase the variance of the health check.
Response String
You can enter a string that you are expecting to see in the body of a response from the real server. This
option is only available when the Health Checker is set to "HTTP". This is often used if you have specific
text in the bottom of a page and you only want to consider the real server "healthy" if the page fully
renders. If you do not enter a value here, then the health checker will use its default behavior, which is to
run a GET against the specified URI. This field will only accept up to 100 characters.

Example: The default setting is Interval = 10 and Timeout = 5. This means that the health checker
request frequency will vary from 10.1 to 15 seconds. If your real servers are performing optimally, then
you will see a majority of health checks go out in 10 second intervals. If you set the Interval = 5 and
Timeout = 10 then the health checker frequency will vary from 5.1 to 15. In this scenario, if the real server
takes as long as 10 seconds to respond, the next health check will not go out until 5 seconds after that
response (or 15 seconds total time elapsed).
Listeners
Dynamic Load Balancers are designed to allow for multiple ports on the VIP. A common use case is to
load balance both standard web traffic (on port 80) and encrypted web traffic (on port 443) on the same
VIP. GoGrid achieves this by allowing multiple listeners to be attached to the VIP. The design of the DLB
is to have one VIP associated with one pool of real servers. Therefore, you can add as many listeners as
you want but they will always be tied to the same DLB / Real Server pool. If you need to send traffic on a
different port to a different pool of real servers, then create another DLB (and therefore another VIP). The
DLB support the following protocols (you are able to change the ports that you want to use):

HTTP (defaults to port 80) - Used for Layer 7 web traffic
TCP - Used for Layer 4 TCP traffic

The algorithm and health checks are tied to the listener. Therefore it is possible to have different
algorithms on the same VIP if you have more than one listener. This, however, is not recommended since
you will have a disparate traffic pattern to your real server pool. In addition, the weights on the real
servers will always be the same regardless of the listener so you may not have the proper traffic pattern if
you have disparate algorithms.
Note that you must associate a health check object before you can deploy a listener. It is likely that you
will have different health checks, depending on the ports that you added. For example, this a typical setup
for balancing both encrypted and non-encrypted traffic on the same VIP using two listeners and three real
servers.
DLB: DLB1
Listener: Web Traffic 1
Protocol: HTTP
Listener Port: 80
Real Port: 80
Algorithm: Weighted Round Robin
Persistence: None
Health Checker Type: HTTP
URI: /index.html
Real IPs: 240.30.248.145, 240.30.248.146,
143.168.230.5
DLB: DLB1
Listener: Web Traffic 2
Protocol: TCP
Listener Port: 443
Real Port: 443
Algorithm: Weighted Round Robin
Persistence: None
Health Checker Type: SSL
URI: [N/A]
Real IPs: 240.30.248.145, 240.30.248.146,
143.168.230.5
Load Balancer: DLB1, Listener: Web Traffic 1
All un-encrypted traffic is forwarded from port 80 to the real servers port 80. You can select any real port
you want but they must be consistent across the real server pool. You will have full Layer 7 capabilities
including seeing the client IP and setting cookies. Using the Weighted Robin Robin Algorithm along with
the HTTP health check is fairly common for this type of load balancing.
Load Balancer: DLB1, Listener: Web Traffic 2
All encrypted traffic is forwarded from port 443 to the real servers port 443. You can select any real port
you want but they must be consistent across the real server pool. Note that this is load balancing the
encrypted traffic only and then passing it through to the real servers. You will need to add the certificates
to the web servers in order to decrypt the traffic. You will not have all load balancing options available to
you since this is technically load balancing at Layer 4. You will not be able to see the client IP or persist
using server cookies (which means your only persistence options are "None" or "IP Subnet"). Since this is
the second listener on the same load balancer, you should keep the algorithms consistent (i.e. use
Weighted Round Robin like in Listener 1). If you intend to send encrypted pass through traffic, you
MUST use SSL as the health check since that is the only one that can check if the port is
responding to encrypted traffic.
In general, most users will add real servers that are in the same data center as the load balancer. It is
possible to add servers from other GoGrid data centers or even other service providers. You will be
charged a per GB fee for load balancing non-GoGrid IPs. You may experience higher latency when you
take advantage of the option to add IPs outside of the same data center as the load balancer.

NOTE: Even though 'Web Traffic 2' is sending encrypted traffic, this is NOT SSL termination! The DLB
currently supports SSL pass-through at Layer 4. Encrypted traffic is load balanced but will need to be
decrypted on the real servers (add the certificates on the real web servers).
Real IPs (Real Servers)
Real IPs are the servers that you place behind the load balancer. They are typically clones so that the
load balancer can distribute traffic across all the servers in the pool and return the same response (the
same web page in the case of web servers).
You can add, edit and delete real servers from the pool in the management console and via the API. You
will not need to delete the load balancer in order to edit its functionality. In addition, you can also alter the
weight applied to each of the servers in the pool - this will dynamically alter the behavior of your load
balancer traffic (except for source hash which is static). In the design of the DLB, you have to create a
"Real IP" object if you want a server to be balanced by the DLB. Once you create the object on the Real
IP page - it becomes a selectable object on the VIP page. Deleting the Real IP object DOES NOT delete
the underlying server.
It is important to note that the DLB is designed to have one pool of real servers for each VIP. It is NOT
per listener. If you need a different pool of servers for a port that is not yet defined, then deploy a new
DLB.
Weights
In addition, you can assign weights to each of the real servers. This is an important feature since it
impacts the behavior of the algorithm that you select. All our algorithms use weighting. You can enter a
value between 1-255 as a weight. The higher the number, the higher the weight. Thus a server with 200
has twice the weight of servers marked as 100. The algorithm will distribute traffic based on the weights
assigned. Note that the weight is tied to the server so it will maintain that weight regardless of which load
balancer it is associated with. Take this into account when re-using real servers across load balancers.
For example, if there are two servers"A" with weight 2 and "B" with weight 1then the algorithm will
choose "A" 2/3 (66%) of the time and select "B" 1/3 (33%) of the time. The order in which the servers are
selected is unspecified and subject to change, so no particular pattern should be expected or counted on.
The management console has a feature that displays the % weight of a particular server relative to the
other servers in the pool.
If you want the servers to be treated equally by the algorithm, assign them the same weight (like 100). In
the case of weighted round robin, this will cause the load balancer to behave like a static round robin
algorithm, sending requests to each server in turn.

External Servers
The DLB has the option of adding external Servers to the real server pool. This is typically used as a fail-
over or backup solution. You will be charged a fixed rate for traffic that travels from this server to the DLB.
Depending on the location of that server, you may also experience higher latency. This is not something
that GoGrid has control over and so we offer no SLA on performance of these servers. Note that you may
also be charged outbound transfer from the provider where that server resides. This could result in high
overall transfer charges.
When you enter an external IP address for the first time as a Real IP object, it may take up to 15 seconds
for the system to properly identify it as "Non GoGrid". It will initially show as GoGrid but wait for 15
seconds and it should update.
VIP
The VIP page is where the DLB is defined. This is also where you can manage the pool of real servers.
Add and remove the real servers that you want in your pool. Note that only servers that have been
defined as a Real IP object will be visible here. Once you have defined the DLB and added at least one
Real IP then a VIP will be assigned to the load balancer.
As stated earlier, VIPs can point to one only pool of servers regardless of how many listeners are
attached. This means that all listener traffic will forward to same pool of real servers. In the listener
example above, this means that port 80 (i.e. Listener1) and port 443 (i.e. Listener2) all forward to the
same real servers. If you need a port to forward to a different set of real servers, then create another
DLB.
Monitoring Statistics
GoGrid also provides monitoring statistics for Dynamic Load Balancers via the API and through the
management console. The following statistics are available by previous hour, day, week, month and year:

Traffic per sec inbound and outbound - Avg. Bytes per second inbound and outbound
Queue Depth - Current queued requests. This is often 0 since requests are processed immediately
or timeout.
Request rate - Number of sessions per second over last elapsed time period
Current sessions - Current number of sessions for a time period
Count of failed health checks - Count of health checks that result in error. Does not include
timeouts.
Responses by HTTP code - Response by 1XX to 5xx
User Manual
See the Dynamic Load Balancer User Manual for instructions on deploying a load balancer.
Pricing
Current pricing for the DLB can be found on the GoGrid website.
Getting Help
See our Support page for information on contacting GoGrid for any questions or issues that arise.
Frequently asked Questions
How can I access the Dynamic Load Balancers?
The GoGrid Dynamic Load Balancers are accessible via the management portal or the API in all our data
centers.

Can I load balance my GoGrid servers that are protected by a GoGrid Firewall?
Yes, load balancing can be configured for servers protected by a GoGrid firewall. To ensure security in
this setup, only servers behind the Firewall will be protected by the Firewall. Other real servers will still be
load balanced.

Can I load balance between servers in US-East-1, US-West-1 and EU-West-1?
Yes, this is possible although you will most likely experience latency. This is NOT global load balancing.

How is this related to CloudLink?
It is not. CloudLink is used to privately connect servers between the US-West-1 and US-East-1 data
centers. The DLB is used to load balance public internet traffic.

Can I load balance between dedicated servers?
Yes, you can load balance virtual or dedicated servers.

When I delete a server, does the load balancer need to be edited to remove the IP address from
the pool?
Assuming that you have enabled the health check, if a server is deleted it will return as unhealthy. It will
be removed from rotation so it will no long return responses but it will not be removed from the pool.

Can I load balance on more than one port on the DLB?
Yes, the DLB supports that feature. You can configure multiple ports (such as 80 and 443) on the same
DLB (thus allowing for the same VIP for both ports) which will then be forwarded to the pool. You can
configure the real port to any port you wish but it will have to be the same port of all the reals.

What is the default response timeout and health check interval settings on the health checker?
Both are set to two seconds.

Will I be able to see the originating IP or only the VIP?
Yes, the DLB supports the X-Forward-For header field standard. You can expect to be able to see the
originating IP of the client (and not the VIP) assuming you set the protocol to HTTP. However, this is not
supported if Keep Alive is enabled on the web server. If you require Keep Alive, you will not be able to
use X-Forward-For. X-Forward-For is also not available when the protocol is set to TCP (since this is
Layer 4).

I love each of my severs equally. How do I make sure that they each get a chance to serve up
traffic?
Set the weight of all your real servers to the same number. This will give them an equal weight so if you
select the round robin algorithm, this will operate more like a static round robin and each server will
respond in turn.

What if I want to do "Global Load Balancing"? Can I use this product?
The DLB is local load balancing. It does not take into account the distance from the client to the the real
server which is more of a characteristic of global load balancing. Check with the Solutions Architects for
their suggestions if you require global load balancing.

I have multiple GoGrid accounts, can I load balance server across those accounts?
Yes. You can deploy a load balancer in one of your accounts and define real servers from your other
GoGrid accounts as "external" servers.

What is this object id field and why can't I edit it?
The DLB is based on an object model so every record that you are creating is a unique object. The object
id is generated by the system and the field is there just in case you need to reference the object via the
API. You use the object id in the URI and NOT the name field. The object id cannot be changed once
created although you can change the name field as much as you like.

How will I be billed for this service?
The DLB uses two factor billing. You are billed for the amount of time that you have a DLB deployed and
for any outbound traffic that travels through the DLB. Traffic billing is a surcharge to your existing
outbound traffic charges except in the case of external IPs in which you are charged a fixed rate that is
independent of your outbound traffic charges. Note that you will still be charged for the DLB even if it is
disabled. You must delete the DLB in order to stop billing.

Can I add an external real server with an IPv6 address?
Currently no. The DLB can only accept IPv4 addresses.

I'm using Nginx as my webserver and I can't see my content from the load balancer.
If you can see your content by going to your webserver directly, you may not have set up a virtual
hostname. This is required for Nginx.

One of my real servers has been restarting and although it is taken out of the pool, it doesn't seem
to show up as a failure in the statistics.
The failure count statistic does not include timeouts. Although the DLB will take real servers that return a
timeout out of the pool, it does not record that as a failure.

Search
Sign in
Contact sales or Try it now
Why Google
Products
Solutions
Customers
Developers
Support
Partners
Easy, No-Fuss, Cost-Effective: Google
Compute Engine Load Balancing In
Action
How You Can Use Compute Engine Load Balancing to Unleash Your Apps Potential
Introduction
If you use Google products such as Search, AdWords, or Gmail, you will know that
Google is committed to performance, scale, and robustness. Compute Engine Load
Balancing is built on top of the same load balancing technology that is central to these
products.
Compute Engine Load Balancing has the following advantages :
Easy to set up and maintain Configure the load balancer via the command line
interface or a programmatic RESTful API, then take load balancing off your mind, and let
Google manage it
Load-balanced within a zone or across zones within a region Make your app
robust by exposing one IP for VMs running in more than one zone
Stable performance from the start No pre-warming of the load balancing service is
required
Able to route around unhealthy instances Configure your health checks and let
Compute Engine Load Balancing take care of the rest
Enabled with lame-duck mode Easily upgrade your app without cutting off existing
user connections, and be ready for maintenance windows: unhealthy backends will not
receive new traffic, and existing connections are not interrupted
Affordable Save yourself not only the headache of maintaining load balancing, but
also decrease your costs as well
Load Balancing on Compute Engine
Load balancing is an essential component when scaling any service. There are various
hardware and software load balancing options available. If you are running a service on
Google Compute Engine, several of these options are open to you. The simplest
approach, which does not require any software or hardware setup, is to use the Round-
robin Domain Name System (DNS), a technique by which a single domain name is used
to address multiple IP addresses. One significant drawback, however, is that clients,
such as a web browser, may cache the DNS entry, and continue to send traffic to
unhealthy servers.
Another approach is to use open source software such as HAProxy or Nginx. These
open source projects may offer some additional features, but require both hardware and
software setup and management. This may result in increased installation,
configuration, and upgrade costs in addition to the introduction of a single point of
failure.
Compute Engine Load Balancing helps eliminate these drawbacks and requirements by
offering load balancing as a distributed service that is seamlessly integrated with
Google Cloud Platform. Compute Engine Load Balancing runs as a service that is fully
managed by Google. There is no need to run a load balancer on Compute Engine
instances, and there is no need to worry about keeping load balancing up and running
or routing around unhealthy backends. Compute Engine Load Balancing takes care of
all of this.
Figure 1 illustrates the load balancing concepts in the context of Googles Compute
Engine Load Balancing. Users will send requests to the app running on Compute
Engine via Compute Engine Load Balancing, avoiding those instances that are
unhealthy.
Figure 1: Compute Engine Load Balancing concepts. User requests are sent through Compute
Engine Load Balancing and are spread among healthy backends.
Benefits of Using Compute Engine Load Balancing
1. Easy to set up and maintain
Configuring your app to use Compute Engine Load Balancing is easy and can be done
either via command line or via the Cloud Console UI. Either way, you start by having a
number of instances running application logic on Compute Engine. As an example, we
set up four instances with Apache web server backends (www-0, www-1, www-2,
and www-3). Load balancing was enabled on these four instances with the following
three commands (where $ZONE0 and $ZONE1 are zones in your $REGION):
gcutil --project=<your-project-id> addhttphealthcheck basic-check

gcutil --project=<your-project-id> addtargetpool www-pool --region=$REGION
\
--instances=$ZONE0/instances/www-0,$ZONE0/instances/www-1,\
$ZONE1/instances/www-2,$ZONE1/instances/www-3 --health_checks="basic-
check"

gcutil --project=<your-project-id> addforwardingrule www-rule \
--region=$REGION --port_range=80 --target=www-pool
Each forwarding rule will expose an external IP address, which you can find by
executing the following command:
gcutil --project=<your-project-id> listforwardingrules
Thats it! Clients will access the application with the externally facing IP and through
Compute Engine Load Balancing. Setting up Compute Engine Load Balancing is as
simple as that, and there is no need to maintain anything.
If you prefer a web interface, you can set up target pools, forwarding rules, and health
checks with Googles Cloud Console as shown in figure 2.
Figure 2: Setting up load balancing in the Cloud Console.
Both the command line and the UI allow users to set up more advanced features such
as backup pools and session stickiness. For more information on setup options, please
refer to the full documentation.
2. Load-balanced within a zone or across zones within a region
Compute Engine Load Balancing spreads load roughly evenly between all instances
that it balances. Figure 3 demonstrates how evenly Compute Engine Load Balancing
spread 500,000 requests to the externally-facing IP exposed by the load balancer. For
any real-world system, load spreading becomes increasingly necessary as the load
increases.
Figure 3: Load spread for
a total of 500,000 requests sent in 100 parallel threads.
[1]

3. Stable performance from the start
We now compare the average response time for querying backends directly to the
response time for querying backends through Compute Engine Load Balancing.
Number of
requests
Average
response
time (in
ms) for
requests to
Average
response
time (in
ms) for
requests
Average
response
time (in
ms) for
requests
Average
response
time (in
ms) for
requests
one
backend
directly
through
Compute
Engine
Load
Balancing
with one
backend
through
Compute
Engine
Load
Balancing
with four
backends
through
Compute
Engine
Load
Balancing
with four
backends
across two
zones
1,000,000
100.9
(median:
100.0)
101.0
(median:
100.0)
98.89
(median:
98.00)
100.7
(median:
98.0)
Table 1: Response times for addressing a backend directly (100 parallel requests to a
single instance) vs. through Compute Engine Load Balancing (100 parallel requests to
one and four).
[2]

As table 1 shows, Compute Engine Load Balancing introduces no perceptible latency
compared to the latency that exists when addressing a backend directly. Furthermore, it
scales to more than one backend without introducing additional latency. Note that we
took great care to ensure that the results were isolated as much as possible from
outside factors that can influence the response time. Factors such as congestion on the
originating system and network latency between the originating network and Googles
network could significantly affect response times.
Compute Engine Load Balancing allows target pools to define a set of instances that
span zones within a region. This is designed to make it easy to design robust systems.
When one of the zones goes down, the load balancer will simply route around the
instances in that zone, which at that point are considered unhealthy. In this section, we
will take a look at the performance of the load balancer when instances are spread
across zones. In our example, we have four instances, where two are in us-central1-a
and two are in us-central1-b. The four instances are configured to be in the same
target pool of a single forwarding rule. The rightmost column in table 1 shows how the
average response time continues to be stable even when the load balancer spreads the
responses among instances in two different zones.
Note that this stability across zones is also a very important feature for backup pools.
Backup pools are designed to make an app more robust in the case of a partial or
complete failure of a primary target pool, and they can be in a different zone from the
primary pool. The stable response time shown above also implies that the user
experience will not suffer when traffic needs to be sent to a backup pool of VMs.
Compute Engine Load Balancing shows stable performance right from the start. In this
section, we again used 100 threads to send a total number of 1,000,000 requests. We
show how the response time stays stable under this load in figure 4. The y-axis show
the response time, and each dot on the graph represents a single request. Note how the
response time is stable right from the beginning. Unlike many other solutions, with
Compute Engine Load Balancing, there is no need to pre-warm the load balancer.
Figure 4: Response time for 1,000,000 requests (100 parallel threads) to four backends through
Compute Engine Load Balancing.
[3]

4. Able to route around unhealthy instances
Compute Engine Load Balancing seamlessly routes around unhealthy instances. Using
the health checks you configure, the load balancer detects any unhealthy backends and
routes traffic to the remaining backends. Figure 5 shows the load spread across
instances before and after an instance goes down. ~500,000 requests were sent before
and after backend www-0 was taken out of rotation. Each data point in the graph
represents the number of requests handled by one specific backend during a single
minute. If the instance goes into lame-duck mode (described in more detail below),
existing connections to that backend will still be handled until the backend is ready to be
shut down, and no requests will time out.
While you focus on bringing your backend instances back to a healthy state, Google
focuses on ensuring that the quality of your users experience is maintained.
Figure 5: Load spread when Compute Engine Load Balancing is handling an instance that
becomes unhealthy.
[4]

5. Enabled with lame-duck mode
Compute Engine Load Balancing supports lame-duck mode, which allows system
administrators to take a VM out of the target pool while not interrupting the service. To
take a VM out of rotation, configure it to respond negatively to health checks. New traffic
will not be routed to that VM, and existing connections will not be interrupted. For the
best user experience, the VM can then be monitored for existing connections before
being shut down.
This feature is useful in various scenarios. One scenario where this feature is
particularly useful is with application updates. When a new version of the application
becomes available, VMs are often upgraded in a rolling fashion one VM is taken out of
rotation at a time, updated, and brought back into rotation. Many management tools
such as Chef and Puppet can be configured to work this way.
Another use case where the lame-duck mode is useful is when there is a need to deal
with maintenance windows effectively. As a maintenance window approaches, more
VMs can be created (and added to the target pool) in a zone that will not go into a
maintenance window. Those VMs that are about to be shut down can again be removed
gracefully: if they respond to health check with unhealthy signals, existing connections
will not be interrupted, but no new traffic will be sent to those VMs. The same concept
also applies to cases where the application fails over to a backup target pool (because a
sufficient portion of the VMs in the primary pool have become unhealthy). In that case,
existing connections will be kept alive to VMs in the primary pool, while all new
connections will be sent to the backup target pool.
The documentation contains additional details about the lame-duck mode. For any
system that sets up Compute Engine Load Balancing, enabling the lame-duck mode is
highly recommended in order to optimize the user experience.
6. Affordable
Compute Engine Load Balancing is very affordable. This can mean substantial cost
savings when compared to running a set of VM instances for load balancing. For
instance, if you run two instances on Compute Engine with load balancing software on
n1-standard-2-d instances (mid-tier general purpose instances, with one available for
failover), you would currently pay $4642.80 per year for the instances alone, not
counting network traffic costs. Compute Engine Load Balancing would be significantly
more affordable at the current pricing, Compute Engine Load Balancing would cost as
little as $219 per year. This is about a 95% savings! Even if you choose to run smaller
instances, your savings can be substantial (see table 2).

Two f1-
micro
instances
dedicated
to load
balancing
software
Two g1-
small
instances
dedicated
to load
balancing
software
Two n1-
standard-2
instances
dedicated
to load
balancing
software
Compute
Engine
Load
Balancing
Cost per
year
$332.88 $946.08 $4029.60 $219
Table 2: Potential cost savings for using Compute Engine Load Balancing in a US
region.
[5]

Is Your App a Good Fit for Compute Engine Load Balancing?
Any application that requires scaling to more than one instance can benefit from
Compute Engine Load Balancing. We describe two scenarios here to guide you through
your application architecture design:
1. Web Application on Compute Engine with Logged-in Users
The first common scenario is a web application with logged-in users. One example is an
app where users can log on, author content, and share this content with other users.
Other users may simply log on and consume the content that has been produced by
others. Figure 6 shows a sketch of an architecture for a typical use case.
Figure 6: Web application using Compute Engine Load Balancing.
Most web applications require that session information be stored. For our example, a
users current session information may be any authored content that is not yet saved. A
commonly used and robust architecture is one that stores session information server-
side in the following ways:
Persistently in a database
Transiently in a high-speed cache for improved responsiveness
In the default setting, requests sent through Compute Engine Load Balancing from the
same client IP are not sticky to any backend and are, in fact, spread over all instances.
Compute Engine Load Balancing can be configured to be sticky
[6]
to a particular
backend from any given client IP. This can further improve performance, as session
information will not have to be retrieved frequently. The lame-duck mode of Compute
Engine Load Balancing allows for seamless, rolling upgrades of the application software
by taking instances out of rotation. Future versions of Compute Engine Load Balancing
will further strengthen this use case as we will continue to expand its capabilities. It will
include such features as SSL termination at the load-balancer and Layer-7 load
balancing.
2. Intensive Processing on Compute Engine
The second scenario is an application that performs long-running or intensive
processing in response to user requests (see figure 7). In this scenario, each user
request requires some processing on one or more Compute Engine instances. The
processing could involve Optical Character Recognition (OCR), video transcoding, a
MapReduce job, and more.
Figure 7: Backend processing application using Compute Engine Load Balancing.
Compute Engine Load Balancing lends itself particularly well to this example if the
requests are of similar cost and duration. The backend VMs do not carry session state,
but instead perform a one-off task. The load balancer can pick any backend VM to
perform each of these tasks, and load balancing can effectively spread the workload
among the backends.
Conclusion
In this paper we explained the advantages that load balancing can bring to applications,
including how easy it is to set up and configure and that it shows consistent
performance from the beginning. We also explained how Compute Engine Load
Balancing provides reduced maintenance and reduced costs when compared with those
of 3rd party load balancers.
The first version of Compute Engine Load Balancing is a good fit for many use cases,
such as web applications and intensive processing as described earlier. But this is only
the beginning. In future releases, we plan to include such features as SSL termination
and Layer-7 load balancing. These features will bring you additional benefits such as
flexibility in balancing techniques. You can then create a highly scalable, load-balanced
web site with very little administrative overhead.

[1] The results reported here are based on an experiment averaging over 500,000
requests. The experiment was done in a controlled testing environment set up within the
Google network and is intended only to be an illustrative example.
[2] The latencies reported here are based on an experiment averaging over 1,000,000
requests. The experiment was done in a controlled testing environment set up within the
Google network and is intended only to be an illustrative example.
[3] The latencies reported here are based on an experiment of 1,000,000 requests. The
experiment was done in a controlled testing environment set up within the Google
network and is intended only to be an illustrative example.
[4] The results reported here are based on an experiment of 1,000,000 requests. The
experiment was done in a controlled testing environment set up within the Google
network and is intended only to be an illustrative example.
[5] Please refer to the Compute Engine Pricing page for the most up-to-date information
both for Compute Engine Load Balancing and for Compute Engine instance charges.
The estimate for Compute Engine Load Balancing includes hourly charges at the US
rate as of November 2013. Bandwith charges will be additional. During the promotional
pricing period until January 2014, use of Compute Engine Load Balancing will be free of
charge.
[6] Please see the documentation for further details.

index
modules |
next |
previous |
boto v2.27.0
An Introduction to botos Elastic Load Balancing
interface
This tutorial focuses on the boto interface for Elastic Load Balancing from Amazon Web
Services. This tutorial assumes that you have already downloaded and installed boto,
and are familiar with the boto ec2 interface.
Elastic Load Balancing Concepts
Elastic Load Balancing (ELB) is intimately connected with Amazons Elastic Compute
Cloud (EC2) service. Using the ELB service allows you to create a load balancer - a DNS
endpoint and set of ports that distributes incoming requests to a set of EC2 instances.
The advantages of using a load balancer is that it allows you to truly scale up or down
a set of backend instances without disrupting service. Before the ELB service, you had
to do this manually by launching an EC2 instance and installing load balancer software
on it (nginx, haproxy, perlbal, etc.) to distribute traffic to other EC2 instances.
Recall that the EC2 service is split into Regions, which are further divided into
Availability Zones (AZ). For example, the US-East region is divided into us-east-1a, us-
east-1b, us-east-1c, us-east-1d, and us-east-1e. You can think of AZs as data
centers - each runs off a different set of ISP backbones and power providers. ELB load
balancers can span multiple AZs but cannot span multiple regions. That means that if
youd like to create a set of instances spanning both the US and Europe Regions youd
have to create two load balancers and have some sort of other means of distributing
requests between the two load balancers. An example of this could be using GeoIP
techniques to choose the correct load balancer, or perhaps DNS round robin. Keep in
mind also that traffic is distributed equally over all AZs the ELB balancer spans. This
means you should have an equal number of instances in each AZ if you want to equally
distribute load amongst all your instances.
Creating a Connection
The first step in accessing ELB is to create a connection to the service.
Like EC2, the ELB service has a different endpoint for each region. By default the US
East endpoint is used. To choose a specific region, use the connect_to_region
function:
>>> import boto.ec2.elb
>>> elb = boto.ec2.elb.connect_to_region('us-west-2')
Heres yet another way to discover what regions are available and then connect to one:
>>> import boto.ec2.elb
>>> regions = boto.ec2.elb.regions()
>>> regions
[RegionInfo:us-east-1,
RegionInfo:ap-northeast-1,
RegionInfo:us-west-1,
RegionInfo:us-west-2,
RegionInfo:ap-southeast-1,
RegionInfo:eu-west-1]
>>> elb = regions[-1].connect()
Alternatively, edit your boto.cfg with the default ELB endpoint to use:
[Boto]
elb_region_name = eu-west-1
elb_region_endpoint = elasticloadbalancing.eu-west-
1.amazonaws.com
Getting Existing Load Balancers
To retrieve any exiting load balancers:
>>> conn.get_all_load_balancers()
[LoadBalancer:load-balancer-prod, LoadBalancer:load-balancer-
staging]
You can also filter by name
>>> conn.get_all_load_balancers(load_balancer_names=['load-
balancer-prod'])
[LoadBalancer:load-balancer-prod]
get_all_load_balancers returns a boto.resultset.ResultSet that
contains instances of boto.ec2.elb.loadbalancer.LoadBalancer, each of
which abstracts access to a load balancer. ResultSet works very much like a list.
>>> balancers = conn.get_all_load_balancers()
>>> balancers[0]
LoadBalancer:load-balancer-prod
Creating a Load Balancer
To create a load balancer you need the following:
1. The specific ports and protocols you want to load balancer over, and what
port you want to connect to all instances.
2. A health check - the ELB concept of a heart beat or ping. ELB will use this
health check to see whether your instances are up or down. If they go
down, the load balancer will no longer send requests to them.
3. A list of Availability Zones youd like to create your load balancer over.
Ports and Protocols
An incoming connection to your load balancer will come on one or more ports -
for example 80 (HTTP) and 443 (HTTPS). Each can be using a protocol - currently,
the supported protocols are TCP and HTTP. We also need to tell the load balancer
which port to route connects to on each instance. For example, to create a load
balancer for a website that accepts connections on 80 and 443, and that routes
connections to port 8080 and 8443 on each instance, you would specify that the
load balancer ports and protocols are:
80, 8080, HTTP
443, 8443, TCP
This says that the load balancer will listen on two ports - 80 and 443. Connections
on 80 will use an HTTP load balancer to forward connections to port 8080 on
instances. Likewise, the load balancer will listen on 443 to forward connections to
8443 on each instance using the TCP balancer. We need to use TCP for the HTTPS
port because it is encrypted at the application layer. Of course, we could specify
the load balancer use TCP for port 80, however specifying HTTP allows you to let
ELB handle some work for you - for example HTTP header parsing.
Configuring a Health Check
A health check allows ELB to determine which instances are alive and able to
respond to requests. A health check is essentially a tuple consisting of:
Target: What to check on an instance. For a TCP check this is comprised of:
TCP:PORT_TO_CHECK
Which attempts to open a connection on PORT_TO_CHECK. If the
connection opens successfully, that specific instance is deemed healthy,
otherwise it is marked temporarily as unhealthy. For HTTP, the situation is
slightly different:
HTTP:PORT_TO_CHECK/RESOURCE
This means that the health check will connect to the resource /RESOURCE
on PORT_TO_CHECK. If an HTTP 200 status is returned the instance is
deemed healthy.
Interval: How often the check is made. This is given in seconds and defaults
to 30. The valid range of intervals goes from 5 seconds to 600 seconds.
Timeout: The number of seconds the load balancer will wait for a check to
return a result.
Unhealthy threshold: The number of consecutive failed checks to deem the
instance as being dead. The default is 5, and the range of valid values lies
from 2 to 10.
The following example creates a health check called instance_health that simply
checks instances every 20 seconds on port 80 over HTTP at the resource /health
for 200 successes.
>>> from boto.ec2.elb import HealthCheck
>>> hc = HealthCheck(
interval=20,
healthy_threshold=3,
unhealthy_threshold=5,
target='HTTP:8080/health'
)
Putting It All Together
Finally, lets create a load balancer in the US region that listens on ports 80 and
443 and distributes requests to instances on 8080 and 8443 over HTTP and TCP.
We want the load balancer to span the availability zones us-east-1a and us-east-
1b:
>>> zones = ['us-east-1a', 'us-east-1b']
>>> ports = [(80, 8080, 'http'), (443, 8443, 'tcp')]
>>> lb = conn.create_load_balancer('my-lb', zones, ports)
>>> # This is from the previous section.
>>> lb.configure_health_check(hc)
The load balancer has been created. To see where you can actually connect to it,
do:
>>> print lb.dns_name
my_elb-123456789.us-east-1.elb.amazonaws.com
You can then CNAME map a better name, i.e. www.MYWEBSITE.com to the above
address.
Adding Instances To a Load Balancer
Now that the load balancer has been created, there are two ways to add instances
to it:
1. Manually, adding each instance in turn.
2. Mapping an autoscale group to the load balancer. Please see the Autoscale
tutorial for information on how to do this.
Manually Adding and Removing Instances
Assuming you have a list of instance ids, you can add them to the load balancer
>>> instance_ids = ['i-4f8cf126', 'i-0bb7ca62']
>>> lb.register_instances(instance_ids)
Keep in mind that these instances should be in Security Groups that match the
internal ports of the load balancer you just created (for this example, they should
allow incoming connections on 8080 and 8443).
To remove instances:
>>> lb.deregister_instances(instance_ids)
Modifying Availability Zones for a Load Balancer
If you wanted to disable one or more zones from an existing load balancer:
>>> lb.disable_zones(['us-east-1a'])
You can then terminate each instance in the disabled zone and then deregister
then from your load balancer.
To enable zones:
>>> lb.enable_zones(['us-east-1c'])
Deleting a Load Balancer
>>> lb.delete()
Table Of Contents
An Introduction to botos Elastic Load Balancing interface
Elastic Load Balancing Concepts
Creating a Connection
Getting Existing Load Balancers
Creating a Load Balancer
Ports and Protocols
Configuring a Health Check
Putting It All Together
Adding Instances To a Load Balancer
Manually Adding and Removing Instances
Modifying Availability Zones for a Load Balancer
Deleting a Load Balancer
Previous topic
An Introduction to botos VPC interface
Next topic
An Introduction to botos S3 interface
This Page
Show Source
Quick search
Go
yes default

Enter search terms or a module, class or function name.

Table Of
Contents

Previous
Chapter

Next
Chapter
Index

Chapter
Contents

Health
Checks
Overview

Server and
Application
Port States

Best Path
to a
Remote
Server

Reassign
Threshold

ServerIron XL L4-7 Software Configuration Guide

Health Checks
Health Checks Overview
The ServerIron (SI) uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of real servers and
applications on the real servers.
When you configure a real server, the SI sends an ARP request for the real server and then sends an IP ping to the
server to verify that the SI can reach the server through the network. The ARP request is sometimes referred to as a
Layer 2 health check since the request is for the real server's hardware layer address.
Later, when you bind the real server to a Virtual IP (VIP) server, the SI sends a Layer 4 or Layer 7 health check to
bring up the port you used for the binding. For example, if you bind a real server to a virtual server using port HTTP,
the SI sends an HTTP Layer 7 health check to bring up the HTTP port on the real server.
The SI performs the health checks described above by default. In addition, you can enable periodic Layer 4 or Layer
7 keepalive health checks for individual application ports. Following successful bringup of an application port when
you bind a real server to a virtual server, the SI repeats the Layer 4 or Layer 7 keepalive health check to continually
verify the health of the port.
Application Ports
The SI selects a Layer 4 or Layer 7 health check based on whether the application port is known to the SI. A Layer
4 health check is a TCP or UDP request and is not related to a specific application. A Layer 7 health check is an
application-aware health check designed for the specific application. The following application ports are known to
the SI. The SI performs Layer 7 health checks for these ports. For other ports, the SI performs a Layer 4 TCP or
UDP health check instead:
TCP Ports
FTP (port 21). Ports 20 and 21 both are FTP ports but on the SI, the name "FTP" corresponds to port 21.
HTTP (port 80)
IMAP4 (port 143)
LDAP (port 389)
MMS (port 1755)
NNTP (port 119)
PNM (port 7070)
POP3 (port 110)
RTSP (port 554)
SMTP (port 25)
SSL (port 443)
TELNET (port 23)
UDP Ports
DNS (port 53)
RADIUS (port 1812

ping-
interval,
ping-retries

l3-health-
check

Layer 3
Health
Check for
Real
Servers

Port
Profiles

Reassign
Threshold

SSL Health
Checks

Layer 4
UDP
Keepalive
Health
Checks for
the DNS
Port

RADIUS-OLD (port 1645), which is used in some older RADIUS implementations instead of port 1812

NOTE: NOTE: You can add either port 1812 or port 1645 to a given real or virtual server, but you cannot
add both ports to the same server.

The keepalive health checks are disabled by default. To enable a keepalive health check for an application port,
configure a port profile for the port (which automatically enables the keepalive globally for the port) or enable the
keepalive on individual real servers that use the port.
Layer 3 Health Checks
Layer 3 health checks consist of ICMP-based IP pings and ARP requests. When you configure a real server on the
SI, the SI sends an ARP request and an IP ping to the real server to verify that the SI can reach the server through
the network.
The SI also sends an IP ping to a real server in the following circumstances:
If the ARP entry for the server times out. In this case, the SI uses the IP ping to create a new ARP entry for
the server. The ARP request is sometimes referred to as a Layer 2 health check since the request is for the
real server's hardware layer address.
If the time between the last packet sent to the server and the last packet received from the server
increases. In this case, the SI uses the IP ping to determine whether the slowed response time indicates
loss of the server. If the server responds to the ping, the SI then sends a Layer 4 or Layer 7 health check,
depending on whether the port's application type is known to the SI. The SI sends pings at an interval of 2
seconds apart, and retries unsuccessful pings up to 4 times by default. You can change the ping interval
and retries if desired. See "ping-interval, ping-retries".
Summary of L3 Health Checks
Type When Performed Description
ARP
request
o When you configure a real server A standard IP ARP request for the
server's MAC address, which the SI
adds to its ARP table.
IP ping o When you configure a real server
o If the ARP entry ages out
o If the time between the last packet sent to
the server and the last packet received
from the server increases
A standard ICMP-based IP ping.
When you bind a real server to a virtual server, the SI performs either a Layer 4 TCP or UDP health check or a
Layer 7
Health
Checks

Health
Check of
Multiple
Web Sites
on the
Same Real
Server

Layer 7
Health
Check for
an
Unknown
Port

Boolean
Health-
Check
Policies

Boolean
Health-
Check
Policies

show
healthck

show
Layer 7 health check to bring up the application port that binds the real and virtual servers. If the application port is
not one of the applications that is known to the SI, the SI uses a Layer 4 health check. Otherwise, the SI uses the
Layer 7 health check for the known application type.
The Layer 4 health check can be a TCP check or a UDP check:
TCP health check - The SI checks the TCP port's health based on a TCP three-way handshake:
o The SI sends a TCP SYN packet to the port on the real server.
o The SI expects the real server to respond with a SYN ACK.
o If the SI receives the SYN ACK, the SI sends a TCP RESET, satisfied that the TCP port is alive.
UDP health check - The SI sends a UDP packet with garbage (meaningless) data to the UDP port:
o If the server responds with an ICMP "Port Unreachable" message, the SI concludes that the port is
not alive.
o If the server does not respond at all, the SI assumes that the port is alive and received the garbage
data. Since UDP is a connectionless protocol, the SI and other clients do not expect replies to data
sent to a UDP port. Thus, lack of a response indicates a healthy port.

NOTE: The SI assumes that a port is a UDP port unless you configure the port as a TCP port. To configure a
port as a TCP port, add a port profile for the port and specify the port type TCP. See "Port Profiles".

After the SI sends an initial packet (TCP or UDP) to the server to bring the port up, the SI waits one second and
then checks for a response from the server. If no response is received during that time, the SI will send another
packet. The time at which the SI sends the second packet depends on the number of ports being brought up at that
time. The SI will send the second packet after it has sent initial packets to all the other ports being brought up at that
time.
By default, the SI does not repeat the Layer 4 health check after bringing up the port when you bind the real server
to the virtual server. However, you can enable a periodic keepalive health check for the port. To configure the
keepalive health check globally, configure a port profile for the port. You also can enable or disable the keepalive
health check on individual real servers.
TCP
When you bind a TCP
application port on a real
server to a TCP application
port on a virtual server
At regular intervals, if
keepalive is enabled for the
port and the port does not
have a Layer 7 health check
The SI attempts to engage in a normal three-way TCP handshake
with the port on the real server:
The SI sends a TCP SYN packet to the port on the real
server.
The SI expects the real server to respond with a SYN
ACK.
If the SI receives the SYN ACK, the SI sends a TCP
RESET, satisfied that the TCP port is alive.
healthck
statistics

Clear
Healthck
Statistics

Port Status
the Syslog

Session
Tables

session-
limit

session-
max-idle

tcp-age

udp-age

clock-scale

Syslog for
Session
UDP
When you bind a UDP
application port on a real
server to a UDP application
port on a virtual server
keepalive is enabled for the
port and the port does not
have a Layer 7 health check
The SI sends a UDP packet with garbage (meaningless) data to
the UDP port.
If the server responds with an ICMP "Port Unreachable"
message, the SI concludes that the port is not alive.
If the server does not respond at all, the SI assumes that
the port is alive and received the garbage data. Since
UDP is a connectionless protocol, the SI and other clients
do not expect replies to data sent to a UDP port. Thus,
lack of a response is a good outcome.
For certain TCP and UDP application ports, the SI can send application-specific health checks to determine the
health of the application. For example, the SI can send user-configurable HTTP requests to real servers to assess
the health of the servers.
When you bind a real server to a virtual server using an application port that is known to the SI, the SI sends a
Layer 7 health check to the application on the real server to bring up the application port.
Table 5.3 describes the Layer 7 health checks. You can enable a Layer 7 health check globally by configuring a port
profile or locally by enabling the health check on an individual real server. In addition, you can customize some
types of Layer 7 health checks for individual real servers. For example, you can specify a URL that the SI should
request on a specific real server when sending the Layer 7 HTTP health check to that server.

NOTE: By default, if a client requests a TCP/UDP port that is not available, the SI does not send an ICMP
"Destination Unreachable" message to the client. For HTTP traffic, you can configure the SI to send such a
message to the client by enabling the ICMP Message feature for HTTP. See "icmp-message" for details.

DNS
Immediately following
a successful Layer 4
UDP health check
keepalive is enabled
for the port
The SI performs one or both of the following types of DNS
health checks:
Address-based - The SI 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 SI 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
Table
Entries

Slow-Start
Mechanism

LDAP
Over SSL

health check.
Note: If you configure both types of DNS health check for a
server, the server must successfully respond to both health
checks to remain in the server rotation. You enable each type
of DNS health check on a global basis and configure them on
an individual server basis.
If the server replies with the requested IP address or
zone name, the SI considers the server port to be and
marks it ACTIVE.
If the server does not reply with the requested IP
address or zone name, the SI retries the health check
up to the number of times configured (the default is
two retries). If the server still does not send the
requested information, the SI marks the DNS port on
the server FAILED and removes the server from the
rotation for DNS services.
Note: By default, the health check is non-recursive. If the real
server (DNS server) does not successfully reply to the health
check, then the DNS port fails the health check. You can
enable the real server to perform a recursive lookup for the IP
address or zone requested by the health check. In this case, if
the real server does not have the requested address or zone,
the server can pass the request on to a DNS server with
higher authority. See "allow-recursive-search".
FTP
TCP health check
for the port
The SI waits for a message from the server.
If the server sends a greeting message with status
code 220, the SI resets the connection and marks the
port ACTIVE.
If the server does not send a greeting message with
status code 220, the SI retries the health check up to
the number of times configured (the default is two
retries). If the server still does not send the expected
message, the SI marks the server port FAILED and
removes the server from the load-balancing rotation
for FTP service.
HTTP
(status code)
TCP health check
for the port
The SI sends HTTP GET or HEAD requests to cache servers
(when using TCS) or HTTP servers (when using SLB).
The GET or HEAD request specifies a page (identified by the
URL, "Universal Resource Locator") on the server. By default,
the SI sends a HEAD request for the default page, "1.0".
If the server responds with an acceptable status
code, the SI resets the connection and marks the port
ACTIVE. For SLB, the default acceptable status
codes for the check are 200 - 299 and 401. For TCS,
the default acceptable status codes are 100 - 499.
If the server responds with a different status code, the
SI marks the HTTP port FAILED.
If the server does not respond, the SI retries the
health check up to the number of times configured
(the default is two retries). If the server still does not
respond, the SI marks the server port FAILED and
for HTTP service.
Note: You can change the status code range for individual
servers. If you do so, the defaults are removed and only the
status code ranges you specify cause the server to pass the
health check.
HTTP
(content
verification)
TCP health check
for the port
The SI sends HTTP GET or HEAD requests to cache servers
(when using TCS) or HTTP servers (when using SLB).
The GET or HEAD request specifies a page (identified by the
URL) on the server. The SI examines the page and compares
the contents of the page to a list of user-defined selection
criteria.
Based on the results of this comparison, the SI takes one of
the following actions with respect to port 80 (HTTP) on the real
server.
If the page meets the criteria for keeping the port up,
then the SI marks the port ACTIVE. This means that
the HTTP application has passed the health check.
If the page meets the criteria for bringing the port
down, then the SI marks the port FAILED.
If the page meets none of the selection criteria, then
the SI marks the port either ACTIVE or FAILED
according to a user-defined setting.
See "HTTP Content Matching Lists" for information on
specifying a page to check and setting up lists of selection
criteria
Scripted
(content
verification
health check for
unknown ports)
TCP health check
for the port
After a successful Layer 4 health check, the SI waits for the
real server to send back a packet in response.
The SI looks in the response packet for a user-specified ASCII
string, defined in a matching list. The SI compares the
contents of the string to a list of user-defined selection criteria
in the matching list.
Based on the results of this comparison, the SI takes one of
the following actions with respect to the port on the real
server.
If the text in the response meets the criteria for
keeping the port up, then the SI marks the port
ACTIVE.
If the text in the response meets the criteria for
bringing the port down, then the SI marks the port
FAILED.
If the text in the response meets none of the selection
criteria, then the SI marks the port either ACTIVE or
FAILED according to a user-defined setting.
If no response is received within the configured
interval (the default is five seconds), the SI 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 SI marks the server
port FAILED.
See "Scripted Health Checks" for more information.
IMAP4
TCP health check
for the port
The SI waits for a message from the IMAP4 server.
If the server sends a greeting message that starts
with "* OK", The SI sends a Logout command to the
IMAP4 port on the real server, then resets the
connection and marks the port ACTIVE.
If the server does not send a greeting message that
starts with "* OK", the SI retries the health check up to
for IMAP4 service.
LDAP
TCP health check
for the port
The SI sends a bind request to the LDAP server and waits for
a reply. The bind request includes a configurable version
number. The version number can be 2 or 3. The default is 3.
If the server sends a bind reply with result code 0 (no
error), the SI resets the connection and marks the
port ACTIVE.
If the server does not send a bind reply by the time
the LDAP keepalive retries expires, the SI retries the
for LDAP service.
MMS
TCP health check
The SI sends an intentionally invalid request to the server.
for the port
If the server replies with a packet containing the value
"MMS", the SI marks the port ACTIVE.
If the server does not reply with a packet containing
the value "MMS", the SI retries the health check up to
retries). If the server still does not respond, the SI
marks the server port FAILED and removes the
server from the load-balancing rotation for MMS
service.
Note: You can view the SI's invalid request in the MMS server
log. The log entry has error code 400.
NNTP
TCP health check
for the port
The SI waits for a message from the NNTP server.
code 200 or 201, the SI sends a Quit command to the
NNTP port on the real server, then resets the
connection by sending a quit and a RESET, one
immediately after the other, and marks the port
ACTIVE.
status code 200 or 201, the SI retries the health
check up to the number of times configured (the
default is two retries). If the server still does not send
the expected message, the SI marks the server port
FAILED and removes the server from the load-
balancing rotation for NNTP service.
PNM
TCP health check
for the port
The SI sends a PNM file request that does not have a file
name.
If the server sends a reply containing the value
"PNA", the SI marks the port ACTIVE.
If the server does not send a reply containing the
value "PNA", the SI retries the health check up to the
number of times configured (the default is two
for PNM service.
POP3
TCP health check
for the port
The SI waits for a message from the POP3 server.
If the server sends a greeting message that starts
with "+ OK", the SI sends a Quit command to the
POP3 port on the real server, then resets the
connection by sending a quit and a RESET, one
immediately after the other, and marks the port
ACTIVE
If the server does not send a greeting message that
starts with "+ OK", the SI retries the health check up
to the number of times configured (the default is two
for POP3 service.
RADIUS
UDP health check
for the port
The SI sends an authentication request with a user name,
password, and key to the RADIUS server. The account
information does not need to be valid for the server to pass
the health check. In fact, to prevent someone from learning
account information by observing the SI's RADIUS health
check, Foundry Networks recommends you use invalid
information.
If the server replies with the result code "ACCEPT" or
"REJECT, the SI considers the port to be ok and
marks it ACTIVE.
If the server does not reply or the server Sends an
ICMP "Destination Unreachable" message, the SI
retries the health check up to the number of times
configured (the default is two retries). If the server still
does not reply with "ACCEPT" or "REJECT", the SI
marks the RADIUS port FAILED and removes the
server from the rotation for RADIUS services.
Note: You can configure a check either for the well-known
RADIUS port number 1812 or 1645. You cannot configure a
health check for both of these ports on the same server.
RTSP
TCP health check
for the port
The SI sends a standard RSTP option packet, using sequence
number 1.
ACTIVE. For SLB, the default acceptable status
codes for the check are 200 - 299 and 401.
If the server responds with a different status code, the
SI marks the port FAILED.
for RSTP service.
SMTP
TCP health check
The SI waits for a message from the SMTP server.
code 220, the SI sends a Quit command to the SMTP
port on the real server, then resets the connection by
for the port sending a quit and a RESET, one immediately after
the other, and marks the port ACTIVE.
status code 220, the SI retries the health check up to
for SMTP service.
SSL
(complete)
TCP health check
for the port
The SI initiates an SSL connection with the server on TCP
port 443, a secure link is negotiated, and encrypted data is
transferred across it.
After the SSL connection is established, the SI sends the SSL
server an HTTP GET or HEAD request. The GET or HEAD
request specifies a page containing the URL of a page on the
server. By default, the SI sends a HEAD request for the
default page, "1.0", although this can be changed with the
port ssl url command.
ACTIVE.
for SSL service.
Note: You can configure the SIXL to use the simple SSL
health check used on other SI models. See below and "SSL
Health Checks".
SSL
(simple)
TCP health check
for the port
The SI sends an SSL client hello with the SSL SID set to 0:
If the server responds, then the SI resets the
for SSL service.
Telnet
TCP health check
The SI waits for a message from the Telnet server.
If the server sends a command string that starts with
the IAC escape characters ("FF"), the SI resets the
for the port
If the server does not send a command that starts
with the IAC escape character, the SI retries the
send the expected escape character, the SI marks
the server port FAILED and removes the server from
the load-balancing rotation for Telnet service.
Health Checking for Real Servers in Other Sub-
Nets
The SI must be able to receive the real server's response to a health check in order to assess the success of the
health check. In topologies where reply traffic from a real server is guaranteed to pass through the SI, the SI is able
to receive replies to the health checks.
However, if the topology is such that the SI and real servers are in different sub-nets or the server reply is not
guaranteed to pass back though the SI, you might need to use source NAT and configure a source IP address.
Source NAT and source IP addresses allow the SI to have multiple sub-net identities. Generally, the SI is a member
of only one sub-net, the sub-net that contains the SI's management IP address. You can place the SI into up to
eight additional sub-nets by enabling source NAT and adding source IP addresses to the SI.
Normally, the SI uses its management IP address as the source address for health check packets. When you
enable source NAT and add a source IP address, the SI uses the source IP address as the source for the health
check packets. Thus, when the real server replies, the reply is addressed to the source IP address instead of the
SI's management IP address.
For an example of how to configure source NAT and source IP addresses, see "Web Hosting with SI and Real
Servers in Different Sub-Nets".
FastCache
In typical TCS configurations, the SI uses cache responses that flow back through the SI as a means to determine
the health of the cache server.
When the SI receives cache responses to client requests sent to the cache by the SI, the SI knows that the cache
server is healthy. However, if the cache server does not respond to client requests, the SI does not receive the
responses from the cache server. Therefore, the SI determines that the cache server is down and stops sending
client requests to the cache server.
Some configurations might require responses from a cache server to select a path that does not return through the
SI. For example, if a cache server supports only one default path and that path is to a gateway router, not to the SI,
the cache server might send responses to the clients through the default gateway instead of through the SI. In this
case, the SI assumes that the cache server has stopped responding even though the cache server is still working
normally.
You can override health checking on an individual server basis by enabling FastCache. This feature allows the SI to
continue using a cache server even if the server does not send responses to client requests back through the SI.
When you enable FastCache on a cache server, the SI continues to send client requests to the cache server even if
the server does not respond through the SI.
Server and Application Port States
Server States
The server states only concern up to Layer 3. They do not deal with Layers 4 or 7. In Table 5.4, Layer 2 reachability
refers to ARPs, a Layer 2 query for Layer 3 information. Layer 3 reachability refers to ICMP echo requests and
replies, or pings.

NOTE: Layer 4 refers to making a TCP connection to a port. Layer 7 refers to making an HTTP request and
getting an HTTP reply.

Server States
State Description
ENB:enabled There is no link to the real server. The real server is configured on the SI but is not physically
connected to the SI.
FAL:failed The real server has failed to respond to repeated Layer 3 health checks (IP pings). Typically, a
real server changes to the FAILED state from the SUSPECT state.
TST:testing A real server will go to "Testing" if it is reachable at Layer 2 but not at Layer 3. When you first
add a real server, the ServerIronXL will first try to ARP it. While it is ARPing, the server state will
read "State: Enabled". After the real server replies to the ARP, the ServerIronXL will normally
send one ICMP echo request. After it gets the ARP reply and before it gets the ICMP echo
reply, the ServerIronXL will show the real server state as Testing. If you have a firewall
application on the real server so that it responds to ARP queries but not to ICMP pings, then the
real server will show as "Testing" forever.
Use show server real to display detailed state information. The show server bind
command is more concise, though it focuses on port status.
SUS:suspect The SI associates a time stamp with each packet sent to and received from the real servers. If
the time gap between the last packet received from the server and the last packet sent to the
server grows to 3 or 4 seconds, the SI sends a ping (Layer 3 health check) to the server. If the
server doesn't respond within the ping interval (a configurable parameter), the SI changes the
state to SUSPECT and resends the ping, up to the number of retries specified by the ping
retries parameter (also configurable). If the server still doesn't respond after all the retries, the
state changes to FAILED. If the server does respond, the state changes to ACTIVE.
GDN:grace-dn The server gracefully shut down. See server force-delete.
ACT:active A real server will go to active as long as it is reachable at Layer 2 and 3, regardless of whether
or not its ports are bound to anything, regardless of whether or not its ports pass tests.
After receiving that first ping reply, normally the ServerIronXL switches to periodic ARPs. If you
enable server l3-health-check globally, then the ServerIronXL switches to using periodic
pings instead. The real server still shows the state active. If you enter no server l3-health-
check globally, then the ServerIronXL will switch back to ARP. After that first ping succeeds, if
you do not have L3 health checks enabled, you can add an ICMP blocking ACL on the real
server, and the system will still display "Active". If you re-add server l3-health-check, then
the real server state will change from Active to Suspect and then Failed. This behavior is all
done before any ports have been bound to a virtual server. All these states on a real server
have nothing to do with L4/L7.
UNB:unbind Used for ports which have not been bound to a virtual server.
AWU:await-
unbind
AWD: await-
shutdown
Both can occur when you're trying to unbind or delete ports. You might not even see them in
anything but a live environment. After you remove real servers from a virtual server or delete
virtual servers or unbind ports, normally the ServerIron chassis or stackable waits until
connections in progress finish their business.

Application Port States
Table 5.5 lists the application port states.
Application Port States
State Description
ENABLED There is no link to the server. The server is configured on the SI but is not connected to the SI.
(This is the same as the ENABLED server state.)
FAILED The application has failed to respond to repeated Layer 4 or (if applicable) Layer 7 health checks.
Typically, an application changes to the FAILED state from the SUSPECT state. Note that if a
application does not pass the Layer 4 health check, the SI does not waste resources on the Layer
7 health check, since the application clearly is not available. When an application enters the
FAILED state, the state of the real server itself moves to the TEST state while the SI continually
tries to reach the failed application.
TEST The server is still reachable at Layer 3, but the application has failed to respond to its Layer 4 (or if
applicable, Layer 7) health check.
SUSPECT The SI associates a time stamp with each packet sent to and received from the real servers. If the
time gap between the last packet received from the server and the last packet sent to the server
grows to 3 or 4 seconds, the SI sends a Layer 4 health check to the service. (If applicable, and if
the server passes the Layer 4 health check, the SI then sends a Layer 7 health check to the
application.) If the application doesn't respond within a specified interval, the SI changes the state
to SUSPECT and resends the Layer 4 (and if applicable, Layer 7) health check up to a specific
number of retries. If the application still doesn't respond after all the retries, the state changes to
FAILED and the server state changes to TEST. If the application does respond, the application
state changes to ACTIVE.
GRACE_DN The forced-shutdown option has been used to gracefully shut the server down.
ACTIVE The application has passed its Layer 4 (and if applicable, Layer 7) health check.
UNBND The application is configured on the real server but is not yet bound to a virtual server.
This following sections describe how to display the state information.
Displaying Real Server State Information
To display real server information, enter the following command at any level of the CLI. For complete information
about these displays, see "show server real".

The state information shown by this display is highlighted in bold type in the example above. The state of the server
itself is listed first, then the states of each of the application ports configured on the server are displayed.
In this example, the server itself is enabled. The HTTP port also is enabled, but the "default" port (a port the SI
automatically configures on all the real and virtual servers) is unbound. These states are typical of a SI that is
configured for deployment but has not been connected to the real servers.
The information under the row for the HTTP application shows settings for the Layer 7 health checks for the port.
For information about HTTP health checks and other configurable Layer 7 health check parameters, see "Layer 7
Health Checks".
Displaying Virtual Server State Information
To display virtual server information, enter the following command at any level of the CLI. For complete information
about these displays, see "show server virtual".

In this example, the virtual server and the application ports configured on the server are enabled, indicating that the
server and the application ports are configured on the SI but the SI is not connected to the real servers bound to this
virtual server. See "Displaying Real Server State Information" for descriptions of the server and application states.

NOTE: The number following "state" in the "Sym" row indicates the Symmetric SLB state of this VIP. See
"show server virtual".

Best Path to a Remote Server

NOTE: Foundry recommends that you use this feature whenever the SI is in the direct path between the
remote server and the default gateway.

When the SI sends a health check to a remote server, the SI sends the health check through the default gateway,
since the remote server's sub-net is different from the sub-net of the SI's management IP address. In some
topologies, the SI's default gateway is not the most direct path to the remote server. Figure 5.1 shows an example.
Figure 5.1 Health check of remote server - Learned MAC address is not used

In this example, the SI sends the health check through its default gateway. The default gateway sends the health
check back to the SI, since Router R1's route to the remote server lists the SI as the next hop. Despite the
unnecessary trip through the default gateway, the health check still reaches the remote server. However, if you want
to eliminate unnecessary hops, you can enable the SI to learn the MAC address from which the remote server's
health check reply is received, and send subsequent health checks directly through that MAC address. Figure 5.2
shows the simplified health check process.
Figure 5.2 Health check of remote server - Learned MAC address is used

Use [no] use-learned-mac-address to enable the SI to use learned MAC addresses for sending health checks
to remote servers:
ServerIron(config-rs-remote1)#use-learned-mac-address

NOTE: This command does not apply to local servers. Since local servers are attached at Layer 2, the SI does
not need to use a gateway or otherwise route the health check to the server.

Reassign Threshold
The reassign threshold specifies the number of contiguous inbound TCP-SYN packets a real server can fail to
respond to before the SI changes the application state to FAILED and the server state to TEST. The default
reassign threshold is 21. The server and application states are described in "Server and Application Port States".
If the field reaches the reassign threshold, the SI marks the application failed. The value of an application's Reas
field is reset to 0 when the SI receives a TCP SYN ACK from the application. No other type of traffic can clear this
field.
If a real server seems to be triggering the reassign threshold too frequently, you can increase the reassign
threshold. The default is 21 and the range of values is 6 - 254. This is a global parameter. See "Reassign
Threshold".
Notes:
It is possible to take a service down without triggering the reassign threshold. For example, in a lab
environment where the server is not receiving TCP SYNs, the service might be down but since the SI is not
sending new requests to the server, the server does not fail to respond to enough consecutive TCP SYNs
to meet the reassign threshold. As a result, the SI indicates the server and the service are ACTIVE when in
fact they are offline.
The SI does not try to reassign the client's request to another server if you configure the application port to
be sticky. The sticky option configures the SI to override load-balancing and send all client requests for the
application to the same server during a given session.
The reassign threshold counter is not incremented in DSR (Direct Server Return) configurations.
ping-interval, ping-retries
The SI automatically uses a Layer 3 health check consisting of ICMP echo requests (pings) to check the health of a
real server. Ping is enabled by default and cannot be disabled. However, you can modify the ping interval and
number of retries.
Use [no] server ping-interval <value> to modify the ping interval, where <value> can be from 1 - 10
seconds. The default is 2 seconds.
ServerIron(config)#server ping-interval 8
Use [no] server ping-retries <value> to modify the number of times the SI will ping a real server before
changing the server state to FAILED, where <value> can be from 2 - 10. The default retry value is 4.
ServerIron(config)#server ping-retries 7
l3-health-check
On the SIXL, software release 07.3.05 provides periodic Layer 3 health checks for real servers. A Layer 3 health
check is an IP ping sent to the real server's IP address. When Layer 3 health checks are enabled, the SI will send
client requests to a real server only if that server responds successfully to the IP pings sent by the SI.
Use [no] server l3-health-check to globally enable periodic Layer 3 health checks:
ServerIron(config)#server l3-health-check
Periodic Layer 3 health checks are disabled by default. To use the health checks, you must enable them globally
using the command above.
The global periodic health checks are different from the Layer 3 health checks performed when you add real
servers. To disable or enable the initial Layer 3 health check, see "Layer 3 Health Check for Real Servers".
Layer 3 Health Check for Real Servers
By default, when you add a real server configuration to the SI, the SI uses a Layer 3 health check (IP ping) to
determine the server's reachability. If the real server responds to the ping, the SI changes the server's state to
ACTIVE and begins using the server for client requests.
You can globally disable the Layer 3 health check for local servers or remote servers. You also can disable the
Layer 3 health check on individual real servers. When you disable the Layer 3 health check, the SI sends an ARP
request for the default gateway and makes the server's state ACTIVE as long as the ARP entry is present in the SI's
ARP cache.
no-real-l3-check
Use [no] server no-real-l3-check to globally disable the Layer 3 health check for all local real servers:
ServerIron(config)#server no-real-l3-check
no-remote-l3-check
Use [no] server no-remote-l3-check to globally disable the Layer 3 health check for all remote real servers:
ServerIron(config)#server no-remote-l3-check
no-l3-check
Use [no] no-l3-check to disable the Layer 3 health check on an individual real server:
ServerIron(config-rs-R1)#no-l3-check
This command applies to local real servers and remote real servers.
l4-check
Use [no] server l4-check to globally disable or re-enable Layer 4 TCP or UDP health checks for servers. The
Layer 4 health checks are enabled by default.
If you are configuring the SI to load balance traffic to multiple servers on the other side of routers and you want to
load-balance the traffic according to TCP or UDP application, use the no server l4-check command to disable
the Layer 4 health checks. If you do not disable the health checks in this type of configuration, the routers will fail
the health checks (because the target applications for the health checks are not on the routers themselves) and the
SI will stop forwarding traffic to those servers.

NOTE: If you are using the SI to load-balance TCP and UDP traffic through routers, you also must add each
router as a real server and disable the HTTP port on each of the real servers. HTTP is enabled by default on
all real servers.

Example
ServerIron(config)#no server l4-check
Port Profiles
A port profile is a set of attributes that globally define an application port. Once defined, the port has the same
attributes on all the real and virtual servers that use the port. Port profiles are useful if you want to globally change
the attributes of a port known to the SI (see the list in "Layer 7 Health Checks") or you want to globally define a port
that is not known to the SI. You also can specify or change port attributes locally, on the Real Server and Virtual
Server configuration levels.
If you want to enable the keepalive health check for an application port, you must configure a port profile for the
port.
Table 5.6 lists the port attributes you can configure at the port profile level.
Port Profile Attributes
Attribute Description
Port type (TCP or
UDP)
This attribute applies only to ports for which the SI does not already know the type. For
example, if a real server uses port 8080 for HTTP (a TCP port), you can globally identify
8080 as a TCP port. The SI assumes that ports for which it does not know the type are UDP
ports.
Note: To display a list of the ports for the SI already knows the type, enter the server port ?
command at the global CONFIG level of the CLI.
Keepalive interval
and retries
The number of seconds between health checks and the number of times the SI re-attempts a
health check to which the server does not respond. You can specify from 2 - 120 seconds for
the interval. You can specify from 1 - 5 retries.
Keepalive state Whether the SI's health check for the port is enabled or disabled. Recurring Layer 4 and
Layer 7 health checks are disabled by default. When you configure a port profile, the
software automatically globally enables the health check for the application. You also can
explicitly disable or re-enable the keepalive health check at this level.
Note: If you are configuring a port profile for a port that is known to the SI, the keepalive
parameters affect Layer 7 health checks. For other ports, the keepalive parameters affect
Layer 4 health checks.
Keepalive port By default, the SI bases the health of an application port on the port itself. You can specify a
different application port for the health check. In this case, the SI bases the health of an
application port on the health of the other port you specify.
Note: You cannot base the health of a port well-known to the SI on the health of another
port, whether the port is well-known or not well-known.
Source of health
for alias port
By default, the SI performs independent health checks on an alias port and its master port.
You can configure the SI to base the health of an alias port on the state of its master port.
TCP or UDP age The number of minutes a TCP or UDP session table entry can remain inactive before the SI
times out the entry. This parameter is set globally for all TCP or UDP ports but you can
override the global setting for an individual port by changing that port's profile. You can set
the TCP or UDP age from 2 - 60 minutes. The default TCP age is 30 minutes. The default
UDP age is five minutes.
On the SIXL, in software releases 07.3.05 and later, you can extend a port's TCP age
beyond the maximum TCP age, by specifying a multiplier. The software multiplies the TCP
age you specify for the port by the multiplier to calculate a higher TCP age. For example, if
you set a port's TCP age to 60 minutes (the maximum configurable value) and specify a
multiplier of 2, the TCP age for the port becomes 120 minutes. The multiplier applies only to
the individual TCP port's age and does not affect the ages of other TCP ports.
You can specify a TCP age from 2 - 60 minutes and a multiplier from 2 - 20. Thus, the
maximum configurable TCP age for an individual port is 1200 minutes (20 hours).
Note: You cannot specify a multiplier when configuring the global TCP age.
Note: Since UDP is a connectionless protocol, the SI does not remove a UDP session from
its session table until the session times out. TCP is a connection-based protocol. Thus, for
TCP sessions, the SI removes the session as soon as the client or server closes the
session.
Note: For DNS and RADIUS UDP load balancing, the age value does not follow the normal
configuration and default value unless udp-normal-age is configured on the port. The
default UDP age will always be 2 minutes unless udp-normal-age is configured.
Note: The SI immediately deletes a UDP DNS or RADIUS session table entry when the SI
receives a reply for the application from a real server. If desired, you can configure the SI to
age these ports like other UDP ports, using the UDP age timer. See "Normal UDP Aging for
DNS and RADIUS".
Session
synchronization
In Symmetric SLB configurations, this attribute provides failover for individual sessions on
the application port. Normally, existing sessions are not carried over from one SI to another
during failover. See "Symmetric SLB".
Connection
logging
You can enable logging for session table entries created for this port. See "Syslog for
Session Table Entries".
Slow start Configures the SI to control the rate of new connections to the application port to allow the
server to ramp up. See "Port Slow-Start Mechanism".
Smooth factor If you plan to use server response time as a load-balancing method, you can adjust the
amount of preference the SI gives the most recent response time compared to the previous
response time.
Recursive DNS
health checks
By default, a Layer 7 health check for a DNS port sends the query only to the real server
(DNS server). If the DNS server does not reply with the IP address or zone name requested
by the health check, the port fails the health check.
You can enable the real server to perform a recursive lookup for the IP address or zone
requested by the health check of the well-known DNS port (53).
You also can change port attributes locally, on the Real Server and Virtual Server configuration levels. Port profiles
simplify configuration by enabling you to characterize a port globally. For example, if many of your real servers use
TCP port 80 (the well-known number for HTTP) and you want to change the keepalive interval for the port, you can
do so globally. You do not need to change the value multiple times on each real server.
The SI knows the port types of a some well-known port numbers. If you are using a port number for which the SI
does not know the port type, you can specify whether the port is TCP or UDP and configure its keepalive values
globally. You do not need to define the port on every server.

NOTE: Unless a port is known to the SI to be a TCP port, the SI assumes the port is UDP. If you are using a
port number that is not known to the SI and the port type is TCP, you must specify this either globally (using
a port profile) or locally (when configuring the individual real servers and virtual servers). Otherwise, the SI
will use a UDP health check to test the port and the port will fail the health check.

NOTE: If you bind an application port on a real server to the same port on a virtual server, the port on the
real server inherits the attributes of the port on the virtual server.

Adding a TCP or UDP Port, Specifying the Port Type, and Configuring the Keepalive Health Check
For an application port that is not known to the SI, the SI assumes that the port is a UDP port. In addition, the SI
does not perform keepalive health checks for the port. You can configure a port profile for the port and specify
whether the port is TCP or UDP and also set keepalive health check parameters for the port.
Even for ports that are known to the SI, you must configure a profile for the port to globally configure the port's
parameters and configure the keepalive health check. After you add the port by indicating whether it is a TCP or
UDP port, the SI automatically enables the keepalive health check for the port.

NOTE: Enabling or disabling a keepalive health check does not affect the health check the SI sends when you
bind a real server to a virtual server using the application port. The keepalive health check state also does
not affect the health checks the SI sends if the server's response time slows.

The keepalive interval and retry values for each type of TCP/UDP health check are global parameters. For
example, if you change the number of retries for the HTTP health check (TCP port 80), the change applies to
all instances of port 80 on all the real servers configured on the SI.

Keepalive Health Check States
State Effect
Global (entire SI) Local (specific real server)
Disabled Disabled Health check is disabled
Disabled Enabled Health check is enabled
Enabled Disabled Health check is enabled
Enabled Enabled Health check is enabled
As shown in this table, once a keepalive health check is enabled, to disable it you must do so both globally and
locally. If you want to enable keepalive health checks only on specific real servers (locally), you can easily do so by
making sure the health checks are disabled globally, then enabling them on individual real servers.
To enable or disable a keepalive health check globally, use one of the following methods. To enable or disable a
keepalive health check locally, see "Layer 7 Health Check".

NOTE: DNS, HTTP, and RADIUS health checks use additional parameters, which you can configure using
separate commands. See "HTTP Keepalive Method, Value, and Status Codes", "DNS Health Check Method
and Values", or "RADIUS Health Check Values".

NOTE: When health checks are enabled for the ports on the VIPs in a host range, the SI checks the health of
the applications on the base IP address only. The SI assumes that the health of an application is the same for
all the VIPs within the host range. For information about host ranges, see "Web Hosting with Unlimited
Virtual IP Addresses".

Adding a Port and Specifying the Type
To add a port and specify that it is a TCP port, enter the following command:
ServerIron(config)# server port 8080
ServerIron(config-port-8080)# tcp
Syntax: server port <TCP/UDP-portnum>
Syntax: tcp | udp [keepalive [disable | enable]]
By adding a port, you also automatically enable periodic Layer 4 (and Layer 7, if applicable) keepalive health checks
for the port. If you do not specify the port type (TCP or UDP), the SI assumes that the port type is UDP.
Changing a Port's Keepalive Parameters
To change a port's keepalive state, enter a command such as the following:
ServerIron(config-port-8080)# tcp keepalive disable
To change a port's keepalive interval and retries, enter a command such as the following:
ServerIron(config-port-80)# tcp keepalive 15 5
Syntax: tcp | udp keepalive [<interval-in-seconds> <retries>]
You can specify from 2 - 120 seconds for the interval. You can specify from 1 - 5 retries.
Changing a Port's Session Age
For SIXL Releases 07.3.05 and Later:
Software release 07.3.05 and later for the SIXL allows you to extend a port's TCP age beyond the maximum TCP
age, by specifying a multiplier. The software multiplies the TCP age you specify for the port by the multiplier to
calculate a higher TCP age. For example, if you set a port's TCP age to 60 minutes (the maximum configurable
value) and specify a multiplier of 2, the TCP age for the port becomes 120 minutes. The multiplier applies only to
the individual TCP port's age and does not affect the ages of other TCP ports.
You can specify a TCP age from 2 - 60 minutes and a multiplier from 2 - 20. Thus, the maximum configurable TCP
age for an individual port is 1200 minutes (20 hours).

NOTE: You cannot specify a multiplier when configuring the global TCP age.

To extend the age of a TCP port, enter commands such as the following:
ServerIron(config-port-80)# tcp 60 2
Syntax: [no] tcp <mins> <multiplier>
The <mins> parameter specifies the number of minutes and can be from 2 - 60. There is no default. (If the age is
unspecified, the port used the globally configured age instead, which is 30 minutes by default.)
The <multiplier> parameter specifies the number by which the software will multiply the minutes specified above.
You can specify from 2 - 20. There is no default. If you do not specify a multiplier, the software uses the number of
minutes you specify, without multiplying them.
Displaying the Session Age of a TCP Port
To display the session age of a TCP port, enter a command such as the following. The TCP session ages are
shown in bold type. Notice that the TCP session ages for ports 8082 and http (80) use multipliers.

Syntax: show server real <name> detail
Basing a Port's Health on the Health of Another Port
You can configure the SI to base the health of a port that is not well-known to the SI on the health of one of the
following ports that are well-known to the SI:
DNS (port 53)
FTP (port 21). Ports 20 and 21 both are FTP ports but on the SI, the name "FTP" corresponds to port 21.
HTTP (port 80)
IMAP4 (port 143)
LDAP (port 389)
POP3 (port 110)
NNTP (port 119)
SMTP (port 25)
TELNET (port 23)
To base a port's health on the health of another port, enter a command such as the following:
ServerIron(config-port-1234)# tcp keepalive port 80
Syntax: tcp | udp keepalive port <TCP/UDP-portnum>
The command in this example configures the SI to base the health of port 1234 on the health of port 80 (HTTP). If
the health of port 80 changes, the SI applies the change to port 1234.

NOTE: You cannot base the health of a port well-known to the SI on the health of another port, whether the
port is well-known or not well-known.

Basing an Alias Port's Health on the Health of its Master Port
By default, the SI performs health checks for alias ports independently of the master ports on which they are based.
For example, if you configure alias port 8080 and base the port on port 80 (its master port), the SI checks the health
of 80 and 8080 independently.
You can configure the SI to check the health of the master port only, and base the health of the alias ports on the
master port.
You can base an alias port's health on the health of one of the following TCP ports:
FTP - port 21 (ports 20 and 21 both are FTP ports but on the SI, the name "FTP" corresponds to port 21)
HTTP - port 80
IMAP4 - port 143
LDAP - port 389
MMS - port 1755
NNTP - port 119
PNM - port 7070
POP3 - port 110
RTSP - port 554
SMTP - port 25
SSL - port 443
TELNET - port 23
You cannot base an alias port's health on the health of a UDP port or a port that is not well-known to the SI.

NOTE: The health checks for the alias ports must be enabled. Otherwise, the SI will not check the master
port's state, and the alias port will not go down when the master port goes down.

To configure an alias port's health to be based on its master port's health, edit the alias port's profile by entering
commands such as the following:
ServerIron(config-port-8080)# tcp keepalive use-master-state
Syntax: [no] tcp keepalive use-master-state
Overriding the Global TCP or UDP Age
The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the SI closes
the session and clears the session from its session table. You can set the TCP or UDP age from 2 - 60 minutes.
The default TCP age is 30 minutes. The default UDP age is five minutes.
Since UDP is a connectionless protocol, the SI does not remove a UDP session from its session table until the
session times out. TCP is a connection-based protocol. Thus, for TCP sessions, the SI removes the session as
soon as the client or server closes the session.

NOTE: The SI immediately deletes a UDP DNS or RADIUS session table entry when the SI receives a reply for
the application from a real server. If desired, you can configure the SI to age these ports like other UDP
ports, using the UDP age timer. See "Normal UDP Aging for DNS and RADIUS".

For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default
value unless udp-normal-age is configured on the port. The default UDP age will always be 2 minutes unless
udp-normal-age is configured.

To change the global default for all TCP or UDP ports, see "tcp-age" or "udp-age".
To override the default TCP age and set the age for TCP port 80 to 15 minutes, enter the following commands:
ServerIron(config-port-80)# tcp 15
Syntax: tcp | udp <2-60>
You can specify from 2 - 60 minutes.
session-sync
In Symmetric SLB configurations, if the active SI becomes unavailable, service for the VIPs that SI was load
balancing is assumed by the backup SI. By default, open sessions on the SI that becomes unavailable are not
carried over to the standby SI. Instead, the sessions end and must be re-established by the clients or servers.
You can configure session failover on an individual TCP or UDP port basis by enabling session synchronization \in
the port's profile.
To enable session synchronization for port 80, enter the following commands:
ServerIron(config-port-80)# session-sync
Syntax: [no] server port <tcp/udp-portnum>
Syntax: [no] session-sync
Changing the Smooth Factor on an Application Port
This smooth factor applies to ports that you plan to use with the server response time load-balancing metric. See
"predictor" and "Smooth Factor" for information about the server response time metric and how the smooth time
works.
The SI calculates the server response time value for a real server by regularly collecting response time samples,
then using a calculation to smooth the values of the samples and derive a single response time value for the real
server. The SI collects the samples around once every 100 milliseconds (about 10 times a second). The sampling
rate can vary slightly depending on the processing the SI is performing.
To change the smooth factor for an application port, enter a command such as the following:
ServerIron(config-port-80)# smooth-factor 50
Syntax: smooth-factor <num>
allow-recursive-search

NOTE: Recursive DNS health checks are supported only on the SIXL running software release 07.3.05 or later.

By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS server). If the DNS
server does not reply with the IP address or zone name requested by the health check, the port fails the health
check.
You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health
check. In this case, if the real server does not have the requested address or zone, the server can pass the request
on to a DNS server with higher authority. The real server can repeat this process until either a DNS server with
higher authority successfully replies to the health check or the server with the highest authority is unable to
successfully reply to the request.
You can enable recursive DNS health checks globally at the port profile level for the DNS port.
ServerIron(config)# server port dns
ServerIron(config-port-dns)# allow-recursive-search
Syntax: [no] allow-recursive-search

NOTE: This feature applies to Boolean health checks as well as standard (non-Boolean) health checks.

NOTE: You can enable this feature only on the well-known DNS port (53).

Reassign Threshold
In addition to the circumstances described in "Server and Application Port States", a real server's state also can be
affected by the reassign threshold. The reassign threshold specifies how many consecutive TCP SYN requests a
real server can fail to respond to before the SI changes the application state to FAILED and the server state to test.
The default reassign threshold is 20.
The value of an application's Reas field is reset to 0 when the SI receives a TCP SYN ACK from the application. No
other type of traffic can clear this field.

NOTE: The reassign threshold does not apply to servers in DSR (Direct Server Return) configurations. In a DSR
configuration, traffic from the real server does not pass back through the SI. As a result, the SI cannot
monitor the TCP SYN ACKs from the server. See "DSR".

NOTE: The SI does not try to reassign the client's request to another server if you configure the application
port to be sticky. The sticky option configures the SI to override load-balancing and send all client requests
for the application to the same server during a given session.

NOTE: If a real server seems to be triggering the reassign threshold too frequently, you can increase the
reassign threshold. This is a global parameter.

To modify the SYN-ACK threshold to 215:
ServerIron(config)# server reassign-threshold 215
Syntax: server reassign-threshold <threshold value>
In releases prior to 6.8.00, the range of values for <threshold value> is 6 - 254 and the default reassign threshold is
21 . In releases 6.8.00 and later, the range of values for <threshold value> is 6 - 4000 and the default reassign
threshold is 20.
no-reassign-count
Use [no] server no-reassign-count to prevent state flapping caused by the reassignment counter. When you
enter this command, the SI will stop incrementing the reassignment counters for real server applications.
By default, the SI brings an application port down if the port's reassignment count exceeds the reassign threshold.
The default reassign threshold is 21. If a port fails to respond with a SYN ACK to 21 client SYNs in a row, the SI
marks the port failed. Once the port is marked failed, the port can be re-activated as a result of a successful health
check on the port.
In some networks, the reassignment counter can cause needless state flapping of application ports. This occurs if
the network conditions cause the counter to frequently reach the threshold and cause the SI to bring ports down
even though the applications are healthy. The applications will remain unavailable for the amount of time it takes the
SI to send health checks, interpret the results, and activate the ports in response to successful results.

NOTE: The reassignment count applies to the total number of contiguous (back-to-back) unanswered SYNs
from all clients who have sent SYNs to the server.

Example
ServerIron(config)#server no-reassign-count

NOTE: This command is supported on the SIXL running software release 07.3.05 or higher.

no-fast-bringup
Use [no] server no-fast-bringup to enable the health-checking procedure that existed in releases prior to
7.1.05.
In release 07.1.05, the health-checking procedure for application ports changed as follows:
In releases prior to 07.1.05, the SI performed a Layer 4 health check on a port on a real server, followed by
a Layer 7 health check, if one was enabled on the port. If the port passed both health checks, it was then
marked ACTIVE.
Starting with release 07.1.05, by default when a port passes a Layer 4 health check, it is then marked
ACTIVE. The SI then performs a Layer 7 health check, if one is enabled on the port. Based on the result of
the Layer 7 health check (if enabled), the port is then marked ACTIVE or FAILED.
This change was made so that ports could be brought up more quickly. You can optionally change the default
behavior so that a port is not marked ACTIVE until it passes both the Layer 4 and (if one is enabled) Layer 7 health
checks. In other words, you can optionally use the health-checking procedure that existed in releases prior to
07.1.05.
Example
ServerIron(config)#server no-fast-bringup
SSL Health Checks
The SI supports two kinds of SSL health checking methods: simple and complete.
SimpleSends the server an SSL client hello with the SSL SID set to 0. If the server responds, then the
server passes the health check. The SI then resets the connection and marks the SSL port ACTIVE.
CompleteNegotiates an SSL connection and sending a GET or HEAD request to the server once the
connection is established. The GET or HEAD request specifies a page containing the URL of a page on the
server. If the server responds with an acceptable status code, the SI resets the connection and marks the
port ACTIVE.
In releases prior to 07.1.18, the SIXL supported only the simple SSL health check. Starting with release 07.1.18,
and continuing through later 07.1.x releases, the SIXL supports both the simple and complete SSL health checks.
The complete SSL health check is the default, but you can configure the device to use the simple SSL health check
if necessary.
The complete SSL health check functionality was removed from 07.3.x releases prior to 07.3.07. Starting with
release 07.3.07, the complete SSL health check functionality was restored. In release 07.3.07, the simple SSL
health check is the default, but you can configure the device to use the complete SSL health check.
Use [no] server use-simple-ssl-health-check to configure the SI to use the simple SSL health check:
ServerIron(config)#server use-simple-ssl-health-check
To use the complete SSL health check (notice the no):
ServerIron(config)#no server use-simple-ssl-health-check
Error Messages
If you see these error messages:
ssl_receive_data but tcb->ssl is null
SSL cleanup: can't find key ???
SSL interface: ssl_read_data return error !!!
they are related to SSL health check, after receiving SSL data while it can not find the key to decrypt the data. The
key is missing possibly due to a time out.
The SI normally stops processing the rest of the data and releases the SSL control block data structure. However
when the SI does not do that, the SI finds the SSL data structure is null and prints these messages.
Layer 4 UDP Keepalive Health Checks for the DNS Port
You can configure the SI to perform Layer 4 UDP keepalive health checks for the DNS port (port 53).
To do this globally for the DNS port on all real servers, enter the following commands:
ServerIron(config-port-dns)# udp l4-check-only
To do this for the DNS port on real server r1, enter commands such as the following:
ServerIron(config)# server real r1 1.1.1.1
ServerIron(config-rs-r1)# port dns l4-check-only
Syntax: port dns l4-check-only
The port dns l4-check-only command configures the SI to use Layer 4 UDP keepalive health checks for the DNS
port, instead of Layer 7 DNS health checks. This command applies to keepalive health checks only, not to the
health check performed when the DNS port is brought up. When the DNS port on a real server is brought up, by
default the SI performs a Layer 4 TCP health check. You can configure the SI to perform a Layer 4 UDP health
check when the DNS port is brought up by adding the no tcp keepalive enable command to the DNS port profile.
For example:
ServerIron(config-port-dns)# no tcp keepalive enable
You can configure the following Layer 7 health check parameters on a real server basis:
Keepalive health check state (enabled or disabled)
HTTP keepalive method, values, and valid status codes
HTTP content matching lists for HTTP content verification health checks
Scripted health checks (content verification health checks for unknown ports)
DNS keepalive method and values (zone-based or addressed-based check and the zone or domain name)
RADIUS keepalive values (user name, password, and encryption key)
LDAP version (2 or 3)

NOTE: The SI uses its own management IP address or a source IP address configured on the SI 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
sub-net as the SI, then the health checks can use the SI's management IP address. Otherwise, the health
checks use a source IP address. See "Web Hosting with SI and Real Servers in Different Sub-Nets".

Layer 7 Health Check
All Layer 7 health checks are disabled by default. You can enable a health check globally or locally. To enable or
disable a health check locally, use one of the following methods.

NOTE: The SI 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 SI
considers the health check to be enabled. See "Adding a TCP or UDP Port, Specifying the Port Type, and
Configuring the Keepalive Health Check".

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:
dns (port 53)
ftp (port 21). Ports 20 and 21 both are FTP ports but in the SI, the name "ftp" corresponds to port 21.
http (port 80)
imap4 (port 143)
ldap (port 389)
nntp (port 119)
ntp (port 123)
pop2 (port 109)
pop3 (port 110)
radius (UDP port 1812)
radius-old (UDP port 1645, which is used in some older RADIUS implementations instead of port 1812)
smtp (port 25)
snmp (port 161)
ssl (port 443)
telnet (port 23)
tftp (port 69)
<number>

NOTE: NOTE: Specify the port number if the port is not one of the well-known names listed above.

HTTP Keepalive Method, Value, and Status Codes
The SI 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 SI 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 "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 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 SI 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 SI automatically inserts a slash before retrieving the URL page.
To change the HTTP status codes that the SI 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 "HTTP Status Codes".

HTTP Content Matching Lists
An HTTP content verification health check is a type of Layer 7 health check in which the SI examines text in an
HTML file sent by a real server in response to an HTTP keepalive request. The SI 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.

NOTE: SI software version 7.3.x does not support URL or content verification health checks for SSL.

The selection criteria used in HTTP content verification is contained in a matching list that is bound to one or more
real servers.
Example:
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
Use [no] http match-list <matching-list-name> to set the name of the matching list and enters the HTTP
matching list CLI level.
Use [no] down simple <text> [log] statements to specify the selection criteria in this matching list. In the
example above, the first statement looks for the text "404" in the HTML file sent from the real server in response to
an HTTP keepalive request; the second statement looks for the text "File Not Found". If either of these text strings
are found in the HTML file, the SI marks port 80 (HTTP) on the real server FAILED. If neither of the text strings are
found, the SI marks the port ACTIVE.

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 SI must not exceed 200.

When an HTML file meets more than one set of selection criteria in a matching list, the SI takes one of the following
actions:
If the strings that meet the selection criteria are different, the SI takes action based on the string that comes
first in the file. For example:
ServerIron(config-http-ml-m2)# down simple "monkey"
ServerIron(config-http-ml-m2)# up simple "elephant"
The selection criteria in the matching list above would cause the SI 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 SI would mark port 80 on the real server FAILED, because "monkey" occurs first in the
file.
If a string that meets the selection criteria is a subset of another, the longer string takes precedence,
regardless of where it occurs in the file. For example:
ServerIron(config-http-ml-m3)# down simple "elephant"
ServerIron(config-http-ml-m3)# up simple "elephantine"
In this example, SI 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 SI 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-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
Syntax: up compound <start> <end> [log]
Syntax: down 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. 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.
The commands in the matching list also include the log parameter, which 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 above, the following message would be logged at the successful completion of an HTTP content
verification health check; 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":

show http match-list
To display the contents of matching lists configured on the SI, enter the following command:

Binding the Matching list to the Real Servers
To enable HTTP content verification on the SI, you bind the matching list to one or more real servers. For example:
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
SI 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.
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 SI. Previous releases
supported content verification health checks on port 80 only.
In a scripted health check, the SI opens a connection to a port on a real server by sending a SYN packet. The SI
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 SI 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 SI 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.
Setting up a scripted health check consists of the following steps:
Creating a port profile
Creating a matching list
Binding the matching list to the real server
Port Profiles
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 does not have a profile associated with it, since the SI 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 no-fast-
bringup command is necessary because it prevents the SI from marking a port ACTIVE until it passes both Layer 4
and Layer 7 health checks.
ServerIron(config-port-12345)# tcp
ServerIron(config-port-12345)# no-fast-bringup
Syntax: tcp | udp [keepalive <interval> <retries>]
Syntax: no-fast-bringup
Matching Lists
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-m1-m1)# up simple "FTP service"
ServerIron(config-http-m1-m1)# default down
Syntax: http match-list <matching-list-name>
Syntax: up simple <text> [log]
Syntax: default down | up
The up simple statement specifies the selection criteria in this matching list.
The default command specifies what happens if none of the text in the response from the real server meets the
selection criteria. You can specify either up or down; the default is up. 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. 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.
You can also use the compound parameter, which allows you to specify beginning and ending parts of a set of
selection criteria, as well as the log parameter, which causes the a Warning message to be logged when the
selection criteria is met.
Binding the Matching List to the Real Server
To enable the scripted health check on the SI, you bind the matching list to one or more real servers. For example,
to bind matching list m1 to real server R:
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-m1-m1)# up simple "FTP service"
ServerIron(config-http-m1-m1)# default down
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.
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 SI performs a Layer 7 health check. If this command is
omitted, the SI performs only a Layer 4 health check, and not the scripted health check.
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 SI 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 SI 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>
RADIUS Health Check Values
You can define the RADIUS parameters that the SI 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>
LDAP Version
By default, the SI 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 SI 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.
Health Check of Multiple Web Sites on the Same Real Server
If you host multiple web sites on the same real server, with each web site using a different VIP, you can perform an
independent health check for each VIP.
As described in "Many-To-One TCP/UDP Port Binding", to bind two VIPs to the HTTP port on the same real server,
you create an alias for the HTTP port on one of the VIPs. To create an alias for the HTTP port, you configure the
VIP to bind to an alternate port number on the real server, then disable port translation for that binding. The SI
collects and presents information for the alias port number, but traffic from both VIPs actually goes to the HTTP port
on the real server.
The state of the master port is used to indicate the health of ports aliased to the master port. For example, if a VIP
uses port 81 as an alias for the HTTP port, then the state information reported for the HTTP port is used as the state
information for port 81. If the HTTP port is reported down, then port 81 is reported down.
When a real server supports multiple web sites, tying the alias port's state to the master port's state may cause
incorrect information to be reported. For example, consider a real server hosting VIPs v1 and v2. VIP v1 is bound to
the HTTP port on the real server, and VIP v2 uses port 81 an alias for the HTTP port. The Layer 7 health check
reports state information about the HTTP port. When VIP v1 is taken down for maintenance, the Layer 7 health
check reports that the HTTP port is down. Because the state information reported for the HTTP port is also used as
the state information for port 81, the SI considers port 81 to be down as well, incorrectly reflecting the state of VIP
v2, which may be functioning normally.
To eliminate this problem, you establish separate health checks for the alias ports. Health checks for the alias ports
will continue to be performed regardless of the HTTP port's status. The following is an example of this kind of
configuration:
ServerIron(config)# server virtual v1 192.168.1.160
ServerIron(config-vs-v1)# port http
ServerIron(config-vs-v1)# bind http rs32 http
ServerIron(config-vs-v1)# exit
ServerIron(config)# server virtual v2 192.168.1.161
ServerIron(config-vs-v2)# port http
ServerIron(config-vs-v2)# no port http translate
ServerIron(config-vs-v2)# bind http rs32 81
ServerIron(config-vs-v2)# exit
ServerIron(config)# server real rs32 64.1.1.32
ServerIron(config-rs-rs32)# port http
ServerIron(config-rs-rs32)# port http keepalive
ServerIron(config-rs-rs32)# port http url "HEAD /"
ServerIron(config-rs-rs32)# port 81
ServerIron(config-rs-rs32)# port 81 keepalive
ServerIron(config-rs-rs32)# port 81 url "GET /81keepalive.htm"
In this configuration, two VIPs are bound to a single real server. VIP v2 uses port 81 as an alias for port 80;
information the SI receives about port 81 is attributed to VIP v2. If VIP v1 is taken down for maintenance, the Layer
7 health check done for port 80 fails, and the SI marks the HTTP port FAILED. However, health checks continue to
be performed for port 81. Port 81 (and thus VIP v2) will continue to be reported active as long as it passes its health
check.
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:
FTP (port 21)
IMAP4 (port 143)
LDAP (port 389)
POP3 (port 110)
SMTP (port 25)
Telnet (port 23)
UDP ports:
DNS (port 53)
Layer 7 TCP Health Checks for Unknown Ports

NOTE: This feature is supported only in software release 07.2.16 and higher 07.2.x releases.

You can use the SI's Layer 7 health check mechanism for the following TCP applications on any TCP port number:
FTP (port 21)
IMAP4 (port 143)
LDAP (port 389)
POP3 (port 110)
SMTP (port 25)
Telnet (port 23)
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-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:
ftp or 21
imap4 or 143
ldap or 389
pop3 or 110
smtp or 25
telnet or 23
Unknown UDP Port to Use a Layer 7 Health Check
The SI can perform Layer 7 health checks on the DNS port (UDP port 53).

NOTE: This feature is supported only in software release 07.1.18 and higher 07.1.x releases.

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 "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 SI 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-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.
Boolean Health-Check Policies
You can configure a group of Layer 4 and Layer 7 health checks as a health-check policy and associate the group
with a specific application port on a real server.
1
Health-check policies enable you to assess the health of any
application port using the health-check mechanisms for ports well-known to the SI. In addition, health-check policies
enable you to use multiple checks with different parameters, and base a port's health on successful completion of
all or any one of the individual checks in the policy.

NOTE: This section applies only to software release 07.3.05 and higher for the SIXL. To use Boolean health-
check policies on the SIXL with software prior to release 7.3.05, see "Boolean Health-Check Policies".

Depending on the conditions you specify when you configure a health-check policy, the SI will bring the application
port on a server down in one of the following cases:
Any one of the servers fails its health check (individual health checks combined using AND condition) - In
this case, all servers in the policy must pass their health checks. Otherwise, the SI considers all of the
servers to have failed the health checks and brings down the application on all servers that are checked by
the policy.
All of the servers fail their health checks (individual health checks combined using OR condition) - In this
case, an application port remains up as long as at least one of the servers checked by the policy passes its
health check.
For finer control, you can combine OR and AND conditions.
Health-Check State
When you attach a health-check policy to a real server's application port, the SI uses the health-check policy for
periodic health checks and also for the next initial bringup of the server. When a health-check policy is attached, the
SI no longer uses the default health check methods for initial bringup and periodic health checks.
For the SI to use a health-check policy, you must enable health checking (keepalive) at either the port profile level
or the real server level for the server port. Otherwise, the state of the policy is FALSE and the state of the server
port remains the state that it was before you attached the policy.

NOTE: Use the show healthck command to display the policy state. Use the show server real-name <name>
command to show the real server port state.

If health checking for a server port is disabled at the port profile level and also at the real server level, the SI will
continue to use the state that is based on the health check during the initial server bringup. The SI will not be able to
update the port's state if the state changes.
To enable health checking at the port profile level, enter commands such as the following:
ServerIron(config-port-80)# tcp keepalive enable
The commands above enable health checking for TCP port 80. For a UDP port, enter commands such as the
following:
ServerIron(config-port-53)# udp keepalive enable
To enable health checking at the real server level, enter commands such as the following:
ServerIron(config)# server real-name R1 10.10.10.10
ServerIron(config-rs-R1)# port 80 keepalive
You can enable health checking at the port profile level, at the real server level, or both. Health checking must be
enabled on at least one of these levels for the SI to use the health-check policy you attach to the port.
Health-Check Policy
Health-check policies consist of element-action expressions and logical expressions.
Element-action expressionConsists of the IP address of the server, the Layer 4 protocol (TCP or UDP),
and the application port on the server. For some applications, the element-action expression can also
include Layer 7 application-specific health check information.
Logical expressionA set of element-action expressions joined by the Boolean operators OR, AND or
NOT.
o To create a health-check policy that is successful if at least one of the applications passes its
health check, use OR.
o To configure a health-check policy that is successful only if the SI receives a successful reply from
all servers and application ports in the policy, use the operator AND.
o To configure a health-check policy that is successful if none of the elements responds to the health
check, use the operator NOT.
You can use the same element-action expressions in multiple logical expressions if desired. You can configure up
to 254 health-check policies.
To use a health-check policy:
Configure the element-action expressions.
Configure the health-check policy using element-action expressions and logical expressions joined by the
operators AND or OR or NOT.
Attach logical expressions to application ports on specific real servers. A health check policy does not take
effect until you attach it to an application port on a server.

NOTE: NOTE: A health-check policy does not take effect (begin sending health check packets) until you
attach the policy to an application port on a real server.

Element-Action Expressions
An element-action expression contains the IP address, protocol (TCP or UDP), and application port number for an
application on an individual real server. If the SI allows you to customize Layer 7 information for the application,
then the element-action expression also can contain the customized Layer 7 information.
You also can change the following parameters for an application port when configuring an element-action
expression:
Health check type - For application types that are well-known to the SI, you can specify whether you want
to use the Layer 4 health check or the Layer 7 health check for the port. By default, the SI uses the Layer 7
health check if the port is one of the types well-known to the SI.
Health check interval - By default, the SI performs the health checks every 5 seconds. You can change the
interval to a value from 2 - 120 seconds.
Health retries - By default, if a reply to a heath check is not received, the SI will attempt the health check
two more times before concluding that the application has failed the health check. You can change the
number of retries to a value from 1 - 5 retries.
Health check state - By default, the health check is enabled as soon as you configure it. You can disable or
re-enable the health check from within the element-action expression for the check.
Specifying the IP Address and Application Port Parameters
To configure an element-action expression, enter commands such as the following. The commands in this example
specify the IP address of the real server and the application port on the server.
ServerIron(config-hc-check1)# port http
These commands change the CLI to the configuration level for an element-action expression, then specify the IP
address of the real server and the application port on the server. Since the specified application is well-known to the
SI, the SI automatically associates the default health check parameters for the port with the element-action
expression. In this example, the port is HTTP (80), so the SI associates the default HTTP health check parameters
with the element-action expression. By default, the SI sends a HEAD request for the default page, "1.0".

NOTE: You must specify the destination IP address before you can specify other health check parameters.
The software creates the health check policy only after you specify the destination IP address. If you try to
specify another parameter before the destination IP address, the CLI displays an error message such as the
following: Error - check1: Health-check element is undefined.

NOTE: If you do not specify the application port, the SI will list the status of the health check as FALSE
(failed).

To configure an element-action expression for a port number that is not well-known to the SI, enter commands such
as the following:
ServerIron(config-hc-check1)# port 8080
ServerIron(config-hc-check1)# protocol http
These commands configure an element-action expression for unknown port 8080 and associate the default health
check parameters for port 80 with the unknown port. To customize the Layer 7 health check parameters for a port,
add the information with the protocol command, as in the following example:
ServerIron(config-hc-check1)# port 8080
ServerIron(config-hc-check1)# protocol http url "GET/sales.html"
The protocol command in this example changes the Layer 7 health check parameters for this HTTP port to a GET
request for a page named "sales.html".
Syntax: [no] healthck <string> tcp | udp
This command begins configuration of the element-action expression. The <string> parameter specifies the name
for the expression and can be up to 20 characters long. The tcp | udp parameter specifies whether you are
configuring an expression for a TCP application port or a UDP application port. There is no default.
This command specifies the IP address of the real server.
Syntax: [no] port <tcp/udp-port>
This command specifies the application port number.

NOTE: If you do not specify the server IP address and the application port, the SI will list the status of the
health check as FALSE (failed).

You can specify any valid number, or one of the following port names well-known to the SI:
dns - port 53
ftp - port 21. (Ports 20 and 21 both are FTP ports but in the SI, the name "ftp" corresponds to port 21.)
http - port 80
imap4 - port 143
ldap - port 389
nntp - port 119
ntp - port 123
pop2 - port 109
pop3 - port 110
radius - port 1812
radius-old - the SI name for UDP port 1645, which is used in some older RADIUS implementations instead
of port 1812
smtp - port 25
snmp - port 161
ssl - port 443
telnet - port 23
tftp - port 69

NOTE: If you enter the no port <tcp/udp-port> command to remove the port, the SI also removes the
protocol <tcp/udp-port> command (see below) if the port is well-known to the SI. This is because the SI
automatically uses the protocol that matches the well-known port. Otherwise, the SI does not remove the
protocol. You must remove it separately.

Syntax: [no] protocol <tcp/udp-port>
This command specifies a port whose health-check mechanism you want to use for the port specified by the port
command. You need to use this command only if the port specified by the port command is not one of the ports
listed above but the port is the same type as one of the ports listed above. For example, use this command if you
want to use the DNS health-check mechanism for a port other than 53.

NOTE: You must specify the port using the port command before you enter the protocol command. If the
port command specified a port that is well-known to the SI, the SI automatically uses the protocol that
matches the port; you do not need to specify it and cannot change it.

NOTE: If you remove the Layer 7 health check information (using a no protocol command), the application
will fail the health check. If you want the SI to use a Layer 4 health check instead, enter the l4-check
command to change the health-check type to Layer 4.

If the port is not well-known to the SI and you do not specify a protocol for the Layer 7 health check, but
Layer 7 health checking is enabled for the port, the port will fail the health check.

See "Changing the Health-Check Type" below.

For some ports, you also can customize the Layer 7 information sent with the health check. Here is the syntax.
Syntax: [no] protocol http | 80
[url "[GET | HEAD] [/]<URL-page-name>" |
port http status_code <range> [<range>[<range>[<range>]]] |
content-match <matching-list-name>]
This command changes one of the following HTTP health-check parameters. To change more than one of these
parameters, enter a separate protocol http or protocol 80 command for each parameter.
url "[GET | HEAD] [/]<URL-page-name>" - This parameter specifies whether the HTTP health check
performs a GET request or a HEAD request. For GET requests, you can specify the page that is requested.
By default, a GET request asks for page "1.0".
port http status_code <range> [<range>[<range>[<range>]]] - This parameter changes the HTTP status
codes that the SI will accept as valid responses. Each <range> specifies the low number and high number
in a range of status codes. 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. For SLB, the default status code range is 200 - 299. If the
server's reply to the health check contains a status code within this range, the SI considers the HTTP
application to be healthy.
content-match <matching-list-name> - This parameter attaches a match list for an HTTP content
verification health check to the real server. An HTTP content verification health check is a type of Layer 7
health check in which the SI examines text in an HTML file sent by a real server in response to an HTTP
keepalive request. The SI 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 attached to one or more real
servers. The following is an example of the commands used to set up a matching list. For information on
how to configure the match lists, see "HTTP Content Matching Lists".
Syntax: [no] protocol dns | 53 [addr_query "<name>" | zone <zone-name>]
This command changes one of the following DNS health-check parameters. To change more than one of these
parameters, enter a separate protocol dns or protocol 53 command for each parameter.
addr_query "<name>" - This parameter specifies a domain name to be requested from the real server by
the SI. If the server successfully responds with the IP address for the domain name, the server passes the
health check. There is no default.
zone <zone-name> - This parameter specifies a DNS zone name. The SI sends a Source-of-Authority
(SOA) request for the zone name. If the server is authoritative for the zone and successfully responds to
the SOA request, the server passes the health check. There is no default.

NOTE: If you do not configure one of these parameters, the DNS port will fail the health check.

Syntax: [no] protocol radius | 1812 [username <string>] | [password <string>] | [key <string>]
This command changes one of the following RADIUS health-check parameters. The health check requests values
that are configured on the RADIOS server. To change more than one of these parameters, enter a separate
protocol radius or protocol 1812 command for each parameter.
username <string> - This parameter specifies an authentication username on the server.
password <string> - This parameter specifies an authentication password on the server.
key <string> - This parameter specifies an authentication key on the server.
Syntax: [no] protocol ldap | 389 [<num>]
This command changes the LDAP version. The health check sent by the SI differs depending on the version. You
can specify 2 or 3. The default is 3.
Using SSL Health Checks in a Health Check Policy
When SSL health checks are used in a health check policy, by default the simple SSL health check is used: The SI
sends the server an SSL client hello with the SSL SID set to 0; if the server responds, it passes the health check.
However, if you use the protocol ssl use-complete command in a health check policy, it causes the SI to negotiate
an SSL connection and send a GET or HEAD request to the server.

NOTE: Simple SSL health check is the default for software release 7.2.x. Full SSL health check is the default
for software release 7.1.x.

For example, the following commands create a health check policy to test IP address 10.10.10.50, using SSL health
checks.
ServerIron(config-hc-check4)# port ssl
ServerIron(config-hc-check4)# protocol ssl use-complete
ServerIron(config-hc-check4)# protocol ssl url "GET /secure.htm"
ServerIron(config-hc-check4)# protocol ssl status-code 200 200
ServerIron(config-hc-check4)# protocol ssl content-match m1
ServerIron(config-hc-check4)# enable
ServerIron(config-hc-check4)# exit
Syntax: [no] protocol ssl use-complete
Changing the Health-Check Interval and Retries
By default, the SI performs a health check every 5 seconds. If a reply is not received, the SI will attempt the health
check two more times before concluding that the application has failed the health check. You can change the
number of seconds the SI will wait for a reply to a health check and the number of retries.

NOTE: The number of retries is the total number of attempts the SI will make. Thus, if you use the default
interval and retries values, the SI will send up to three health-check packets, at 5-second intervals. If a server
does not respond within 15 seconds of the time the SI sent the first health-check packet, the server fails the
health check and the SI concludes that the server is not available.

To change the interval for a health check, enter a command such as the following at the configuration level for the
element-action expression that contains the health check:
ServerIron(config-hc-check1)# interval 30
Syntax: [no] interval <secs>
You can specify from 2 - 120 seconds. The default is 5 seconds.
To change the number of retries for a health check, enter a command such as the following at the configuration
level for the element-action expression that contains the health check:
ServerIron(config-hc-check1)# retries 4
Syntax: [no] retries <num>
You can specify from 1 - 5 retries. The default is 3 retries.

NOTE: You also can globally change the interval and retries for a an application port by editing its port
profile. See "Adding a TCP or UDP Port, Specifying the Port Type, and Configuring the Keepalive Health
Check".

Changing the Health-Check Type
For TCP application ports, you can change the health-check type between Layer 4 and Layer 7. By default, the SI
performs a Layer 7 health check in the following cases:
The port is one of the following ports well-known to the SI:
o FTP - port 21. (Ports 20 and 21 both are FTP ports but on the SI, the name "FTP" corresponds to
port 21.)
o HTTP - port 80
o IMAP4 - port 143
o LDAP - port 389
o MMS - port 1755
o NNTP - port 119
o PNM - port 7070
o POP3 - port 110
o RTSP - port 554
o SMTP - port 25
o SSL - port 443
o TELNET - port 23
The port is not well-known to the SI but you used the protocol command to specify the protocol of one of
the well-known ports. By specifying the protocol, you configure the SI to use the protocol's Layer 7 health-
check method for the port.
If the TCP port is not one of the ports above or you did not specify a Layer 7 health-check method (using the
protocol command), the SI uses the Layer 4 health check for TCP.

NOTE: Changing the health-check type for UDP application ports has no effect. If the application port is
RADIUS (1812) or DNS (53) or uses the health-check method of one of these ports, the SI uses a Layer 7
health check. Otherwise, the SI uses the Layer 4 health check for UDP.

The Layer 7 health-check methods differ depending on the application:
TCP - The SI attempts to engage in a normal three-way TCP handshake with the port on the real server:
o The SI sends a TCP SYN packet to the port on the real server.
o The SI expects the real server to respond with a SYN ACK.
o If the SI receives the SYN ACK, the SI sends a TCP RESET, satisfied that the TCP port is alive.
UDP - The SI sends a UDP packet with garbage (meaningless) data to the UDP port.
o If the server responds with an ICMP "Port Unreachable" message, the SI concludes that the port is
not alive.
o If the server does not respond at all, the SI assumes that the port is alive and received the garbage
data. Since UDP is a connectionless protocol, the SI and other clients do not expect replies to data
sent to a UDP port. Thus, lack of a response is a good outcome.
The command in this example configures the SI to use the Layer 4 health check for the application port in the
element-action expression. Since the application port in this element-action expression is HTTP, the SI will use the
Layer 4 health check for TCP.
Syntax: [no] l4-check | l7-check
Changing the Health-Check State
Once you configure an element-action expression, the health check in the expression is enabled by default. To
disable the health check, enter the following command at the configuration level for the element-action expression:
ServerIron(config-hc-check1)# disable
Syntax: [no] disable | enable

NOTE: Health checking (keepalive) also must be enabled on the port profile level or the real server level.
Otherwise, the health-check policy is used during initial bringup of the server but is not used for periodic
health checks after the server is brought up.

NOTE: If the health check for an application on a server is disabled, the SI assumes that the server and
application are healthy and continues to send client requests to the server.

NOTE: If you change the health-check state from within the element-action expression, this state overrides
the health-check state configured in the port profile for the application port or in the real server
configuration.

NOTE: You can globally enable or disable all health-check policies. See "Globally Disabling All Health-Check
Policies".

Health-Check Policy
A health-check policy consists of one or more element-action expressions. When a logical expression contains
multiple element-action expressions, the policy also contains the logical operator AND or OR or NOT.
You can use a health-check policy as an element-action expression in another policy.
To configure a health-check policy, enter commands such as the following:
ServerIron(config)# healthck "httpsrvr" boolean
ServerIron(config-hc-httpsrvr)# and "check1" "check2"
These commands configure a health-check policy that uses the element-action expressions "check1" and "check2".
Since the AND operator is used, the real servers in both "check1" and "check2" must reply successfully for the
health check to be successful. If only one of the servers replies, the health check is unsuccessful and the SI stops
using all the server application ports in the health-check policy "httpsrvr".
Syntax: [no] healthck "<policy-name>" boolean
Syntax: and | or "<element-name>" "<element-name>"
The <policy-name> parameter specifies the name of the health-check policy. The name can be up to 20 characters
long. The name cannot contain blanks.
The and | or | not parameter specifies a logical operator in the health-check policy. You can enter two element-
action expressions along with the logical operator and or or or not.
If you specify and, the policy evaluates to true only if all elements (IP addresses) respond to the health
check.
If you specify or, the policy is true if at least one of the elements responds to the health check.
If you specify not, the policy is true if none of the elements responds to the health check.

NOTE: When a boolean ICMP health check policy is applied on a SIXL's interface, you should add a static
route for destination IP subnet that the health check policy is pointing to. This will allow the SIXL to use that
static route instead of default route to send health check ICMP requests and correctly learn the next hop
MAC address of the interface.

If you are configuring a boolean UDP health check policy a link, define the static next hop MAC address along with
a VLAN ID for on that link; otherwise, the SI cannot learn the next-hop-mac-address of that link. Enter
commands such as the following to define a static next-hop-mac-address and a vlan-id:
ServerIron(config-link-link3)# next-hop-mac-address 00e0.5208.dd8e vlan-id 40
The address 00e0.5208.dd8e is the MAC address of Link3's access router interface. Vlan-id 40 is the SIs interface
that is used to connect Link3's access router is in vlan 40
Syntax: next-hop-mac-address <mac-address> vlan-id <vlan#>
Nested Health-Check Policy
If you want to use a single health-check policy to test more than two IP addresses, configure health-check policies
for all the IP addresses, and use them in another health-check policy. For example, to create a health-check policy
that tests four IP addresses, enter commands such as the following:
ServerIron(config-hc-check1)# healthck check2 tcp
The commands above configure four element-action expressions, one for each of four servers. The following
commands configure two health-check policies, each of which contains two of the element-action expressions.
ServerIron(config-hc-check4)# healthck nested1 boolean
ServerIron(config-hc-nested1)# or check1 check2
ServerIron(config-hc-nested1)# healthck nested2 boolean
ServerIron(config-hc-nested2)# or check3 check4
The following command creates a health-check policy that contains the two policies configured above. The result is
a single health-check policy for all four IP servers.
ServerIron(config-hc-nested2)# healthck checkall boolean
ServerIron(config-hc-checkall)# or nested1 nested2
In this example, the OR logical operator is used in all the policies. Thus, the "checkall" health check is successful if
at least one of the four servers responds. To create more restrictive policies, you can use the AND logical operator.
For example, if the AND operator is used in this configuration instead of OR, the health check is successful only if
all four servers respond.
You also can combine policies that use AND with policies that use OR in nested health-check policies.
Attaching a Health-Check Policy to an Application Port on a Server
After you configure logical expressions, you can attach them to application ports on real servers. The SI does not
begin sending health-check packets until you attach the policy to a real server port.
To attach a health-check policy to an application port on a server, enter commands such as the following:
ServerIron(config)# server real-name R1 10.10.10.50
ServerIron(config-rs-R1)# port 80 healthck "check1"
This command configures the SI to base the health of application port 80 on real server R1 on the results of the
check1 health-check policy.
Globally Disabling All Health-Check Policies
You can easily disable all the health-check policies configured on the SI. To do so, enter the following command at
the global CONFIG level of the CLI:
ServerIron(config)# no server l4-check

NOTE: This command also disables the TCP and UDP Layer 4 health checks for all applications that are not
associated with a health-check policy.

Syntax: [no] server l4-check
To re-enable the health-check policies, enter the following command.
ServerIron(config)# server l4-check

NOTE: The server l4-check command does not enable a policy if its element-action expressions contain the
disable command. In this case, the policy remains disabled.

Boolean Health-Check Policies

NOTE: This section applies only to software release 07.3.02 and releases prior to 07.3.05 for the SIXL. To use
Boolean health-check policies SIXL running release 7.3.05 and higher, see "Boolean Health-Check Policies".

You can configure a group of Layer 3 health checks as a health-check policy and associate the group with a specific
TCP or UDP application port on an individual virtual IP address (VIP). You can use health-check policies to check
the health of downstream routers and bring a VIP down if a router fails a health check.
Depending on the conditions you specify when you configure a health-check policy, the SI will bring the VIP down in
one of the following cases:
Any one of the health checks fails (AND condition)
All of the health checks fail (OR condition)
For finer control, you can combine OR and AND conditions.
The health checks consist of an ICMP echo packet, the same type of packet used by the SI for other Layer 3 health
checks. By default, the SI performs the VIP-based health checks you have configured by sending an ICMP ping to
the specified IP address every 400 milliseconds.
If the SI receives one or more responses within 1.2 seconds, the SI concludes that the VIP is healthy.
Otherwise, the SI reattempts the health check by sending another ping. The SI reattempts an unanswered
health check up to two more times before concluding that the VIP is unhealthy.

NOTE: If a VIP fails a health check, the SI brings the VIP down. However, the VIP's state listed by the show
server virtual command remains "enabled".

Configuring a Health-Check Policy
Health-check policies consist of element-action expressions and logical operators.
Element-action expression - In the case of Layer 3 health checks, an element-action expression consists of
the IP protocol to be used (ICMP) and the IP address to be checked.
Logical operator - A logical operator is the Boolean operator OR or AND. To configure a health-check policy
that requires a reply from all IP addresses in the policy, use the operator AND. To create a policy that is
successful if at least one of the addresses replies, use OR.
You can use the same element-action expressions in multiple logical expressions if desired. You can configure up
to 254 health-check policies. The default maximum number you can configure is 128. You can change the
maximum to a number from 64 - 254.
To use a health-check policy:
Configure the element-action expressions.
Configure the health-check policy using element-action expressions and the logical operator AND or OR.
Bind logical expressions to application ports on specific VIPs. A health check policy does not take effect
until you bind it to an application port on a VIP.
Here is an example of how to configure and apply a Layer 3 health-check policy. The example is described in detail
in the following sections.
ServerIron(config)# healthck Rtr2-ck1 icmp
ServerIron(config-hc-Rtr2-ck1)# dest-ip 10.168.2.56
ServerIron(config-hc-Rtr2-ck1)# healthck Rtr2-ck2 icmp
ServerIron(config)# healthck Router2 boolean
ServerIron(config-hc-Router2)# and Rtr2-ck1 Rtr2-ck2
ServerIron(config)# server virtual-name VIP1 1.1.1.1
ServerIron(config-vs-VIP1)# port http healthck Router2
These commands configure two element-action expressions, "Rtr2-ck1" and "Rtr2-ck2", and use them in a health-
check policy called "Router2". The last two commands apply the health-check policy to the HTTP port on VIP1. For
more information, see the following sections.
Configuring an Element-Action Expression
For Layer 3 health-check policies, an element-action expression contains an IP address. To configure an element-
action expression, enter commands such as the following:
ServerIron(config)# healthck Rtr2-ck1 icmp
ServerIron(config-hc-Rtr2-ck1)# healthck Rtr2-ck2 icmp
The commands in this example configure two element-action expressions.
Syntax: [no] healthck <element-name> <protocol>
The <element-name> parameter specifies a name for the element-action expression. The name can be up to 20
characters long. The name cannot contain blanks.
The <protocol> parameter specifies the IP protocol to use for the health. The Layer health checks use ICMP echo
packets. Therefore, you must specify icmp.
The <ip-addr> parameter specifies the IP address to check.
Configuring a Health-Check Policy
A health-check policy consists of one or more element-action expressions. When a logical expression contains
multiple element-action expressions, the policy also contains the logical operator AND or OR.
You can use a health-check policy as an element-action expression in another policy.
To configure a health-check policy, enter commands such as the following:
ServerIron(config)# healthck Router2 boolean
ServerIron(config-hc-Router2)# and Rtr2-ck1 Rtr2-ck2
These commands configure a health-check policy that uses the element-action expressions "Rtr2-ck1" and "Rtr2-
ck2". Since the AND operator is used, the IP addresses in both "Rtr2-ck1" and "Rtr2-ck2" must reply successfully for
the health check to be successful. If only one of the addresses replies, the health check is unsuccessful and the SI
brings the VIP down.
Syntax: [no] healthck <policy-name> boolean
Syntax: < element-name>
Or
Syntax: and | or <element-name> <element-name>
The <policy-name> parameter specifies the name of the health-check policy. The name can be up to 20 characters
long. The name cannot contain blanks.
The and | or parameter specifies a logical operator in the health-check policy.
You can specify an element-action without also specifying a logical operator (AND or OR). In this case, the
policy checks the health of the specified element (IP address) and has a true result (the health check is
successful) if the element replies to the health check.
You can enter two element-action expressions along with the logical operator and or or.
o If you specify and, the policy evaluates to true only if all elements (IP addresses) respond to the
health check.
o If you specify or, the policy is true if at least one of the elements responds to the health check.
Configuring a Nested Health-Check Policy
If you want to use a single health-check policy to test more than two IP addresses, configure health-check policies
for all the IP addresses, and use them in another health-check policy. For example, to create a health-check policy
that tests four IP addresses, enter commands such as the following:
ServerIron(config)# healthck nest1 icmp
ServerIron(config-hc-nest1)# dest-ip 1.1.1.10
ServerIron(config-hc-nest1)# healthck nest2 icmp
The commands above configure four element-action expressions, one for each IP address. The following
commands configure two health-check policies, each of which contains two of the IP addresses.
ServerIron(config-hc-nest4)# healthck nested1 boolean
ServerIron(config-hc-nested1)# or nest1 nest2
ServerIron(config-hc-nested1)# healthck nested2 boolean
ServerIron(config-hc-nested2)# or nest3 nest4
The following command creates a health-check policy that contains the two policies configured above. The result is
a single health-check policy for all four IP addresses.
ServerIron(config-hc-nested2)# healthck check1 boolean
ServerIron(config-hc-check1)# or nested1 nested2
In this example, the OR logical operator is used in all the policies. Thus, the "check1" health check is successful if at
least one of the four IP addresses responds. To create more restrictive policies, you can use the AND logical
operator. For example, if the AND operator is used in this configuration instead of OR, the health check is
successful only if all four IP addresses respond.
You also can combine policies that use AND with policies that use OR in nested health-check policies.
Binding a Health-Check Policy to an Application Port on a VIP
After you configure logical expressions, you can bind them to application ports on VIPs. A health-check policy does
not take effect until you bind the policy to an application port on a VIP.
To bind a health-check policy to an application port on a VIP, enter commands such as the following:
ServerIron(config)# server virtual-name VIP1 1.1.1.1
ServerIron(config-vs-VIP1)# port http healthck Router2
This command configures virtual IP address VIP1 to use the heath-check policy named "Router2" to check the
health of HTTP (port 80) for the VIP.
Syntax: [no] port <tcp/udp-portnum> healthck <policy-name>
The <tcp/udp-portnum> parameter specifies a TCP or UDP application port. Specify the port number or one of the
following well-known port names:
dns - port 53
ftp - port 21. (Ports 20 and 21 both are FTP ports but in the SI, the name "ftp" corresponds to port 21.)
http - port 80
imap4 - port 143
ldap - port 389
nntp - port 119
ntp - port 123
pop2 - port 109
pop3 - port 110
radius - UDP port 1812
radius-old - the SI name for UDP port 1645, which is used in some older RADIUS implementations instead
of port 1812
smtp - port 25
snmp - port 161
ssl - port 443
telnet - port 23
tftp - port 69
The <policy-name> parameter specifies the health-check policy you want to use to check the Layer 3 health of a
device associated with the application port.
Changing the Memory Allocation for Health-Check Policies
By default, you can configure up to 128 health-check policies. To change the maximum number of health-check
policies that can be configured on the SI, enter commands such as the following:
ServerIron(config)# system-max healthck 254
ServerIron(config)# end
ServerIron# reload
Syntax: [no] system-max healthck <num>
The <num> parameter specifies the maximum number of health-check polices and can be a number from 64 - 254.
The default is 128.

NOTE: You must reload the software to place the change into effect.

show healthck
Use show healthck to display a list of the configured health-check policies and their current status:

Health-Check Policy Status
This
Field...
Displays...
Total
nodes
The number of health-check policies in the configuration. The number includes attached and
unattached policies.
Max
nodes
The maximum number of health-check policies you can configure.
Name The element-action expression or policy name.
Value The current value of the policy. The value can be one of the following:
TRUE - The most recent health check performed using this policy was successful. The SI
received a valid reply to the health check.
FALSE - The most recent health check performed using this policy was unsuccessful.
N/B - The health check is not bound to any VIP and thus is not in use.
N/A (Not Attached) - The policy is not attached to a real server.
Note: If the policy is disabled, the value is always TRUE. This is because the SI assumes a server is
healthy unless its health check is enabled and the server has not responded appropriately to the
health check.
Enable The state of the policy, which can be one of the following:
YES - The policy is enabled.
NO - The policy is disabled.
na (not applicable) - This field does not apply to the policy. This value indicates that the policy
is not attached to a real server.
Type The element-action expression or policy type. For Layer 3 health checks, this information consists of
ICMP and the IP address tested by the health check.
Values can be one of the following:
tcp - An element-action expression for a TCP application port.
udp - An element-action expression for a UDP application port.
and - A policy containing element-action expressions joined by AND.
or - A policy containing element-action expressions joined by OR.
Dest-IP For element-action expressions, the IP address of the real server. For policies, this field shows the
element-action expressions in the policy.
The value " - " indicates that the IP address has not been specified.
Port For element-action expressions, the application port. This field does not apply to policies.
Proto For element-action expressions, the health-check method to be used for the port.
Note: If the value is " - ", the protocol has not been specified and the port is not well-known to the SI.
Layer The type of health check, which can be one of the following:
l4-chk - Layer 4 TCP or UDP health check.
l7-chk - Layer 7 application-specific health check.
show healthck statistics
Use show healthck statistics to display health-check policy statistics:
ServerIron(config)# show healthck statistics
Ping Statistics:
Sent: 1524 Received: 1524
Invalid Replies: 0 Dropped Replies: 0
Health-Check Policy Statistics
This Field... Displays...
Sent The number of health-check packets sent by bound health-check policies.
Received The number of replies received. A received reply results in a true condition.
Note: Since the SI retries a health check if a reply is not received, a higher sent count than receive
count does not necessarily indicate a problem.
Invalid
Replies
The number of replies that were received that had an invalid ID. The SI is sometimes able to
resolve an invalid ID. If the SI cannot resolve the invalid ID, the device drops the reply and
increments the Dropped Replies counter.
Dropped
Replies
The number of replies that the SI dropped.
Clear Healthck Statistics
Use clear healthck statistics to clear health-check policy statistics:
Example:
ServerIron(config)# clear healthck statistics
Port Status the Syslog
The SI generates Syslog messages for changes to the Layer 4 or Layer 7 status of a real server. To display the
Syslog buffer on the SI, enter the following command:
ServerIron(config)# show log
Dynamic Log Buffer (50 entries):
03d02h47m38s:N:L4 server 192.168.1.170 danPC is down
03d02h46m18s:N:L4 server 192.168.1.170 danPC is up
03d02h46m08s:I:Interface ethernet5, state up
This example shows log entries for a real server named "danPC" with IP address 192.168.1.170. In this example,
the real server passed a Layer 4 or Layer 7 health check ("up"), but then failed a Layer 4 or Layer 7 health check
("down") later.
Syntax: show logging

NOTE: The log messages do not distinguish between Layer 4 and Layer 7 health checks. When the status
changes based on either type of health check, the SI logs the event as shown in this example.

Session Tables
The SI maintains state information for TCP and UDP connections in the session table. The session table contains
an entry for each TCP and UDP session between the SI and a client or real server. The SI uses the session table
entries for health checks, stateful failover in hot-standby configurations, and other functions.
Each entry in the session table is a session. A session consists of the following:
Source IP address
Source application port
Destination IP address
Destination application port
Protocol (TCP or UDP)
A connection consists of two sessions, a send session and a receive session. For example, a TCP connection
between a client and a server consists of two sessions, a client-to-server session and a server-to-client session.

NOTE: "Stateless" features such as stateless application ports and stateless health checks do not use session
table entries.

This section describes how to configure the following session table parameters:
Maximum number of sessions
Maximum age of TCP session entries
Maximum age of UDP session entries
Clock scale for TCP and UDP session age timers
Logging of session table entries
session-limit
Use server session-limit to limit the maximum number of total active sessions the SI allows. An active
session is a session entry in the SI's session table. Thus, a UDP or TCP session that has become idle but has not
yet timed out (according to the UDP or TCP age timer) is an "active" session in this table.
Syntax
[no] server session-limit <value>
Up to 1,000,000 sessions are supported on a SI XL (with 32MB memory installed). Possible values are 32,768 -
1,000,000 with a default value of 524,288.
Example
ServerIron(config)#server session-limit 50000
ServerIron(config)#write memory
ServerIron(config)#end
ServerIron#reload
To place this change into effect, you must save the change to the startup-config file, then reload the software.
session-max-idle
Starting with Release 07.3.07, the SI supports fast session aging. When fast session aging is enabled with server
session-max-idle, the SI can rapidly age out sessions when the number of available free sessions drops below
specified threshold values.
The threshold values are specified as percentages of the maximum number of sessions available on the SI (the
"max-sessions" value). The number of free sessions that trigger fast session aging is calculated using the following
formula:
number of free sessions = (max-sessions * threshold) / 100
For example, if the max-sessions value on the SI is 500,000 sessions, and the threshold is 30%, then fast session
aging is triggered when the number of free sessions reaches 150,000 or fewer; that is (500,000 * 30) / 100.
Two thresholds can be configured for fast session aging: the fast-age threshold and the random threshold.
Fast-age thresholdWhen the number of free sessions drops below the fast-age threshold, sessions
older than a specified time are aged out.
Random thresholdWhen the number of free sessions drops below the random threshold, sessions are
aged out randomly, without regard to session age. The random threshold can be equal to or lesser than the
fast-age threshold.
In the example, if the fast-age threshold is reached, sessions as old as or older than a specified amount of time (for
example, 5 minutes) are aged out until the number of available sessions climbs above 150,000. If the random
threshold is reached, sessions are aged out at random until the number of available sessions climbs above
150,000.

NOTE: By default, the maximum number of active sessions on the SIXL is 1,000,000; you can change this with
the server session-limit command.

Fast session aging is disabled by default.
Syntax
[no] session-max-idle <max-idle-time> [<fast-age-threshold> <random-threshold>]
Parameters
The <max-idle-time> specifies the number of minutes allowed for idle sessions when <fast-age-threshold>
is configured. When <fast-age-threshold> is reached, sessions that are the same as and older than the
threshold are aged out until the number of free sessions exceeds <fast-age-threshold>. The <max-idle-
time> can be from 1 - 30 minutes. The default is 0 minutes (disabled). To enable fast session aging, you must
specify a value for <max-idle-time> greater than 0.
When the number of available sessions drops below the <fast-age-threshold>, sessions older than <max-
idle-time> are aged out until the number of free sessions exceeds the threshold. The <fast-age-threshold> is
expressed as a percentage of the maximum number of sessions available on the SI. The <fast-age-threshold>
can be from 10 - 70 percent. The default is 33 percent.
When the number of available sessions drops below the <random-threshold>, sessions are aged out randomly,
without regard to session age, until the number of free sessions exceeds the threshold. The <random-threshold>
is expressed as a percentage of the maximum number of sessions available on the SI. The <random-threshold>
can be from 1 - 30 percent. The default is 0 percent (disabled).

NOTE: Even though the <max-idle-time> value is not used with the random-age threshold, you must still
specify a value for <max-idle-time> when configuring the random threshold, since specifying a value for
<max-idle-time> enables the fast session aging feature.

Example
SI(config)#server session-max-idle 5 30 10
show server sessions
Two fields in the output of the show server sessions command display information about the sessions subject to
fast aging.
The following is an example of the show server sessions output. The fields related to fast session aging are
highlighted in bold.
ServerIron# show server sessions

Avail. Sessions = 524282 Total Sessions = 524288
Total C->S Conn = 0 Total S->C Conn = 0
Total Reassign = 0 Unsuccessful Conn = 0
Fast-aged : total = 0 last 60 sec = 0
Random-aged : total = 0 last 60 sec = 0
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active

Real Server State CurrConn TotConn TotRevConn CurrSess PeakConn

rs1 1 0 0 0 0 0
rs2 1 0 0 0 0 0
Syntax: show server sessions
If the fast-age threshold is configured, the command displays the total number of sessions that were aged out
because the number of free sessions dropped below the fast-age threshold, as well as the number of these
sessions that were aged out in the last 60 seconds.
If the random threshold is configured, the command also displays the total number of sessions that were aged out at
random because the number of free sessions dropped below the random threshold, as well as the number of
sessions that were aged out randomly in the last 60 seconds.
clear server fast-age-counters
Use clear server fast-age-counters to clear the statistics counters for fast session aging.
Example:
ServerIron(config)# clear server fast-age-counters
This command resets the "Fast-aged : total" counter and corresponding "last 60 sec" counter as displayed by show
server session.
clear server random-age-counters
If the random threshold is configured, you can use clear server random-age-counters to clear the statistics
counters for sessions aged out randomly.
Example:
ServerIron(config)# clear server random-age-counters
This command resets the "Random-aged : total" counter and corresponding "last 60 sec" counter as displayed by
show server session.
tcp-age
The TCP age specifies how many minutes a TCP server connection can remain inactive before the SI times out the
session. Use server tcp-age <value> to modify the server TCP age, where <value> is from 2 - 60 minutes.
The default is 30 minutes.
If you change the TCP age, the change affects only new TCP sessions that start after you make the change. The
maximum age for sessions that are already in the session table does not change.

NOTE: This parameter globally sets the age for all TCP ports. To override the setting for an individual TCP
port, change that port's profile. See "Overriding the Global TCP or UDP Age".

Example
ServerIron(config)#server tcp-age 20
udp-age
Use [no] server udp-age <minutes> to modify the aging out parameter for inactive UDP server connections,
where <minutes> is from 2 - 60 minutes. The default is 5 minutes, except for DNS and Radius; their default age is
2 minutes.
Example
To modify the server UDP age to 20 minutes from the default value of 5 minutes:
ServerIron(config)#server udp-age 20
This parameter globally sets the age for all UDP ports. To override the setting for an individual TCP port, change
that port's profile. See "Overriding the Global TCP or UDP Age".
The SI immediately deletes a UDP DNS or RADIUS session table entry when the SI receives a reply for the
application from a real server. If desired, you can configure the SI to age these ports like other UDP ports, using the
UDP age timer. See "Normal UDP Aging for DNS and RADIUS".

For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default
value unless udp-normal-age is configured on the port, under the virtual server port definition, port dns udp-
normal-age. (See "Normal UDP Aging for DNS and RADIUS".) The default UDP age will always be 2 minutes
unless udp-normal-age is configured.
clock-scale
The SI uses a configurable clock scale for the following session timers:
o TCP age
o UDP age
Use server clock-scale to adjust the clock scale for configurations that require TCP or UDP timeouts longer
than the maximum configurable value (60 minutes).
Syntax
[no] server clock-scale <multiplier>
The <multiplier> can be a value from 1 - 20. The default is 1.
Example
ServerIron(config)#server clock-scale 2
When you set the clock scale to 2, the TCP and UDP age timer values are multiplied by 2. Thus, a TCP age of 60
would then be equivalent to 120 minutes instead of 60 minutes.
Syslog for Session Table Entries
You can configure the SI to send a message to external Syslog servers when the software creates a session table
entry. The messages indicate the following information:
Source IP address
Source TCP or UDP application port
Destination IP address
Destination TCP or UDP application port
Layer 4 protocol (TCP or UDP)
Message time (measured in units of 100 milliseconds, relative to system uptime)
URL (optional)
Cookie (optional)
Internet (applies to TCS only)
You can enable TCP/UDP logging on a global basis for all TCP and UDP ports or for individual TCP or UDP ports.
When you enable TCP/UDP logging, you can specify whether all new session table entries generate log messages
or only the entries that are used for Source NAT.
In addition, you can enable logging for URL or Cookie information. The URL logging option applies only when URL
switching is enabled. The Cookie logging option applies only when Cookie switching is enabled.
Here is an example of a Syslog message for a session:

The "Internet" parameter at the end of the message applies only to TCS, and indicates that the SI sent the client
request to the Internet instead of to a cache server.
The time value in this example is in the format for devices on which the system time add date have not been set.
For information, see the Foundry ServerIron Command Line Interface Reference.

NOTE: The feature description and command syntax use the terms "session" and "connection". A connection
consists of multiple sessions, for the send and receive directions.

NOTE: Since the log messages are generated when the software creates a session table entry, features that
do not use session table entries do not result in log messages. For example, if you configure a TCP or UDP
port to be stateless, the SI does not create session table entries for the port and therefore does not generate
log messages for the port.

connection-log
Use server connection-log to enable TCP/UDP session logging. When enabled, the SI sends a message to
the external Syslog servers when the software creates a session table entry. You can enable session logging
globally for all ports or on an individual TCP or UDP port basis.
Syntax
[no] server connection-log all | src-nat [url] [cookie]
Parameters
allenables logging for all sessions.
src-natenables logging only for sessions that are used for Source NAT.
urlenables logging of URL information for sessions that contain a URL.
cookieenables logging of Cookie information for sessions that contain a Cookie.

NOTE: The URL logging option applies only when URL switching is enabled. The Cookie logging option applies
only when Cookie switching is enabled.

Examples
To globally enable logging for all new session table entries:
ServerIron(config)#server connection-log all
To enable logging only for new sessions that are used for Source NAT:
ServerIron(config)#server connection-log src-nat
To enable session logging for a specific TCP or UDP port:
ServerIron(config)#server port 80
ServerIron(config-port-80)#connection-log all url cookie
Slow-Start Mechanism
When the SI begins sending client requests to a real server that has recently gone online, it allows the server to
ramp up by using the slow-start mechanism. The slow-start mechanism allows a server (or a port on the server) to
handle a limited number of connections at first and then gradually handle an increasing number of connections until
the maximum is reached.
The SI uses two kinds of slow-start mechanisms:
The non-configurable server slow-start mechanism applies to a real server that has just gone online
The configurable port slow-start mechanism applies to individual TCP application ports that have just
been activated on a real server
Overview
The SI uses the server slow-start mechanism to adjust the maximum number of connections that can be established
for a real server that has just gone online. The SI begins with a connection limit that is lower than the maximum
configured value (which is one million by default) and gradually increases this connection limit until the maximum
configured value is reached.
The server slow-start mechanism is especially useful when least connections is the distribution predictor. Without
the server slow-start mechanism, a server that is just brought online could receive all the new connections in a
flurry, which could bring the server down. Many servers cannot handle more than 2,000 new connections per
second.

NOTE: The server slow-start mechanism is always applied to all real servers when they are brought online.
Unlike the slow-start mechanism for individual ports, described in the next section, the server slow-start
mechanism is not configurable.

The two graphs in Figure 5.3 illustrate how the server slow-start mechanism ramps up the connections for a real
server during the 30-second slow-start period. The graph on the left shows the rate at which the number of
connections increases over the slow-start period. The graph on the right shows how the maximum number of
connections the SI allows for the real server increases over the slow-start period.
Figure 5.3 Slow-start mechanism for a real server

The graph on the left shows the rate at which the SI allows connections for a given real server, as follows:
From the time the real server is brought online until 10 seconds afterwards, the SI allows the real server up
to 10 new connections every second.
From 10 seconds to 30 seconds, the SI allows up to 20 new connections every second.
After 30 seconds, the connection flow control delivered by the slow-start mechanism ends, and the SI
allows up to the maximum number of connections to the server. The maximum number of allowed
connections for a real server is set by the max-conn command; this is one million connections by default.
The graph on the right shows how the maximum number of connections allowed for the real server increases over
the 30-second slow-start period. The following table lists the maximum number of connections a real server can
have during each second of the slow-start period.
Seconds after going online Max. Connections Seconds after going online Max. Connections
1 10 16 220
2 20 17 240
3 30 18 260
4 40 19 280
5 50 20 300
6 60 21 320
7 70 22 340
8 80 23 360
9 90 24 380
10 100 25 400
11 120 26 420
12 140 27 440
13 160 28 460
14 180 29 480
15 200 30 500
When the slow-start period ends after 30 seconds, the maximum number of connections a real server can have is
determined by the max-conn setting for the real server; this is one million connections by default.

NOTE: When you disable and re-enable a real server, the SI will go through the slow-start mechanism for the
server if it is not disabled. When you disable and re-enable a real-server port, the SI does not go through the
port level slow-start mechanism.

Port Slow-Start Mechanism
When individual TCP application ports on a real server are activated, they are allocated connections using the port
slow-start mechanism, which works differently from the server slow-start mechanism described in the previous
section.
When a port on a real server becomes active, the SI applies the default slow-start mechanism to regulate how
fast connections for the port are established. In addition, you can set up a user-configured slow-start mechanism
that regulates how fast connections are established for specific ports on specific real servers. The following sections
explain how the default slow-start mechanism works, as well as how to set up a user-configured slow-start
mechanism and apply it to a port on a real server.
Default Port Slow-Start Mechanism
By default, when a port is activated, the SI gives it 60 seconds of warm-up time. Over this period, the SI gradually
increases the number of connections it allows for the port. The default slow-start mechanism is always applied to all
ports when they are first brought online, unless they are configured to use a user-configured slow-start mechanism.
The two graphs in Figure 5.4 illustrate how the default slow-start mechanism ramps up the connections for a port on
a real server. The graph on the left shows the rate at which the number of connections increases over the slow-start
period. The graph on the right shows how the maximum number of connections the SI allows for the port on the real
server increases over the slow-start period.
Figure 5.4 Default slow-start mechanism for a port

The graph on the left shows the rate at which the SI allows connections for a given port on a real server, as follows:
From the time the port is activated until 10 seconds afterwards, the SI allows the port up to 10 new
connections every second.
After 60 seconds, the connection flow control delivered by the slow-start mechanism ends, and the SI
allows up to the maximum number of connections for the port on the server. The maximum number of
allowed connections for a real server is set by the max-conn command; this is one million connections by
default.
The graph on the right shows how the maximum number of connections allowed for the port on the real server
increases over the slow-start period. The following table lists the maximum number of connections a port can have
at 10-second intervals.
Seconds after port activated Max. Connections
10 100
20 300
30 600
40 1,000
50 1,500
60 2,500
When the slow-start period ends after 60 seconds, the maximum number of connections a port on a real server can
have is determined by the max-conn setting for the real server; this is one million connections by default.
User-Configured Port Slow-Start Mechanism
You can configure how fast the SI ramps up a particular port on a particular real server by setting up a user-
configured slow-start mechanism. Unlike the default port slow-start mechanism, which applies to all ports on all real
servers, a user-configured slow-start mechanism is applied to a specific port on a specific real server.
A user-configured slow-start mechanism sets the rate at which the SI allows connections for a port over two
configurable intervals (which comprise the slow-start period), as well as a limit for the total number of connections
that the port on the real server can have during the time the server is active.
Setting up a user-configured slow-start mechanism consists of two steps:
1. Setting up a slow-start list for a port
2. Applying the slow-start list to a port on a real server
For example, the following commands set up a slow-start list for port 80 (HTTP):
ServerIron(config-port-80)# slow-start 101 10 30 20 30 600
ServerIron(config-port-80)# exit
Syntax: slow-start <list-id> <rate1> <interval1> <rate2> <interval2> <max-connections>
In the slow-start command, the <list-id> parameter identifies the slow-start list. This ID can be a number from 1 -
1000000. When you apply the slow-start list to a port on a real server, you refer to the slow-start list by this ID
number. You can create multiple slow-start lists for a given port and assign them each an ID number.
The <rate1> parameter specifies the number of connections per second allowed for the port during the first interval.
This can be a number from 1 - 1000000. From the time the port is activated until the end of the first interval, the SI
allows the port on the real server up to this number of new connections every second.
The <interval1> parameter specifies the length of the first interval in seconds. This can be a number from 1 -
1000000.
The <rate2> parameter specifies the number of connections per second allowed for the port during the second
interval. This can be a number from 1 - 1000000. From the end of the first interval until the end of the second
interval, the SI allows the port on the real server up to this number of new connections every second.
The <interval2> parameter specifies the length of the second interval in seconds. This can be a number from 1 -
1000000. The number of seconds in the first interval, plus the number of seconds in the second interval, comprise
the slow-start period. In this example, <interval1> is 30 seconds, and <interval2> is 30 seconds, so the slow-start
period is 60 seconds.
The <max-connections> parameter sets a ceiling for the number of concurrent connections allowed for the port
during the time the server is active. This can be a number from 1 - 1000000. No more than this number of
connections can be established for the port on the real server where this slow-start mechanism is applied.
Once you have created a slow-start list, you apply it to a port on a real server; for example:
ServerIron(config-rs-rs1)# port http slow-start 101
Syntax: port <port> slow-start <list-id>
The port http slow-start 101 command binds slow-start list 101 (defined for port 80 above) to port 80 (HTTP) on
real server rs1.
Using the slow-start list defined above, the two graphs in Figure 5.5 illustrate how a user-configured slow-start
mechanism ramps up the connections for a port on a real server. The graph on the left shows the rate at which the
number of HTTP connections increases over the slow-start period. The graph on the right shows how the maximum
number of HTTP connections the SI allows for real server rs1 increases over the slow-start period.
Figure 5.5 Example of a user-configured slow-start mechanism for port 80 (HTTP) on a real server

The graph on the left shows the rate at which the SI allows HTTP connections for real server rs1, as follows:
From the time port 80 (HTTP) on real server rs1 is activated, until 30 seconds afterwards (until the end of
interval 1), the SI allows the real server up to 10 (rate 1) new HTTP connections every second.
From 30 seconds to 60 seconds (until the end of interval 2), the SI allows up to 20 (rate 2) new HTTP
connections every second.
After 60 seconds (interval 1 plus interval 2), the slow-start period ends, and the SI allows up to the
maximum number of connections for the server set by the <max-connections> parameter in the slow start
list.
The graph on the right shows how the maximum number of possible HTTP connections for real server rs1 increases
over the slow-start period:
Ten seconds after going online, the maximum number of HTTP connections real server rs1 can have is
300: a maximum of 10 (rate 1) new HTTP connections per second for 30 (interval 1) seconds equals 300
total HTTP connections for real server rs1.
After 30 seconds, the maximum number of HTTP connections for real server rs1 increases by 20 (rate 2)
connections per second, until 600 HTTP connections (the ceiling specified by the <max-connections>
parameter in the slow-start list) is reached. This ceiling of concurrent 600 HTTP connections applies for the
entire time the server is active; the SI allows the server no more than this number of concurrent HTTP
connections.
Applying a User-Configured Slow-Start Mechanism to Multiple
Ports
To apply a user-configured slow-start mechanism to more than one port, create slow-start lists for each port and
apply them to ports on one or more real servers. For example, to configure a slow-start mechanism for HTTP (port
80) and SSL (port 443):
ServerIron(config-rs-rs3)# port ssl
ServerIron(config-rs-rs3)# port ssl slow-start 101
The commands above create two slow-start lists for port 80 (HTTP) and one for port 443 (SSL). Slow-start list 100
for port 80 is applied to the HTTP port on real server rs2. Slow-start list 101 for port 80 is applied to the HTTP port
on real server rs3. Slow-start list 101 for port 443 is applied to the SSL port on real server rs3. Note that slow-start
list 101 for port 80 has no relation to slow-start list 101 for port 443.
In this configuration, port 80 on real server rs2 and ports 80 and 443 on real server rs3 are each subject to a user-
configured slow-start mechanism. All other ports on the real servers are subject to the default slow-start mechanism
described in "Default Port Slow-Start Mechanism".
no-slow-start
Use [no] server no-slow-start to globally disable the mechanism. When you disable the slow-start
mechanism, the SI can immediately send up to the maximum number of connections specified for the real server
when the server comes up. Disabling slow-start does not remove the slow-start configuration information from the
real servers. To reactive slow-start, globally re-enable the feature.
Example
ServerIron(config)#server no-slow-start
To globally re-enable slow-start:
ServerIron(config)#no server no-slow-start
LDAP Over SSL
Overview
Older SI releases support Lightweight Directory Access Protocol (LDAP) health checks sent over an unsecure
connection on TCP port 389. Starting in Release 07.4.01, the SI can perform LDAP health checks using a Secure
Sockets Layer (SSL) connection on TCP port 636.
The LDAP over SSL (LDAPS) health check procedure works as follows:
The SI initiates an SSL connection with the server on TCP port 636, a secure link is negotiated, and encrypted data
is transferred across the link. After the SSL connection is established, the SI sends a bind request to the LDAPS
server and waits for a reply. The bind request includes a configurable version number, either 2 or 3 (by default,
version 3).
If the LDAPS server sends a bind reply with a result code of 0 (no error), the SI resets the connection and
marks the port ACTIVE.
If the LDAPS server does not send a bind reply by the time the LDAPS keepalive interval expires, the
ServerIron retries the health check up to the number of times configured (by default, two retries). If the
LDAPS server still does not respond, the SI marks the server port FAILED and removes the LDAPS server
from the load-balancing rotation for LDAPS service.
You can configure standard (non-Boolean) LDAPS health checks, as well as Boolean LDAPS health checks. Health
checking commands available for other TCP ports are also available for the LDAPS port.
Example
To configure a standard health check for port ldaps on real server r1, enter the following commands:
ServerIron(config)# server port ldaps
ServerIron(config-port-ldaps)# tcp keepalive enable
ServerIron(config-port-ldaps)# exit
ServerIron(config)# server real r1 10.10.1.101
ServerIron(config-rs-r1)# port ldaps
ServerIron(config-rs-r1)# exit
If no-fast-bringup is not configured for the LDAPS port, l4-check-only is configured for the LDAPS port, or
the keepalive health check for the LDAPS port is disabled, then the SI does not establish a secure connection when
performing a health check on port 636. Instead, the SI establishes a regular TCP connection on port 636 and sends
a TCP RESET, using the same method as the LDAP health check.
To configure a Boolean LDAPS health check, enter commands such as the following:
ServerIron(config-hc-check1)# port ldaps
ServerIron(config-hc-check1)# protocol ldaps
A Layer 7 health check must be configured in order for the SI to establish a secure connection on the LDAPS port. If
only a Layer 4 health check is configured, then the SI establishes a regular TCP connection on port 636.
1
Real servers include those added using the server real-name command and those added using the
server remote-name command. Generally, both types of servers are referred to as real servers. An
application port is a port that uses the TCP or UDP protocol. You associate health-check policies with TCP or
UDP ports on the real servers (not with physical ports on the servers).

Table Of Contents | Previous Chapter | Next Chapter

Health Checking On Load Balancers

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Health Checking On Load Balancers

Enviado por

Direitos autorais:

Formatos disponíveis

Health Checking On Load Balancers: More

Art Than Science

Você também pode gostar