Guest

Cisco IOS Software Releases 12.2 Special and Early Deployments

IOS Server Load Balancing, 12.2(14)ZA5

  • Viewing Options

  • PDF (2.5 MB)
  • Feedback
IOS Server Load Balancing

Table Of Contents

IOS Server Load Balancing

Overview of the IOS SLB Feature

Features

IOS SLB Features

Routing Features

Security Features

Server Failure Detection and Recovery Features

Protocol Support Features

Redundancy Features

Exchange Director Features

Benefits

Restrictions

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

Configuring Required and Optional IOS SLB Functions

Configuring a Server Farm and Real Server

Configuring a Virtual Server

Verifying the Virtual Server

Verifying the Server Farm

Verifying the Clients

Verifying IOS SLB Connectivity

Configuring Firewall Load Balancing

Configuring the Firewall Farm

Verifying the Firewall Farm

Verifying Firewall Connectivity

Configuring Probes

Configuring Custom UDP Probes

Configuring DNS Probes

Configuring HTTP Probes

Configuring Ping Probes

Configuring TCP Probes

Configuring WSP Probes

Associating the Probe

Verifying the Probe

Configuring DFP

GPRS Load Balancing Configuration Task List

Configuring a GSN Idle Timer

RADIUS Load Balancing Configuration Task List

Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing

Exchange Director for CMX Configuration Task List

RADIUS Configuration for the Exchange Director

Firewall Configuration for the Exchange Director

VPN Server Load Balancing Configuration Task List

Home Agent Director Configuration Task List

Configuring NAT

Configuring Static NAT

Stateless Backup Configuration Task List

Verifying the Stateless Backup Configuration

Stateful Backup of Redundant Route Processors Configuration Task List

Configuring Database Entries

Configuring Buffers for the Fragment Database

Clearing Databases and Counters

Configuring Wildcard Searches

Purging and Reassigning Connections

Disabling Automatic Server Failure Detection

Monitoring and Maintaining the IOS SLB Feature

Configuration Examples

Basic IOS SLB Network Configuration Example

Server Farm Configuration

Virtual Server Configuration

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 Probes Example

IOS SLB with Routed Probe Example

Layer 3 Switch Configured with IOS SLB Example

IOS SLB with NAT 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 Stateful Backup of Redundant Route Processors Example

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

WAP Load Balancing Example

UDP Load Balancing Example

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 GPRS Load Balancing, NAT, and GTP Cause Code Inspection Example

IOS SLB 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 Home Agent Director Example

IOS SLB with Sticky Connections Example

IOS SLB with Transparent Web Cache Load Balancing

Command Reference

access (firewall farm)

access (virtual server)

address (custom UDP probe)

address (DNS probe)

address (HTTP probe)

address (ping probe)

address (TCP probe)

address (WSP probe)

advertise

agent (DFP)

bindid

clear ip slb connections

clear ip slb counters

clear ip slb sessions

clear ip slb sticky radius

client (virtual server)

credentials

debug gprs dfp

debug ip slb

delay (firewall farm TCP protocol)

delay (virtual server)

expect

failaction (firewall farm)

failaction (server farm)

faildetect (DNS probe)

faildetect (ping probe)

faildetect inband (real server)

faildetect numconns (real server)

hand-off radius

header

idle (firewall farm datagram protocol)

idle (firewall farm TCP protocol)

idle (virtual server)

inservice (firewall farm)

inservice (firewall farm real server)

inservice (server farm real server)

inservice (server farm virtual server)

interval (custom UDP probe)

interval (DNS probe)

interval (HTTP probe)

interval (ping probe)

interval (TCP probe)

interval (WSP probe)

ip slb dfp

ip slb entries

ip slb firewallfarm

ip slb maxbuffers frag

ip slb natpool

ip slb probe custom udp

ip slb probe dns

ip slb probe http

ip slb probe ping

ip slb probe tcp

ip slb probe wsp

ip slb replicate slave rate

ip slb route

ip slb serverfarm

ip slb static

ip slb timers gtp gsn

ip slb vserver

lookup

maxclients

maxconns (firewall farm datagram protocol)

maxconns (firewall farm TCP protocol)

maxconns (server farm)

mls aging slb normal

mls aging slb process

mls ip slb search wildcard

nat

port (custom UDP probe)

port (HTTP probe)

port (TCP probe)

predictor (server farm)

predictor hash address (firewall farm)

probe (firewall farm real server)

probe (server farm)

protocol datagram

protocol tcp

purge radius framed-ip acct on-off (virtual server)

purge radius framed-ip acct stop (virtual server)

real (firewall farm)

real (server farm)

real (static NAT)

reassign

replicate casa (firewall farm)

replicate casa (virtual server)

replicate interval (firewall farm)

replicate interval (virtual server)

replicate slave (firewall farm)

replicate slave (virtual server)

request (custom UDP probe)

request (HTTP probe)

response

retry

serverfarm

show ip slb conns

show ip slb dfp

show ip slb firewallfarm

show ip slb fragments

show ip slb gtp

show ip slb natpool

show ip slb probe

show ip slb reals

show ip slb replicate

show ip slb serverfarms

show ip slb sessions

show ip slb static

show ip slb stats

show ip slb sticky

show ip slb vserver

snmp-server enable traps slb

sticky (firewall farm datagram protocol)

sticky (firewall farm TCP protocol)

sticky (virtual server)

synguard (virtual server)

url (WSP probe)

virtual (virtual server)

weight (firewall farm real server)

weight (server farm)

FAQ (Frequently Asked Questions)

Glossary


IOS Server Load Balancing


Feature History

Release
Modification

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)

Cisco 7200 series routers

The following functions were provided:

Algorithms for Server Load Balancing

Automatic Server Failure Detection

Automatic Unfail

Bind ID Support

Client-Assigned Load Balancing

Delayed Removal of TCP Connection Context

Dynamic Feedback Protocol for IOS SLB

Maximum Connections

Port-Bound Servers

Slow Start

Sticky Connections

SynGuard

TCP Session Reassignment

12.1(1)E

The following functions were added:

Alternate IP Addresses

Server NAT

Stateless Backup

Transparent Web Cache Load Balancing

12.1(2)E

The following functions were added:

Audio and Video Load Balancing

Content Flow Monitor Support

Client NAT

Probes—HTTP Probes

Stateful Backup

12.1(3a)E

The following functions were added:

Firewall Load Balancing

Probes—HTTP and Ping Probes

Protocol Support

Active Standby

WAP Load Balancing

12.1(5a)E

The following functions were added:

Avoiding Attacks on Server Farms and Firewall Farms

Probes—HTTP, Ping, and WSP Probes

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:

Cisco 7100 series routers

The following functions were added:

Multiple Firewall Farm Support

Route Health Injection

12.1(8a)E

Support for the following platform was added:

MSFC2 and Supervisor Engine 2 for Cisco Catalyst 6500 family switches (including the Catalyst 6506, Catalyst 6509, and Catalyst 6513)

The following functions were added:

Backup Server Farms

DFP Agent Subsystem Support

12.1(9)E

The following functions were added:

GPRS Load Balancing—Support for GPRS Tunneling Protocol (GTP) v0

12.1(11b)E

Support for the following platforms was added:

MSFC2, Supervisor Engine 1, and Supervisor Engine 2 for the Cisco 7600 Internet routers (including the Cisco 7603, Cisco 7606, and Cisco 7609)

The following functions were added:

Static NAT

Probes—DNS, HTTP, Ping, TCP, and WSP Probes

RADIUS Load Balancing—General packet radio service (GPRS) networks

VPN Server Load Balancing

12.1(12c)E

The following functions were added:

Probes—Routed Probes

RADIUS Load Balancing—CDMA2000 and Multiple Service Gateway Server Farms

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:

Cisco 7100 series routers

MSFC2, Supervisor Engine 1, and Supervisor Engine 2 for Cisco Catalyst 6500 family switches (including the Catalyst 6506, Catalyst 6509, and Catalyst 6513)

MSFC2, Supervisor Engine 1, and Supervisor Engine 2 for the Cisco 7600 Internet routers (including the Cisco 7603, Cisco 7606, and Cisco 7609)

12.1(13)E3

Support for the following platforms was added:

Cisco 7100 series routers

MSFC2, Supervisor Engine 1, and Supervisor Engine 2 for Cisco Catalyst 6500 family switches (including the Catalyst 6506, Catalyst 6509, and Catalyst 6513)

MSFC2, Supervisor Engine 1, and Supervisor Engine 2 for the Cisco 7600 Internet routers (including the Cisco 7603, Cisco 7606, and Cisco 7609)

The following functions were added:

GPRS Load Balancing—Support for GTP v0 and GTP v1

GPRS Load Balancing with GTP Cause Code Inspection

Probes—DNS, HTTP, Ping, TCP, Custom UDP, and WSP Probes

12.2(14)ZA2

The following function was added:

Home Agent Director

12.2(14)ZA4

The following functions were added:

Automatic Server Failure Detection—Disabling Automatic Server Failure Detection

12.2(14)ZA5

The following functions were added:

Exchange Director Features

Flow Persistence

Stateful Backup of Redundant Route Processors


This document describes the Cisco IOS Server Load Balancing (IOS SLB) feature in Cisco IOS Release 12.2(14)ZA5. It includes the following sections:

Overview of the IOS SLB Feature

Features

Benefits

Restrictions

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

Monitoring and Maintaining the IOS SLB Feature

Configuration Examples

Command Reference

FAQ (Frequently Asked Questions)

Glossary

Overview of the IOS SLB Feature

The IOS SLB feature is an IOS-based solution that provides load balancing for a variety of networked devices and services, including:

Application servers, such as Hypertext Transfer Protocol (HTTP), Telnet, File Transfer Protocol (FTP), and so on

Firewalls

Service nodes, such as authentication, authorization, and accounting (AAA) servers, web caches, and so on

In addition, the IOS SLB Exchange Director enables advanced load-balancing routing capabilities for the following additional service nodes:

Cisco Mobile Exchange (CMX) components:

Cisco Content Services Gateways (CSGs)

Cisco gateway GPRS support nodes (GGSNs)

Cisco Service Selection Gateways (SSGs)

Cisco Home Agents

Other components for mobile, Public Wireless LAN (PWLAN), and Service Provider networks:

Wireless Application Protocol (WAP) gateways

Protocol optimization gateways

Non-Cisco GGSNs and Home Agents

Other RADIUS-aware flow gateways. These gateways are proxies or routing nodes that receive RADIUS Authorization and Accounting requests for users that route flows through the gateways. The Exchange Director binds the RADIUS and data flows to the same gateway, ensuring that the gateway receives a complete and consistent view of the network activity for the user.

The Exchange Director also adds the following features:

Enhanced failover capabilities for single-chassis failover within the CMX for Catalyst 6500 Family Switches and Cisco 7600 Internet Routers. When used with Route Processor Redundancy Plus (RPR+), IOS SLB stateful backup for redundant route processors provides full IOS SLB stateful failover for these platforms.

Flow persistence, which provides intelligent return routing of load-balanced IP flows.

Figure 1 illustrates a logical view of a simple IOS SLB network.

Figure 1 Logical View of IOS SLB

Features

This section describes the general features provided by IOS SLB, as well as the specific features provided by the Exchange Director for Cisco Mobile Exchange (CMX).


Note Some IOS SLB features are specific to a single platform and are not described in this feature document. For information about those features, refer to the appropriate platform-specific documentation.


IOS SLB Features

Exchange Director Features

IOS SLB Features

IOS SLB provides the following features:

Routing Features

Security Features

Server Failure Detection and Recovery Features

Protocol Support Features

Redundancy Features

Routing Features

IOS SLB provides the following routing features:

Algorithms for Server Load Balancing

Bind ID Support

Client-Assigned Load Balancing

Content Flow Monitor Support

Delayed Removal of TCP Connection Context

Firewall Load Balancing

Maximum Connections

Multiple Firewall Farm Support

Network Address Translation (NAT)

Port-Bound Servers

Route Health Injection

Sticky Connections

TCP Session Reassignment

Transparent Web Cache Load Balancing

Algorithms for Server Load Balancing

IOS SLB provides the following load-balancing algorithms:

Weighted Round Robin

Weighted Least Connections

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 = 3, ServerB with = 1, and ServerC with = 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 Assigning a weight of n=1 to all of the servers in the server farm configures the IOS SLB device to use a simple round robin algorithm.

General packet radio service (GPRS) load balancing without GPRS Tunneling Protocol (GTP) cause code inspection enabled 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 without GTP cause code inspection enabled, but you cannot place the virtual server INSERVICE. If you try to do so, IOS SLB issues an error message.

The Home Agent Director requires the weighted round robin algorithm. A server farm that uses weighted least connections can be bound to a Home Agent Director virtual server, 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 = 3, ServerB with = 1, and ServerC with = 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 Assigning a weight of n=1 to all of the servers in the server farm configures the IOS SLB device to use a simple least-connection algorithm.

GPRS load balancing without GTP cause code inspection enabled does not support the weighted least connections algorithm.

GPRS load balancing with GTP cause code inspection enabled does support the weighted least connections algorithm.

The Home Agent Director does not support the weighted least connections algorithm.


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 and the Home Agent Director do 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 and the Home Agent Director do 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.

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 IOS SLB firewall load balancing must examine incoming packets and perform route lookup. On Catalyst 6500 Family Switches, some additional packets might need to be examined. Firewall load balancing impacts internal (secure) side routing performance and must be considered in the complete design.


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:

Connections initiated from either side of the firewall farm are load-balanced.

The load is balanced among a set of firewalls—the firewall farm.

All packets for a connection travel through the same firewall. Subsequent connections can be "sticky," ensuring that they are assigned to the same firewall.

Probes are used to detect and recover from firewall failures.

Redundancy is provided. Hot Standby Router Protocol (HSRP), stateless backup, and stateful backup are all supported.

Multiple interface types and routing protocols are supported, enabling the external (Internet side) load-balancing device to act as an access router.

Proxy firewalls are supported.

Maximum Connections

IOS SLB allows you to configure maximum connections for server and firewall load balancing.

For server load balancing, you can configure a limit on the number of active connections that a real server is assigned. If the maximum number of connections is reached for a real server, IOS SLB automatically switches all further connection requests to other servers until the connection number drops below the specified limit.

For firewall load balancing, you can configure a limit on the number of active TCP or UDP connections that a firewall farm is assigned. If the maximum number of connections is reached for the firewall farm, new connections are dropped until the connection number drops below the specified limit.

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

Dispatched Mode

Directed Mode

Server NAT

Client NAT

Static NAT

Server Port Translation

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 In both dispatched and directed modes, IOS SLB must track connections. Therefore, you must design your network so that there is no alternate network path from the real servers to the client that bypasses the load-balancing device.


Dispatched Mode

In dispatched mode, the virtual server address is known to the real servers; you must configure the virtual server IP address as a loopback address, or secondary IP address, on each of the real servers. IOS SLB redirects packets to the real servers at the media access control (MAC) layer. Since the virtual server IP address is not modified in dispatched mode, the real servers must be Layer 2-adjacent to IOS SLB, or intervening routers might not be able to route to the chosen real server.

For Catalyst 6500 Family Switches, dispatched mode with hardware data packet acceleration generally yields better performance than directed mode.

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:

"Server NAT" section

"Client NAT" section

"Static NAT" section

"Server Port Translation" section


Note You can use both server NAT and client NAT for the same connection.

IOS SLB does not support FTP or firewall load balancing in directed mode. Therefore, FTP and firewall 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:

Servers can be many hops away from the load-balancing device.

Intervening routers can route to them without requiring tunnelling.

Loopback and secondary interfaces are not required on the real server.

The real server need not be Layer 2-adjacent to IOS SLB.

The real server can initiate a connection to a virtual server on the same IOS SLB device.

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 Static NAT is not required for DNS, but it is recommended, because it hides your real server IP addresses from the outside world.


IOS SLB supports the following static NAT options, configured using the ip slb static command:

Static NAT with dropped connections—The real server is configured to have its packets dropped by IOS SLB, if the packets do not correspond to existing connections. This option is usually used in conjunction with the subnet mask or port number option on the real command in static NAT configuration mode, such that IOS SLB builds connections to the specified subnet or port, and drops all other connections from the real server.

Static NAT with a specified address—The real server is configured to use a user-specified virtual IP address when translating addresses.

Static NAT with per-packet server load balancing—The real server is configured such that IOS SLB is not to maintain connection state for packets originating from the real server. That is, IOS SLB is to use server NAT to redirect packets originating from the real server. Per-packet server load balancing is especially useful for DNS load balancing. IOS SLB uses DNS probes to detect failures in the per-packet server load-balancing environment.

Static NAT with sticky connections—The real server is configured such that IOS SLB is not to maintain connection state for packets originating from the real server, unless those packets match a sticky object:

If IOS SLB finds a matching sticky object, it builds the connection.

If IOS SLB does not find a matching sticky object, it forwards the packets without building the connection.

IOS SLB uses the following logic when handling a packet from a real server:


Step 1 Does the packet match a real server?

If no, IOS SLB has no interest in the packet.

If yes, continue.

Step 2 Does the packet match an existing connection?

If yes, IOS SLB uses NAT to redirect the packet, in accordance with the connection control block.

If no, continue.

Step 3 Is the real server configured to use static NAT?

If no, IOS SLB handles the packet as usual. This functionality is also called static NAT pass-through.

If yes, continue.

Step 4 Is the real server configured to have its packets dropped by IOS SLB, if the packets do not correspond to existing connections?

If yes, IOS SLB drops the packet.

If no, continue.

Step 5 Is the real server configured for per-packet server load balancing?

If yes, IOS SLB uses NAT to redirect the packet.

If no, continue.

Step 6 Is the real server configured to maintain connection state for sticky connections?

If no, IOS SLB builds the connection.

If yes, IOS SLB searches for a matching sticky object. Continue.

Step 7 Can IOS SLB find a matching sticky object?

If no, IOS SLB drops the packet.

If yes, IOS SLB builds the connection.


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

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.

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:

The real server is in either OPERATIONAL or MAXCONNS_THROTTLED state.

The sticky timer is defined on a virtual server or on a firewall farm.

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 and the Home Agent Director do not support sticky connections.

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.

Security Features

IOS SLB provides the following security features:

Alternate IP Addresses

Avoiding Attacks on Server Farms and Firewall Farms

Slow Start

SynGuard

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:

Use any of the interface addresses to telnet to the load-balancing device.

Define a secondary IP address to telnet to the load-balancing device.

This function is similar to that provided by the LocalDirector (LD) Alias command.

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:

Configure real servers on a private network to keep clients from connecting directly to them. This configuration ensures that the clients must go through IOS SLB to get to the real servers.

Configure input access lists on the access router or on the IOS SLB device to deny flows from the outside network aimed directly at the interfaces on the IOS SLB device. That is, deny all direct flows from unexpected addresses.

To protect against attackers trying to direct flows to real or nonexistent IP addresses in the firewall subnet, configure the firewalls in a private network.

Configure firewalls to deny all unexpected flows targeted at the firewalls, especially flows originating from the external network.

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 and the Home Agent Director do not support slow start.

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 and the Home Agent Director do not support SynGuard.

Server Failure Detection and Recovery Features

IOS SLB provides the following server failure detection and recovery features:

Automatic Server Failure Detection

Automatic Unfail

Backup Server Farms

DFP Agent Subsystem Support

Dynamic Feedback Protocol for IOS SLB

Probes

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.

For RADIUS load balancing, the IOS SLB performs automatic server failure detection when a RADIUS request is not answered by the real server.

If you have configured all-port virtual servers (that is, virtual servers that accept flows destined for all ports except GTP ports), flows can be passed to servers for which no application port exists. When the servers reject these flows, IOS SLB might fail the servers and remove them from load balancing. This situation can also occur in slow-to-respond AAA servers in RADIUS load-balancing environments. To prevent this situation, you can disable automatic server failure detection.


Note If you disable automatic server failure detection using the no faildetect inband command, Cisco strongly recommends that you configure one or more probes.

If you specify the no faildetect inband command, the faildetect numconns command is ignored, if specified.


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. The unsuccessful connection must have experienced at least one retry, otherwise the next qualifying connection would also be sent to that failed server.

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:

A server farm can act as both primary and backup at the same time.

The same real server cannot be defined in both primary and backup at the same time.

Both primary and backup require the same NAT configuration (none, client, server, or both). In addition, if NAT is specified, both server farms must use the same NAT pool.

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, refer to the DFP Agent Subsystem feature document for Cisco IOS Release 12.2(14)ZA2.

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.

DFP and GPRS Load Balancing

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

Probes

IOS SLB supports DNS, HTTP, ping, TCP, custom UDP, and WSP probes:

A DNS probe sends domain name resolve requests to real servers, and verifies the returned IP addresses.

An HTTP probe establishes HTTP connections to real servers, sends HTTP requests to the real servers, and verifies the responses. HTTP probes are a simple way to verify connectivity for devices being server load-balanced, and for firewalls being firewall load-balanced (even devices on the other side of a firewall).

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.

A ping probe pings real servers. Like HTTP probes, ping probes are a simple way to verify connectivity for devices and firewalls being load-balanced.

A TCP probe establishes and removes TCP connections. Use TCP probes to detect failures on TCP port 443 (HTTPS).

A custom UDP probe can to support a variety of applications and protocols, including:

RADIUS Accounting/Authorization probes

GTP Echo probes

Connectionless WSP probes

XML-over-UDP probes for CSG user-database load-balancing

Mobile IP RRQ/RRP

A WSP probe simulates requests for wireless content and verifies the retrieved content. Use WSP probes to detect failures in the Wireless Application Protocol (WAP) stack on port 9201.

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:

Only one instance of a routed probe per server farm can run at any given time.

Outbound packets for a routed probe are routed directly to a specified IP address.

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. Refer to 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 Features

IOS SLB provides the following protocol support features:

Protocol Support

AAA Load Balancing

Audio and Video Load Balancing

VPN Server Load Balancing

Protocol Support

IOS SLB supports the following protocols:

Domain Name System (DNS)

Encapsulation Security Payload (ESP)

File Transfer Protocol (FTP)

Generic Routing Encapsulation (GRE)

GPRS Tunneling Protocol v0 (GTPv0)

GPRS Tunneling Protocol v1 (GTPv1)

Hypertext Transfer Protocol (HTTP)

Hypertext Transfer Protocol over Secure Socket Layer (HTTPS)

Internet Message Access Protocol (IMAP)

IP in IP Encapsulation (IPinIP)

Internet Key Exchange (IKE, was ISAKMP)

Mapping of Airline Traffic over IP, Type A (MATIP-A)

Network News Transport Protocol (NNTP)

Post Office Protocol, version 2 (POP2)

Post Office Protocol, version 3 (POP3)

RealAudio/RealVideo via RTSP

Remote Authentication Dial-In User Service (RADIUS)

Simple Mail Transport Protocol (SMTP)

Telnet

Transmission Control Protocol (TCP) and standard TCP protocols

User Datagram Protocol (UDP) and standard UDP protocols

X.25 over TCP (XOT)

Wireless Application Protocol (WAP), including:

Connectionless Secure WSP

Connectionless WSP

Connection-Oriented Secure WSP

Connection-Oriented WSP

AAA Load Balancing

IOS SLB provides RADIUS load-balancing capabilities for RADIUS authentication, authorization, and accounting (AAA) servers.

IOS SLB provides the following RADIUS load-balancing functions:

Balances RADIUS requests among available RADIUS servers and proxy servers.

Routes RADIUS request retransmissions (such as retransmissions of unanswered requests) to the same RADIUS server or proxy server as the original request.

Provides session-based automatic failure detection.

Supports both stateless backup and stateful backup.

In addition, IOS SLB can load-balance devices that proxy the RADIUS Authorization and Accounting flows in both traditional and mobile wireless networks. For more information, see the "RADIUS Load Balancing" section.

Audio and Video Load Balancing

IOS SLB can balance RealAudio and RealVideo streams via Real-Time Streaming Protocol (RTSP), for servers running RealNetworks applications.

VPN Server Load Balancing

IOS SLB can balance Virtual Private Network (VPN) flows, including the following flows:

IP Security (IPSec) flows. An IPSec flow consists of a UDP control session and an ESP tunnel.

Point-to-Point Tunneling Protocol (PPTP) flows. A PPTP flow consists of a TCP control session and a GRE tunnel.

Redundancy Features

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:

The IOS SLB device fails.

A link from a switch to the distribution-layer switch becomes disconnected.

To reduce that risk, IOS SLB supports the following redundancy enhancements, based on HSRP:

Stateless Backup

Stateful Backup

Active Standby

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 without GTP cause code inspection enabled does not support stateful backup.

The Home Agent Director 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.

Exchange Director Features

IOS SLB supports the Exchange Director for the Cisco Mobile Exchange (CMX) for Catalyst 6500 Family Switches and Cisco 7600 Internet Routers. The Exchange Director provides the following features:

GPRS Load Balancing

GPRS Load Balancing without GTP Cause Code Inspection

GPRS Load Balancing with GTP Cause Code Inspection

Home Agent Director

RADIUS Load Balancing

WAP Load Balancing

Stateful Backup of Redundant Route Processors

Flow Persistence

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.

When configuring the network shared by IOS SLB and the GGSNs, keep the following considerations in mind:

Specify static routes (using ip route commands) and real server IP addresses (using real commands) such that the Layer 2 information is correct and unambiguous.

Choose subnets carefully, using one of the following methods:

Do not overlap virtual template address subnets.

Specify next hop addresses to real servers, not to interfaces on those servers.

IOS SLB assigns all PDP context creates from a specific IMSI to the same GGSN.

IOS SLB supports both GTP Version 0 (GTP v0) and GTP Version 1 (GTP v1). Support for GTP enables IOS SLB to become "GTP aware," extending IOS SLB's knowledge into Layer 5.

IOS SLB supports two types of GPRS load balancing:

GPRS Load Balancing without GTP Cause Code Inspection

GPRS Load Balancing with GTP Cause Code Inspection

GPRS Load Balancing without GTP Cause Code Inspection

GPRS load balancing without GTP cause code inspection enabled is recommended for Cisco GGSNs. It has the following characteristics:

Can operate in dispatched mode or in directed server NAT mode, but not in directed client NAT mode. In dispatched mode, the GGSNs must be Layer 2-adjacent to the IOS SLB device.

Does not support stateful backup. See the "Stateful Backup" section for more information.

Delivers tunnel creation messages destined to the virtual GGSN IP address 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.

Requires DFP in order to account for secondary PDP contexts in GTP v1.

GPRS Load Balancing with GTP Cause Code Inspection

