Server Load Balancing (SLB) is based on associations between real servers and virtual servers. The real servers are your application servers. The virtual servers have one or more Virtual IP addresses (VIPs). You associate a real server with a virtual server by binding TCP/UDP ports on the real servers with TCP/UDP ports on the virtual server. When a client sends a TCP/UDP request for a port on the virtual server, the SI sends the client's request to the real server. The client is unaware of the real servers behind the virtual server but does experience enhanced throughput and availability for TCP/UDP services.
SLB maps one logical (virtual) server connection to multiple physical (real) servers. Thus, a single IP address (virtual server IP address) can serve as the connection point for multiple TCP/UDP services such as HTTP, FTP or Telnet rather than each of the services requiring a different IP address for each service. These services can be located on a single server or across multiple servers.
Figure 3.1 Single virtual IP address mapped to multiple real servers
In Figure 3.1, a company establishes a web site with the URL of www.alterego.com. The web site is mapped to the virtual IP address 207.95.55.1, defined on a ServerIron (SI). All inquiries made to that web site by users on the Internet or the company's Intranet use either the URL or virtual IP address to reach the company's web site.
Once these inquiries are received at the company site, the requests are handled by one of four separate physical (real) web servers that the system administrator has mapped to the virtual IP address. The addresses of the four physical (real) web servers are unknown and unseen to those users who send the inquiries. The only address the users ever see for the web site is the virtual IP address.
SLB provides numerous benefits that ease overall administration of TCP/UDP applications on servers as well as increase their performance and reliability.
In the previous example, Figure 3.1, the system administrator has greater flexibility in managing server resources for this application. When you use an SI, you can add or remove the physical (real) servers to handle changing traffic requirements without disrupting service to the end users. The end users continue to access the virtual IP address configured on the SI and are not aware of added or removed real servers that underlay the virtual IP address.
SLB also enhances server security because the real servers' IP addresses are never broadcast. The SI sends and responds to ARPs with the virtual IP address, not the actual IP addresses of the real servers.
In addition to offering increased control over server resources and greater security within the network, SLB provides increased reliability of the server resources by providing support for both switch and server redundancy.
A Foundry SI running SLB software establishes a virtual server that acts as a front-end to physical servers, distributing user service requests among active real servers. SLB packet processing is based on the Network Address Translation (NAT) method. Packets received by the virtual server IP address are translated into the real physical IP address based on the configured distribution metric (for example, "round robin") and sent to a real server. Packets returned by the real server for the end user are translated by SLB so that the source address is that of the virtual server instead of the real server.
NAT translation is performed for both directions of the traffic flow. Converting virtual services to real services requires IP and TCP checksum modifications.
Port translation is not performed for any virtual port that is bound to a default virtual port.
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
See "Slow-Start Mechanism" for more information.
The predictor is the parameter that determines how to balance the client load across servers.
You can fine-tune how traffic is distributed across multiple real servers by selecting one of the following load balancing metrics (predictors):
- Least connections—Sends the request to the real server that currently has the fewest active connections with clients. For sites where a number of servers have similar performance, the least connections option smooths distribution if a server gets bogged down. For sites where the capacity of various servers varies greatly, the least connections option maintains an equal number of connections among all servers. This results in those servers capable of processing and terminating connections faster receiving more connections than slower servers over time.
- Least sessions—Sends the request to the real server that currently has the fewest session table entries. The least sessions approach applies to stackable SI XLs only. This predictor is supported in software releases 07.1.19, 07.2.14, and 07.3.03 and later.
- Round robin—Directs the service request to the next server, and treats all servers equally regardless of the number of connections or response time. For example, in a configuration of four servers, the first request is sent to server1, the second request is sent to server2, the third is sent to server3, and so on. After all servers in the list have received one request, assignment begins with server1 again. If a server fails, SLB avoids sending connections to that server and selects the next server instead.
- Weighted—Assigns a performance weight to each server. Weighted load balancing is similar to least connections, except servers with a higher weight value receive a larger percentage of connections at a time. You can assign a weight to each real server, and that weight determines the percentage of the current connections that are given to each server. The default weight is 0.
For example, in a configuration with five servers of various weights, the percentage of connections is calculated as follows:
Weight server1 = 7
Weight server2 = 8
Weight server3 = 2
Weight server4 = 2
Weight server5 = 5
Total weight of all servers = 24
The result is that server1 gets 7/24 of the current number of connections, server2 gets 8/24, server3 gets 2/24, and so on. If a new server, server6, is added with a weight of 10, the new server gets 10/34.
If you set the weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the connections at a given time. Because the server is faster than others, it can complete more than 50 percent of the total connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed ratio but adjusts to server capacity over time.
- Server response time only—Selects the real server with the fastest response time. If Layer 4 or Layer 7 health checks are disabled, the response time is based on how quickly the server responds to client requests forwarded by the SI. If the health checks are enabled, the response time is the combination of the response to forwarded client queries and the response to the health checks. The SI calculates the response time based on TCP SYN and TCP SYN ACK packets.
When the Server Response Time method is used, the SI generally forwards request to the server with the fastest response time. However, if a slower server has not been selected for more than one minute, it is selected so that the SI can measure its response time.
For DSR (Direct Server Return) configurations, since the SI does not see the server reply traffic, the SI uses only the health check responses to measure the response time.
- Least connection and server response time weights—Compares a combination of a real server's least-connections weight and server response time weight to the same values for the other real servers.
The server response time method, when used by itself, always selects the real server with the fastest response time. If all your real servers have similar response capacities, then using the server response time metric by itself generally provides an even load-balancing distribution among the real servers. However, if your server farm contains a mixture of servers, some of which have greater response capability than others, you might want to set the Server Response Time weights on individual real servers.
The default server response time weight is 0 (no weight). You can specify a weight from 0 - 65000. Setting a real server's weight higher relative to other real servers biases the SI's load-balancing selections toward that real server.
You can assign these metrics on a global basis (see "predictor") and an individual virtual server basis (see "Predictor: Virtual Server Specific Configuration"). By default, least connections is applied globally to all virtual servers. If you define a metric for a specific virtual server, that metric takes precedence over the globally defined metric.
NOTE:
Foundry recommends you enable health checking when using either of the response-time metrics. When health checking is enabled, a server's response time consists of the combination of its response to client requests and its response to Layer 4 or Layer 7 health checks from the SI.
By default, the SI uses the predictor (load-balancing method) you configure for each new request from a client to a virtual server. This works well for many situations. However, for some web implementations, it is desirable or even required to have the client continue to access the same real server for subsequent requests.
You can configure the SI to ensure that a client that accesses certain TCP/UDP ports on a VIP always goes to the same real server. For example, you might want to configure the TCP/UDP ports related to an interactive web site so that when a client begins a session on the site, subsequent requests from the client go to the same real server. As another example, you might want the real server to be able to arbitrarily assign open TCP/UDP sessions with the client using ports dynamically allocated by the real server.
Application grouping parameters apply to virtual servers. When you configure a virtual server, you specify the TCP/UDP ports on that virtual server. When you apply application grouping to a TCP/UDP port on a virtual server, the application grouping overrides the predictor. The SI allows you to configure the following application grouping methods on an individual virtual-server basis:
- Sticky connections - When you add a TCP/UDP port to a virtual server, if you specify that the port is "sticky", a client request for that port always goes to the same real server unless the sticky age timer has expired. The sticky age timer specifies how long the connection remains "sticky" (always goes to the same real server) and is reset each time a new client request goes to the sticky port. Once the sticky timer expires, the SI uses the predictor (load-balancing metric) you have configured to select a real server for requests for a port.
- Configurable TCP/UDP application groups - You can group a "primary" TCP/UDP port with up to four additional TCP/UDP ports. After the SI sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server.
- Concurrent connections - When you configure a TCP/UDP port in a virtual server to support concurrent connections, the real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers. Although the concurrent connections feature is similar to the application group feature, application groups apply to specific TCP/UDP ports that you configure on the virtual server. Concurrent connections enables the real server to arbitrarily determine the TCP/UDP ports and assign them to the client.
NOTE:
For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
When a service request by a client mandates a series of sequential TCP/UDP port connections to be served by the same real server, you can enable a sticky connection on that TCP/UDP virtual server port. For example, if a user is accessing dynamically generated pages, the client must consistently attach to the same server; otherwise, the state information is lost. By default, the sticky parameter is disabled for virtual service ports, except for Secure Socket Layer (SSL).
Application groups enhance the sticky connections method by allowing you to group up to four TCP/UDP ports with another, "primary" TCP/UDP port. When the SI sends a client request for the primary port to a real server, requests from the same client for a port that is grouped with the primary port also go to the same real server. The application group method, like the sticky method, is governed by the sticky age.
The SI automatically sends requests for the grouped ports to the same real server as the "primary" port as long as the sticky timer has not expired. You must define all the ports in an application group individually in the VIP and you must configure all of them to be sticky.
See "TCP/UDP Application Groups" for an example of this feature.
The concurrent connection option is similar to the sticky option. However, instead of supporting sequential connections to the same server, the concurrent connection option supports both a primary connection and secondary connections. The connections are supported at the same time.
The primary connection is the controlling connection and dictates the resource, such as a server, to which subsequent or secondary connections are made.
Once the controlling connection is established, the server dynamically assigns a TCP/UDP port to which the client should open subsequent or secondary connections. Subsequent connections from that client are accepted on the server as long as the controlling connection is still active.
Figure 3.2 shows an example of a concurrent connection. A client initiates a session request to the NETPERF application supported on servers S1, S2, and S3. When the SLB switch receives the request, the switch forwards the request to server S2. This forms the primary connection. Then S2 dynamically assigns a port, 10000, to the application and forwards it to the client.
NOTE:
The method the server uses to communicate the dynamic port to the client is application specific.
The SI switches all subsequent connections to S2 to ensure that the NETPERF session completes successfully.
By default, the concurrent property of a virtual TCP/UDP service port is enabled except for FTP, Telnet, TFTP, HTTP, and SSL ports.
Figure 3.2 Concurrent connections in operation on an SLB network
If your real web servers have many IP addresses, you can easily create a separate VIP for each real IP address without individually configuring each VIP. To do so, configure a host range. A host range is a block of contiguous IP addresses.
To configure a host range, you add a VIP and specify how many hosts are in the range. The SI automatically configures a separate VIP for each host in the range. When you bind the base VIP to the real servers, the SI associates the VIP with the first real IP address on the server. Subsequent VIPs in the host range are associated with subsequent real IP addresses on the server. The association is based on the offset from the base VIP. When a client requests an address in the VIP range, the SI automatically maps the VIP to a real IP address on a real server based on the address's offset from the base VIP address.
For example, if you define a range using the base VIP 209.157.22.1 and a host range of 10, the SI maps VIPs 209.157.22.1 - 209.157.22.10 to a range of ten addresses on each real server. If a client requests VIP 209.157.22.3 (two from the base VIP number), the SI sends the request to an IP address that is two higher than the start of the corresponding range on a real server.
You can configure up to 256 virtual servers, each with a host range of 256 addresses, for a total of up to 64,000 VIPs.
NOTE:
To use this feature, the IP address range on the real server must be contiguous. If the range contains gaps (addresses in use by other hosts), specify separate ranges on the virtual server to work around the gaps.
The servers in your SLB configurations do not need to have Layer 2 connectivity to the SI. In fact, they do not need to be in the same LAN or Intranet as the SI at all. Using the NAT support described in "Multinetting Using NAT", you can configure the SI to use geographically-distributed servers.
In a typical configuration, the SI uses geographically-distributed servers as failovers if all the local servers become unavailable. When you configure a real server, you indicate whether the server is local or remote. If the server is remote, the SI does not include the server in its predictor (load-balancing metric). The remote server can be the IP address of a real server or even a virtual IP address configured on another SI. For information about the predictor, see "Load-Balancing Predictor".
Servers that are locally attached to the SI (not separated by one or more router hops) are local servers. Servers that are one or more router hops away from the SI are remote servers.
NOTE:
You can configure the SI to include remote servers when load balancing traffic, instead of using the remote servers only as failovers. See "Primary and Backup Servers".
Global Server Load Balancing (GSLB) enables a SI to add intelligence to authoritative Domain Name Servers (DNSs) by serving as a proxy to the servers. As a DNS proxy, the GSLB SI evaluates the server IP addresses in the DNS replies from the DNS for which the SI is a proxy. Based on the results of the evaluation, the GSLB SI can change the order of the addresses in the reply so that the "best" host address for the client is on top.
You can configure a SI to provide GSLB for other SIs. In this case, each of the other SIs is a site SI providing SLB for a local server farm. The GSLB SI uses a policy to select the best site and if necessary modifies the DNS reply to the client accordingly.
For more information, see "Global Server Load Balancing".
Symmetric Server Load Balancing (SLB) allows you to use multiple SIs to simultaneously load balance VIP traffic and provide hot standbys for one another's VIPs. In addition to their roles as mutual backups, each SI actively provides Layer 4 SLB (and TCS, if configured) services. As a result, you get the fault protection of a hot standby configuration while doubling connection capacity.
In a Symmetric SLB configuration, each VIP is actively served by only one of the SIs. The other SIs are standbys for that VIP, although they may each simultaneously be the active SI for other VIPs. You determine which SI is the active SI for a VIP by assigning a priority to each VIP. The SI that has the highest priority for a specific VIP is the active SI for the VIP by default. The other SIs have lower priorities for the VIP and are standbys for that VIP. Only if the SI that has the highest priority for the VIP becomes unavailable does another SI (with the next highest priority for the VIP) assume service for the VIP.
To configure Symmetric SLB, you configure the same VIPs on multiple SIs that have Layer 2 connectivity, then assign a different SLB priority to each VIP on each of the SIs. For example, to configure two SIs for SLB, configure the same VIPs on each of the SIs. On one of the SIs, assign half of the VIPs a priority of 1 (lowest) and assign the other VIPs a priority of 255 (highest). Assign the reverse priorities to the VIPs on the other SI.
A typical Symmetric SLB configuration uses a redundant set of real servers connected to each SI. The VIPs and their contents are identical on each pair of servers. The only difference for each VIP is the priority you assign the VIP on a particular virtual server. You can configure a priority from 1 - 255 and you can use up to 255 SIs in a Symmetric SLB configuration.
Figure 3.3 shows an example of Symmetric SLB.
Figure 3.3 Symmetric SLB automatically compensates for unavailable equipment and links
Symmetric SLB includes link-level redundancy to provide fault tolerance against failed links.
If a link from a SI to the real servers fails, Symmetric SLB can use an alternate path through another SI running Symmetric SLB to reach the real servers. Link-level redundancy requires no additional configuration. If the SIs have Layer 2 connectivity and you configure Symmetric SLB priorities for the VIPs, then link-level redundancy is automatically enabled.
See "Symmetric SLB".
Direct Server Return (DSR) configures the SI to instruct real servers to send client responses directly to the clients instead of sending the responses back through the SI. As a result, the clients receive faster response time and the SI is free to support even more sessions to serve more clients. (A connection is two sessions, one in each direction.)
When configured for this feature, the SI sends client requests addressed to a VIP to a load balanced real server, as in standard Server Load Balancing (SLB) configurations. However, to enhance server-to-client response time and to increase the overall connection capacity of the SI, the software in a DSR configuration formats the client request packets in such a away that the real servers respond directly to the clients, instead of sending the responses back through the SI.
Figure 3.4 shows an example of two SI 800s deployed in a SLB DSR configuration.
Figure 3.4 SI 800s deployed in DSR configuration
You configure DSR on an individual TCP/UDP port basis when you configure your virtual servers. The feature requires that you configure a loopback interface on each real server and give the loopback interface the IP address of the VIP. The SI sends the client traffic to the real server without translating the destination address from the VIP into the real server's IP address. Thus, the real server receives the client traffic addressed to its loopback address and responds directly to the client.
The DSR feature can be used on a single SI supporting a single server farm, but is also is quite powerful when used on multiple SIs in combination with the Symmetric SLB feature (see "Symmetric Server Load Balancing").
For a complete configuration example, see "DSR Configuration Example".
For overview information, see "DSR Configuration Example".
When you associate a VIP with a real server, you make the association for a particular TCP/UDP port. The association of a TCP/UDP port on a VIP with a TCP/UDP port on a real server is called a "port binding". Typical configurations use one VIP-to-real-server binding for a TCP/UDP port. For example, if you bind VIP 192.29.2.2 to real server 10.0.0.1 for port 80 (the well-known HTTP port), generally you do not then create another binding between VIP 192.29.2.2 and real server 10.0.0.1 for the same port.
However, if you want to track statistics for individual applications or domain names mapped to the same port, the SI allows you to configure an alias for the port. You configure a separate alias for each additional VIP. For example, if you are associating three VIPs with the same real server, you define two TCP/UDP port aliases, one for each of the additional VIPs. The SI collects and displays statistics and configuration information individually for each VIP, but sends all traffic to the same TCP/UDP port number on the real server.
See "Many-To-One TCP/UDP Port Binding" for an example application using this feature.
The remote server support and NAT support described in previous sections allow you to configure geographically-distributed servers that the SI uses as failovers if the local servers are unavailable. A typical configuration with geographically-distributed servers uses source NAT to cause responses from the remote real server to go back to the SI instead of directly to the client. This traffic pattern matches the standard traffic pattern among the SI, the clients, and the real servers.
However, if the links between a remote server and SI are slow and would introduce unacceptable delays, you can enable HTTP redirect. HTTP redirect configures the SI to send an HTTP redirect message to a client when the SI is sending the client's request to a remote server. The HTTP redirect instructs the client to redirect its TCP connection from the VIP to the real IP address of the remote server. After a successful HTTP redirect, the client and remote server communicate directly, not through the SI.
NOTE:
If a client creates a bookmark when communicating directly with a remote server, the bookmark points to the real IP address of the server instead of the VIP. If the client uses the bookmark later to re-access the server, the client bypasses the VIP.
Transparent VIP allows you to configure a SI to transparently load balance a VIP, without owning the VIP address. Use this feature when you want to configure multiple SIs to load balance the same VIP. For example, if you have globally distributed clients that access the same VIP, you can place SIs close to those clients for optimal service, and use the SI to load balance requests for the VIP to locally distributed server farms.
Depending on the network topology, you might also want to configure the application ports on the transparent VIP to be stateless. A stateless port does not use session table entries and the SI does not expect the server reply for the port to come back through the SI. Standard Layer 4 and Layer 7 keepalive health checking relies on session table entries, but you can configure stateless health checking for the stateless ports.
The SI can support all the variations of NAT listed in Table 3.1 on page 3-10. The NAT support enables the SI to operate in a multi-netted environment.
NOTE:
The standard NAT support described in "Network Address Translation" provides IP address translation for hosts attached to private networks on the SI, and is separate from the virtual IP address features provided for SLB. For example, standard NAT is not related to source IP addresses used for multinetting the SI, performing health checks on remote servers, and so on.
Address translation applies only to SLB. The default NAT behavior for SLB is as follows:
The SI always translates the MAC address in responses from a real server into the MAC address of the virtual IP address (VIP) before sending the response to the client. Thus, the client receives a response that contains the source IP address and MAC address of the VIP.
This behavior assumes that the SI and the real servers are all on the same sub-net and have direct
Layer 2 connectivity. However, you are not limited to this topology. You can easily configure the SI to operate in a multi-netted environment in which the SI and the real servers are in different sub-nets.
In addition to the IP management address, the SI can have up to eight additional IP addresses for use with source NAT. When the network topology requires the SI to translate a packet's source IP address into one of the SI's source IP addresses, the SI can use one of the source IP addresses you configure. You can configure source IP addresses on a global basis (for the entire device). See the application examples in "SLB Configuration Examples" for more information.
SI NAT Support
|
Translation
|
Direction
|
Application
|
|
Source
IP Address
|
Destination
IP Address
|
| |
X
|
SI->real server
|
Destination - Translate virtual IP address known by client into real server address.
|
|
X
|
|
SI->client
|
Source - Translate real server IP address into virtual IP address known by client.
|
|
X
|
X
|
SI->real server
|
In multi-netted environment:
- Destination - Translate virtual IP address known by client into real server address.
- Source - Translate client IP address into source IP address in the same sub-net as the real server if possible. (Source IP address is defined on the SI.)
When sending client request to remote real server:
- Destination - Translate virtual IP address known by client into real server address.
- Source - Translate client IP address into source IP address defined on the SI. This ensures that server response comes back to SI instead of directly to client.
|
|
X
|
X
|
SI->client
|
In multi-netted environment:
- Source - Translate real server address into virtual IP address known by client.
- Destination - Translate SI source IP address back into client IP address.
When receiving response from remote server:
- Source - Translate real server address into virtual IP address known by client.
- Destination - Translate SI source IP address into client IP address.
|
The following configuration guidelines should be observed when configuring SLB on a switch:
- Each virtual server name and IP address must be unique.
- Each virtual server can have multiple TCP/UDP ports assigned.
- Each real server name and IP address must be unique.
- Each real server can have multiple TCP/UDP ports assigned.
- Each real server TCP/UDP port can be bound only to one virtual TCP/UDP port. One virtual TCP/UDP port can be bound to one or more real TCP/UDP ports.
NOTE:
NOTE: If you need to map a real server port to multiple VIP ports, you can use the many-to-one TCP/UDP port binding feature. See "Many-To-One TCP/UDP Port Binding".
- The selection of a real server among many is managed by the selected predictor (load balancing metric).
- Binding must be done to establish a relationship between virtual and real servers.
NOTE:
SYN reassign is not available in the chassis code. However, it is in XL code.
A basic SLB configuration consists of a single SI and multiple real servers with identical content.
To configure basic SLB:
- Define the real servers on the SI. For each real server, identify the TCP or UDP application ports for which you want the SI to balance client traffic. The real servers contain the content you are load balancing.
- Define a virtual server (VIP). The VIP is the IP address or server name to which client browsers send requests. Add the TCP or UDP application ports the SI will load balance. These should be the same application ports you specified for the real servers.
- Bind the real servers to the VIP. The bindings are based on the TCP and UDP application ports you are load balancing.
Figure 3.5 shows an example of a basic SLB configuration. This example uses multiple web servers to handle remote web requests received on the web site. The web site URL is assigned to the switch as the focal point for all inquiries as a virtual server address. The virtual server will then forward requests to each of the four web servers as specified by the predictor (load balancing metric).
The sections following the example show how to configure the SI in the example using the CLI.
Figure 3.5 Basic SLB configuration
Real and virtual server assignments
|
Domain Name
|
Virtual IP
|
Port
|
Real IP
|
Port
|
|
www.alterego.com
|
207.95.55.1
|
80
|
207.95.55.21 (web1)
207.95.55.22 (web2)
207.95.55.23 (web3)
207.95.55.24 (web4)
|
80
80
80
80
|
The following commands define the real servers and TCP/UDP ports shown in Figure 3.5:
ServerIron(config)# server real web1 207.95.55.21
ServerIron(config-rs-web1)# port http
ServerIron(config-rs-web1)# server real web2 207.95.55.22
ServerIron(config-rs-web2)# port http
ServerIron(config-rs-web2)# server real web3 207.95.55.23
ServerIron(config-rs-web3)# port http
ServerIron(config-rs-web3)# server real web4 207.95.55.24
ServerIron(config-rs-web4)# port http
Syntax:
[no] server real-name-or-ip [<name>] <ip-address>
Syntax:
[no] port <tcp/udp-port>
After you have defined the real server, you can add configuration statements or delete the server by referring to the server's IP address or name:
Example:
ServerIron(config)# server real web1 207.95.55.21
ServerIron(config-rs-web1)# port http
ServerIron(config-rs-web1)# exit
ServerIron(config)# server real 207.95.55.21
ServerIron(config-rs-web1)# exit
ServerIron(config)# server real web1
ServerIron(config-rs-web1)# exit
ServerIron(config)# no server real web1
If a real server is not reachable from the ServerIron at Layer 2 (does not respond to ARP requests), and if the router connecting the ServerIron to the real server is not running proxy ARP, use server remote-name <name> <ip-addr> instead. This command adds the server as a remote server. See "Web Hosting with Geographically-Distributed Servers" for information.
If the ServerIron and real server are in different sub-nets, you might need to enable source NAT and configure a source IP address. See "Web Hosting with SI and Real Servers in Different Sub-Nets".
If you plan to configure SLB for a range of contiguous IP addresses on the server starting with the IP address you entered above, use host-range <range>. See "Web Hosting with Unlimited Virtual IP Addresses" for information.
To simplify configuration for large server farms, you can clone real servers. When you clone a real server, you make a copy of the real server's configuration information under a new name. The copy includes the port bindings to the virtual server.
Syntax
[no] clone-server <name> <ip-addr>
The <name> parameter specifies the name of the clone.
The <ip-addr> parameter specifies the IP address of the clone.
Example
ServerIron(config)#server real rs1 1.2.3.4
ServerIron(config-rs-rs1)#clone-server rs2 5.6.7.8
The first command changes the CLI to the configuration level for the real server you want to copy. The second command creates a clone of real server rs1. The clone is named "rs2" and has IP address 5.6.7.8.
NOTE:
To delete a server clone, you must manually edit the startup-config file to remove the command. The "no" option is not supported for this command.
After you define the actual web server's physical addresses (real server), you then need to configure the external web server address on the switch. The external web server is the virtual server.
Use server virtual-name-or-ip to define the virtual name and address that is the access point for the company's web site and the supported service.
Syntax
[no] server virtual-name-or-ip [<name>] <ip-address>
[no] port <tcp/udp-port>
Example
ServerIron(config-rs-web4)#server virtual www.altergo.com 207.95.55.1
ServerIron(config-vs-www.alterego.com)#port http
After you have defined the virtual server, you can add configuration statements or delete the server by referring to the server's IP address or name:
ServerIron(config)#server virtual www.altergo.com 207.95.55.1
ServerIron(config-vs-www.alterego.com)#port http
ServerIron(config-vs-www.alterego.com)#exit
ServerIron(config)#server virtual 207.95.55.1
ServerIron(config-vs-www.alterego.com)#exit
ServerIron(config)#server virtual www.altergo.com
ServerIron(config-vs-www.alterego.com)#exit
ServerIron(config)#no server virtual 207.95.55.1
After you define the real servers, virtual servers, and TCP/UDP ports, you need to bind the real and virtual servers together.
To bind the four web servers shown in Figure 3.5 to the virtual server address, enter the following commands:
ServerIron(config-rs-web4)# server virtual www.altergo.com
ServerIron(config-vs-www.alterego.com)# bind http web1 http
ServerIron(config-vs-www.alterego.com)# bind http web2 http
ServerIron(config-vs-www.alterego.com)# bind http web3 http
ServerIron(config-vs-www.alterego.com)# bind http web4 http
Syntax:
bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
NOTE:
For clarity, the bindings in the example above are shown as four separate entries. Alternatively, you can enter all the binding information as one command: bind http web1 http web2 http web3 http web4 http
Many global parameters have default settings. In most cases, you do not need to modify these parameters. The following sections describe the parameters, their possible values, and how to configure them.
NOTE:
To change the maximum number of sessions, TCP age, UDP age, or reassign threshold, see "Health Checks".
Starting with SI XL software release 07.3.07, if the SI is used only for server load balancing (in Layer 4 or Layer 7 SLB configurations), you can improve performance by entering server slb-optimize.
Syntax
[no] server slb-optimize
Example
ServerIron(config)#server slb-optimize
When this command is configured, packet processing for SLB traffic is done more efficiently, resulting in higher connection rates. The performance improvement applies to TCP SLB traffic only. It does not apply to UDP SLB or non-SLB traffic.
NOTE:
If TCS, FWLB, NAT, or IP forwarding are configured on the SI, no performance improvement may be apparent after entering this command.
Use server predictor to globally change the load-balancing method used by the SI.
Syntax
[no] server predictor least-conn | response-time | round-robin | weighted
When response-time is enabled, the faster server is selected. However, if a slower server is not used for more than one minute, it is to give it a chance to measure response time.
If you enable the weighted percentage method, you must configure both the virtual and real servers involved. Each real server is assigned a weight from 0 - 64000. The default weight is 0.
Example
ServerIron(config)#server predictor round-robin
NOTE:
If you enable server response time load balancing, you can weight individual servers based on a combination of weight and response time. See "Setting a Real Server's Weight Based on Response Time".
For overview information, see "Load-Balancing Predictor".
If the SI is attached to multiple routers or to a single router configured for FSRP, or HSRP, you need to identify the ports on the SI that are attached to the router(s). Explicitly identifying the ports enables the SI or switch to handle Layer 4 traffic correctly.
Syntax
[no] server router-ports <portnum>
Example
To identify port 8 as a router port:
ServerIron(config)#server router-port 8
To define multiple router ports on a switch, enter the port numbers, separated by blanks. You can enter up to eight router ports in a single command line. To enter more than 8 ports, enter the server router-port... command again with the additional ports.
You can limit the maximum number of TCP SYN requests on a per-second basis per server. A TCP SYN request is a packet a client sends requesting a TCP connection to the server. Possible values are 1 - 65535. The default value is 65535.
To limit the connections to a maximum of 3500 for all web servers on the network shown in Figure 3.5, enter the following command:
ServerIron(config)# server syn-limit 3500
Syntax:
[no] server syn-limit <1 - 65535>
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 [no] server icmp-message. When this feature is enabled, the SI sends an ICMP "Destination Unreachable" message to the client if the requested port either is not configured on any of the real servers or is unavailable because all the servers configured with the requested port are busy or down. The ICMP message feature is disabled by default.
The ICMP message feature enables the SI to send an ICMP "Destination Unreachable" message to a client for HTTP traffic. When this feature is enabled, the SI will send an ICMP "Destination Unreachable" message to a client whenever an HTTP port requested by the client is not configured on any of the real servers, or the real servers that have the requested port are busy or down.
Example
ServerIron(config)#server icmp-message
By default, if the application requested by a client is not available, the SI does one of the following things:
- In Release 07.2.25 and later 07.2.2x releases - Sends a TCP RST to the client.
- In Releases 07.2.24 and earlier, as well as stackable 07.1.x, and 07.3.x - Quietly drops the request.
Generally, an application is not available if all the real servers that have the application are unavailable or the application is not configured on the VIP requested by the client. The SI can do one of the following when a requested application is unavailable:
- Quietly drop the request
- Send an ICMP Destination Unreachable message (for UDP or TCP)
- Send a TCP RST (for TCP only) - the default action
Use [no] server icmp-message to globally configure the SI to send an ICMP Destination Unreachable message to a client if it requests a TCP application that is unavailable.
Use [no] server reset-message to configure the SI to send a TCP RST to a client if it requests a TCP application that is unavailable:
ServerIron(config)# server reset-message
NOTE:
ICMP messages are enabled by default in chassis Release 07.2.25 and later 07.2.x Releases. The messages are disabled by default in other releases.
NOTE:
This command overrides the server icmp-message command (see the following section). If the configuration contains both commands, the SI sends a TCP RST instead of an ICMP message for TCP requests. For UDP requests, the device still sends ICMP messages. TCP RST does not apply to UDP.
By default, the SI does not send a TCP RST to a client or server when its TCP session in the session table ages out.
Use server tcp-age reset to enable the SI to send a TCP RST to a client or server when a TCP session entry in use by the client or server ages out. You can enable the device to send a RST for client sessions only, server sessions only, or both. This command only works if you are running L7 SLB.
Syntax:
[no] server tcp-age reset [both | client | server]
Parameters:
both—(Default) The device sends messages to clients and servers.
client—The device sends messages only to clients.
server—The device sends messages only to servers.
Example:
ServerIron(config)# server tcp-age reset
NOTE:
This feature is supported on the ServerIronXL running software release 07.3.05 or later.
Use server source-ip to add an IP adddress for use by the real servers as their default gateway address. Source IP addresses, when used with the source NAT feature, enable you to place the SI in a multinetted environment. You can configure up to 64 source IP addresses on a SIXL running software release 07.3.00 or later. You can configure up to 40 source IP addresses on other models running 07.1.x or 07.2.x software.
Syntax
[no] server source-ip <ip-addr> <network-mask> <default-gateway>
The <default-gateway> parameter is required. By specifying "0.0.0.0" as a gateway, the system is going to use the ip default-gateway setting for the default gateway. The gateway function will not actually be disabled for the interface.
The additional IP addresses allow you to deploy the SI in multinetted environments, including the following examples:
- The SI and real servers are on different sub-nets.
- The remote access server (RAS) and SI are on different sub-nets.
- The border access router (BAR) and SI are on different sub-nets.
See "Web Hosting with SI and Real Servers in Different Sub-Nets" for an example of the type of configuration in which you need to use this feature.
NOTE:
Depending on the configuration, you might also need to enable source NAT. See "Web Hosting with SI and Real Servers in Different Sub-Nets". See "Multinetting Using NAT" for general information about the NAT operations performed by the SI.
The SI supports a maximum of 64,000 simultaneous connections on each source IP address. This maximum value is based on the architectural limits of IP itself. As a result, if you add only one source IP address, the SI can support up to a maximum of 64,000 simultaneous connections to the real servers. If you configure 64 source IP addresses, the SI can support more simultaneous connections.
Examples
ServerIron(config)#server source-ip 192.168.1.5 255.255.255.0 192.168.1.1
You can configure source IP addresses to enable the SI to communicate with routers and real servers that are in different subnets than the SI is in. For example, if the Figure 3.6 shows an example of a SI that uses both public and private source NAT addresses.
Figure 3.6 SI configured with public and private source NAT addresses
The SI in this example is configured with three source IP addresses. Two of the addresses are in the subnets of the real servers and the third address is in the same subnet as the SI management address.
The software considers any address that is not within the following address ranges to be a public address. These address ranges are defined as private address ranges in RFC 1918.
- 10.0.0.0 - 10.255.255.255
- 172.16.0.0 - 172.31.255.255
- 192.168.0.0 - 192.168.255.255
You can also use the server source-ip command under a real server to designate the source IP address for Source NAT.
For example, to specify that traffic from remote real server R1 use 193.77.7.7 as its source IP address, enter the following commands:
ServerIron(config)#server remote R1 193.77.7.2
ServerIron(config-rs-R1)#source-ip 193.77.7.7
If the <ip-addr> is not already configured as a source IP address on the SI (with the server source-ip command), an error message is displayed.
NOTE:
For Router (R) code, the SI uses the VE/interface address to do SNAT by default (no user action needed). However, VE addresses do not exist on Switch (S) code.
By default, the SI uses the MAC address of its default gateway as the destination MAC address for server replies (TCP SYN and TCP SYN ACK) to a client.
Use [no] server l7-dont-use-gateway-mac to enable use of the client MAC address instead of the default gateway address.
Example
ServerIron(config)#server l7-dont-use-gateway-mac
Source NAT allows the SI to use a specific source IP address as the source for sending packets to real servers, which is useful fo operating in a multinetted environment. You can enable source NAT globally or locally, on individual real servers. If you enable source NAT globally, the feature applies to all real servers. If you enable the feature locally, the SI performs source NAT only for those real servers. Other locally-attached real servers, on which source NAT is not enabled, must be in the same sub-net as the SI.
Syntax
[no] server source-nat
Example
ServerIron(config)#server source-nat
You must also configure a source IP address. The SI uses source NAT to translate its management IP address in the source field of the IP packet into the source IP address you configure. See "Multinetting Using NAT" and "server source-ip". See "Web Hosting with SI and Real Servers in Different Sub-Nets" for an example of the type of configuration in which you need to use Source NAT.
If you are configuring a pair of SIs for hot-standby (active-standby) and you want to use the same source IP address on each SI, use the server source-nat-ip command instead.
Reverse NAT allows the SI to change the source IP address of some traffic initiated by a real server. Specifically, the [no] server reverse-nat command causes the ServerIron to change the source IP address for traffic that the real server initiates on TCP or UDP ports that are bound to a VIP.
By default, the ServerIron does not perform address translation for any traffic initiated by the real server. However, if you enable Reverse NAT, the ServerIron does perform address translation for connections that the server initiates on ports that are bound to a VIP on the ServerIron.
Reverse NAT works with any port number you use for binding the real server to the VIP. However, TCP and UDP traffic initiated by a real server uses a source port that is chosen by the server when the traffic is sent. As a result, it is not easy to predict the source port numbers the real server will use. You can ensure that the ServerIron translates the source address of the traffic by binding the real server to a VIP using the "default" port. For example, if you configure VIP1 and bind it to real server RS1 using the default port, the ServerIron translates the source IP address in all TCP and UDP traffic initiated by RS1 from the real server's IP address into the VIP address.
Even when Reverse NAT is enabled, the ServerIron does not translate the source address for traffic that the real server initiates over ports that are not bound to a VIP.
If you bind a real server to more than one VIP, the ServerIron will use the address of the VIP that is bound to the server using the default port. For example, if you bind a real server to VIP1 using TCP port 80 and bind the same server to VIP2 using the default port, the ServerIron always uses VIP2 for Reverse NAT.
NOTE:
Reverse NAT does not affect reply traffic from the server. The feature applies only to traffic initiated by the server. In addition, the feature applies only to traffic on the TCP and UDP ports that are used to bind the real server to a VIP configured on the ServerIron. If the real server and VIP are bound using the default port, Reverse NAT applies to all TCP and UDP traffic initiated by the server.
The server reverse-nat command is disabled by default.
Example
ServerIron(config)#server real-name R1 10.10.10.1
ServerIron(config-rs-RS1)#port http
ServerIron(config-rs-RS1)#exit
ServerIron(config)#server virtual-name VIP1 192.168.1.10
ServerIron(config-vs-VIP1)#bind http RS1 http
ServerIron(config-rs-RS1)#exit
ServerIron(config)#server virtual-name VIP2 192.168.1.69
ServerIron(config-vs-VIP1)#bind default RS1 default
ServerIron(config)#server reverse-nat
The commands in this example create real server R1 and VIPs VIP1 and VIP2. VIP1 is bound to RS1 using TCP port 80 (HTTP). VIP2 is bound to RS1 using the default port. When RS1 initiates TCP or UDP traffic, the ServerIron translates the source IP address from 10.10.10.1 to 192.168.1.69. The ServerIron uses VIP2's IP address instead of VIP1's IP address for Reverse NAT because VIP2 is bound using the default port.
SLB and TCS allow the graceful shutdown of servers and services. By default, when a service is disabled or deleted, the ServerIron does not send new connections to the real servers for that service. However, the ServerIron does allow existing connections to complete normally, however long that may take.
Use [no] server force-delete to force the existing SLB connections to be terminated within two minutes.
If you disable or delete a service, do not enter an additional command to reverse the command you used to disable or delete the service, while the server is in graceful shutdown.
NOTE:
See "Real Server Shutdown" for important information about shutting down services or servers.
Example
Suppose you have unbound the Telnet service on real server 15, but you do not want to wait until the service comes down naturally. You can use the force-delete command to force server load-balancing connections to be terminated:
ServerIron(config)#server force-delete
To display active sessions for a specific server, enter | 
