Health Checking On Load Balancers: More Art Than ScienceMarch 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 they’re 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 it’s 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 can’t. 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 it’s 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 that’s two down, and we’ve got a server marked as down.

So that’s 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, that’s 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 didn’t 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 wasn’t 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 didn’t 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, it’s 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.comGET /healthcheck.html HTTP/1.1 Host: example.comIf 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, today’s application delivery

controllers (ADCs) represent a considerable evolution from simple server load balancing. Array’s 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 Array’s 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 SolutionsCloud Platform

Support & ResourcesGet Started

Documentation

Wiki HomeServer ImagesSupported OS'sAPINetwork DevicesCustomer Wiki

How To's & TutorialsAPI LibrariesAPI ToolsSupport OverviewKnowledgebaseFAQs

System StatusPrintable 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

Search Wiki Wiki Forum Search all

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 FeaturesSelf-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 AvailabilityDynamic Load balancers are currently available in our US-West-1, US-East-1, and EU-West-1 data centers.

APIUse API:GoGrid_Load_Balancer_API_v2 to manage your load balancers.

Recommended UseThe 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 BalancerWhen 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 you’re 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: DLB1Listener: Web Traffic 1Protocol: HTTPListener Port: 80Real Port: 80Algorithm: Weighted Round RobinPersistence: NoneHealth Checker Type: HTTPURI: /index.html

Real IPs: 240.30.248.145, 240.30.248.146, 143.168.230.5DLB: DLB1Listener: Web Traffic 2Protocol: TCPListener Port: 443Real Port: 443Algorithm: Weighted Round RobinPersistence: NoneHealth Checker Type: SSLURI: [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 1—then 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 ManualSee the Dynamic Load Balancer User Manual for instructions on deploying a load balancer.

PricingCurrent pricing for the DLB can be found on the GoGrid website.

Getting HelpSee our Support page for information on contacting GoGrid for any questions or issues that arise.

Frequently asked QuestionsHow 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 ActionHow You Can Use Compute Engine Load Balancing to Unleash Your App’s 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 Google’s 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

That’s 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 Google’s 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 ofrequests

Average response

time (in ms) for requests

to one

Average response

time (in ms) for requests

through

Average response

time (in ms) for requests

through

Average response

time (in ms) for requests

through

backend directly

Compute Engine Load

Balancing with one backend

Compute Engine Load

Balancing with four backends

Compute Engine Load

Balancing with four backends

across two zones

1,000,000100.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 Google’s 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 user’s 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 boto’s 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 Amazon’s 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 you’d like to create a set of instances spanning both the US and Europe Regions you’d 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')

Here’s 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-1elb_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 you’d 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, let’s 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_namemy_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 boto’s 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 topicAn Introduction to boto’s VPC interface

Next topicAn Introduction to boto’s S3 interface

This Page

Show Source

Quick search

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

Go yes default

Table Of Contents

Previous Chapter

Next Chapter

Index

Chapter Contents

Health Checks Overview

Server and Application Port States

Best Path to a

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)

Remote Server

Reassign Threshold

ping-interval, ping-retries

l3-health-check

Layer 3 Health Check for Real Servers

Port Profiles

Reassign Threshold

SSL Health Checks

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

When Performed Description

Layer 4 UDP Keepalive Health Checks for the DNS Port

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 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 Table Entries

Slow-Start Mechanism

LDAP Over SSL

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.

o When you configure a real servero If the ARP entry ages outo 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.

Layer 4 Health Checks 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 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.

Summary of L4 Health Checks

When Performed Description

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.

When you bind a UDP application port on a real server to a UDP 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 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.

Layer 7 Health Checks 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.

Summary of L7 Health Checks

When Performed Description

Immediately following a successful Layer 4 UDP health check

At regular intervals, if 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 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".

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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.

(status code)

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 removes the server from the load-balancing rotation 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.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 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

health check for unknown ports)

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 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 IMAP4 service.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 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 removes the server from the load-balancing rotation for LDAP service.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled for the port

The SI sends an intentionally invalid request to the server.

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

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled for the port

The SI waits for a message from the NNTP server.

If the server sends a greeting message with status 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.

If the server does not send a greeting message with 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.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 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 PNM service.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 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 POP3 service.

Immediately following a successful Layer 4 UDP health check

At regular intervals, if keepalive is enabled 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.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled for the port

The SI sends a standard RSTP option packet, using sequence number 1.

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.