GPRS load balancing with GTP cause code inspection enabled allows IOS SLB to monitor all PDP context signaling flows to and from GGSN server farms. This enables IOS SLB to monitor GTP failure cause codes, detecting system-level problems in both Cisco and non-Cisco GGSNs.

Table 1 lists the PDP create response cause codes and the corresponding actions taken by IOS SLB.

Table 1 PDP Create Response Cause Codes and Corresponding IOS SLB Actions 

Cause Code
IOS SLB Action

Request Accepted

Establish session

No Resource Available

Fail current real, reassign session, drop the response

All dynamic addresses are occupied

Fail current real, reassign session, drop the response

No memory is available

Fail current real, reassign session, drop the response

System Failure

Fail current real, reassign session, drop the response

Missing or Unknown APN

Forward the response

Unknown PDP Address or PDP type

Forward the response

User Authentication Failed

Forward the response

Semantic error in TFT operation

Forward the response

Syntactic error in TFT operation

Forward the response

Semantic error in packet filter

Forward the response

Syntactic error in packet filter

Forward the response

Mandatory IE incorrect

Forward the response

Mandatory IE missing

Forward the response

Optional IE incorrect

Forward the response

Invalid message format

Forward the response

Version not supported

Forward the response


GPRS load balancing with GTP cause code inspection enabled has the following characteristics:

Must operate in directed server NAT mode.

Supports stateful backup. See the "Stateful Backup" section for more information.

Tracks the number of open PDP contexts for each GGSN, which enables GGSN server farms to use the weighted least connections (leastconns) algorithm for GPRS load balancing. See the "Weighted Least Connections" section for more information about this algorithm.

Enables IOS SLB to deny access to a virtual GGSN if the carrier code of the requesting International Mobile Subscriber ID (IMSI) does not match a specified value.

Enables IOS SLB to account for secondary PDP contexts even without DFP.

Home Agent Director

The Home Agent Director load balances Mobile IP Registration Requests (RRQs) among a set of home agents (configured as real servers in a server farm). Home agents are the anchoring points for mobile nodes. Home agents route flows for a mobile node to its current foreign agent (point of attachment).

The Home Agent Director has the following characteristics:

Can operate in dispatched mode or in directed server NAT mode, but not in directed client NAT mode. In dispatched mode, the home agents must be Layer 2-adjacent to the IOS SLB device.

Can operate in both fast and CEF switching modes.

Does not support stateful backup. See the "Stateful Backup" section for more information.

Delivers RRQs destined to the virtual Home Agent Director IP address to one of the real home agents, using the weighted round robin load-balancing algorithm. See the "Weighted Round Robin" section for more information about this algorithm.

For more information about Mobile IP, home agents, and related topics, refer to the Cisco IOS IP Configuration Guide, Release 12.2.

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:

GPRS networks. In a GPRS mobile wireless network, the RADIUS client is typically a GGSN.

Simple IP CDMA2000 networks. CDMA2000 is a third-generation (3-G) version of Code Division Multiple Access (CDMA). In a simple IP CDMA2000 mobile wireless network, the RADIUS client is a Packet Data Service Node (PDSN).

Mobile IP CDMA2000 networks. In a Mobile IP CDMA2000 mobile wireless network, both the Home Agent (HA) and the PDSN/Foreign Agent (PDSN/FA) are RADIUS clients.

IOS SLB provides the following RADIUS load-balancing functions:

Balances RADIUS requests among available RADIUS servers and proxy servers.

Routes RADIUS request retransmissions (such as retransmissions of unanswered requests) to the same RADIUS server or proxy server as the original request.

Routes all of a subscriber's RADIUS flows, as well as all non-RADIUS data flows for the same subscriber, to the same service gateway.

Supports multiple service gateway server farms (for example, one farm of SSGs and another of CSGs). IOS SLB examines the input interface in a packet to route it to the correct service gateway server farm.

Can route data packets to a real server in the CSG farm, then to a real server in the SSG farm.

Routes RADIUS Accounting-Request messages from a RADIUS client to the service gateway that processed the RADIUS Access-Request message for the subscriber. The service gateway can then clean up the host entry it has created for the subscriber.

Uses the weighted round robin load-balancing algorithm. See the "Weighted Round Robin" section for more information about this algorithm.

Facilitates SSG single sign-on via the RADIUS protocol.

Provides session-based automatic failure detection.

Supports both stateless backup and stateful backup.

To perform RADIUS load balancing, IOS SLB uses the following RADIUS sticky databases:

The IOS SLB RADIUS framed-IP sticky database associates each subscriber's IP address with a specific service gateway. In a GPRS mobile wireless network, IOS SLB uses the RADIUS framed-IP sticky database to route packets correctly.


Note Subscriber IP addresses are assigned by service gateways or by RADIUS clients. If subscriber IP addresses are assigned from disjoint per-service gateway pools (so that the next-hop service gateway can be chosen based on the source IP address), IOS SLB can use policy routing to route subscriber flows.


The IOS SLB RADIUS calling-station-ID sticky database associates each subscriber's calling station ID with a specific service gateway.

The IOS SLB RADIUS username sticky database associates each subscriber's username with a specific service gateway.

In a CDMA2000 mobile wireless network, to route packets correctly, IOS SLB requires both the RADIUS framed-IP sticky database and either the RADIUS username sticky database or the RADIUS calling-station-ID sticky database.

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:

Connectionless WSP mode (IP/UDP [9200]/WSP). In connectionless WSP mode, WSP is a simple one-request/one-response protocol in which a single server-bound packet results in a server response of one or more packets.

Connection-oriented WSP mode (IP/UDP [9201]/WTP/WSP). In connection-oriented WSP mode, WTP handles retransmissions of WDP events, and WSP operates using a defined session bring-up/tear-down sequence. IOS SLB uses a WAP-aware finite state machine (FSM), driven by events in WSP sessions, to reassign sessions. This FSM operates only on port 9201, where the WSP sessions are not encrypted and WTP handles retransmissions.

Connectionless secure WSP mode (IP/UDP [9202]/WTLS/WSP). This mode functions the same as connectionless WSP mode, but with security provided by WTLS.

Connection-oriented secure WSP mode (IP/UDP [9203]/WTLS/WTP/WSP). This mode functions the same as connection-oriented WSP mode, but with security provided by WTLS.

IOS SLB uses WSP probes to detect failures in the WAP stack on port 9201.

Stateful Backup of Redundant Route Processors

When used with RPR+, IOS SLB supports the stateful backup of redundant route processors for CMX for Catalyst 6500 Family Switches and Cisco 7600 Internet Routers. This enables you to deploy Cisco Multiprocessor WAN Application Modules (MWAMs) in the same chassis as IOS SLB, while maintaining high availability of load-balancing assignments.

Flow Persistence

Flow persistence provides intelligent return routing of load-balanced IP flows to the appropriate node, without the need for coordinated hash mechanisms on both sides of the load-balanced data path, and without using Network Address Translation (NAT) or proxies to change client or server IP addresses.

Benefits

IOS SLB shares the same software code base as Cisco IOS and has all the software features sets of Cisco IOS software. IOS SLB is recommended for customers desiring complete integration of SLB technology into traditional Cisco switches and routers.

On Cisco Catalyst 6500 Family Switches, IOS SLB takes advantage of hardware acceleration to forward packets at very high speed when running in dispatched mode.

IOS SLB assures continuous, high availability of content and applications with proven techniques for actively managing servers and connections in a distributed environment. By distributing user requests across a cluster of servers, IOS SLB optimizes responsiveness and system capacity, and dramatically reduces the cost of providing Internet, database, and application services for large-, medium-, and small-scale sites.

IOS SLB facilitates scalability, availability, and ease of maintenance:

The addition of new physical (real) servers, and the removal or failure of existing servers, can occur at any time, transparently, without affecting the availability of the virtual server.

IOS SLB's slow start capability allows a new server to increase its load gradually, preventing failures caused by assigning the server too many new connections too quickly.

IOS SLB supports fragmented packets and packets with IP options, buffering your servers from client or network vagaries that are beyond your control.

IOS SLB firewall load balancing enables you to scale access to your Internet site. You can add firewalls without affecting existing connections, enabling your site to grow without impacting customers.

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

IOS SLB has the following restrictions:

Does not support load balancing of flows between clients and real servers that are on the same local-area network (LAN) or virtual LAN (VLAN). The packets being load-balanced cannot enter and leave the load-balancing device on the same interface.

You cannot configure IOS SLB from different user sessions at the same time.

Operates in a standalone mode and currently does not operate as a MultiNode Load Balancing (MNLB) Services Manager. Does not support IOS SLB and MNLB configured with the same virtual IP address, even if they are for different services. The presence of IOS SLB does not preclude the use of the existing MNLB Forwarding Agent with an external Services Manager (such as the LocalDirector) in an MNLB environment. (MNLB is sometimes called Cisco Application Services Architecture, or CASA.)

Does not support coordinating server load-balancing statistics among different IOS SLB instances for backup capability.

Supports FTP and firewall load balancing only in dispatched mode.

When operating in dispatched mode, real servers must be Layer 2-adjacent, tag-switched, or via GRE tunnel.

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.

When operating in directed mode as a member of a multicast group, IOS SLB can receive multicast flows but cannot send multicast flows. This is not a restriction when operating in dispatched mode.

Supports client NAT and server port translation for TCP and UDP virtual servers only.

When balancing streams to a virtual IP address (VIP) that is the same as one of the IOS interface addresses (loopback, Ethernet, and so on), IOS SLB treats all UDP packets to that address as traceroute packets and replies with "host unreachable" ICMP packets. This occurs even if the IOS listens to the target UDP port. To avoid this issue, configure the virtual server as a network (address/31), not as a host (address/32).

The DFP agent requires a delay between hello messages of at least 3 seconds. Therefore, if your DFP manager provides a timeout specification, you must set the timeout to at least 3 seconds.

For static NAT:

Does not work with client NAT server farms. That is, if a real server is using a given virtual IP address for server NAT, and a server farm is associated with that same virtual IP address, then you cannot configure the server farm to use client NAT.

Requires that each real server be associated with only one virtual server, to ensure that IOS SLB can create connections correctly.

Requires a 0-port virtual server.

Does not support virtual service FTP.

For backup server farm support:

Does not support defining the same real server in both primary and backup server farms.

Requires the same NAT configuration (none, client, server, or both) for both primary and backup server farms. In addition, if NAT is specified, both server farms must use the same NAT pool.

Does not support HTTP redirect load balancing. If a primary server farm specifies a redirect virtual server, you cannot define that primary as a backup, nor can you define a backup for that primary.

For firewall load balancing:

Is no longer limited to a single firewall farm in each load-balancing device.

Is limited to a single active firewall load-balancing device on each side of the firewall farm. Each firewall must have its own unique MAC address and must be Layer 2-adjacent to each device. The firewalls can be connected to individual interfaces on the device, or they can all share a VLAN and connect using a single interface.

Requires Ethernet between each firewall load-balancing device and each firewall.

On each firewall load-balancing device, requires that each Layer 2 firewall be connected to a single Layer 3 (IP) interface.

Flows with a destination IP address on the same subnet as the configured firewall IP addresses are not load-balanced. (Such flows could be a firewall console session or other flows on the firewall LAN.)

Does not support the following IOS SLB functions:

- Active standby

- Network Address Translation (NAT)

- Port-bound servers

- SynGuard

- TCP session reassignment

- Transparent web cache load balancing

For GPRS load balancing without GTP cause code inspection enabled:

If a real server is defined in two or more server farms, each server farm must be associated with a different virtual server.

Operates in either dispatched or directed server NAT mode only.

Does not load-balance network-initiated PDP context requests.

Does not support the following IOS SLB functions:

- Bind IDs

- Client-assigned load balancing

- Slow Start

- Stateful backup (unless GTP cause code inspection is enabled)

- Sticky connections

- Weighted least connections load-balancing algorithm

For GPRS load balancing with GTP cause code inspection enabled:

If a real server is defined in two or more server farms, each server farm must be associated with a different virtual server.

Operates in directed server NAT mode only.

Cannot load-balance network-initiated PDP context requests.

Requires inbound and outbound signaling to flow through IOS SLB.

Requires either the SGSN or the GGSN to echo its peer.

Does not support the following IOS SLB functions:

- Bind IDs

- Client-assigned load balancing

- Slow Start

- Sticky connections

For VPN server load balancing:

Does not support Internet Control Message Protocol (ICMP) and wildcard (0-protocol) virtual servers.

For RADIUS load balancing for GPRS:

RADIUS load balancing requires the weighted round robin algorithm.

RADIUS load balancing does not support fragmented RADIUS packets.

All Accounting-Request and Access-Accept messages must include the RADIUS-assigned Framed-ip-address attribute. The source IP address for each subscriber flow must also match the value of the Framed-ip-address attribute in the Access-Accept message.

RADIUS accounting must be enabled on the RADIUS client, which is typically a Network Access Server (NAS).

For RADIUS load balancing for CDMA2000:

RADIUS load balancing requires the weighted round robin algorithm.

RADIUS load balancing does not support fragmented RADIUS packets.

All subscribers on the mobile network must be assigned a unique IP address (that is, no overlapping IP addresses) which can be routed in the mobile wireless network.

Each User-Name attribute must correspond to a single subscriber, or at most to a very small number of subscribers. Otherwise, a single SSG might be burdened with an unexpectedly large load.

For simple IP networks, the following additional restrictions apply:

- 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 Mobile IP networks, the following additional restrictions apply:

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

For the Home Agent Director:

A Registration Request (RRQ) must include the network access identifier (NAI) in order to be load-balanced.

An RRQ must include a home agent IP address of either 0.0.0.0 or 255.255.255.255 in order to be load-balanced.

For fast switching, the NAI in the RRQ cannot be more than 96 bytes deep in the packet. If the NAI is deeper than 96 bytes, IOS SLB handles the packet at the process level.

Operates in either dispatched or directed server NAT mode only.

Does not support the following IOS SLB functions:

- Bind IDs

- Client-assigned load balancing

- Slow Start

- Stateful backup

- Sticky connections

- Weighted least connections load-balancing algorithm

For HTTP probes:

HTTP probes do not support HTTP over Secure Socket Layer (HTTPS). That is, you cannot send an HTTP probe to an SSL server.

For UDP probes:

UDP probes do not support fragmented Response packets.

UDP probes do not support hosts that require a particular source port value in probe packets. UDP probes select an ephemeral port for each probe.

Protocols and applications that have Message Digest Algorithm Version 5 (MD5) checksums generated from payload must be captured by a "sniffer" to obtain a correct checksum.

For Catalyst 6500 Family Switches and Cisco 7600 Internet Routers:

Supports Native IOS only (c6sup images). Native IOS requires the MSFC and the Policy Feature Card (PFC). When running redundant MSFCs in the same Catalyst 6500 Family Switch, stateful backup between the two MSFCs is not supported, but stateless backup between the two MSFCs is supported.

The term "MSFC" refers to either an MSFC1 or an MSFC2, except when specifically differentiated.

The term "PFC" refers to either a PFC1 or a PFC2, except when specifically differentiated.

Requires that the Multilayer Switching (MLS) flow mode be set to full. For more information about how to set the MLS flow, refer to the Catalyst 6000 Family IOS Software Configuration Guide.

When operating in dispatched mode, real servers must be Layer 2-adjacent to IOS SLB (that is, not beyond an additional router), with hardware data packet acceleration performed by the PFC. All real servers in the same server farm must be on the same VLAN. The loopback address must be configured in the real servers.

Requires that all real servers in a firewall farm be on the same VLAN. Real servers in different firewall farms can be on different VLANs.

Provides no hardware data packet acceleration in directed mode. (Hardware data packet acceleration is performed by the PFC, and in directed mode the packets are handled by the MSFC, not the PFC.)

For the Cisco 7100 Series and Cisco 7200 Series:

Provides no hardware acceleration for the IOS SLB function for either dispatched mode or directed mode.

Supports Cisco IOS NAT in directed mode with no hardware data packet acceleration.

Does not support the Exchange Director for CMX.

Related Features and Technologies

Content Flow Monitor (CFM)

Dynamic Feedback Protocol (DFP)

General packet radio service (GPRS)

Hot Standby Router Protocol (HSRP)

Mobile IP

Network Address Translation (NAT)

Wireless Application Protocol (WAP)

Related Documents

Cisco IOS IP Configuration Guide, Release 12.2

Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services, Release 12.2

Cisco IOS Mobile Wireless Configuration Guide, Release 12.2

Cisco IOS Mobile Wireless Command Reference, Release 12.2

Dynamic Feedback Protocol Support in Distributed Director

Using Content Flow Monitor

Supported Platforms

Cisco 7100 series routers

Cisco 7200 series routers

MSFC2, Supervisor Engine 1, and Supervisor Engine 2 for Cisco Catalyst 6500 family switches (including the Catalyst 6506, Catalyst 6509, and Catalyst 6513)

MSFC2, Supervisor Engine 1, and Supervisor Engine 2 for the Cisco 7600 Internet routers (including the Cisco 7603, Cisco 7606, and Cisco 7609)

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:

http://www.cisco.com/register

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:

http://www.cisco.com/go/fn

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

No new or modified standards

MIBs

CISCO-SLB-MIB


Note Although the objects in this MIB are defined as read-create, you cannot use the SNMP SET command to modify them. Instead, you must use the command line to set the associated command line keywords, after which the new values are reflected in SNMP.


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:

http://www.cisco.com/register

RFCs

Cisco IOS NAT, RFC 1631

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 (Required)

Configuring Firewall Load Balancing (Optional)

Configuring Probes (Optional)

Configuring DFP (Optional)

GPRS Load Balancing Configuration Task List (Optional)

RADIUS Load Balancing Configuration Task List (Optional)

Exchange Director for CMX Configuration Task List (Optional)

VPN Server Load Balancing Configuration Task List (Optional)

Home Agent Director Configuration Task List (Optional)

Configuring NAT (Optional)

Configuring Static NAT (Optional)

Stateless Backup Configuration Task List (Optional)

Stateful Backup of Redundant Route Processors Configuration Task List (Optional)

Configuring Database Entries (Optional)

Configuring Buffers for the Fragment Database (Optional)

Clearing Databases and Counters (Optional)

Configuring Wildcard Searches (Optional)

Purging and Reassigning Connections (Optional)

Disabling Automatic Server Failure Detection (Optional)

Monitoring and Maintaining the IOS SLB Feature

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 (Required)

Configuring a Virtual Server (Required)

Verifying the Server Farm (Optional)

Verifying the Virtual Server (Optional)

Verifying the Clients (Optional)

Verifying IOS SLB Connectivity (Optional)

Configuring a Server Farm and Real Server


Note You cannot configure IOS SLB from different user sessions at the same time.


To configure an IOS SLB server farm, use the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# ip slb serverfarm server-farm
Router(config-slb-sfarm)#

Adds a server farm definition to the IOS Server Load Balancing (IOS SLB) configuration and enters server farm configuration mode.

Step 2 

Router(config-slb-sfarm)# bindid [bind-id]

(Optional) Specifies a bind ID on the server farm for use by Dynamic Feedback Protocol (DFP).

Note GPRS load balancing and Home Agent Director do not support this command.

Step 3 

Router(config-slb-sfarm)# nat {client pool | 
server}

(Optional) Configures Network Address Translation (NAT) client translation mode or NAT server address translation mode on the server farm.

Step 4 

Router(config-slb-sfarm)# predictor 
[roundrobin leastconns]

(Optional) Specifies the algorithm to be used to determine how a real server is selected.

Note RADIUS load balancing requires the default setting (the weighted round robin algorithm).

In GPRS load balancing without GTP cause code inspection enabled, you must accept the default setting (the weighted round robin algorithm).

The Home Agent Director requires the default setting (the weighted round robin algorithm).

See the following sections for more details:

Weighted Round Robin

Weighted Least Connections

Step 5 

Router(config-slb-sfarm)# probe probe

(Optional) Associates a probe with the real server.

Step 6 

Router(config-slb-sfarm)# real ip-address [port]

Identifies a real server by IP address and optional port number as a member of a server farm and enters real server configuration mode.

Note In GPRS load balancing, specify the IP addresses (virtual template addresses, for Cisco GGSNs) of the real servers performing the GGSN function.

In VPN server load balancing, specify the IP addresses of the real servers acting as VPN terminators.

For the Home Agent Director, specify the IP addresses of the real servers acting as home agents.

Step 7 

Router(config-slb-real)# faildetect 
numconns number-of-conns 
[numclients number-of-clients]

(Optional) Specifies the number of consecutive connection failures and, optionally, the number of unique client connection failures, that constitute failure of the real server.

In GPRS load balancing, if there is only one SGSN in your environment, specify the numclients keyword with a value of 1.

In RADIUS load balancing, for automatic session-based failure detection, specify the numclients keyword with a value of 1.

Step 8 

Router(config-slb-real)# maxclients 
number-of-conns

(Optional) Specifies the maximum number of IOS Server Load Balancing (IOS SLB) RADIUS and GTP sticky subscribers that can be assigned to an individual virtual server.

Step 9 

Router(config-slb-real)# maxconns 
number-of-conns

(Optional) Specifies the maximum number of active connections allowed on the real server at one time.

Step 10 

Router(config-slb-real)# reassign threshold

(Optional) Specifies the threshold of consecutive unacknowledged SYNchronize sequence numbers (SYNs) or Create Packet Data Protocol (PDP) requests that, if exceeded, result in an attempted connection to a different real server.

Note In GPRS load balancing, you must specify a reassign threshold less than the SGSN's N3-REQUESTS counter value.

Step 11 

Router(config-slb-real)# retry retry-value

(Optional) Specifies the interval, in seconds, to wait between the detection of a server failure and the next attempt to connect to the failed server.

Step 12 

Router(config-slb-real)# weight setting

(Optional) Specifies the real server's workload capacity relative to other servers in the server farm.

Note If you use Dynamic Feedback Protocol (DFP), the static weights you define using the weight command in server farm configuration mode are overridden by the weights calculated by DFP. If DFP is removed from the network, IOS SLB reverts to the static weights.

Step 13 

Router(config-slb-real)# inservice

Enables the real server for use by IOS Server Load Balancing (IOS SLB).


Note When performing server load balancing and firewall load balancing together on a Catalyst 6500 Family Switch, use the mls ip slb wildcard search rp command to reduce the probability of exceeding the capacity of the TCAM on the PFC. See the"Configuring Wildcard Searches" section for more details.


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:

 
Command
Purpose

Step 1 

Router(config)# ip slb vserver virtual-server

Identifies a virtual server and enters virtual server configuration mode.

Step 2 

Router(config-slb-vserver)# virtual ip-address 
[netmask [group]] {esp gre protocol}

or

Router(config-slb-vserver)# virtual ip-address 
[netmask [group]] {tcp udp} [port any] 
[service service]

Specifies the virtual server IP address, type of connection, and optional TCP or User Datagram Protocol (UDP) port number, Internet Key Exchange (IKE) or Wireless Session Protocol (WSP) setting, and service coupling.

Note For GPRS load balancing:

Specify a virtual GGSN IP address as the virtual server, and specify the udp keyword option.

To load-balance GTP v1 sessions, specify port number 2123, if the GGSNs and SGSNs are in compliance with the ETSI standard, or specify port number 0 or any to configure an all-port virtual server (that is, a virtual server that accepts flows destined for all ports).

To load-balance GTP v0 sessions, specify port number 3386, if the GGSNs and SGSNs are in compliance with the ETSI standard, or specify port number 0 or any to configure an all-port virtual server.

To enable GPRS load balancing without GTP cause code inspection, specify the service gtp keyword option.

To enable GPRS load balancing with GTP cause code inspection, specify the service gtp-inspect keyword option.

Step 3 

Router(config-slb-vserver)# serverfarm primary-farm 
[backup backup-farm [sticky]]

Associates a real server farm with a virtual server, and optionally configures a backup server farm and specifies that sticky connections are to be used in the backup server farm.

Note GPRS load balancing and the Home Agent Director do not support the sticky attribute.

For GPRS load balancing, if a real server is defined in two or more server farms, each server farm must be associated with a different virtual server.

Step 4 

Router(config-slb-vserver)# access interface route 
framed-ip

(Optional) Enables framed-IP routing to inspect the ingress interface.

Step 5 

Router(config-slb-vserver)# advertise

(Optional) Controls the installation of a static route to the Null0 interface for a virtual server address.

Step 6 

Router(config-slb-vserver)# client {ip-address 
netmask [exclude] | gtp carrier-code [code]}

(Optional) Specifies which clients are allowed to use the virtual server.

Note GPRS load balancing supports only the gtp carrier-code option, and only if GTP cause code inspection is enabled.

Step 7 

Router(config-slb-vserver)# delay duration

(Optional) Specifies the time IOS Server Load Balancing (IOS SLB) maintains TCP connection context after a connection has terminated.

Step 8 

Router(config-slb-vserver)# hand-off radius duration

(Optional) Changes the amount of time IOS Server Load Balancing (IOS SLB) waits for an ACCT-START message from a new Mobile IP foreign agent in the event of a foreign agent hand-off.

Step 9 

Router(config-slb-vserver)# idle [gtp request | 
ipmobile request | radius {request framed-ip}] 
duration

(Optional) Specifies the minimum time IOS Server Load Balancing (IOS SLB) maintains connection context in the absence of packet activity.

Note In GPRS load balancing without GTP cause code inspection enabled, specify an idle timer greater than the longest possible interval between PDP context requests on the SGSN.

Step 10 

Router(config-slb-vserver)# purge radius framed-ip 
acct on-off

(Optional) Enables IOS SLB to purge entries in the IOS SLB RADIUS framed-ip sticky database upon receipt of an Accounting ON or OFF message.

Step 11 

Router(config-slb-vserver)# purge radius framed-ip 
acct stop {attribute-number | {26 vsa} 
{vendor-ID 3gpp 3gpp2} sub-attribute-number}

(Optional) Enables IOS SLB to purge entries in the IOS SLB RADIUS framed-ip sticky database upon receipt of an Accounting-Stop message.

Step 12 

