SLB Overview

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.

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.

Value of SLB

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.

How SLB Works

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.

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.

Load-Balancing Predictor

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.

Configurable Application Grouping

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.

Sticky Connections

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

Configurable TCP/UDP Application Groups

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.

Concurrent Connections

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.

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.

Unlimited VIPs

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.

Geographically-Distributed Servers

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.

Global Server Load Balancing

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.

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

Link-Level Redundancy

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.

DSR

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.

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

Many-To-One TCP/UDP Port Binding

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.

HTTP Redirect

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.

Transparent VIP and Stateless Application Ports

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.

Multinetting Using NAT

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.

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.

Configuration Guidelines

The following configuration guidelines should be observed when configuring SLB on a switch:

Basic Configuration Example

A basic SLB configuration consists of a single SI and multiple real servers with identical content.

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.

Defining the Real Servers and Adding the Application Ports

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

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:

ServerIron(config)# server real web1 207.95.55.21
ServerIron(config-rs-web1)# port http
ServerIron(config-rs-web1)# exit

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

clone-server

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.

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.

virtual-name-or-ip

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.

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

Binding Virtual and Real Servers

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

Global SLB Settings

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.

slb-optimize

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.

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.

predictor

Use server predictor to globally change the load-balancing method used by the SI.

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

router-ports

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.

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.

TCP SYN Limit

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:

icmp-message

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.

Sending a TCP RST or ICMP Unreachable Message to a Client

By default, if the application requested by a client is not available, the SI does one of the following things:

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:

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:

tcp-age reset

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.

server source-ip

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.

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

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.

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.

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.

l7-dont-use-gateway-mac

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.

source-nat

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.

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

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.

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.

force-delete

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.

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:

To display active sessions for a specific server, enter show sessions real server <number> and a display as seen below will appear. Notice that the display below shows the Telnet connection on server 15 as awaiting unbinding. Without server force-delete, this feature will stay in this state until the session ends naturally.

Because the binding is awaiting deletion, it will also still be seen as an active binding, if you enter show session bind, as seen below:

Once force delete is enabled, the unbinding will occur within two minutes and show session real server s15 will show that connection as unbound, as seen below:

sticky-age

A connection is sticky if you configure the SI to send successive requests from the same client for the same application port to the same real server, instead of load balancing the requests to different real servers. Possible values are from 2 - 60 minutes. The default is 5 minutes.

Sticky connections are defined on a virtual server port of an SLB switch when a service request by a client mandates a series of sequential TCP/UDP port connections to be served by the same real server. For example, if a client is accessing dynamically generated pages, the client must consistently attach to the same server, otherwise the state information will be lost.

Starting in Release 07.3.07, the sticky age is a global setting applying to all virtual servers:

Starting in Release 07.3.07, you can also set the sticky age for an individual virtual server. The sticky age for the individual virtual server overrides the global setting:

ServerIron(config)#server virtual v1
ServerIron(config-vs-v1)#sticky-age 20

allow-sticky

Use server allow-sticky to allow the SI to continue using a sticky port (a persistent connection) even if you have entered a command to unbind the port or the port is disabled.

When you unbind an application port from a server, the SI temporarily places the port in the aw_unbnd (awaiting unbind) state. If you delete an application port, the SI temporarily places the port in the aw_del (awaiting delete) state. These temporary states allow open sessions on the port to be completed before the port is unbound or removed.

By default, when the SI receives a new request associated with a sticky port in the aw_unbnd state, the SI establishes the session on another real server, not the real server from which you are unbinding the port.

You can configure the SI to accept new sessions for the same real server for a sticky port, even under the following conditions:

The refresh-age option resets the age of a sticky session on the port whenever a new connection associated with the sticky port is established. This parameter ensures that the session stays up indefinitely until it is no longer needed.

By default, the SI does not reset the age of the session when new connections are established. Instead, the session times out after the sticky age expires.

If you use refresh-age, the SI resets the age of the session to the value of the sticky age. For example, if the sticky age is five minutes (the default), when the SI establishes a new session on the sticky port, the SI resets the age time for the session to five minutes. Each time the SI receives another connection request associated with the sticky session, the SI resets the session age again.

transparent-vip

This feature allows the SI to load balance the same VIP with other SIs, without "owning" the VIP address. Transparent VIP is useful when you want to configure multiple SIs to load balance for the same VIP.

To enable transparent VIP, enable the feature globally, then configure a cache redirection policy and apply it locally to the SI port(s) connected to the clients. The cache redirection policy identifies the application port(s) on the VIP that you want to load balance.

Enter commands such as the following to enable transparent VIP on SI port 1 for TCP port 80:

SI(config)# server transparent-vip
SI(config)# ip policy 1 cache tcp 80 local
SI(config)# interface ethernet 1
SI(config-if-1)# ip-policy 1

Real Server Settings

For basic real server configuration, you need to specify a name and the real server's IP address, then add the application ports that you want to load balance. The following sections describe more advanced real server options.

ip-address

The SI enables you to easily change a real server's IP address, even when the real server is active. This capability is useful when you want to perform some maintenance on the real server (either the server itself or the server's configuration on the SI) or when the network topology has changed.

By default, when you change a server's IP address, the SI performs the change gracefully, as follows:

Optionally, you can force all existing connections to be reset instead of waiting for them to terminate normally. When you force the connections to be reset, the SI immediately resets a connection when it receives client data for the connection.

ServerIron(config)# server real rs1
ServerIron(config-rs-rs1)# ip-address 5.6.7.8

The force-shutdown parameter immediately resets a client's connection to the IP address when the SI receives TCP data from the client. By default, the SI allows existing connections to terminate normally following the address change.

description

Use [no] description "<text>" to add a description to a real server, virtual server, firewall, or cache. The description appears in the output of show commands and in the running-config and startup-config files.

ServerIron(config)#server real RS20 1.2.3.4
ServerIron(config-rs-RS20)#description "Real Server # 20"

Location

When you define a real server, you specify whether the real server is local or remote.

Primary and Backup Servers

The real server is either a primary server or a backup server based on how you added the server:

Using the feature described in this section, you can explicitly designate a server to be a primary or backup server, regardless of the command you used to add it. Thus, a primary or backup server can be locally attached or attached through a router.

In addition, this feature implements the primary and backup configuration on an individual VIP basis. You designate each backup server by changing the real server configurations. You do not need to designate the primary servers. You enable the feature in individual VIPs for individual application ports.

Figure 3.7 shows an SLB configuration that uses locally-attached and remotely-attached servers. The configuration also uses some of the servers as the primary load-balancing servers while using the other servers only as backups. Notice that one of the locally-attached servers is a backup server while one of the remotely-attached servers is a primary load-balancing server.

By default, when this feature is enabled on a VIP and all the primary servers are unavailable, a VIP begins using the backup servers until a primary server becomes available again. Once a primary server is available, the VIP uses the primary server instead. Optionally, you can configure a VIP to continue to use the backup servers even after the primary servers become available again.

Configuring Primary and Backup Servers

backup

By default, the virtual server uses the locally attached real servers (added using the server real-name command) as the primary load-balancing servers and uses the remotely attached servers (added using the server remote-name command) as backups. In order for the backup functionality to operate, you must also apply the lb-pri-servers command.

Enabling a VIP to Use the Primary and Backup Servers

To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the load-balancing servers, enter the following command at the configuration level for the VIP:

This command enables VIP1 to use the backup and primary servers for application port HTTP.

The port http lb-pri-servers command is needed for the backup functionality to operate, regardless if you have local or remote real servers. For example, even if all your real servers are local and you have one designated as backup, it will not be used as a backup unless you apply this command.

To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example:

Complete CLI Example

Here are the commands for implementing the load-balancing configuration shown in Figure 3.7.

The following commands configure the real servers. Notice that the backup command is used with servers R3 and R5.

ServerIron(config)# server real-name R1 10.10.10.10
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real-name R2 10.10.10.20
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# exit
ServerIron(config)# server real-name R3 10.10.10.30
ServerIron(config-rs-R3)# backup
ServerIron(config-rs-R3)# port http
ServerIron(config-rs-R3)# exit
ServerIron(config)# server remote-name R4 198.10.10.40
ServerIron(config-rs-R4)# port http
ServerIron(config-rs-R4)# exit
ServerIron(config)# server remote-name R5 198.10.10.50
ServerIron(config-rs-R5)# backup
ServerIron(config-rs-R5)# port http

ServerIron(config-rs-R5)# server virtual-name VIP1 198.10.10.100
ServerIron(config-vs-VIP1)# port http lb-pri-servers
ServerIron(config-vs-VIP1)# bind http R1 http R2 http R3 http R4 http R5 http

Backup Real Server Port

Starting with Release 07.3.07, the backup functionality is extended to the application port level.

This means for a given real server, you can specify one port to be a backup, while another port is a primary. Figure 3.8 illustrates this enhancement.

In this example, real servers RS1 and RS2 are bound to a VIP. Each real server has three ports defined: HTTP, FTP, and DNS. RS1 is the primary server for HTTP and FTP, and the backup for DNS. RS2 is the primary server for DNS, and the backup for HTTP and FTP. An HTTP or FTP request will not be sent to RS2 unless the HTTP or FTP service on RS1 is down, and a DNS request will not be sent to RS1 unless the DNS service on RS2 is down.

ServerIron(config)# server virtual vs1 10.10.10.10
ServerIron(config-vs-vs1)# port http
ServerIron(config-vs-vs1)# bind http rs1 http rs2 http
ServerIron(config-vs-vs1)# port http lb-primary-servers

ServerIron(config-vs-vs1)# port ftp
ServerIron(config-vs-vs1)# bind ftp rs1 ftp rs2 ftp
ServerIron(config-vs-vs1)# port ftp lb-primary-servers

ServerIron(config-vs-vs1)# port dns
ServerIron(config-vs-vs1)# bind dns rs1 dns rs2 dns
ServerIron(config-vs-vs1)# port dns lb-primary-servers

ServerIron(config)# server real rs1 10.10.10.1
ServerIron(config-rs-rs1)# port http
ServerIron(config-rs-rs1)# port ftp
ServerIron(config-rs-rs1)# port dns backup
ServerIron(config-rs-rs1)# exit

ServerIron(config)# server real rs2 10.10.10.2
ServerIron(config-rs-rs2)# port http backup
ServerIron(config-rs-rs2)# port ftp backup
ServerIron(config-rs-rs2)# port dns
ServerIron(config-rs-rs2)# exit

Application Ports

You must specify the application ports that you want the SI to load balance. The SI sends client requests only to the application ports you specify in the real server definition.

You can use the CLI to add an application port to a real server you have already defined.

To add application ports to a real server, enter commands such as the following:

ServerIron(config)# server real web1 207.95.55.21
ServerIron(config-rs-web1)# port http
ServerIron(config-rs-web1)# port ftp
ServerIron(config-rs-web1)# port 8080

host-range

If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses on the real server, use [no] host-range <num>. This command creates a range of contiguous virtual IP addresses (VIPs) based on the VIP address of the virtual server. The SI creates the range by creating the number of VIPs that you specify with this command. You do not specify a range; you specify the number of hosts in the range. The beginning address in the range is always the VIP. The IP addresses must be contiguous on the real server.

ServerIron(config)#server real-name r1 10.4.4.4
ServerIron(config-rs-r1)#host-range 500
ServerIron(config-rs-r1)#exit
ServerIron(config)#server real-name r2 10.4.4.5
ServerIron(config-rs-r2)#host-range 500
ServerIron(config-rs-r2)#exit
ServerIron(config)#server virtual-name lotsofhosts 209.157.22.99
ServerIron(config-vs-lotsofhosts)#host-range 500
ServerIron(config-vs-lotsofhosts)#exit

Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually.

ServerIron(config)#server real-name r1 10.0.0.1
ServerIron(config-rs-r1)#host-range 20

This command configures a range of 20 IP addresses, from 10.0.0.1 through 10.0.0.20.

Host-Range Maps

A host range allows you to easily configure a contiguous range of VIP addresses. Instead of individually configuring each VIP address, you can configure the base VIP address (the lowest VIP address in the range), then specify how many addresses the range contains. These VIP addresses can, in turn, be mapped to a range of real server addresses. When a client requests an address in the VIP host range, the ServerIron automatically maps the VIP address to a real IP address on a real server, based on the real server address's offset from the base VIP address.

For example, you can specify that a host range of 5 VIP addresses on a virtual server be mapped to a host range of 5 IP addresses on a real server. If the virtual server's base IP address is 192.168.9.10 and the real server's base IP address is 10.10.10.30, the mapping would be as follows.

Additionally, you can map a host range of VIP addresses to a host range of IP addresses on multiple real servers. For example:

With host ranges, the mapping between the host range on the virtual server and the host range on the real server(s) had to be sequential and contiguous. With the host-range map feature, addresses in the host range on the real server(s) do not need to be contiguous.

The host-range map feature allows you to select the addresses in a real server's host range that can be mapped to addresses in the virtual server's host range. For example, using this feature, you can establish the following mapping between a host range of VIP addresses on a virtual server and a host range of IP addresses on three real servers.

In this example, real server 1 can use addresses in its host range that are offset by 2, 3, and 4 from its base IP address to map to VIP addresses that are offset by 2, 3, and 4 from the virtual server's base VIP address. However, the IP address in real server 1's host range that is offset by 1 from its base IP address would not be mapped to the VIP address that is offset by 1 from the virtual server's base VIP address.

You can use the host-range map feature with up to 32 real servers and host ranges of up to 255 addresses.

To use the host-range map feature to establish a mapping structure like the one shown in Table 3.3, you perform the following tasks:

Assigning a Bind-ID to a Real Server

A bind-ID is a number you assign to a real server. When you configure the host range map, you refer to the real servers by their bind-IDs. Assign a bind-ID to each real server to be included in a host-range map.

For example, to implement the sample configuration in Table 3.3, you can assign real server 1 to bind-ID = 1, real server 2 to bind-ID = 2, and real server 3 to bind-ID = 3. The following commands configure these three real servers.