If the server responds with a different status code, the SI marks the 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 removes the server from the load-balancing rotation for RSTP service.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled for the port

The SI waits for a message from the SMTP server.

If the server sends a greeting message with status code 220, the SI sends a Quit command to the SMTP 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 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 SMTP service.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 command.

If the server responds with an acceptable status code, the SI resets the connection and marks the port ACTIVE.

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 removes the server from the load-balancing rotation

for SSL service.

Note: You can configure the SIXL to use the simple SSL health check used on other SI models. See below and Health Checks".

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled 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 connection and marks the port ACTIVE.

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 removes the server from the load-balancing rotation for SSL service.

Immediately following a successful Layer 4 TCP health check

At regular intervals, if keepalive is enabled for the port

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 connection and marks the port ACTIVE.

If the server does not send a command that starts with the IAC escape character, 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 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

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.

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.

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 bindcommand 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.

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-checkthe 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.

AWD: await-

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

Description

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.)

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.

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.

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.

The application has passed its Layer 4 (and if applicable, Layer 7) health check.

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

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

You can enable logging for session table entries created for this port. See "Syslog for Session Table Entries".

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 8080ServerIron(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)# server port 80ServerIron(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)# server port 8080ServerIron(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)# server port 80ServerIron(config-port-80)# tcp 15

Syntax: server port <TCP/UDP-portnum>

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)# server port 80ServerIron(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.

Simple—Sends 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.

Complete—Negotiates 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 nullSSL cleanup: can't find key ???SSL interface: ssl_read_data return error !!!ssl_receive_data but tcb->ssl is nullSSL cleanup: can't find key ???SSL interface: ssl_read_data return error !!!ssl_receive_data but tcb->ssl is nullSSL 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)# server port dns 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.1ServerIron(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)# server port dnsServerIron(config-port-dns)# no tcp keepalive enable

Layer 7 Health Checks

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.251ServerIron(config-rs-zip)# port http url "GET/sales.html"ServerIron(config-rs-zip)# exit

ServerIron(config)# server virtual shoosh 207.96.4.250ServerIron(config-vs-shoosh)# port httpServerIron(config-vs-shoosh)# bind http zip httpServerIron(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 m1ServerIron(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 match-list m2ServerIron(config-http-ml-m2)# down simple "monkey"ServerIron(config-http-ml-m2)# up simple "elephant"ServerIron(config-http-ml-m2)# exit

The selection criteria in the matching list above would cause the 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 match-list m3ServerIron(config-http-ml-m3)# down simple "elephant"ServerIron(config-http-ml-m3)# up simple "elephantine"ServerIron(config-http-ml-m3)# exit

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 match-list m4ServerIron(config-http-ml-m4)# up compound "monkey see" "monkey do" logServerIron(config-http-ml-m4)# down compound "500" "Internal Server Error" logServerIron(config-http-ml-m4)# down compound "503" "Service Unavailable" logServerIron(config-http-ml-m4)# default downServerIron(config-http-ml-m4)# exit

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.1ServerIron(config-rs-rs1)# port http content-match m4ServerIron(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)# server port 12345ServerIron(config-port-12345)# tcpServerIron(config-port-12345)# no-fast-bringup

Syntax: server port <TCP/UDP-portnum>

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 match-list m1ServerIron(config-http-m1-m1)# up simple "FTP service"ServerIron(config-http-m1-m1)# default down

ServerIron(config-http-ml-m1)# exit

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.50ServerIron(config-rs-R)# port 12345 content-check m1

Syntax: port <portnum> content-check <matching-list-name>

The <portnum> is a non-well-known port. You cannot specify a well-known port for a scripted health check.

The <matching-list-name> is a previously configured matching list. If the <matching-list-name> does not refer to an existing matching list, the port on the real server is marked FAILED when the health check is performed.

Using a Scripted Health Check in a Health-Check Policy

A scripted health check can be used in a health-check policy. A health-check policy is a group of one or more health checks attached to a real server port. When the scripted health check checks the health of a destination port specified in the policy, the health-check policy can be evaluated to true or false depending on the response from the server.

To use a scripted health check with a health-check policy, you configure a matching list, then configure the health-check policy.

For example, when the following matching list is used with a health-check policy, it will evaluate the policy to true if the string "FTP service" is found in the response from the real server. If this text is not found, the policy is evaluated to false.

ServerIron(config)# http match-list m1ServerIron(config-http-m1-m1)# up simple "FTP service"ServerIron(config-http-m1-m1)# default downServerIron(config-http-ml-m1)# exit