Router(config-slb-vserver)# replicate casa listen-ip 
remote-ip port [interval] [password [7password 
timeout]

(Optional) Configures a stateful backup of IOS Server Load Balancing (IOS SLB) decision tables to a backup switch.

Note GPRS load balancing without GTP cause code inspection enabled does not support this command.

The Home Agent Director does not support this command.

Step 13 

Router(config-slb-vserver)# replicate interval 
interval

(Optional) Sets the replication delivery interval for an IOS Server Load Balancing (IOS SLB) virtual server.

Note GPRS load balancing without GTP cause code inspection enabled does not support this command.

The Home Agent Director does not support this command.

Step 14 

Router(config-slb-vserver)# replicate slave

(Optional) Enables stateful backup of redundant route processors for an IOS Server Load Balancing (IOS SLB) virtual server.

Note GPRS load balancing without GTP cause code inspection enabled does not support this command.

The Home Agent Director does not support this command.

Step 15 

Router(config-slb-vserver)# sticky 
{duration [group group-id] [netmask netmask] | 
radius calling-station-id  | 
radius framed-ip [group group-id] | 
radius username [msid-cisco] [group group-id]}

(Optional) Specifies that connections from the same client use the same real server, as long as the interval between client connections does not exceed the specified duration.

Note In VPN server load balancing, specify a duration of at least 15 seconds.

GPRS load balancing and the Home Agent Director do not support this command.

Step 16 

Router(config-slb-vserver)# synguard syn-count 
interval

(Optional) Specifies the rate of TCP SYNchronize sequence numbers (SYNs) handled by a virtual server in order to prevent a SYN flood denial-of-service attack.

Note GPRS load balancing and the Home Agent Director do not support this command.

Step 17 

Router(config-slb-vserver)# inservice

Enables the virtual server for use by IOS Server Load Balancing (IOS SLB).

Step 18 

Router(config-slb-vserver)# client ip-address 
netmask

Specifies which clients are allowed to use the virtual server.

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 vserver

slb vserver      prot  virtual               state         conns
-------------------------------------------------------------------
PUBLIC_HTTP      TCP   10.0.0.1:80           OPERATIONAL     0
RESTRICTED_HTTP  TCP   10.0.0.2:80           OPERATIONAL     0
Router#

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 real

real                    farm name        weight   state          conns
---------------------------------------------------------------------
10.1.1.1                 PUBLIC           8       OPERATIONAL      0
10.1.1.2                 PUBLIC           8       OPERATIONAL      0
10.1.1.3                 PUBLIC           8       OPERATIONAL      0
10.1.1.20                RESTRICTED       8       OPERATIONAL      0
10.1.1.21                RESTRICTED       8       OPERATIONAL      0
Router#

The following show ip slb serverfarm command displays the configuration and status of server farms PUBLIC and RESTRICTED:

Router# show ip slb serverfarm

server farm      predictor    nat   reals   bind id
---------------------------------------------------
PUBLIC           ROUNDROBIN   none  3       0
RESTRICTED       ROUNDROBIN   none  2       0
Router#

Verifying the Clients

The following show ip slb conns command verifies the restricted client access and status:

Router# show ip slb conns

vserver         prot client                real                  state     nat
-------------------------------------------------------------------------------
RESTRICTED_HTTP TCP  10.4.4.0:80           10.1.1.20             CLOSING   none
Router#

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 detail
VSTEST_UDP, client = 10.4.4.0:80
  state = CLOSING, real = 10.1.1.20, nat = none
  v_ip = 10.0.0.2:80, TCP, service = NONE
  client_syns = 0, sticky = FALSE, flows attached = 0
Router#

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 stats
 Pkts via normal switching:  0
 Pkts via special switching: 6
 Pkts dropped:               0
 Connections Created:        1
 Connections Established:    1
 Connections Destroyed:      0
 Connections Reassigned:     0
 Zombie Count:               0
 Connections Reused:         0

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

When performing server load balancing and firewall load balancing together on a Catalyst 6500 Family Switch, use the mls ip slb wildcard search rp command to reduce the probability of exceeding the capacity of the TCAM on the PFC. See the"Configuring Wildcard Searches" section for more details.

This section describes the following IOS SLB firewall load-balancing configuration tasks. Required and optional tasks are indicated.

Configuring the Firewall Farm (Required)

Verifying the Firewall Farm (Optional)

Verifying Firewall Connectivity (Optional)

Configuring the Firewall Farm

To configure an IOS SLB firewall load-balancing network, enter the following commands in order, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# ip slb firewallfarm firewall-farm
Router(config-slb-fw)#

Adds a firewall farm definition to the IOS Server Load Balancing (IOS SLB) configuration and enters firewall farm configuration mode.

Step 2 

Router(config-slb-fw)# real ip-address

Identifies a firewall by IP address as a member of a firewall farm and enters real server configuration mode.

Step 3 

Router(config-slb-fw-real)# probe probe

Associates a probe with the firewall.

Step 4 

Router(config-slb-fw-real)# weight setting

(Optional) Specifies the firewall's workload capacity relative to other firewalls in the firewall farm.

Step 5 

Router(config-slb-fw-real)# inservice

Enables the firewall for use by the firewall farm and by IOS Server Load Balancing (IOS SLB).

Step 6 

Router(config-slb-fw)# access 
[source source-ip netmask] 
[destination destination-ip netmask]

(Optional) Routes specific flows to a firewall farm.

Step 7 

Router(config-slb-fw)# predictor hash address [port]

(Optional) Specifies whether the source and destination TCP or User Datagram Protocol (UDP) port numbers, in addition to the source and destination IP addresses, are to be used when selecting a firewall.

Step 8 

Router(config-slb-fw)# replicate casa listen-ip 
remote-ip port [interval] [password [7password 
[timeout]]

(Optional) Configures a stateful backup of IOS Server Load Balancing (IOS SLB) firewall load balancing decision tables to a backup switch.

Step 9 

Router(config-slb-vserver)# replicate interval 
interval

(Optional) Sets the replication delivery interval for an IOS Server Load Balancing (IOS SLB) firewall farm.

Note GPRS load balancing without GTP cause code inspection enabled does not support this command.

The Home Agent Director does not support this command.

Step 10 

Router(config-slb-vserver)# replicate slave

(Optional) Enables stateful backup of redundant route processors for an IOS Server Load Balancing (IOS SLB) firewall farm.

Note GPRS load balancing without GTP cause code inspection enabled does not support this command.

The Home Agent Director does not support this command.

Step 11 

Router(config-slb-fw)# protocol tcp

(Optional) Enters firewall farm TCP protocol configuration mode.

Step 12 

Router(config-slb-fw-tcp)# delay duration

(Optional) For firewall farm TCP protocol configuration mode, specifies the time IOS Server Load Balancing (IOS SLB) firewall load balancing maintains TCP connection context after a connection has terminated.

Step 13 

Router(config-slb-fw-tcp)# idle duration

(Optional) For firewall farm TCP protocol configuration mode, specifies the minimum time IOS Server Load Balancing (IOS SLB) firewall load balancing maintains connection context in the absence of packet activity.

Step 14 

Router(config-slb-fw-tcp)# maxconns number-of-conns

(Optional) For firewall farm TCP protocol configuration mode, specifies the maximum number of active TCP connections allowed on the firewall farm at one time.

Step 15 

Router(config-slb-fw-tcp)# sticky duration 
[netmask netmask] [source | destination]

(Optional) For firewall farm TCP protocol configuration mode, specifies that connections from the same IP address use the same firewall if either of the following conditions is met:

As long as any connection between the same pair of IP addresses exists (source/destination sticky).

For a period, defined by duration, after the last connection is destroyed.

Step 16 

Router(config-slb-fw)# protocol datagram

(Optional) Enters firewall farm datagram protocol configuration mode.

Step 17 

Router(config-slb-fw-udp)# idle duration

(Optional) For firewall farm datagram protocol configuration mode, specifies the minimum time IOS Server Load Balancing (IOS SLB) firewall load balancing maintains connection context in the absence of packet activity.

Step 18 

Router(config-slb-fw-udp)# maxconns number-of-conns

(Optional) For firewall farm datagram protocol configuration mode, specifies the maximum number of active datagram connections allowed on the firewall farm at one time.

Step 19 

Router(config-slb-fw-udp)# sticky duration 
[netmask netmask] [source | destination]

(Optional) For firewall farm datagram protocol configuration mode, specifies that connections from the same IP address use the same firewall if either of the following conditions is met:

As long as any connection between the same pair of IP addresses exists (source/destination sticky).

For a period, defined by duration, after the last connection is destroyed.

Step 20 

Router(config-slb-fw)# inservice

Enables the firewall farm for use by IOS Server Load Balancing (IOS SLB).

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 real

real                  farm name        weight   state          conns
--------------------------------------------------------------------
10.1.1.2              FIRE1            8        OPERATIONAL    0
10.1.2.2              FIRE1            8        OPERATIONAL    0

The following show ip slb firewallfarm command displays the configuration and status of firewall farm FIRE1:

Router# show ip slb firewallfarm
 
firewall farm    hash        state         reals
------------------------------------------------
FIRE1            IPADDR      INSERVICE     2

Verifying Firewall Connectivity

To verify that IOS SLB firewall load balancing has been configured and is operating correctly:


Step 1 Ping the external real servers (the ones outside the firewall) from the IOS SLB firewall load-balancing switch.

Step 2 Ping the internal real servers (the ones inside the firewall) from the clients.

Step 3 Use the show ip slb stats command to display detailed information about the IOS SLB firewall load-balancing network status:

Router# show ip slb stats
 Pkts via normal switching:  0
 Pkts via special switching: 0
 Pkts dropped:               0
 Connections Created:        1911871
 Connections Established:    1967754
 Connections Destroyed:      1313251
 Connections Reassigned:     0
 Zombie Count:               0
 Connections Reused:         59752
 Connection Flowcache Purges:1776582
 Failed Connection Allocs:   17945
 Failed Real Assignments:    0

Normal 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 Use the show ip slb real detail command to display detailed information about the IOS SLB firewall load-balancing real server status:

Router# show ip slb real detail
10.1.1.3, FIRE1, state = OPERATIONAL, type = firewall
  conns = 299310, dummy_conns = 0, maxconns = 4294967295
  weight = 10, weight(admin) = 10, metric = 104, remainder = 2
  total conns established = 1074779, hash count = 4646
  server failures = 0
  interface FastEthernet1/0, MAC 0010.f68f.7020

Step 5 Use the show ip slb conns command to display detailed information about the active IOS SLB firewall load-balancing connections:

Router# show ip slb conns

vserver         prot client                real                  state     nat 
-------------------------------------------------------------------------------
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none

Step 6 See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB networks and connections.


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 Custom UDP Probes (Required)

Configuring DNS Probes (Required)

Configuring HTTP Probes (Required)

Configuring Ping Probes (Required)

Configuring TCP Probes (Required)

Configuring WSP Probes (Required)

Associating the Probe (Required)

Verifying the Probe (Optional)

Configuring Custom UDP Probes

To configure a custom UDP probe, enter the following commands in order, beginning in global configuration mode:

 
Command
Description

Step 1 

Router(config)# ip slb probe probe custom udp

Configures the IOS Server Load Balancing (IOS SLB) probe name and enters custom User Datagram Protocol (UDP) probe configuration mode.

Step 2 

Router(config-slb-probe)# address 
[ip-address [routed]]

(Optional) Configures an IP address to which to send the custom User Datagram Protocol (UDP) probe.

Step 3 

Router(config-slb-probe)# interval seconds

(Optional) Configures the custom User Datagram Protocol (UDP) probe transmit timers.

Step 4 

Router(config-slb-probe)# port port

Configures the port to which the custom User Datagram Protocol (UDP) probe is to connect.

Step 5 

Router(config-slb-probe)# request 
data {start-byte continue} hex-data-string

Defines the payload of the User Datagram Protocol (UDP) request packet to be sent by a custom UDP probe.

Step 6 

Router(config-slb-probe)# response clause-number 
data start-byte hex-data-string

Defines the data string to match against custom User Datagram Protocol (UDP) probe response packets.

Configuring DNS Probes

To configure a DNS probe, enter the following commands in order, beginning in global configuration mode:

 
Command
Description

Step 1 

Router(config)# ip slb probe probe dns

Configures the IOS Server Load Balancing (IOS SLB) probe name and enters Domain Name System (DNS) probe configuration mode.

Step 2 

Router(config-slb-probe)# address 
[ip-address [routed]]

(Optional) Configures an IP address to which to send the Domain Name System (DNS) probe.

Step 3 

Router(config-slb-probe)# faildetect number-of-probes

(Optional) Specifies the number of consecutive unacknowledged Domain Name System (DNS) probes that constitute failure of the real server or firewall.

Step 4 

Router(config-slb-probe)# interval seconds

(Optional) Configures the Domain Name System (DNS) probe transmit timers.

Step 5 

Router(config-slb-probe)# lookup [ip-address]

(Optional) Configures an IP address of a real server that a Domain Name System (DNS) server should supply in response to a domain name resolve request.

Configuring HTTP Probes

To configure an HTTP probe, enter the following commands in order, beginning in global configuration mode:

 
Command
Description

Step 1 

Router(config)# ip slb probe probe http

Configures the IOS Server Load Balancing (IOS SLB) probe name and enters HTTP probe configuration mode.

Step 2 

Router(config-slb-probe)# address 
[ip-address [routed]]

(Optional) Configures an IP address to which to send the HTTP probe.

Step 3 

Router(config-slb-probe)# credentials {username 
[password]}

(Optional) Configures header values for the HTTP probe.

Step 4 

Router(config-slb-probe)# expect [status number] 
[regex expression]

(Optional) Configures the expected HTTP status code or regular expression.

Step 5 

Router(config-slb-probe)# header {name field-name 
[field-value]}

(Optional) Configures header values for the HTTP probe.

Step 6 

Router(config-slb-probe)# interval seconds

(Optional) Configures the HTTP probe transmit timers.

Step 7 

Router(config-slb-probe)# port port

(Optional) Configures the port to which the HTTP probe is to connect.

Step 8 

Router(config-slb-probe)# request 
[method {get post head name name}] [url path]

(Optional) Configures the URL path to request from the server, and the method used to perform the request to the server.

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:

 
Command
Description

Step 1 

Router(config)# ip slb probe probe ping

Configures the IOS Server Load Balancing (IOS SLB) probe name and enters ping probe configuration mode.

Step 2 

Router(config-slb-probe)# address 
[ip-address [routed]]

(Optional) Configures an IP address to which to send the ping probe.

Step 3 

Router(config-slb-probe)# faildetect number-of-pings

(Optional) Specifies the number of consecutive unacknowledged pings that constitute failure of the real server or firewall.

Step 4 

Router(config-slb-probe)# interval seconds

(Optional) Configures the ping probe transmit timers.

Configuring TCP Probes

To configure a TCP probe, enter the following commands in order, beginning in global configuration mode:

 
Command
Description

Step 1 

Router(config)# ip slb probe probe tcp

Configures the IOS Server Load Balancing (IOS SLB) probe name and enters TCP probe configuration mode.

Step 2 

Router(config-slb-probe)# address 
[ip-address [routed]]

(Optional) Configures an IP address to which to send the TCP probe.

Step 3 

Router(config-slb-probe)# interval seconds

(Optional) Configures the TCP probe transmit timers.

Step 4 

Router(config-slb-probe)# port port

Configures the port to which the TCP probe is to connect.

Configuring WSP Probes

To configure a WSP probe, enter the following commands in order, beginning in global configuration mode:

 
Command
Description

Step 1 

Router(config)# ip slb probe probe wsp

Configures the IOS Server Load Balancing (IOS SLB) probe name and enters Wireless Session Protocol (WSP) probe configuration mode.

Step 2 

Router(config-slb-probe)# address 
[ip-address [routed]]

(Optional) Configures an IP address to which to send the Wireless Session Protocol (WSP) probe.

Step 3 

Router(config-slb-probe)# interval seconds

(Optional) Configures the Wireless Session Protocol (WSP) probe transmit timers.

Step 4 

Router(config-slb-probe)# url [path]

(Optional) Configures the Wireless Session Protocol (WSP) probe URL path.

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 You cannot associate a WSP probe with a firewall.


Verifying the Probe

To verify that a probe is configured correctly, use the show ip slb probe command:

Router# show ip slb probe

Server:Port            State        Outages  Current  Cumulative
----------------------------------------------------------------
10.1.1.1:80            OPERATIONAL        0  never    00:00:00
10.1.1.2:80            OPERATIONAL        0  never    00:00:00
10.1.1.3:80            OPERATIONAL        0  never    00:00:00
Router#

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:

 
Command
Description

Step 1 

Router(config)# ip slb dfp [password [7password 
[timeout]]

Configures Dynamic Feedback Protocol (DFP), supplies an optional password, and enters DFP configuration mode.

Step 2 

Router(config-slb-dfp)# agent ip-address port 
[timeout [retry-count [retry-interval]]]

Identifies a Dynamic Feedback Protocol (DFP) agent to which IOS Server Load Balancing (IOS SLB) can connect.

To configure IOS SLB as a DFP agent, refer to the DFP Agent Subsystem feature document for Cisco IOS Release 12.2(14)ZA2.

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.

Configuring a Server Farm and Real Server (Required)

When you configure the server farm and real server for GPRS load balancing, keep the following considerations in mind:

If GTP cause code inspection is not enabled, accept the default setting (the weighted round robin algorithm) for the predictor command.

If GTP cause code inspection is enabled, you can specify either the weighted round robin (roundrobin) or the weighted least connections (leastconns) algorithm.

Specify the IP addresses (virtual template addresses, for Cisco GGSNs) of the real servers performing the GGSN function, using the real command.

Specify a reassign threshold less than the SGSN's N3-REQUESTS counter value, using the reassign command.

Configuring a Virtual Server (Required)

When you configure the virtual command, keep the following considerations in mind:

Specify a virtual GGSN IP address as the virtual server, and specify the udp keyword option.

To load-balance GTP v1 sessions, specify port number 2123, if the GGSNs and SGSNs are in compliance with the ETSI standard, or specify port number 0 or any to configure an all-port virtual server (that is, a virtual server that accepts flows destined for all ports).

To load-balance GTP v0 sessions, specify port number 3386, if the GGSNs and SGSNs are in compliance with the ETSI standard, or specify port number 0 or any to configure an all-port virtual server.

To enable GPRS load balancing without GTP cause code inspection, specify the service gtp keyword option.

To enable GPRS load balancing with GTP cause code inspection, specify the service gtp-inspect keyword option.

In GPRS load balancing without GTP cause code inspection enabled, when you configure the idle timer using the idle command, specify an idle timer greater than the longest possible interval between PDP context requests on the SGSN.

Configuring the virtual IP address as a loopback on each of the GGSNs in the server (Required for dispatched mode)

This step is required only if you are using dispatched mode without GTP cause code inspection enabled. Refer to the "Configuring a Loopback Interface" section in the Cisco IOS Interface Configuration Guide, Release 12.2 for more information.

Routing each GGSN to each associated SGSN (Required)

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.

Routing each SGSN to the virtual templates on each associated Cisco GGSN, and to the GPRS load-balancing virtual server (Required)

Refer to the configuration guide for your SGSN for more details.

Configuring a GSN Idle Timer (Optional)

This step is applicable only if GTP cause code inspection is enabled.

Configuring a GSN Idle Timer

To configure a GPRS support node (GSN) idle timer, enter the following command in global configuration mode:

Command
Purpose
Router(config)# ip slb timers gtp gsn duration

Change the amount of time IOS Server Load Balancing (IOS SLB) maintains sessions to and from an idle gateway GPRS support node (GGSN) or serving GPRS support node (SGSN).


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.

Configuring a Server Farm and Real Server (Required)

When you configure the server farm and real server for RADIUS load balancing, keep the following considerations in mind:

Accept the default setting (the weighted round robin algorithm) for the predictor command.

(Optional) Specify a value of 1 for the numclients keyword on the faildetect numconns command, if you want to enable session-based failure detection.

(Optional) To specify the maximum number of IOS SLB RADIUS and GTP sticky subscribers that can be assigned to an individual virtual server, use the maxclients command.

Configuring a Virtual Server (Required)

When you configure the virtual server for RADIUS load balancing, keep the following considerations in mind:

Specify the service radius keyword option, using the virtual command.

(Optional) To enable framed-IP routing to inspect the ingress interface, specify the access interface route framed-ip command.

If you configure the access interface route framed-ip command, you must also configure the virtual command with the service radius keywords specified.

(Optional) To change the amount of time IOS SLB waits for an ACCT-START message from a new Mobile IP foreign agent in the event of a foreign agent hand-off, configure a hand-off radius command.

(Optional) To set a duration for RADIUS entries in the IOS SLB session database, configure an idle command with the radius request keywords specified.

(Optional) To set a duration for entries in the IOS SLB RADIUS framed-IP sticky database, configure an idle command with the radius framed-ip keywords specified.

(Optional) To enable IOS SLB to create the IOS SLB RADIUS framed-IP sticky database and direct RADIUS requests and non-RADIUS flows from a given subscriber to the same service gateway, specify the radius framed-ip keywords on the sticky command.

If you configure the sticky radius framed-ip command, you must also configure the virtual command with the service radius keywords specified.

(Optional) To enable IOS SLB to purge entries in the IOS SLB RADIUS framed-ip sticky database upon receipt of an Accounting ON or OFF message, specify the purge radius framed-ip acct on-off virtual server configuration command.

To prevent IOS SLB from purging entries in the IOS SLB RADIUS framed-ip sticky database upon receipt of an Accounting ON or OFF message, specify the no purge radius framed-ip acct on-off virtual server configuration command.

(Optional) To enable IOS SLB to purge entries in the IOS SLB RADIUS framed-ip sticky database upon receipt of an Accounting-Stop message, specify the purge radius framed-ip acct stop virtual server configuration command.

To prevent IOS SLB from purging entries in the IOS SLB RADIUS framed-ip sticky database upon receipt of an Accounting-Stop message, specify the no purge radius framed-ip acct stop virtual server configuration command.

(Optional—for CDMA2000 networks only) To enable IOS SLB to create the IOS SLB RADIUS calling-station-ID sticky database and direct RADIUS requests from a given subscriber to the same service gateway based on the calling station ID, specify the radius calling-station-id keywords on the sticky command.

To enable IOS SLB to create the IOS SLB RADIUS username sticky database and direct RADIUS requests from a given subscriber to the same service gateway based on the username, specify the radius username keywords on the sticky command.

If you configure the sticky radius calling-station-id command or 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.

You cannot configure both the sticky radius calling-station-id command and the sticky radius username command on the same virtual server.

Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing (Optional)

Increasing the number of available MLS entries (Optional)

If you are running IOS SLB in dispatched mode on a Catalyst 6500 Family Switch with Supervisor Engine 2, you can improve performance by configuring the no mls netflow command. This command increases the number of MLS entries available for hardware switching of end-user flows.


Note If you are using IOS features that use the hardware NetFlow table, such as micro-flow QoS, reflexive ACLs, TCP intercept, or Web Cache Redirect, do not configure the no mls netflow command.


For more information about configuring MLS NetFlow, refer to the Catalyst 6000 Family IOS Software Configuration Guide.

Configuring Probes (Required)

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:

Command
Purpose
Router(config)# ip slb route 
{ip-address netmask framed-ip | 
inter-firewall}

Enables IOS Server Load Balancing (IOS SLB) to route packets using the RADIUS framed-IP sticky database, or to route packets from one firewall real server back through another firewall real server.


Exchange Director for CMX Configuration Task List

This section contains the following information:

RADIUS Configuration for the Exchange Director

Firewall Configuration for the Exchange Director

RADIUS Configuration for the Exchange Director

This section lists the tasks used to configure RADIUS for the Exchange Director. Detailed configuration information is contained in the referenced sections of this or other documents. Required and optional tasks are indicated.

Configuring a Server Farm and Real Server (Required)

When you configure the server farm and real server for RADIUS for the Exchange Director, keep the following considerations in mind:

(Optional) Specify a value of 1 for the numclients keyword on the faildetect numconns command, if you want to enable session-based failure detection.

(Optional) To specify the maximum number of IOS SLB RADIUS and GTP sticky subscribers that can be assigned to an individual virtual server, use the maxclients command.

Configuring a Virtual Server (Required)

When you configure the virtual server for RADIUS for the Exchange Director, keep the following considerations in mind:

Specify the service radius keyword option, using the virtual command.

(Optional) To enable framed-IP routing to inspect the ingress interface, specify the access interface route framed-ip command.

If you configure the access interface route framed-ip command, you must also configure the virtual command with the service radius keywords specified.

(Optional) To change the amount of time IOS SLB waits for an ACCT-START message from a new Mobile IP foreign agent in the event of a foreign agent hand-off, configure a hand-off radius command.

(Optional) To set a duration for RADIUS entries in the IOS SLB session database, configure an idle command with the radius request keywords specified.

(Optional) To set a duration for entries in the IOS SLB RADIUS framed-IP sticky database, configure an idle command with the radius framed-ip keywords specified.

(Optional) To enable IOS SLB to create the IOS SLB RADIUS framed-IP sticky database and direct RADIUS requests and non-RADIUS flows from a given subscriber to the same service gateway, specify the radius framed-ip keywords on the sticky command.

If you configure the sticky radius framed-ip command, you must also configure the virtual command with the service radius keywords specified.

(Optional—for CDMA2000 networks only) To enable IOS SLB to create the IOS SLB RADIUS calling-station-ID sticky database and direct RADIUS requests from a given subscriber to the same service gateway based on the calling station ID, specify the radius calling-station-id keywords on the sticky command.

To enable IOS SLB to create the IOS SLB RADIUS username sticky database and direct RADIUS requests from a given subscriber to the same service gateway based on the username, specify the radius username keywords on the sticky command.

If you configure the sticky radius calling-station-id command or 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.

You cannot configure both the sticky radius calling-station-id command and the sticky radius username command on the same virtual server.

Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing (Optional)

Increasing the number of available MLS entries (Optional)

If you are running IOS SLB in dispatched mode on a Catalyst 6500 Family Switch with Supervisor Engine 2, you can improve performance by configuring the no mls netflow command. This command increases the number of MLS entries available for hardware switching of end-user flows.


Note If you are using IOS features that use the hardware NetFlow table, such as micro-flow QoS, reflexive ACLs, TCP intercept, or Web Cache Redirect, do not configure the no mls netflow command.


For more information about configuring MLS NetFlow, refer to the Catalyst 6000 Family IOS Software Configuration Guide.

Configuring Probes (Required)

To verify the health of the server, configure a ping probe.

Firewall Configuration for the Exchange Director

This section lists the tasks used to configure firewalls for the Exchange Director. Detailed configuration information is contained in the referenced sections of this or other documents. Required and optional tasks are indicated.

Configuring the Firewall Farm (Required)

To configure a firewall farm for the Exchange Director, enter the following commands in order, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# ip slb firewallfarm firewall-farm
Router(config-slb-fw)#

Adds a firewall farm definition to the IOS Server Load Balancing (IOS SLB) configuration and enters firewall farm configuration mode.