ServerIron(config)# server real rs1 10.10.10.30
ServerIron(config-rs-rs1)# host-range 5
ServerIron(config-rs-rs1)# bind-id 1
ServerIron(config-rs-rs1)# port http
ServerIron(config-rs-rs1)# exit

ServerIron(config)# server real rs2 10.10.10.50
ServerIron(config-rs-rs2)# host-range 5
ServerIron(config-rs-rs2)# bind-id 2
ServerIron(config-rs-rs2)# port http
ServerIron(config-rs-rs2)# exit

ServerIron(config)# server real rs3 10.10.10.70
ServerIron(config-rs-rs3)# host-range 5
ServerIron(config-rs-rs3)# bind-id 3
ServerIron(config-rs-rs3)# port http
ServerIron(config-rs-rs3)# exit

The host-range <number-of-addresses> command specifies the number of IP addresses that will be included in the host range for the real server. For example, since real server rs1 has a base IP address of 10.10.10.30, the host-range 5 command causes addresses 10.10.10.30 through 10.10.10.34 to be included in the host range. You use the host range map to select individual addresses within the range and omit the addresses you want to omit.

The bind-id <number> command assigns a bind-ID to each real server to be included in a host-range map. When you configure a host range map, you refer to the real servers by their bind-IDs. Each real server in a host range map must have a unique bind-ID.

Defining a Host-Range Map

The host-range map specifies which IP addresses in the host ranges of each real server you actually want to use for SLB. The map enables you to selectively include individual addresses, by specifying their offsets in the range.

To define a host range map, you associate each VIP offset with one or more bind-IDs, then determine the binary representation of this association, then convert the binary representation to a hexadecimal number. You enter this hex number as part of the host-range map definition.

When defining a host-range map, it may be useful to create a table containing a row for each VIP offset and a column for each bind-ID (real server), as well as a column for the binary representation and a column for the hex number. For each VIP offset, specify which bind-ID can use IP addresses in its host range to map to the VIP offset address. For the sample configuration in Table 3.3 on page 3-29, such a table would look like the following:

The first line of the table indicates that VIP offset 1 applies only to the real server with bind-ID = 2. Only real server 2 will map the IP address in its host range that is offset by 1 to the IP address that is offset by one from the VIP's base IP address. The binary representation of this is "010", which means "not bind-ID = 3, bind-ID = 2, not bind-ID = 1". The hex representation of "010" is "2". You enter this hex number as part of the definition of the host-range map.

Using the information in Table 3.4, you would define the host-range map for the sample configuration in Table 3.3 on page 3-29 as follows:

ServerIron(config)# vip-host-range-map 1
ServerIron(config-vip-host-range-1)# vip-offset 1 2
ServerIron(config-vip-host-range-1)# vip-offset 2 7
ServerIron(config-vip-host-range-1)# vip-offset 3 5
ServerIron(config-vip-host-range-1)# vip-offset 4 3
ServerIron(config-vip-host-range-1)# exit

The default behavior (without a host-range map definition) is to bind each VIP address offset from the virtual server's base address to the comparable offset address on each of the real servers. In the sample configuration, the host-range map definition for VIP offset 2 specifies that addresses from all three real servers be included in the bindings. Since this is the default behavior, the vip-offset 2 7 command in the host-range map definition can be omitted.

Applying the Host-Range Map to the Virtual Server

After you assign the bind-IDs to the real servers and create a host-range map, you apply the host-range map to the virtual server.

ServerIron(config)# server virtual vs1 192.168.9.10
ServerIron(config-vs-vs1)# host-range 5
ServerIron(config-vs-vs1)# host-range-map 1
ServerIron(config-vs-vs1)# port http
ServerIron(config-vs-vs1)# bind http rs1 http rs2 http rs3 http

no-host-range-ip-check

If you are using DSR (sometimes called "Direct Server Return"), you configure a separate loopback interface on each real server for the VIP's base address and also for each additional address in the host range you want to use on the real server.

The SI sends the client traffic to the real server without translating the destination address. The real server receives the client traffic addressed to a loopback address configured on the server and responds directly to the client.

Normally, the CLI checks for address range overlaps when you configure a real server. For example, if real server abc has management IP address 10.10.10.10 and a host range of 5, the CLI assumes that the real server also will have addresses 10.10.10.11 - 10.10.10.14. If you then try to configure real server def with management IP address 10.10.10.12, the CLI detects an address overlap, since 10.10.10.12 is within the range specified for abc, and displays an error message instead of accepting the configuration. Here is an example:

ServerIron(config)#server real def 10.10.10.12
duplicate IP address !!!
Error - Failed to create real server

The overlap check is not applicable to DSR configurations since the addresses in the range are not going to be configured on the real server. For example, if the VIP is 192.168.9.10 with a range of 5, you need to configure loopback interfaces 192.168.9.10 - 192.168.9.14 on each real server. You do not need to configure a range beginning with the real server's management IP address.

For a DSR configuration, if the management IP address of a real server is within the host range on another real server (even though the addresses in the range will not actually be configured on the real server), you need to disable overlap checking using [no] server no-host-range-ip-check.

After you disable the range check, use the commands described in the previous section to configure the real servers, bind-IDs, VIP, and host range map.

max-conn

Use [no] max-conn <1-1000000> to limit the maximum number of sessions the SI will maintain in its session table for a real server. By setting a limit for a server, you can avoid a condition where the capacity threshold of the server is exceeded.

When a real server reaches the maximum defined connection threshold, an SNMP trap is sent. When all the real servers in a server pool reach their maximum connection threshold, additional TCP/UDP packets are dropped, and an ICMP destination unreachable message is sent.

Up to one million total sessions are supported on the SI. This is also the default maximum connection value for real servers.

ServerIron(config)#server real web1
ServerIron(config-rs-web1)#max-conn 145000
ServerIron(config-rs-web4)#end
ServerIron#write mem

Starting with Release 07.3.07, you can limit the maximum number of connections for individual application ports on a real server:

For example, if you want to limit the number of FTP connections on real server web1 to 10, enter the following commands:

ServerIron(config)#server real web1
ServerIron(config-rs-web1)#port ftp max-conn 10

Layer 3 Health Check

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

Use [no] no-l3-check to disable the Layer 3 health check on an individual real server.

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

To globally disable Layer 3 health checks for local real servers or remote real servers, see server no-real-l3-check and server no-remote-l3-check.

source-nat

This feature allows the SI to use a source IP address as the source for packets sent to the real server.

Source NAT allows the SI to be in more than one sub-net. If the real server and the SI are in different sub-nets and they are not connected by a router that is multinetted, enable source NAT on the real server.

If you enable source NAT on a real server, the feature applies only to the server. You also can enable source NAT globally. See "source-nat".

ServerIron(config)# server real-name berto
ServerIron(config-rs-berto)# source-nat

Weight

This parameter specifies the weight assigned to the real server. It is used for the weighted and least connection with server response-time-weights for load balancing methods.

Suppose you want to assign a higher weight to real server web1 to bias traffic toward that server. No other changes are made to the weights of web servers 2, 3, and 4, and they remain configured with the default weight of zero (Figure 3.5).

ServerIron(config)# server virtual www.alterego.com
ServerIron(config-vs-www.alterego.com)# predictor weighted
ServerIron(config-vs-www.alterego.com)# server real web1 207.95.55.21
ServerIron(config-vs-www.alterego.com)# exit
ServerIron(config)# server real web1
ServerIron(config-rs-web1)# weight 10

The <least-connections-weight> parameter specifies the real server's weight relative to other real servers in terms of the number of connections on the server. More precisely, this weight is based on the number of session table entries the SI has for TCP or UDP sessions with the real server. You can specify a value from 0 - 65000. The default is 1. This parameter is required. However, if you want to use a weight value only for the Server Response Time but not for the number of connections, specify 0 for this parameter.

The <response-time-weight> parameter specifies the real server's weight relative to other real servers in terms of the server's response time to client requests sent to the server. You can specify a value from 0 - 65000. The default is 0 (disabled). This weight is applicable only when the server response time load-balancing method is enabled. See "Setting a Real Server's Weight Based on Response Time".

If you enter a value for <response-time-weight>, the SI adds the two weight values together when selecting a real server. If you specify equal values for each parameter, the SI treats the weights equally. The number of connections on the server is just as relevant as the server's response time. However, if you set one parameter to a higher value than the other, the SI places more emphasis (weight) on the parameter with the higher value. For example, if you specify a higher server response time weight than the weight for the number of connections, the SI pays more attention to the server's response time than to the number of connections it currently has when considering the real server for a new connection.

Setting a Real Server's Weight Based on Response Time

The Server Response Time metric, 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.

For example, if you bind a virtual server to three real servers, and one of the servers tends to respond less quickly than the other two but otherwise has the same connection capacity as the faster servers, you can enter commands such as the following to increase the Server Response Time weight of the faster servers:

ServerIron(config)# server real-name wolalak
ServerIron(config-rs-wolalak)# weight 1 5
ServerIron(config-rs-wolalak)# exit
ServerIron(config)# server real-name wuwanich
ServerIron(config-rs-wuwanich)# weight 1 5

This command sets the Server Response Time weight on the faster servers to 5, giving the servers more weight in terms of response time than the slower real server.

Real Server Ports

You can globally configure an application port by configuring a port profile for the port. When you configure a port profile, the parameters in the profile apply to all servers that include the application port. To configure a port profile, see "Port Profiles".

You also can locally define some SLB port parameters on an individual real-server basis:

Port State

Application ports are enabled by default. To disable an application port on a real server, use either of the following methods.

ServerIron(config)# server real Sy_Borg 192.168.4.69
ServerIron(config-rs-Sy_Borg)# port http disable

ServerIron(config)# server real Sy_Borg 192.168.4.69
ServerIron(config-rs-Sy_Borg)# no port http disable

To disable all the application ports on a real server, enter the following command at the configuration level for the server:

Globally Disabling Application Ports

You can globally disable a Layer 4 port on the SI. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled.

When the SI is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly.

SI(config)# server port 80
SI(config-port-http)# disable real
SI(config-port-http)#

SI(config)# server port 80
SI(config-port-http)# disable virtual
SI(config-port-http)#

port unbind-all

By default, a real server's application ports remain bound to the virtual servers to which you bind them. You can unbind all of a real server's application ports from the virtual servers.

To unbind a real server's application ports, enter the following command at the configuration level for the server:

To re-bind an application port, you must use the bind command at the configuration level for the virtual server. For example, if server R1 has two application ports, 80 and 8080, enter the following commands to rebind the ports to virtual server VIP1. This example assumes that the VIP uses two real servers (R1 and R2) for the application ports.

ServerIron(config-vs-VIP1)# bind http R1 http R2 http
ServerIron(config-vs-VIP1)# bind 8080 R1 8080 R2 8080

port keepalive

When you configure a port profile for an application port, the L4/L7 keepalive health check for that port is enabled automatically. You also can enable or disable the keepalive health check for an application port on a specific real server, without affecting the global setting for the health check.

ServerIron(config)# server real Auto_Plooker 192.168.2.69
ServerIron(config-rs-Auto_Plooker)# port http keepalive

ServerIron(config)# server real Auto_Plooker 192.168.2.69
ServerIron(config-rs-Auto_Plooker)# no port http keepalive

max-con-rate

Connection Rate Control (CRC) specifies the maximum number of new TCP, UDP, or individual port connections per second allowed on the real server.

The SI increments the connection counter for real server connections only after the SI selects a server for the connection. If the SI cannot serve a client request because a real server, cache, or firewall already has the maximum number of connections for the current second for the requested port, the SI tries another server. If there are no servers available, the SI sends a TCP RST to the client.

If you configure a limit for TCP or UDP and also for an individual application port, the SI uses the lower limit. For example, if you limit new TCP connections to a real server to 1000 per second and also limit new HTTP connections to 600 per second, the SI limits connections to TCP port HTTP to 600 per second.

To limit the number of new TCP and UDP connections a real server can receive each second, enter commands such as the following:

ServerIron(config)# server real RS1 1.2.3.4
ServerIron(config-rs-RS1)# max-tcp-conn-rate 1000
ServerIron(config-rs-RS1)# max-udp-conn-rate 800

The first command limits new TCP connections to the real server to 1000 per second. The second command limits the rate of new UDP connections to the real server to 800 per second.

The <num> parameter specifies the maximum number of connections per second. There is no default.

To limit the rate of new connections for a specific application port, enter commands such as the following:

ServerIron(config-rs-RS1)# port http
ServerIron(config-rs-RS1)# port http max-tcp-conn-rate 600

These commands add port HTTP (80) to the real server and limit the rate of new connections to the port to 600.

Layer 7 Health Check Parameters

VIP Settings

For basic Virtual IP server (VIP) configuration, you need to specify a name and the virtual server's IP address (the VIP), add the application ports that you want to load balance, then bind the VIP to the real servers based on the application ports. The following sections describe more advanced virtual server options.

Application Ports and Bindings

You can specify the TCP or UDP application ports for which you want the SI to load balance requests. Add the ports to the virtual server, then bind the virtual server to the real server based on the ports.

To add an application port to a virtual server, enter commands such as the following:

ServerIron(config-rs-web4)# server virtual www.altergo.com 207.95.55.1
ServerIron(config-vs-www.alterego.com)# port http

To bind a real server to a virtual server, enter commands such as the following:

Primary and Backup Servers

You can enable the virtual server to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers.

Configuring Primary and Backup Servers

Enabling a VIP to Use the Primary and Backup Servers

To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers, enter the following command at the configuration level for the VIP:

This command enables VIP1 to use the backup and primary servers for application port HTTP.

To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example:

host-range

If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses, define a host range on the real servers and on the virtual server. Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually.

Enter commands such as the following to configure a host range on a virtual server.

ServerIron(config)# server virtual-name v1 209.157.22.6
ServerIron(config-vs-v1)# host-range 20

HTTP Redirect

This feature configures the SI to send an HTTP redirect message to the client, so the client redirects its HTTP connection to the real server's IP address instead of the VIP. Use this feature when you configure remote real servers and want replies from the servers to go directly to clients.

To enable HTTP redirect (disabled by default) on a virtual server, enter commands such as the following:

ServerIron(config)# server virtual-name VIP 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80
ServerIron(config-vs-VIP1)# httpredirect

