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 Web Cache 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 Web Cache Load Balancing
clear ip slb sticky radius framed-ip
delay (firewall farm TCP protocol)
idle (firewall farm datagram protocol)
idle (firewall farm TCP protocol)
inservice (firewall farm real server)
inservice (server farm real server)
inservice (server farm virtual server)
maxconns (firewall farm datagram protocol)
maxconns (firewall farm TCP protocol)
predictor hash address (firewall farm)
probe (firewall farm real server)
replicate casa (firewall farm)
replicate casa (virtual server)
sticky (firewall farm datagram protocol)
sticky (firewall farm TCP 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 platforms was added:
•
The following functions were added:
12.1(9)E
The following functions were added:
12.1(11b)E
Support for the following platforms was added:
•
The following functions were added:
•
•
•
12.1(12c)E
The following functions were added:
•
•
12.1(13)E
This release incorporated only minor corrections and clarifications.
12.2(14)S
This feature was integrated into Cisco IOS Release 12.2(14)S.
Support for the following platforms was removed:
•
•
•
This document describes the Cisco IOS Server Load Balancing (IOS SLB) feature in Cisco IOS Release 12.2(14)S. 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. Dynamic Feedback Protocol (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 document for Cisco IOS Release 12.2(14)S.
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 command in server farm configuration mode. 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 Packet Data Protocol (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. For example, Cisco 7200 series routers acting as GGSNs are often configured with a maximum of 45,000 PDP contexts.
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 type of routing 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 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 configuration 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.
Refer to the "Configuring Logical Interfaces" chapter of the Cisco IOS Interface Configuration Guide, Release 12.2 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 option 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 Domain Name System (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:
•
•
IOS SLB probes use the SA Agent. You might want to specify the amount of memory that the SA Agent can use, using the rtr low-memory command. If the amount of available free memory falls below the value specified in the rtr low-memory command, then the SA Agent does not allow new operations to be configured. Refer to the description of the rtr low-memory command in the Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 for more details.
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. Refer to the description of the ip http server command in the Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 for more details.
In a transparent web cache load-balancing environment, an HTTP probe uses the real IP address of the web cache, 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. These connections are 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 option 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 reassigned to a new real server. The number of SYN attempts is controlled by a configurable reassign threshold.
IOS SLB firewall load balancing does not support TCP session reassignment.
Transparent Web Cache Load Balancing
IOS SLB can load-balance HTTP flows across a cluster of transparent web caches. To set up this function, configure the subnet IP addresses served by the transparent web caches, or some common subset of them, as virtual servers. Virtual servers used for transparent web cache load balancing do not answer pings on behalf of the subnet IP addresses, and they do not affect traceroute.
In some cases, such as when its cache does not contain needed pages, a web cache might need to initiate its own connections to the Internet. Those connections should not be load-balanced back to the same set of web caches. To address this need, IOS SLB allows you to configure client exclude statements, which exclude connections initiated by the web caches from the load-balancing scheme.
IOS SLB firewall load balancing does not support transparent web cache load balancing.
VPN Server Load Balancing
IOS SLB can balance Virtual Private Network (VPN) flows, including the following flows:
•
•
WAP Load Balancing
You can use IOS SLB to load-balance Wireless Session Protocol (WSP) sessions among a group of WAP gateways or servers on an IP bearer network. WAP runs on top of UDP on a set of well known ports, with each port indicating a different WAP mode:
•
•
•
•
IOS SLB uses WSP probes to detect failures in the WAP stack on port 9201.
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.
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-, medium-, and small-scale sites.
IOS SLB facilitates scalability, availability, and ease of maintenance:
•
•
•
•
Using DFP enables IOS SLB to provide weights to another load-balancing system. IOS SLB can act as a DFP manager, receiving weights from host servers, and it can act as a DFP agent, sending weights to a DFP manager. The functions are enabled independently—you can implement either one, or both, at the same time.
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 for IOS SLB
IOS SLB has the following restrictions:
•
•
•
•
•
When operating in directed mode with server NAT, real servers need not be Layer 2-adjacent to IOS SLB. This function allows for more flexible network design, since servers can be placed several Layer 3 hops away from the IOS SLB switch.
•
•
•
–
–
–
–
•
–
–
–
•
–
–
–
–
–
–
- Active standby
- Network Address Translation (NAT)
- Port-bound servers
- SynGuard
- TCP session reassignment
- Transparent web cache load balancing
•
–
–
–
- Bind IDs
- Client-assigned load balancing
- Slow Start
- Stateful backup
- Sticky connections
- Weighted least connections load-balancing algorithm. 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.
•
–
•
–
–
–
–
•
–
–
–
–
- The PDSN must include the User-Name attribute in all RADIUS Access-Request and Accounting-Start packets. The value of the User-Name attribute for a given subscriber must be the same in all the packets (except for Cisco PDSNs that provide MSID-based access).
- The PDSN must include the Framed-ip-address attribute and the NAS-ip-address in all RADIUS Accounting-Start and Accounting-Stop packets. The value of the Framed-ip-address attribute must equal the source IP address in subscriber data packets routed by RADIUS load balancing for SSG service.
- The PDSN must include the NAS-ip-address in all Accounting-Requests. For BSC/PCF hand-offs, the Accounting-Stop must include the 3GPP2-Session-Continue VSA with a value of 1, to prevent the destruction of RADIUS load balancing sticky database objects for the subscriber.
–
- For a given subscriber session, the PDSN and HA must send the RADIUS Access-Request and Accounting-Start packets with the User-Name attribute. The value of the User-Name attribute in all PDSN and HA RADIUS packets must be the same for the session.
- For a given subscriber session, the PDSN and HA must send RADIUS Accounting-Request packets with a Framed-ip-address attribute equal to the source IP address in subscriber data packets routed by RADIUS load balancing for SSG service. All RADIUS Accounting-Requests sent by the PDSN and HA must also include the NAS-ip-address attribute.
- The PDSN must include the 3GPP2-Correlation-Identifier attribute in all Accounting-Requests.
•
–
•
–
–
Related Features and Technologies
•
•
•
•
•
•
Related Documents
•
•
•
•
•
•
Supported Platforms
•
Determining Platform Support Through Cisco Feature Navigator
Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.
To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:
Availability of Cisco IOS Software Images
Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.
Supported Standards, MIBs, and RFCs
Standards
•
MIBs
•
Note
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
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.
For configuration examples associated with these tasks, see the "Configuration Examples" section.
For a complete description of the IOS SLB commands in this section, see the "Command Reference" section. To locate documentation of other commands that appear in this section, search online using Cisco.com.
To configure IOS SLB, perform the tasks in the following sections:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring Required and Optional IOS SLB Functions
To configure IOS SLB functions, perform the tasks in the following sections. Required and optional tasks are indicated.
•
•
•
•
•
•
Configuring a Server Farm and Real Server
To configure an IOS SLB server farm, use the following commands beginning in global configuration mode:
Configuring a Virtual Server
IOS SLB supports up to 500 virtual servers.
To configure an IOS SLB virtual server, use the following commands beginning in global configuration mode:
Verifying the Virtual Server
The following show ip slb vserver command verifies the configuration of the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router# show ip slb vserverslb vserver prot virtual state conns-------------------------------------------------------------------PUBLIC_HTTP TCP 10.0.0.1:80 OPERATIONAL 0RESTRICTED_HTTP TCP 10.0.0.2:80 OPERATIONAL 0Router#Verifying the Server Farm
The following show ip slb reals command displays the status of server farms PUBLIC and RESTRICTED, the associated real servers, and their status:
Router# show ip slb realreal farm name weight state conns---------------------------------------------------------------------10.1.1.1 PUBLIC 8 OPERATIONAL 010.1.1.2 PUBLIC 8 OPERATIONAL 010.1.1.3 PUBLIC 8 OPERATIONAL 010.1.1.20 RESTRICTED 8 OPERATIONAL 010.1.1.21 RESTRICTED 8 OPERATIONAL 0Router#The following show ip slb serverfarm command displays the configuration and status of server farms PUBLIC and RESTRICTED:
Router# show ip slb serverfarmserver farm predictor nat reals bind id---------------------------------------------------PUBLIC ROUNDROBIN none 3 0RESTRICTED ROUNDROBIN none 2 0Router#Verifying the Clients
The following show ip slb conns command verifies the restricted client access and status:
Router# show ip slb connsvserver prot client real state nat-------------------------------------------------------------------------------RESTRICTED_HTTP TCP 10.4.4.0:80 10.1.1.20 CLOSING noneRouter#The following show ip slb conns command displays detailed information about the restricted client access status:
Router# show ip slb conns client 10.4.4.0 detailVSTEST_UDP, client = 10.4.4.0:80state = CLOSING, real = 10.1.1.20, nat = nonev_ip = 10.0.0.2:80, TCP, service = NONEclient_syns = 0, sticky = FALSE, flows attached = 0Router#Verifying IOS SLB Connectivity
To verify that the IOS SLB feature has been installed and is operating correctly, ping the real servers from the IOS SLB switch, then ping the virtual servers from the clients.
The following show ip slb stats command displays detailed information about the IOS SLB network status:Router# show ip slb statsPkts via normal switching: 0Pkts via special switching: 6Pkts dropped: 0Connections Created: 1Connections Established: 1Connections Destroyed: 0Connections Reassigned: 0Zombie Count: 0Connections Reused: 0Normal switching is when IOS SLB packets are handled on normal IOS switching paths (CEF, fast switching, and process level switching). Special switching is when IOS SLB packets are handled on hardware-assisted switching paths.
See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB networks and connections.
Configuring Firewall Load Balancing
This section describes the tasks required to configure a basic IOS SLB firewall load-balancing network.
IOS SLB firewall load balancing uses probes to detect and recover from failures. You must configure a probe on each real server in the firewall farm. Ping probes are recommended; see the "Configuring Ping Probes" section for more details. If a firewall does not allow ping probes to be forwarded, use HTTP probes instead. See the "Configuring HTTP Probes" section for more details. You can configure more than one probe, in any combination of supported types (DNS, HTTP, TCP, or ping), for each firewall in a firewall farm.
This section describes the following IOS SLB firewall load-balancing configuration tasks. Required and optional tasks are indicated.
•
•
•
Configuring the Firewall Farm
To configure an IOS SLB firewall load-balancing network, enter the following commands in order, beginning in global configuration mode:
Verifying the Firewall Farm
The following show ip slb reals command displays the status of firewall farm FIRE1, the associated real servers, and their status:
Router# show ip slb realreal farm name weight state conns--------------------------------------------------------------------10.1.1.2 FIRE1 8 OPERATIONAL 010.1.2.2 FIRE1 8 OPERATIONAL 0The following show ip slb firewallfarm command displays the configuration and status of firewall farm FIRE1:
Router# show ip slb firewallfarmfirewall farm hash state reals------------------------------------------------FIRE1 IPADDR INSERVICE 2Verifying Firewall Connectivity
To verify that IOS SLB firewall load balancing has been configured and is operating correctly:
Step 1
Step 2
Step 3
Router# show ip slb statsPkts via normal switching: 0Pkts via special switching: 0Pkts dropped: 0Connections Created: 1911871Connections Established: 1967754Connections Destroyed: 1313251Connections Reassigned: 0Zombie Count: 0Connections Reused: 59752Connection Flowcache Purges:1776582Failed Connection Allocs: 17945Failed Real Assignments: 0Normal switching is when IOS SLB packets are handled on normal IOS switching paths (CEF, fast switching, and process level switching). Special switching is when IOS SLB packets are handled on hardware-assisted switching paths.
Step 4
Router# show ip slb real detail10.1.1.3, FIRE1, state = OPERATIONAL, type = firewallconns = 299310, dummy_conns = 0, maxconns = 4294967295weight = 10, weight(admin) = 10, metric = 104, remainder = 2total conns established = 1074779, hash count = 4646server failures = 0interface FastEthernet1/0, MAC 0010.f68f.7020Step 5
Router# show ip slb connsvserver prot client real state nat-------------------------------------------------------------------------------FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneStep 6
Configuring Probes
IOS SLB uses probes to verify connectivity and detect failures. For a detailed description of each type of probe, see the "Probes" section.
By default, no probes are configured in IOS SLB. The following sections describe how to configure and verify probes. Required and optional tasks are indicated.
•
•
•
•
•
•
•
Configuring DNS Probes
To configure a DNS probe, enter the following commands in order, beginning in global configuration mode:
Configuring HTTP Probes
To configure an HTTP probe, enter the following commands in order, beginning in global configuration mode:
In addition, HTTP probes require a route to the virtual server. The route is not used, but it must exist to enable the sockets code to verify that the destination can be reached, which in turn is essential for HTTP probes to function correctly. The route can be either a host route (advertised by the virtual server) or a default route (specified using the ip route 0.0.0.0 0.0.0.0 command, for example).
Configuring Ping Probes
To configure a ping probe, enter the following commands in order, beginning in global configuration mode:
Configuring TCP Probes
To configure a TCP probe, enter the following commands in order, beginning in global configuration mode:
Configuring WSP Probes
To configure a WSP probe, enter the following commands in order, beginning in global configuration mode:
Associating the Probe
After configuring a probe, you must associate it with a real server or firewall, using the probe command. See the "Configuring a Server Farm and Real Server" section and the "Configuring Firewall Load Balancing" section for more details.
Note
Verifying the Probe
To verify that a probe is configured correctly, use the show ip slb probe command:
Router# show ip slb probeServer:Port State Outages Current Cumulative----------------------------------------------------------------10.1.1.1:80 OPERATIONAL 0 never 00:00:0010.1.1.2:80 OPERATIONAL 0 never 00:00:0010.1.1.3:80 OPERATIONAL 0 never 00:00:00Router#Configuring DFP
You can define IOS SLB as a DFP manager, as a DFP agent for another DFP manager, or as both at the same time. Depending on your network configuration, you might enter the commands for configuring IOS SLB as a DFP manager and the commands for configuring IOS SLB as a DFP agent on the same device or on different devices.
To configure IOS SLB as a DFP manager, and to identify a DFP agent with which IOS SLB can initiate connections, enter the following commands in order, beginning in global configuration mode:
To configure IOS SLB as a DFP agent, see the DFP Agent Subsystem feature document for Cisco IOS Release 12.2(14)S.
GPRS Load Balancing Configuration Task List
This section lists the tasks used to configure GPRS load balancing. Detailed configuration information is contained in the referenced sections of this or other documents. Required and optional tasks are indicated.
•
When you configure the server farm and real server for GPRS load balancing, keep the following considerations in mind:
–
–
–
•
When you configure the virtual server for GPRS load balancing, keep the following considerations in mind:
–
–
•
This step is required only if you are using dispatched mode. Refer to the "Configuring a Loopback Interface" section in the Cisco IOS Interface Configuration Guide, Release 12.2 for more information.
•
The route can be static or dynamic, but the GGSN needs to be able to reach the SGSN. Refer to the "Configuring Network Access to the GGSN" section of the Cisco IOS Mobile Wireless Configuration Guide, Release 12.2 for more details.
•
Refer to the configuration guide for your SGSN for more details.
RADIUS Load Balancing Configuration Task List
This section lists the tasks used to configure RADIUS load balancing. Detailed configuration information is contained in the referenced sections of this or other documents. Required and optional tasks are indicated.
•
When you configure the server farm and real server for RADIUS load balancing, keep the following considerations in mind:
–
–
–
•
When you configure the virtual server for RADIUS load balancing, keep the following considerations in mind:
–
–
If you configure the access interface route framed-ip command, you must also configure the virtual command with the service radius keywords specified.
–
–
–
If you configure the sticky radius framed-ip command, you must also configure the virtual command with the service radius keywords specified.
–
If you configure the sticky radius username command, you must also configure the virtual command with the service radius keywords specified, and you must configure the sticky radius framed-ip command.
•
•
To verify the health of the server, configure a ping probe.
Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing
You can enable IOS SLB to inspect packets whose source IP addresses match a configured IP address and subnet mask. If the source IP address of an inspected packet matches an entry in the IOS SLB RADIUS framed-IP sticky database, IOS SLB uses that entry to route the packet. Otherwise, IOS routes the packet.
To enable IOS SLB to inspect packets for routing using the RADIUS framed-IP sticky database, enter the following command in global configuration mode:
Enables IOS Server Load Balancing (IOS SLB) to route packets using the RADIUS framed-IP sticky database.
VPN Server Load Balancing Configuration Task List
This section lists the tasks used to configure VPN server load balancing. Detailed configuration information is contained in the referenced sections of this or other documents. Required and optional tasks are indicated.
•
When you configure the server farm and real server for VPN server load balancing, specify the IP addresses of the real servers acting as VPN terminators, using the real command.
•
When you configure the virtual server for VPN server load balancing of IPSec flows, keep the following considerations in mind:
–
–
–
When you configure the virtual server for VPN server load balancing of PPTP flows, keep the following considerations in mind:
–
–
–
•
To verify the health of the server, configure a ping probe.
Configuring NAT
To configure the IOS SLB NAT client address pool for client NAT, enter the following command in global configuration mode:
You need not configure the client address pool for server NAT.
You must also specify either NAT client translation mode or NAT server address translation mode on the server farm, using the nat command. See the "Configuring a Server Farm and Real Server" section for more details. When you configure the virtual server for NAT, remember that you cannot configure client NAT for an ESP or GRE virtual server.
Configuring Static NAT
Static NAT enables you to allow some users to utilize NAT and allow other users on the same Ethernet interface to continue with their own IP addresses. This option 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.
Note
To configure NAT for the server, enter the following commands in order, beginning in global configuration mode:
Stateless Backup Configuration Task List
This section lists the tasks used to configure stateless backup over VLANs between IOS SLB devices. Detailed configuration information is contained in the referenced sections of this or other documents. Required and optional tasks are indicated.
•
•
•
Refer to the "IP Routing Protocols" chapter of the Cisco IOS IP Configuration Guide, Release 12.2 for more details.
•
Refer to the "Virtual LANs" chapter of the Cisco IOS Switching Services Configuration Guide, Release 12.2 for more details.
•
Note
Verifying the Stateless Backup Configuration
For server load balancing, to verify that stateless backup has been configured and is operating correctly, use the following show ip slb vserver commands to display information about the IOS SLB virtual server status:
Router# show ip slb vserverslb vserver prot virtual state conns-------------------------------------------------------------------VS1 TCP 10.10.10.12:23 OPERATIONAL 2VS2 TCP 10.10.10.18:23 OPERATIONAL 2Router# show ip slb vserver detailVS1, state = OPERATIONAL, 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 = INSERVICE, 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 = NoneFor firewall load balancing, to verify that stateless backup has been configured and is operating correctly, use the following show ip slb firewallfarm commands to display information about the IOS SLB firewall farm status:
Router# show ip slb firewallfarmfirewall farm hash state reals------------------------------------------------FIRE1 IPADDR INSERVICE 2Router# show ip slb firewallfarm detailsFIRE1, hash = IPADDRPORT, state = INSERVICE, reals = 2FirewallTCP:sticky timer = 0, sticky subnet = 255.255.255.255idle = 3600, delay = 10, syns = 1965732, syn drop = 0maxconns = 4294967295, conns = 597445, total conns = 1909512FirewallUDP:sticky timer = 0, sticky subnet = 255.255.255.255idle = 3600maxconns = 1, conns = 0, total conns = 1Real firewalls:10.1.1.3, weight = 10, OPERATIONAL, conns = 29882310.1.1.4, weight = 10, OPERATIONAL, conns = 298622Total connections = 597445Configuring Database Entries
To configure an initial allocation and a maximum value for IOS SLB database entries, enter the following command in global configuration mode:
Configuring Buffers for the Fragment Database
To configure the maximum number of buffers for the IOS SLB fragment database, enter the following command in global configuration mode:
Configures the maximum number of buffers for the IOS Server Load Balancing (IOS SLB) fragment database.
Clearing Databases and Counters
To clear IP IOS SLB databases and counters, enter one or more of the following commands in privileged EXEC mode:
Purging and Reassigning Connections
You can enable IOS SLB to automatically remove connections to failed real servers and firewalls from the connection database even if the idle timers have not expired. This function is useful for applications that do not rotate the source port (such as IKE), and for protocols that do not have ports to differentiate flows (such as ESP).
You can also enable IOS SLB to automatically reassign to a new real server or firewall RADIUS sticky objects that are destined for a failed real server or firewall.
To configure IOS SLB's behavior when a real server fails, enter the following commands in order, beginning in global configuration mode:
To configure IOS SLB's behavior when a firewall fails, enter the following commands in order, beginning in global configuration mode:
Monitoring and Maintaining the IOS SLB Feature
To obtain and display runtime information about IOS SLB, use the following commands in EXEC mode:
Configuration Examples
This section provides real-world examples of IOS SLB configurations. For a complete description of the IOS SLB commands in this section, see the "Command Reference" section. To locate documentation of other commands that appear in this section, search online using Cisco.com.
This section includes the following examples:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
Basic IOS SLB Network Configuration Example
Figure 2 shows a sample IOS SLB network with the following components:
•
•
–
–
•
–
–
Figure 2 Example IOS SLB Network
The following sections include examples of the configuration commands used to configure and verify the IOS SLB network shown in Figure 2:
•
Server Farm Configuration
The following example shows the configuration for the server farm PUBLIC, associated with three real servers:
ip slb serverfarm PUBLICreal 10.1.1.1reassign 2faildetect numconns 4 numclients 2retry 20inserviceexitreal 10.1.1.2reassign 2faildetect numconns 4retry 20inserviceexitreal 10.1.1.3reassign 2faildetect numconns 4retry 20inserviceendThe following example shows the configuration for the server farm RESTRICTED, associated with two real servers:
ip slb serverfarm RESTRICTEDreal 10.1.1.20reassign 2faildetect numconns 4retry 20inserviceexitreal 10.1.1.21reassign 2faildetect numconns 4retry 20inserviceendVirtual Server Configuration
The following example shows the configuration for the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
ip slb vserver PUBLIC_HTTPvirtual 10.0.0.1 tcp wwwserverfarm PUBLICidle 120delay 5inserviceexitip slb vserver RESTRICTED_HTTPvirtual 10.0.0.2 tcp wwwserverfarm RESTRICTEDidle 120delay 5inserviceendRestricted Client Configuration
The following example shows the configuration for the virtual server RESTRICTED_HTTP:
ip slb vserver RESTRICTED_HTTPno inserviceclient 10.4.4.0 255.255.255.0inserviceendComplete IOS SLB Configuration Example
The following example provides a complete configuration using many of the commands described in this feature document:
ip slb probe PROBE2 httprequest method POST url /probe.cgi?allheader HeaderName HeaderValue!ip slb serverfarm PUBLICnat serverreal 10.1.1.1reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.2reassign 4faildetect numconns 16retry 120inserviceprobe PROBE2!ip slb serverfarm RESTRICTEDpredictor leastconnsbindid 309real 10.1.1.1weight 32maxconns 1000reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.20reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.21reassign 4faildetect numconns 16retry 120inservice!ip slb vserver PUBLIC_HTTPvirtual 10.0.0.1 tcp wwwserverfarm PUBLIC!ip slb vserver RESTRICTED_HTTPvirtual 10.0.0.2 tcp wwwserverfarm RESTRICTEDno advertisesticky 60 group 1idle 120delay 5client 10.4.4.0 255.255.255.0synguard 3600000inserviceIOS SLB with Firewall Load Balancing Example
Figure 3 shows a sample IOS SLB firewall load-balancing network with the following components:
•
•
•
•
Figure 3 IOS SLB with Layer 3 Firewalls in Different Subnets
When you configure IOS SLB firewall load balancing, the load-balancing devices use route lookup to recognize flows destined for the firewalls. To enable route lookup, you must configure each device with the IP address of each firewall that will route flows to that device.
In the following firewall farm configuration samples:
•
•
Internal Firewall Load-Balancing Device
The following example shows the configuration for ping probe PROBE1, HTTP probe PROBE2, and firewall farm FIRE1, associated with the two real servers for the load-balancing device on the internal (secure) side of the firewall:
!-----Ping probeip slb probe PROBE1 ping!-----IP address of other load-balancing deviceaddress 10.1.1.1faildetect 4!-----HTTP probeip slb probe PROBE2 http!-----IP address of other load-balancing deviceaddress 10.1.2.1expect status 401!-----Firewall farm FIRE1ip slb firewallfarm FIRE1!-----First firewallreal 10.1.4.1probe PROBE1!-----Enable first firewallinservice!-----Second firewallreal 10.1.3.1probe PROBE2!-----Enable second firewallinserviceExternal Firewall Load-Balancing Device
The following example shows the configuration for ping probe PROBE1, HTTP probe PROBE2, and firewall farm FIRE1, associated with the two real servers for the load-balancing device on the external (Internet) side of the firewall:
!-----Ping probeip slb probe PROBE1 ping!-----IP address of other load-balancing deviceaddress 10.1.4.2faildetect 4!-----HTTP probeip slb probe PROBE2 http!-----IP address of other load-balancing deviceaddress 10.1.3.2expect status 401!-----Firewall farm FIRE1ip slb firewallfarm FIRE1!-----First firewallreal 10.1.1.2probe PROBE1!-----Enable first firewallinservice!-----Second firewallreal 10.1.2.2probe PROBE2!-----Enable second firewallinserviceexitinserviceIOS SLB with Server Load Balancing and Firewall Load Balancing Example
Figure 4 shows a sample IOS SLB load-balancing network with server load balancing and firewall load balancing running together, and the following components:
•
•
•
•
•
•
Figure 4 IOS SLB with Server Load Balancing and Firewall Load Balancing
In the following firewall farm configuration samples:
•
•
Internal Server and Firewall Load-Balancing Device
The following example shows the configuration for ping probes ABCPROBE and XYZPROBE, firewall farm FIRE1, and server farm PUBLIC for the load-balancing device on the internal (secure) side of the firewalls:
ip slb probe ABCPROBE pingaddress 10.1.1.1ip slb probe XYZPROBE pingaddress 10.1.2.1!ip slb firewallfarm FIRE1real 10.1.4.1probe ABCPROBEinservice!real 10.1.3.1probe XYZPROBEinserviceinservice!ip slb serverfarm PUBLICnat serverreal 10.2.1.1inservicereal 10.2.1.2inservice!ip slb vserver HTTP1virtual 128.1.0.1 tcp wwwserverfarm PUBLICidle 120delay 5inserviceExternal Firewall Load-Balancing Device
The following example shows the configuration for ping probes ABCPROBE and XYZPROBE and firewall farm FIRE1 for the load-balancing device on the external (Internet) side of the firewalls:
ip slb probe ABCPROBE pingaddress 10.1.4.2ip slb probe XYZPROBE pingaddress 10.1.3.2ip slb firewallfarm FIRE1real 10.1.1.2probe ABCPROBEinserviceprobe XYZPROBEinserviceIOS SLB with Multiple Firewall Farms Example
Figure 5 shows a sample IOS SLB load-balancing network with multiple firewall farms and the following components:
•
•
•
•
•
Figure 5 IOS SLB with Multiple Firewall Farms
In the following firewall farm configuration samples:
•
•
Internal Firewall Load-Balancing Device
The following example shows the configuration for ping probes ABCPROBE and XYZPROBE and firewall farms ABCFARM and XYZFARM for the load-balancing device on the internal (secure) side of the firewalls:
ip slb probe ABCPROBE pingaddress 10.1.2.1ip slb probe XYZPROBE pingaddress 10.1.1.1ip slb firewallfarm ABCFARMaccess source 10.1.6.0 255.255.255.0inservicereal 10.1.4.2probe ABCPROBEinservicereal 10.1.4.3probe ABCPROBEinserviceip slb firewallfarm XYZFARMaccess source 10.1.5.0 255.255.255.0inservicereal 10.1.3.2probe XYZPROBEinservicereal 10.1.3.3probe XYZPROBEinserviceExternal Firewall Load-Balancing Device
The following example shows the configuration for ping probes ABCPROBE and XYZPROBE and firewall farms ABCFARM and XYZFARM for the load-balancing device on the external (Internet) side of the firewalls:
ip slb probe ABCPROBE pingaddress 10.1.4.1ip slb probe XYZPROBE pingaddress 10.1.3.1ip slb firewallfarm ABCFARMaccess destination 10.1.6.0 255.255.255.0inservicereal 10.1.2.2probe ABCPROBEinservicereal 10.1.2.3probe ABCPROBEinserviceip slb firewallfarm XYZFARMaccess destination 10.1.5.0 255.255.255.0inservicereal 10.1.1.2probe XYZPROBEinservicereal 10.1.1.3probe XYZPROBEinserviceIOS SLB with Probes Example
Figure 6 shows a sample configuration with IOS SLB real server connections configured as part of a server farm, focusing on using ping and HTTP probes to monitor applications being server load-balanced.
Figure 6 Sample Ping and HTTP Probe Topology
:
The topology shown in Figure 6 is a heterogeneous server farm servicing a single virtual server. Following are the configuration statements for this topology, including a ping probe named PROBE1 and an HTTP probe named PROBE2:
! Configure ping probe PROBE1, change CLI to IOS SLB probe configuration modeip slb probe PROBE1 ping! Configure probe to receive responses from IP address 13.13.13.13address 13.13.13.13! Configure unacknowledged ping threshold to 16faildetect 16! Configure ping probe timer interval to send every 11 secondsinterval 11! Configure HTTP probe PROBE2ip slb probe PROBE2 http! Configure request method as POST, set URL as /probe.cgi?allrequest method post url /probe.cgi?all! Configure header HeaderNameheader HeaderName HeaderValue! Configure basic authentication username and passwordcredentials Semisweet chips! Exit to global configuration modeexit! Enter server farm configuration mode for server farm PUBLICip slb serverfarm PUBLIC! Configure NAT server and real servers on the server farmnat serverreal 10.1.1.1inservicereal 10.1.1.2inservicereal 10.1.1.3inservicereal 10.1.1.4inservicereal 10.1.1.5inservice! Configure ping probe on the server farmprobe PROBE1! Configure HTTP probe on the server farmprobe PROBE2endIOS SLB with Routed Probe Example
Figure 7 shows a typical datacenter and IOS SLB configuration. Virtual server ACME_VSERVER is configured with two real servers (10.10.10.1, and 10.10.10.2) in server farm ACME_FARM. The user wants the real servers to fail based on the health of the backend server (10.10.10.3). To accomplish this configuration without sending health checks via the real servers, the user defines BACKEND, a routed ping probe to the backend server's IP address.
Figure 7 IOS SLB with a Routed Ping Probe
Following are the IOS SLB configuration statements for the configuration shown in Figure 7:
ip slb probe BACKEND pingaddress 10.10.10.3 routed!ip slb serverfarm ACME_SFARMnat serverprobe BACKENDreal 10.10.10.1inservicereal 10.10.10.2inservice!ip slb vserver ACME_VSERVERvirtual 10.10.10.10 tcp 80serverfarm ACME_SFARMinserviceLayer 3 Switch Configured with IOS SLB Example
Figure 8 shows a sample configuration with IOS SLB server connections configured as part of a server farm.
Figure 8 Network Configuration for IOS SLB
As shown in the following sample configuration, the example topology has three public web servers and two restricted web servers for privileged clients in subnet 10.4.4.0. 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.
The network configuration to provide the previously described IOS SLB functionality follows:
ip slb probe PROBE2 httprequest method POST url /probe.cgi?allheader HeaderName HeaderValueheader Authorization Basic U2VtaXN3ZWV0OmNoaXBz!ip slb serverfarm PUBLICnat serverpredictor leastconns! First real serverreal 10.1.1.1reassign 4faildetect numconns 16retry 120inservice! Second real serverreal 10.1.1.2reassign 4faildetect numconns 16retry 120inservice! Third real serverreal 10.1.1.3reassign 4faildetect numconns 16retry 120inservice! Probeprobe PROBE2! Restricted web server farmip slb serverfarm RESTRICTEDpredictor leastconns! First real serverreal 10.1.1.20reassign 2faildetect numconns 4retry 20inservice! Second real serverreal 10.1.1.21reassign 2faildetect numconns 4retry 20inservice!! Unrestricted web virtual serverip slb vserver PUBLIC_HTTPvirtual 10.0.0.1 tcp wwwserverfarm PUBLICidle 120delay 5inservice!! Restricted HTTP virtual serverip slb vserver RESTRICTED_HTTPvirtual 10.0.0.1 tcp wwwserverfarm RESTRICTEDclient 10.4.4.0 255.255.255.0sticky 60 group 1idle 120delay 5inservice!! Restricted SSL virtual serverip slb vserver RESTRICTED_SSLvirtual 10.0.0.1 tcp httpsserverfarm RESTRICTEDclient 10.4.4.0 255.255.255.0sticky 60 group 1idle 120delay 5inservice!interface GigabitEthernet1/1switchportswitchport access vlan 3switchport mode accessno ip address!interface FastEthernet2/1switchportswitchport access vlan 2switchport mode accessno ip address!interface FastEthernet2/2switchportswitchport access vlan 2switchport mode accessno ip address!interface FastEthernet2/3switchportswitchport access vlan 2switchport mode accessno ip address!interface Vlan2ip address 10.1.1.100 255.255.255.0!interface Vlan3ip address 40.40.40.1 255.255.255.0IOS SLB with NAT Example
Figure 9 shows a sample configuration with IOS SLB real server connections configured as part of a server farm, focusing on the configuration of the NAT server and address pool of clients.
Figure 9 Sample IOS SLB NAT Topology
The topology in Figure 9 has four web servers, configured as follows:
•
•
Server 1 and Server 2 are load-balanced using Switch A, which is performing server address translation.
Server 3 and Server 4 are load-balanced using Switch B and Switch C. These two switches are performing both server and client address translation since there are multiple paths between the clients and the servers. These switches also must perform server port translation for HTTP packets to and from Server 4.
Switch A Configuration Statements
ip slb serverfarm FARM1! Translate server addressesnat server! Server 1 port 80real 10.1.1.1reassign 2faildetect numconns 4 numclients 2retry 20inservice! Server 2 port 80real 10.2.1.1reassign 2faildetect numconns 4retry 20inservice!ip slb vserver HTTP1! Handle HTTP (port 80) requestsvirtual 128.1.0.1 tcp wwwserverfarm FARM1idle 120delay 5inserviceSwitch B Configuration Statements
ip slb natpool web-clients 128.3.0.1 128.3.0.254! NAT address pool for clientsip slb serverfarm FARM2! Translate server addressesnat server! Translate client addressesnat client web-clients! Server 3 port 80real 10.3.1.1reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8080real 10.4.1.1 port 8080reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8081real 10.4.1.1 port 8081reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8082real 10.4.1.1 port 8082reassign 2faildetect numconns 4retry 20inservice!ip slb vserver HTTP2! Handle HTTP (port 80) requestsvirtual 128.2.0.1 tcp wwwserverfarm FARM2idle 120delay 5inserviceSwitch C Configuration Statements
ip slb natpool web-clients 128.5.0.1 128.5.0.254! NAT address pool for clientsip slb serverfarm FARM2! Translate server addressesnat server! Translate client addressesnat client web-clients! Server 3 port 80real 10.3.1.1reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8080real 10.4.1.1 port 8080reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8081real 10.4.1.1 port 8081reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8082real 10.4.1.1 port 8082reassign 2faildetect numconns 4retry 20inservice!ip slb vserver HTTP2! Handle HTTP (port 80) requestsvirtual 128.4.0.1 tcp wwwserverfarm FARM2idle 120delay 5inserviceIOS SLB with Static NAT Example
The following example shows configuration statements for the following items:
•
•
•
•
ip slb probe PROBE4 dnslookup 13.13.13.13!ip slb serverfarm DNSnat serverprobe PROBE4real 10.0.0.0inservice!ip slb vserver DNSvirtual 10.11.11.11 UDP 0 service per-packetserverfarm DNS!ip slb static nat 10.11.11.11 per-packetreal 10.0.0.0IOS SLB with Stateless Backup Examples
There are several different ways in which you can configure IOS SLB stateless backup. The differences between the configurations depend on the networking capabilities of your load balancing devices, and on the capabilities of the distribution devices that direct client traffic to those load balancing devices.
•
•
•
•
•
This section contains the following examples, illustrating several different IOS SLB stateless backup configurations:
•
•
•
•
Note
Dynamic Routing and Trunking Example
Figure 10 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
•
Figure 10 Stateless Backup with Layer 3 and Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4 numclients 2retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!int Eth1switchportswitchport vlan 1int Eth2ip address 10.10.2.1 255.255.255.0int vlan 1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3router eigrp 666redistribute staticnetwork 10.0.0.0SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!interface GigabitEthernet1no ip addressswitchportswitchport trunk encapsulation islint Eth1switchportswitchport vlan 1int Eth2ip address 10.10.3.1 255.255.255.0int vlan 1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3router eigrp 666redistribute staticnetwork 10.0.0.0Dynamic Routing and No Trunking Example
Figure 11 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
Figure 11 Stateless Backup with Layer 3 and No Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!int Eth1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3int Eth2ip address 10.10.2.1 255.255.255.0router eigrp 666redistribute staticnetwork 10.0.0.0SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!int Eth1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3int Eth2ip address 10.10.3.1 255.255.255.0router eigrp 666redistribute staticnetwork 10.0.0.0Static Routing and Trunking Example
Figure 12 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
•
Figure 12 Stateless Backup with Layer 2 and Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!int Eth1switchportswitchport vlan 1int Eth2ip address 10.10.2.1 255.255.255.0standby ip 10.10.2.100standby priority 10 preempt delay sync 20standby track vlan1standby timers 1 3int vlan 1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!interface GigabitEthernet1no ip addressswitchportswitchport trunk encapsulation islint Eth1switchportswitchport vlan 1int Eth2ip address 10.10.2.2 255.255.255.0standby ip 10.10.2.100standby priority 5 preempt delay sync 20standby track vlan 1standby timers 1 3int vlan 1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3Distribution Device Configuration Statements
int Eth1switchportswitchport distribution vlan 2int Eth2switchportswitchport distribution vlan 2int vlan2ip address 10.10.2.3 255.255.255.0no shutip route 10.10.14.1 255.255.255.255 10.10.2.100Static Routing and No Trunking Example
Figure 13 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
Figure 13 Stateless Backup with Layer 2 and No Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!int Eth1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3int Eth2ip address 10.10.2.1 255.255.255.0standby ip 10.10.2.100standby priority 10 preempt delay sync 20standby track Eth1standby timers 1 3SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER!int Eth1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERstandby track Eth2standby timers 1 3!int Eth2ip address 10.10.2.2 255.255.255.0standby ip 10.10.2.100standby priority 5 preempt delay sync 20standby track Eth1standby timers 1 3Distribution Device Configuration Statements
int Eth1switchportswitchport distribution vlan 2int Eth2switchportswitchport distribution vlan 2int vlan2ip address 10.10.2.3 255.255.255.0no shutip route 10.10.14.1 255.255.255.255 10.10.2.100IOS SLB with Stateful Backup Example
This sample configuration focuses on the IOS SLB real server connections configured as part of a server farm, with real and virtual servers over Fast Ethernet interfaces configured with stateful backup standby connections.
Figure 14 is an example of a stateful backup configuration, using HSRP on both the client and server sides to handle failover. The real servers route outbound flows to 10.10.3.100, which is the HSRP address on the server side interfaces. The client (or access router), routes to the virtual IP address (10.10.10.12) through 10.10.2.100, HSRP address on the client side.
Notice the loopback interfaces configured on both devices for the exchange of these messages. Each IOS SLB should also be given duplicate routes to the other switch loopback address. This configuration allows replication messages to flow despite an interface failure.
Note
Figure 14 IOS SLB Stateful Environment
Switch SLB1 Configuration Statements
ip slb serverfarm SF1nat serverreal 10.10.3.1inservicereal 10.10.3.2inservicereal 10.10.3.3inservice!ip slb vserver VS1virtual 10.10.10.12 tcp telnetserverfarm SF1replicate casa 10.10.99.132 10.10.99.99 1024 password PASSinservice standby virt!interface loopback 1ip address 10.10.99.132 255.255.255.255!interface FastEthernet1ip address 10.10.3.132 255.255.255.0no ip redirectsno ip mroute-cachestandby priority 5 preemptstandby name outstandby ip 10.10.3.100standby track FastEthernet2standby timers 1 3interface FastEthernet2ip address 10.10.2.132 255.255.255.0no ip redirectsstandby priority 5standby name virtstandby ip 10.10.2.100standby timers 1 3Switch SLB2 Configuration Statements
ip slb serverfarm SF1nat serverreal 10.10.3.1inservicereal 10.10.3.2inservicereal 10.10.3.3inservice!ip slb vserver VS1virtual 10.10.10.12 tcp telnetserverfarm SF1replicate casa 10.10.99.99 10.10.99.132 1024 password PASSinservice standby virt!interface loopback 1ip address 10.10.99.99 255.255.255.255!interface FastEthernet2ip address 10.10.2.99 255.255.255.0no ip redirectsno ip route-cacheno ip mroute-cachestandby priority 10 preempt delay sync 20standby name virtstandby ip 10.10.2.100standby track FastEthernet3standby timers 1 3!interface FastEthernet3ip address 10.10.3.99 255.255.255.0no ip redirectsno ip route-cacheno ip mroute-cachestandby priority 10 preempt delay 20standby name outstandby ip 10.10.3.100standby track FastEthernet2standby timers 1 3IOS SLB with Active Standby Example
Figure 15 shows an IOS SLB network configured for active standby, with two IOS SLB devices load-balancing the same virtual IP address while backing up each other. If either device fails, the other takes over its load via normal HSRP failover and IOS SLB stateless redundancy.
Figure 15 IOS SLB Active Standby
The sample network configuration in Figure 15 has the following characteristics:
•
•
•
•
•
•
SLB 1 Configuration Statements
ip slb serverfarm EVENnat serverreal 10.10.3.2reassign 2faildetect numconns 4 numclients 2retry 20inservicereal 10.10.3.3reassign 2faildetect numconns 4retry 20inservice!ip slb serverfarm ODDnat serverreal 10.10.3.2reassign 2faildetect numconns 4retry 20inservicereal 10.10.3.3reassign 2faildetect numconns 4retry 20inservice!-----Same EVEN virtual server as in SLB 2ip slb vserver EVENvirtual 10.10.10.12 tcp wwwserverfarm EVENclient 0.0.0.0 0.0.0.1idle 120delay 5!-----See standby name in Ethernet 3/3 belowinservice standby STANDBY_EVEN!-----Same ODD virtual server as in SLB 2ip slb vserver ODDvirtual 10.10.10.12 tcp wwwserverfarm ODDclient 0.0.0.1 0.0.0.1idle 120delay 5!-----See standby name in Ethernet 3/2 belowinservice standby STANDBY_ODD!interface Ethernet3/2ip address 10.10.5.132 255.255.255.0standby priority 20 preempt delay sync 20!-----See standby name in SLB 2, Ethernet 3/5standby name STANDBY_ODDstandby ip 10.10.5.100standby track Ethernet3/3standby timers 1 3!interface Ethernet3/3ip address 10.10.2.132 255.255.255.0standby priority 10!-----See standby name in SLB 2, Ethernet 3/1standby name STANDBY_EVENstandby ip 10.10.2.100standby track Ethernet3/2standby timers 1 3SLB 2 Configuration Statements
ip slb serverfarm EVENnat serverreal 10.10.3.4reassign 2faildetect numconns 4retry 20inservicereal 10.10.3.5reassign 2faildetect numconns 4retry 20inservice!ip slb serverfarm ODDnat serverreal 10.10.3.4reassign 2faildetect numconns 4retry 20inservicereal 10.10.3.5reassign 2faildetect numconns 4retry 20inservice!-----Same EVEN virtual server as in SLB 1ip slb vserver EVENvirtual 10.10.10.12 tcp wwwserverfarm EVENclient 0.0.0.0 0.0.0.1idle 120delay 5!-----See standby name in Ethernet 3/1 belowinservice standby STANDBY_EVEN!-----Same ODD virtual server as in SLB 1ip slb vserver ODDvirtual 10.10.10.12 tcp wwwserverfarm ODDclient 0.0.0.1 0.0.0.1idle 120delay 5!-----See standby name in Ethernet 3/5 belowinservice standby STANDBY_ODD!interface Ethernet3/1ip address 10.10.2.128 255.255.255.0standby priority 20 preempt delay sync 20!-----See standby name in SLB 1, Ethernet 3/3standby name STANDBY_EVENstandby ip 10.10.2.100standby track Ethernet3/5standby timers 1 3!interface Ethernet3/5ip address 10.10.5.128 255.255.255.0standby priority 10 preempt delay sync 20!-----See standby name in SLB 1, Ethernet 3/2standby name STANDBY_ODDstandby ip 10.10.5.100standby track Ethernet3/1standby timers 1 3Access Router Configuration Statements
interface Ethernet0/0ip address 10.10.5.183 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cache!interface Ethernet0/1ip address 10.10.2.183 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cache!interface Ethernet0/2ip address 10.10.6.183 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cacheip policy route-map virts!access-list 100 permit ip 0.0.0.1 255.255.255.254 host 10.10.10.12access-list 101 permit ip 0.0.0.0 255.255.255.254 host 10.10.10.12route-map virts permit 10match ip address 100set ip next-hop 10.10.5.100!route-map virts permit 15match ip address 101set ip next-hop 10.10.2.100IOS SLB with Redistribution of Static Routes Example
Figure 16 shows an IOS SLB network configured to distribute static routes to a virtual server's IP address. The route to the address is added to the routing table as static if you advertise the address when you bring the virtual server into service (using the inservice command). See the description of the advertise command in the "Command Reference" section for more details about advertising virtual server IP addresses.
Because the routing configuration varies from protocol to protocol, sample configurations for several different routing protocols are given.
Figure 16 IOS SLB Redistribution of Static Routes
Routing Information Protocol (RIP)
Following is the RIP static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router ripredistribute staticnetwork 10.0.0.0network 8.0.0.0Following is the RIP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router ripnetwork 10.0.0.0network 8.0.0.0Open Shortest Path First (OSPF)
Following is the OSPF static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router ospf 1redistribute static subnetsnetwork 10.10.6.217 0.0.0.0 area 0network 8.8.8.0 0.0.0.255 area 0Following is the OSPF static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router ospf 1network 10.10.6.2 0.0.0.0 area 0network 8.8.8.0 0.0.0.255 area 0Interior Gateway Routing Protocol (IGRP)
Following is the IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router igrp 1redistribute connectedredistribute staticnetwork 8.0.0.0network 10.0.0.0Following is the IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router igrp 1network 8.0.0.0network 10.0.0.0Enhanced Interior Gateway Routing Protocol (Enhanced IGRP)
Following is the Enhanced IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router eigrp 666redistribute staticnetwork 10.0.0.0network 8.0.0.0Following is the Enhanced IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router eigrp 666network 10.0.0.0network 8.0.0.0IOS SLB with WAP and UDP Load Balancing Examples
Figure 17 shows an IOS SLB network configured to balance WAP flows. In this example:
•
•
•
Figure 17 IOS SLB with WAP Load Balancing
There are two ways to configure IOS SLB load balancing for WAP:
•
•
WAP Load Balancing Example
The following example shows the configuration for the IOS SLB device shown in Figure 17, which balances WAP flows on UDP port 9201 (WSP/WTP/UDP):
ip slb probe PROBE3 wspurl http://localhost/test.txt!ip slb serverfarm WAPFARMnat serverreal 10.10.2.1inservicereal 10.10.2.2inservicereal 10.10.2.3inserviceprobe PROBE3!ip slb vserver VSERVERvirtual 10.10.1.1 udp 9201serverfarm WAPFARMidle 3000inserviceUDP Load Balancing Example
The following example shows the configuration for the IOS SLB device shown in Figure 17, which balances WAP flows on UDP port 9203 (WSP/WTP/WTLS/UDP):
ip slb probe PROBE1 ping!ip slb serverfarm WAPFARMnat serverreal 10.10.2.1inservicereal 10.10.2.2inservicereal 10.10.2.3inserviceprobe PROBE1!ip slb vserver VSERVERvirtual 10.10.1.1 udp 9203serverfarm WAPFARMidle 3000inserviceIOS SLB with Route Health Injection Examples
This section contains the following examples, illustrating several different IOS SLB route health injection configurations:
•
•
•
Example with Two Distributed Sites with One Web Server Each
Figure 18 shows an IOS SLB network configured with route health injection with the following characteristics:
•
•
•
Figure 18 Two Distributed Sites with One Web Server Each
When both web servers in Figure 18 are operational, the client router receives the host route from both IOS SLB devices.
If Web Server A fails, the virtual server for the virtual IP address on SLB A enters FAILED state and stops advertising the host route for the virtual IP address. The client router then begins using the route to SLB B.
When Web Server A is again available, the virtual server again advertises the host route for the virtual IP address, and the client router begins using SLB A.
Example with Two Distributed Sites with Two Web Servers Each
Figure 19 shows an IOS SLB network configured with route health injection with the following characteristics:
•
•
•
Figure 19 Two Distributed Sites with Two Web Servers Each
When all web servers in Figure 19 are operational, the client router receives the host route from both IOS SLB devices.
If one web server in either server farm fails, the route continues to be advertised by the given IOS SLB device.
If both Web Server A1 and Web Server A2 fail, the virtual server for the virtual IP address on SLB A enters FAILED state and stops advertising the host route for the virtual IP address. The client router then begins using the route to SLB B.
When either Web Server A1 or Web Server A2 is again available, the virtual server again advertises the host route for the virtual IP address, and the client router begins using SLB A.
Example with Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each
Figure 20 shows an IOS SLB network configured with route health injection with the following characteristics:
•
•
•
•
Figure 20 Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each
When both web servers in Figure 20 are operational, the client router receives the host route from both SLB A Primary and SLB B Primary.
If SLB A Primary fails, SLB A Backup begins advertising the host route to the virtual IP address. If SLB A Backup also fails, the virtual server for the virtual IP address on SLB A Primary and SLB A Backup enters FAILED state and stops advertising the host route for the virtual IP address. The client router then begins using the route to SLB B Primary (or to SLB B Backup, if SLB B Primary is not available).
When either SLB A Primary or SLB A Backup is again available, the virtual server again advertises the host route for the virtual IP address, and the client router begins using SLB A Primary or SLB A Backup.
IOS SLB with GPRS Load Balancing Example
Figure 21 shows a typical GPRS load-balancing configuration. In this configuration:
•
•
•
•
•
Figure 21 IOS SLB with GPRS Load Balancing
Following are the configuration statements for the configuration shown in Figure 21:
•
•
•
•
For more detailed GGSN configuration examples, refer to the Cisco IOS Mobile Wireless Configuration Guide.
IOS SLB Configuration Statements
hostname GTP_SLB!ip domain-name gprs.com!ip slb serverfarm GPRSreal 192.168.1.1weight 1faildetect numconns 1 numclients 1inservice!real 192.168.2.2weight 1faildetect numconns 1 numclients 1inservice!real 192.168.3.3weight 1faildetect numconns 1 numclients 1inservice!ip slb vserver FOR_GPRSvirtual 10.10.10.10 udp 3386 service gtpserverfarm GPRSinservice!ip slb dfp password Password1 0agent 10.1.1.201 1111 30 0 10agent 10.1.1.202 1111 30 0 10agent 10.1.1.203 1111 30 0 10!interface FastEthernet1/0description TO SERVERFARM GPRSip address 10.1.1.100 255.255.255.0no ip redirectsduplex half!interface FastEthernet3/0description TO SGSNip address 10.2.1.100 255.255.255.0no ip mroute-cacheduplex half!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0ip route 192.168.1.1 255.255.255.255 10.1.1.201ip route 192.168.2.2 255.255.255.255 10.1.1.202ip route 192.168.3.3 255.255.255.255 10.1.1.203GGSN1 Configuration Statements
service gprs ggsn!hostname GGSN1!ip dfp agent gprsport 1111password Password1 0inservice!ip domain-name gprs.com!interface loopback 1description LOOPBACK SAME AS IOS SLB VSERVER ADDRESSip address 10.10.10.10 255.255.255.255no ip route-cacheno ip mroute-cache!interface FastEthernet1/0description TO SLBip address 10.1.1.201 255.255.255.0ip directed-broadcastno ip mroute-cacheduplex half!interface Virtual-Template1description GTP VIRTUAL TEMPLATEip address 192.168.1.1 255.255.255.0encapsulation gtpgprs access-point-list gprs1!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0!gprs access-point-list gprs1access-point 1access-point-name gprs.company.comaccess-mode non-transparentip-address-pool dhcp-proxy-clientdhcp-server 10.100.0.5 10.100.0.6dhcp-gateway-address 10.27.3.1exit!gprs maximum-pdp-context-allowed 45000gprs qos map canonical-qosgprs gtp path-echo-interval 0gprs dfp max-weight 32gprs slb cef 10.10.10.10GGSN2 Configuration Statements
service gprs ggsn!hostname GGSN2!ip dfp agent gprsport 1111password Password1 0inservice!ip domain-name gprs.com!interface loopback 1description LOOPBACK SAME AS IOS SLB VSERVER ADDRESSip address 10.10.10.10 255.255.255.255no ip route-cacheno ip mroute-cache!interface FastEthernet1/0description TO SLBip address 10.1.1.202 255.255.255.0ip directed-broadcastno ip mroute-cacheduplex half!interface Virtual-Template1description GTP VIRTUAL TEMPLATEip address 192.168.2.2 255.255.255.0encapsulation gtpgprs access-point-list gprs1!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0!gprs access-point-list gprs1access-point 1access-point-name gprs.company.comaccess-mode non-transparentip-address-pool dhcp-proxy-clientdhcp-server 10.100.0.5 10.100.0.6dhcp-gateway-address 10.27.3.1exit!gprs maximum-pdp-context-allowed 45000gprs qos map canonical-qosgprs gtp path-echo-interval 0gprs dfp max-weight 32gprs slb cef 10.10.10.10GGSN3 Configuration Statements
service gprs ggsn!hostname GGSN3!ip dfp agent gprsport 1111password Password1 0inservice!ip domain-name gprs.com!interface loopback 1description LOOPBACK SAME AS IOS SLB VSERVER ADDRESSip address 10.10.10.10 255.255.255.255no ip route-cacheno ip mroute-cache!interface FastEthernet1/0description TO SLBip address 10.1.1.203 255.255.255.0ip directed-broadcastno ip mroute-cacheduplex half!interface Virtual-Template1description GTP VIRTUAL TEMPLATEip address 192.168.3.3 255.255.255.0encapsulation gtpgprs access-point-list gprs1!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0!gprs access-point-list gprs1access-point 1access-point-name gprs.company.comaccess-mode non-transparentip-address-pool dhcp-proxy-clientdhcp-server 10.100.0.5 10.100.0.6dhcp-gateway-address 10.27.3.1exit!gprs maximum-pdp-context-allowed 45000gprs qos map canonical-qosgprs gtp path-echo-interval 0gprs dfp max-weight 32gprs slb cef 10.10.10.10IOS SLB with GPRS Load Balancing and NAT Example
The following example uses the same basic configuration as in the "IOS SLB with GPRS Load Balancing Example" section, including the network shown in Figure 21, but with the addition of NAT:
•
•
•
•
For more detailed GGSN configuration examples, refer to the Cisco IOS Mobile Wireless Configuration Guide.
IOS SLB Configuration Statements
hostname GTP_SLB!ip domain-name gprs.com!ip slb serverfarm GPRSnat serverreal 192.168.1.1weight 1faildetect numconns 1 numclients 1inservice!real 192.168.2.2weight 1faildetect numconns 1 numclients 1inservice!real 192.168.3.3weight 1faildetect numconns 1 numclients 1inservice!ip slb vserver FOR_GPRSvirtual 10.10.10.10 udp 3386 service gtpserverfarm GPRSinservice!ip slb dfp password Password1 0agent 10.1.1.201 1111 30 0 10agent 10.1.1.202 1111 30 0 10agent 10.1.1.203 1111 30 0 10!interface FastEthernet1/0description TO SERVERFARM GPRSip address 10.1.1.100 255.255.255.0no ip redirectsduplex half!interface FastEthernet3/0description TO SGSNip address 10.2.1.100 255.255.255.0no ip mroute-cacheduplex half!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0ip route 192.168.1.1 255.255.255.255 10.1.1.201ip route 192.168.2.2 255.255.255.255 10.1.1.202ip route 192.168.3.3 255.255.255.255 10.1.1.203GGSN1 Configuration Statements
service gprs ggsn!hostname GGSN1!ip dfp agent gprsport 1111password Password1 0inservice!ip domain-name gprs.com!interface FastEthernet1/0description TO SLBip address 10.1.1.201 255.255.255.0ip directed-broadcastno ip mroute-cacheduplex halfinterface Virtual-Template1description GTP VIRTUAL TEMPLATEip address 192.168.1.1 255.255.255.0encapsulation gtpgprs access-point-list gprs1!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0!gprs access-point-list gprs1access-point 1access-point-name gprs.company.comaccess-mode non-transparentip-address-pool dhcp-proxy-clientdhcp-server 10.100.0.5 10.100.0.6dhcp-gateway-address 10.27.3.1exit!gprs maximum-pdp-context-allowed 45000gprs qos map canonical-qosgprs gtp path-echo-interval 0gprs dfp max-weight 32GGSN2 Configuration Statements
service gprs ggsn!hostname GGSN2!ip dfp agent gprsport 1111password Password1 0inservice!ip domain-name gprs.com!interface FastEthernet1/0description TO SLBip address 10.1.1.202 255.255.255.0ip directed-broadcastno ip mroute-cacheduplex halfinterface Virtual-Template1description GTP VIRTUAL TEMPLATEip address 192.168.2.2 255.255.255.0encapsulation gtpgprs access-point-list gprs1!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0!gprs access-point-list gprs1access-point 1access-point-name gprs.company.comaccess-mode non-transparentip-address-pool dhcp-proxy-clientdhcp-server 10.100.0.5 10.100.0.6dhcp-gateway-address 10.27.3.1exit!gprs maximum-pdp-context-allowed 45000gprs qos map canonical-qosgprs gtp path-echo-interval 0gprs dfp max-weight 32GGSN3 Configuration Statements
service gprs ggsn!hostname GGSN3!ip dfp agent gprsport 1111password Password1 0inservice!ip domain-name gprs.com!interface FastEthernet1/0description TO SLBip address 10.1.1.203 255.255.255.0ip directed-broadcastno ip mroute-cacheduplex half!interface Virtual-Template1description GTP VIRTUAL TEMPLATEip address 192.168.3.3 255.255.255.0encapsulation gtpgprs access-point-list gprs1!ip route 10.111.111.111 255.255.255.255 FastEthernet1/0!gprs access-point-list gprs1access-point 1access-point-name gprs.company.comaccess-mode non-transparentip-address-pool dhcp-proxy-clientdhcp-server 10.100.0.5 10.100.0.6dhcp-gateway-address 10.27.3.1exit!gprs maximum-pdp-context-allowed 45000gprs qos map canonical-qosgprs gtp path-echo-interval 0gprs dfp max-weight 32IOS SLB with VPN Server Load Balancing Example
Figure 22 shows a typical VPN server load-balancing configuration. In this configuration:
•
•
•
•
Figure 22 IOS SLB with VPN Server Load Balancing
Following are the IOS SLB configuration statements for the configuration shown in Figure 22:
ip slb serverfarm VPNnat serverreal 20.20.20.10inservicereal 20.20.20.20inservicefailaction purge!ip slb vserver ESPvirtual 10.10.1.1 ESPserverfarm VPNsticky 3600 group 69inservice!ip slb vserver UDPvirtual 10.10.1.1 UDP isakmpserverfarm VPNsticky 3600 group 69inserviceIOS SLB with RADIUS Load Balancing for a GPRS Network Example
Figure 23 shows a typical IOS SLB RADIUS load-balancing configuration for a GPRS network. In this configuration:
•