Step 2 

Router(config-slb-fw)# real ip-address

Identifies a firewall by IP address as a member of a firewall farm and enters real server configuration mode.

Step 3 

Router(config-slb-fw-real)# probe probe

Associates a probe with the firewall.

Step 4 

Router(config-slb-fw-real)# weight setting

(Optional) Specifies the firewall's workload capacity relative to other firewalls in the firewall farm.

Step 5 

Router(config-slb-fw-real)# inservice

Enables the firewall for use by the firewall farm and by IOS Server Load Balancing (IOS SLB).

Step 6 

Router(config-slb-fw)# access 
[source source-ip netmask] 
[destination destination-ip netmask]

(Optional) Routes specific flows to a firewall farm.

Step 7 

Router(config-slb-fw)# predictor hash address [port]

(Optional) Specifies whether the source and destination TCP or User Datagram Protocol (UDP) port numbers, in addition to the source and destination IP addresses, are to be used when selecting a firewall.

Step 8 

Router(config-slb-fw)# replicate casa listen-ip 
remote-ip port [interval] [password [7password 
[timeout]]

(Optional) Configures a stateful backup of IOS Server Load Balancing (IOS SLB) firewall load balancing decision tables to a backup switch.

Step 9 

Router(config-slb-fw)# protocol tcp

(Optional) Enters firewall farm TCP protocol configuration mode.

Step 10 

Router(config-slb-fw-tcp)# delay duration

(Optional) For firewall farm TCP protocol configuration mode, specifies the time IOS Server Load Balancing (IOS SLB) firewall load balancing maintains TCP connection context after a connection has terminated.

Step 11 

Router(config-slb-fw-tcp)# idle duration

(Optional) For firewall farm TCP protocol configuration mode, specifies the minimum time IOS Server Load Balancing (IOS SLB) firewall load balancing maintains connection context in the absence of packet activity.

Step 12 

Router(config-slb-fw-tcp)# maxconns number-of-conns

(Optional) For firewall farm TCP protocol configuration mode, specifies the maximum number of active TCP connections allowed on the firewall farm at one time.

Step 13 

Router(config-slb-fw-tcp)# sticky duration 
[netmask netmask] [source | destination]

(Optional) For firewall farm TCP protocol configuration mode, specifies that connections from the same IP address use the same firewall if either of the following conditions is met:

As long as any connection between the same pair of IP addresses exists (source/destination sticky).

For a period, defined by duration, after the last connection is destroyed.

Step 14 

Router(config-slb-fw)# protocol datagram

(Optional) Enters firewall farm datagram protocol configuration mode.

Step 15 

Router(config-slb-fw-udp)# idle duration

(Optional) For firewall farm datagram protocol configuration mode, specifies the minimum time IOS Server Load Balancing (IOS SLB) firewall load balancing maintains connection context in the absence of packet activity.

Step 16 

Router(config-slb-fw-udp)# maxconns number-of-conns

(Optional) For firewall farm datagram protocol configuration mode, specifies the maximum number of active datagram connections allowed on the firewall farm at one time.

Step 17 

Router(config-slb-fw-udp)# sticky duration 
[netmask netmask] [source | destination]

(Optional) For firewall farm datagram protocol configuration mode, specifies that connections from the same IP address use the same firewall if either of the following conditions is met:

As long as any connection between the same pair of IP addresses exists (source/destination sticky).

For a period, defined by duration, after the last connection is destroyed.

Step 18 

Router(config-slb-fw)# inservice

Enables the firewall farm for use by IOS Server Load Balancing (IOS SLB).

Verifying the Firewall Farm (Optional)

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 real

real                  farm name        weight   state          conns
--------------------------------------------------------------------
10.1.1.2              FIRE1            8        OPERATIONAL    0
10.1.2.2              FIRE1            8        OPERATIONAL    0

The following show ip slb firewallfarm command displays the configuration and status of firewall farm FIRE1:

Router# show ip slb firewallfarm
 
firewall farm    hash        state         reals
------------------------------------------------
FIRE1            IPADDR      INSERVICE     2

Verifying Firewall Connectivity (Optional)

To verify that IOS SLB firewall load balancing has been configured and is operating correctly, use the following procedure:


Step 1 Ping the external real servers (the ones outside the firewall) from the IOS SLB firewall load-balancing switch.

Step 2 Ping the internal real servers (the ones inside the firewall) from the clients.

Step 3 Use the show ip slb stats command to display detailed information about the IOS SLB firewall load-balancing network status:

Router# show ip slb stats
 Pkts via normal switching:  0
 Pkts via special switching: 0
 Pkts dropped:               0
 Connections Created:        1911871
 Connections Established:    1967754
 Connections Destroyed:      1313251
 Connections Reassigned:     0
 Zombie Count:               0
 Connections Reused:         59752
 Connection Flowcache Purges:1776582
 Failed Connection Allocs:   17945
 Failed Real Assignments:    0

Normal 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 Use the show ip slb real detail command to display detailed information about the IOS SLB firewall load-balancing real server status:

Router# show ip slb real detail
10.1.1.3, FIRE1, state = OPERATIONAL, type = firewall
  conns = 299310, dummy_conns = 0, maxconns = 4294967295
  weight = 10, weight(admin) = 10, metric = 104, remainder = 2
  total conns established = 1074779, hash count = 4646
  server failures = 0
  interface FastEthernet1/0, MAC 0010.f68f.7020

Step 5 Use the show ip slb conns command to display detailed information about the active IOS SLB firewall load-balancing connections:

Router# show ip slb conns

vserver         prot client                real                  state     nat 
-------------------------------------------------------------------------------
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none
FirewallTCP     TCP  80.80.50.187:40000    10.1.1.4              ESTAB     none

Step 6 See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB networks and connections.


Configuring Probes (Required)

The Exchange Director 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.

Configuring Wildcard Searches (Optional)

Use the mls ip slb wildcard search rp command to reduce the probability of exceeding the capacity of the TCAM on the PFC.

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.

Configuring a Server Farm and Real Server (Required)

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.

Configuring a Virtual Server (Required)

When you configure the virtual server for VPN server load balancing of IPSec flows, keep the following considerations in mind:

Configure a UDP virtual server, using the virtual command with the protocol set to udp and the port set to isakmp. The isakmp keyword enables the cryptographic key exchange to occur via IKE (port 500).

Configure an ESP virtual server, using the virtual command with the protocol set to esp.

Specify a sticky connection from the UDP virtual server to the ESP virtual server, and vice versa, using the sticky command with a duration of at least 15 seconds.

When you configure the virtual server for VPN server load balancing of PPTP flows, keep the following considerations in mind:

Configure a TCP virtual server, using the virtual command with the tcp keyword and port number 1723 specified.

Configure a GRE virtual server, using the virtual command with the gre keyword specified.

Specify a sticky connection from the TCP virtual server to the GRE virtual server, and vice versa, using the sticky command with a duration of at least 15 seconds.

Configuring Probes (Required)

To verify the health of the server, configure a ping probe.

Home Agent Director Configuration Task List

This section lists the tasks used to configure the Home Agent Director. Detailed configuration information is contained in the referenced sections of this or other documents. Required and optional tasks are indicated.

Configuring a Server Farm and Real Server (Required)

When you configure the server farm and real server for the Home Agent Director, keep the following considerations in mind:

Accept the default setting (the weighted round robin algorithm) for the predictor command.

Specify the IP addresses of the real servers acting as home agents, using the real command.

Configuring a Virtual Server (Required)

When you configure the virtual server for the Home Agent Director using the virtual command, keep the following considerations in mind:

Specify the Home Agent Director's IP address as the virtual server.

Specify the udp keyword option.

Specify port number 434 if the home agents are in compliance with the IP Mobility Support, RFC 2002, or specify port number 0 or any to configure an all-port virtual server (that is, a virtual server that accepts flows destined for all ports).

Specify the service ipmobile keyword option.

Configuring the virtual IP address as a loopback on each of the home agents in the server (Required for dispatched mode)

Refer to the "Configuring a Loopback Interface" section in the Cisco IOS Interface Configuration Guide, Release 12.2 for more information.

Configuring NAT

To configure the IOS SLB NAT client address pool for client NAT, enter the following command in global configuration mode:

Command
Purpose
Router(config)# ip slb natpool pool start-ip end-ip 
[netmask netmask | prefix-length leading-1-bits] 
[entries init-address [max-address]]

Configures the client address pool.

Note GPRS load balancing does not support this command.


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 avoid unexpected results, make sure your static NAT configuration mirrors your virtual server configuration.


To configure NAT for the server, enter the following commands in order, beginning in global configuration mode:

 
Command
Description

Step 1 

Router(config)# ip slb static {drop | 
nat {virtual virtual-ip [per-packet sticky]}}

Configures the real server's Network Address Translation (NAT) behavior and enters static NAT configuration mode.

Note If you specify the virtual-ip argument and you do not specify the per-packet option, IOS Server Load Balancing (IOS SLB) uses server port translation to distinguish between connection requests initiated by different real servers.

Step 2 

Router(config-slb-static)# real ip-address [port]

Configures one or more real servers to use static Network Address Translation (NAT).

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.

Configuring Required and Optional IOS SLB Functions (Required for server load balancing)

Configuring Firewall Load Balancing (Required for firewall load balancing)

Configuring the IP Routing Protocol (Required)

Refer to the "IP Routing Protocols" chapter of the Cisco IOS IP Configuration Guide, Release 12.2 for more details.

Configuring the VLAN between the IOS SLB devices (Required)

Refer to the "Virtual LANs" chapter of the Cisco IOS Switching Services Configuration Guide, Release 12.2 for more details.

Verifying the Stateless Backup Configuration (Optional)


Note For active standby, in which multiple IOS SLB devices share a virtual IP address, you must use exclusive client ranges and you must use policy routing to forward flows to the correct IOS SLB device.


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 vserver

slb vserver      prot  virtual               state         conns   
-------------------------------------------------------------------
VS1              TCP   10.10.10.12:23        OPERATIONAL     2 
VS2              TCP   10.10.10.18:23        OPERATIONAL     2 

Router# show ip slb vserver detail
VS1, state = OPERATIONAL, v_index = 10
  virtual = 10.10.10.12:23, TCP, service = NONE, advertise = TRUE
  server farm = SERVERGROUP1, delay = 10, idle = 3600
  sticky timer = 0, sticky subnet = 255.255.255.255
  sticky group id = 0 
  synguard counter = 0, synguard period = 0
  conns = 0, total conns = 0, syns = 0, syn drops = 0
  standby group = None
VS2, state = INSERVICE, v_index = 11
  virtual = 10.10.10.18:23, TCP, service = NONE, advertise = TRUE
  server farm = SERVERGROUP2, delay = 10, idle = 3600
  sticky timer = 0, sticky subnet = 255.255.255.255
  sticky group id = 0 
  synguard counter = 0, synguard period = 0
  conns = 0, total conns = 0, syns = 0, syn drops = 0
  standby group = None

For 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 firewallfarm
 
firewall farm    hash        state         reals
------------------------------------------------
FIRE1            IPADDR      INSERVICE     2

Router# show ip slb firewallfarm details
FIRE1, hash = IPADDRPORT, state = INSERVICE, reals = 2
  FirewallTCP:
   sticky timer = 0, sticky subnet = 255.255.255.255
   idle = 3600, delay = 10, syns = 1965732, syn drop = 0 
   maxconns = 4294967295, conns = 597445, total conns = 1909512
  FirewallUDP:
   sticky timer = 0, sticky subnet = 255.255.255.255
   idle = 3600
   maxconns = 1, conns = 0, total conns = 1
  Real firewalls:
    10.1.1.3, weight = 10, OPERATIONAL, conns = 298823
    10.1.1.4, weight = 10, OPERATIONAL, conns = 298622
  Total connections = 597445

Stateful Backup of Redundant Route Processors Configuration Task List

This section lists the tasks used to configure stateful backup of redundant route processors. Detailed configuration information is contained in the referenced sections of this document. Required and optional tasks are indicated.

Configuring the Replication Message Rate for Slave Replication (Required)

Specify the ip slb replicate slave rate command in global configuration mode.

Configuring Required and Optional IOS SLB Functions (Required for server load balancing)

When you configure the virtual server for stateful backup of redundant route processors, keep the following considerations in mind:

Specify the replicate slave command.

(Optional) To set the replication delivery interval for the virtual server, configure a replicate interval command.

Configuring Firewall Load Balancing (Required for firewall load balancing)

When you configure the firewall farm for stateful backup of redundant route processors, keep the following considerations in mind:

Specify the replicate slave command.

(Optional) To set the replication delivery interval for the firewall farm, configure a replicate interval command.

Configuring Database Entries

To configure an initial allocation and a maximum value for IOS SLB database entries, enter the following command in global configuration mode:

Command
Purpose
Router(config)# ip slb entries 
[conn [init-conn [max-conn]] | 
frag [init-frag [max-frag] | lifetime timeout] | 
sticky [init-sticky [max-sticky]]]

Specifies an initial allocation and a maximum value for IOS Server Load Balancing (IOS SLB) database entries.


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:

Command
Purpose
Router(config)# ip slb maxbuffers frag buffers

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:

Command
Purpose
Router# clear ip slb connections 
[firewallfarm firewall-farm | serverfarm server-farm | 
vserver virtual-server]

Clears the IOS Server Load Balancing (IOS SLB) connection database for one or more firewall farms, server farms, or virtual servers.

Router# clear ip slb counters

Clears the IOS Server Load Balancing (IOS SLB) counters.

Router# clear ip slb sessions 
[firewallfarm firewall-farm | serverfarm server-farm | 
vserver virtual-server]

Clears the IOS Server Load Balancing (IOS SLB) RADIUS session database for one or more firewall farms, server farms, or virtual servers.

Router# clear ip slb sticky radius 
{calling-station-id [id string] | 
framed-ip [framed-ip [netmask]]}

Clears entries from an IOS Server Load Balancing (IOS SLB) RADIUS sticky database.


Configuring Wildcard Searches

To specify the behavior of IOS SLB wildcard searches, enter the following command in global configuration mode:

Command
Purpose
Router(config)# mls ip slb search 
{wildcard [pfc | rp] | icmp}

Specifies the behavior of IOS Server Load Balancing (IOS SLB) wildcard searches.

This command is supported for Catalyst 6500 Family Switches only.


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:

 
Command
Purpose

Step 1 

Router(config)# ip slb serverfarm server-farm

Enters server farm configuration mode.

Step 2 

Router(config-slb-sfarm)# failaction 
[purge radius reassign]

Configures IOS Server Load Balancing (IOS SLB)'s behavior when a real server fails.

To configure IOS SLB's behavior when a firewall fails, enter the following commands in order, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# ip slb firewallfarm firewall-farm

Enters firewall farm configuration mode.

Step 2 

Router(config-slb-fw)# failaction purge

Configures IOS Server Load Balancing (IOS SLB)'s behavior when a firewall fails.

Disabling Automatic Server Failure Detection

If you have configured all-port virtual servers (that is, virtual servers that accept flows destined for all ports except GTP ports), flows can be passed to servers for which no application port exists. When the servers reject these flows, IOS SLB might fail the servers and remove them from load balancing. This situation can also occur in slow-to-respond AAA servers in RADIUS load-balancing environments. To prevent this situation, you can disable automatic server failure detection.

To disable automatic server failure detection, enter the following command in real server configuration mode:

Command
Purpose
Router(config-slb-real)# no faildetect inband

Disables automatic server failure detection.



Note If you disable automatic server failure detection using the no faildetect inband command, Cisco strongly recommends that you configure one or more probes.

If you specify the no faildetect inband command, the faildetect numconns command is ignored, if specified.


Monitoring and Maintaining the IOS SLB Feature

To obtain and display runtime information about IOS SLB, use the following commands in EXEC mode:

Command
Purpose
Router# show ip slb conns [vserver virtual-server | 
client ip-address | firewall firewall-farm] [detail]

Displays all connections handled by IOS Server Load Balancing (IOS SLB), or, optionally, only those connections associated with a particular virtual server or client.

Router# show ip slb dfp [agent agent-ip port | 
manager manager-ip | detail | weights]

Displays information about Dynamic Feedback Protocol (DFP) and DFP agents, and about the weights assigned to real servers.

Router# show ip slb firewallfarm [detail]

Displays information about firewall farms.

Router# show ip slb fragments

Displays information from the IOS Server Load Balancing (IOS SLB) fragment database.

Router# show ip slb gtp {gsn [gsn-ip-address] | 
nsapi [nsapi-key] [detail]

Displays IOS Server Load Balancing (IOS SLB) GTP information.

Router# show ip slb natpool [name pool] [detail]

Displays information about the IOS Server Load Balancing (IOS SLB) Network Address Translation (NAT) configuration.

Router# show ip slb probe [name probe] [detail]

Displays information about probes defined to IOS Server Load Balancing (IOS SLB).

Router# show ip slb reals [sfarm server-farm] [detail]

Displays information about the real servers defined to IOS Server Load Balancing (IOS SLB).

Router# show ip slb replicate

Displays information about the IOS Server Load Balancing (IOS SLB) replication configuration.

Router# show ip slb serverfarms [name server-farm] [detail]

Displays information about the server farms defined to IOS Server Load Balancing (IOS SLB).

Router# show ip slb sessions 
[gtp gtp-inspect ipmobile radius] 
[vserver virtual-server] [client ip-address netmask] [detail]

Displays information about sessions handled by IOS Server Load Balancing (IOS SLB).

Router# show ip slb static

Displays information about the IOS Server Load Balancing (IOS SLB) server Network Address Translation (NAT) configuration.

Router# show ip slb stats

Displays IOS Server Load Balancing (IOS SLB) statistics.

Router# show ip slb sticky [client ip-address netmask | 
radius calling-station-id [id string] | 
radius framed-ip [client ip-address netmask] | 
radius username [name string]]

Displays information about the sticky connections defined to IOS Server Load Balancing (IOS SLB).

Router# show ip slb vserver [name virtual-server] [redirect] 
[detail]

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).


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:

Basic IOS SLB Network Configuration Example

Complete IOS SLB Configuration Example

IOS SLB with Firewall Load Balancing Example

IOS SLB with Server Load Balancing and Firewall Load Balancing Example

IOS SLB with Multiple Firewall Farms Example

IOS SLB with Probes Example

IOS SLB with Routed Probe Example

Layer 3 Switch Configured with IOS SLB Example

IOS SLB with NAT Example

IOS SLB with Static NAT Example

IOS SLB with Stateless Backup Examples

IOS SLB with Stateful Backup Example

IOS SLB with Stateful Backup of Redundant Route Processors Example

IOS SLB with Active Standby Example

IOS SLB with Redistribution of Static Routes Example

IOS SLB with WAP and UDP Load Balancing Examples

IOS SLB with Route Health Injection Examples

IOS SLB with GPRS Load Balancing Example

IOS SLB with GPRS Load Balancing and NAT Example

IOS SLB with GPRS Load Balancing, NAT, and GTP Cause Code Inspection Example

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 Home Agent Director Example

IOS SLB with Sticky Connections Example

IOS SLB with Transparent Web Cache Load Balancing


Note The IP and network addresses in these examples are generic; you must replace them with the actual addresses for your network.


Basic IOS SLB Network Configuration Example

Figure 2 shows a sample IOS SLB network with the following components:

Two server farms—one configured to allow access by the public and named PUBLIC, one configured to allow limited access and named RESTRICTED.

Five real servers configured as follows:

Three real servers in the PUBLIC server farm with IP addresses 10.1.1.1, 10.1.1.2, and 10.1.1.3

Two real servers in the restricted server farm with IP addresses 10.1.1.20 and 10.1.1.21

Two virtual servers—one configured to allow access by the public and named PUBLIC_HTTP and one configured to allow limited access and named RESTRICTED_HTTP.

Virtual server PUBLIC_HTTP is configured with IP address 10.0.0.1 load balancing TCP connections on the WWW port (80).

Virtual server RESTRICTED_HTTP is configured with IP address 10.0.0.2 load balancing TCP connections on the WWW port (80) and allows access only from clients from network 10.4.4.0 255.255.255.0.

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

Virtual Server Configuration

Restricted Client Configuration

Server Farm Configuration

The following example shows the configuration for the server farm PUBLIC, associated with three real servers:

ip slb serverfarm PUBLIC
  real 10.1.1.1
    reassign 2
    faildetect numconns 4 numclients 2
    retry 20
    inservice
    exit
  real 10.1.1.2
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
    exit
  real 10.1.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
    end

The following example shows the configuration for the server farm RESTRICTED, associated with two real servers:

ip slb serverfarm RESTRICTED
  real 10.1.1.20
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
    exit
  real 10.1.1.21
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
    end

Virtual Server Configuration

The following example shows the configuration for the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:

ip slb vserver PUBLIC_HTTP
  virtual 10.0.0.1 tcp www
  serverfarm PUBLIC
  idle 120
  delay 5
  inservice
  exit
ip slb vserver RESTRICTED_HTTP
  virtual 10.0.0.2 tcp www
  serverfarm RESTRICTED
  idle 120
  delay 5
  inservice
  end

Restricted Client Configuration

The following example shows the configuration for the virtual server RESTRICTED_HTTP:

ip slb vserver RESTRICTED_HTTP
  no inservice
  client 10.4.4.0 255.255.255.0
  inservice
  end

Complete 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 http
 request method POST url /probe.cgi?all
 header HeaderName HeaderValue
!
ip slb serverfarm PUBLIC
 nat server
 real 10.1.1.1
  reassign 4
  faildetect numconns 16
  retry 120
  inservice
 real 10.1.1.2
  reassign 4
  faildetect numconns 16
  retry 120
  inservice
probe PROBE2
!
ip slb serverfarm RESTRICTED
 predictor leastconns
 bindid 309
 real 10.1.1.1
  weight 32
  maxconns 1000
  reassign 4
  faildetect numconns 16
  retry 120
  inservice
 real 10.1.1.20
  reassign 4
  faildetect numconns 16
  retry 120
  inservice
 real 10.1.1.21
  reassign 4
  faildetect numconns 16
  retry 120
  inservice
!
ip slb vserver PUBLIC_HTTP
 virtual 10.0.0.1 tcp www
 serverfarm PUBLIC
!



ip slb vserver RESTRICTED_HTTP
 virtual 10.0.0.2 tcp www
 serverfarm RESTRICTED
 no advertise
 sticky 60 group 1
 idle 120
 delay 5
 client 10.4.4.0 255.255.255.0
 synguard 3600000
 inservice

IOS SLB with Firewall Load Balancing Example

Figure 3 shows a sample IOS SLB firewall load-balancing network with the following components:

Two firewalls with IP addresses as shown

An internal firewall load-balancing device on the secure side of the firewalls

An external firewall load-balancing device on the Internet side of the firewalls

One firewall farm named FIRE1, containing both firewalls

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:

The internal (secure side) firewall load-balancing device is configured with firewall IP addresses 10.1.3.1 and 10.1.4.1.

The external (Internet side) firewall load-balancing device is configured with firewall IP addresses 10.1.1.2 and 10.1.2.2.

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 probe
ip slb probe PROBE1 ping
!-----IP address of other load-balancing device
  address 10.1.1.1
  faildetect 4
!-----HTTP probe
  ip slb probe PROBE2 http
!-----IP address of other load-balancing device
  address 10.1.2.1
  expect status 401
!-----Firewall farm FIRE1
ip slb firewallfarm FIRE1
!-----First firewall
  real 10.1.4.1
    probe PROBE1
!-----Enable first firewall
    inservice
!-----Second firewall
    real 10.1.3.1
    probe PROBE2
!-----Enable second firewall
    inservice

External 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 probe
ip slb probe PROBE1 ping
!-----IP address of other load-balancing device
  address 10.1.4.2
  faildetect 4
!-----HTTP probe
ip slb probe PROBE2 http
!-----IP address of other load-balancing device
  address 10.1.3.2
  expect status 401
!-----Firewall farm FIRE1
ip slb firewallfarm FIRE1
!-----First firewall
  real 10.1.1.2
    probe PROBE1
!-----Enable first firewall
    inservice

!-----Second firewall
  real 10.1.2.2
    probe PROBE2
!-----Enable second firewall
    inservice
    exit
  inservice

IOS 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:

Two real servers with IP addresses as shown

One server farm named PUBLIC, containing both real servers

Two firewalls with IP addresses as shown

One firewall farm named FIRE1, containing both firewalls

An internal IOS SLB device on the secure side of the firewalls, performing server load balancing and firewall load balancing

An external firewall load-balancing device on the Internet side of the firewalls

Figure 4 IOS SLB with Server Load Balancing and Firewall Load Balancing

In the following firewall farm configuration samples:

The internal (secure side) firewall load-balancing device is configured with firewall IP addresses 10.1.3.1 and 10.1.4.1.

The external (Internet side) firewall load-balancing device is configured with firewall IP addresses 10.1.1.2 and 10.1.2.2.

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 ping
  address 10.1.1.1
ip slb probe XYZPROBE ping
  address 10.1.2.1
!
ip slb firewallfarm FIRE1
  real 10.1.4.1
    probe ABCPROBE
    inservice


  real 10.1.3.1
    probe XYZPROBE
    inservice
  inservice
!
ip slb serverfarm PUBLIC
  nat server
  real 10.2.1.1
    inservice
    real 10.2.1.2
    inservice
!
ip slb vserver HTTP1
  virtual 128.1.0.1 tcp www
  serverfarm PUBLIC
  idle 120
  delay 5
  inservice

Note On Catalyst 6500 Family Switches, you can also specify that IOS SLB wildcard searches are to be performed by the route processor, using the mls ip slb search wildcard rp command in global configuration mode.


External 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 ping
  address 10.1.4.2
  ip slb probe XYZPROBE ping
  address 10.1.3.2
  ip slb firewallfarm FIRE1
  real 10.1.1.2
    probe ABCPROBE
    inservice
    probe XYZPROBE
    inservice

IOS SLB with Multiple Firewall Farms Example

Figure 5 shows a sample IOS SLB load-balancing network with multiple firewall farms and the following components:

Four firewalls with IP addresses as shown

An internal firewall load-balancing device on the secure side of the firewalls

An external firewall load-balancing device on the Internet side of the firewalls

One firewall farm named ABCFARM, containing the two firewalls on the left.

One firewall farm named XYZFARM, containing the two firewalls on the right.

Figure 5 IOS SLB with Multiple Firewall Farms

In the following firewall farm configuration samples:

The internal (secure side) firewall load-balancing device is configured with firewall IP addresses 10.1.3.1 and 10.1.4.1.