Predictor: Virtual Server Specific Configuration

You can override the globally configured load balancing method for an individual virtual server. The methods you can use are the same as the ones you can configure globally. For overview information, see "Load-Balancing Predictor".

To change the load balancing method on an individual virtual server, enter commands such as the following:

ServerIron(config)# server virtual www.plookme.com 207.95.5.1
ServerIron(config-vs-www.plookme.com)# predictor response-time

Symmetric SLB Priority

If you are configuring a pair of SIs to provide redundancy for individual VIPs, you must specify an SLB priority on each SI for each of the VIPs. The SI with the higher priority for a given VIP is the default active SI for that VIP. The other SI is the default standby for the VIP.

ServerIron(config)# server virtual-name noi-is-cool 1.2.3.4
ServerIron(config-vs-noi-is-cool)# sym-priority 254

You can specify from 0 - 255. If you specify 0, the priority setting is removed.

track

You can configure the SI to send all client requests for a specific set of TCP/UDP ports to the same real server as a "primary" TCP/UDP port grouped with the other ports. 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. See "TCP/UDP Application Groups" for an example of application grouping.

Note that if any service port is down for a real server, any track ports on that real server are not considered for load balancing.

To configure a TCP/UDP application group, enter the following commands. These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky.

ServerIron(config)# server virtual-name v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# track 80 23 69
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69

Syntax: [no] track <primary-port> <TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port>]]]

track-group

A track-group is similar to track ports. The SI sends a client's request for one of the ports to the same real server the SI selected for the same client's request for another application port. The features differ in the following way:

Note that if any service port is down for a real server, any track port groups on that real server are not considered for load balancing.

ServerIron(config)# server virtual-name v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track-group 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit

In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69) together. Whenever a client attempts to connect to a port within the group, the SI ensures all ports in the group are active before granting the connection.

The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the group.

After the SI sends a client to a real server for any of these three ports, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to eight ports can be grouped together using the track group function. A port can be part of only one group. The track-group and track commands for a port are mutually exclusive.

track-group-unbind-wait-all

By default, when you unbind a port that is the lead port in a track group, all the ports that track the lead port also are immediately unbound. This occurs even if a port is still active and has not completed the AW_unbind (awaiting unbind) state.

Use [no] server track-group-unbind-wait-all to configure the SI to allow track ports in a track group to unbind gracefully following the unbinding of the track group's lead port.

Normal UDP Aging for DNS and RADIUS

By default, 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. You can configure the SI to instead age DNS or RADIUS sessions out normally using the UDP age timer.

To age DNS or RADIUS sessions using the UDP age timer, enter the following command at the global CONFIG level of the CLI:

For DNS and RADIUS UDP load balancing, unless the port is configured with this command, the DNS or RADIUS sessions are always aged out after two minutes.

Transparent VIP

Transparent VIP allows you to configure a SI to transparently load balance a VIP, without owning the VIP address. Multiple SIs on which this virtual server is configured to be transparent can load balance requests for the server. For examples and configuration information, see "Stateless SLB".

To configure an individual virtual server for the transparent VIP feature, enter a command such as the following:

TCP and UDP Ages for VIPs

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. In previous releases, the TCP and UDP ages are global settings, applying to all TCP or UDP ports on all virtual servers. You could optionally change the TCP or UDP age on a specific port by modifying the port's profile.

Starting in Release 07.4.00, you can set the TCP or UDP ages for a specific virtual server, and you can set the TCP or UDP ages for an individual port on a virtual server.

For example, to set the TCP age for virtual server v1 to 20 minutes, enter the following commands:

To set the UDP age for virtual server v1 to 26 minutes, enter the following commands:

To set the TCP age for the HTTP port on virtual server v1 to 10 minutes, enter the following commands:

ServerIron(config)# server virtual v1
ServerIron(config-vs-v1)# port http tcp-age 10

To set the UDP age for the SNMP port on virtual server v1 to 26 minutes, enter the following commands:

ServerIron(config)# server virtual v1
ServerIron(config-vs-v1)# port snmp udp-age 26

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.

More specific settings override more general settings; that is, a TCP or UDP age setting for the HTTP port will override a TCP or UDP age setting for the virtual server, which will override the global TCP or UDP age (set with the server tcp-age or server udp-age commands).

Virtual Server Ports

The following sections describe how to modify parameters for application ports on virtual servers.

Port Disable

Application ports are enabled by default. To disable an application port on a virtual server, use either of the following methods.

ServerIron(config)# server virtual Zoot_Allures 1.2.3.4
ServerIron(config-vs-Zoot_Allures)# port http disable

ServerIron(config)# server virtual Zoot_Allures 1.2.3.4
ServerIron(config-vs-Zoot_Allures)# no port http disable

Globally Disable Real and Virtual

SI(config)# server port 80
SI(config-port-http)# disable real
SI(config-port-http)#

SI(config)# server port 80
SI(config-port-http)# disable virtual
SI(config-port-http)#

Port Sticky

By default, the SI sends a client's request to the next available real server based on the load balancing method. This is true regardless of whether the client has already sent a request for the same application. If you want the SI to send all of a client's requests for a given application to the same real server during a client's session with the server, configure the application port to be sticky.

The port tracking and port group features require the application ports to be sticky.

To configure a TCP/UDP application group, enter the following commands. These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky. In addition, the Telnet and TFTP ports are configured to track the HTTP port.

ServerIron(config)# server virtual-name v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky

Concurrent

The concurrent feature allows a client to have sessions on different application ports on the same real server at the same time. When you enable an application port to be concurrent, the real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers.

Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP/UDP ports that you configure on the virtual server.

ServerIron(config)# server virtual-name v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 concurrent

Smooth Factor

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.

S = Smooth factor, which is configurable and can be from 1 - 99. The default is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.

For example, if a given real server's previous response time value was 2 milliseconds, and a new measurement also results in 2 milliseconds, the calculated server response time using the default smooth factor is as follows:

If the real server's response time slows due to processing for additional connections, the slower response time affects the Server Response Time calculation for the server. For example, if the next server response time sample is 5 milliseconds instead of 2, the Server Response Time calculation is as follows:

Since the real server's response time has slowed by two and a half times, the server's response time calculation biases the SI away from selecting that server for new connections.

You can affect the degree of difference in subsequent response time weights by changing the smooth factor (S). For example, if you change the smooth factor from 90 (the default) to 50, the calculations shown above have the following results:

Here is the calculation when the previous and new response times are 2 milliseconds:

Notice that the differences between the first and second samples are much greater when the smooth factor is 50 than when the smooth factor is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.

You can change the smooth factor on an individual virtual server basis and on an individual application port basis.

To change the smooth factor for a virtual server, enter a command such as the following at the configuration level for the virtual server:

The <num> parameter specifies the smooth factor value the server response time calculation uses. You can specify a number from 1 - 99. The default is 90.

Stateless

By default, the SI creates session table entries for sessions between clients and applications on real servers. The SI uses the session table entries to maintain state information for the sessions. The SI uses the state information for features such as health checking and session failover in hot-standby configurations.

You can configure individual application ports to be stateless. The SI does not maintain state information for a stateless port. Making a port stateless is useful when you want to conserve session table resources or when you have configured the VIP to be transparent.

To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server. Here is an example:

SI(config)# server real R1 10.10.10.1
SI(config-rs-R1)# port http
SI(config-rs-R1)# exit
SI(config)# server real R2 10.10.11.1
SI(config-rs-R2)# port http
SI(config-rs-R2)# exit
SI(config)# server virtual StatelessHTTP 192.168.4.69
SI(config-vs-StatelessHTTP)# port http stateless
SI(config-vs-StatelessHTTP)# bind http R1 http
SI(config-vs-StatelessHTTP)# bind http R2 http

The <tcp/udp-portnum> parameter specifies the application port you want to make stateless.

Virtual Source

In a typical configuration, a client's IP address remains the same throughout the client's session with a virtual server. However, in some configurations where a proxy is used for the clients before the client traffic reaches the SI, the client's IP address can be different for each request. To configure session persistence in a proxy environment, configure a standard IP ACL containing the addresses, then use the Virtual Source feature.

When you configure the Virtual Source feature, the SI sends all client traffic from a specified range of IP addresses to the same real server for the application ports you specify. To specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some configurations, the proxy device assigns different IP addresses to traffic from the same client. Unless you configure the addresses to go to the same real server, the SI might load balance the client traffic to different servers. This makes applications that require continued access to the same real server unusable.

ServerIron(config)# access-list 1 permit 209.157.22.0
ServerIron(config)# server virtual fromproxy 1.1.1.1
ServerIron(config-vs-fromproxy)# port 80 sticky-acl 1

Syntax: [no] access-list <num> deny | permit <source-ip> | <hostname> <wildcard> [log]

Syntax: [no] access-list <num> deny | permit <source-ip>/<mask-bits> | <hostname> [log]

For standard IP ACL configuration information, see the "Configuring Standard ACLs" section in the "Using Access Control Lists (ACLs)" chapter of the Foundry Switch and Router Installation and Basic Configuration Guide.

Translation

By default, the SI translates the application port number requested by the client into the application port number you specify on the virtual server when you bind it to the real server. For example, if you bind port 80 on a virtual server to port 8080 on a real server, the SI translates the application port in the client's request from port 80 into 8080 before forwarding the request to a real server.

A few SI configurations require that you disable translation for an application port. For example, if you want to bind multiple virtual IP addresses to the same real server, you must disable port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias port for the application. Disabling port translation enables the virtual IP addresses to use the same actual port number on the real server while the SI collects and displays separate statistics for the alias port number associated with each virtual IP address.

ServerIron(config)# server virtual-name v1 209.157.22.1
ServerIron(config-vs-v1)# no port 80 translate

Health Check of Multiple Web Sites on the Same Real Server

In a configuration with two VIPs bound to the same server port, where the VIPs are hosting multiple web sites on the same server (different VIPs point to different sites), an alias port is required. In this scenario, if the master port goes down, the SI stops forwarding traffic to the other sites as well, even though these sites are up. This occurs because the SI uses the master port's state for traffic forwarding decisions. To resolve this issue, you must enable the SI to use the alias port's state for traffic forwarding decisions. Thus, if the alias port's state is up, the SI continues to forwarding traffic. Likewise, if the alias port's state is down, the SI stops forwarding traffic to the server.

Use use-alias-port-state to enable the SI to use the alias port's state for traffic forwarding decisions.

In the next example, if site test1 goes down, the SI would stop forwarding traffic to VIP2 as well. In this scenario, you would enable the port http-use-alias-port-state command so that traffic to VIP2 does not stop when site test1 goes down.

ServerIron(config)#server real r1 10.10.1.31
ServerIron(config-rs-r1)#port http
ServerIron(config-rs-r1)#port http url "test1.html"
ServerIron(config-rs-r1)#port 8080
ServerIron(config-rs-r1)#port 8080 url "test2.html"
ServerIron(config-rs-r1)#server virt VIP1 10.10.1.121
ServerIron(config-vs-v1)#port http
ServerIron(config-vs-v1)#bind http r1 http
ServerIron(config-vs-v1)#server virt VIP2 10.10.1.122
ServerIron(config-vs-v2)#port http
ServerIron(config-vs-v2)#bind http r1 8080
ServerIron(config-vs-v2)#no port http translate

SSL Accelerators

Overview

The SI features enhanced support for SSL accelerators by allowing the SI to send return traffic from a real server back to the SSL accelerator from which it was sent.

Normally, when the SI supports SLB for some services and TCS for others, the cache server uses the original client's IP address as the source IP address for SLB traffic sent from the cache server to the SI. When the SI sends return traffic from the real server back to the client, it goes directly to the original client (bypassing the cache server).

However, some configurations (such as those using an SSL accelerator as a cache server) may require that traffic from a real server first go back to the cache server before going to the original client. Using a technique called VIP spoofing, the SI, when it receives traffic from a real server on a specified port, forwards it not to the original client, but to the cache server where the SLB traffic was initiated.

The following diagram illustrates a configuration that uses VIP spoofing to direct SLB traffic from a real server to the SSL accelerator that originated the traffic.

In this configuration, SSL traffic travels from the client to the real server as follows:

To implement a configuration like the one in Figure 3.9, enter the following commands.

SLB Configuration

You can configure the SI so that the client's request to the VIP is translated to the real IP address of the cache server (that is, the SSL Accelerator) and then sent there. In this case, the port ssl cache-enable command is not used in the VIP's configuration. Instead, the cache server is bound to the SSL port on the VIP. In the example above, VIP vip1 would have the following configuration:

ServerIron(config)# server virtual vip1 10.10.1.100
ServerIron(config-vs-vip1)# port http
ServerIron(config-vs-vip1)# port http spoofing
ServerIron(config-vs-vip1)# port ssl
ServerIron(config-vs-vip1)# port ssl sticky
ServerIron(config-vs-vip1)# bind ssl cs1 ssl
ServerIron(config-vs-vip1)# bind http rs1 http
ServerIron(config-vs-vip1)# exit

TCS Configuration

ServerIron(config)# server cache-name cs1 10.10.1.10
ServerIron(config-rs-cs1)# port ssl
ServerIron(config-rs-cs1)# port ssl no-health-check
ServerIron(config-rs-cs1)# port http
ServerIron(config-rs-cs1)# port http no-health-check
ServerIron(config-rs-cs1)# port http url "HEAD /"
ServerIron(config-rs-cs1)# exit

ServerIron(config)# server real rs1 10.10.1.40
ServerIron(config-rs-rs1)# port http
ServerIron(config-rs-rs1)# port http url "HEAD /"
ServerIron(config-rs-rs1)# exit

ServerIron(config)# server virtual vip1 10.10.1.100
ServerIron(config-vs-vip1)# port http
ServerIron(config-vs-vip1)# port http spoofing
ServerIron(config-vs-vip1)# port ssl
ServerIron(config-vs-vip1)# port ssl sticky
ServerIron(config-vs-vip1)# port ssl cache-enable
ServerIron(config-vs-vip1)# bind http rs1 http
ServerIron(config-vs-vip1)# exit