The default down command causes the policy to be evaluated to false if the selection criteria is not found in the response from the server. If the real server responds to the health check with a RST, the policy is evaluated to true or false depending on what was specified in the default statement in the matching list.

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 tcpServerIron(config-hc-check1)# dest-ip 10.10.10.10ServerIron(config-hc-check1)# port 1234 content-check m1ServerIron(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 evilServerIron(config-rs-rocket)# port radius password woodyServerIron(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.160ServerIron(config-vs-v1)# port httpServerIron(config-vs-v1)# bind http rs32 httpServerIron(config-vs-v1)# exit

ServerIron(config)# server virtual v2 192.168.1.161ServerIron(config-vs-v2)# port httpServerIron(config-vs-v2)# no port http translateServerIron(config-vs-v2)# bind http rs32 81ServerIron(config-vs-v2)# exit

ServerIron(config)# server real rs32 64.1.1.32ServerIron(config-rs-rs32)# port httpServerIron(config-rs-rs32)# port http keepaliveServerIron(config-rs-rs32)# port http url "HEAD /"ServerIron(config-rs-rs32)# port 81ServerIron(config-rs-rs32)# port 81 keepaliveServerIron(config-rs-rs32)# port 81 url "GET /81keepalive.htm"ServerIron(config-rs-rs32)# exit

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)# server port 999ServerIron(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)# server port 999ServerIron(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)# server port 80ServerIron(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)# server port 53ServerIron(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.10ServerIron(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 expression—Consists 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 expression—A 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)# healthck check1 tcpServerIron(config-hc-check1)# dest-ip 10.10.10.50ServerIron(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)# healthck check1 tcpServerIron(config-hc-check1)# dest-ip 10.10.10.50ServerIron(config-hc-check1)# port 8080ServerIron(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)# healthck check1 tcpServerIron(config-hc-check1)# dest-ip 10.10.10.50ServerIron(config-hc-check1)# port 8080ServerIron(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.

Syntax: [no] dest-ip <ip-addr>

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)# healthck check4 tcpServerIron(config-hc-check4)# dest-ip 10.10.10.50ServerIron(config-hc-check4)# port sslServerIron(config-hc-check4)# protocol ssl use-completeServerIron(config-hc-check4)# protocol ssl url "GET /secure.htm"ServerIron(config-hc-check4)# protocol ssl status-code 200 200ServerIron(config-hc-check4)# protocol ssl content-match m1ServerIron(config-hc-check4)# l7-check 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 80o IMAP4 - port 143o LDAP - port 389o MMS - port 1755o NNTP - port 119o PNM - port 7070o POP3 - port 110o RTSP - port 554o SMTP - port 25o SSL - port 443o 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.

ServerIron(config-hc-check1)# l4-check

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" booleanServerIron(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)# healthck check1 tcpServerIron(config-hc-check1)# dest-ip 10.10.10.50

ServerIron(config-hc-check1)# port httpServerIron(config-hc-check1)# healthck check2 tcpServerIron(config-hc-check2)# dest-ip 10.10.10.20ServerIron(config-hc-check2)# port httpServerIron(config-hc-check2)# healthck check3 tcpServerIron(config-hc-check3)# dest-ip 10.10.10.30ServerIron(config-hc-check3)# port httpServerIron(config-hc-check3)# healthck check4 tcpServerIron(config-hc-check4)# dest-ip 10.10.10.40ServerIron(config-hc-check4)# port http

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 booleanServerIron(config-hc-nested1)# or check1 check2ServerIron(config-hc-nested1)# healthck nested2 booleanServerIron(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 booleanServerIron(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.50ServerIron(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 icmpServerIron(config-hc-Rtr2-ck1)# dest-ip 10.168.2.56ServerIron(config-hc-Rtr2-ck1)# healthck Rtr2-ck2 icmpServerIron(config-hc-Rtr2-ck2)# dest-ip 10.168.2.57ServerIron(config)# healthck Router2 booleanServerIron(config-hc-Router2)# and Rtr2-ck1 Rtr2-ck2ServerIron(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 icmpServerIron(config-hc-Rtr2-ck1)# dest-ip 10.168.2.56ServerIron(config-hc-Rtr2-ck1)# healthck Rtr2-ck2 icmpServerIron(config-hc-Rtr2-ck2)# dest-ip 10.168.2.57

The commands in this example configure two element-action expressions.