The external (Internet side) firewall load-balancing device is configured with firewall IP addresses 10.1.1.2 and 10.1.2.2.

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 ping
  address 10.1.2.1
ip slb probe XYZPROBE ping
  address 10.1.1.1
ip slb firewallfarm ABCFARM
  access source 10.1.6.0 255.255.255.0
  inservice
  real 10.1.4.2
    probe ABCPROBE
    inservice
  real 10.1.4.3
    probe ABCPROBE
    inservice
ip slb firewallfarm XYZFARM
  access source 10.1.5.0 255.255.255.0
  inservice
  real 10.1.3.2
    probe XYZPROBE
    inservice
  real 10.1.3.3
    probe XYZPROBE
    inservice

External 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 ping
  address 10.1.4.1
ip slb probe XYZPROBE ping
  address 10.1.3.1
ip slb firewallfarm ABCFARM
  access destination 10.1.6.0 255.255.255.0
  inservice
  real 10.1.2.2
    probe ABCPROBE
    inservice
  real 10.1.2.3
    probe ABCPROBE
    inservice
ip slb firewallfarm XYZFARM
  access destination 10.1.5.0 255.255.255.0
  inservice
  real 10.1.1.2
    probe XYZPROBE
    inservice
  real 10.1.1.3
    probe XYZPROBE
    inservice

IOS 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 mode
ip slb probe PROBE1 ping
! Configure probe to receive responses from IP address 13.13.13.13
  address 13.13.13.13
! Configure unacknowledged ping threshold to 16
  faildetect 16
! Configure ping probe timer interval to send every 11 seconds
  interval 11
! Configure HTTP probe PROBE2
  ip slb probe PROBE2 http
! Configure request method as POST, set URL as /probe.cgi?all
  request method post url /probe.cgi?all
! Configure header HeaderName
  header HeaderName HeaderValue
! Configure basic authentication username and password
  credentials Semisweet chips
! Exit to global configuration mode
  exit



! Enter server farm configuration mode for server farm PUBLIC
ip slb serverfarm PUBLIC
! Configure NAT server and real servers on the server farm
  nat server
  real 10.1.1.1
   inservice
  real 10.1.1.2
   inservice
  real 10.1.1.3
   inservice
  real 10.1.1.4
   inservice
  real 10.1.1.5
   inservice
! Configure ping probe on the server farm
  probe PROBE1
! Configure HTTP probe on the server farm
  probe PROBE2
  end

IOS 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 ping
  address 10.10.10.3 routed

ip slb serverfarm ACME_SFARM
  nat server
  probe BACKEND
  real 10.10.10.1
   inservice
  real 10.10.10.2
   inservice
ip slb vserver ACME_VSERVER
  virtual 10.10.10.10 tcp 80
  serverfarm ACME_SFARM
  inservice	

Layer 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 http
  request method POST url /probe.cgi?all
  header HeaderName HeaderValue
  header Authorization Basic U2VtaXN3ZWV0OmNoaXBz
!
ip slb serverfarm PUBLIC
  nat server
  predictor leastconns
! First real server
  real 10.1.1.1
    reassign 4
    faildetect numconns 16
    retry 120
    inservice
! Second real server
  real 10.1.1.2
    reassign 4
    faildetect numconns 16
    retry 120
    inservice
! Third real server
  real 10.1.1.3
    reassign 4
    faildetect numconns 16
    retry 120
    inservice
! Probe
  probe PROBE2
! Restricted web server farm
ip slb serverfarm RESTRICTED
  predictor leastconns
! First real server
  real 10.1.1.20
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
! Second real server
  real 10.1.1.21
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
!
! Unrestricted web virtual server
ip slb vserver PUBLIC_HTTP
  virtual 10.0.0.1 tcp www
  serverfarm PUBLIC
  idle 120
  delay 5
  inservice
!
! Restricted HTTP virtual server
ip slb vserver RESTRICTED_HTTP
  virtual 10.0.0.1 tcp www
  serverfarm RESTRICTED
  client 10.4.4.0 255.255.255.0
  sticky 60 group 1
  idle 120
  delay 5
  inservice
!
! Restricted SSL virtual server
ip slb vserver RESTRICTED_SSL
  virtual 10.0.0.1 tcp https
  serverfarm RESTRICTED
  client 10.4.4.0 255.255.255.0
  sticky 60 group 1
  idle 120
  delay 5
  inservice
!
interface GigabitEthernet1/1
  switchport
  switchport access vlan 3
  switchport mode access
  no ip address
!
interface FastEthernet2/1
  switchport
  switchport access vlan 2
  switchport mode access
  no ip address
!
interface FastEthernet2/2
  switchport
  switchport access vlan 2
  switchport mode access
  no ip address
!
interface FastEthernet2/3
  switchport
  switchport access vlan 2
  switchport mode access
  no ip address
!
interface Vlan2
  ip address 10.1.1.100 255.255.255.0
!
interface Vlan3
  ip address 40.40.40.1 255.255.255.0

IOS 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:

Servers 1, 2, and 3 are running single HTTP server applications listening on port 80.

Server 4 has multiple HTTP server applications listening on ports 8080, 8081, and 8082.

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 addresses
  nat server
! Server 1 port 80
  real 10.1.1.1
    reassign 2
    faildetect numconns 4 numclients 2
    retry 20
    inservice
! Server 2 port 80
  real 10.2.1.1
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
!
ip slb vserver HTTP1
! Handle HTTP (port 80) requests
  virtual 128.1.0.1 tcp www
  serverfarm FARM1
  idle 120
  delay 5
  inservice

Switch B Configuration Statements

ip slb natpool web-clients 128.3.0.1 128.3.0.254
! NAT address pool for clients
ip slb serverfarm FARM2
! Translate server addresses
  nat server
! Translate client addresses
  nat client web-clients
! Server 3 port 80
  real 10.3.1.1
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
! Server 4 port 8080
  real 10.4.1.1 port 8080
    reassign 2
    faildetect numconns 4
    retry 20
    inservice


! Server 4 port 8081
  real 10.4.1.1 port 8081
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
! Server 4 port 8082
  real 10.4.1.1 port 8082
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
!
ip slb vserver HTTP2
! Handle HTTP (port 80) requests
  virtual 128.2.0.1 tcp www
  serverfarm FARM2
  idle 120
  delay 5
  inservice

Switch C Configuration Statements

ip slb natpool web-clients 128.5.0.1 128.5.0.254
! NAT address pool for clients
ip slb serverfarm FARM2
! Translate server addresses
  nat server
! Translate client addresses
  nat client web-clients 
! Server 3 port 80
  real 10.3.1.1
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
! Server 4 port 8080
  real 10.4.1.1 port 8080
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
! Server 4 port 8081
  real 10.4.1.1 port 8081
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
! Server 4 port 8082
  real 10.4.1.1 port 8082
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
!
ip slb vserver HTTP2
! Handle HTTP (port 80) requests
  virtual 128.4.0.1 tcp www
  serverfarm FARM2
  idle 120
  delay 5
  inservice

IOS SLB with Static NAT Example

The following example shows configuration statements for the following items:

A DNS probe, PROBE4, configured to supply real server IP address 13.13.13.13 in response to domain name resolve requests.

A server farm, DNS, that is configured to use server NAT and PROBE4.

An all-port virtual server, 10.11.11.11, associated with server farm DNS, that performs per-packet server load balancing for UDP connections.

A real server, 10.0.0.0, associated with server farm DNS, configured for static NAT and per-packet server load balancing.

ip slb probe PROBE4 dns
 lookup 13.13.13.13
!
ip slb serverfarm DNS
 nat server
 probe PROBE4
 real 10.0.0.0
  inservice
!
ip slb vserver DNS
 virtual 10.11.11.11 UDP 0 service per-packet
 serverfarm DNS
!
ip slb static nat 10.11.11.11 per-packet
 real 10.0.0.0

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

If a load balancing device is capable of Layer 2 switching and VLAN trunking (such as the Catalyst 6500 Family Switch), you can wire the device directly to its real servers, and it can handle outbound flows from the real servers while acting as a standby for IOS SLB. HSRP is used on the server-side VLANs of the load balancing device, with the real servers routing to the HSRP address.

If a load balancing device is not capable of both Layer 2 switching and VLAN trunking, you must connect it and its real servers to a Layer 2 switch. This configuration is required in order to use HSRP on the server-side VLANs.

If a distribution device is capable of Layer 3 switching, it can use route redistribution to direct flows to the active load balancing device.

If a distribution device is capable of Layer 2 switching, it can use client-side HSRP on the load balancing device to direct flows to the active load balancing device.

While HSRP offers faster failover times, routing converges quickly enough for most configurations. If you use both client-side and server-side HSRP on the load balancing devices, you must use HSRP interface tracking and priorities to synchronize the client-side and server-side HSRP groups.

This section contains the following examples, illustrating several different IOS SLB stateless backup configurations:

Dynamic Routing and Trunking Example

Dynamic Routing and No Trunking Example

Static Routing and Trunking Example

Static Routing and No Trunking Example


Note Stateful backup is omitted from these examples in the interest of simplicity. To see an example that uses stateful backup, see the "IOS SLB with Stateful Backup Example" section.


Dynamic Routing and Trunking Example

Figure 10 shows a sample IOS SLB stateless backup configuration with the following characteristics:

The IP address for real server 1 is 10.10.1.3, and for real server 2 is 10.10.1.4, routed to clients through 10.10.1.100.

The IP address for the virtual server is 10.10.14.1.

The IP address for VLAN 1 is 10.10.1.0, with a subnet mask of 255.255.255.0.

The IP address for Subnet 2 is 10.10.2.0, with a subnet mask of 255.255.255.0.

The IP address for Subnet 3 is 10.10.3.0, with a subnet mask of 255.255.255.0.

The distribution device uses EIGRP to learn the route to 10.10.14.1 via either 10.10.2.1 or 10.10.3.1, depending on which IOS SLB is active.

Figure 10 Stateless Backup with Layer 3 and Trunking

SLB 1 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4 numclients 2
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface Ethernet1
  switchport
  switchport vlan 1
interface Ethernet2
  ip address 10.10.2.1 255.255.255.0
interface vlan 1
  ip address 10.10.1.1 255.255.255.0
  standby ip 10.10.1.100
  standby priority 10 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3
router eigrp 666
  redistribute static
  network 10.0.0.0

SLB 2 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface GigabitEthernet1
  no ip address
  switchport
  switchport trunk encapsulation isl
interface Ethernet1
  switchport
  switchport vlan 1
interface Ethernet2
  ip address 10.10.3.1 255.255.255.0
interface vlan 1
  ip address 10.10.1.2 255.255.255.0
  standby ip 10.10.1.100
  standby priority 5 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3
router eigrp 666
  redistribute static
  network 10.0.0.0

Dynamic Routing and No Trunking Example

Figure 11 shows a sample IOS SLB stateless backup configuration with the following characteristics:

The IP address for real server 1 is 10.10.1.3, and for real server 2 is 10.10.1.4, routed to clients through 10.10.1.100.

The IP address for the virtual server is 10.10.14.1.

The IP address for Subnet 2 is 10.10.2.0, with a subnet mask of 255.255.255.0.

The IP address for Subnet 3 is 10.10.3.0, with a subnet mask of 255.255.255.0.

The distribution device uses EIGRP to learn the route to 10.10.14.1 via either 10.10.2.2 or 10.10.3.2, depending on which IOS SLB is active.

Figure 11 Stateless Backup with Layer 3 and No Trunking

SLB 1 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface Ethernet1
  ip address 10.10.1.1 255.255.255.0
  standby ip 10.10.1.100
  standby priority 10 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3
interface Ethernet2
  ip address 10.10.2.1 255.255.255.0
router eigrp 666
  redistribute static
  network 10.0.0.0

SLB 2 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface Ethernet1
  ip address 10.10.1.2 255.255.255.0
  standby ip 10.10.1.100
  standby priority 5 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3
interface Ethernet2
  ip address 10.10.3.1 255.255.255.0

router eigrp 666
  redistribute static
  network 10.0.0.0

Static Routing and Trunking Example

Figure 12 shows a sample IOS SLB stateless backup configuration with the following characteristics:

The IP address for real server 1 is 10.10.1.3, and for real server 2 is 10.10.1.4, routed to clients through 10.10.1.100.

The IP address for the virtual server is 10.10.14.1.

The IP address for VLAN 1 is 10.10.1.0, with a subnet mask of 255.255.255.0.

The IP address for Subnet 2 is 10.10.2.0, with a subnet mask of 255.255.255.0.

The IP address for Subnet 3 is 10.10.3.0, with a subnet mask of 255.255.255.0.

The configuration uses static routing to the HSRP route on the distribution device.

Figure 12 Stateless Backup with Layer 2 and Trunking

SLB 1 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface Ethernet1
  switchport
  switchport vlan 1
interface Ethernet2
  ip address 10.10.2.1 255.255.255.0
  standby ip 10.10.2.100
  standby priority 10 preempt delay sync 20
  standby track vlan1
  standby timers 1 3
interface vlan 1
  ip address 10.10.1.1 255.255.255.0
  standby ip 10.10.1.100
  standby priority 10 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3

SLB 2 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface GigabitEthernet1
  no ip address
  switchport
  switchport trunk encapsulation isl
interface Ethernet1
  switchport
  switchport vlan 1
interface Ethernet2
  ip address 10.10.2.2 255.255.255.0
  standby ip 10.10.2.100
  standby priority 5 preempt delay sync 20
  standby track vlan 1
  standby timers 1 3
interface vlan 1
  ip address 10.10.1.2 255.255.255.0
  standby ip 10.10.1.100
  standby priority 5 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3

Distribution Device Configuration Statements

interface Ethernet1
  switchport
  switchport distribution vlan 2
interface Ethernet2
  switchport
  switchport distribution vlan 2
interface vlan2
  ip address 10.10.2.3 255.255.255.0
  no shut
ip route 10.10.14.1 255.255.255.255 10.10.2.100

Static Routing and No Trunking Example

Figure 13 shows a sample IOS SLB stateless backup configuration with the following characteristics:

The IP address for real server 1 is 10.10.1.3, and for real server 2 is 10.10.1.4, routed to clients through 10.10.1.100.

The IP address for the virtual server is 10.10.14.1.

The IP address for Subnet 2 is 10.10.2.0, with a subnet mask of 255.255.255.0.

The IP address for Subnet 3 is 10.10.3.0, with a subnet mask of 255.255.255.0.

The configuration uses static routing to the HSRP route on the distribution device.

Figure 13 Stateless Backup with Layer 2 and No Trunking

SLB 1 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface Ethernet1
  ip address 10.10.1.1 255.255.255.0
  standby ip 10.10.1.100
  standby priority 10 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3
interface Ethernet2
  ip address 10.10.2.1 255.255.255.0
  standby ip 10.10.2.100
  standby priority 10 preempt delay sync 20
  standby track Ethernet1
  standby timers 1 3

SLB 2 Configuration Statements

ip slb serverfarm SF1
  real 10.10.1.3
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
  real 10.10.1.4
    reassign 2
    faildetect numconns 4
    retry 20
    inservice
ip slb vserver VS1
  virtual 10.10.14.1 tcp www
  serverfarm SF1
  idle 120
  delay 5
  inservice standby SERVER
!
interface Ethernet1
  ip address 10.10.1.2 255.255.255.0
  standby ip 10.10.1.100
  standby priority 5 preempt delay sync 20
  standby name SERVER
  standby track Ethernet2
  standby timers 1 3


interface Ethernet2
  ip address 10.10.2.2 255.255.255.0
  standby ip 10.10.2.100
  standby priority 5 preempt delay sync 20
  standby track Ethernet1
  standby timers 1 3

Distribution Device Configuration Statements

interface Ethernet1
  switchport
  switchport distribution vlan 2
interface Ethernet2
  switchport
  switchport distribution vlan 2
interface vlan2
  ip address 10.10.2.3 255.255.255.0
  no shut
ip route 10.10.14.1 255.255.255.255 10.10.2.100

IOS 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 To allow HSRP to function properly, the set spantree portfast command must be configured on any Layer 2 device between the IOS SLB switches.


Figure 14 IOS SLB Stateful Environment

Switch SLB1 Configuration Statements

ip slb serverfarm SF1
  nat server
  real 10.10.3.1
   inservice
  real 10.10.3.2
   inservice
  real 10.10.3.3
   inservice
!
ip slb vserver VS1
  virtual 10.10.10.12 tcp telnet
  serverfarm SF1
  replicate casa 10.10.99.132 10.10.99.99 1024 password PASS
  inservice standby virt
!
interface loopback 1
  ip address 10.10.99.132 255.255.255.255
!
interface FastEthernet1
  ip address 10.10.3.132 255.255.255.0
  no ip redirects
  no ip mroute-cache
  standby priority 5 preempt
  standby name out
  standby ip 10.10.3.100
  standby track FastEthernet2
  standby timers 1 3
interface FastEthernet2
  ip address 10.10.2.132 255.255.255.0
  no ip redirects
  standby priority 5
  standby name virt
  standby ip 10.10.2.100
  standby timers 1 3

Switch SLB2 Configuration Statements

ip slb serverfarm SF1
  nat server
  real 10.10.3.1
   inservice
  real 10.10.3.2
   inservice
  real 10.10.3.3
   inservice
!
ip slb vserver VS1
  virtual 10.10.10.12 tcp telnet
  serverfarm SF1
  replicate casa 10.10.99.99 10.10.99.132 1024 password PASS
  inservice standby virt
!
interface loopback 1
  ip address 10.10.99.99 255.255.255.255
!
interface FastEthernet2
  ip address 10.10.2.99 255.255.255.0
  no ip redirects
  no ip route-cache
  no ip mroute-cache
  standby priority 10 preempt delay sync 20
  standby name virt
  standby ip 10.10.2.100
  standby track FastEthernet3
  standby timers 1 3
!
interface FastEthernet3
  ip address 10.10.3.99 255.255.255.0
  no ip redirects
  no ip route-cache
  no ip mroute-cache
  standby priority 10 preempt delay 20
  standby name out
  standby ip 10.10.3.100
  standby track FastEthernet2
  standby timers 1 3

IOS SLB with Stateful Backup of Redundant Route Processors Example

In Figure 15, the IOS SLB device includes two supervisor engines configured for stateful backup. If the active supervisor engine fails, the backup supervisor engine takes over via RPR+ with IOS SLB synchronization information already populated. IOS SLB replicates state information for virtual server ACME_VSERVER (10.10.10.10) from the active supervisor engine to the backup every 20 seconds. The real servers (10.10.10.1, 10.10.10.2, and 10.10.10.3) are configured in server farm ACME_SFARM.

Figure 15 IOS SLB with Redundant Route Processors

Following are the IOS SLB configuration statements for the configuration shown in Figure 15:

ip slb replicate slave rate 300

ip slb serverfarm ACME_SFARM
  nat server
  real 10.10.10.1
   inservice
  real 10.10.10.2
   inservice
  real 10.10.10.3
   inservice

ip slb vserver ACME_VSERVER
 virtual 10.10.10.10 tcp 80
 replicate interval 20
 replicate slave
 serverfarm ACME_SFARM
 inservice

IOS SLB with Active Standby Example

Figure 16 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 16 IOS SLB Active Standby

The sample network configuration in Figure 16 has the following characteristics:

SLB 1 balances servers 1A and 1B and SLB 2 balances 2A and 2B.

A single virtual IP address (10.10.10.12 for web) is supported across the two IOS SLB devices.

Client traffic is divided in an access router, sending clients with even IP addresses to HSRP1 (10.10.5.100) and clients with odd IP addresses to HSRP2 (10.10.2.100). SLB 1 is configured as primary for clients with odd IP addresses, and SLB 2 is primary for clients with even IP addresses.

The IOS SLB devices balance the traffic to disjoint sets of real servers. (If client NAT was used in this example, this characteristic would not be a requirement).

Each set of real servers has a default gateway configured to its IOS SLB device.

The HSRP address on VLAN 105 is 10.10.5.100. The HSRP address on VLAN 102 is 10.10.2.100.

SLB 1 Configuration Statements

ip slb serverfarm EVEN
 nat server
 real 10.10.3.2
  reassign 2
  faildetect numconns 4 numclients 2
  retry 20
  inservice
 real 10.10.3.3
  reassign 2
  faildetect numconns 4
  retry 20
  inservice
!
ip slb serverfarm ODD
 nat server
 real 10.10.3.2
  reassign 2
  faildetect numconns 4
  retry 20
  inservice
 real 10.10.3.3
  reassign 2
  faildetect numconns 4
  retry 20
  inservice
!-----Same EVEN virtual server as in SLB 2
ip slb vserver EVEN
 virtual 10.10.10.12 tcp www
 serverfarm EVEN
 client 0.0.0.0 0.0.0.1
 idle 120
 delay 5
!-----See standby name in Ethernet 3/3 below
 inservice standby STANDBY_EVEN
!-----Same ODD virtual server as in SLB 2
ip slb vserver ODD
 virtual 10.10.10.12 tcp www
 serverfarm ODD
 client 0.0.0.1 0.0.0.1
 idle 120
 delay 5
!-----See standby name in Ethernet 3/2 below
 inservice standby STANDBY_ODD
!
interface Ethernet3/2
 ip address 10.10.5.132 255.255.255.0
 standby priority 20 preempt delay sync 20
!-----See standby name in SLB 2, Ethernet 3/5
 standby name STANDBY_ODD
 standby ip 10.10.5.100
 standby track Ethernet3/3
 standby timers 1 3
!
interface Ethernet3/3
 ip address 10.10.2.132 255.255.255.0
 standby priority 10
!-----See standby name in SLB 2, Ethernet 3/1
 standby name STANDBY_EVEN
 standby ip 10.10.2.100
 standby track Ethernet3/2
 standby timers 1 3

SLB 2 Configuration Statements

ip slb serverfarm EVEN
 nat server
 real 10.10.3.4
  reassign 2
  faildetect numconns 4
  retry 20
  inservice
 real 10.10.3.5
  reassign 2
  faildetect numconns 4
  retry 20
  inservice
!
ip slb serverfarm ODD
 nat server
 real 10.10.3.4
  reassign 2
  faildetect numconns 4
  retry 20
  inservice
 real 10.10.3.5
  reassign 2
  faildetect numconns 4
  retry 20
  inservice
!-----Same EVEN virtual server as in SLB 1
ip slb vserver EVEN
 virtual 10.10.10.12 tcp www
 serverfarm EVEN
 client 0.0.0.0 0.0.0.1
 idle 120
 delay 5
!-----See standby name in Ethernet 3/1 below
 inservice standby STANDBY_EVEN
!-----Same ODD virtual server as in SLB 1
ip slb vserver ODD
 virtual 10.10.10.12 tcp www
 serverfarm ODD
 client 0.0.0.1 0.0.0.1
 idle 120
 delay 5
!-----See standby name in Ethernet 3/5 below
 inservice standby STANDBY_ODD
!
interface Ethernet3/1
 ip address 10.10.2.128 255.255.255.0
 standby priority 20 preempt delay sync 20
!-----See standby name in SLB 1, Ethernet 3/3
 standby name STANDBY_EVEN
 standby ip 10.10.2.100
 standby track Ethernet3/5
 standby timers 1 3
!
interface Ethernet3/5
 ip address 10.10.5.128 255.255.255.0
 standby priority 10 preempt delay sync 20
!-----See standby name in SLB 1, Ethernet 3/2
 standby name STANDBY_ODD
 standby ip 10.10.5.100
 standby track Ethernet3/1
 standby timers 1 3

Access Router Configuration Statements

interface Ethernet0/0
 ip address 10.10.5.183 255.255.255.0
 no ip directed-broadcast
 no ip route-cache
 no ip mroute-cache
!
interface Ethernet0/1
 ip address 10.10.2.183 255.255.255.0
 no ip directed-broadcast
 no ip route-cache
 no ip mroute-cache
!
interface Ethernet0/2
 ip address 10.10.6.183 255.255.255.0
 no ip directed-broadcast
 no ip route-cache
 no ip mroute-cache
 ip policy route-map virts
!
access-list 100 permit ip 0.0.0.1 255.255.255.254 host 10.10.10.12
access-list 101 permit ip 0.0.0.0 255.255.255.254 host 10.10.10.12
route-map virts permit 10
match ip address 100
set ip next-hop 10.10.5.100
!
route-map virts permit 15
match ip address 101
set ip next-hop 10.10.2.100

IOS SLB with Redistribution of Static Routes Example

Figure 17 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 17 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 17:

router rip
 redistribute static
 network 10.0.0.0
 network 8.0.0.0

Following is the RIP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 17:

router rip
 network 10.0.0.0
 network 8.0.0.0

Open Shortest Path First (OSPF)

Following is the OSPF static route redistribution configuration for the IOS SLB switch shown in Figure 17:

router ospf 1
 redistribute static subnets
 network 10.10.6.217 0.0.0.0 area 0
 network 8.8.8.0 0.0.0.255 area 0

Following is the OSPF static route redistribution configuration for the access router that is listening for routing updates shown in Figure 17:

router ospf 1
 network 10.10.6.2 0.0.0.0 area 0
 network 8.8.8.0 0.0.0.255 area 0

Interior Gateway Routing Protocol (IGRP)

Following is the IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 17:

router igrp 1
 redistribute connected
 redistribute static
 network 8.0.0.0
 network 10.0.0.0

Following is the IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 17:

router igrp 1
 network 8.0.0.0
 network 10.0.0.0

Enhanced Interior Gateway Routing Protocol (Enhanced IGRP)

Following is the Enhanced IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 17:

router eigrp 666
 redistribute static
 network 10.0.0.0
 network 8.0.0.0

Following is the Enhanced IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 17:

router eigrp 666
 network 10.0.0.0
 network 8.0.0.0

IOS SLB with WAP and UDP Load Balancing Examples

Figure 18 shows an IOS SLB network configured to balance WAP flows. In this example:

WAP flows are balanced between WAP gateways 10.10.2.1, 10.10.2.2, and 10.10.2.3.

The clients connect to 10.10.1.1, the IOS SLB virtual server address.

For a given session, load-balancing decisions change if the connection idles longer than the virtual server's idle connection timer (3000 seconds in this example).

Figure 18 IOS SLB with WAP Load Balancing

There are two ways to configure IOS SLB load balancing for WAP:

To load-balance sessions running in connection-oriented WSP mode, define a WSP probe and use WAP load balancing. WAP load balancing requires a WAP virtual server configured on one of the WAP ports.

To load-balance sessions running in connectionless WSP, connectionless secure WSP, and connection-oriented secure WSP modes, define a ping or WSP probe and use standard UDP load balancing with a low idle timer.