ServerIron(config)# server cache-group 1
ServerIron(config-tc-1)# cache-name cs1
ServerIron(config-tc-1)# exit

ServerIron(config)# ip address 10.10.1.1 255.255.255.0
ServerIron(config)# ip default-gateway 10.10.1.3
ServerIron(config)# ip policy 1 cache tcp 0 global
ServerIron(config)# ip policy 2 cache tcp ssl global

Real Server Shutdown

The force shutdown feature (sometimes called the force delete feature) allows you to force termination of existing SLB connections. This feature assumes that you already have shut down a TCP/UDP service on the real server or you have shut down the real server itself.

There are several methods for shutting down a service or server. Each method has consequences, so choose the method that works best in your situation.

Policy-Based Routing for Reverse SLB Traffic

Software Release 09.1.00R supports Policy-Based Routing (PBR) for reverse SLB traffic on the SI. Policy-Based Routing routes traffic based on policies you define. A PBR policy specifies the next hop for traffic that matches the policy.

To configure PBR, you define the policies using IP ACLs and route maps, then enable PBR globally or on individual interfaces. The device routes traffic that matches the ACLs according to the instructions in the route maps.

In a network where clients belonging to different sub-nets and VLANs are sending traffic to VIPs belonging to their respective sub-nets, you can configure PBR to send return traffic back to each client the way it came, rather than having all of the traffic use the default route. To do this, you can configure ACLs and route maps and apply them either globally or to individual interfaces.

In the following example, clients belonging to two different sub-nets 33.33.33.0/24 and 10.10.1.0/24 are accessing VIPs 33.33.33.111 and 10.10.1.111, respectively. The next-hop routers for these clients are 33.33.33.1 and 10.10.1.1. To load balance the return traffic to the clients, you can configure the following ACLs and route map:

ServerIron(config)# access-list 101 permit ip 33.33.33.0 0.0.0.255 any
ServerIron(config)# access-list 102 permit ip 10.10.1.0 0.0.0.255 any

ServerIron(config)# route-map test-route permit 101
ServerIron(config-route-map test-route)# match ip address 101
ServerIron(config-route-map test-route)# set ip next-hop 33.33.33.2
ServerIron(config-route-map test-route)# exit

ServerIron(config)# route-map test-route permit 102
ServerIron(config-route-map test-route)# match ip address 102
ServerIron(config-route-map test-route)# set ip next-hop 10.10.1.2
ServerIron(config-route-map test-route)# exit

See "Policy-Based Routing (PBR)" in the Foundry Enterprise Configuration and Management Guide for more information on configuring PBR.

DSR

Overview

Direct Server Return (DSR) enables the return traffic to not be processed by the SI. Instead, the real server directly sends the return traffic to the client. In this case, the SI changes the way it sends health checks to the application so that the health checks do not rely on the return traffic.

There are many DSR applications. You can use DSR on a single SI or apply it to a High Availability (HA) scenario (Hot Standby SLB, symmetric SLB, and Sym-Active SLB).

DSR configurations enhance server response time and increase capacity on the SI, by allowing server responses to bypass the SI on the way to clients and at the same time increasing the number of simultaneous connections the SI can support.

When DSR is used in the configuration, the return traffic gets directed over a more efficient path.

DSR configurations can enhance server response time and increase capacity on the SI, by allowing server responses to bypass the SI on the way to clients and at the same time increasing the number of simultaneous connections the SI can support.

Some SI implementations are in topologies where both directions of load-balancing traffic, the client-to-server and server-to-client traffic, flow through the SI. In this type of configuration, the SI uses two sessions for each connection. One session is for the client-server traffic and the other session is for the server-client traffic.

Typically, the client-server traffic uses less bandwidth than the server-client traffic. The client-server traffic usually consists of the initial GET requests to the VIP and TCP ACKs when the client receives a response from the server. The remaining traffic consists of the requested web pages sent to the client by the server.

The DSR feature places the real server directly in contact with the client, so that server-client traffic does not pass through the SI but instead goes directly from the server to the client. By placing the client directly in contact with the real server, DSR enhances overall performance and throughput, and thus enhances the service experienced by the client.

A SI configured for Server Load Balancing acts as a dispatcher, sending client requests for a VIP directly to the real server, which responds directly to the client. The SI does not translate the destination IP address in the client's request from the VIP into the real server's IP address as in other SLB configurations. Instead, the SI leaves the destination IP address unchanged.

The DSR feature applies to individual TCP/UDP ports. To configure the SI for DSR, you enable the feature for individual TCP/UDP ports when configuring the virtual server. For example, when you enable TCP port 80 (HTTP) on a virtual server, you can add the dsr parameter to enable DSR for that port. Traffic for other ports still returns through the SI. The SI does not translate the destination IP address in client requests for the port with DSR enabled. However, the SI does still translate the destination IP address in the client's request to the real server's IP address for other ports.

To configure the real servers for DSR, configure a loopback interface on each real server and assign the VIP addresses to the loopback interface. The loopback interface enables the real server to respond to client requests directed at the VIPs, while at the same time keeping the real server "hidden". The loopback interface responds to unicast traffic directed to it, but does not respond to ARP requests. The SI responds to pings and ARPs for the VIPs. Thus, an attempt to obtain the real server's MAC address by ARPing a VIP does not succeed. See "Configuring the Loopback Address on a Real Server".

Remote Failover Servers for DSR

You can use real servers on other sub-nets as remote servers in DSR configurations. In this configuration, the SI uses the local servers as in previous releases. This means all the local servers must have Layer 2 connectivity to the SI. However, if all the local servers become unavailable, the SI then fails over to the remote servers, thus continuing to provide service to the clients.

Health Checks with DSR

Normally, the SI can perform health checks on an application port only when server replies from that port pass back through the SI. If the SI does not see the real server's responses to client requests, the SI concludes that the application or the entire server is down and stops sending client requests to that server.

When you enable an application port for DSR, the SI can still perform heath checks on the application by sending the health checks to the loopback address you configure on the real server:

ServerIron(config)# server virtual-name v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 dsr

The configuration procedures for the health checks are the same as for other types of SLB. See "Health Checks".

DSR Configuration Example

The following table and Figure 3.11 show an example of a DSR configuration for a High Availability scenario.

Because multiple VIPs are mapping to the same ports on the same real servers, TCP/UDP port binding is used. Thus, port 180 on VIP2 on SI A and on VIP1 on SI B is a logical port that is bound to port 80 on the real servers. For more information, see "Many-To-One TCP/UDP Port Binding".

Command Support

To implement the configuration shown in Figure 3.11, enter the following commands.

Note the dsr parameter on the port commands that add the HTTP port (TCP port 80) to the VIPs. To enable DSR for additional TCP/UDP ports, you use the dsr parameter for each port when you add the port to a VIP.

Commands on SI A

Enter the following commands to configure the real servers. Notice that all four real servers must be configured, and bound to the VIPs, on both SIs. Notice also that two HTTP ports are added to each real server. This type of configuration requires that you use the TCP/UDP port binding feature to bind the ports on the two real servers to the same port on the virtual server. For information, see "Many-To-One TCP/UDP Port Binding".

SIA(config)# server real-name Real_Server_1 10.0.0.1
SIA(config-rs-Real_Server_1)# port http
SIA(config-rs-Real_Server_1)# port 180
SIA(config-rs-Real_Server_1)# exit
SIA(config)# server real-name Real_Server_2 10.0.0.2
SIA(config-rs-Real_Server_2)# port http
SIA(config-rs-Real_Server_2)# port 180
SIA(config-rs-Real_Server_2)# exit
SIA(config)# server real-name Real_Server_3 10.0.1.1
SIA(config-rs-Real_Server_3)# port http
SIA(config-rs-Real_Server_3)# port 180
SIA(config-rs-Real_Server_3)# exit
SIA(config)# server real-name Real_Server_4 10.0.1.2
SIA(config-rs-Real_Server_4)# port http
SIA(config-rs-Real_Server_4)# port 180
SIA(config-rs-Real_Server_4)# exit

SIA(config)# server virtual-name VIP1 209.157.22.100
SIA(config-vs-VIP1)# port http dsr
SIA(config-vs-VIP1)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 http
SIA(config-vs-VIP1)# sym-priority 254
SIA(config-vs-VIP1)# exit
SIA(config)# server virtual-name VIP2 209.157.22.101
SIA(config-vs-VIP2)# port http dsr
SIA(config-vs-VIP2)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180
SIA(config-vs-VIP2)# no http port translate
SIA(config-vs-VIP2)# sym-priority 2
SIA(config-vs-VIP2)# exit
SIA(config)# write memory

Commands on SI B

SIB(config)# server real-name Real_Server_1 10.0.0.1
SIB(config-rs-Real_Server_1)# port http
SIB(config-rs-Real_Server_1)# port 180
SIB(config-rs-Real_Server_1)# exit
SIB(config)# server real-name Real_Server_2 10.0.0.2
SIB(config-rs-Real_Server_2)# port http
SIB(config-rs-Real_Server_2)# port 180
SIB(config-rs-Real_Server_2)# exit
SIB(config)# server real-name Real_Server_3 10.0.1.1
SIB(config-rs-Real_Server_3)# port http
SIB(config-rs-Real_Server_3)# port 180
SIB(config-rs-Real_Server_3)# exit
SIB(config)# server real-name Real_Server_4 10.0.1.2
SIB(config-rs-Real_Server_4)# port http
SIB(config-rs-Real_Server_4)# port 180
SIB(config-rs-Real_Server_4)# exit

SIB(config)# server virtual-name VIP1 209.157.22.100
SIB(config-vs-VIP1)# port http dsr
SIB(config-vs-VIP1)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180
SIB(config-vs-VIP1)# no http port translate
SIB(config-vs-VIP1)# sym-priority 2
SIB(config-vs-VIP1)# exit
SIB(config)# server virtual-name VIP2 209.157.22.101
SIB(config-vs-VIP2)# port http dsr
SIB(config-vs-VIP2)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 http
SIB(config-vs-VIP2)# sym-priority 254
SIB(config-vs-VIP2)# exit
SIB(config)# write memory

Configuring the Loopback Address on a Real Server

This section contains procedures for configuring loopback addresses on some common types of real servers.

Solaris

You might need to "plumb" the interface first. In this case, enter the following commands:

Linux

To configure a loopback interface on Linux, enter a command such as the following:

To configure a loopback interface on NT, you need to configure a new network adapter. Use the following procedure. This procedure applies to the following products:

Manual Installation

After the adapter is installed successfully, you can configure its options manually, as with any other adapter.

Unattended Installation

Modify the Unattend.txt file using the following example as a guide to install the Microsoft Loopback adapter:

[Params.Adapter01]
InfID="*msloop" ; Microsoft Loopback Adapter
ConnectionName = "MS Loopback Adapter"

; TCP/IP parameters
; Use parameter values specific to your network
[Params.MS_TCPIP]
AdapterSections=params.TCPIP.Adapter01
DNS=yes
DNSSuffixSearchOrder=mycorp.com
EnableLMHosts=No

; Adapter Specific TCP/IP parameters
; Use parameter values specific to your network
[params.TCPIP.Adapter01]
SpecificTo=Adapter01
DNSDomain=mycorp.com
DNSServerSearchOrder=192.168.5.251
WINS=no
DHCP=no
IPAddress=192.168.5.10
SubnetMask=255.255.255.0
DefaultGateway=192.168.5.254

Deleting the Unwanted Routes

In some cases, NT creates a route that has the same address as the loopback interface. You need to delete this route.

Two methods are shown in this section. If you receive an error message while trying to use the simple method, you need to use the long method instead.

The simple method requires you to delete the route that NT creates when you add the loopback interface. The route you need to delete is the one that has the same IP address as the loopback interface.

Enter the route print command to display the server's route table. In this example, the loopback interface has address 192.168.200.106.

C:\>route print

Active Routes:

  Network Address          Netmask  Gateway Address        Interface  Metric
          0.0.0.0          0.0.0.0  192.168.204.254  192.168.200.251       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1

192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1

    192.168.200.0    255.255.255.0  192.168.200.251  192.168.200.251       1
  192.168.200.106  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.251  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.255  255.255.255.255  192.168.200.251  192.168.200.251       1
        224.0.0.0        224.0.0.0  192.168.200.106  192.168.200.106       1
        224.0.0.0        224.0.0.0  192.168.200.251  192.168.200.251       1
  255.255.255.255  255.255.255.255  192.168.200.251  192.168.200.251       1

Delete the route that has the same address as the loopback interface.

C:\>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106

Display the route table again to verify that the unwanted route is gone.

C:\>route print 

Active Routes:

  Network Address          Netmask  Gateway Address        Interface  Metric
          0.0.0.0          0.0.0.0  192.168.204.254  192.168.200.251       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
    192.168.200.0    255.255.255.0  192.168.200.251  192.168.200.251       1
  192.168.200.106  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.251  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.255  255.255.255.255  192.168.200.251  192.168.200.251       1
        224.0.0.0        224.0.0.0  192.168.200.106  192.168.200.106       1
        224.0.0.0        224.0.0.0  192.168.200.251  192.168.200.251       1
  255.255.255.255  255.255.255.255  192.168.200.251  192.168.200.251       1

The long method, like the short method, requires you to delete the route that NT creates when you add the loopback interface. However, what makes this method is long is that in some cases, when the route table has more than one route in the network that contains the loopback interface, the route delete command deletes the wrong route. In this case, you need to enter the command again to delete the route that has the loopback address, then re-add the other route.

Enter the route print command to display the server's route table. In this example, the loopback interface has address 192.168.200.106. Notice that the route table also contains another route (192.168.200.250) in the same network. The 192.168.200.250 route is the gateway route and needs to stay in the route table.

C:\users\default>route print

Active Routes:

 Network Address          Netmask  Gateway Address        Interface  Metric
         0.0.0.0          0.0.0.0  192.168.200.254  192.168.200.250       1
       127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1

