Downloads |
Table Of Contents
IOS SLB Functions and Capabilities
Algorithms for Server Load Balancing
Client-Assigned Load Balancing
Delayed Removal of TCP Connection Context
Automatic Server Failure Detection
Dynamic Feedback Protocol for IOS SLB
Transparent Web Cache Balancing
Redundancy Enhancement—Stateless Backup
Supported Standards, MIBs, and RFCs
Specifying a Server Farm (Required)
Specifying a Load-Balancing Algorithm (Optional)
Specifying a Bind ID (Optional)
Specifying a Real Server (Required)
Configuring Real Server Attributes (Optional)
Enabling the Real Server for Service (Required)
Specifying a Virtual Server (Required)
Associating a Virtual Server with a Server Farm (Required)
Configuring Virtual Server Attributes (Required)
Adjusting Virtual Server Values (Optional)
Preventing Advertisement of Virtual Server Address (Optional)
Enabling the Virtual Server for Service (Required)
Configuring IOS SLB Dynamic Feedback Protocol (Optional)
Implementing IOS SLB Stateless Backup (Optional)
How IOS SLB Stateless Backup Works
Configuring IOS SLB Stateless Backup
Verifying the IOS SLB Stateless Backup Configuration
Sample IOS SLB Stateless Backup Configuration
Verifying IOS SLB Installation
Verifying Server Failure Detection
Monitoring and Maintaining IOS SLB
Sample IOS SLB Network Configuration
IOS Server Load Balancing
This feature module describes the Cisco IOS Server Load Balancing (SLB) feature for Cisco IOS Release 12.1(5)T. It includes the following sections:
•
Supported Standards, MIBs, and RFCs
•
Feature Overview
The IOS SLB feature is an IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, the network administrator defines 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 are configured to connect to the IP address of the virtual server. The virtual server IP address is configured as a loopback address, or secondary IP address, on each of the real servers. 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.
Figure 1 illustrates IOS SLB.
Figure 1
Logical View of IOS SLB
IOS SLB Functions and Capabilities
This section describes the following functions and capabilities supported in IOS SLB:
•
•
•
•
•
•
•
•
Algorithms for Server Load Balancing
IOS SLB provides two load-balancing algorithms: weighted round robin and weighted least connections. You may specify either algorithm 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
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
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.
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 serverfarm, and assign another set of clients (such as external clients) to a different serverfarm.
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.
Sticky Connections
When you use sticky connections, new connections from a client IP address or subnet are assigned to the same real server as were previous connections from that address or subnet.
IOS SLB creates sticky objects to track client assignments. The sticky objects remain in the IOS SLB database after the last sticky connection is deleted, for a period defined by a configurable sticky timer. If the timer is configured on a virtual server, new connections from a client are sent to the same real server that handled the previous client connection, provided one of the following is true:
•
•
Sticky connections also permit the coupling of services that are handled by more than one virtual server. This allows connection requests for related services to use the same real server. For example, Web server (HTTP) typically uses TCP port 80, and HTTP over Secure Socket Layer (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.
Maximum Connections
The maximum connections feature allows you to configure a limit on the number of active connections that a real server can handle.
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.
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 reassigned to a new real server. The number of SYN attempts is controlled by a configurable reassign threshold.
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 connection for which it qualifies. 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.
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.
SynGuard
SynGuard limits the rate of TCP synchronous idle characters (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 to a virtual server over a specific time interval and does not allow the number to exceed a configured SYN threshold. If the threshold is reached, any new SYNs are dropped.
Dynamic Feedback Protocol for IOS SLB
The IOS SLB Dynamic Feedback Protocol (DFP) is a mechanism that allows host agents in load-balanced environments to dynamically report the change in status of the host systems that provide a virtual service. The status reported is a relative weight that specifies a host server's capacity to perform work.
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.
Transparent Web Cache Balancing
You can balance transparent Webcaches if you know in advance the IP addresses they are serving. In IOS SLB, configure the IP addresses, or some common subset of them, as virtual servers.
Note
NAT
Cisco IOS Network Address Translation (NAT), RFC 1631, allows unregistered "private" IP addresses to connect to the Internet by translating them into globally registered IP addresses. Cisco IOS NAT also increases network privacy by hiding internal IP addresses from external networks.
IOS SLB can operate in one of two redirection modes:
•
•
The main advantage of dispatched mode is performance. In dispatched mode, the Layer 3 and Layer 4 addresses are not modified so IP header checksum adjustment is fast, and checksum adjustment or recalculation for TCP or UDP is not required. Dispatched mode is also simpler because packets for applications with IP addresses in the packet do not have to be examined and modified.
The main disadvantage of dispatched mode is that the virtual server IP address is not modified, so the real servers must be Layer 2 adjacent with the load balancer or intervening routers may not be able to route to the chosen real server.
NAT (directed mode) is used to solve these dispatched mode problems.
IOS SLB currently supports only server NAT. By replacing the virtual server IP address with the real server IP address (and vice versa), servers can be many hops away from the load balancer and intervening routers can route to them without requiring tunnelling. Additionally, loopback and secondary interfaces need no longer be on the real server.
Note
The network designer must ensure that outbound packets travel through IOS SLB, using one of the following methods:
•
•
•
A less common form of server NAT is server port translation, which involves replacement of a virtual server port. Server port translation does not require server IP address translation, but the two translations can be used together.
Redundancy Enhancement—Stateless Backup
An IOS SLB could represent a point of failure and the servers could lose their connections to the backbone if power fails, or if a link from a switch to the distribution-layer switch is disconnected. IOS SLB supports a stateless backup option you can use to reduce that risk. Stateless backup, based on Hot Standby Router Protocol (HSRP), provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of a single Layer 3 switch.
HSRP is configured on Layer 3 switches that run IP over Ethernet. If a Layer 3 switch fails, HSRP automatically allows another Layer 3 switch to assume the function of the failing switch. HSRP is therefore particularly useful when you require continuous access to resources in the network.
HSRP is compatible with Novell's Internetwork Packet Exchange (IPX) and with AppleTalk.
Note
Benefits
IOS SLB shares the same software code base as Cisco IOS and has all the software features sets of Cisco IOS software. IOS SLB is recommended for customers desiring complete integration of SLB technology into traditional Cisco switches and routers.
On the Cisco Catalyst 6500 switch, IOS SLB takes advantage of hardware acceleration to forward data packets at very high speed when running in dispatched mode.
IOS SLB assures continuous, high availability of content and applications with proven techniques for actively managing servers and connections in a distributed environment. By distributing user requests across a cluster of servers, IOS SLB optimizes responsiveness and system capacity, and dramatically reduces the cost of providing Internet, database, and application services for large-scale as well as small- and medium- sized sites.
IOS SLB facilitates scalability, availability, and ease of maintenance:
•
•
•
Administration of server applications is easier. Clients know only about virtual servers; no administration is required for real server changes.
Security of the real server is provided because its address is never announced to the external network. Users are familiar only with the virtual IP address. You can filter unwanted flows based on both IP address and TCP or UDP port numbers. Additionally, though it does not eliminate the need for a firewall, IOS SLB can help protect against some denial-of-service attacks.
In a branch office, IOS SLB allows balancing of multiple sites and disaster recovery in the event of full-site failure, and distributes the work of load balancing.
Restrictions
IOS SLB has the following restrictions:
•
•
•
•
•
•
•
–
–
–
–
–
–
•
–
–
–
Supported Platforms
•
•
Supported Standards, MIBs, and RFCs
Standards
•
MIBs
•
RFCs
•
Configuration Tasks
Configuring IOS SLB involves identifying server farms, configuring groups of real servers in server farms, and configuring the virtual servers that represent the real servers to the clients. See the following sections for configuration tasks for the IOS SLB feature. Perform these tasks in the order given. Some of the tasks are required; others are optional.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Specifying a Server Farm (Required)
Grouping real servers into server farms is an essential part of IOS SLB. Using server farms enables IOS SLB to assign new connections to the real servers based on their weighted capacities, and on the load-balancing algorithms used.
To configure a server farm, use the following command in global configuration mode:
Specifying a Load-Balancing Algorithm (Optional)
To determine which real server to use for each new connection request, the IOS SLB feature uses one of two load-balancing algorithms: weighted round robin (the default) or weighted least connections. (See the "Weighted Round Robin" section or the "Weighted Least Connections" section for detailed descriptions of these algorithms.) To specify the load-balancing algorithm, use the following command in server farm configuration mode:
Specifying a Bind ID (Optional)
To configure a bind ID on the server farm for use by DFP, use the following command in server farm configuration mode:
Specifies a bind ID on the server farm for use by DFP. See the bindid command for more details.
Specifying a Real Server (Required)
A server farm comprises a number of real servers. The real servers are the physical devices that provide the load-balanced services.
To identify a real server in your network, use the following command in server farm configuration mode:
Identifies a real server to the IOS SLB function and initiates real server configuration mode. See the real command for more details.
Configuring Real Server Attributes (Optional)
You can configure any of the following real server attributes, by using the following commands in real server configuration mode:
Enabling the Real Server for Service (Required)
To place the real server into service, use the following command in real server configuration mode:
Enables the real server for use by IOS SLB. See the inservice (real server) command for more details.
Specifying a Virtual Server (Required)
To specify a virtual server, use the following command in global configuration mode:
Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details.
Associating a Virtual Server with a Server Farm (Required)
To associate the virtual server with a server farm, use the following command in virtual server configuration mode:
Associates a real server farm with a virtual server. See the serverfarm command for more details.
Configuring Virtual Server Attributes (Required)
To configure virtual server attributes, use the following command in virtual server configuration mode:
Adjusting Virtual Server Values (Optional)
To change the default settings of the virtual server values, use the related command in virtual server configuration mode:
Preventing Advertisement of Virtual Server Address (Optional)
By default, virtual server addresses are advertised. That is, static routes to the Null0 interface are installed for the virtual server addresses. To advertise these static routes using the routing protocol, you must configure redistribution of static routes for the routing protocol. To prevent the installation of a static route, use the no form of the advertise command, in virtual server configuration mode:
Omits the virtual server IP address from the routing protocol updates. See the advertise command for more details.
Enabling the Virtual Server for Service (Required)
To place the virtual server into service, use the following command in virtual server configuration mode:
Enables the virtual server for use by IOS SLB. See the inservice (virtual server) command for more details.
Configuring IOS SLB Dynamic Feedback Protocol (Optional)
To configure IOS SLB DFP, enter the following commands in order, beginning in global configuration mode:
Configuring NAT (Optional)
To configure IOS SLB NAT mode for a specific server farm, enter the following commands in order, beginning in global configuration mode:
Implementing IOS SLB Stateless Backup (Optional)
Stateless backup, based on the Hot Standby Router Protocol (HSRP), provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of any 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.
How IOS SLB Stateless Backup Works
A Layer 3 switch running the HSRP detects a failure by sending and receiving multicast User Datagram Protocol (UDP) "hello" packets. When the IOS SLB switch running HSRP detects that the designated active Layer 3 switch has failed, the selected backup Layer 3 switch assumes control of the HSRP group MAC and IP addresses. (You can also select a new standby Layer 3 switch at that time.) Both the primary and the backup Layer 3 switch must be on the same subnetwork.
The chosen MAC and IP addresses must be unique and must not conflict with any others on the same network segment. The MAC address is selected from a pool of Cisco MAC addresses. Configure the last byte of the MAC address by using the HSRP group number. When the HSRP is running, it selects an active Layer 3 switch and instructs its device layer to listen on an additional (dummy) MAC address.
IOS SLB switching software supports HSRP over 10/100 Ethernet, Gigabit Ethernet, FEC, GEC, and BVI (Bridge-Group Virtual Interface) connections.
HSRP uses a priority scheme to determine which HSRP-configured Layer 3 switch is to be the default active Layer 3 switch. To configure a Layer 3 switch as active, you assign it a priority higher than that of all other HSRP-configured Layer 3 switches. The default priority is 100, so if you configure just one Layer 3 switch to have a higher priority, that switch becomes the default active switch.
HSRP works by the exchange of multicast messages that advertise priority among HSRP-configured Layer 3 switches. When the active switch fails to send a hello message within a configurable period, the standby switch with the highest priority becomes the active switch. The transition of packet-forwarding functions between Layer 3 switches is completely transparent to all hosts accessing the network.
HSRP-configured Layer 3 switches exchange the following types of multicast messages:
•
•
•
At any time, HSRP-configured Layer 3 switches are in one of the following states:
•
•
•
•
Configuring IOS SLB Stateless Backup
Configuration of stateless backup requires the following:
•
•
To configure stateless backup over VLANs between IOS SLB switches, perform the following tasks in order:
Step 1
Step 2
Step 3
Note
Step 4
Step 5
Step 6
Step 7
Step 8
A sample stateless backup configuration is shown in the "Sample IOS SLB Stateless Backup Configuration" section.
Enabling HSRP
To enable HSRP on an IOS SLB interface, enable the protocol, then customize it for the interface. Enter the following command in interface configuration mode:
Enables HSRP.
Customizing Group Attributes
To customize "hot standby" group attributes, use one or more of the following commands in interface configuration mode:
Verifying the IOS SLB Stateless Backup Configuration
To verify that stateless backup has been configured and is operating correctly, use the following show ip slb vservers commands to display information about the IOS SLB virtual server status:
Router# show ip slb vserversslb vserver prot virtual state conns-------------------------------------------------------------------VS1 TCP 10.10.10.12:23 INSERVICE 2VS2 TCP 10.10.10.18:23 INSERVICE 2Router# show ip slb vservers detailVS1, state = INSERVICE, v_index = 10virtual = 10.10.10.12:23, TCP, service = NONE, advertise = TRUEserver farm = SERVERGROUP1, delay = 10, idle = 3600sticky timer = 0, sticky subnet = 255.255.255.255sticky group id = 0synguard counter = 0, synguard period = 0conns = 0, total conns = 0, syns = 0, syn drops = 0standby group = NoneVS2, state = INOFSERVICE, v_index = 11virtual = 10.10.10.18:23, TCP, service = NONE, advertise = TRUEserver farm = SERVERGROUP2, delay = 10, idle = 3600sticky timer = 0, sticky subnet = 255.255.255.255sticky group id = 0synguard counter = 0, synguard period = 0conns = 0, total conns = 0, syns = 0, syn drops = 0standby group = NoneSample IOS SLB Stateless Backup Configuration
The following commands enable the HSRP standby group 100 IP address, priority, preempt, timers, configure a name and authentication for Device A in Figure 4:
Router(config-if)# standby 100 ip 172.20.100.10Router(config-if)# standby 100 priority 110Router(config-if)# standby 100 preemptRouter(config-if)# standby 100 timers 5 15Router(config-if)# standby 100 name Web_group1Router(config-if)# standby 100 authentication SecretRouter(config-if)# exitRouter#Verifying IOS SLB
This section describes how to verify the following different aspects of the IOS SLB feature:
•
•
Verifying IOS SLB Installation
To verify that the IOS SLB is installed and working properly, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
Step 6
Step 7
Step 8
Verifying Server Failure Detection
To verify that server failures are detected correctly, follow these steps:
Step 1
Step 2
Step 3
•
•
•
Troubleshooting IOS SLB
The following questions and answers can help you troubleshoot IOS SLB, if you have problems.
Monitoring and Maintaining IOS SLB
To obtain and display runtime information about IOS SLB, use the following commands in EXEC mode:
Configuration Examples
This section provides the following IOS SLB configuration examples:
•
Sample IOS SLB Network Configuration
This section provides a configuration example based on the network layout shown in Figure 2.
Figure 2 IOS SLB Network Configuration
As shown in the following sample code, the example topology has three public Web servers and two restricted Web servers for privileged clients in subnet 10.4.4.x. The public Web servers are weighted according to their capacity, with server 10.1.1.2 having the lowest capacity and having a connection limit imposed on it. The restricted Web servers are configured as members of the same sticky group, so that HTTP connections and Secure Socket Layer (SSL) connections from the same client use the same real server.
This configuration is coded as follows:
ip slb serverfarm PUBLIC Unrestricted Web server farmpredictor leastconns Use weighted least connections algorithm