WAP Load Balancing Example

The following example shows the configuration for the IOS SLB device shown in Figure 18, which balances WAP flows on UDP port 9201 (WSP/WTP/UDP):

ip slb probe PROBE3 wsp
  url http://localhost/test.txt
!
ip slb serverfarm WAPFARM
  nat server
  real 10.10.2.1
  inservice
  real 10.10.2.2
  inservice
  real 10.10.2.3
  inservice
  probe PROBE3
!
ip slb vserver VSERVER
  virtual 10.10.1.1 udp 9201
  serverfarm WAPFARM
  idle 3000
  inservice

UDP Load Balancing Example

The following example shows the configuration for the IOS SLB device shown in Figure 18, which balances WAP flows on UDP port 9203 (WSP/WTP/WTLS/UDP):

ip slb probe PROBE1 ping
!
ip slb serverfarm WAPFARM
  nat server
  real 10.10.2.1
  inservice
  real 10.10.2.2
  inservice
  real 10.10.2.3
  inservice
  probe PROBE1
!
ip slb vserver VSERVER
  virtual 10.10.1.1 udp 9203
  serverfarm WAPFARM
  idle 3000
  inservice

IOS 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

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

Example with Two Distributed Sites with One Web Server Each

Figure 19 shows an IOS SLB network configured with route health injection with the following characteristics:

Both IOS SLB devices are configured with the same virtual IP address.

Each IOS SLB device has a server farm containing only the locally attached web server as a real server.

The path to SLB A has the lower weight.

Figure 19 Two Distributed Sites with One Web Server Each

When both web servers in Figure 19 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 20 shows an IOS SLB network configured with route health injection with the following characteristics:

Both IOS SLB devices are configured with the same virtual IP address.

Each IOS SLB device has a server farm containing two locally attached web servers as real servers.

The path to SLB A has the lower weight.

Figure 20 Two Distributed Sites with Two Web Servers Each

When all web servers in Figure 20 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 21 shows an IOS SLB network configured with route health injection with the following characteristics:

Both IOS SLB devices are configured with the same virtual IP address.

Each IOS SLB device has a server farm containing only the locally attached web server as a real server.

Each site has a primary IOS SLB device and a backup IOS SLB device.

The path to SLB A has the lower weight.

Figure 21 Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each

When both web servers in Figure 21 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 22 shows a typical GPRS load-balancing configuration without GTP cause code inspection enabled. In this configuration:

IOS SLB can balance GPRS flows across multiple real GGSNs. The SGSN "sees" the real GGSNs as a single virtual GGSN. This configuration increases the flow-handling capability of the real GGSNs and increases the reliability and availability.

The virtual template address of the SGSN is 10.111.111.111.

The virtual template address of GGSN1 is 192.168.1.1.

The virtual template address of GGSN2 is 192.168.2.2.

The virtual template address of GGSN3 is 192.168.3.3.

Figure 22 IOS SLB with GPRS Load Balancing

Following are the configuration statements for the configuration shown in Figure 22:

IOS SLB Configuration Statements

GGSN1 Configuration Statements

GGSN2 Configuration Statements

GGSN3 Configuration Statements

For more detailed GGSN configuration examples, refer to the Cisco IOS Mobile Wireless Configuration Guide, Release 12.2.

IOS SLB Configuration Statements

hostname GTP_SLB
!
ip domain-name gprs.com
!
ip slb serverfarm GPRS
 real 192.168.1.1
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
 real 192.168.2.2
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
 real 192.168.3.3
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
ip slb vserver FOR_GPRS
 virtual 10.10.10.10 udp 3386 service gtp
 serverfarm GPRS
 inservice
!
ip slb dfp password Password1 0
 agent 10.1.1.201 1111 30 0 10
 agent 10.1.1.202 1111 30 0 10
 agent 10.1.1.203 1111 30 0 10
!
interface FastEthernet1/0
 description TO SERVERFARM GPRS
 ip address 10.1.1.100 255.255.255.0
 no ip redirects
 duplex half
!
interface FastEthernet3/0
 description TO SGSN
 ip address 10.2.1.100 255.255.255.0
 no ip mroute-cache
 duplex half
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
ip route 192.168.1.1 255.255.255.255 10.1.1.201
ip route 192.168.2.2 255.255.255.255 10.1.1.202
ip route 192.168.3.3 255.255.255.255 10.1.1.203

GGSN1 Configuration Statements

service gprs ggsn
!
hostname GGSN1
!
ip dfp agent gprs
 port 1111
 password Password1 0
 inservice
!
ip domain-name gprs.com
!
interface loopback 1
 description LOOPBACK SAME AS IOS SLB VSERVER ADDRESS
 ip address 10.10.10.10 255.255.255.255
 no ip route-cache
 no ip mroute-cache
!
interface FastEthernet1/0
 description TO SLB
 ip address 10.1.1.201 255.255.255.0
 ip directed-broadcast
 no ip mroute-cache
 duplex half
!
interface Virtual-Template1
 description GTP VIRTUAL TEMPLATE
 ip address 192.168.1.1 255.255.255.0
 encapsulation gtp
 gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
  access-point 1
   access-point-name gprs.company.com
   access-mode non-transparent
   ip-address-pool dhcp-proxy-client
   dhcp-server 10.100.0.5 10.100.0.6
   dhcp-gateway-address 10.27.3.1
   exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32
gprs slb cef 10.10.10.10

GGSN2 Configuration Statements

service gprs ggsn
!
hostname GGSN2
!
ip dfp agent gprs
 port 1111
 password Password1 0
 inservice
!
ip domain-name gprs.com
!
interface loopback 1
 description LOOPBACK SAME AS IOS SLB VSERVER ADDRESS
 ip address 10.10.10.10 255.255.255.255
 no ip route-cache
 no ip mroute-cache
!
interface FastEthernet1/0
 description TO SLB
 ip address 10.1.1.202 255.255.255.0
 ip directed-broadcast
 no ip mroute-cache
 duplex half
!
interface Virtual-Template1
 description GTP VIRTUAL TEMPLATE
 ip address 192.168.2.2 255.255.255.0
 encapsulation gtp
 gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
  access-point 1
   access-point-name gprs.company.com
   access-mode non-transparent
   ip-address-pool dhcp-proxy-client
   dhcp-server 10.100.0.5 10.100.0.6
   dhcp-gateway-address 10.27.3.1
   exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32
gprs slb cef 10.10.10.10

GGSN3 Configuration Statements

service gprs ggsn
!
hostname GGSN3
!
ip dfp agent gprs
 port 1111
 password Password1 0
 inservice
!
ip domain-name gprs.com
!
interface loopback 1
 description LOOPBACK SAME AS IOS SLB VSERVER ADDRESS
 ip address 10.10.10.10 255.255.255.255
 no ip route-cache
 no ip mroute-cache
!
interface FastEthernet1/0
 description TO SLB
 ip address 10.1.1.203 255.255.255.0
 ip directed-broadcast
 no ip mroute-cache
 duplex half
!
interface Virtual-Template1
 description GTP VIRTUAL TEMPLATE
 ip address 192.168.3.3 255.255.255.0
 encapsulation gtp
 gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!





gprs access-point-list gprs1
  access-point 1
   access-point-name gprs.company.com
   access-mode non-transparent
   ip-address-pool dhcp-proxy-client
   dhcp-server 10.100.0.5 10.100.0.6
   dhcp-gateway-address 10.27.3.1
   exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32
gprs slb cef 10.10.10.10

IOS 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 22, but with the addition of NAT:

IOS SLB Configuration Statements

GGSN1 Configuration Statements

GGSN2 Configuration Statements

GGSN3 Configuration Statements

For more detailed GGSN configuration examples, refer to the Cisco IOS Mobile Wireless Configuration Guide, Release 12.2.

IOS SLB Configuration Statements

hostname GTP_SLB
!
ip domain-name gprs.com
!
ip slb serverfarm GPRS
 nat server
 real 192.168.1.1
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
 real 192.168.2.2
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
 real 192.168.3.3
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
ip slb vserver FOR_GPRS
 virtual 10.10.10.10 udp 3386 service gtp
 serverfarm GPRS
 inservice
!

ip slb dfp password Password1 0
 agent 10.1.1.201 1111 30 0 10
 agent 10.1.1.202 1111 30 0 10
 agent 10.1.1.203 1111 30 0 10
!
interface FastEthernet1/0
 description TO SERVERFARM GPRS
 ip address 10.1.1.100 255.255.255.0
 no ip redirects
 duplex half
!
interface FastEthernet3/0
 description TO SGSN
 ip address 10.2.1.100 255.255.255.0
 no ip mroute-cache
 duplex half
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
ip route 192.168.1.1 255.255.255.255 10.1.1.201
ip route 192.168.2.2 255.255.255.255 10.1.1.202
ip route 192.168.3.3 255.255.255.255 10.1.1.203

GGSN1 Configuration Statements

service gprs ggsn
!
hostname GGSN1
!
ip dfp agent gprs
 port 1111
 password Password1 0
 inservice
!
ip domain-name gprs.com
!
interface FastEthernet1/0
 description TO SLB
 ip address 10.1.1.201 255.255.255.0
 ip directed-broadcast
 no ip mroute-cache
 duplex half
!
interface Virtual-Template1
 description GTP VIRTUAL TEMPLATE
 ip address 192.168.1.1 255.255.255.0
 encapsulation gtp
 gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
  access-point 1
   access-point-name gprs.company.com
   access-mode non-transparent
   ip-address-pool dhcp-proxy-client
   dhcp-server 10.100.0.5 10.100.0.6
   dhcp-gateway-address 10.27.3.1
   exit
!



gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32

GGSN2 Configuration Statements

service gprs ggsn
!
hostname GGSN2
!
ip dfp agent gprs
 port 1111
 password Password1 0
 inservice
!
ip domain-name gprs.com
!
interface FastEthernet1/0
 description TO SLB
 ip address 10.1.1.202 255.255.255.0
 ip directed-broadcast
 no ip mroute-cache
 duplex half
interface Virtual-Template1
 description GTP VIRTUAL TEMPLATE
 ip address 192.168.2.2 255.255.255.0
 encapsulation gtp
 gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
  access-point 1
   access-point-name gprs.company.com
   access-mode non-transparent
   ip-address-pool dhcp-proxy-client
   dhcp-server 10.100.0.5 10.100.0.6
   dhcp-gateway-address 10.27.3.1
   exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32

GGSN3 Configuration Statements

service gprs ggsn
!
hostname GGSN3
!
ip dfp agent gprs
 port 1111
 password Password1 0
 inservice
!
ip domain-name gprs.com
!
interface FastEthernet1/0
 description TO SLB
 ip address 10.1.1.203 255.255.255.0
 ip directed-broadcast
 no ip mroute-cache
 duplex half
!

interface Virtual-Template1
 description GTP VIRTUAL TEMPLATE
 ip address 192.168.3.3 255.255.255.0
 encapsulation gtp
 gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
  access-point 1
   access-point-name gprs.company.com
   access-mode non-transparent
   ip-address-pool dhcp-proxy-client
   dhcp-server 10.100.0.5 10.100.0.6
   dhcp-gateway-address 10.27.3.1
   exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32

IOS SLB with GPRS Load Balancing, NAT, and GTP Cause Code Inspection Example

The following example uses the same basic configuration as in the "IOS SLB with GPRS Load Balancing and NAT Example" section, including the network shown in Figure 22, but with the GTP cause code inspection enabled. In this configuration:

The GSN idle timer is set to 20 seconds.

The GTP request idle timer is set to 15 seconds.

The virtual server accepts PDP context creates only from International Mobile Subscriber IDs (IMSIs) with carrier code mcc 222 mnc 22.

Following are the configuration statements for the configuration shown in Figure 22, with the addition of NAT and GTP cause code inspection support:

IOS SLB Configuration Statements

GGSN1 Configuration Statements (no change for GTP cause code inspection)

GGSN2 Configuration Statements (no change for GTP cause code inspection)

GGSN3 Configuration Statements (no change for GTP cause code inspection)

For more detailed GGSN configuration examples, refer to the Cisco IOS Mobile Wireless Configuration Guide, Release 12.2.

IOS SLB Configuration Statements

hostname GTP_SLB
!
ip domain-name gprs.com
!
ip slb timers gtp gsn 20
!
ip slb serverfarm GPRS
 nat server
 real 192.168.1.1
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
 real 192.168.2.2
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
 real 192.168.3.3
  weight 1
  faildetect numconns 1 numclients 1
  inservice
!
ip slb vserver FOR_GPRS
 virtual 10.10.10.10 udp 0 service gtp-inspect
 idle gtp request 15
 client gtp carrier-code mcc 222 mnc 22
 serverfarm GPRS
 inservice
!
ip slb dfp password Password1 0
 agent 10.1.1.201 1111 30 0 10
 agent 10.1.1.202 1111 30 0 10
 agent 10.1.1.203 1111 30 0 10
!
interface FastEthernet1/0
 description TO SERVERFARM GPRS
 ip address 10.1.1.100 255.255.255.0
 no ip redirects
 duplex half
!
interface FastEthernet3/0
 description TO SGSN
 ip address 10.2.1.100 255.255.255.0
 no ip mroute-cache
 duplex half
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
ip route 192.168.1.1 255.255.255.255 10.1.1.201
ip route 192.168.2.2 255.255.255.255 10.1.1.202
ip route 192.168.3.3 255.255.255.255 10.1.1.203

IOS SLB with VPN Server Load Balancing Example

Figure 23 shows a typical VPN server load-balancing configuration. In this configuration:

VPN flows are balanced between real servers 20.20.20.10 and 20.20.20.20.

Clients connect to 10.10.1.1, the IOS SLB virtual server address.

There is a sticky connection between the ESP virtual server and the UDP virtual server.

The cryptographic key exchange occurs via IKE (ISAKMP; port 500).

Figure 23 IOS SLB with VPN Server Load Balancing

Following are the IOS SLB configuration statements for the configuration shown in Figure 23:

ip slb serverfarm VPN
 nat server
 real 20.20.20.10
  inservice
 real 20.20.20.20
  inservice
 failaction purge
!
ip slb vserver ESP
 virtual 10.10.1.1 ESP
 serverfarm VPN
 sticky 3600 group 69
 inservice
!
ip slb vserver UDP
 virtual 10.10.1.1 UDP isakmp
 serverfarm VPN
 sticky 3600 group 69
 inservice

IOS SLB with RADIUS Load Balancing for a GPRS Network Example

Figure 24 shows a typical IOS SLB RADIUS load-balancing configuration for a GPRS network. In this configuration:

RADIUS requests are load-balanced between SSG RADIUS proxy servers 10.10.10.1 and 10.10.10.2.

End-user data packets are routed to the IOS SLB device.

End-user data packets from the 1.1.1.0 subnet are directed by IOS SLB to SSG1.

End-user data packets from the 1.1.2.0 subnet are directed by IOS SLB to SSG2.

Figure 24 IOS SLB with RADIUS Load Balancing for a GPRS Network

Following are the IOS SLB configuration statements for the configuration shown in Figure 24:

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
 nat server
 real 10.10.10.1
  inservice
 real 10.10.10.2
  inservice
!
ip slb vserver RADIUS_ACCT
 virtual 10.10.10.10 udp 1812 service radius
 serverfarm SSGFARM
 idle radius request 20
 idle radius framed-ip 7200
 sticky radius framed-ip group 1
 inservice
!


ip slb vserver RADIUS_AUTH
 virtual 10.10.10.10 udp 1813 service radius
 serverfarm SSGFARM
 idle radius request 20
 idle radius framed-ip 7200
 sticky radius framed-ip group 1
 inservice

IOS SLB with RADIUS Load Balancing for a Simple IP CDMA2000 Network Example

Figure 25 shows a typical IOS SLB RADIUS load-balancing configuration for a CDMA2000 network with simple IP service. In this configuration:

The RADIUS virtual server IP address for the PDSNs is 10.10.10.10.

RADIUS requests are load-balanced between SSG RADIUS proxy servers 10.10.10.1 and 10.10.10.2.

End-user data packets are routed to the IOS SLB device.

End-user data packets from the 1.1.0.0 network are routed to the SSGs.

Figure 25 IOS SLB with RADIUS Load Balancing for a Simple IP CDMA2000 Network

Following are the IOS SLB configuration statements for the configuration shown in Figure 25:

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
  nat server
  real 10.10.10.1
    inservice
  real 10.10.10.2
    inservice
!
ip slb vserver RADIUS_SIP
  virtual 10.10.10.10 udp 0 service radius
  serverfarm SSGFARM
  idle radius framed-ip 3600
  sticky radius username
  sticky radius framed-ip
  inservice

IOS SLB with RADIUS Load Balancing for a Mobile IP CDMA2000 Network Example

Figure 26 shows a typical IOS SLB RADIUS load-balancing configuration for a CDMA2000 network with Mobile IP service. In this configuration:

The RADIUS virtual server IP address for the PDSNs and the HA is 10.10.10.10.

RADIUS requests are load-balanced between SSG RADIUS proxy servers 10.10.10.1 and 10.10.10.2.

End-user data packets are routed to the IOS SLB device.

End-user data packets from the 1.1.0.0 network are routed to the SSGs.

Figure 26 IOS SLB with RADIUS Load Balancing for a Mobile IP CDMA2000 Network

Following are the IOS SLB configuration statements for the configuration shown in Figure 26:

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
  nat server
  real 10.10.10.1
    inservice
  real 10.10.10.2
    inservice
!
ip slb vserver RADIUS_SIP
  virtual 10.10.10.10 udp 0 service radius
  serverfarm SSGFARM
  idle radius framed-ip 3600
  sticky radius username
  sticky radius framed-ip
  inservice

IOS SLB with RADIUS Load Balancing for Multiple Service Gateway Farms Example

The following sample configuration enables IOS SLB to balance packet flows for a set of subscribers among multiple service gateway server farms (in this sample, a server farm of SSGs and a server farm of CSGs):

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
 nat server
 real 10.10.10.1
  inservice
 real 10.10.10.2
  inservice
!
ip slb serverfarm CSGFARM
 nat server
 real 20.20.20.1
  inservice
 real 20.20.20.2
  inservice
!
ip slb vserver SSG_AUTH
 virtual 10.10.10.10 udp 1812 service radius
 serverfarm SSGFARM
 idle radius request 20
 idle radius framed-ip 7200
 sticky radius framed-ip group 1
 access Vlan20 route framed-ip
 inservice
!
ip slb vserver SSG_ACCT
 virtual 10.10.10.10 udp 1813 service radius
 serverfarm SSGFARM
 idle radius request 20
 idle radius framed-ip 7200
 sticky radius framed-ip group 1
 access Vlan20 route framed-ip
 inservice
!
ip slb vserver CSG_ACCT
 virtual 20.20.20.20 udp 1813 service radius
 serverfarm CSGFARM
 idle radius request 25
 idle radius framed-ip 0
 sticky radius framed-ip
 access Vlan30 route framed-ip
 inservice

IOS SLB with Home Agent Director Example

The following sample configuration enables IOS SLB to balance Mobile IP RRQs among multiple home agents.

Figure 27 IOS SLB with Home Agent Director

Following are the IOS SLB configuration statements for the configuration shown in Figure 27:

ip slb serverfarm HA_FARM
 nat server
 real 10.10.10.1
  inservice
 real 10.10.10.2
  inservice

ip slb vserver VIRTUAL_HA
 virtual 10.10.10.10 udp 434 service ipmobile
 serverfarm HA_FARM
 inservice

IOS SLB with Sticky Connections Example

The following sample configuration assigns all HTTP connections from a subnet to the same real server in server farm PUBLIC:

ip slb vserver http
  serverfarm PUBLIC
  sticky 30 group 1 netmask 255.255.255.248
  virtual 20.20.20.20 tcp 80
  inservice

The following sample configuration adds HTTPS connections to the above configuration, using the same sticky information but with a different virtual server:

ip slb vserver https
  serverfarm PUBLIC
  sticky 30 group 1 netmask 255.255.255.248
  virtual 20.20.20.20 tcp 443
  inservice

Now, all HTTP and HTTPS connections from the subnet are assigned to the same real server. For example, if a user connects to HTTP, then a second user connects to HTTPS, both connections are assigned to the same real server.

IOS SLB with Transparent Web Cache Load Balancing

In the following sample configuration, virtual server WEBCACHE examines all web flows passing through the load-balancing device and dispatches them to server farm WEBCACHE-FARM. The client exclude statement ignores flows originating from subnet 80.80.7.0, enabling the real servers 80.80.7.188 and 80.80.7.189 to communicate with the Internet as needed.

ip slb serverfarm WEBCACHE-FARM
  real 80.80.7.188
   inservice
  real 80.80.7.189
   inservice
ip slb vserver WEBCACHE
  virtual 0.0.0.0 0.0.0.0 tcp www
  serverfarm WEBCACHE-FARM
  client 80.80.7.0 255.255.255.0 exclude
  inservice

Command Reference

This section documents only new and modified commands.

access (firewall farm)

access (virtual server)

address (custom UDP probe)

address (DNS probe)

address (HTTP probe)

address (ping probe)

address (TCP probe)

address (WSP probe)

advertise

agent (DFP)

bindid

clear ip slb connections

clear ip slb counters

clear ip slb sessions

clear ip slb sticky radius

client (virtual server)

credentials

debug gprs dfp

debug ip slb

delay (firewall farm TCP protocol)

delay (virtual server)

expect

failaction (firewall farm)

failaction (server farm)

faildetect (DNS probe)

faildetect (ping probe)

faildetect inband (real server)

faildetect numconns (real server)

hand-off radius

header

idle (firewall farm datagram protocol)

idle (firewall farm TCP protocol)

idle (virtual server)

inservice (firewall farm)

inservice (firewall farm real server)

inservice (server farm real server)

inservice (server farm virtual server)

interval (custom UDP probe)

interval (DNS probe)

interval (HTTP probe)

interval (ping probe)

interval (TCP probe)

interval (WSP probe)

ip slb dfp

ip slb entries

ip slb firewallfarm

ip slb maxbuffers frag

ip slb natpool

ip slb probe custom udp

ip slb probe dns

ip slb probe http

ip slb probe ping

ip slb probe tcp

ip slb probe wsp

ip slb replicate slave rate

ip slb route

ip slb serverfarm

ip slb static

ip slb vserver

lookup

maxclients

maxconns (firewall farm datagram protocol)

maxconns (firewall farm TCP protocol)

maxconns (server farm)

mls aging slb normal

mls aging slb process

mls ip slb search wildcard

nat

port (custom UDP probe)

port (HTTP probe)

port (TCP probe)

predictor (server farm)

predictor hash address (firewall farm)

probe (firewall farm real server)

probe (server farm)

protocol datagram

protocol tcp

purge radius framed-ip acct on-off (virtual server)

purge radius framed-ip acct stop (virtual server)

real (firewall farm)

real (server farm)

real (static NAT)

reassign

replicate casa (firewall farm)

replicate casa (virtual server)

replicate interval (firewall farm)

replicate interval (virtual server)

replicate slave (firewall farm)

replicate slave (virtual server)

request (custom UDP probe)

request (HTTP probe)

response

retry

serverfarm

show ip slb conns

show ip slb dfp

show ip slb firewallfarm

show ip slb fragments

show ip slb gtp

show ip slb natpool

show ip slb probe

show ip slb reals

show ip slb replicate

show ip slb serverfarms

show ip slb sessions

show ip slb static

show ip slb stats

show ip slb sticky

show ip slb vserver

snmp-server enable traps slb

sticky (firewall farm datagram protocol)

sticky (firewall farm TCP protocol)

sticky (virtual server)

synguard (virtual server)

url (WSP probe)

virtual (virtual server)

weight (firewall farm real server)

weight (server farm)

access (firewall farm)

To route specific flows to a firewall farm, use the access command in firewall farm configuration mode. To restore the default settings, use the no form of this command.

access [source source-ip netmask] [destination destination-ip netmask]

no access [source source-ip netmask] [destination destination-ip netmask]

Syntax Description

source

(Optional) Routes flows based on source IP address.

source-ip

(Optional) Source IP address. The default is 0.0.0.0 (all sources).

netmask

(Optional) Source IP network mask. The default is 0.0.0.0 (all source subnets).

destination

(Optional) Routes flows based on destination IP address.

destination-ip

(Optional) Destination IP address. The default is 0.0.0.0 (all destinations).

netmask

(Optional) Destination IP network mask. The default is 0.0.0.0 (all destination subnets).


Defaults

The default source IP address is 0.0.0.0 (routes flows from all sources to this firewall farm).
The default source IP network mask is 0.0.0.0 (routes flows from all source subnets to this firewall farm).
The default destination IP address is 0.0.0.0 (routes flows from all destinations to this firewall farm).
The default destination IP network mask is 0.0.0.0 (routes flows from all destination subnets to this firewall farm).

Command Modes

Firewall farm configuration

Command History

Release
Modification

12.1(7)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

You can specify more than one source or destination for each firewall farm. To do so, configure multiple access statements, making sure the network masks do not overlap each other.

Examples

The following example routes flows with a destination IP address of 10.1.6.0 to firewall farm FIRE1:

Router(config)# ip slb firewallfarm FIRE1
Router(config-slb-fw)# access destination 10.1.6.0 255.255.255.0

Related Commands

Command
Description

show ip slb firewallfarm

Displays information about the firewall farm configuration.


access (virtual server)

To enable framed-IP routing to inspect the ingress interface, use the access command in virtual server configuration mode. To disable framed-IP routing, use the no form of this command.

access interface route framed-ip

no access interface route framed-ip

Syntax Description

interface

Interface to be inspected.

route framed-ip

Routes flows using framed-IP routing.


Defaults

Framed-IP routing cannot inspect the ingress interface.

Command Modes

Virtual server configuration

Command History

Release
Modification

12.1(12c)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

You can specify more than one source or destination for each firewall farm. To do so, configure multiple access statements, making sure the network masks do not overlap each other.

This command enables framed-IP routing to inspect the ingress interface when routing subscriber traffic. All framed-IP sticky database entries created as a result of RADIUS requests to this virtual server will include the interface in the entry. In addition to matching the source IP address of the traffic with the framed-IP address, the ingress interface must also match this interface when this command is configured.

You can use this command to allow subscriber data packets to be routed to multiple service gateway service farms.

Examples

The following example enables framed-IP routing to inspect ingress interface Vlan20:

Router(config)# ip slb vserver SSG_AUTH
Router(config-slb-vserver)# access Vlan20 route framed-ip

Related Commands

Command
Description

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).