192.168.200.0 255.255.255.0 192.168.200.250 192.168.200.250 1
192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1

 192.168.200.106  255.255.255.255        127.0.0.1        127.0.0.1       1
 192.168.200.250  255.255.255.255        127.0.0.1        127.0.0.1       1
 192.168.200.255  255.255.255.255  192.168.200.106  192.168.200.106       1
       224.0.0.0        224.0.0.0  192.168.200.250  192.168.200.250       1
       224.0.0.0        224.0.0.0  192.168.200.106  192.168.200.106       1
 255.255.255.255  255.255.255.255  192.168.200.106  192.168.200.106       1

Enter the route delete command to delete the unwanted 192.168.200.106 route.

C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106

Display the route table again to verify the results. In this example, NT deletes the first 192.168.200.x route in the table instead of deleting the route you want to delete. If this occurs when you are performing this procedure, go to Step 4. Otherwise, you are through with this procedure.

C:\users\default>route print

Active Routes:

  Network Address          Netmask  Gateway Address        Interface  Metric
          0.0.0.0          0.0.0.0  192.168.200.254  192.168.200.250       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1

192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1

  192.168.200.106  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.250  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.255  255.255.255.255  192.168.200.106  192.168.200.106       1
        224.0.0.0        224.0.0.0  192.168.200.250  192.168.200.250       1
        224.0.0.0        224.0.0.0  192.168.200.106  192.168.200.106       1
  255.255.255.255  255.255.255.255  192.168.200.106  192.168.200.106       1

Enter the route delete command again to delete the unwanted route.

C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106

Display the route table again to verify the results. In this example, none of the 192.168.200.x routes remain in the table.

C:\users\default>route print

Active Routes:

  Network Address          Netmask  Gateway Address        Interface  Metric
          0.0.0.0          0.0.0.0  192.168.200.254  192.168.200.250       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
  192.168.200.106  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.250  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.255  255.255.255.255  192.168.200.106  192.168.200.106       1
        224.0.0.0        224.0.0.0  192.168.200.250  192.168.200.250       1
        224.0.0.0        224.0.0.0  192.168.200.106  192.168.200.106       1
  255.255.255.255  255.255.255.255  192.168.200.106  192.168.200.106       1

Enter the route add command to re-add the gateway route.

C:\users\default>route add 192.168.200.0 mask 255.255.255.0 192.168.200.250

Display the route table again to verify that the table contains the gateway route but does not contain a route with the loopback address.

C:\users\default>route print

Active Routes:

  Network Address          Netmask  Gateway Address        Interface  Metric
          0.0.0.0          0.0.0.0  192.168.200.254  192.168.200.250       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1

192.168.200.0 255.255.255.0 192.168.200.250 192.168.200.250 1

  192.168.200.106  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.250  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.200.255  255.255.255.255  192.168.200.106  192.168.200.106       1
        224.0.0.0        224.0.0.0  192.168.200.250  192.168.200.250       1
        224.0.0.0        224.0.0.0  192.168.200.106  192.168.200.106       1
  255.255.255.255  255.255.255.255  192.168.200.106  192.168.200.106       1

Show Commands

show server global

Use show server global to display global Layer 4 SI configuration information:

ServerIron(config)# show server global

Server Load Balancing - global parameters
Predictor = least-conn
Force-deletion = 0
Reassign-threshold = 20
Reassign-limit = 3
Ping-interval = 2
Ping-retries = 4
TCP-age = 30
UDP-age = 5
Sticky-age = 30
TCP-syn-limit = 65535
TCP-total conn = 4233
Unsuccessful conn = 0
ICMP-message = Disabled

**Global Layer 4 Configuration Information**
This Field...	Displays...
Symmetric SLB Parameters You also can display this information separately. See "show server symmetric".
Server Symmetric port	The SI port number on which the SI perceives other SIs running Symmetric SLB.
Group_id	The Symmetric SLB group ID. The group ID is always 1 in the current release.
Candidate cnt	The number of ports on which the SI perceives a partner SI running Symmetric SLB.
Port	The TCP/UDP port for which Symmetric SLB is enabled.
Priority	The priority for the VIP.
No-rx	Information Foundry technical support can use to help resolve Symmetric SLB configuration issues.
SLB Parameters
Predictor	The load balancing metric in effect on the SI. The predictor can be one of the following: least-conn (least connections) least-sess (least sessions) response-time (server response time) Note: This value also applies to the combined method of least connections and server response time weights. round-robin (round robin) weighted (weighted percentage) The default is least-conn. You can assign these metrics on a global basis and an individual virtual server basis. For more information or to globally change the predictor, see "predictor". To locally change the predictor for a virtual server, see "Predictor: Virtual Server Specific Configuration".
Force-deletion	The state of the force shutdown option. This option immediately shuts down a server or service instead of waiting for existing connections to end before shutting the server or service down. The state can be one of the following: 0 - Disabled 1 - Enabled
Reassign-threshold	The number of contiguous inbound TCP-SYN packets sent to the server that the server has not responded to. The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received, the counter is cleared. The default reassign threshold is 21 unacknowledged TCP SYN-ACKs. The value can be from 6 - 254. To change the reassign threshold, see "Reassign Threshold" Note: You can modify this parameter to help minimize vulnerability to TCP SYN attacks.
Reassign-limit	The number of missed TCP SYN packets the SI will accept before moving an inbound connection attempt to another server.
Layer 3 Health Check Parameters
Ping-interval	How often the SI sends a Layer 3 IP ping to test the basic health and reachability of the real servers. When enabled, this parameter specifies the interval for the pings. To change the interval, see "ping-interval, ping-retries".
Ping-retries	How many times the SI resends a ping to a real server that is not responding. The default is 4 and can be from 2 - 10. To change this parameter, see "ping-interval, ping-retries". If the server still does not respond after the last retry, the SI marks the server FAILED and removes it from the load balancing rotation.
Global TCP/UDP Parameters
TCP-age	The number of minutes the SI allows a TCP connection to remain unused before closing the connection. The default is 30 minutes. To change this parameter, see "tcp-age". The value shown here is the global value. You can override this value for an individual TCP/UDP port by modifying its port profile. See "Overriding the Global TCP or UDP Age".
UDP-age	The number of minutes the SI allows a UDP connection to remain unused before closing the connection. The default is 5 minutes. To change this parameter, see "udp-age". The value shown here is the global value. You can override this value for an individual TCP/UDP port by modifying its port profile. See "Overriding the Global TCP or UDP Age".
Sticky-age	The number of minutes a sticky server connection can remain inactive before aging out. The default is 5 minutes.
TCP-syn-limit	The maximum number of TCP SYN connections per second the SI is allowed to send to the real server. The default is 65535 connections. You can guard against TCP SYN attacks by changing this parameter to a lower value. See "TCP SYN Limit".
TCP Connections Counters
TCP-total conn	The total number of TCP connections the SI is currently managing.
Unsuccessful conn	The number of client requests for a TCP port that the SI could not fulfill because the server was busy or down, or the port was not configured on the server.
ICMP Message Feature State
ICMP-message	The state of the ICMP message feature. The state can be one of the following: Disabled - The SI does not send ICMP "Destination Unreachable" messages to a client that requests an HTTP port that is on a busy or down server or that is not configured on the server. This is the default. Enabled - The SI does send ICMP "Destination Unreachable" messages to clients when the requested HTTP port is not available or not configured. To change the state of this feature, see "icmp-message".

show server real

Use show server real to display configuration information and statistics for the real servers configured on the SI:

**Real Server Information**
This Field...	Displays...
Server State Codes
Server State	The possible values for the server state. The state of each real server is shown by the State field. See below.
General Server Parameters
Name	The name of the real server. This is the name you assigned to the server when you configured it on the SI.
IP	The IP address of the real server. If you configured a host range of VIPs on the server, the number following the IP address (after the colon) is the number of hosts on the server. In the example shown above, the VIP address is 209.157.23.60 and the address has been configured with a host range of four hosts. For more information, see "Web Hosting with Unlimited Virtual IP Addresses".
State	The state of the real server, based on the results Layer 4 or Layer 7 health checks. The state can be one of the following states, also listed next to "Server State" at the top of the show server real display: 1 - Enabled 2 - Failed 3 - Test 4 - Suspect 5 - Graceful shutdown 6 - Active Note: The value in this field is based on the results of Layer 4 or Layer 7 health checks, if enabled. To display the server state based on Layer 3 health checks, see the State field in the show server session display. (See "show server session".)
Wt	The weight assigned to this server. The weight applies only if the predictor (load balancing method) is "weighted". See "Predictor: Virtual Server Specific Configuration".
Max-conn	The maximum number of client connections that the SI will manage for the server. A connection consists of two sessions, the client-to-server session and the server-to-client session. By default, the SI allows up to 500,000 connections (one million sessions) on a server. If you need to lower the maximum number of connections the SI will manage, see "session-limit".
Src-nat	The configured and operational states of the source NAT feature. The two states are separated by a colon ( : ). The configured state is shown first, followed by the operational state. Each state can have one of the following values: 0 - Disabled 1 - Enabled
Dest-nat	The configured and operational states of the destination NAT feature. The two states are separated by a colon ( : ). The configured state is shown first, followed by the operational state. Each state can have one of the following values: 0 - Disabled 1 - Enabled
Remote server	Indicates whether the server is configured on the SI as a remote server or a local server. The SI uses remote servers as failovers if all the local servers are down. This field can have one of the following values: No - The server is not a remote server. Yes - The server is a remote server. For more information about remote servers, see "Web Hosting with Geographically-Distributed Servers".
Dynamic	A statistic used by Foundry technical support.
TCP/UDP Port Statistics The following fields apply to all the TCP/UDP ports on the real servers. Note: For DNS, HTTP, and RADIUS ports, the server-specific health check information for the port is listed under the port's statistics. For information about the health check parameters, see "HTTP Keepalive Method, Value, and Status Codes".
Port	The TCP/UDP port name or number. This field can have one of the following values: default dns - the well-known name for port 53 ftp - the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the SI, the name "ftp" corresponds to port 21.) http - the well-known name for port 80 imap4 - the well-known name for port 143 ldap - the well-known name for port 389 nntp - the well-known name for port 119 ntp - the well-known name for port 123 pop2 - the well-known name for port 109 pop3 - the well-known name for port 110 radius - the well-known name for udp port 1812 smtp - the well-known name for port 25 snmp - the well-known name for port 161 ssl - the well-known name for port 443 telnet - the well-known name for port 23 tftp - the well-known name for port 69 <number> - the port number, if the port is not one of those listed above
State	The state of the port. The state can be one of the following: enabled failed test suspect graceful shutdown active unbnd Note: If the state is unbnd, you have not bound the port to a virtual server port.
Ms	The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations. For track ports, the state of the master port. When a port is configured to track a master port, the SI sends a client's request for the tracking port to the same real server as the master port. See "track-group" and "TCP/UDP Application Groups". In the example show real server output shown above, assume that port 500 is tracked by port 600. If port 500's state changes, port 600's state also changes to match. For many-to-one TCP/UDP port binding, the state of the port that is translated in the port binding between the real server and the virtual server. The ports that are not translated follow the state of the port that is translated. See "Many-To-One TCP/UDP Port Binding". In the example show real server output shown above, assume that port 70 is untranslated and follows the state of port http. If port http's state changes, port 70's state also changes to match. This field can have one of the following values for the types of ports listed above: 1 - Enabled 2 - Failed 3 - Test 4 - Suspect 5 - Graceful shutdown 6 - Active For all other types of ports, the value is always 0.
CurConn	The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConns	The number of client connections on the server since the SI was last booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Rx-pkts	The number of packets the SI has received from the server.
Tx-pkts	The number of packets the SI has sent to the server.
Rx-octet	The number of octets (bytes) the SI has received from the server.
Tx-octet	The number of octets (bytes) the SI has sent to the server.
Reas	The number of times the SI has reassigned the connection to another server in the rotation because the server that is in use has not responded to two contiguous TCP SYNs from the client. When this occurs, the SI directs the client to another server upon receiving the third SYN from the client. Note: Windows 98 sends two TCP SYNs for each connection attempt. Note: This statistic does not apply to DSR (Direct Server Return).

show server virtual

Use show server virtual to display configuration information and statistics for the virtual servers configured on the SI using either of the following methods:

**Virtual Server Information**
This Field...	Displays...
General Server Parameters
Server Name	The name of the virtual server. This is the name you assigned to the server when you configured it on the SI.
IP	The IP address of the virtual server. If you configured a host range of VIPs on the server, the number following the IP address (after the colon) is the number of hosts on the server. In the example above, the VIP has a host range of 4 addresses.
Status	The status of the virtual server. The status can be one of the following: enabled disabled
Predictor	The load balancing predictor the SI uses to balance traffic among the real servers bound to this virtual server. The predictor can be one of the following: least-conn (least connections) least-sess (least sessions) response-time (server response time) Note: This value also applies to the combined method of least connections and server response time weights. round-robin (round robin) weighted (weighted percentage) You can assign these metrics on a global basis and an individual virtual server basis. For more information or to globally change the predictor, see "predictor". To locally change the predictor for a virtual server, see "Predictor: Virtual Server Specific Configuration".
TotConn	The number of client connections on the server since the SI was last booted or restarted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Dynamic	A statistic used by Foundry technical support.
HTTP-redirect	The state of the HTTP redirect feature. This feature enables the SI to send an HTTP redirect message to the client if all the real servers are down and the SI is therefore sending client requests to a remote server. The HTTP redirect message instructs the client to redirect its HTTP connection directly to the remote server, bypassing the SI. The state can be one of the following: disabled enabled For more information, see "Using HTTP Redirect with Geographically-Distributed Servers".
Sym	Information for Symmetric SLB. The following information is displayed: group - The Symmetric SLB group number. state - State 3 means the VIP is inactive. State 5 means the VIP is active. priority - The Symmetric SLB priority configured on the SI. keep - The number of times an SSLB backup has failed to communicate with the active SI. By default, the counter is incremented by 1 every 400 milliseconds the backup SI is late responding to the active SI's keepalive message. The counter is reset to 0 each time the backup SI replies to a keepalive message. If the counter goes higher than the maximum number allowed (20 by default, thus 8 seconds), the standby SI takes over as the new active SI. Normally, this field almost always contains 0. Note: This field is applicable only on the active SI. dyn priority/factor - The current dynamically set priority and the decrement value. In this example, an application has failed a health check, so the dynamic priority is 20 instead of 30. The decrement value is 10. If the priority and dyn priority values match, then all the VIP's applications that are configured for SSLB are responding to their health checks. Activates - The number of times this SI has become the active SI. Inactive - The number of times this SI has changed from being the active SI. Best-standby-mac - The MAC address of the backup SI with the second-highest priority. This SI will become the active SI if a failover occurs. For more information about Symmetric SLB, see "Symmetric SLB".
TCP/UDP Port Information and Statistics
Port	The TCP/UDP port name or number. This field can have one of the following values: default dns - the well-known name for port 53 ftp - the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the SI, the name "ftp" corresponds to port 21.) http - the well-known name for port 80 imap4 - the well-known name for port 143 ldap - the well-known name for port 389 nntp - the well-known name for port 119 ntp - the well-known name for port 123 pop2 - the well-known name for port 109 pop3 - the well-known name for port 110 radius - the well-known name for udp port 1812 radiuso - UDP port 1645, which is used in some older RADIUS implementations instead of port 1812 smtp - the well-known name for port 25 snmp - the well-known name for port 161 ssl - the well-known name for port 443 telnet - the well-known name for port 23 tftp - the well-known name for port 69 <number> - the port number, if the port is not one of those listed above
State	The state of the port. The state can be one of the following: enabled failed test suspect graceful shutdown active unbnd Note: If the status is unbnd, you have not bound the port to a real server port.
Sticky	Whether the port is "sticky". When a port is sticky, the SI uses the same real server for multiple requests from the same client for the port. For non-sticky ports, the SI load balances the requests and thus does not necessarily send them all to the same real server. This parameter can have one of the following values: NO YES For more information, see "TCP/UDP Application Groups".
Concur	Whether the port is configured for concurrent connections. A port configured to allow concurrent connections can have more than connection open to the same client at the same time. For more information, see "TCP/UDP Application Groups".
CurConn	The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConn	The number of client connections on the server since the SI was booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
PeakConn	The highest number of connections the VIP has had at the same time.

