Downloads |
Table Of Contents
Overview of the IOS SLB Feature
Algorithms for Server Load Balancing
Audio and Video Load Balancing
Automatic Server Failure Detection
Avoiding Attacks on Server Farms and Firewall Farms
Client-Assigned Load Balancing
Delayed Removal of TCP Connection Context
Dynamic Feedback Protocol for IOS SLB
Multiple Firewall Farm Support
Network Address Translation (NAT)
Probes in Server Load Balancing
Probes in Firewall Load Balancing
Transparent Webcache Load Balancing
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring Required and Optional IOS SLB Functions
Configuring a Server Farm and Real Server
Verifying IOS SLB Connectivity
Configuring Firewall Load Balancing
Verifying Firewall Connectivity
GPRS Load Balancing Configuration Task List
RADIUS Load Balancing Configuration Task List
Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing
VPN Server Load Balancing Configuration Task List
Stateless Backup Configuration Task List
Verifying the Stateless Backup Configuration
Configuring Buffers for the Fragment Database
Clearing Databases and Counters
Purging and Reassigning Connections
Monitoring and Maintaining the IOS SLB Feature
Basic IOS SLB Network Configuration Example
Restricted Client Configuration
Complete IOS SLB Configuration Example
IOS SLB with Firewall Load Balancing Example
Internal Firewall Load-Balancing Device
External Firewall Load-Balancing Device
IOS SLB with Server Load Balancing and Firewall Load Balancing Example
Internal Server and Firewall Load-Balancing Device
External Firewall Load-Balancing Device
IOS SLB with Multiple Firewall Farms Example
Internal Firewall Load-Balancing Device
External Firewall Load-Balancing Device
IOS SLB with Routed Probe Example
Layer 3 Switch Configured with IOS SLB Example
Switch A Configuration Statements
Switch B Configuration Statements
Switch C Configuration Statements
IOS SLB with Static NAT Example
IOS SLB with Stateless Backup Examples
Dynamic Routing and Trunking Example
Dynamic Routing and No Trunking Example
Static Routing and Trunking Example
Static Routing and No Trunking Example
IOS SLB with Stateful Backup Example
Switch SLB1 Configuration Statements
Switch SLB2 Configuration Statements
IOS SLB with Active Standby Example
SLB 1 Configuration Statements
SLB 2 Configuration Statements
Access Router Configuration Statements
IOS SLB with Redistribution of Static Routes Example
Routing Information Protocol (RIP)
Open Shortest Path First (OSPF)
Interior Gateway Routing Protocol (IGRP)
Enhanced Interior Gateway Routing Protocol (Enhanced IGRP)
IOS SLB with WAP and UDP Load Balancing Examples
IOS SLB with Route Health Injection Examples
Example with Two Distributed Sites with One Web Server Each
Example with Two Distributed Sites with Two Web Servers Each
Example with Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each
IOS SLB with GPRS Load Balancing Example
IOS SLB Configuration Statements
GGSN1 Configuration Statements
GGSN2 Configuration Statements
GGSN3 Configuration Statements
IOS SLB with GPRS Load Balancing and NAT Example
IOS SLB Configuration Statements
GGSN1 Configuration Statements
GGSN2 Configuration Statements
GGSN3 Configuration Statements
IOS SLB with VPN Server Load Balancing Example
IOS SLB with RADIUS Load Balancing for a GPRS Network Example
IOS SLB with RADIUS Load Balancing for a Simple IP CDMA2000 Network Example
IOS SLB with RADIUS Load Balancing for a Mobile IP CDMA2000 Network Example
IOS SLB with RADIUS Load Balancing for Multiple Service Gateway Farms Example
IOS SLB with Sticky Connections Example
IOS SLB with Transparent Webcache Load Balancing
clear ip slb sticky radius framed-ip
delay (firewall farm TCP protocol)
idle (firewall farm TCP protocol)
idle (firewall farm datagram protocol)
inservice (firewall farm real server)
inservice (server farm real server)
inservice (server farm virtual server)
maxconns (firewall farm TCP protocol)
maxconns (firewall farm datagram protocol)
predictor hash address (firewall farm)
probe (firewall farm real server)
purge radius framed-ip acct on-off (virtual server)
replicate casa (firewall farm)
replicate casa (virtual server)
sticky (firewall farm TCP protocol)
sticky (firewall farm datagram protocol)
weight (firewall farm real server)
FAQ (Frequently Asked Questions)
IOS Server Load Balancing
Feature History
12.0(7)XE
This feature was introduced with support for the following platforms:
•
Multilayer Switch Feature Card (MSFC) and Supervisor Engine 1 for Cisco Catalyst 6500 family switches (including the Catalyst 6506, Catalyst 6509, and Catalyst 6513)
•
The following functions were provided:
•
•
•
•
•
12.1(1)E
The following functions were added:
•
•
12.1(2)E
The following functions were added:
•
•
•
•
12.1(3a)E
The following functions were added:
•
•
12.1(5a)E
The following functions were added:
•
•
12.1(5)T
The Cisco IOS Release 12.1(1)E feature was integrated into Cisco IOS Release 12.1(5)T, supporting Cisco 7200 Series Routers only.
12.2
The Cisco IOS Release 12.1(5)T feature was integrated into Cisco IOS Release 12.2.
12.1(7)E
Support for the following platform was added:
•
The following functions were added:
•
12.1(8a)E
Support for the following platform was added:
•
The following functions were added:
12.1(9)E
The following functions were added:
12.1(11b)E
Support for the following platform was added:
•
The following functions were added:
•
•
•
12.1(12c)E
The following functions were added:
•
•
This document describes the Cisco IOS Server Load Balancing (SLB) feature in Cisco IOS Release 12.1(12c)E. It includes the following sections:
•
•
•
•
•
Overview of the IOS SLB Feature
The IOS SLB feature is an IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, you can define a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. In this environment, the clients connect to the IP address of the virtual server. When a client initiates a connection to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured load-balancing algorithm.
Note
IOS SLB also provides firewall load balancing, which balances flows across a group of firewalls called a firewall farm.
Figure 1 illustrates a logical view of a simple IOS SLB network.
Figure 1 Logical View of IOS SLB
Functions and Capabilities
This section describes the following functions and capabilities provided by IOS SLB.
Note
•
•
•
•
•
•
•
•
•
•
Algorithms for Server Load Balancing
IOS SLB provides the following load-balancing algorithms:
You can specify one of these algorithms as the basis for choosing a real server for each new connection request that arrives at the virtual server.
Weighted Round Robin
The weighted round robin algorithm specifies that the real server used for a new connection to the virtual server is chosen from the server farm in a circular fashion. Each real server is assigned a weight, n, that represents its capacity to handle connections, as compared to the other real servers associated with the virtual server. That is, new connections are assigned to a given real server n times before the next real server in the server farm is chosen.
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. The first three connections to the virtual server are assigned to ServerA, the fourth connection to ServerB, and the fifth and sixth connections to ServerC.
Note
GPRS load balancing requires the weighted round robin algorithm. A server farm that uses weighted least connections can be bound to a virtual server providing GPRS load balancing, but you cannot place the virtual server INSERVICE. If you try to do so, IOS SLB issues an error message.
Weighted Least Connections
The weighted least connections algorithm specifies that the next real server chosen from a server farm for a new connection to the virtual server is the server with the fewest active connections. Each real server is assigned a weight for this algorithm, also. When weights are assigned, the server with the fewest connections is based on the number of active connections on each server, and on the relative capacity of each server. The capacity of a given real server is calculated as the assigned weight of that server divided by the sum of the assigned weights of all of the real servers associated with that virtual server, or n1/(n1+n2+n3...).
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. ServerA would have a calculated capacity of 3/(3+1+2), or half of all active connections on the virtual server, ServerB one-sixth of all active connections, and ServerC one-third of all active connections. At any point in time, the next connection to the virtual server would be assigned to the real server whose number of active connections is farthest below its calculated capacity.
Note
GPRS load balancing does not support the weighted least connections algorithm.
Alternate IP Addresses
IOS SLB enables you to telnet to the load-balancing device using an alternate IP address. To do so, use either of the following methods:
•
•
This function is similar to that provided by the LocalDirector (LD) Alias command.
Audio and Video Load Balancing
IOS SLB can balance RealAudio and RealVideo streams via Real-Time Streaming Protocol (RTSP), for servers running RealNetworks applications.
Automatic Server Failure Detection
IOS SLB automatically detects each failed Transmission Control Protocol (TCP) connection attempt to a real server, and increments a failure counter for that server. (The failure counter is not incremented if a failed TCP connection from the same client has already been counted.) If a server's failure counter exceeds a configurable failure threshold, the server is considered out of service and is removed from the list of active real servers.
Automatic Unfail
When a real server fails and is removed from the list of active servers, it is assigned no new connections for a length of time specified by a configurable retry timer. After that timer expires, the server is again eligible for new virtual server connections and IOS SLB sends the server the next qualifying connection. If the connection is successful, the failed server is placed back on the list of active real servers. If the connection is unsuccessful, the server remains out of service and the retry timer is reset.
Avoiding Attacks on Server Farms and Firewall Farms
IOS SLB relies on a site's firewalls to protect the site from attacks. In general, IOS SLB is no more susceptible to direct attack than is any switch or router. However, a highly secure site can take the following steps to enhance its security:
•
•
•
•
Backup Server Farms
A backup server farm is a server farm that can be used when none of the real servers defined in a primary server farm is available to accept new connections. When configuring backup server farms, keep in mind the following considerations:
•
•
•
Bind ID Support
The bind ID allows a single physical server to be bound to multiple virtual servers and report a different weight for each one. Thus, the single real server is represented as multiple instances of itself, each having a different bind ID. DFP uses the bind ID to identify for which instance of the real server a given weight is specified. The bind ID is needed only if you are using DFP.
GPRS load balancing does not support bind IDs.
Client-Assigned Load Balancing
Client-assigned load balancing allows you to limit access to a virtual server by specifying the list of client IP subnets that are permitted to use that virtual server. With this feature, you can assign a set of client IP subnets (such as internal subnets) connecting to a virtual IP address to one server farm or firewall farm, and assign another set of clients (such as external clients) to a different server farm or firewall farm.
GPRS load balancing does not support client-assigned load balancing.
Content Flow Monitor Support
IOS SLB supports the Cisco Content Flow Monitor (CFM), a web-based status monitoring application within the CiscoWorks2000 product family. You can use CFM to manage Cisco server load-balancing devices. CFM runs on Windows NT and Solaris workstations, and is accessed using a web browser.
Delayed Removal of TCP Connection Context
Because of IP packet ordering anomalies, IOS SLB might "see" the termination of a TCP connection (a finish [FIN] or reset [RST]) followed by other packets for the connection. This problem usually occurs when there are multiple paths that the TCP connection packets can follow. To correctly redirect the packets that arrive after the connection is terminated, IOS SLB retains the TCP connection information, or context, for a specified length of time. The length of time the context is retained after the connection is terminated is controlled by a configurable delay timer.
DFP Agent Subsystem Support
IOS SLB supports the DFP Agent Subsystem feature, also called global load balancing, which enables client subsystems other than IOS SLB to act as DFP agents. With the DFP Agent Subsystem, you can use multiple DFP agents from different client subsystems at the same time.
For more information about the DFP Agent Subsystem, see the DFP Agent Subsystem feature module.
Dynamic Feedback Protocol for IOS SLB
With IOS SLB Dynamic Feedback Protocol (DFP) support, a DFP manager in a load-balancing environment can initiate a TCP connection with a DFP agent. Thereafter, the DFP agent collects status information from one or more real host servers, converts the information to relative weights, and reports the weights to the DFP manager. The DFP manager factors in the weights when load balancing the real servers. In addition to reporting at user-defined intervals, the DFP agent sends an early report if there is a sudden change in a real server's status.
The weights calculated by DFP override the static weights you define using the weight (server farm) command. If DFP is removed from the network, IOS SLB reverts to the static weights.
You can define IOS SLB as a DFP manager, as a DFP agent for another DFP manager, or as both at the same time. In such a configuration, IOS SLB sends periodic reports to the other DFP manager, which uses the information to choose the best server farm for each new connection request. IOS SLB then uses the same information to choose the best real server within the chosen server farm.
DFP also supports the use of multiple DFP agents from different client subsystems (such as IOS SLB and GPRS) at the same time.
In GPRS load balancing, you can define IOS SLB as a DFP manager and define a DFP agent on each GGSN in the server farm, and the DFP agent can report the weights of the GGSNs. The DFP agents calculate the weight of each GGSN based on CPU utilization, processor memory, and the maximum number of PDP contexts (mobile sessions) that can be activated for each GGSN. As a first approximation, DFP calculates the weight as the number of existing PDP contexts divided by the maximum allowed PDP contexts:
(existing PDP contexts)/(maximum PDP contexts)
Maximum PDP contexts are specified using the gprs maximum-pdp-context-allowed command, which defaults to 10,000 PDP contexts. If you accept the default value, DFP might calculate a very low weight for the GGSN:
(existing PDP contexts)/10000 = Low GGSN weight
Keep this calculation in mind when specifying maximum PDP contexts using the gprs maximum-pdp-context-allowed command.
Firewall Load Balancing
As its name implies, firewall load balancing enables IOS SLB to balance flows to firewalls. Firewall load balancing uses a load-balancing device on each side of a group of firewalls (called a firewall farm) to ensure that the traffic for each flow travels to the same firewall, ensuring that the security policy is not compromised.
You can configure more than one firewall farm in each load-balancing device.
Layer 3 firewalls, which have IP-addressable interfaces, are supported by IOS SLB firewall load balancing if they are subnet-adjacent to the firewall load-balancing device and have unique MAC addresses. The device does not modify the IP addresses in the user packet. To send the packet to the chosen firewall, the device determines which interface to use and changes the Layer 2 headers accordingly. This is the standard dispatched routing used by IOS SLB.
Layer 2 firewalls, which do not have IP addresses, are transparent to IOS SLB firewall load balancing. IOS SLB supports Layer 2 firewalls by placing them between two IP-addressable interfaces.
Whereas many Layer 3 firewalls might exist off a single Layer 3 interface on the load-balancing device (for example, a single LAN), only one Layer 2 firewall can exist off each interface.
When configuring the load-balancing device, you configure a Layer 3 firewall using its IP address, and a Layer 2 firewall using the IP address of the interface of the device on the "other side" of the firewall.
To balance flows across the firewalls in a firewall farm, IOS SLB firewall load balancing performs a route lookup on each incoming flow, examining the source and destination IP addresses (and optionally the source and destination TCP or User Datagram Protocol [UDP] port numbers). Firewall load balancing applies a hash algorithm to the results of the route lookup and selects the best firewall to handle the connection request.
Note
To maximize availability and resilience in a network with multiple firewalls, configure a separate equal-weight route to each firewall, rather than a single route to only one of the firewalls.
IOS SLB firewall load balancing provides the following capabilities:
•
•
•
•
•
•
•
GPRS Load Balancing
General Packet Radio Service (GPRS) is the packet network infrastructure based on the European Telecommunications Standards Institute (ETSI) Global System for Mobile Communication (GSM) phase 2+ standards for transferring packet data from the GSM mobile user to the packet data network (PDN). The Cisco gateway GPRS support node (GGSN) interfaces with the serving GPRS support node (SGSN) using the GPRS Tunneling Protocol (GTP), which in turn uses UDP/IP for transport. IOS SLB provides GPRS load balancing and increased reliability and availability for the GGSN.
Tunnel creation messages destined to the virtual GGSN IP address are delivered to one of the real GGSNs using the weighted round robin load-balancing algorithm. See the "Weighted Round Robin" section for more information about this algorithm.
GPRS load balancing can operate in dispatched mode or in server NAT mode, but not in client NAT mode. In dispatched mode, the GGSNs must be Layer 2-adjacent to the IOS SLB device.
When configuring the network shared by IOS SLB and the GGSNs, keep the following considerations in mind:
•
•
–
–
Maximum Connections
IOS SLB allows you to configure maximum connections for server and firewall load balancing.
•
•
Multiple Firewall Farm Support
You can configure more than one firewall farm in each load-balancing device.
Network Address Translation (NAT)
Cisco IOS NAT, RFC 1631, allows unregistered "private" IP addresses to connect to the Internet by translating them into globally registered IP addresses. As part of this functionality, Cisco IOS NAT can be configured to advertise only one address for the entire network to the outside world. This provides additional security and network privacy, effectively hiding the entire internal network from the world behind that address. NAT has the dual functionality of security and address conservation, and is typically implemented in remote access environments.
This section includes information about the following topics:
•
Session Redirection
Session redirection involves redirecting packets to real servers. IOS SLB can operate in one of two session redirection modes, dispatched mode or directed mode.
Note
Dispatched Mode
In dispatched mode, the virtual server address is known to the real servers; you must configure the virtual server IP address as a loopback address, or secondary IP address, on each of the real servers. IOS SLB redirects packets to the real servers at the media access control (MAC) layer. Since the virtual server IP address is not modified in dispatched mode, the real servers must be Layer 2-adjacent to IOS SLB, or intervening routers might not be able to route to the chosen real server.
For Catalyst 6500 Family Switches, dispatched mode with hardware data packet acceleration generally yields better performance than directed mode.
See the "Configuring Logical Interfaces" chapter of the Cisco IOS Interface Configuration Guide for more information about configuring the loopback address.
Directed Mode
In directed mode, the virtual server can be assigned an IP address that is not known to any of the real servers. IOS SLB translates packets exchanged between a client and a real server, using NAT to translate the virtual server IP address to a real server IP address.
IOS SLB supports the following types of NAT:
•
Note
IOS SLB does not support FTP, firewall load balancing, and GPRS load balancing in directed mode. Therefore, FTP, firewall load balancing, and GPRS load balancing cannot use NAT.
IOS SLB supports only client NAT for TCP and UDP virtual servers.
IOS SLB supports only server NAT (but not server port translation) for Encapsulation Security Payload (ESP) virtual servers or generic routing encapsulation (GRE) virtual servers.
Server NAT
Server NAT involves replacing the virtual server IP address with the real server IP address (and vice versa). Server NAT provides the following benefits:
•
•
•
•
•
Client NAT
If you use more than one load-balancing device in your network, replacing the client IP address with an IP address associated with one of the devices results in proper routing of outbound flows to the correct device. Client NAT also requires that the ephemeral client port be modified since many clients can use the same ephemeral port. Even in cases where multiple load-balancing devices are not used, client NAT can be useful to ensure that packets from load-balanced connections are not routed around the device.
Static NAT
With static NAT, address translations exist in the NAT translation table as soon as you configure static NAT commands, and they remain in the translation table until you delete the static NAT commands.
You can use static NAT to allow some users to utilize NAT and allow other users on the same Ethernet interface to continue with their own IP addresses. This enables you to provide a default NAT behavior for real servers, differentiating between responses from a real server, and connection requests initiated by the real server.
For example, you can use server NAT to redirect DNS inbound request packets and outbound response packets for a real server, and static NAT to process connection requests from that real server.
Note
IOS SLB supports the following static NAT options, configured using the ip slb static command:
•
•
•
•
–
–
IOS SLB uses the following logic when handling a packet from a real server:
Step 1
•
•
Step 2
•
•
Step 3
•
•
Step 4
•
•
Step 5
•
•
Step 6
•
•
Step 7
•
•
Server Port Translation
Server port translation, also known as port address translation, or PAT, is a form of server NAT that involves the translation of virtual server ports instead of virtual server IP addresses. Virtual server port translation does not require translation of the virtual server IP address, but you can use the two types of translation together.
IOS SLB supports server port translation for TCP and UDP only.
Port-Bound Servers
When you define a virtual server, you must specify the TCP or UDP port handled by that virtual server. However, if you configure NAT on the server farm, you can also configure port-bound servers. Port-bound servers allow one virtual server IP address to represent one set of real servers for one service, such as Hypertext Transfer Protocol (HTTP), and a different set of real servers for another service, such as Telnet.
Packets destined for a virtual server address for a port that is not specified in the virtual server definition are not redirected.
IOS SLB supports both port-bound and non-port-bound servers, but port-bound servers are recommended.
IOS SLB firewall load balancing does not support port-bound servers.
Probes
IOS SLB supports DNS, HTTP, ping, TCP, and WSP probes:
•
•
HTTP probes also enable you to monitor applications being server load-balanced. With frequent probes, the operation of each application is verified, not just connectivity to the application.
HTTP probes do not support HTTP over Secure Socket Layer (HTTPS). That is, you cannot send an HTTP probe to an SSL server.
•
•
•
You can configure more than one probe, in any combination of supported types, for each server farm, or for each firewall in a firewall farm.
You can also flag a probe as a routed probe, with the following considerations:
•
•
Probes in Server Load Balancing
Probes determine the status of each real server in a server farm. All real servers associated with all virtual servers tied to that server farm are probed.
If a real server fails for one probe, it is failed for all probes. After the real server recovers, all probes must acknowledge its recovery before it is restored to service.
Probes in Firewall Load Balancing
Probes detect firewall failures. All firewalls associated with the firewall farm are probed.
If a firewall fails for one probe, it is failed for all probes. After the firewall recovers, all probes must acknowledge its recovery before it is restored to service.
Make sure you configure the HTTP probe to expect status code 401, to eliminate password problems. See the description of the expect command in the "Command Reference" section for more details.
Use the ip http server command to configure an HTTP server on the device. See the description of the ip http server command in the Cisco IOS Configuration Fundamentals Command Reference for more details.
In a transparent webcache load-balancing environment, an HTTP probe uses the real IP address of the webcache, since there is no virtual IP address configured.
Protocol Support
IOS SLB supports the following protocols:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RADIUS Load Balancing
IOS SLB provides RADIUS load-balancing capabilities for RADIUS servers. In addition, IOS SLB can load-balance devices that proxy the RADIUS Authorization and Accounting flows in both traditional and mobile wireless networks, if desired. IOS SLB does this by correlating data flows to the same proxy that processed the RADIUS for that subscriber flow.
IOS SLB provides RADIUS load balancing in mobile wireless networks that use service gateways, such as the Cisco Service Selection Gateway (SSG) or the Cisco Content Services Gateway (CSG). The following mobile wireless networks are supported:
•
•
•
IOS SLB provides the following RADIUS load-balancing functions:
•
•
•
•
•
•
•
•
•
•
To perform RADIUS load balancing, IOS SLB uses the following RADIUS sticky databases:
•
•
Note
Redundancy Enhancements
An IOS SLB device can represent a single point of failure, and the servers can lose their connections to the backbone, if either of the following occurs:
•
•
To reduce that risk, IOS SLB supports the following redundancy options, based on HSRP:
Stateless Backup
Stateless backup provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of a single Layer 3 switch. Stateless backup is particularly useful for hosts that do not support a router discovery protocol (such as the Intermediate System-to-Intermediate System [IS-IS] Interdomain Routing Protocol [IDRP]) and do not have the functionality to shift to a new Layer 3 switch when their selected Layer 3 switch reloads or loses power.
Stateful Backup
Stateful backup enables IOS SLB to incrementally backup its load-balancing decisions, or "keep state," between primary and backup switches. The backup switch keeps its virtual servers in a dormant state until HSRP detects failover; then the backup (now primary) switch begins advertising virtual addresses and processing flows. You can use HSRP to configure how quickly the failover is detected.
Stateful backup provides IOS SLB with a one-to-one stateful or idle backup scheme. This means that only one instance of IOS SLB is handling client or server flows at a given time, and that there is at most one backup platform for each active IOS SLB switch.
GPRS load balancing does not support stateful backup.
Active Standby
Active standby enables two IOS SLBs to load-balance the same virtual IP address while at the same time acting as backups for each other. If a site has only one virtual IP address to load-balance, an access router is used to direct a subset of the flows to each IOS SLB using policy-based routing.
IOS SLB firewall load balancing does not support active standby. That is, you cannot configure two pairs of firewall load balancing devices (one pair on each side of the firewalls), with each device in each pair handling traffic and backing up its partner.
Route Health Injection
By default, a virtual server's IP address is advertised (added to the routing table) when you bring the virtual server into service (using the inservice command). If you have a preferred host route to a website's virtual IP address, you can advertise that host route, but you have no guarantee that the IP address is available. However, you can use the advertise command to configure IOS SLB to advertise the host route only when IOS SLB has verified that the IP address is available. IOS SLB withdraws the advertisement when the IP address is no longer available. This function is known as route health injection.
Note
Slow Start
In an environment that uses weighted least connections load balancing, a real server that is placed in service initially has no connections, and could therefore be assigned so many new connections that it becomes overloaded. To prevent such an overload, slow start controls the number of new connections that are directed to a real server that has just been placed in service.
GPRS load balancing does not support slow start.
Sticky Connections
Sometimes, a client transaction can require multiple consecutive connections, which means new connections from the same client IP address or subnet must be assigned to the same real server. This is especially important in firewall load balancing, because the firewall might need to profile the multiple connections in order to detect certain attacks.
You can use the optional sticky command to enable IOS SLB to force connections from the same client to the same load-balanced server within a server farm. For firewall load balancing, the connections between the same client-server pair are assigned to the same firewall. New connections are considered to be sticky as long as the following conditions are met:
•
•
This binding of new connections to the same server or firewall is continued for a user-defined period after the last sticky connection ends.
To get the client-server address sticky behavior needed for "sandwich" firewall load balancing, you must enable sticky on both sides of the firewall farm. In this configuration, client-server sticky associations are created when an initial connection is opened between a client-server address pair. After this initial connection is established, IOS SLB maintains the sticky association in the firewall load-balancing devices on either side of the farm, and applies the sticky association to connections initiated from either the client or server IP address, by both firewall load-balancing devices.
Client subnet sticky is enabled when you specify a subnet mask on the sticky command. Subnet sticky is useful when the client IP address might change from one connection to the next. For example, before reaching IOS SLB, the client connections might pass through a set of NAT or proxy firewalls that have no sticky management of their own. Such a situation can result in failed client transactions if the servers do not have the logic to cope with it. In cases where such firewalls assign addresses from the same set of subnets, IOS SLB's sticky subnet mask can overcome the problems that they might cause.
Sticky connections also permit the coupling of services that are handled by more than one virtual server or firewall farm. This allows connection requests for related services to use the same real server. For example, web server (HTTP) typically uses TCP port 80, and HTTPS uses port 443. If HTTP virtual servers and HTTPS virtual servers are coupled, connections for ports 80 and 443 from the same client IP address or subnet are assigned to the same real server.
Virtual servers that are in the same sticky group are sometimes called buddied virtual servers.
GPRS load balancing does not support sticky connections.
SynGuard
SynGuard limits the rate of TCP start-of-connection packets (SYNchronize sequence numbers, or SYNs) handled by a virtual server to prevent a type of network problem known as a SYN flood denial-of-service attack. A user might send a large number of SYNs to a server, which could overwhelm or crash the server, denying service to other users. SynGuard prevents such an attack from bringing down IOS SLB or a real server. SynGuard monitors the number of SYNs handled by a virtual server at specific intervals and does not allow the number to exceed a configured SYN threshold. If the threshold is reached, any new SYNs are dropped.
IOS SLB firewall load balancing does not support SynGuard.
TCP Session Reassignment
IOS SLB tracks each TCP SYN sent to a real server by a client attempting to open a new connection. If several consecutive SYNs are not answered, or if a SYN is replied to with an RST, the TCP session is r