address (custom UDP probe)

To configure an IP address to which to send custom User Datagram Protocol (UDP) probes, use the address command in custom UDP probe configuration mode. To restore the default settings, use the no form of this command.

address [ip-address] [routed]

no address [ip-address] [routed]

Syntax Description

ip-address

(Optional) Destination IP address that is to respond to the custom UDP probe.

routed

(Optional) Flags the probe as a routed probe, with the following considerations:

Only one instance of a routed probe per server farm can run at any given time.

Outbound packets for a routed probe are routed directly to ip-address.


Defaults

If the custom UDP probe is associated with a firewall farm, you must specify an IP address.
If the custom UDP probe is associated with a server farm, and you do not specify an IP address, the address is inherited from the server farm real servers.

Command Modes

Custom UDP probe configuration

Command History

Release
Modification

12.1(13)E3

This command was introduced.


Examples

The following example configures a custom UDP probe named PROBE6, enters custom UDP probe configuration mode, and configures the probe to receive responses from IP address 13.13.13.13:

Router(config)# ip slb probe PROBE6 custom udp
Router(config-slb-probe)# address 13.13.13.13

Related Commands

Command
Description

ip slb probe custom udp

Configures a custom User Datagram Protocol (UDP) probe name and enters custom UDP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


address (DNS probe)

To configure an IP address to which to send Domain Name System (DNS) probes, use the address command in DNS probe configuration mode. To restore the default settings, use the no form of this command.

address [ip-address [routed]]

no address [ip-address [routed]]

Syntax Description

ip-address

(Optional) Destination IP address that is to respond to the DNS probe.

routed

(Optional) Flags the probe as a routed probe, with the following considerations:

Only one instance of a routed probe per server farm can run at any given time.

Outbound packets for a routed probe are routed directly to the specified IP address.


Defaults

If the DNS probe is associated with a firewall farm, you must specify an IP address.
If the DNS probe is associated with a server farm, and you do not specify an IP address, the address is inherited from the server farm real servers.

Command Modes

DNS probe configuration

Command History

Release
Modification

12.1(11b)E

This command was introduced.

12.1(12c)E

The routed keyword was added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a DNS probe named PROBE4, enters DNS probe configuration mode, and configures the probe to receive responses from IP address 13.13.13.13:

Router(config)# ip slb probe PROBE4 dns
Router(config-slb-probe)# address 13.13.13.13

Related Commands

Command
Description

ip slb probe dns

Configures a Domain Name System (DNS) probe name and enters DNS probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


address (HTTP probe)

To configure an IP address to which to send HTTP probes, use the address command in HTTP probe configuration mode. To restore the default settings, use the no form of this command.

address [ip-address [routed]]

no address [ip-address [routed]]

Syntax Description

ip-address

(Optional) Destination IP address that is to respond to the HTTP probe.

routed

(Optional) Flags the probe as a routed probe, with the following considerations:

Only one instance of a routed probe per server farm can run at any given time.

Outbound packets for a routed probe are routed directly to the specified IP address.


Defaults

If the HTTP probe is associated with a firewall farm, you must specify an IP address.
If the HTTP probe is associated with a server farm, and you do not specify an IP address, the address is inherited from the server farm real servers.

Command Modes

HTTP probe configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.1(12c)E

The routed keyword was added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures an HTTP probe named PROBE2, enters HTTP probe configuration mode, and configures the probe to receive responses from IP address 13.13.13.13:

Router(config)# ip slb probe PROBE2 http
Router(config-slb-probe)# address 13.13.13.13

Related Commands

Command
Description

ip slb probe http

Configures an HTTP probe name and enters HTTP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


address (ping probe)

To configure an IP address to which to send ping probes, use the address command in ping probe configuration mode. To restore the default settings, use the no form of this command.

address [ip-address [routed]]

no address [ip-address [routed]]

Syntax Description

ip-address

(Optional) Destination IP address that is to respond to the ping probe.

routed

(Optional) Flags the probe as a routed probe, with the following considerations:

Only one instance of a routed probe per server farm can run at any given time.

Outbound packets for a routed probe are routed directly to the specified IP address.


Defaults

If the ping probe is associated with a firewall farm, you must specify an IP address.
If the ping probe is associated with a server farm, and you do not specify an IP address, the address is inherited from the server farm real servers.

Command Modes

Ping probe configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.1(12c)E

The routed keyword was added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a ping probe named PROBE1, enters ping probe configuration mode, and configures the probe to receive responses from IP address 13.13.13.13:

Router(config)# ip slb probe PROBE1 ping
Router(config-slb-probe)# address 13.13.13.13

Related Commands

Command
Description

ip slb probe ping

Configures a ping probe name and enters ping probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


address (TCP probe)

To configure an IP address to which to send TCP probes, use the address command in TCP probe configuration mode. To restore the default settings, use the no form of this command.

address [ip-address [routed]]

no address [ip-address [routed]]

Syntax Description

ip-address

(Optional) Destination IP address that is to respond to the TCP probe.

routed

(Optional) Flags the probe as a routed probe, with the following considerations:

Only one instance of a routed probe per server farm can run at any given time.

Outbound packets for a routed probe are routed directly to the specified IP address.


Defaults

If the TCP probe is associated with a firewall farm, you must specify an IP address
If the TCP probe is associated with a server farm, and you do not specify an IP address, the address is inherited from the server farm real servers.

Command Modes

TCP probe configuration

Command History

Release
Modification

12.1(11b)E

This command was introduced.

12.1(12c)E

The routed keyword was added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a TCP probe named PROBE5, enters TCP probe configuration mode, and configures the probe to receive responses from IP address 13.13.13.13:

Router(config)# ip slb probe PROBE5 tcp
Router(config-slb-probe)# address 13.13.13.13

Related Commands

Command
Description

ip slb probe tcp

Configures a TCP probe name and enters TCP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


address (WSP probe)

To configure an IP address to which to send Wireless Session Protocol (WSP) probes, use the address command in WSP probe configuration mode. To restore the default settings, use the no form of this command.

address [ip-address [routed]]

no address [ip-address [routed]]

Syntax Description

ip-address

(Optional) Destination IP address that is to respond to the WSP probe.

routed

(Optional) Flags the probe as a routed probe, with the following considerations:

Only one instance of a routed probe per server farm can run at any given time.

Outbound packets for a routed probe are routed directly to the specified IP address.


Defaults

If the WSP probe is associated with a firewall farm, you must specify an IP address.
If the WSP probe is associated with a server farm, and you do not specify an IP address, the address is inherited from the server farm real servers.
In dispatched mode, the ip-address argument value is the same as the virtual server IP address. In directed Network Address Translation (NAT) mode, an IP address is unnecessary.

Command Modes

WSP probe configuration

Command History

Release
Modification

12.1(5a)E

This command was introduced.

12.1(12c)E

The routed keyword was added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a WSP probe named PROBE3, enters WSP probe configuration mode, and configures the probe to receive responses from IP address 13.13.13.13:

Router(config)# ip slb probe PROBE3 wsp
Router(config-slb-probe)# address 13.13.13.13

Related Commands

Command
Description

ip slb probe wsp

Configures a Wireless Session Protocol (WSP) probe name and enters WSP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


advertise

To control the installation of a static route to the Null0 interface for a virtual server address, use the advertise command in virtual server configuration mode. To prevent the installation of a static route for the virtual server IP address, use the no form of this command.

advertise [active]

no advertise [active]

Syntax Description

active

(Optional) Indicates that the host route is to be advertised only when the virtual IP address is available (that is, when there is at least one real server in OPERATIONAL, DFP_THROTTLED, or MAXCONNS state).


Defaults

The virtual server IP address is advertised. That is, a static route to the Null0 interface is installed for the virtual server IP addresses and it is added to the routing table.
If you do not specify the active keyword, the host route is advertised regardless of whether the virtual IP address is available.

Command Modes

Virtual server configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.1(7)E

The active keyword was added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

Advertisement of a static route using the routing protocol requires that you configure redistribution of static routes for the routing protocol.

The advertise command does not affect virtual servers used for transparent web cache load balancing.

HTTP probes and route health injection 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 and route health injection to function correctly.

For HTTP probes, 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). If you specify either the no advertise or the advertise active command, you must specify a default route.

For route health injection, the route must be a default route.

HTTP probes and route health injection can both use the same default route; you need not specify two unique default routes.

Examples

The following example prevents advertisement of the virtual server's IP address in routing protocol updates:

Router(config)# ip slb vserver PUBLIC_HTTP
Router(config-slb-vserver)# no advertise

Related Commands

Command
Description

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).


agent (DFP)

To identify a Dynamic Feedback Protocol (DFP) agent with which the IOS Server Load Balancing (IOS SLB) feature can initiate connections, use the agent command in DFP configuration mode. To remove a DFP agent definition from the DFP configuration, use the no form of this command.

agent ip-address port [timeout [retry-count [retry-interval]]]

no agent ip-address port

Syntax Description

ip-address

Agent IP address.

port

Agent TCP or User Datagram Protocol (UDP) port number.

timeout

(Optional) Time period, in seconds, during which the DFP manager must receive an update from the DFP agent. The valid range is 0 to 65535 seconds. The default is 0 seconds, which means there is no timeout.

retry-count

(Optional) Number of times the DFP manager attempts to establish the TCP connection to the DFP agent. The valid range is 0 to 65535 times. The default is 0 retries, which means there are infinite retries.

retry-interval

(Optional) Interval, in seconds, between retries. The valid range is 1 to 65535 seconds. The default is 180 seconds.


Defaults

The default timeout is 0 seconds (no timeout).
The default retry count is 0 (infinite retries).
The default retry interval is 180 seconds.

Command Modes

DFP configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

The password specified in the ip slb dfp command for the DFP manager must match the password specified in the password command for the DFP agent.

You can identify up to 1024 DFP agents.

Examples

The following example sets the DFP password to Password1 (to match the DFP agent's password), sets the timeout to 360 seconds, enters DFP configuration mode, and enables IOS SLB to connect to the DFP agent with IP address 10.1.1.1 and port number 2221:

Router(config)# ip slb dfp password Password1 360
Router(config-slb-dfp)# agent 10.1.1.1 2221 30 0 10

Related Commands

Command
Description

ip dfp agent

Identifies a Dynamic Feedback Protocol (DFP) agent subsystem and enters DFP agent configuration mode.

ip slb dfp

Configures Dynamic Feedback Protocol (DFP), supplies an optional password, and enters DFP configuration mode.


bindid

To configure a bind ID, use the bindid command in server farm configuration mode. To remove a bind ID from the server farm configuration, use the no form of this command.

bindid [bind-id]

no bindid [bind-id]

Syntax Description

bind-id

(Optional) Bind ID number. The default bind ID is 0.


Defaults

The default bind ID is 0.

Command Modes

Server farm configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

You can configure one bind ID on each bindid command.

The bind ID allows a single physical server to be bound to multiple virtual servers, and to 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.

In general packet radio service (GPRS) load balancing, bind IDs are not supported. Therefore do not use the bindid command in a GPRS load-balancing environment.

Examples

The following example configures bind ID 309:

Router(config)# ip slb serverfarm PUBLIC
Router(config-slb-sfarm)# bindid 309

Related Commands

Command
Description

ip slb dfp

Configures Dynamic Feedback Protocol (DFP), supplies an optional password, and enters DFP configuration mode.

show ip slb serverfarms

Displays information about the IOS Server Load Balancing (IOS SLB) server farms.


clear ip slb connections

To clear IP IOS Server Load Balancing (IOS SLB) connections, use the clear ip slb connections command in privileged EXEC mode.

clear ip slb connections [firewallfarm firewall-farm | serverfarm server-farm | vserver virtual-server]

Syntax Description

firewallfarm firewall-farm

(Optional) Clears the IOS SLB connection database for the specified firewall farm.

serverfarm server-farm

(Optional) Clears the IOS SLB connection database for the specified server farm.

vserver virtual-server

(Optional) Clears the IOS SLB connection database for the specified virtual server.


Defaults

The IOS SLB connection database is cleared for all firewall farms, server farms, and virtual servers.

Command Modes

Privileged EXEC

Command History

Release
Modification

12.1(1)E

This command was introduced as part of the clear ip slb command.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.1(11b)E

This command was separated from the clear ip slb command.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

In general packet radio service (GPRS) load balancing, the clear ip slb connections command clears connections, but does not clear sessions.

Examples

The following example clears the connection database of server farm FARM1:

Router# clear ip slb connections serverfarm FARM1

The following example clears the connection database of virtual server VSERVER1:

Router# clear ip slb connections vserver VSERVER1

Related Commands

Command
Description

show ip slb conns

Displays information about active IOS Server Load Balancing (IOS SLB) connections.

show ip slb firewallfarm

Displays information about the firewall farm configuration.

show ip slb serverfarms

Displays information about the IOS Server Load Balancing (IOS SLB) server farms.

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).


clear ip slb counters

To clear IP IOS Server Load Balancing (IOS SLB) counters, use the clear ip slb counters command in privileged EXEC mode.

clear ip slb counters

Syntax Description

This command has no arguments or keywords.

Defaults

IP IOS SLB counters are not cleared.

Command Modes

Privileged EXEC

Command History

Release
Modification

12.1(1)E

This command was introduced as part of the clear ip slb command.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.1(11b)E

This command was separated from the clear ip slb command.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example clears the IP IOS SLB counters:

Router# clear ip slb counters

Related Commands

Command
Description

show ip slb stats

Displays IOS Server Load Balancing (IOS SLB) statistics.


clear ip slb sessions

To clear the IP IOS Server Load Balancing (IOS SLB) sessions database, use the clear ip slb sessions command in privileged EXEC mode.

clear ip slb sessions [firewallfarm firewall-farm | serverfarm server-farm | vserver virtual-server]

Syntax Description

firewallfarm firewall-farm

(Optional) Clears the IOS SLB session database for the specified firewall farm.

serverfarm server-farm

(Optional) Clears the IOS SLB session database for the specified server farm.

vserver virtual-server

(Optional) Clears the IOS SLB session database for the specified virtual server.


Command Modes

Privileged EXEC

Command History

Release
Modification

12.1(11b)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

If no optional keywords or arguments are specified, the IOS SLB sessions database is cleared of all firewall farms, server farms, and virtual servers.

Examples

The following example clears the session database of server farm FARM1:

Router# clear ip slb sessions serverfarm FARM1

The following example clears the session database of virtual server VSERVER1:

Router# clear ip slb sessions vserver VSERVER1

Related Commands

Command
Description

show ip slb firewallfarm

Displays information about the IOS Server Load Balancing (IOS SLB) firewall farms.

show ip slb serverfarms

Displays information about the IOS Server Load Balancing (IOS SLB) server farms.

show ip slb sessions

Displays information about sessions handled by IOS Server Load Balancing (IOS SLB).

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).


clear ip slb sticky radius

To clear entries from an IOS Server Load Balancing (IOS SLB) RADIUS sticky database, use the clear ip slb sticky radius command in privileged EXEC mode.

clear ip slb sticky radius {calling-station-id [id string] | framed-ip [framed-ip [netmask]]}

Syntax Description

calling-station-id

Clears entries from the IOS SLB RADIUS calling-station-ID sticky database

id string

(Optional) Calling station ID of the entry to be cleared.

framed-ip

Clears entries from the IOS SLB RADIUS framed-IP sticky database

framed-ip

(Optional) Framed-IP address of entries to be cleared.

netmask

(Optional) Subnet mask specifying a range of entries to be cleared.


Command Modes

Privileged EXEC

Command History

Release
Modification

12.1(11b)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.

12.2(14)ZA5

The calling-station-id and id keywords and string argument were added.


Usage Guidelines

If no optional arguments are specified, all entries are cleared from the IOS SLB RADIUS calling-station-ID sticky database or framed-IP sticky database.

Examples

The following example clears all entries from the IOS SLB RADIUS framed-IP sticky database:

Router# clear ip slb sticky radius framed-ip

Related Commands

Command
Description

show ip slb sticky

Displays information about the IOS Server Load Balancing (IOS SLB) sticky database.


client (virtual server)

To define which clients are allowed to use the virtual server, use the client command in virtual server configuration mode. To remove a client definition from the IOS Server Load Balancing (IOS SLB) configuration, use the no form of this command.

client {ip-address netmask [exclude] | gtp carrier-code [code]}

no client {ip-address netmask [exclude] | gtp carrier-code [code]}

Syntax Description

ip-address

(Optional) Client IP address. The default is 0.0.0.0 (all clients).

netmask

(Optional) Client IP network mask. The default is 0.0.0.0 (all subnets).

exclude

(Optional) Ignores connections initiated by the client IP address from the load-balancing scheme.

gtp carrier-code

(Optional) For general packet radio service (GPRS) Tunneling Protocol (GTP) cause code inspection, configures the virtual server to accept Packet Data Protocol (PDP) context creates only from the specified IMSI carrier code.

code

(Optional) For GTP cause code inspection, identifies the IMSI carrier code from which this virtual server is to accept PDP context creates. The code has the format:

mcc mcc-code mnc mnc-code

where:

mcc-code is the Mobile Country Code (MCC)

mnc-code is the Mobile Network Code (MNC)

If you do not specify a code, the virtual server accepts PDP context creates from any IMSI carrier code.


Defaults

The default client IP address is 0.0.0.0 (all clients).
The default client IP network mask is 0.0.0.0 (all subnets).
Taken together, the default is client 0.0.0.0 0.0.0.0 (allows all clients on all subnets to use the virtual server).
If you specify gtp carrier-code and you do not specify a code, the virtual server accepts PDP context creates from any IMSI carrier code.

Command Modes

Virtual server configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(1)E

The exclude keyword was added.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.

12.1(13)E3

The gtp request keyword and code argument were added.


Usage Guidelines

You can use more than one client command to define more than one client.

The netmask value is applied to the source IP address of incoming connections. The result must match the ip-address value for the client to be allowed to use the virtual server.

If you configure probes in your network, you must also do one of the following:

Configure the exclude keyword on the client command on the virtual server to exclude connections initiated by the client IP address from the load-balancing scheme.

Configure IP addresses on the IOS SLB device that are Layer 3-adjacent to the real servers used by the virtual server.

Configure separate client commands to specify the clients that can use the virtual server, and to specify the IMSI carrier code from which the virtual server is to accept PDP context creates.

Examples

The following example allows clients from only 10.4.4.0 access to the virtual server:

Router(config)# ip slb vserver PUBLIC_HTTP
Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0

Related Commands

Command
Description

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).

virtual (virtual server)

Configures the virtual server attributes.


credentials

To configure basic authentication values for the HTTP IOS Server Load Balancing (IOS SLB) probe, use the credentials command in HTTP probe configuration mode. To remove a credentials configuration, use the no form of this command.

credentials username [password]

no credentials username [password]

Syntax Description

username

Authentication username of the HTTP probe header. The character string is limited to 15 characters.

password

(Optional) Authentication password of the HTTP probe header. The character string is limited to 15 characters.


Defaults

Basic authentication values for the HTTP IOS SLB probe are not configured.

Command Modes

HTTP probe configuration

Command History

Release
Modification

12.1(2)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures an HTTP probe named PROBE2, enters HTTP probe configuration mode, sets the HTTP authentication to username Username1, and sets the password to develop:

Router(config)# ip slb probe PROBE2 http
Router(config-slb-probe)# credentials Username1 develop

Related Commands

Command
Description

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


debug gprs dfp

To display debugging messages for general packet radio service (GPRS) Dynamic Feedback Protocol (DFP) weight calculation, use the debug gprs dfp command in user EXEC or privileged EXEC mode. To disable debugging output, use the no form of this command.

debug gprs dfp

no debug gprs dfp

Syntax Description

This command has no arguments or keywords.

Defaults

No default behavior or values

Command Modes

User EXEC or privileged EXEC

Command History

Release
Modification

12.1(9)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

This command displays debugging messages for GPRS DFP weight calculation. To display debugging messages for the DFP agent subsystem, use the debug ip dfp agent command.


Caution Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network flows and fewer users. Debugging during these periods reduces the effect these commands have on other users on the system.

Examples

The following example configures a debugging session to check all GPRS DFP weight calculation:

Router# debug gprs dfp
GPRS DFP debugging is on
Router#

The following example stops all debugging:

Router# no debug all
All possible debugging has been turned off
Router#

debug ip slb

To display debugging messages for IOS Server Load Balancing (IOS SLB), use the debug ip slb command in user EXEC or privileged EXEC mode. To disable debugging output, use the no form of this command.

debug ip slb {conns [acl-number] | dfp | firewallfarm | fragments | gtp | icmp | natpool | probe | reals | replication | route | sessions [gtp | ipmobile | radius] | vservers | all}

no debug ip slb {conns [acl-number] | dfp | firewallfarm | fragments | gtp | icmp | natpool | probe | reals | replication | route | sessions [gtp | ipmobile | radius] | vservers | all}

Syntax Description

all

Displays all debugging messages for IOS SLB.

conns [acl-number]

Displays debugging messages for all connections being handled by IOS SLB, including Wireless Session Protocol (WSP) events and states.

The optional acl-number argument references an IP access control list (ACL). This argument limits the information displayed based on the client IP address, real server IP address, or virtual server IP address:

For simple ACLs, IOS SLB checks the client IP address.

For extended ACLs, IOS SLB checks the client real and virtual IP addresses.

For more information about ACLs, refer to the "Configuring IP Services" chapter of the Cisco IOS IP Configuration Guide, Release 12.2.

dfp

Displays debugging messages for Dynamic Feedback Protocol (DFP).

To display debugging messages for the DFP agent subsystem, use the debug ip dfp agent command.

To display debugging messages for the general packet radio service (GPRS) DFP weight calculation, use the debug gprs dfp command.

firewallfarm

Displays debugging messages related to firewall load balancing.

fragments

Displays debugging messages related to the IOS SLB fragment database.

gtp

Displays all GPRS Tunneling Protocol (GTP)-related packet handler, gateway GPRS support node (GGSN), serving GPRS support node (SGSN), and NSAPI debugging messages for IOS SLB.

icmp

Displays all Internet Control Message Protocol debugging messages for IOS SLB.

natpool

Displays debugging messages related to the IOS SLB client Network Address Translation (NAT) pool.

probe

Displays debugging messages related to probes.

reals

Displays debugging messages for all real servers defined to IOS SLB.

replication

Displays debugging messages related to IOS SLB stateful backup virtual server.

route

Displays debugging messages for all routing handled by the IOS SLB RADIUS framed-IP sticky database.

sessions [gtp | ipmobile | radius]

Displays debugging messages for all sessions being handled by IOS SLB.

The optional gtp keyword enables users to limit the information displayed to only GTP sessions.

The optional ipmobile keyword enables users to limit the information displayed to only Mobile IP sessions.

The optional radius keyword enables users to limit the information displayed to only RADIUS sessions.

vservers

Displays debugging messages for all virtual servers defined to IOS SLB.


Defaults

No default behavior or values

Command Modes

User EXEC or privileged EXEC

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.1(2)E

The natpool and replication keywords were added.

12.1(3a)E

The firewallfarm keyword was added.

12.1(7)E

The vservers keyword was added.

12.1(9)E

The sessions keyword was added.

12.1(11b)E

The route keyword, the acl-number argument, and the radius option on the sessions keyword were added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.

12.1(13)E3

The gtp keyword and the gtp option on the sessions keyword were added.

12.2(14)ZA2

The ipmobile keyword was added.


Usage Guidelines

This command displays debugging messages for IOS SLB.


Caution Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network flows and fewer users. Debugging during these periods reduces the effect these commands have on other users on the system.

Examples

The following example configures a debugging session to check all IP IOS SLB parameters:

Router# debug ip slb all
SLB All debugging is on
Router# 

The following example stops all debugging:

Router# no debug all
All possible debugging has been turned off
Router#

The following example configures debugging to check IP IOS SLB replication used with stateful backup and displays the output from the send or transmit virtual server:

Router# debug ip slb replication
*Mar  2 08:02:38.019:  SLB Replicate: (send) update vs: VS1 update_count 42

delay (firewall farm TCP protocol)

To change the amount of time IOS Server Load Balancing (IOS SLB) maintains TCP connection context after a connection has terminated, use the delay command in firewall farm TCP protocol configuration mode. To restore the default delay timer, use the no form of this command.

delay duration

no delay

Syntax Description

duration

Delay timer duration in seconds. The valid range is 1 to 600 seconds. The default value is 10 seconds.


Defaults

The default duration is 10 seconds.

Command Modes

Firewall farm TCP protocol configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

The delay timer allows out-of-sequence packets and final acknowledgments (ACKs) to be delivered after a TCP connection ends. Do not set this value to zero (0).

If you are configuring a delay timer for HTTP flows, choose a low number such as 5 seconds as a starting point.

Examples

The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:

Router(config)# ip slb firewallfarm FIRE1
Router(config-slb-fw)# protocol tcp
Router(config-slb-fw-tcp)# delay 30

Related Commands

Command
Description

protocol tcp

Enters firewall farm TCP protocol configuration mode.

show ip slb firewallfarm

Displays information about the firewall farm configuration.


delay (virtual server)

To change the amount of time IOS Server Load Balancing (IOS SLB) maintains TCP connection context after a connection has terminated, use the delay command in virtual server configuration mode. To restore the default delay timer, use the no form of this command.

delay duration

no delay

Syntax Description

duration

Delay timer duration in seconds. The valid range is 1 to 600 seconds. The default value is 10 seconds.


Defaults

The default duration is 10 seconds.

Command Modes

Virtual server configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

The delay timer allows out-of-sequence packets and final acknowledgments (ACKs) to be delivered after a TCP connection ends. Do not set this value to zero (0).

If you are configuring a delay timer for HTTP flows, choose a low number such as 5 seconds as a starting point.

For the Home Agent Director, the delay command has no meaning and is not supported.

Examples

The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:

Router(config)# ip slb vserver PUBLIC_HTTP
Router(config-slb-vserver)# delay 30

Related Commands

Command
Description

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).

virtual (virtual server)

Configures the virtual server attributes.


expect

To configure a status code or regular expression to expect information from the HTTP probe, use the expect command in HTTP probe configuration mode. To restore the default settings, use the no form of this command.

expect [status status-code] [regex expression]

no expect [status status-code] [regex expression]

Syntax Description

status status-code

(Optional) Configures the expected HTTP status code. The valid range is 100 to 599. The default expected status code is 200.

regex expression

(Optional) Configures the regular expression expected in the HTTP response.


Defaults

The default expected status code is 200.
There is no default expected regular expression.

Command Modes

HTTP probe configuration

Command History

Release
Modification