Virtual Server's Bound Ports

On SI chassis devices running software version 07.2.26A or later, the show server virtual command has an option that displays detailed information for the server's bound application ports.

**Virtual Server Bound Port Information**
This Field...	Displays...
Binding Information
<port>------->	The virtual server port.
<real-server-name>: <ip-addr>	The name and IP address of the real server to which the port is bound.
<port> (<state>)	The state of the application port on the real server. The state can be one of the following: Enabled Failed Test Suspect Graceful shutdown Active For information about these states, see the "Application Port States" section in the "Configuring Port and Health Check Parameters" chapter of the Foundry ServerIron Installation and Configuration Guide.
Bound Port Information Note: This information is the same as the application information displayed by the show server real command.
Port	The real server port.
State	The state of the application port on the real server. See the description for "<port> (<state>)" above.
Ms	The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations. For track ports, the state of the master port. For many-to-one TCP/UDP port binding, the state of the port that is translated in the port binding between the real server and the virtual server. This field can have one of the following values for the types of ports listed above: 1 - Enabled 2 - Failed 3 - Test 4 - Suspect 5 - Graceful shutdown 6 - Active For all other types of ports, the value is always 0.
CurConn	The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConn	The number of client connections on the server since the SI was last booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Rx-pkts	The number of packets the SI has received from the server.
Tx-pkts	The number of packets the SI has sent to the server.
Rx-octet	The number of octets (bytes) the SI has received from the server.
Tx-octet	The number of octets (bytes) the SI has sent to the server.
Reas	The number of times the SI has reassigned the connection to another server in the rotation because the server that is in use has not responded to two contiguous TCP SYNs from the client. When this occurs, the SI directs the client to another server upon receiving the third SYN from the client. Note: Windows 98 sends two TCP SYNs for each connection attempt. Note: This statistic does not apply to DSR (Direct Server Return).

show server bind

Use show server bind to display port-binding information using either of the following methods:

The display lists the port bindings for each virtual server configured on the SI. The first row of information for each virtual server lists the virtual server name and VIP. The following rows list the TCP/UDP ports configured on the virtual server and the real servers and port names or numbers to which each port is bound.

In the example shown above, two virtual servers are configured on the SI, v100 and v105. The first set of rows in the example output shown above is for virtual server v100, with VIP 209.157.23.100.

The rows below the first row list the real servers and ports to which the virtual server's ports are bound. The rows are grouped by port type. The first two rows after the first row in the example above list the port bindings for the virtual server's HTTP port. In this case, the virtual server is bound to an HTTP port on two real servers, s43 and s60. The port name or number on the real server is listed following the real server's IP address. In this example, the HTTP port to which v100 is bound on s43 is "http", the well-known name for the port. The virtual server's HTTP port is bound to port 8080 on real server s60.

show server session

**Field Descriptions for show server session**
Field	Description
Global Statistics
Avail. Sessions	The number of sessions that are still available for use. By default, the SI is configured to allow the maximum number of sessions it can support. However, if you need to decrease the number of sessions supported, see "session-limit".
Total Sessions	The number of sessions that are currently in use.
Total C->S Conn	The number of connections initiated by clients.
Total S->C Conn	The number of connections initiated by servers. Generally, this value is 0 unless the client is using FTP or another application that causes the server to initiate connections.
Total Reassign	The number of unacknowledged TCP SYN-ACKs on all the real servers combined. When a server reaches the maximum number of unacknowledged TCP SYN-ACKs allowed by the SI (the reassign threshold), the SI marks that server FAILED and removes it from the load balancing rotation. The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received from a real server, the counter is cleared for that server, thus reducing the total count. For more information, see "Reassign Threshold". Note: This statistic does not apply to DSR (Direct Server Return).
Unsuccessful Conn	The number of connection attempts by clients or servers that were unsuccessful.
Fast-aged : total	If the fast-age threshold is configured, 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.
Random-aged : total	If the random threshold is configured, 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. See "session-max-idle" for more information on the fast-age and random thresholds.
Statistics for Individual Real Servers
Server State	The possible values for the server state. The state of each real server is shown by the State field. See below.
Real Server	The name of the real server. This is the name you gave the server when you configured it.
St	The state of the real server. The state can be one of the states listed by "Server State" at the top of the display. Note: The value in this field is based on the results of Layer 3 health checks. To display the server state based on Layer 4 or Layer 7 health checks, see the State field in the show server real display. (See "show server real".)
CurConn	The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConn	The number of client connections on the server since the SI was last booted or restarted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Tot RevConn	The total number of connections initiated by the server to a client.
CurrSess	The number of sessions currently open on the SI.
PeakConn	The highest number of simultaneous connections the SI has managed since it was last booted or restarted.

show server traffic

In theory, each BP sends its counters to the MP. The MP then aggregates all the counters from each BP and synthesizes them into tables. However in reality, not all the BP counters are implemented yet on the MP.

The MP correctly shows most of the commonly used counters. For some counters of show server traffic and show server debug, you should rconsole into BPs and issue show commands from there.

Use clear server traffic to clear traffic statistics for real and virtual servers.

**Field Descriptions for show server traffic**
Field	Description
Client->Server	Number of packets sent from clients to servers.
Server->Client	Number of packets sent from servers to clients.
Drops	Number of packets dropped by the SI. This statistic includes the following: TCP Resets - Resets sent by the SI Forward Resets - Resets from the client Unsuccessful requests - Requests sent to a TCP or UDP port that is not bound to the request's destination VIP
Aged	Number of TCP and UDP sessions that the SI closed because the aged out. A session ages out when the age timer configured on the SI expires. For more information, see "tcp-age" and "udp-age".
Fw_drops	Number of client-to-server packets the SI has dropped. If this statistic is high, there might not be a session entry. This can occur under the following circumstances: If the session is terminated normally but the client sends another RESET. If Denial of Service (DoS) protection is configured and has been activated. If the maximum number of sessions has been reached. If all the real servers are down.
Rev_drops	Number of server-to-client packets the SI has dropped. If this statistic is high, there might not be a session entry. This can occur for the same reasons as listed for the Fw_drops field.
FIN_or_RST	Number of FINs or RSTs passing through (forward and reverse) a non-optimized path (no FPGA processing) inside the ServerIron. All traffic is optimized (FPGA processed) by default except FTP control, streaming protocol control, and DNS traffic.
old-conn
fast vport found	Number of successful virtual-port searches using an improved (faster) method.
Duplicate SYN	When the SI receives a SYN packet for a session that is already listed in the session table (show server sessions), the SI has received a Duplicate SYN. The counter is then incremented by 1.
TCP ttl reset recvd	Total (ttl) number of resets received in both the forward and reverse direction. This counter applies to both optimized (FPGA assisted) and non optimized traffic paths.
Disable_drop	Number of packets the SI dropped because they were sent by a client to a VIP port that is bound to a real server port that is currently disabled.
Exceed_drop	Number of packets dropped by the SI because the TCP SYN limit on the real servers had been reached. The TCP SYN limit is a configurable parameter that allows you to protect servers against TCP SYN attacks by limiting the number of TCP SYN requests the SI can send to the server each second. For more information, see "session-limit".
Stale_drop	Number of TCP SYN packets the SI dropped because they matched a stale session entry.
Unsuccessful	Number of packets that were dropped for one of the following reasons: A deny filter configured on the SI matched the packet, causing the SI to drop the packet. A client requested a TCP/UDP port that is not bound on the VIP.

clear server session

Use clear server session to clear all session table entries for a deleted real server.

Where <name> specifies the name of the real server. You can enter up to four real server names. It can take up to three minutes for the command to take effect. This command is supported only on the MP (the main processor management session).

When you delete a real server, the SI attempts to clear all the session entries for that real server from the session table. The SI requires all the sessions to be cleared from the table before performing these operations. If you use the force shutdown option (server force-delete command), the SI ends the sessions within one minute. Otherwise, the SI allows active sessions to end normally before removing them.

When you enter the command to delete a real server (no server real <name>), the SI changes the server's state to "await_delete". The real server remains in this state until all its sessions are cleared from the session table. Occasionally, the SI cannot clear all of a deleted real server's sessions from the table. When this occurs, the real server cannot be fully deleted. To complete deletion of the server in this case, enter the clear server session <name> command after entering the no server real <name> command.

The no server real command deletes real server "rs1". The show server real command displays the states of the real servers. Notice that rs1 is still listed as a valid real server, and has the state "await_delete". If the no server real command does not list the deleted server, the server has been completely deleted.

If the server continues to be listed with the "await_delete" state after several minutes, enter the clear server session command to finish deleting the server. The clear server session command deletes the remaining sessions for rs1, after which the SI can finish deleting the server. You can enter this command immediately after entering the no server real command. You do not need to wait for any sessions to end normally.

clear server tot-conn

Use clear server tot-conn {real | virtual} to clear the total connections counter ("Tot-Conn") in show commands for real and virtual servers. You can clear the counter for real servers only or virtual servers only.

SLB Configuration Examples

Web Hosting with One Virtual Server Mapped to Multiple Real Servers

Suppose a company establishes a web site with a URL of www.alterego.com. The company system administrator configures the networks so that the SLB switch forwards web requests among four independent servers, as shown in Figure 3.12.

Web Hosting with Multiple Virtual Servers Mapped to One Real Server

Suppose an ISP administrator wants to use one real server to accommodate three premium users, all of which are web sites. Each of these premium users is assigned its own web site URL:

As shown in Figure 3.13, the SLB switch forwards requests received for each of the three web sites to the real server(s) assigned to handle the traffic.

Many-To-One TCP/UDP Port Binding

Most SLB configurations for web hosting map one virtual IP address to multiple real servers. However, suppose an ISP wants to host one or multiple domain names on the same real server, using the same TCP/UDP port and use a different VIP for each site. Using a separate VIP for each web site eases administration and accounting by allowing the ISP to display statistics on the SI for each VIP address. In addition, you can create the appearance that you have many web servers even if you have only a few.

When you bind a port on a real server with a port on a virtual server together, the SI makes an entry in its internal Layer 4 binding table. The port on the real server cannot be bound again to another virtual server if the Layer 4 binding table already has a binding for that port. Thus, to map multiple VIPs to the same real server, normally you need to map each VIP to a different TCP/UDP port on the real server.

If you want to bind multiple VIPs to the same TCP/UDP port on the same real server for accounting reasons, you can do so by creating an alias for the port. When you create an alias, you configure the VIP to bind to a different port number on the real server, then disable port translation for that binding. The SI thus collects and presents information for the alias port number, but traffic from all the VIPs goes to the same TCP/UDP port number on the real server.

To map multiple virtual IP addresses to the same real server, disable HTTP port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias HTTP port. Disabling HTTP port translation enables the virtual IP addresses to use the same actual HTTP port number on the real server while the SI collects and displays separate statistics for the alias HTTP port number associated with each virtual IP address.

Configuration Rules

Use the following rules when configuring the SI to bind more than one virtual server to the same real server using the same application port:

You must configure both the real port and the alias port on the real server(s). For example, if you need to create alias port 180 so that you can bind two virtual servers to the same real server and application port (80) on a real server, you must configure port 80 and port 180 on the real server. Otherwise, you will not be able to completely bind all the virtual servers to the real server. In the example below, the following real server configurations are incomplete because neither of the real servers has both the untranslated and alias ports configured:

ServerIron(config)# server real-name r1 10.0.1.5 
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200 
ServerIron(config-rs-r2)# port 180
ServerIron(config-rs-r2)# exit

You cannot bind to both the untranslated port and the alias port in the same bind statement. In the example below, the following bind statement is invalid:

ServerIron

(config-vs-VIP1)# port http

ServerIron(config-vs-VIP1)# bind http r1 http r2 180

When you configure SLB, one of the tasks you perform is to bind the TCP or UDP application ports on the virtual server to their counterparts on the real server. For example, if clients will be sending requests to port 80 (HTTP) on virtual server www.mysite.com, but your real servers expect the HTTP connections to arrive on port 8080 of real server R1, then you must bind port 80 on the virtual server to port 8080 on the real server.

One of the requirements is that a real server can be bound to only one virtual server using the same TCP or UDP application port. Thus, once you bind a real server port to a virtual server port, you cannot bind the same real server port to a different virtual server port.