Syntax: [no] healthck <element-name> <protocol>

Syntax: [no] dest-ip <ip-addr>

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 booleanServerIron(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 icmpServerIron(config-hc-nest1)# dest-ip 1.1.1.10ServerIron(config-hc-nest1)# healthck nest2 icmpServerIron(config-hc-nest2)# dest-ip 1.1.1.20ServerIron(config-hc-nest2)# healthck nest3 icmpServerIron(config-hc-nest3)# dest-ip 1.1.1.30ServerIron(config-hc-nest3)# healthck nest4 icmpServerIron(config-hc-nest4)# dest-ip 1.1.1.40

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 booleanServerIron(config-hc-nested1)# or nest1 nest2ServerIron(config-hc-nested1)# healthck nested2 booleanServerIron(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.1ServerIron(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 254ServerIron(config)# endServerIron# 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

Displays...

The number of health-check policies in the configuration. The number includes attached and unattached policies.

The maximum number of health-check policies you can configure.

The element-action expression or policy name.

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.

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.

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.

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.

For element-action expressions, the application port. This field does not apply to policies.

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.

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 statisticsPing Statistics:Sent: 1524 Received: 1524Invalid Replies: 0 Dropped Replies: 0

Health-Check Policy Statistics

This Field... Displays...

The number of health-check packets sent by bound health-check policies.

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.

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.

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 logDynamic Log Buffer (50 entries):

03d02h47m38s:N:L4 server 192.168.1.170 danPC is down03d02h46m18s:N:L4 server 192.168.1.170 danPC is up03d02h46m08s: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 50000ServerIron(config)#write memoryServerIron(config)#endServerIron#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 threshold—When the number of free sessions drops below the fast-age threshold, sessions older than a specified time are aged out.

Random threshold—When 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 = 524288Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Fast-aged : total = 0 last 60 sec = 0Random-aged : total = 0 last 60 sec = 0Server 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 0rs2 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 ageo 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

all—enables logging for all sessions.

src-nat—enables logging only for sessions that are used for Source NAT.

url—enables logging of URL information for sessions that contain a URL.

cookie—enables 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 80ServerIron(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

10 16 220

20 17 240

30 18 260

40 19 280

50 20 300

60 21 320

70 22 340

80 23 360

90 24 380

100 25 400

120 26 420

140 27 440

160 28 460

180 29 480

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.

From 10 seconds to 20 seconds, the SI allows up to 20 new connections every second.

From 20 seconds to 30 seconds, the SI allows up to 30 new connections every second.

From 30 seconds to 40 seconds, the SI allows up to 40 new connections every second.

From 40 seconds to 50 seconds, the SI allows up to 50 new connections every second.

From 50 seconds to 60 seconds, the SI allows up to 100 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 port2. 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)# server port 80ServerIron(config-port-80)# slow-start 101 10 30 20 30 600ServerIron(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)# server real-name rs1 192.168.1.1ServerIron(config-rs-rs1)# port httpServerIron(config-rs-rs1)# port http slow-start 101ServerIron(config-rs-rs1)# exit

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)# server port 80ServerIron(config-port-80)# slow-start 100 10 30 20 30 600ServerIron(config-port-80)# slow-start 101 20 30 40 30 1500ServerIron(config-port-80)# exit

ServerIron(config)# server port 443ServerIron(config-port-80)# slow-start 101 20 60 40 120 2400ServerIron(config-port-80)# exit

ServerIron(config)# server real-name rs2 192.168.1.2ServerIron(config-rs-rs2)# port httpServerIron(config-rs-rs2)# port http slow-start 100ServerIron(config-rs-rs2)# exit

ServerIron(config)# server real-name rs3 192.168.1.3ServerIron(config-rs-rs3)# port httpServerIron(config-rs-rs3)# port http slow-start 101ServerIron(config-rs-rs3)# port sslServerIron(config-rs-rs3)# port ssl slow-start 101ServerIron(config-rs-rs3)# exit

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 ldapsServerIron(config-port-ldaps)# tcp keepalive enableServerIron(config-port-ldaps)# exit

ServerIron(config)# server real r1 10.10.1.101ServerIron(config-rs-r1)# port ldapsServerIron(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)# healthck check1 tcpServerIron(config-hc-check1)# dest-ip 10.10.1.101ServerIron(config-hc-check1)# port ldapsServerIron(config-hc-check1)# protocol ldapsServerIron(config-hc-check1)# l7-check

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.

1Real 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