12.1(2)E

This command was introduced.

12.1(3a)E

The regex keyword and expression argument were added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

The expect command configures the expected status code or regular expression to be received from the servers. A real server is considered to have failed and is taken out of service if any of the following events occurs:

A status number other than the expected one is received.

The expected regular expression is not received in the first 2920 bytes of probe output. (IOS SLB searches only the first 2920 bytes for the expected status code or regular expression.)

The server fails to respond.

For IOS SLB firewall load balancing, configure the HTTP probe to expect status code 40l.

Examples

The following example configures an HTTP probe named PROBE2, enters HTTP configuration mode, and configures the HTTP probe to expect the status code 40l and the regular expression Copyright:

Router(config)# ip slb probe PROBE2 http
Router(config-slb-probe)# expect status 401 regex Copyright

Related Commands

Command
Description

ip slb probe http

Configures an HTTP probe name and enters HTTP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


failaction (firewall farm)

To configure IOS Server Load Balancing (IOS SLB)'s behavior when a firewall fails, use the failaction command in firewall farm configuration mode.

failaction purge

Syntax Description

purge

Enables IOS SLB to automatically remove connections to failed firewalls from the connection database even if the idle timers have not expired.


Defaults

If you do not specify the failaction command, IOS SLB does not automatically remove connections to failed firewalls.

Command Modes

Firewall farm configuration

Command History

Release
Modification

12.1(9)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

This command is useful for applications that do not rotate the source port (such as Internet Key Exchange [IKE]), and for protocols that do not have ports to differentiate flows (such as Encapsulation Security Payload [ESP]).

Examples

In the following example, IOS SLB removes all connections to failed firewalls in firewall farm FIRE1:

Router(config)# ip slb firewallfarm FIRE1
Router(config-slb-fw)# failaction purge

failaction (server farm)

To configure IOS Server Load Balancing (IOS SLB)'s behavior when a real server fails, use the failaction command in server farm configuration mode. To restore the default settings, use the no form of this command.

failaction {purge | radius reassign}

no failaction {purge | radius reassign}

Syntax Description

purge

Enables IOS SLB to automatically remove connections to failed real servers from the connection database even if the idle timers have not expired.

radius reassign

Enables IOS SLB to automatically reassign to a new real server RADIUS sticky objects that are destined for a failed real server.


Defaults

If you do not specify the failaction command, IOS SLB does not automatically remove connections to failed real servers, nor does it reassign RADIUS sticky objects.

Command Modes

Server farm configuration

Command History

Release
Modification

12.1(9)E

This command was introduced.

12.1(11b)E

The radius reassign keywords were added.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

This command is useful for applications that do not rotate the source port (such as Internet Key Exchange [IKE]), and for protocols that do not have ports to differentiate flows (such as Encapsulation Security Payload [ESP]).

You can specify no failaction purge, but it has no effect on the connection database.

If you specify failaction radius reassign, IOS SLB reassigns RADIUS sticky objects without seeing any new RADIUS messages. The assumption is that, in the event of a failure, the RADIUS proxy gateways can handle user flows without seeing the RADIUS messages. If the RADIUS proxy gateways cannot do so, do not specify the failaction radius reassign command.

Examples

In the following example, IOS SLB removes all connections to failed real servers in server farm PUBLIC:

Router(config)# ip slb serverfarm PUBLIC
Router(config-slb-sfarm)# failaction purge

faildetect (DNS probe)

To specify the conditions that indicate a server failure, use the faildetect command in DNS probe configuration mode. To restore the default values that indicate a server failure, use the no form of this command.

faildetect number-of-probes

no faildetect

Syntax Description

number-of-probes

Number of consecutive unacknowledged Domain Name System (DNS) probes allowed before a real server is considered to have failed. Valid range is 1 to 65535. The default value is three (3) unacknowledged DNS probes.


Defaults

The default value is three (3) unacknowledged DNS probes.

Command Modes

DNS probe configuration

Command History

Release
Modification

12.1(11b)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

In the following example the unacknowledged DNS probe threshold is set to 16:

Router(config)# ip slb probe PROBE4 dns
Router(config-slb-probe)# faildetect 16

Related Commands

Command
Description

ip slb probe dns

Configures a Domain Name System (DNS) probe name and enters DNS probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


faildetect (ping probe)

To specify the conditions that indicate a server failure, use the faildetect command in ping probe configuration mode. To restore the default values that indicate a server failure, use the no form of this command.

faildetect number-of-pings

no faildetect

Syntax Description

number-of-pings

Number of consecutive unacknowledged pings allowed before a real server is considered to have failed. Valid range is 1 to 65535. The default is ten (10) unacknowledged pings.


Defaults

The default value is ten (10) unacknowledged pings.

Command Modes

Ping probe configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

In the following example the unacknowledged ping threshold is set to 16:

Router(config)# ip slb probe PROBE1 ping
Router(config-slb-probe)# faildetect 16

Related Commands

Command
Description

ip slb probe ping

Configures a ping probe name and enters ping probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


faildetect inband (real server)

To enable automatic server failure detection, use the faildetect inband command in real server configuration mode. To disable automatic server failure detection, use the no form of this command.

faildetect inband

no faildetect inband

Syntax Description

This command has no arguments or keywords.

Defaults

Automatic server failure detection is enabled.

Command Modes

Real server configuration

Command History

Release
Modification

12.2(14)ZA4

This command was introduced.


Usage Guidelines

If you have configured all-port virtual servers (that is, virtual servers that accept flows destined for all ports except GTP ports), flows can be passed to servers for which no application port exists. When the servers reject these flows, IOS SLB might fail the servers and remove them from load balancing. This situation can also occur in slow-to-respond AAA servers in RADIUS load-balancing environments. To prevent this situation, you can disable automatic server failure detection using the no faildetect inband command.


Note If you disable automatic server failure detection using the no faildetect inband command, Cisco strongly recommends that you configure one or more probes.

If you specify the no faildetect inband command, the faildetect numconns command is ignored, if specified.


Examples

In the following example, automatic server failure detection is disabled:

Router(config)# ip slb serverfarm PUBLIC
Router(config-slb-sfarm)# real 10.10.1.1
Router(config-slb-real)# no faildetect inband

Related Commands

Command
Description

faildetect numconns (real server)

Specifies the conditions that indicate a real server failure.

real (server farm)

Identifies a real server by IP address and optional port number as a member of a server farm and enters real server configuration mode.

show ip slb reals

Displays information about the real servers.

show ip slb serverfarms

Displays information about the server farm configuration.


faildetect numconns (real server)

To specify the conditions that indicate a real server failure, use the faildetect numconns command in real server configuration mode. To restore the default values that indicate a server failure, use the no form of this command.

faildetect numconns number-of-conns [numclients number-of-clients]

no faildetect numconns number-of-conns [numclients number-of-clients]

Syntax Description

number-of-conns

Number of consecutive connection failures allowed before IOS Server Load Balancing (IOS SLB) fails the real server. The valid range is 1 to 255. The default value is 8.

numclients number-of-clients

(Optional) Number of unique client IP addresses that can experience connection failures before IOS SLB fails the real server. The valid range is 1 to 8. The default value is 2.

If there is only one client in your network (for example, one serving GPRS support node [SGSN] in a general packet radio service [GPRS] load-balancing environment), then you must specify numclients 1.

In RADIUS load balancing, for automatic session-based failure detection, specify numclients 1.


Defaults

If you do not specify the faildetect numconns command, the default value of the connection failure threshold is 8.
If you specify the faildetect numconns command but do not specify the numclients keyword, the default value of the client connection failure threshold is 2.

Command Modes

Real server configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.1(9)E

This command was modified to support GPRS load balancing.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

If you specify the no faildetect inband command, the faildetect numconns command is ignored, if specified.

IOS SLB does not fail the real server until both of the following conditions are met:

There have been number-of-conns consecutive connection failures.

There have been number-of-clients unique client connection failures.

That is, there can be many consecutive connection failures, but until there have also been number-of-clients unique client connection failures, IOS SLB does not fail the real server.

Similarly, there can be many unique client connection failures, but until there have also been number-of-conns consecutive connection failures, IOS SLB does not fail the real server.

GPRS load balancing has the following features:

The numconns keyword specifies the number of consecutive Create Packet Data Protocol (PDP) requests allowed before IOS SLB fails the gateway GPRS support node (GGSN).

The numclients keyword specifies the number of unique client Create PDP request failures allowed before IOS SLB fails the GGSN.

Examples

In the following example, the numconns keyword is set to 10 and the numclients keyword is set to 3:

Router(config)# ip slb serverfarm PUBLIC
Router(config-slb-sfarm)# real 10.10.1.1
Router(config-slb-real)# faildetect numconns 10 numclients 3

With those settings, IOS SLB will not fail the real server until there have been ten (10) consecutive connection failures and there have been three (3) unique client connection failures.

Related Commands

Command
Description

faildetect inband (real server)

Enables automatic server failure detection.

real (server farm)

Identifies a real server by IP address and optional port number as a member of a server farm and enters real server configuration mode.

show ip slb reals

Displays information about the real servers.

show ip slb serverfarms

Displays information about the server farm configuration.


hand-off radius

To change the amount of time IOS Server Load Balancing (IOS SLB) waits for an ACCT-START message from a new Mobile IP foreign agent in the event of a foreign agent hand-off, use the hand-off radius command in virtual server configuration mode. To restore the default hand-off timer, use the no form of this command.

hand-off radius duration

no hand-off radius

Syntax Description

duration

Hand-off timer duration in seconds. The valid range is 1 to 43200 seconds.


Defaults

No default behavior or values

Command Modes

Virtual server configuration

Command History

Release
Modification

12.2(14)ZA2

This command was introduced.


Usage Guidelines

The hand-off radius timer is valid only for RADIUS virtual servers that have the service radius keywords specified on the virtual command.

Examples

The following example specifies that IOS SLB waits for 30 seconds after a foreign agent hand-off:

Router(config)# ip slb vserver PUBLIC_HTTP
Router(config-slb-vserver)# hand-off radius 30

Related Commands

Command
Description

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).

virtual (virtual server)

Configures the virtual server attributes.


header

To configure the basic authentication values for the HTTP probe, use the header command in HTTP probe configuration mode. To remove a header HTTP probe configuration, use the no form of this command.

header field-name [field-value]

no header field-name [field-value]

Syntax Description

field-name

Configures the name of the HTTP probe header. The character string is limited to 15 characters.

field-value

(Optional) Configures the value of the HTTP probe header.


Defaults

The following headers are inserted in the request by default:

Accept: */*
Connection: close
User-Agent: cisco-slb-probe/1.0
Host: virtual IP address

Command Modes

HTTP probe configuration

Command History

Release
Modification

12.1(2)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

The header command in HTTP probe configuration mode configures the name and value parameters of the header.


Note The colon ( : ) separating the field name and field value is automatically inserted if not provided. Multiple headers with the same name are not supported.


Examples

The following example configures an HTTP probe named PROBE2, enters HTTP configuration mode, and configures the HTTP probe header name as HeaderName and value as HeaderValue:

Router(config)# ip slb probe PROBE2 http
Router(config-slb-probe)# header HeaderName HeaderValue

Related Commands

Command
Description

ip slb probe http

Configures an HTTP probe name and enters HTTP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


idle (firewall farm datagram protocol)

To specify the minimum time IOS Server Load Balancing (IOS SLB) maintains connection information in the absence of packet activity, use the idle command in firewall farm datagram protocol configuration mode. To restore the default idle duration value, use the no form of this command.

idle duration

no idle

Syntax Description

duration

Idle connection timer duration in seconds. Valid values range from 10 to 65535 seconds. The default is 3600 seconds (1 hour).


Defaults

The default idle duration is 3600 seconds.

Command Modes

Firewall farm datagram protocol configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds:

Router(config)# ip slb firewallfarm FIRE1
Router(config-slb-fw)# protocol datagram
Router(config-slb-fw-udp)# idle 120

Related Commands

Command
Description

protocol datagram

Enters firewall farm datagram protocol configuration mode.

show ip slb firewallfarm

Displays information about the firewall farm configuration.


idle (firewall farm TCP protocol)

To specify the minimum time IOS Server Load Balancing (IOS SLB) maintains connection information in the absence of packet activity, use the idle command in firewall farm TCP protocol configuration mode. To restore the default idle duration value, use the no form of this command.

idle duration

no idle

Syntax Description

duration

Idle connection timer duration in seconds. Valid values range from 10 to 65535 seconds. The default is 3600 seconds (1 hour).


Defaults

The default idle duration is 3600 seconds.

Command Modes

Firewall farm TCP protocol configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

If a client sends a TCP packet that is not a sequence number (SYN) or reset (RST) packet, and IOS SLB does not have a TCP connection object in its table (possibly due to expiration of the idle timer), IOS SLB sends a TCP RST to the client.

If you are configuring an idle timer for HTTP flows, choose a low number such as 120 seconds as a starting point. A low number ensures that the IOS SLB connection database maintains a manageable size if problems at the server, client, or network result in a large number of connections. However, do not choose a value under 60 seconds; such a low value can reduce the efficiency of IOS SLB.

Examples

The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds:

Router(config)# ip slb firewallfarm FIRE1
Router(config-slb-fw)# protocol tcp
Router(config-slb-fw-tcp)# idle 120

Related Commands

Command
Description

protocol tcp

Enters firewall farm TCP protocol configuration mode.

show ip slb firewallfarm

Displays information about the firewall farm configuration.


idle (virtual server)

To specify the minimum time IOS Server Load Balancing (IOS SLB) maintains connection information in the absence of packet activity, use the idle command in virtual server configuration mode. To restore the default idle duration value, use the no form of this command.

idle [gtp request | ipmobile request | radius {request | framed-ip}] duration

no idle [gtp request | ipmobile request | radius {request | framed-ip}] duration

Syntax Description

gtp request

(Optional) For general packet radio service (GPRS) Tunneling Protocol (GTP) cause code inspection, configures the duration for Packet Data Protocol (PDP) context create, update, or delete request messages to a real gateway GPRS support node (GGSN) to go unanswered, before IOS SLB cleans up the session object.

ipmobile request

(Optional) For Home Agent Director, configures the duration for IOS SLB to wait for a Mobile IP Registration Request (RRQ), before IOS SLB cleans up the session object.

radius request

(Optional) Configures the duration for RADIUS entries in the IOS SLB session database.

radius framed-ip

(Optional) Configures the duration for entries in the IOS SLB RADIUS framed-IP sticky database.

duration

Idle connection timer duration in seconds. Valid values range from 4 to 65535 seconds. The default values are:

10 seconds in the Home Agent Director.

30 seconds in general packet radio service (GPRS) load balancing.

30 seconds for RADIUS entries in the IOS SLB session database.

7200 seconds for entries in the IOS SLB RADIUS framed-IP sticky database.

3600 seconds (1 hour) in all other environments.


Defaults

The default idle duration is:

10 seconds in the Home Agent Director

30 seconds in GPRS load balancing

30 seconds for RADIUS entries in the IOS SLB session database

7200 seconds for entries in the IOS SLB RADIUS framed-IP sticky database

3600 seconds (1 hour) in all other environments

Command Modes

Virtual server configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.1(9)E

This command was modified to support GPRS load balancing.

12.1(11b)E

This command was modified to support RADIUS load balancing.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.

12.1(13)E3

The gtp request option was added.

12.2(14)ZA2

The ipmobile request option was added.


Usage Guidelines

If a client sends a TCP packet that is not a sequence number (SYN) or reset (RST) packet, and IOS SLB does not have a TCP connection object in its table (possibly due to expiration of the idle timer), IOS SLB sends a TCP RST to the client.

If you are configuring an idle timer for HTTP flows, choose a low number such as 120 seconds as a starting point. A low number ensures that the IOS SLB connection database maintains a manageable size if problems at the server, client, or network result in a large number of connections. However, do not choose a value under 60 seconds (except in GPRS load balancing); such a low value can reduce the efficiency of IOS SLB.

In most environments, the idle timer times out data paths. However, in GPRS load balancing, it times out the session context for signaling paths (not data paths).

In GPRS load balancing without GTP cause code inspection enabled, you must specify an idle timer greater than the longest possible interval between PDP context requests on the serving GPRS support node (SGSN). The longest interval can be expressed using the following algorithm:

Longest interval = T3 x 2(N3-2)

where T3 is the SGSN's T3-RESPONSE counter value and N3 is the SGSN's N3-REQUESTS counter value.

For example, if the T3-RESPONSE counter value is 3 and the N3-REQUESTS counter value is 6, then:

Longest interval = 3 x 2(6-2) = 3 x 2(4) = 3 x 16 = 48 seconds

Given those values, you must specify an idle timer of at least 49 seconds.

Examples

The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds:

Router(config)# ip slb vserver PUBLIC_HTTP
Router(config-slb-vserver)# idle 120

Related Commands

Command
Description

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).

virtual (virtual server)

Configures the virtual server attributes.


inservice (firewall farm)

To enable the firewall farm for use by IOS Server Load Balancing (IOS SLB), use the inservice command in firewall farm configuration mode. To remove the firewall farm from service, use the no form of this command.

inservice [standby group-name]

no inservice [standby group-name]

Syntax Description

standby

(Optional) Configures the Hot Standby Router Protocol (HSRP) standby firewall farm for use with stateless and stateful backup.

group-name

(Optional) HSRP group name with which the IOS SLB firewall farm is associated.


Defaults

The firewall farm is defined to IOS SLB but is not used.

Command Modes

Firewall farm configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

When you use the no form of this command to remove a firewall farm from service, the firewall farm acquiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.

Examples

In the following example, the firewall farm is enabled for use by the IOS SLB feature:

Router(config)# ip slb firewallfarm FIRE1
Router(config-slb-fw)# inservice

Related Commands

Command
Description

ip slb firewallfarm

Identifies a firewall by IP address farm and enters firewall farm configuration mode.

show ip slb firewallfarm

Displays information about the firewall farm configuration.


inservice (firewall farm real server)

To enable the firewall for use by IOS Server Load Balancing (IOS SLB), use the inservice command in firewall farm real server configuration mode. To remove the firewall from service, use the no form of this command.

inservice

no inservice

Syntax Description

This command has no arguments or keywords.

Defaults

The firewall is defined to IOS SLB but is not used.

Command Modes

Firewall farm real server configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

IOS SLB firewall load balancing uses probes to detect failures. Therefore, if you have not configured a probe, the firewall is not placed in service.

When you use the no form of this command to remove a firewall from service, the firewall acquiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.

Examples

In the following example, the firewall is enabled for use by the IOS SLB feature:

Router(config)# ip slb firewallfarm FIRE1
Router(config-slb-fw)# real 10.10.1.1
Router(config-slb-fw-real)# inservice

Related Commands

Command
Description

real (firewall farm)

Identifies a firewall by IP address as a member of a firewall farm and enters real server configuration mode.

show ip slb firewallfarm

Displays information about the firewall farm configuration.

show ip slb reals

Displays information about the real servers.


inservice (server farm real server)

To enable the real server for use by IOS Server Load Balancing (IOS SLB), use the inservice command in server farm real server configuration mode. To remove the real server from service, use the no form of this command.

inservice

no inservice

Syntax Description

This command has no arguments or keywords.

Defaults

The real server is defined to IOS SLB but is not used.

Command Modes

Server farm real server configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

When you use the no form of this command to remove a real server from service, the real server acquiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.

Examples

In the following example, the real server is enabled for use by the IOS SLB feature:

Router(config)# ip slb serverfarm PUBLIC
Router(config-slb-sfarm)# real 10.10.1.1
Router(config-slb-sfarm-real)# inservice

Related Commands

Command
Description

real (server farm)

Identifies a real server by IP address and optional port number as a member of a server farm and enters real server configuration mode.

show ip slb reals

Displays information about the real servers.

show ip slb serverfarms

Displays information about the server farm configuration.


inservice (server farm virtual server)

To enable the virtual server for use by IOS Server Load Balancing (IOS SLB), use the inservice command in server farm virtual server configuration mode. To remove the virtual server from service, use the no form of this command.

inservice [standby group-name]

no inservice [standby group-name]

Syntax Description

standby

(Optional) Configures the Hot Standby Router Protocol (HSRP) standby virtual server for use with stateless and stateful backup.

group-name

(Optional) HSRP group name with which the IOS SLB virtual server is associated.


Defaults

The virtual server is defined to IOS SLB but is not used.

Command Modes

Server farm virtual server configuration

Command History

Release
Modification

12.0(7)XE

This command was introduced.

12.1(1)E

The standby keyword and group-name argument were added.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.2

This command was integrated into Cisco IOS Release 12.2.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Usage Guidelines

When you use the no form of this command to remove a virtual server from service, the virtual server acquiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.

Examples

In the following example, the virtual server is enabled for use by the IOS SLB feature:

Router(config)# ip slb vserver PUBLIC_HTTP
Router(config-slb-vserver)# inservice

Related Commands

Command
Description

show ip slb vserver

Displays information about the virtual servers defined to IOS Server Load Balancing (IOS SLB).

virtual (virtual server)

Configures the virtual server attributes.


interval (custom UDP probe)

To configure a custom User Datagram Protocol (UDP) probe interval, use the interval command in custom UDP probe configuration mode. To remove a custom UDP probe interval configuration, use the no form of this command.

interval seconds

no interval seconds

Syntax Description

seconds

Number of seconds to wait before reattempting the probe. Valid values range from 1 to 65535 seconds. The default interval is 10 seconds.


Defaults

The default custom UDP probe interval value is 10 seconds.

Command Modes

Custom UDP probe configuration

Command History

Release
Modification

12.1(13)E3

This command was introduced.


Examples

The following example configures a custom UDP probe named PROBE6, enters custom UDP configuration mode, and configures the custom UDP probe timer interval to send every 11 seconds:

Router(config)# ip slb probe PROBE6 tcp
Router(config-slb-probe)# interval 11

Related Commands

Command
Description

ip slb probe custom udp

Configures a custom User Datagram Protocol (UDP) probe name and enters custom UDP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


interval (DNS probe)

To configure a DNS probe interval, use the interval command in Domain Name System (DNS) probe configuration mode. To remove a DNS probe interval configuration, use the no form of this command.

interval seconds

no interval seconds

Syntax Description

seconds

Number of seconds to wait before reattempting the probe. Valid values range from 1 to 65535 seconds. The default interval is 10 seconds.


Defaults

The default DNS probe interval value is 10 seconds.

Command Modes

DNS probe configuration

Command History

Release
Modification

12.1(11b)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a DNS probe named PROBE4, enters DNS configuration mode, and configures the DNS probe timer interval to send every 11 seconds:

Router(config)# ip slb probe PROBE4 dns
Router(config-slb-probe)# interval 11

Related Commands

Command
Description

ip slb probe dns

Configures a Domain Name System (DNS) probe name and enters DNS probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


interval (HTTP probe)

To configure an HTTP probe interval, use the interval command in HTTP probe configuration mode. To remove an HTTP probe interval configuration, use the no form of this command.

interval seconds

no interval seconds

Syntax Description

seconds

Number of seconds to wait before reattempting the probe. Valid values range from 1 to 65535 seconds. The default interval is 8 seconds.


Defaults

The default HTTP probe interval value is 8 seconds.

Command Modes

HTTP probe configuration

Command History

Release
Modification

12.1(2)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures an HTTP probe named PROBE2, enters HTTP configuration mode, and configures the HTTP probe timer interval to send every 11 seconds:

Router(config)# ip slb probe PROBE2 http
Router(config-slb-probe)# interval 11

Related Commands

Command
Description

ip slb probe http

Configures an HTTP probe name and enters HTTP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


interval (ping probe)

To configure a ping probe interval, use the interval command in ping probe configuration mode. To remove a ping probe interval configuration, use the no form of this command.

interval seconds

no interval seconds

Syntax Description

seconds

Number of seconds to wait before reattempting the probe. Valid values range from 1 to 65535 seconds. The default interval is 1 second.


Defaults

The default ping probe interval value is 1 second.

Command Modes

Ping probe configuration

Command History

Release
Modification

12.1(3a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a ping probe named PROBE1, enters ping configuration mode, and configures the ping probe timer interval to send every 11 seconds:

Router(config)# ip slb probe PROBE1 ping
Router(config-slb-probe)# interval 11

Related Commands

Command
Description

ip slb probe ping

Configures a ping probe name and enters ping probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


interval (TCP probe)

To configure a TCP probe interval, use the interval command in TCP probe configuration mode. To remove a TCP probe interval configuration, use the no form of this command.

interval seconds

no interval seconds

Syntax Description

seconds

Number of seconds to wait before reattempting the probe. Valid values range from 1 to 65535 seconds. The default interval is 10 seconds.


Defaults

The default TCP probe interval value is 10 seconds.

Command Modes

TCP probe configuration

Command History

Release
Modification

12.1(11b)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a TCP probe named PROBE5, enters TCP configuration mode, and configures the TCP probe timer interval to send every 11 seconds:

Router(config)# ip slb probe PROBE5 tcp
Router(config-slb-probe)# interval 11

Related Commands

Command
Description

ip slb probe tcp

Configures a TCP probe name and enters TCP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


interval (WSP probe)

To configure a Wireless Session Protocol (WSP) probe interval, use the interval command in WSP probe configuration mode. To remove a WSP probe interval configuration, use the no form of this command.

interval seconds

no interval seconds

Syntax Description

seconds

Number of seconds to wait before reattempting the probe. Valid values range from 1 to 65535 seconds. The default interval is 8 seconds.


Defaults

The default WSP probe interval value is 8 seconds.

Command Modes

WSP probe configuration

Command History

Release
Modification

12.1(5a)E

This command was introduced.

12.2(14)S

This command was integrated into Cisco IOS Release 12.2(14)S.


Examples

The following example configures a ping probe named PROBE3, enters WSP probe configuration mode, and configures the WSP probe timer interval to send every 11 seconds:

Router(config)# ip slb probe PROBE3 wsp
Router(config-slb-probe)# interval 11

Related Commands

Command
Description

ip slb probe wsp

Configures a Wireless Session Protocol (WSP) probe name and enters WSP probe configuration mode.

show ip slb probe

Displays information about an IOS Server Load Balancing (IOS SLB) probe.


ip slb dfp

To configure Dynamic Feedback Protocol (DFP), supply an optional password, and enter DFP configuration mode, use the ip slb dfp command in global configuration mode. To remove the DFP configuration, use the no form of this command.

ip slb dfp [password [0 | 7] password [timeout]]

no ip slb dfp

Syntax Description

password

(Optional) Password for Message Digest Algorithm Version 5 (MD5) authentication.