Normally, the SI translates the IP address and application port of the virtual server requested by the client into the real server IP address and application port that you bind to the virtual server. However, when you disable port translation, the SI does not perform the translation for the application port. Instead, the SI translates the destination IP address in the client's request to the IP address of a real server, but leaves the application port in the client's request untranslated.

CLI Example

ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# port 180
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# port 180
ServerIron(config-rs-r2)# exit
ServerIron(config)# server virtual-name VIP1 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 http r2 http
ServerIron(config-vs-VIP1)# exit
ServerIron(config)# server virtual-name VIP2 209.157.22.99
ServerIron(config-vs-VIP2)# port http
ServerIron(config-vs-VIP2)# no port http translate
ServerIron(config-vs-VIP2)# bind http r1 180 r2 180

The well-known port (80) is used for VIP1, but an alias (180) is used for VIP2. The real servers actually use port 80 for traffic to both virtual IP addresses. However, the alias port enables the ISP to distinguish among the two IP addresses and their traffic when they display SLB information on the SI. The no port http translate command is required. This command enables the SI to send traffic from multiple VIPs to the same real TCP/UDP port on the real server (in this example, "http" (port 80)). If you leave this command out, the SI does not use port 180 as an alias but instead sends the VIP traffic to TCP/UDP port 180 on the real server rather than 80.

To display statistics for the separate real IP addresses, enter the following command at any command prompt:

The lines highlighted in bold indicate the separate HTTP port numbers. The two HTTP lines for real server 1 (r1) indicate that an alias is in use. The first line lists the alias port number and the second line lists the actual port number used by the real server. Even though the same port number is used on the real server, the SI display distinguishes the traffic for the two virtual IP addresses.

Web Hosting with Unlimited Virtual IP Addresses

Many ISPs provide subscribers space on their web servers for home pages. Some ISPs provide the user spaces by creating subdirectories off the main domain name of the ISP. For example, an ISP with the domain name "www.budget-web.com" might create directories such as the following for individual subscribers:

Each subscriber's account is on the same IP address. A web user who accesses the server by entering the IP address gains access to the ISP's main page, but then must navigate to the individual subscriber's directory. For home subscribers, this method of web hosting is perfectly satisfactory. However, business subscribers sometimes prefer to have unique domain names.

ISPs that provide separate IP addresses and domain names to their subscribers often do so by configuring multiple IP addresses on their real servers. The real servers have Network Interface Cards (NICs) that support multiple IP addresses. To provide load balancing and redundancy, ISPs sometimes configure multiple real servers with the same contents, but of course with different IP addresses. The ISP configures a unique virtual IP address (VIP) for each subscriber and uses the SI to map the VIP to real IP addresses on each real server for the subscriber's web site.

In this type of application, individually configuring a VIP for each subscriber can require a lot of typing. However, the SI makes configuring multiple VIPs easy by allowing you to configure a range of VIPs. When you configure a range, you create a VIP with the lowest address in the range, then specify how many consecutive addresses are in the range. When the SI translates a VIP address configured as part of a host range into its corresponding real IP address on a real server, the SI uses the VIP's offset from the base address to determine the correct real address.

For example, suppose an ISP has two real servers with the following IP address ranges:

Instead of configuring 20 individual VIPs for these addresses, the ISP administrator can configure one VIP and a host range. In this example, the administrator configures the VIP 209.157.22.6 and adds a host range of 20 addresses to the VIP.

In the example in Figure 3.15, when the SI receives a request for VIP 209.157.22.6, the SI uses the predictor (balancing method) you configured to select one of the real servers, then selects the appropriate IP address on the server. In this case, since 209.157.22.6 is the first address in the VIP range, the SI sends the request to 10.0.1.6 on real server 1 or 10.0.2.101 on real server 2.

Suppose the SI receives a request for 209.157.22.8. The SI selects a real server, then applies the offset from the base VIP address to determine the corresponding real server address. In this example, 209.157.22.8 is two addresses higher than the base VIP address. Therefore, when the SI sends the request to a real server, the SI sends the request to a real IP address that is two addresses higher than the base address on the real server. The SI knows to apply the offset because the administrator specified a host range when configuring the virtual server and real servers. The IP address you specify when you configure the real server is the first address in the range.

To configure the SI or switch for this application, enter the following commands:

ServerIron(config)# server real-name r1 10.0.0.1
ServerIron(config-rs-r1)# host-range 20
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit

These commands configure information for the first real server. The host-range command specifies the range of IP addresses the virtual server will represent for the real server. (You do not need to specify the beginning and ending points in the range, just the number of hosts in the range. The IP address you specify for the real server is automatically the first IP address in the range.)

ServerIron(config)# server real-name r2 10.0.2.101
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# host-range 20
ServerIron(config-rs-r2)# exit

After you enter information for the real servers, you are ready to create the virtual server. The following commands create the virtual server.

ServerIron(config)# server virtual-name v1 209.157.22.6
ServerIron(config-vs-v1)# host-range 20
ServerIron(config-vs-v1)# port http
ServerIron(config-vs-v1)# bind http r1 http r2 http
ServerIron(config-vs-v1)# exit

The bind commands associate the http port on each real server with the http port on the virtual server.

SLB Intranet Configuration with HTTP, TELNET Hosting across Multiple Virtual Servers and Multiple Real Servers

A company establishes an Intranet that will handle three different URLs: www.support.com, www.marketing.com, and www.sales.com, as well as Telnet traffic. Telnet traffic is allocated among all four servers, and a server is dedicated to handle each URL with two servers allocated to handle www.support.com requests.

TCP/UDP Application Groups

Normally, when the SI selects a real server for a client's request for a TCP/UDP port, there is no guarantee that the SI will select the same real server for subsequent requests from the same client. In many situations, this does not present a problem. Even when the client is requesting the same web page or application, if the content or service is replicated on all the real servers, the client does not know or care which real server provides the content or service for each request.

However, some applications may require that the client continue to use the same real server. For example, an interactive web site might require successive client requests to come to the same server. Other applications might require that additional TCP/UDP applications also be on the same real server. Some applications may even require the ability to open concurrent connections on the client with different TCP/UDP ports dynamically assigned by the real server.

In all of these cases, the predictor (load-balancing metric) does not ensure that the client returns to the same real server. To accommodate these types of applications, you can configure ports on a virtual server to have the following attributes:

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 ages out inactive sticky server connections. Possible values are from 2 - 60 minutes. The default is 5 minutes. See "sticky-age" for information.

TCP/UDP application groups (using the track port function) - A "primary" TCP/UDP port is grouped 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.

TCP/UDP application groups (using the track group function) - Up to eight TCP/UDP ports are grouped together. After the SI sends a client request for any of the grouped ports to a real server, subsequent requests from the client for ports in the group go to the same real server.

NOTE:

NOTE: You must configure all the ports in a TCP/UDP application group to be "sticky".

Concurrent connections - The real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers.

NOTE:

NOTE: Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP/UDP ports that you configure on the virtual server. Concurrent connections enable the real server to arbitrarily determine the TCP/UDP ports and assign them to the client.

Figure 3.17 shows an example of servers configured with sticky ports and an application group. In this example, the content on each real server is identical. However, some applications on the server require that clients use the same server for subsequent requests to application. The virtual server is configured to make the ports sticky and to group the TFTP and Telnet ports under the HTTP port.

The following commands show how to implement an application group for this example:

ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# port tftp
ServerIron(config-rs-r1)# port telnet
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# port tftp
ServerIron(config-rs-r2)# port telnet
ServerIron(config-rs-r2)# exit

After you enter information for the real servers, you are ready to create the virtual server. The following commands create the virtual server. The sticky parameter makes the TCP/UDP ports sticky.

ServerIron(config)# server virtual-name v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit

The commands above illustrate the track port function. The track command groups the Telnet port (23) and the TFTP port (69) under the HTTP port (80); the HTTP port is established as the "primary" port. After the SI sends a client to a real server for the HTTP port, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to four ports can be grouped with the primary port.

The track group function works similarly to the track port function. With the track port function, the client uses the same server for applications associated with the grouped ports, as long as the primary port is active. In contrast, with the track group function, the client uses the same server for applications associated with the grouped ports, as long as all the ports in the group are active. After the SI sends a client to a real server for any of the grouped ports, subsequent requests from that client for any of the grouped ports go to the same real server.

The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the group.

Web Hosting with SI and Real Servers in Different Sub-Nets

The SI allows you to easily deploy its services in a multinetted environment, without the overhead of configuring routing protocols.

Normally, the SI requires only one IP address, which you use for management access to the device. However, when the SI and real servers are on different sub-nets, you need one of the following:

Figure 3.18 shows an example of a multinetted environment, in which the SI is on one sub-net but the real servers are on another sub-net. The SI is on sub-net 141.149.65.x and the real servers are on sub-net 10.10.10.x.

In this example, the SI and the real servers are on different sub-nets, but can communicate because the router is configured with interfaces in both sub-nets. Traffic from the SI to the real servers goes to the router, which routes the traffic to the real servers' sub-net. (The traffic passes back through the SI to reach the real servers, but still must be routed by the router.)

Traffic from the real servers to the SI passes through the SI to the router. The SI acts like a Layer 2 bridge in this case and thus passes the traffic to the router. The router then routes the traffic to the SI's sub-net.

If you have network topology similar to the example in Figure 3.18, but you do not want to configure the router with multiple sub-nets, you can instead enable source NAT and configure a source IP address on the SI. The source IP address allows the SI to be in multiple sub-nets, in addition to the sub-net of the SI's management IP address. Source NAT enables the SI to perform IP address translation on the source address in packets addressed to the real servers. When source NAT is enabled, the SI changes the source address in the IP packets addressed to the real server to the source IP address configured on the SI. Figure 3.19 shows an example of the topology shown in Figure 3.18, but in this case the SI is configured for multiple sub-nets instead of the router.

In this example, the SI is configured with source IP addresses in the real server's sub-net and source NAT is enabled. The configuration requires five CLI commands. No reconfiguration of the router is required.

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. You can configure up to eight source IP addresses, for even more simultaneous connections to the real servers.

ServerIron(config)# server source-ip 10.10.10.5 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.6 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.7 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.8 255.255.255.0 0.0.0.0
ServerIron(config)# server source-nat

ServerIron(config)# server real-name R1 10.10.10.2
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit

ServerIron(config)# server real-name R2 10.10.10.3
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# exit

ServerIron(config)# server virtual-name VIP 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http R1 http R2 http
ServerIron(config-vs-VIP1)# exit

Web Hosting with Geographically-Distributed Servers

The SI allows you to configure a virtual server to fail over to remote real server IP addresses or VIPs if all local servers become unavailable. The remote servers can be real servers, virtual servers, or a combination of real servers and virtual servers. The remote servers can be locally connected to the SI, connected across a router or even across the Internet.

When you configure remote servers in addition to local servers, the SI does not include the remote servers in the predictor (load balancing method). Thus, the remote servers are not used unless all local servers are unavailable.

Figure 3.20 shows an ISP that wants to use load sharing between two local real servers but use remote servers as failovers if both the local real servers are unavailable. The local servers are load balanced by the SI with IP management address 141.149.65.10. The remote servers are load balanced by the SI with IP management address 150.60.60.6. In this example, a VIP on the SI 2 (150.60.60.26) is configured on the SI 1 (141.149.65.10) as a remote server. The remote server can also be a real server's IP address.

When you configure a SI to fail over to a remote server or to a VIP on another SI, the remote server or VIP typically is on a different sub-net. In this case, the SI must perform some additional address translation to ensure that the traffic from the remote server to the client passes back through the SI that originally serviced the request.

When the SI sends a client request to a local server, it does not change the source IP address of the client's request. However, the SI does change the destination IP address from the VIP requested by the client to the IP address of a real server. When the real server replies to the request, the server's reply is addressed to the client. The SI changes the source IP address of the server's reply to the VIP, then forwards the reply to the client. When the client receives the reply, the reply appears to have come from the VIP.

For the configuration shown in Figure 3.20, you need to enable source NAT. When the SI sends a client request to a real server, the SI does not do source NAT by default. The SI simply performs a destination NAT, changing the VIP address to a real server address. When the real server replies, the SI reverses the destination NAT so that the client sees a reply from the VIP. Real server responses must flow through the SI that performed the original destination NAT so that the NAT can be reversed. Otherwise, the client sees a response from the wrong IP address and either resets the TCP connection or ignores the response.

If you use remote servers in a remote sub-net, you must enable source NAT to force traffic to return to the SI that performed the original destination NAT. The source IP addresses used for source NAT must be in the original SI's broadcast domain. The remote real server replies are addressed to the original SI, not to the client's address. The original SI can then properly reverse the destination NAT.

In Figure 3.20, client requests initially are addressed to VIP1 on SI 1, 141.149.65.2. If the local real servers are healthy, SI 1 distributes traffic to them using destination NAT in the normal way. However, if all the local real servers become unavailable, SI 1 sends traffic to VIP2 on SI 2. SI 1 sends the traffic by using destination NAT in the usual way, translating VIP1's address into VIP2's address. The client's packet is forwarded to the SI's default gateway. By default, if source NAT is not enabled, this is all that happens.

If source NAT is disabled, SI 2 performs a second destination NAT, replacing VIP2's address with R3 or R4's address, depending on which real server is next in the rotation. For this example, assume that SI 2 sends the client request to R3. When R3 replies, the destination address is the client's address and R3's address is replaced by VIP2's address. R3's default gateway forwards this packet directly to the client. SI 1 never sees the packet and never has a chance to reverse the original destination NAT. The client sees a response from 150.60.60.26, rather than 141.149.65.2. The client therefore either resets the TCP connection or simply ignores the response.

To avoid this problem, enable source NAT on SI 1 for VIP2, the remote server. In the example in Figure 3.20, SI 1 has four addresses to use with source NAT:

When SI 1 sends a packet to VIP2, SI 1 also performs a source NAT using one of these four addresses. The remote servers reply to an address on SI 1 rather than to the client's address. Traffic returns to SI 1 where the original destination NAT is reversed. The client sees a response from VIP1, the same address to which the client sent its request.

All of this is transparent to the client, who simply sends a request to a published IP address and receives a response from that address.

Here are the commands for implementing the configuration shown in Figure 3.20. This configuration and all the other configuration information shown here is from the perspective of SI 1. You of course also can configure the remote SI to use a VIP on the local SI as a remote failover.

ServerIron-1(config)# server real-name R1 10.10.10.2
ServerIron-1(config-rs-R1)# port http
ServerIron-1(config-rs-R1)# exit

ServerIron-1(config)# server real-name R2 10.10.10.3
ServerIron-1(config-rs-R2)# port http
ServerIron-1(config-rs-R2)# exit

The commands shown above configure the local servers. The following commands configure the remote server and enable source NAT for the server. In this example, the remote server is VIP2 configured on SI 2. It is also valid to configure real servers R3 and R4 as the remote servers instead. However, by configuring VIP2 as the remote server, you simplify configuration and also take advantage of the SLB services of SI 2. This example assumes that real servers R3 and R4 and VIP2 are configured on SI 2.

ServerIron-1(config)# server remote-name VIP2 150.60.60.26
ServerIron-1(config-rs-VIP2)# source-nat
ServerIron-1(config-rs-VIP2)# port http
ServerIron-1(config-rs-VIP2)# exit

ServerIron-1(config)# server virtual-name VIP1 141.149.65.2
ServerIron-1(config-vs-VIP1)# port http
ServerIron-1(config-vs-VIP1)# bind http R1 http R2 http VIP2 http
ServerIron-1(config-vs-VIP1)# exit

The following source-ip commands configure source IP addresses to allow the SI to send a client request to a remote server, receive the response, and then send the response to the client. Notice that the source IP addresses added to the SI are not in the sub-net of the remote SI. They are in the sub-net that connects the SI's local router to the Internet. The purpose of the source IP addresses in this configuration is to ensure that the responses from remote servers come back to the SI instead of going directly to the clients, so that the SI can properly change the source addresses of the responses back to the VIP requested by the clients.

ServerIron-1(config)# server source-ip 141.149.65.4 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.5 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.6 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.7 255.255.255.0 0.0.0.0

You can implement this type of configuration using just one source IP address. However, an architectural limitation in IP allows a maximum of 64,000 simultaneous connections on an IP address. As a result, to maximize the number of simultaneous connections the SI can have to the remote VIP, add the maximum number of source IP addresses (eight).

Using HTTP Redirect with Geographically-Distributed Servers

The application example in the previous section illustrates how to configure the SI to fail over to a remote real server if all local real servers are unavailable. In the previous example, the source NAT feature is used to cause traffic from the remote real server to flow back through the SI to the client.

Depending on the speed of the network connections between the SI and the remote server, you might want the remote server to instead communicate directly with the client. To do so, you can configure a VIP to use HTTP redirect.

Normally, a client expects a response from the VIP and thus regards a TCP SYN ACK (acknowledgment) from the real server as a connection attempt from a different server. If the real server responds directly to the client, the client refuses the real server's TCP SYN ACK. However, you can configure a VIP to use HTTP redirect. In this case, the SI performs address translation as normal when using local real servers. However, if all of the local real servers are unavailable and a remote server is available, the SI sends an HTTP redirect message to the client. The HTTP redirect message instructs the client to redirect its HTTP connection directly to the remote server, bypassing the SI. The client now is talking to the remote server's IP address instead of the VIP.

Here are the commands for implementing HTTP redirect for the VIP shown in Figure 3.21. The command that enables HTTP redirect is shown in bold.

ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit

ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# exit

ServerIron(config)# server remote-name r3 192.157.22.244
ServerIron(config-rs-r3)# source-nat
ServerIron(config-rs-r3)# port http
ServerIron(config-rs-r3)# exit

ServerIron(config)# server virtual-name VIP 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80
ServerIron(config-vs-VIP1)# httpredirect
ServerIron(config-vs-VIP1)# exit

Using Reverse Proxy SLB

The Reverse Proxy SLB feature enables you to send client requests for a web page first to a cache server, then to a load balanced real server if the cache server does not have the requested content. This feature is useful for enhancing performance within a load balanced web site for frequently requested web pages.

To configure the SI for Reverse Proxy SLB, you configure the real servers and a VIP, then enable Reverse Proxy SLB on the VIP. When the SI receives a request for the VIP, the SI sends the request to a cache server.

The SI uses the TCS hash mechanism when selecting a cache server and uses the SLB load balancing method (the predictor) when selecting a real server.

Basic Example

Figure 3.22 shows an example of a simple Reverse Proxy SLB configuration. Notice that the cache servers and real servers are located close to the web content, as opposed to being located close to the client (or the client's ISP), which is usually the case. Because the cache servers are located close to the content, this type of configuration is sometimes called "reverse caching" or "reverse proxy". The SI is a proxy acting on behalf of the client, but the proxy is located with the web content, rather than with the client's ISP.

In this example, the SI is configured to send client requests for VIP 209.157.22.26 to a cache server (C1 or C2). If the cache server does not have the requested content, the SI does not send the request to the Internet, as it does in a standard TCS configuration. Instead, the SI sends the request to a load balanced real server.

ServerIron(config)# ip policy 1 cache tcp 80 global
ServerIron(config)# server cache-name C1 10.0.1.2
ServerIron(config)# server cache-name C2 10.0.1.3
ServerIron(config)# server cache-group 1
ServerIron(config-tc-1)# cache-name C1
ServerIron(config-tc-1)# cache-name C2
ServerIron(config-tc-1)# exit

The following commands configure the real servers. Notice that port 80 (HTTP) is added to each server.

ServerIron(config)# server real-name R1 10.0.1.4
ServerIron(config-rs-R1)# port 80
ServerIron(config-rs-R1)# exit

ServerIron(config)# server real-name R2 10.0.1.5
ServerIron(config-rs-R2)# port 80
ServerIron(config-rs-R2)# exit

ServerIron(config)# server real-name R3 10.0.1.6
ServerIron(config-rs-R3)# port 80
ServerIron(config-rs-R3)# exit

The following commands configure the VIP and save the configuration to the SI's startup-config file on the flash memory. The cache-enable command enables the Reverse Proxy SLB feature. You must use this command to use Reverse Proxy SLB. Otherwise, the SI will use the standard TCS behavior, and send client requests to the Internet if the cache server does not have the requested content. The cache-enable command configures the SI to send requests that the cache servers cannot fulfill to the real servers instead of to the Internet.

ServerIron(config)# server virtual-name VIP1 209.157.22.26
ServerIron(config-vs-VIP1)# port 80
ServerIron(config-vs-VIP1)# bind 80 R1 80 R2 80 R3 80
ServerIron(config-vs-VIP1)# cache-enable
ServerIron(config)# write memory

E-Commerce Example

You can use Reverse Proxy SLB in an E-Commerce environment to offer information that is located on a corporate intranet to the general public without compromising network security. Figure 3.23 shows an example of a Reverse Proxy SLB configuration. Notice that this configuration uses multiple SIs. One of the SIs is configured for TCS and Reverse Proxy SLB while the other two are configured for SLB.

In this example, the cache servers are located in the demilitarized zone (DMZ) of a company. The DMZ is the part of the company's network that is outside the company firewalls but still on the private side of the company's router connection to the Internet.

When a client request comes in from the Internet addressed to VIP 192.1.1.1 on a SI with Reverse Proxy SLB enabled, the SI redirects the request to a cache server. If the cache server has the requested content, the cache server responds directly to the client (through the SI). If the cache server does not have the requested content, the cache server redirects the request to the SI.

Normally, a SI configured for TCS redirects a cache request to the Internet. However, since Reverse Proxy SLB is enabled, the SI instead sends the request to a load balanced real server. In this example, the real servers are firewalls acting as proxy servers. The TCS SI is configured with two real servers. Each of them is actually a firewall. Each of the firewalls is configured to perform NAT to translate packets addressed to its interface with the SI into the VIP configured on the SLB SI connected to it. Thus, if the TCS SI sends a client request to firewall interface 192.1.1.5 (configured on the TCS SI as a real server), the firewall translates the packet's destination address into VIP 10.10.2.20.

The SI to which the firewall (proxy server) sends the client request sends the request to a real server, then sends the response back to the firewall, which again performs NAT and sends the response to the cache server. The cache server then sends the requested content to the client. From the client's perspective, the response arrives from IP address 192.1.1.1. This is true whether the content was on the cache server when the client requested it or the cache server needed to obtain the content from a real server before providing it to the client.

Commands on TCS SI

The following commands configure the TCS SI. Notice that two real servers are added to the SI. These real servers are actually the firewalls. The real server IP addresses are the firewall interfaces with the TCS SI. Also notice that the ports on the VIP are bound to the real servers, as in a standard TCS configuration.

ServerIron(config)# ip policy 1 cache tcp 80 global
ServerIron(config)# server cache-name C1 192.1.1.2
ServerIron(config)# server cache-name C2 192.1.1.3

ServerIron(config)# server cache-group 1
ServerIron(config-tc-1)# cache-name C1
ServerIron(config-tc-1)# cache-name C2
ServerIron(config-tc-1)# exit

ServerIron(config)# server real-name Proxy1 192.1.1.5
ServerIron(config-rs-Proxy1)# port 80
ServerIron(config-rs-Proxy1)# port 443
ServerIron(config-rs-Proxy1)# exit

ServerIron(config)# server real-name Proxy2 192.1.1.4
ServerIron(config-rs-Proxy2)# port 80
ServerIron(config-rs-Proxy2)# port 443
ServerIron(config-rs-Proxy2)# exit

ServerIron(config)# server virtual-name VIP1 192.1.1.1
ServerIron(config-vs-VIP1)# port 80
ServerIron(config-vs-VIP1)# port 443
ServerIron(config-vs-VIP1)# bind 80 Proxy1 80 Proxy2 80
ServerIron(config-vs-VIP1)# bind 443 Proxy1 443 Proxy2 443
ServerIron(config-vs-VIP1)# cache-enable
ServerIron(config-vs-VIP1)# exit
ServerIron(config)# write memory

Commands on SLB SI A

ServerIron(config)# server real-name R1 10.10.2.1
ServerIron(config-rs-R1)# port 80
ServerIron(config-rs-R1)# port 443
ServerIron(config-rs-R1)# exit

ServerIron(config)# server real-name R2 10.10.2.2
ServerIron(config-rs-R2)# port 80
ServerIron(config-rs-R2)# port 443
ServerIron(config-rs-R2)# exit

ServerIron(config)# server virtual-name VIP2 10.10.2.20
ServerIron(config-vs-VIP2)# port 80
ServerIron(config-vs-VIP2)# port 443
ServerIron(config-vs-VIP2)# bind 80 R1 80 R2 80
ServerIron(config-vs-VIP2)# bind 443 R1 443 R2 443
ServerIron(config-vs-VIP2)# exit
ServerIron(config)# write memory

Commands on SLB SI B

ServerIron(config)# server real-name R3 10.10.3.1
ServerIron(config-rs-R3)# port 80
ServerIron(config-rs-R3)# port 443
ServerIron(config-rs-R3)# exit

ServerIron(config)# server real-name R4 10.10.3.2
ServerIron(config-rs-R4)# port 80
ServerIron(config-rs-R4)# port 443
ServerIron(config-rs-R4)# exit

ServerIron(config)# server virtual-name VIP3 10.10.3.21
ServerIron(config-vs-VIP2)# port 80
ServerIron(config-vs-VIP2)# port 443
ServerIron(config-vs-VIP2)# bind 80 R3 80 R4 80
ServerIron(config-vs-VIP2)# bind 443 R3 443 R4 443
ServerIron(config-vs-VIP2)# exit
ServerIron(config)# write memory

Load Balancing Streaming Media Files

The SI can perform load balancing for the following kinds of streaming media files:

Figure 3.24 shows a sample configuration where requests for three kinds of streaming media files are load balanced across three real servers.

In this configuration, all the streaming media content is located on the three real servers. Requests for MS-media files on VIP 192.162.1.50 are load balanced across the real servers using the weighted predictor; requests for Real Audio files on VIP 192.162.1.51 are load balanced using the least connections predictor; and requests for QuickTime files on VIP 192.162.1.52 are load balanced using the round-robin predictor.

ServerIron(config)# server real-name rs1 10.10.10.1
ServerIron(config-rs-rs1)# port rtsp
ServerIron(config-rs-rs1)# port pnm
ServerIron(config-rs-rs1)# port mms
ServerIron(config-rs-rs1)# exit

ServerIron(config)# server real-name rs2 10.10.10.2
ServerIron(config-rs-rs2)# port rtsp
ServerIron(config-rs-rs2)# port pnm
ServerIron(config-rs-rs2)# port mms
ServerIron(config-rs-rs2)# exit

ServerIron(config)# server real-name rs3 10.10.10.3
ServerIron(config-rs-rs3)# port rtsp
ServerIron(config-rs-rs3)# port pnm
ServerIron(config-rs-rs3)# port mms
ServerIron(config-rs-rs3)# exit

The following commands bind the real servers to the virtual servers in Figure 3.24.

ServerIron(config)# server virtual-name MSmedia1755 192.162.1.50
ServerIron(config-vs-MSmedia1755)# predictor weighted
ServerIron(config-vs-MSmedia1755)# port mms
ServerIron(config-vs-MSmedia1755)# bind mms rs1 mms rs2 mms rs3 mms
ServerIron(config-vs-MSmedia1755)# exit

ServerIron(config)# server virtual-name real7070 192.162.1.51
ServerIron(config-vs-real7070)# predictor least-conn
ServerIron(config-vs-real7070)# port pnm
ServerIron(config-vs-real7070)# bind pnm rs1 pnm rs2 pnm rs3 pnm
ServerIron(config-vs-real7070)# exit

ServerIron(config)# server virtual-name quicktime554 192.162.1.52
ServerIron(config-vs-quicktime554)# predictor round-robin
ServerIron(config-vs-quicktime554)# port rtsp
ServerIron(config-vs-quicktime554)# bind rtsp rs1 rtsp rs2 rtsp rs3 rtsp
ServerIron(config-vs-quicktime554)# exit