Table Of Contents
Configuring Server Load Balancing
Finding Feature Information
Contents
Restrictions for IOS SLB
Information About IOS SLB
Benefits of IOS SLB
General IOS SLB Features
Routing Features
Security Features
Server Failure Detection and Recovery Features
Protocol Support Features
Redundancy Features
Exchange Director Features
How to Configure IOS SLB
Configuring Required and Optional IOS SLB Functions
Configuring a Server Farm and a Real Server
Configuring a Virtual Server
Verifying a Virtual Server
Verifying a Server Farm
Verifying the Clients
Verifying IOS SLB Connectivity
Configuring Firewall Load Balancing
Configuring a Firewall Farm
Verifying a Firewall Farm
Verifying Firewall Connectivity
Configuring a Probe
Configuring a Custom UDP Probe
Configuring a DNS Probe
Configuring an HTTP Probe
Configuring a Ping Probe
Configuring a TCP Probe
Configuring a WSP Probe
Associating a Probe
Verifying a Probe
Configuring DFP
What to Do Next
GPRS Load Balancing Configuration Task List
Configuring a GSN Idle Timer
GGSN-IOS SLB Messaging Task List
Configuring GPRS Load Balancing Maps
Configuring KeepAlive Application Protocol (KAL-AP) Agent Support
RADIUS Load Balancing Configuration Task List
Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing
Configuring RADIUS Load Balancing Maps
Configuring RADIUS Load Balancing Accelerated Data Plane Forwarding
Prerequisites
Exchange Director for mSEF Configuration Task List
RADIUS Configuration for the Exchange Director
Firewall Configuration for the Exchange Director
VPN Server Load Balancing Configuration Task List
ASN R6 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 a Wildcard Search
Purging and Reassigning Connections
Disabling Automatic Server Failure Detection
Monitoring and Maintaining IOS SLB
Configuration Examples for IOS SLB
Configuring a Basic IOS SLB Network: Example
Server Farm Configuration
Virtual Server Configuration
Restricted Client Configuration
Configuring a Complete IOS SLB Network: Example
Configuring IOS SLB with Firewall Load Balancing: Examples
Configuring IOS SLB with Basic Firewall Load Balancing: Example
Configuring IOS SLB with Server Load Balancing and Firewall Load Balancing: Example
Configuring IOS SLB with Multiple Firewall Farms: Example
Configuring IOS SLB with Dual Firewall Load Balancing "Sandwich": Example
Configuring IOS SLB with Probes: Examples
Configuring IOS SLB with Ping and HTTP Probes: Example
Configuring IOS SLB with Routed Probe: Example
Configuring a Layer 3 Switch with IOS SLB: Example
Configuring IOS SLB with NAT and Static NAT: Examples
Configuring IOS SLB with NAT: Example
Configuring IOS SLB with Static NAT: Example
Configuring IOS SLB with Redundancy: Examples
Configuring IOS SLB with Stateless Backup: Examples
Configuring IOS SLB with Stateful Backup: Example
Configuring IOS SLB with Stateful Backup of Redundant Route Processors: Example
Configuring IOS SLB with Active Standby: Example
Configuring 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)
Configuring IOS SLB with WAP and UDP Load Balancing: Example
Balancing WAP Flows on UDP Port 9201
Balancing WAP Flows on UDP Port 9203
Configuring IOS SLB with Route Health Injection: Examples
Configuring Two Distributed Sites with One Web Server Each: Example
Configuring Two Distributed Sites with Two Web Servers Each: Example
Configuring Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each: Example
Configuring IOS SLB with GPRS Load Balancing: Examples
Configuring IOS SLB with GPRS Load Balancing Without GTP Cause Code Inspection: Example
Configuring IOS SLB with GPRS Load Balancing and NAT: Example
Configuring IOS SLB with GPRS Load Balancing, NAT, and GTP Cause Code Inspection: Example
Configuring IOS SLB with GPRS Load Balancing Maps: Example
Configuring IOS SLB with VPN Server Load Balancing: Example
Configuring IOS SLB with RADIUS Load Balancing: Examples
Configuring IOS SLB with RADIUS Load Balancing for a GPRS Network: Example
Configuring IOS SLB with RADIUS Load Balancing for a Simple IP CDMA2000 Network: Example
Configuring IOS SLB with RADIUS Load Balancing for a Mobile IP CDMA2000 Network: Example
Configuring IOS SLB with RADIUS Load Balancing for Multiple Service Gateway Farms: Example
Configuring IOS SLB with RADIUS Load Balancing/Firewall Load Balancing "Sandwich": Example
Configuring IOS SLB with RADIUS Load Balancing Maps: Example
Configuring IOS SLB with RADIUS Load Balancing Accelerated Data Plane Forwarding: Example
Configuring IOS SLB with Home Agent Director: Example
Configuring IOS SLB with Sticky Connections: Example
Configuring IOS SLB with GTP IMSI Sticky Database: Example
Configuring IOS SLB with Transparent Web Cache Load Balancing: Example
Configuring IOS SLB with KAL-AP Agent: Example
GSS
Site-1: IOS SLB - CHICAGO
Site-2: IOS SLB - NEWYORK
Additional References
Troubleshooting
Related Documents
Supported Platforms
Standards
MIBs
RFCs
Technical Assistance
Feature Information for IOS SLB
Configuring Server Load Balancing
First Published: January 14, 2008
Last Updated: September 30, 2009
This document describes how to configure the IOS Server Load Balancing (IOS SLB) feature. For a complete description of the IOS SLB commands in this chapter, refer to the "Server Load Balancing Commands" chapter of the Cisco IOS IP Application Services Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
The SLB feature is a Cisco IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, the network administrator defines a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. In this environment the clients are configured to connect to the IP address of the virtual server. The virtual server IP address is configured as a loopback address, or secondary IP address, on each of the real servers. When a client initiates a connection to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured load-balancing algorithm.
The IOS SLB feature 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:
•mobile Service Exchange Framework (mSEF) components:
–Cisco Content Services Gateways (CSGs)
If you are running with Supervisor Engine 32 (SUP32-MSFC2A), CSG Release 3.1(3)C7(1) or later is required.
–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 mSEF for Catalyst 6500 family switches and Cisco 7600 series 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
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for IOS SLB" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS, Cisco Catalyst OS, and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•Restrictions for IOS SLB
•Information About IOS SLB
•How to Configure IOS SLB
•Configuration Examples for IOS SLB
•Additional References
•Feature Information for IOS SLB
Restrictions for IOS SLB
General 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.
•Do not configure an IOS SLB virtual IP address on the same subnet as any real server IP address, unless all server farms that include the real server IP address are configured with nat server.
•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.
•Does not support Dynamic Host Configuration Protocol (DHCP) load balancing.
•Does not support Internet Protocol version 6 (IPv6).
•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 that is the same as one of the IOS interface IP 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).
•Do not use the virtual IP address configured in the IOS SLB virtual server for UDP-based router management applications such as SNMP. Doing so can result in high CPU usage. (This is not a problem for a UDP virtual server that is configured with destination port number 0.)
•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.
•When both IOS SLB and the Web Cache Communication Protocol (WCCP) are configured on a Catalyst 6500 family switch, and WCCP Input Redirection is configured with IOS SLB, Layer 2 WCCP forwarding must be used between the router and the cache. In this case, WCCP and IOS SLB both run in hardware and are processed in the correct order. If Generic Routing Encapsulation (GRE) forwarding is used, then IOS SLB takes precedence over WCCP and there is no redirection, because GRE forwarding is done on the MSFC. Note that the WCCP forwarding method, either Layer 2 or GRE, is configured on the cache engine and not on the switch.
•Do not configure IOS SLB and a Cisco Service Selection Gateway (SSG) on the same device.
•For "sandwich" configurations, if a flow is to be directed through two IOS SLB instances (virtual servers or firewall farms), the IOS SLB instances must reside in different Virtual Private Network (VPN) routing and forwardings (VRFs).
•If you do not configure an access interface using the access command in server farm, virtual server, or firewall farm configuration mode, IOS SLB automatically configures wildcards for the server farm, virtual server, or firewall farm in all of its interfaces, including the VRF interfaces. If IOS SLB is not required on the VRF interfaces, use the access command to limit wildcards to those interfaces only.
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.
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.
Firewall Load Balancing
•Is no longer limited to a single firewall farm in each load-balancing device.
•Requires that 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:
–Network Address Translation (NAT)
–Port-bound servers
–SynGuard
–TCP session reassignment
–Transparent web cache load balancing
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.
•Supports stateful backup only if sticky connections are enabled.
•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
–Weighted least connections load-balancing algorithm
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
VPN Server Load Balancing
•Does not support Internet Control Message Protocol (ICMP) and wildcard (0-protocol) virtual servers.
RADIUS Load Balancing Accelerated Data Plane Forwarding
•Requires the route map algorithm.
•Requires redundant CSGs for best results.
•Requires static provisioning of load distribution by subscriber address range.
•Supports only simple IP access control lists (ACLs).
•When VSA correlation used, IOS SLB maintains the correlation information only in the active RADIUS load-balancing device, not in the backup RADIUS load-balancing device. The backup RADIUS load-balancing device does not receive VSA correlation information from the active RADIUS load-balancing device.
•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).
•When you specify the predictor route-map command in SLB server farm configuration mode, no further commands in SLB server farm configuration mode or real server configuration mode are allowed.
VSA Correlation
•VSA correlation might result in a degradation of performance.
•IOS SLB maintains the correlation information only in the active RADIUS load-balancing device, not in the backup RADIUS load-balancing device. The backup RADIUS load-balancing device does not receive VSA correlation information from the active RADIUS load-balancing device.
•The Cisco VSA is injected into the RADIUS Accounting-Start packet. The Cisco VSA is not injected into any other RADIUS messages or packets, such as interim RADIUS Accounting ON or OFF messages or RADIUS Accounting-Stop packets.
•You cannot configure radius inject acct commands and radius inject auth commands on the same virtual server.
RADIUS Load Balancing for GPRS
•Requires the weighted round robin algorithm.
•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).
RADIUS Load Balancing for CDMA2000
•Requires the weighted round robin algorithm.
•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.
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
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.
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 Cisco IOS Multiprotocol Label Switching (MPLS):
–Clients can connect to IOS SLB via the MPLS cloud in a Supervisor Engine 720 environment.
–The MPLS client interface must be configured with Tunnel Engineering. No other MPLS configuration is supported.
–The MPLS client interface must receive packets as IP packets.
–The MPLS client interface must be behind a Penultimate Hop Popping (PHP) router.
•For Catalyst 6500 family switches and Cisco 7600 series 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 an MSFC1, MSFC2, or MSFC3, except when specifically differentiated.
The term "PFC" refers to a PFC1, PFC2, or PFC3, except when specifically differentiated.
–Requires that the Multilayer Switching (MLS) flow mode operate in full-flow mode or in interface full-flow mode. IOS SLB automatically sets the flow mode for its own use. 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 Supervisor Engine 2, "sandwich" configurations that require firewall load balancing are not supported, because such configurations require VRF, and VRF is not supported for Supervisor Engine 2.
Access Service Network (ASN) R6 Load Balancing
•Operates in either dispatched or directed server NAT mode only. In directed mode, IOS SLB changes the destination IP address of the Mobile Station (MS) Pre-Attachment request to that of the selected ASN gateway real server.
•Requires DFP
•Does not support the following features:
–Client NAT
–Stateful redundancy
–Sticky connections
–Weighted least connections algorithm (for MS Pre-Attachment requests)
•When the base station is configured to send MS Pre-Attachment ACK packets directly to an ASN gateway, bypassing IOS SLB, you must ensure that the session can time out without failing the real server. To do so, configure the no faildetect inband command real server configuration mode.
Information About IOS SLB
To configure IOS SLB, you should understand the following concepts:
•Benefits of IOS SLB
•General IOS SLB Features—This section describes the general features provided by IOS SLB.
•Exchange Director Features—This section describes the specific features provided by the Exchange Director for mobile Service Exchange Framework (mSEF).
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.
Benefits of IOS SLB
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.
General 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
•Connection Rate Limiting
•Content Flow Monitor Support
•Delayed Removal of TCP Connection Context
•Firewall Load Balancing
•GTP IMSI Sticky Database
•Home Agent Director
•Interface Awareness
•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
•Route Map
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.
For each algorithm, connections in closing state continue to be counted against the number of connections assigned to a real server. This impacts the least connections algorithm more than the other algorithms, because the least connections algorithm is influenced by the number of connections impacts the least connections more. IOS SLB adjusts the number of connections per real server, and the algorithm metrics, each time a connection is assigned.
Weighted Round Robin
The weighted round robin algorithm specifies that the real server used for a new connection to the virtual server is chosen from the server farm in a circular fashion. Each real server is assigned a weight, n, that represents its capacity to handle connections, as compared to the other real servers associated with the virtual server. That is, new connections are assigned to a given real server n times before the next real server in the server farm is chosen.
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. The first three connections to the virtual server are assigned to ServerA, the fourth connection to ServerB, and the fifth and sixth connections to ServerC.
Note 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.
RADIUS load balancing requires the weighted round robin algorithm.
RADIUS load balancing accelerated data plane forwarding does not support the weighted round robin algorithm.
Weighted Least Connections
The weighted least connections algorithm specifies that the next real server chosen from a server farm for a new connection to the virtual server is the server with the fewest active connections. Each real server is assigned a weight for this algorithm, also. When weights are assigned, the server with the fewest connections is based on the number of active connections on each server, and on the relative capacity of each server. The capacity of a given real server is calculated as the assigned weight of that server divided by the sum of the assigned weights of all of the real servers associated with that virtual server, or n1/(n1+n2+n3...).
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. ServerA would have a calculated capacity of 3/(3+1+2), or half of all active connections on the virtual server, ServerB one-sixth of all active connections, and ServerC one-third of all active connections. At any point in time, the next connection to the virtual server would be assigned to the real server whose number of active connections is farthest below its calculated capacity.
Note 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.
Access Service Network (ASN) R6 load balancing (for MS Pre-Attachment requests), the Home Agent Director, RADIUS load balancing, and RADIUS load balancing accelerated data plane forwarding do not support the weighted least connections algorithm.
Route Map
The route map algorithm is valid only with IOS SLB RADIUS load balancing accelerated data plane forwarding, also known as Turbo RADIUS load balancing. Turbo RADIUS load balancing is a high-performance solution that uses policy-based routing (PBR) route maps to handle subscriber data-plane traffic in a Cisco Content Services Gateway (CSG) environment. When Turbo RADIUS load balancing receives a RADIUS payload, it inspects the payload, extracts the framed-IP attribute, applies a route map to the IP address, and then determines which CSG is to handle the subscriber.
For more information about policy-based routing, including how it works, when to use it, how to configure it, and how to enable it, see the "Policy-Based Routing" and "Configuring Policy-Based Routing" sections of the Cisco IOS IP Routing Configuration Guide.
Note RADIUS load balancing accelerated data plane forwarding requires the route map 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.
Connection Rate Limiting
IOS SLB enables you to specify the maximum connection rate allowed for a real server in a server farm. For more information, see the description of the rate command in real server configuration mode.
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.
•Source-IP, destination-IP, and source-destination-IP sticky connections are supported.
•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.
GTP IMSI Sticky Database
IOS SLB can select a gateway general packet radio service (GPRS) support node (GGSN) for a given International Mobile Subscriber ID (IMSI), and forward all subsequent Packet Data Protocol (PDP) create requests from the same IMSI to the selected GGSN.
To enable this feature, IOS SLB uses a GPRS Tunneling Protocol (GTP) IMSI sticky database, which maps each IMSI to its corresponding real server, in addition to its session database.
IOS SLB creates a sticky database object when it processes the first GTP PDP create request for a given IMSI. IOS SLB removes the sticky object when it receives a notification to do so from the real server, or as a result of inactivity. When the last PDP belonging to an IMSI is deleted on the GGSN, the GGSN notifies IOS SLB to remove the sticky object.
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.
•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.
•Requires DFP in order to allocate RRQs based on capacity.
For more information about Mobile IP, home agents, and related topics, refer to the Cisco IOS IP Mobility Configuration Guide.
Interface Awareness
Some environments require IOS SLB on both sides of a farm of CSGs, SSGs, or firewalls. For example, you might want IOS SLB to perform RADIUS load balancing on one side of a farm and firewall load balancing on the other, or firewall load balancing on both sides of a firewall farm.
Such "sandwich" environments require IOS SLB to take into account the input interface when mapping packets to virtual servers, firewall farms, connections, and sessions. In IOS SLB, this function is called interface awareness. When interface awareness is configured, IOS SLB processes only traffic arriving on configured access interfaces. (An access interface is any Layer 3 interface.)
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 Virtual Interfaces" chapter of the Cisco IOS Interface Configuration Guide for more information about configuring the loopback address.
Note Some UDP applications cannot respond from the loopback interface. If that situation occurs, you must use directed mode.
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.
•IOS SLB supports source-IP sticky connections.
•Firewall load balancing supports source-IP, destination-IP, and source-destination-IP sticky connections.
•RADIUS load balancing supports calling-station-IP, framed-IP, and username sticky connections.
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.
Access Service Network (ASN) R6 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 IP 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
•GGSN-IOS SLB Messaging
•INOP_REAL State for Virtual Servers
•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(18)SXD.
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.
See the following sections for more information:
•DFP and GPRS Load Balancing
•DFP and the Home Agent Director
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.
DFP and the Home Agent Director
For the Home Agent Director, you can define IOS SLB as a DFP manager and define a DFP agent on each home agent in the server farm, and the DFP agent can report the weights of the home agents. The DFP agents calculate the weight of each home agent based on CPU utilization, processor memory, and the maximum number of bindings that can be activated for each home agent:
(maximum-number-of-bindings - current-number-of-bindings)/maximum-number-of-bindings * (cpu-utilization + memory-utilization)/32 * maximum-DFP-weight = reported-weight
The maximum-number-of-bindings is 235,000. The maximum-DFP-weight is 24.
GGSN-IOS SLB Messaging
This feature enables a GGSN to notify IOS SLB when certain conditions occur. The notifications enable IOS SLB to make intelligent decisions, which in turn improves GPRS load balancing and failure detection.
The notifications sent by the GGSN use GTP with message types from the unused space (reserved for future use) and the following information elements (IEs):
•Notification type, which indicates the notification condition. For example, this could be a notification to IOS SLB to reassign the session to an alternate GGSN, when the current GGSN fails on Call Admission Control (CAC).
•Identifier of the relevant session (session key).
•Other IEs specific to the notification type. For example, for a notification to reassign, GGSN includes the create response, which it would otherwise have sent to the SGSN. This enables IOS SLB to relay this response back to SGSN when the maximum number of reassignments due to notification reach the configured limit.
GGSN-IOS SLB messaging is supported in both dispatched mode and directed modes.
INOP_REAL State for Virtual Servers
You can configure a virtual server such that, if all of the real servers that are associated with the virtual server are inactive, the following actions occur:
•The virtual server is placed in the INOP_REAL state.
•An SNMP trap is generated for the virtual server's state transition.
•The virtual server stops answering ICMP requests.
For more information, see the description of the inservice (server farm virtual server) command in SLB server farm virtual server configuration mode.
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 IP SLAs Command Reference 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.
Note If a probe is configured for stateful backup and a failover occurs, the change in status (from backup to active) is reflected accurately in the probe in the new active IOS SLB device. However, the probe in the new backup IOS SLB device (which had been the active device before the failover) still shows its status as active.
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 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 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:
•Access Service Network (ASN) R6
•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)
•Internet Key Exchange (IKE, was ISAKMP)
•IP in IP Encapsulation (IPinIP)
•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.
Access Service Network (ASN) R6 load balancing and the Home Agent Director do not support stateful backup.
Note If a probe is configured for stateful backup and a failover occurs, the change in status (from backup to active) is reflected accurately in the probe in the new active IOS SLB device. However, the probe in the new backup IOS SLB device (which had been the active device before the failover) still shows its status as active.
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 supports active standby. That is, you can 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 mobile Service Exchange Framework (mSEF) for Catalyst 6500 family switches and Cisco 7600 series routers. The Exchange Director provides the following features:
•ASN R6 Load Balancing
•GPRS Load Balancing
•GPRS Load Balancing without GTP Cause Code Inspection
•GPRS Load Balancing with GTP Cause Code Inspection
•Home Agent Director
•KeepAlive Application Protocol (KAL-AP) Agent Support
•RADIUS Load Balancing
•RADIUS Load Balancing Accelerated Data Plane Forwarding
•WAP Load Balancing
•Stateful Backup of Redundant Route Processors
•Flow Persistence
ASN R6 Load Balancing
IOS SLB can provide load balancing across a set of Access Service Network (ASN) gateways. The gateway server farm appears to the base station as a single ASN gateway.
When a Mobile Subscriber Station (MSS) wants to enter the network, the base station sends a Mobile Station (MS) Pre-Attachment request to the virtual IP address of the IOS SLB. IOS SLB selects an ASN gateway and forwards the request to that gateway. The gateway responds directly to the base station with an MS Pre-Attachment response. If configured to do so, the base station then returns an MS Pre-Attachment ACK to IOS SLB, which forwards the ACK to the selected gateway. Thereafter, all subsequent transactions flow between the base station and the gateway.
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.
•GPRS load balancing maps enable IOS SLB to categorize and route user traffic based on access point names (APNs).
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.
•Supports stateful backup only if sticky connections are enabled. 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.
•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.
•Requires DFP in order to allocate RRQs based on capacity.
For more information about Mobile IP, home agents, and related topics, refer to the Cisco IOS IP Configuration Guide, Release 12.2.
KeepAlive Application Protocol (KAL-AP) Agent Support
KAL-AP agent support enables IOS SLB to perform load balancing in a global server load balancing (GSLB) environment. KAL-AP provides load information along with its keepalive response message to the KAL-AP manager or GSLB device, such as the Global Site Selector (GSS), and helps the GSLB device load-balance client requests to the least-loaded IOS SLB devices.
When configuring KAL-AP agent support for IOS SLB, keep the following considerations in mind:
•KAL-AP agent support automatically detects the Virtual Private Network (VPN) routing and forwarding (VRF) ID of an incoming request packet, and uses the same VRF ID when sending a response.
•A client that uses DNS caching might contact IOS SLB directly, instead of sending requests through the GSS. Therefore, configure the DNS setting in the client to avoid such a situation.
KAL-AP calculates the load value in one of two ways: relatively or absolutely. (IOS SLB CPU/memory load might affect the final KAL-AP load value.)
Relative KAL-AP Load Value
If the farm-weight command is not configured in server farm configuration mode, or if DFP is not enabled for the IOS SLB, KAL-AP calculates a relative load value, using the following formula:
KAL-AP Load = 256 - (number-of-active-real-servers * 256 / number-of-inservice-real-servers)
For example, if a site is provisioned with two real servers, and both real servers are inservice but only one is currently active, the resulting KAL-AP load value for that site is:
KAL-AP Load = 256 - (1 * 256 / 2) = 256 - 128 = 128
Absolute KAL-AP Load Value
If the farm-weight command is configured in server farm configuration mode, and DFP is enabled for the IOS SLB, KAL-AP calculates an absolute load value, using the following formula:
KAL-AP Load = 256 - (sum-of-max-dfp-weights-of-real-servers * 256 / farm-weight)
Note The maximum DFP weight for a real server is configured using the gprs dfp max-weight command in global configuration mode. However, the actual maximum DFP weight reported to KAL-AP is proportional to the load on the GGSN. For example, if a GGSN is configured with a maximum DFP weight of 100, but the GGSN is 50% loaded, it reports a maximum DFP weight of 50 to KAL-AP.
If the DFP connection to the real server is down, KAL-AP uses the setting of the weight command in SLB real server configuration mode. If no weight command is configured for the real server, KAL-AP uses the default weight of 8.
For example, consider a site with the following settings:
•A server farm configured with a farm weight of 200.
•GGSN-1 configured with a maximum DFP weight of 100, 0% loaded (so it reports a DFP weight of 100).
•GGSN-2 configured with a maximum DFP weight of 100, 50% loaded (so it reports a DFP weight of only 50).
The resulting KAL-AP load value for that site is:
KAL-AP Load = 256 - [(100 + 50) * 256 / 200] = 256 - 192 = 64
For best results, configure a farm-weight that is equal to the sum of the maximum DFP weights for the real servers in the server farm. For example, if there are three real servers in a server farm, configured with maximum DFP weights of 100, 50, and 50, then configure a farm-weight of 200 (that is, 100 + 50 + 50). If a real server is added to or removed from the server farm, you must adjust the farm-weight accordingly.
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.
•Supports multiple WAP gateway server farms behind a RADIUS load balancing virtual server, using RADIUS calling station IDs and usernames to select specific server farms. This enhancement enables RADIUS load balancing on both the control plane and the data plane. RADIUS load balancing on the control plane enables RADIUS messages to be load-balanced to AAA servers for subscriber authorization, authentication and accounting. RADIUS load balancing on the data plane enables data flows for a given subscriber to maintain a consistent network path to the destination network device. In addition, the RADIUS virtual server can acknowledge RADIUS accounting messages and build or delete sticky objects, rather than having to forward the messages to the specified server.
•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.
•RADIUS load balancing maps enable IOS SLB to categorize and route user traffic based on RADIUS calling station IDs and user names. RADIUS load balancing maps is mutually exclusive with Turbo RADIUS load balancing and RADIUS load balancing accounting local acknowledgement.
•RADIUS load balancing accounting local acknowledgement enables IOS SLB to respond to RADIUS accounting packets with an ACK response while maintaining sticky objects for those sessions. RADIUS load balancing accounting local acknowledgement is mutually exclusive with RADIUS load balancing maps and Turbo RADIUS load balancing.
•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.
•The IOS SLB RADIUS International Mobile Subscriber ID (IMSI) sticky database maps the IMSI address for each user to the corresponding gateway. This enables IOS SLB to forward all subsequent flows for the same user to the same gateway.
RADIUS Load Balancing Accelerated Data Plane Forwarding
RADIUS load balancing accelerated data plane forwarding, also known as Turbo RADIUS load balancing, is a high-performance solution that uses basic policy-based routing (PBR) route maps to handle subscriber data-plane traffic in a CSG environment.
When Turbo RADIUS load balancing receives a RADIUS payload, it inspects the payload, extracts the framed-IP attribute, applies a route map to the IP address, and then determines which CSG is to handle the subscriber.
If vendor-specific attribute (VSA) correlation is configured, and if the Cisco VSA is buffered, then the Cisco VSA is injected into the RADIUS Accounting-Start packet.
Turbo RADIUS load balancing does not require VSA correlation, but it does require a server farm configured with predictor route-map on the accounting virtual server.
Note When you specify the predictor route-map command in SLB server farm configuration mode, no further commands in SLB server farm configuration mode or real server configuration mode are allowed.
For more information about policy-based routing, including how it works, when to use it, how to configure it, and how to enable it, see the "Policy-Based Routing" and "Configuring Policy-Based Routing" sections of the Cisco IOS IP Routing Configuration Guide.
In a mobile Service Exchange Framework (mSEF) environment, Turbo RADIUS load balancing does not require firewall load balancing on the network side of the CSG cluster. (Standard RADIUS load balancing does require firewall load balancing on the network side of the cluster.)
Turbo RADIUS load balancing is mutually exclusive with RADIUS load balancing maps and RADIUS load balancing accounting local acknowledgement.
Turbo RADIUS load balancing is mutually exclusive with Virtual Private Network (VPN) routing and forwarding (VRF).
Turbo RADIUS load balancing supports simple IP access control lists (ACLs) and match and set next-hop pairs.
Turbo RADIUS load balancing is mutually exclusive with the optional ACL logging facility. In order to use Turbo RADIUS load balancing, you must first disable the logging facility. For more information, see the description of the access-list (IP standard) command in the Cisco IOS Security Command Reference, Cisco IOS 12.4.
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 mSEF for Catalyst 6500 family switches and Cisco 7600 series 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.
How to Configure IOS SLB
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 for IOS SLB" section.
For a complete description of the IOS SLB commands in this section, refer to the "Server Load Balancing Commands" chapter of the Cisco IOS IP Application Services Command Reference. 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 a Probe (Optional)
•Configuring DFP (Optional)
•GPRS Load Balancing Configuration Task List (Optional)
•GGSN-IOS SLB Messaging Task List (Optional)
•Configuring GPRS Load Balancing Maps (Optional)
•Configuring KeepAlive Application Protocol (KAL-AP) Agent Support (Optional)
•RADIUS Load Balancing Configuration Task List (Optional)
•Exchange Director for mSEF Configuration Task List (Optional)
•VPN Server Load Balancing Configuration Task List (Optional)
•ASN R6 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 a Wildcard Search (Optional)
•Purging and Reassigning Connections (Optional)
•Disabling Automatic Server Failure Detection (Optional)
•Monitoring and Maintaining IOS SLB (Optional)
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 a Real Server (Required)
•Configuring a Virtual Server (Required)
•Verifying a Server Farm (Optional)
•Verifying a Virtual Server (Optional)
•Verifying the Clients (Optional)
•Verifying IOS SLB Connectivity (Optional)
Configuring a Server Farm and a Real Server
Perform this task to configure a server farm and a real server.
Note You cannot configure IOS SLB from different user sessions at the same time.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb serverfarm server-farm
4. bindid [bind-id]
5. nat {client pool | server}
6. predictor [roundrobin | leastconns | route-map mapname]
7. probe probe
8. real ip-address [port]
9. faildetect numconns number-of-conns [numclients number-of-clients]
10. maxclients number-of-conns
11. maxconns number-of-conns [sticky-override]
12. reassign threshold
13. retry retry-value
14. weight setting
15. inservice
DETAILED STEPS
| |
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb serverfarm server-farm
Example:
Router(config)# ip slb serverfarm PUBLIC
|
Adds a server farm definition to the IOS Server Load Balancing (IOS SLB) configuration and enters server farm configuration mode.
|
Step 4
|
bindid [bind-id]
Example:
Router(config-slb-sfarm)# bindid 309
|
(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 5
|
nat {client pool | server}
Example:
Router(config-slb-sfarm)# nat server
|
(Optional) Configures Network Address Translation (NAT) client translation mode or NAT server address translation mode on the server farm.
|
Step 6
|
predictor [roundrobin | leastconns | route-map
mapname]
Example:
Router(config-slb-sfarm)# predictor 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).
When you specify the predictor route-map command in SLB server farm configuration mode, no further commands in SLB server farm configuration mode or real server configuration mode are allowed.
See the following sections for more details:
•Weighted Round Robin
•Weighted Least Connections
•Route Map
|
Step 7
|
probe probe
Example:
Router(config-slb-sfarm)# probe PROBE1
|
(Optional) Associates a probe with the real server.
|
Step 8
|
real ip-address [port]
Example:
Router(config-slb-sfarm)# real 10.1.1.1
|
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 9
|
faildetect numconns number-of-conns
[numclients number-of-clients]
Example:
Router(config-slb-real)# faildetect numconns 10
numclients 3
|
(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 10
|
maxclients number-of-conns
Example:
Router(config-slb-real)# maxclients 10
|
(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 11
|
maxconns number-of-conns [sticky-override]
Example:
Router(config-slb-real)# maxconns 1000
|
(Optional) Specifies the maximum number of active connections allowed on the real server at one time.
|
Step 12
|
Example:
Router(config-slb-real)# reassign 2
|
(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 13
|
retry retry-value
Example:
Router(config-slb-real)# retry 120
|
(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 14
|
Example:
Router(config-slb-real)# weight 24
|
(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 15
|
inservice
Example:
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 a Wildcard Search" section for more details.
Configuring a Virtual Server
Perform this task to configure a virtual server.
IOS SLB supports up to 500 virtual servers.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb vserver virtual-server
4. virtual ip-address [netmask [group]] {esp | gre | protocol}
or
virtual ip-address [netmask [group]] {tcp | udp} [port | any] [service service]
5. serverfarm primary-farm [backup backup-farm [sticky]] [map map-id priority priority]
6. access interface [route framed-ip]
7. advertise [active]
8. client {ip-address netmask [exclude] | gtp carrier-code [code]}
9. delay {duration | radius framed-ip duration}
10. gtp notification cac [reassign-count]
11. hand-off radius duration
12. idle [asn r6 request | gtp request | ipmobile request | radius {request | framed-ip}] duration
13. purge radius framed-ip acct on-off
14. purge radius framed-ip acct stop {attribute-number | {26 | vsa} {vendor-ID | 3gpp | 3gpp2} sub-attribute-number}
15. radius acct local-ack key [encrypt] secret-string
16. radius inject auth group-number {calling-station-id | username}
17. radius inject auth timer seconds
18. radius inject auth vsa vendor-id
19. replicate casa listen-ip remote-ip port [interval] [password [encrypt] secret-string timeout]
20. replicate interval interval
21. replicate slave
22. sticky {duration [group group-id] [netmask netmask] | gtp imsi [group group-id] | radius calling-station-id | radius framed-ip [group group-id] | radius username [msid-cisco] [group group-id]}
23. synguard syn-count interval
24. inservice [standby group-name] [active]
DETAILED STEPS
| |
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb vserver virtual-server
Example:
Router(config)# ip slb vserver
PUBLIC_HTTP
|
Identifies a virtual server and enters virtual server configuration mode.
|
Step 4
|
virtual ip-address [netmask [group]]
{esp | gre | protocol}
or
virtual ip-address [netmask [group]]
{tcp | udp} [port | any]
[service service]
Example:
Router(config-slb-vserver)# virtual
10.0.0.1 tcp www
|
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 RADIUS load balancing, specify the service radius keyword option.
Note For ASN R6 load balancing, specify the service asn r6 keyword option.
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 5
|
serverfarm primary-farm
[backup backup-farm [sticky]]
[map map-id priority priority]
Example:
Router(config-slb-vserver)# serverfarm
SF1 backup SF2 map 1 priority 1
|
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 RADIUS load balancing and the Home Agent Director do not support the sticky keyword.
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.
You can associate more than one server farm with a given RADIUS virtual server by configuring more than one serverfarm command, each with a unique map ID and a unique priority. (That is, each map ID and each map priority must be unique across all server farms associated with the virtual server.)
|
Step 6
|
access interface [route framed-ip]
Example:
Router(config-slb-vserver)# access Vlan20
route framed-ip
|
(Optional) Enables framed-IP routing to inspect the ingress interface.
|
Step 7
|
Example:
Router(config-slb-vserver)# advertise
|
(Optional) Controls the installation of a static route to the Null0 interface for a virtual server address.
|
Step 8
|
client {ip-address netmask [exclude] |
gtp carrier-code [code]}
Example:
Router(config-slb-vserver)# client
10.4.4.0 255.255.255.0
|
(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 9
|
delay {duration |
radius framed-ip duration}
Example:
Router(config-slb-vserver)# delay 30
|
(Optional) Specifies the time IOS Server Load Balancing (IOS SLB) maintains TCP connection context after a connection has terminated.
|
Step 10
|
gtp notification cac [reassign-count]
Example:
Router(config-slb-vserver)# gtp
notification cac 5
|
(Optional) Limits the number of times IOS SLB can reassign a session to a new real server for GGSN-IOS SLB messaging.
|
Step 11
|
hand-off radius duration
Example:
Router(config-slb-vserver)# hand-off
radius 30
|
(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 12
|
idle [asn r6 request | gtp request |
ipmobile request |
radius {request | framed-ip}] duration
Example:
Router(config-slb-vserver)# idle 120
|
(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 13
|
purge radius framed-ip acct on-off
Example:
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 14
|
purge radius framed-ip acct stop
{attribute-number | {26 | vsa}
{vendor-ID | 3gpp | 3gpp2}
sub-attribute-number}
Example:
Router(config-slb-vserver)# purge radius
framed-ip acct stop 44
|
(Optional) Enables IOS SLB to purge entries in the IOS SLB RADIUS framed-ip sticky database upon receipt of an Accounting-Stop message.
|
Step 15
|
radius acct local-ack key [encrypt]
secret-string
Example:
Router(config-slb-vserver)# radius acct
local-ack key SECRET_PASSWORD
|
(Optional) Enables a RADIUS virtual server to acknowledge RADIUS accounting messages.
|
Step 16
|
radius inject auth group-number
{calling-station-id | username}
Example:
Router(config-slb-vserver)# radius inject
auth 1 calling-station-id
|
(Optional) Configures a vendor-specific attribute (VSA) correlation group for an IOS SLB RADIUS load balancing accelerated data plane forwarding authentication virtual server, and specifies whether IOS SLB is to create VSA correlation entries based on RADIUS calling station IDs or RADIUS usernames.
|
Step 17
|
radius inject auth timer seconds
Example:
Router(config-slb-vserver)# radius inject
auth timer 45
|
(Optional) Configures a timer for vendor-specific attribute (VSA) correlation for an IOS SLB RADIUS load balancing accelerated data plane forwarding authentication virtual server.
|
Step 18
|
radius inject auth vsa vendor-id
Example:
Router(config-slb-vserver)# radius inject
auth vsa vendor1
|
(Optional) Buffers vendor-specific attributes (VSAs) for VSA correlation for an IOS SLB RADIUS load balancing accelerated data plane forwarding authentication virtual server.
|
Step 19
|
replicate casa listen-ip remote-ip port
[interval] [password [encrypt]
secret-string timeout]
Example:
Router(config-slb-vserver)# replicate
casa 10.10.10.11 10.10.11.12 4231
|
(Optional) Configures a stateful backup of IOS Server Load Balancing (IOS SLB) decision tables to a backup switch.
Note The Home Agent Director does not support this command.
If you specify the service gtp keyword on the virtual command, and you do not specify the gtp imsi keyword on the sticky command, the replicate casa command is not supported (because sessions are not persistent, and there is nothing to replicate).
|
Step 20
|
replicate interval interval
Example:
Router(config-slb-vserver)# replicate
interval 20
|
(Optional) Sets the replication delivery interval for an IOS Server Load Balancing (IOS SLB) virtual server.
Note The Home Agent Director does not support this command.
If you specify the service gtp keyword on the virtual command, and you do not specify the gtp imsi keyword on the sticky command, the replicate casa command is not supported (because sessions are not persistent, and there is nothing to replicate).
|
Step 21
|
replicate slave
Example:
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 The Home Agent Director does not support this command.
If you specify the service gtp keyword on the virtual command, and you do not specify the gtp imsi keyword on the sticky command, the replicate casa command is not supported (because sessions are not persistent, and there is nothing to replicate).
If you are using a single Supervisor with replicate slave configured, you might receive out-of-sync messages on the Supervisor.
|
Step 22
|
sticky {duration [group group-id]
[netmask netmask] |
gtp imsi [group group-id] |
radius calling-station-id |
radius framed-ip [group group-id] |
radius username [msid-cisco]
[group group-id]}
Example:
Router(config-slb-vserver)# sticky 60
group 10
|
(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 23
|
synguard syn-count interval
Example:
Router(config-slb-vserver)# synguard 50
|
(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 24
|
inservice [standby group-name] [active]
Example:
Router(config-slb-vserver)# inservice
|
Enables the virtual server for use by IOS Server Load Balancing (IOS SLB).
|
Verifying a Virtual Server
Perform the following task to verify a virtual server.
SUMMARY STEPS
1. show ip slb vservers
DETAILED STEPS
The following show ip slb vservers command verifies the configuration of the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router# show ip slb vservers
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
Verifying a Server Farm
Perform the following task to verify a server farm.
SUMMARY STEPS
1. show ip slb reals
2. show ip slb serverfarm
DETAILED STEPS
The following show ip slb reals command displays the status of server farms PUBLIC and RESTRICTED, the associated real servers, and their status:
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
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
Verifying the Clients
Perform the following task to verify the clients.
SUMMARY STEPS
1. show ip slb conns
DETAILED STEPS
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
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
Verifying IOS SLB Connectivity
Perform the following task to verify IOS SLB connectivity.
SUMMARY STEPS
1. show ip slb stats
DETAILED STEPS
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
Connections Established: 1
Connections Reassigned: 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 IOS SLB" section for additional commands used to verify IOS SLB networks and connections.
Configuring Firewall Load Balancing
Perform the following task 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 a Ping Probe" section for more details. If a firewall does not allow ping probes to be forwarded, use HTTP probes instead. See the "Configuring an HTTP Probe" 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 a Wildcard Search" section for more details.
This section describes the following IOS SLB firewall load-balancing configuration tasks. Required and optional tasks are indicated.
•Configuring a Firewall Farm (Required)
•Verifying a Firewall Farm (Optional)
•Verifying Firewall Connectivity (Optional)
Configuring a Firewall Farm
Perform the following task to configure a firewall farm.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb firewallfarm firewall-farm
4. real ip-address
5. probe probe
6. weight service
7. inservice
8. access [source source-ip netmask] [destination destination-ip netmask]
9. predictor hash address [port]
10. replicate casa listen-ip remote-ip port [interval] [password [[encrypt] secret-string [timeout]]
11. replicate interval interval
12. replicate slave
13. protocol tcp
14. delay duration
15. idle duration
16. maxconns maximum-number
17. sticky duration [netmask netmask] [source | destination]
18. protocol datagram
19. idle duration
20. maxconns maximum-number
21. sticky duration [netmask netmask] [source | destination]
22. inservice
DETAILED STEPS
| |
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb firewallfarm firewall-farm
Example:
Router(config)# ip slb firewallfarm FIRE1
|
Adds a firewall farm definition to the IOS Server Load Balancing (IOS SLB) configuration and enters firewall farm configuration mode.
|
Step 4
|
real ip-address
Example:
Router(config-slb-fw)# real 10.1.1.1
|
Identifies a firewall by IP address as a member of a firewall farm and enters real server configuration mode.
|
Step 5
|
probe probe
Example:
Router(config-slb-fw-real)# probe FireProbe
|
Associates a probe with the firewall.
|
Step 6
|
weight setting
Example:
Router(config-slb-fw-real)# weight 24
|
(Optional) Specifies the firewall's workload capacity relative to other firewalls in the firewall farm.
|
Step 7
|
inservice
Example:
Router(config-slb-fw-real)# inservice
|
Enables the firewall for use by the firewall farm and by IOS Server Load Balancing (IOS SLB).
|
Step 8
|
access [source source-ip netmask]
[destination destination-ip netmask]
Example:
Router(config-slb-fw)# access destination 10.1.6.0
255.255.255.0
|
(Optional) Routes specific flows to a firewall farm.
|
Step 9
|
predictor hash address [port]
Example:
Router(config-slb-fw)# predictor hash address
|
(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 10
|
replicate casa listen-ip remote-ip port [interval]
[password [[encrypt] secret-string [timeout]]
Example:
Router(config-slb-fw)# replicate casa 10.10.10.11
10.10.11.12 4231
|
(Optional) Configures a stateful backup of IOS Server Load Balancing (IOS SLB) firewall load balancing decision tables to a backup switch.
|
Step 11
|
replicate interval interval
Example:
Router(config-slb-fw)# replicate interval 20
|
(Optional) Sets the replication delivery interval for an IOS Server Load Balancing (IOS SLB) firewall farm.
Note The Home Agent Director does not support this command.
If you specify the service gtp keyword on the virtual command, and you do not specify the gtp imsi keyword on the sticky command, the replicate casa command is not supported (because sessions are not persistent, and there is nothing to replicate).
|
Step 12
|
replicate slave
Example:
Router(config-slb-fw)# replicate slave
|
(Optional) Enables stateful backup of redundant route processors for an IOS Server Load Balancing (IOS SLB) firewall farm.
Note The Home Agent Director does not support this command.
If you specify the service gtp keyword on the virtual command, and you do not specify the gtp imsi keyword on the sticky command, the replicate casa command is not supported (because sessions are not persistent, and there is nothing to replicate).
If you are using a single Supervisor with replicate slave configured, you might receive out-of-sync messages on the Supervisor.
|
Step 13
|
protocol tcp
Example:
Router(config-slb-fw)# protocol tcp
|
(Optional) Enters firewall farm TCP protocol configuration mode.
|
Step 14
|
delay duration
Example:
Router(config-slb-fw-tcp)# delay 30
|
(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 15
|
idle duration
Example:
Router(config-slb-fw-tcp)# idle 120
|
(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 16
|
maxconns maximum-number
Example:
Router(config-slb-fw-tcp)# maxconns 1000
|
(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 17
|
sticky duration [netmask netmask] [source |
destination]
Example:
Router(config-slb-fw-tcp)# sticky 60
|
(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 18
|
protocol datagram
Example:
Router(config-slb-fw)# protocol datagram
|
(Optional) Enters firewall farm datagram protocol configuration mode.
|
Step 19
|
idle duration
Example:
Router(config-slb-fw-udp)# idle 120
|
(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 20
|
maxconns maximum-number
Example:
Router(config-slb-fw-udp)# maxconns 1000
|
(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 21
|
sticky duration [netmask netmask] [source |
destination]
Example:
Router(config-slb-fw-udp)# sticky 60
|
(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 22
|
inservice
Example:
Router(config-slb-fw)# inservice
|
Enables the firewall farm for use by IOS Server Load Balancing (IOS SLB).
|
Verifying a Firewall Farm
Perform the following task to verify a firewall farm.
SUMMARY STEPS
1. show ip slb real
2. show ip slb firewallfarm
DETAILED STEPS
The following show ip slb reals command displays the status of firewall farm FIRE1, the associated real servers, and their status:
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
------------------------------------------------
Verifying Firewall Connectivity
Perform the following task to verify firewall connectivity.
SUMMARY STEPS
1. Ping the external real servers.
2. Ping the internal real servers.
3. show ip slb stats
4. show ip slb real detail
5. show ip slb conns
DETAILED STEPS
To verify that IOS SLB firewall load balancing has been configured and is operating correctly, perform the following steps:
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
Connections Created: 1911871
Connections Established: 1967754
Connections Destroyed: 1313251
Connections Reassigned: 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
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
See the "Monitoring and Maintaining IOS SLB" section for additional commands used to verify IOS SLB networks and connections.
Configuring a Probe
Perform the following task to configure a probe.
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 a Custom UDP Probe (Required)
•Configuring a DNS Probe (Required)
•Configuring an HTTP Probe (Required)
•Configuring a Ping Probe (Required)
•Configuring a TCP Probe (Required)
•Configuring a WSP Probe (Required)
•Associating a Probe (Required)
•Verifying a Probe (Optional)
Configuring a Custom UDP Probe
Perform the following task to configure a custom UDP probe.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb probe probe custom udp
4. address [ip-address] [routed]
5. faildetect number-of-probes
6. interval seconds
7. port port
8. request data {start-byte | continue} hex-data-string
9. response clause-number data start-byte hex-data-string
10. timeout seconds
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb probe probe custom udp
Example:
Router(config)# ip slb probe PROBE6 custom udp
|
Configures the IOS Server Load Balancing (IOS SLB) probe name and enters custom User Datagram Protocol (UDP) probe configuration mode.
|
Step 4
|
address [ip-address] [routed]
Example:
Router(config-slb-probe)# address 10.1.1.1
|
(Optional) Configures an IP address to which to send the custom User Datagram Protocol (UDP) probe.
|
Step 5
|
faildetect number-of-probes
Example:
Router(config-slb-probe)# faildetect 16
|
(Optional) Specifies the number of consecutive unacknowledged custom User Datagram Protocol (UDP) probes that constitute failure of the real server.
|
Step 6
|
interval seconds
Example:
Router(config-slb-probe)# interval 11
|
(Optional) Configures the custom User Datagram Protocol (UDP) probe transmit timers.
|
Step 7
|
port port
Example:
Router(config-slb-probe)# port 8
|
Configures the port to which the custom User Datagram Protocol (UDP) probe is to connect.
|
Step 8
|
request data {start-byte | continue} hex-data-string
Example:
Router(config-slb-probe)# request data 0 05 04 00 77
18 2A D6 CD 0A AD 53 4D F1 29 29 CF C1 96 59 CB
|
Defines the payload of the User Datagram Protocol (UDP) request packet to be sent by a custom UDP probe.
|
Step 9
|
response clause-number data start-byte
hex-data-string
Example:
Router(config-slb-probe)# response 2 data 44 DD DD
|
Defines the data string to match against custom User Datagram Protocol (UDP) probe response packets.
|
Step 10
|
timeout seconds
Example:
Router(config-slb-probe)# timeout 20
|
(Optional) Sets a timeout for custom User Datagram Protocol (UDP) probes.
|
Configuring a DNS Probe
Perform the following task to configure a DNS probe.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb probe probe dns
4. address [ip-address [routed]]
5. faildetect number-of-probes
6. interval seconds
7. lookup ip-address
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb probe probe dns
Example:
Router(config)# ip slb probe PROBE4 dns
|
Configures the IOS Server Load Balancing (IOS SLB) probe name and enters Domain Name System (DNS) probe configuration mode.
|
Step 4
|
address [ip-address [routed]]
Example:
Router(config-slb-probe)# address 10.1.10.1
|
(Optional) Configures an IP address to which to send the Domain Name System (DNS) probe.
|
Step 5
|
faildetect number-of-probes
Example:
Router(config-slb-probe)# faildetect 16
|
(Optional) Specifies the number of consecutive unacknowledged Domain Name System (DNS) probes that constitute failure of the real server or firewall.
|
Step 6
|
interval seconds
Example:
Router(config-slb-probe)# interval 11
|
(Optional) Configures the Domain Name System (DNS) probe transmit timers.
|
Step 7
|
lookup ip-address
Example:
Router(config-slb-probe)# lookup 10.1.10.1
|
(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 an HTTP Probe
Perform the following task to configure an HTTP probe.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb probe probe http
4. address [ip-address [routed]]
5. credentials {username [password]}
6. expect [status status-code] [regex expression]
7. header field-name [field-value]
8. interval seconds
9. port port
10. request [method {get | post | head | name name}] [url path]
11. Configure a route to the virtual server.
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb probe probe http
Example:
Router(config)# ip slb probe PROBE2 http
|
Configures the IOS Server Load Balancing (IOS SLB) probe name and enters HTTP probe configuration mode.
|
Step 4
|
address [ip-address [routed]]
Example:
Router(config-slb-probe)# address 10.1.10.1
|
(Optional) Configures an IP address to which to send the HTTP probe.
|
Step 5
|
credentials {username [password]}
Example:
Router(config-slb-probe)# credentials
Username1 password
|
(Optional) Configures header values for the HTTP probe.
|
Step 6
|
expect [status status-code] [regex expression]
Example:
Router(config-slb-probe)# expect status 401
regex Copyright
|
(Optional) Configures the expected HTTP status code or regular expression.
|
Step 7
|
header field-name [field-value]
Example:
Router(config-slb-probe)# header HeaderName
HeaderValue
|
(Optional) Configures header values for the HTTP probe.
|
Step 8
|
interval seconds
Example:
Router(config-slb-probe)# interval 11
|
(Optional) Configures the HTTP probe transmit timers.
|
Step 9
|
port port
Example:
Router(config-slb-probe)# port 8
|
(Optional) Configures the port to which the HTTP probe is to connect.
|
Step 10
|
request
[method {get | post | head | name name}]
[url path]
Example:
Router(config-slb-probe)# request method post
url /probe.cgi?all
|
(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 a Ping Probe
Perform the following task to configure a ping probe.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb probe probe ping
4. address [ip-address [routed]]
5. faildetect number-of-pings
6. interval seconds
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb probe probe ping
Example:
Router(config)# ip slb probe PROBE1 ping
|
Configures the IOS Server Load Balancing (IOS SLB) probe name and enters ping probe configuration mode.
|
Step 4
|
address [ip-address [routed]]
Example:
Router(config-slb-probe)# address 10.1.10.1
|
(Optional) Configures an IP address to which to send the ping probe.
|
Step 5
|
faildetect number-of-pings
Example:
Router(config-slb-probe)# faildetect 16
|
(Optional) Specifies the number of consecutive unacknowledged pings that constitute failure of the real server or firewall.
|
Step 6
|
interval seconds
Example:
Router(config-slb-probe)# interval 11
|
(Optional) Configures the ping probe transmit timers.
|
Configuring a TCP Probe
Perform the following task to configure a TCP probe.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb probe probe tcp
4. address [ip-address [routed]]
5. interval seconds
6. port port
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb probe probe tcp
Example:
Router(config)# ip slb probe PROBE5 tcp
|
Configures the IOS Server Load Balancing (IOS SLB) probe name and enters TCP probe configuration mode.
|
Step 4
|
address [ip-address [routed]]
Example:
Router(config-slb-probe)# address 10.1.10.1
|
(Optional) Configures an IP address to which to send the TCP probe.
|
Step 5
|
interval seconds
Example:
Router(config-slb-probe)# interval 5
|
(Optional) Configures the TCP probe transmit timers.
|
Step 6
|
port port
Example:
Router(config-slb-probe)# port 8
|
Configures the port to which the TCP probe is to connect.
|
Configuring a WSP Probe
Perform the following task to configure a WSP probe.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb probe probe wsp
4. address [ip-address [routed]]
5. interval seconds
6. url [path]
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb probe probe wsp
Example:
Router(config)# ip slb probe PROBE3 wsp
|
Configures the IOS Server Load Balancing (IOS SLB) probe name and enters Wireless Session Protocol (WSP) probe configuration mode.
|
Step 4
|
address [ip-address [routed]]
Example:
Router(config-slb-probe)# address 10.1.10.1
|
(Optional) Configures an IP address to which to send the Wireless Session Protocol (WSP) probe.
|
Step 5
|
interval seconds
Example:
Router(config-slb-probe)# interval 11
|
(Optional) Configures the Wireless Session Protocol (WSP) probe transmit timers.
|
Step 6
|
url [path]
Example:
Router(config-slb-probe)# url
http://localhost/test.txt
|
(Optional) Configures the Wireless Session Protocol (WSP) probe URL path.
|
Associating a Probe
Perform the following task to associate a probe with a real server or firewall.
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 a Real Server" section and the "Configuring Firewall Load Balancing" section for more details.
Note You cannot associate a WSP probe with a firewall.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb firewallfarm firewall-farm
or
ip slb serverfarm server-farm
4. probe probe
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb firewallfarm firewall-farm
or
ip slb serverfarm server-farm
Example:
Router(config)# ip slb serverfarm PUBLIC
or
Router(config)# ip slb firewallfarm FIRE1
|
Identifies a firewall farm and enters firewall farm configuration mode.
or
Identifies a server farm and enters SLB server farm configuration mode.
|
Step 4
|
probe probe
Example:
Router(config-slb-sfarm)# probe PROBE1
or
Router(config-slb-fw-real)# probe FireProbe
|
Associates a probe with a firewall farm or a server farm.
|
Verifying a Probe
Perform the following task to verify a probe.
SUMMARY STEPS
1. show ip slb probe
DETAILED STEPS
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
Configuring DFP
Perform the following task to configure IOS SLB as a DFP manager, and to identify a DFP agent with which IOS SLB can initiate connections.
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.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb dfp [password [[encrypt] secret-string [timeout]]
4. agent ip-address port [timeout [retry-count [retry-interval]]]
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb dfp [password [[encrypt] secret-string
[timeout]]
Example:
Router(config)# ip slb dfp password Password1 360
|
Configures Dynamic Feedback Protocol (DFP), supplies an optional password, and enters DFP configuration mode.
|
Step 4
|
agent ip-address port [timeout [retry-count
[retry-interval]]]
Example:
Router(config-slb-dfp)# agent 10.1.1.1 2221 30 0 10
|
Identifies a Dynamic Feedback Protocol (DFP) agent to which IOS Server Load Balancing (IOS SLB) can connect.
|
What to Do Next
To configure IOS SLB as a DFP agent, refer to the DFP Agent Subsystem feature document for Cisco IOS Release 12.2(18)SXB.
GPRS Load Balancing Configuration Task List
Perform the following tasks to configure GPRS load balancing.
SUMMARY STEPS
1. Configure a server farm and a real server.
2. Configure a virtual server.
3. Configure the virtual IP address as a loopback on each of the GGSNs in the servers.
4. Route each GGSN to each associated SGSN.
5. Route each SGSN to the virtual templates on each associated Cisco GGSN, and to the GPRS load-balancing virtual server.
6. Configure a GSN idle timer.
DETAILED STEPS
| |
Task
|
Description
|
Step 1
|
Configure a server farm and a real server.
|
See the "Configuring a Server Farm and a Real Server" procedure.
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.
|
Step 2
|
Configure a virtual server.
|
See the "Configuring a Virtual Server" procedure.
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.
|
Step 3
|
Configure the virtual IP address as a loopback on each of the GGSNs in the servers.
|
(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 Virtual Interfaces" section in the Cisco IOS Interface Configuration Guide for more information.
|
Step 4
|
Route each GGSN to each associated SGSN.
|
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 for more details.
|
Step 5
|
Route 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.
|
Step 6
|
Configure a GSN idle timer.
|
(Optional) This step is applicable only if GTP cause code inspection is enabled.
See the "Configuring a GSN Idle Timer" section for more information.
|
Configuring a GSN Idle Timer
Perform this task to configure a GSN idle timer.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb timers gtp gsn duration
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb timers gtp gsn duration
Example:
Router(config)# ip slb timers gtp gsn 45
|
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).
|
GGSN-IOS SLB Messaging Task List
Perform this task to configure GGSN-IOS SLB messaging.
SUMMARY STEPS
1. Configure the GGSN to support GGSN-IOS SLB messaging.
2. Configure a server farm and a real server.
3. Configure a virtual server.
DETAILED STEPS
| |
Task
|
Description
|
Step 1
|
Configure the GGSN to support GGSN-IOS SLB messaging.
|
When you configure GGSN-IOS SLB messaging support, configure all IOS SLB virtual servers that share the same GGSN to use the same NAT mode, either dispatched mode or directed mode, using the gprs slb mode command. The virtual servers cannot use a mix of dispatched mode and directed mode, because you can configure only one NAT mode on a given GGSN.
For more information, refer to the Cisco IOS Mobile Wireless Configuration Guide for GGSN 5.0 for Cisco IOS Release 12.3(2)XU or later.
|
Step 2
|
Configure a server farm and a real server.
|
See the "Configuring a Server Farm and a Real Server" procedure.
When you configure the server farm and real server for GGSN-IOS SLB messaging, to prevent IOS SLB from failing the current real server when reassigning the session to a new real server, disable automatic server failure detection by specifying the no faildetect inband command.
|
Step 3
|
Configure a virtual server.
|
See the "Configuring a Virtual Server" procedure.
When you configure the virtual server for GGSN-IOS SLB messaging, specify the gtp notification cac command to limit the number of times IOS SLB can reassign a session to a new real server.
|
Configuring GPRS Load Balancing Maps
Perform this task to configure GPRS load balancing maps.
GPRS load balancing maps enable IOS SLB to categorize and route user traffic based on APNs. To enable maps for GPRS load balancing, you must define a GTP map, then associate the map with a server farm.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb map map-id gtp | radius}
4. apn string
5. exit
6. ip slb vserver virtual-server
7. virtual ip-address [netmask [group]] {tcp | udp} [port | any] [service service]
8. serverfarm primary-farm [backup backup-farm [sticky]] [map map-id priority priority]
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb map map-id gtp | radius}
Example:
Router(config)# ip slb map 1 radius
|
Configures an IOS SLB GTP map and enters SLB GTP map configuration mode.
|
Step 4
|
Example:
Router(config-slb-map-gtp)# apn abc
|
Configures an ASCII regular expression string to be matched against the access point name (APN) for general packet radio service (GPRS) load balancing.
|
Step 5
|
Example:
Router(config-slb-map-gtp)# exit
|
Exits SLB GTP map configuration mode.
|
Step 6
|
ip slb vserver virtual-server
Example:
Router(config)# ip slb vserver GGSN_SERVER
|
Identifies a virtual server and enters virtual server configuration mode.
|
Step 7
|
virtual ip-address [netmask [group]]
{tcp | udp} [port | any] [service service]
Example:
Router(config-slb-vserver)# virtual
10.10.10.10 udp 0 service gtp
|
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 8
|
serverfarm primary-farm
[backup backup-farm [sticky]]
[map map-id priority priority]
Example:
Router(config-slb-vserver)# serverfarm
farm1 backup farm2 map 1 priority 3
|
Associates a GTP map with a server farm. 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 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.
You can associate more than one server farm with a given virtual server by configuring more than one serverfarm command, each with a unique map ID and a unique priority. (That is, each map ID and each map priority must be unique across all server farms associated with the virtual server.
If you are using GTP maps, and you have configured a given real server in more than one server farm, you must associate a different virtual server with each server farm.
|
Configuring KeepAlive Application Protocol (KAL-AP) Agent Support
Perform this task to configure KAL-AP agent support.
KAL-AP agent support enables IOS SLB to perform load balancing in a global server load balancing (GSLB) environment.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb capp udp
4. peer [ip-address] port port
5. peer [ip-address] secret [encrypt] secret-string
6. exit
7. ip slb serverfarm server-farm
8. kal-ap domain tag
9. farm-weight setting
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb capp udp
Example:
Router(config)# ip slb capp udp
|
Enables the KAL-AP agent and enters SLB Content Application Peering Protocol (CAPP) configuration mode.
|
Step 4
|
peer [ip-address] port port
Example:
Router(config-slb-capp)# peer port 6000
|
(Optional) Specifies the port to which the KAL-AP agent is to connect.
|
Step 5
|
peer [ip-address] secret [encrypt]
secret-string
Example:
Router(config-slb-capp)# peer secret
SECRET_STRING
|
(Optional) Enables Message Digest Algorithm Version 5 (MD5) authentication for the KAL-AP agent.
|
Step 6
|
exit
Example:
Router(config-slb-map-gtp)# exit
|
Exits SLB CAPP configuration mode.
|
Step 7
|
ip slb serverfarm server-farm
Example:
Router(config)# ip slb serverfarm PUBLIC
|
Identifies a server farm and enters SLB server farm configuration mode.
|
Step 8
|
kal-ap domain tag
Example:
Router(config-slb-sfarm)# kal-ap domain
chicago-com
|
(Optional) Enables the KAL-AP agent to look for a domain tag when reporting the load for a virtual server.
|
Step 9
|
farm-weight setting
Example:
Router(config-slb-sfarm)# farm-weight 16
|
(Optional) Specifies a weight to be used by the KAL-AP agent when calculating the load value for a server farm.
|
RADIUS Load Balancing Configuration Task List
Perform this task to configure RADIUS load balancing.
SUMMARY STEPS
1. Configure a server farm and a real server.
2. Configure a virtual server.
3. Enable IOS SLB to inspect packets for RADIUS framed-IP sticky routing.
4. Configure RADIUS load balancing maps.
5. Configure RADIUS load balancing accelerated data plane forwarding.
6. Increase the number of available MLS entries.
7. Configure a probe.
DETAILED STEPS
| |
Task
|
Description
|
Step 1
|
Configure a server farm and a real server.
|
See the "Configuring a Server Farm and a Real Server" procedure.
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.
|
Step 2
|
Configure a virtual server.
|
See the "Configuring a Virtual Server" procedure.
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.
|
| |
Configure a virtual server.
(continued)
|
See the "Configuring a Virtual Server" procedure.
When you configure the virtual server for RADIUS load balancing, keep the following considerations in mind:
•(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.
|
| |
Configure a virtual server.
(continued)
|
See the "Configuring a Virtual Server" procedure.
When you configure the virtual server for RADIUS load balancing, keep the following considerations in mind:
•(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.
•(Optional—for RADIUS load balancing accelerated data plane forwarding only) To configure a VSA correlation group for an authentication virtual server, and to specify whether IOS SLB is to create VSA correlation entries based on RADIUS calling station IDs or RADIUS usernames, configure the radius inject auth command.
To configure a timer for VSA correlation for an authentication virtual server, configure the radius inject auth timer command.
To buffer VSAs for VSA correlation for an authentication virtual server, configure the radius inject auth vsa command.
To configure a VSA correlation group for an accounting virtual server, and to enable Message Digest Algorithm Version 5 (MD5) authentication for VSA correlation, configure the radius inject acct command.
|
Step 3
|
Enable IOS SLB to inspect packets for RADIUS framed-IP sticky routing.
|
(Optional) See the "Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing" section.
|
Step 4
|
Configure RADIUS load balancing maps.
|
(Optional) See the "Configuring RADIUS Load Balancing Maps" section.
|
Step 5
|
Configure RADIUS load balancing accelerated data plane forwarding.
|
(Optional) See the "Configuring RADIUS Load Balancing Accelerated Data Plane Forwarding" section.
|
Step 6
|
Increase 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.
|
Step 7
|
Configure a probe.
|
See the "Configuring a Probe" section.
To verify the health of the server, configure a ping probe.
|
Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing
Perform this task to enable 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.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb route {framed-ip deny | ip-address netmask framed-ip | inter-firewall}
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb route {framed-ip deny | ip-address
netmask framed-ip | inter-firewall}
Example:
Router(config)# ip slb route 10.10.10.1
255.255.255.255 framed-ip
|
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.
|
Configuring RADIUS Load Balancing Maps
Perform this task to configure RADIUS load balancing maps.
RADIUS load balancing maps enable IOS SLB to categorize and route user traffic based on RADIUS calling station IDs and user names. To enable maps for RADIUS load balancing, you must define a RADIUS map, then associate the map with a server farm.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb map map-id radius
4. calling-station-id string
5. username string
6. exit
7. ip slb vserver virtual-server
8. virtual ip-address [netmask [group]] {tcp | udp} [port | any] [service service]
9. serverfarm primary-farm [backup backup-farm [sticky]] [map map-id priority priority]
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb map map-id radius
Example:
Router(config)# ip slb map 1 radius
|
Configures an IOS SLB RADIUS map and enters SLB RADIUS map configuration mode.
|
Step 4
|
calling-station-id string
Example:
Router(config-slb-radius-map)#
calling-station-id .919*
|
Configures an ASCII regular expression string to be matched against the calling station ID attribute for RADIUS load balancing.
|
Step 5
|
username string
Example:
Router(config-slb-map-radius)# )#
username ...?525*
|
Configures an ASCII regular expression string to be matched against the username attribute for RADIUS load balancing.
|
Step 6
|
exit
Example:
Router(config-slb-map-gtp)# exit
|
Exits SLB RADIUS map configuration mode.
|
Step 7
|
ip slb vserver virtual-server
Example:
Router(config)# ip slb vserver GGSN_SERVER
|
Identifies a virtual server and enters virtual server configuration mode.
|
Step 8
|
virtual ip-address [netmask [group]] {tcp | udp}
[port | any] [service service]
Example:
Router(config-slb-vserver)# virtual 10.0.0.1 udp
0 service radius
|
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 RADIUS load balancing, specify the service radius keyword option.
|
Step 9
|
serverfarm primary-farm
[backup backup-farm [sticky]]
[map map-id priority priority]
Example:
Router(config-slb-vserver)# serverfarm SF1 backup
SF2 map 1 priority 1
|
Associates a RADIUS map with a server farm. 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 RADIUS load balancing does not support the sticky keyword.
You can associate more than one server farm with a given virtual server by configuring more than one serverfarm command, each with a unique map ID and a unique priority. (That is, each map ID and each map priority must be unique across all server farms associated with the virtual server.)
|
Configuring RADIUS Load Balancing Accelerated Data Plane Forwarding
Perform this task to configure RADIUS load balancing accelerated data plane forwarding.
RADIUS load balancing accelerated data plane forwarding, also known as Turbo RADIUS load balancing, is a high-performance solution that uses basic policy-based routing (PBR) route maps to handle subscriber data-plane traffic in a CSG environment.
Prerequisites
Turbo RADIUS load balancing requires a server farm configured with predictor route-map on the accounting virtual server.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb serverfarm server-farm
4. predictor [roundrobin | leastconns | route-map mapname]
5. exit
6. ip slb vserver virtual-server
7. virtual ip-address [netmask [group]] {tcp | udp} [port | any] [service service]
8. serverfarm primary-farm [backup backup-farm [sticky]] [map map-id priority priority]
9. radius acct local-ack key [encrypt] secret-string
10. radius inject auth group-number {calling-station-id | username}
11. radius inject auth timer seconds
12. radius inject auth vsa vendor-id
DETAILED STEPS
| |
Command
|
Description
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb serverfarm server-farm
Example:
Router(config)# ip slb serverfarm PUBLIC
|
Identifies a server farm and enters SLB server farm configuration mode.
|
Step 4
|
predictor [roundrobin | leastconns |
route-map mapname]
Example:
Router(config-slb-sfarm)# predictor route-map
map1
|
(Optional) Specifies the algorithm to be used to determine how a real server is selected.
Turbo RADIUS load balancing requires the route-map keyword and mapname argument.
When you specify the predictor route-map command, no further commands in SLB server farm configuration mode or real server configuration mode are allowed.
|
Step 5
|
exit
Example:
Router(config-slb-sfarm)# exit
|
Exits SLB server farm configuration mode.
|
Step 6
|
ip slb vserver virtual-server
Example:
Router(config)# ip slb vserver RADIUS_AUTH
|
Identifies a virtual server and enters virtual server configuration mode.
|
Step 7
|
virtual ip-address [netmask [group]] {tcp | udp}
[port | any] [service service]
Example:
Router(config-slb-vserver)# virtual 10.10.10.10
udp 1813 service radius
|
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 and enters SLB virtual server configuration mode.
Note For RADIUS load balancing, specify the service radius keyword option.
|
Step 8
|
serverfarm primary-farm
[backup backup-farm [sticky]]
[map map-id priority priority]
Example:
Router(config-slb-vserver)# serverfarm AAAFARM
|
Associates a RADIUS map with a server farm. 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 RADIUS load balancing does not support the sticky keyword.
You can associate more than one server farm with a given virtual server by configuring more than one serverfarm command, each with a unique map ID and a unique priority. (That is, each map ID and each map priority must be unique across all server farms associated with the virtual server.)
|
Step 9
|
radius acct local-ack key [encrypt] secret-string
Example:
Router(config-slb-vserver)# radius acct local-ack
key SECRET_PASSWORD
|
(Optional) Configures VSA correlation and enables a RADIUS virtual server to acknowledge RADIUS accounting messages
Note If vendor-specific attribute (VSA) correlation is configured, and if the Cisco VSA is buffered, then the Cisco VSA is injected into the RADIUS Accounting-Start packet. Turbo RADIUS load balancing does not require VSA correlation.
This command is valid only for VSA correlation accounting virtual servers.
|
Step 10
|
radius inject auth group-number
{calling-station-id | username}
Example:
Router(config-slb-vserver)# radius inject auth 1
calling-station-id
|
(Optional) Configures a vendor-specific attribute (VSA) correlation group for an IOS SLB RADIUS load balancing accelerated data plane forwarding authentication virtual server, and specifies whether IOS SLB is to create VSA correlation entries based on RADIUS calling station IDs or RADIUS usernames.
For a given authentication virtual server, you can configure a single radius inject auth group-number calling-station-id command or a single radius inject auth group-number username command, but not both.
This command is valid only for VSA correlation authentication virtual servers.
|
Step 11
|
radius inject auth timer seconds
Example:
Router(config-slb-vserver)# radius inject auth
timer 45
|
(Optional) Configures a timer for vendor-specific attribute (VSA) correlation for an IOS SLB RADIUS load balancing accelerated data plane forwarding authentication virtual server.
This command is valid only for VSA correlation authentication virtual servers.
|
Step 12
|
radius inject auth vsa vendor-id
Example:
Router(config-slb-vserver)# radius inject auth
vsa vendor1
|
(Optional) Buffers vendor-specific attributes (VSAs) for VSA correlation for an IOS SLB RADIUS load balancing accelerated data plane forwarding authentication virtual server.
This command is valid only for VSA correlation authentication virtual servers.
|
Exchange Director for mSEF Configuration Task List
Perform this task to configure Exchange Director for mSEF.
This section contains the following information:
•RADIUS Configuration for the Exchange Director
•Firewall Configuration for the Exchange Director
RADIUS Configuration for the Exchange Director
Perform this task to configure RADIUS load balancing for the Exchange Director.
SUMMARY STEPS
1. Configure a server farm and a real server.
2. Configure a virtual server.
3. Enable IOS SLB to inspect packets for RADIUS framed-IP sticky routing.
4. Configure RADIUS load balancing maps.
5. Increase the number of available MLS entries.
6. Configure a probe.
DETAILED STEPS
| |
Task
|
Description
|
Step 1
|
Configure a server farm and a real server.
|
See the "Configuring a Server Farm and a Real Server" procedure.
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.
|
Step 2
|
Configure a virtual server.
|
See the "Configuring a Virtual Server" procedure.
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.
|
| |
Configure a virtual server.
(continued)
|
See the "Configuring a Virtual Server" procedure.
When you configure the virtual server for RADIUS load balancing, keep the following considerations in mind:
•(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.
|
Step 3
|
Enable IOS SLB to inspect packets for RADIUS framed-IP sticky routing.
|
(Optional) See the "Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing" section.
|
Step 4
|
Configure RADIUS load balancing maps.
|
(Optional) See the "Configuring RADIUS Load Balancing Maps" section.
|
Step 5
|
Increase 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.
|
Step 6
|
Configure a probe.
|
See the "Configuring a Probe" section.
To verify the health of the server, configure a ping probe.
|
Firewall Configuration for the Exchange Director
Perform this task to configure firewall load balancing 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 a Firewall Farm (Required)
•Verifying a Firewall Farm (Optional)
•Verifying Firewall Connectivity (Optional)
•Configuring a Probe (Required)
•Configuring a Wildcard Search (Optional)
Configuring a Firewall Farm
Perform the following task to configure a firewall farm.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb firewallfarm firewall-farm
4. real ip-address
5. probe probe
6. weight setting
7. inservice
8. exit
9. access [source source-ip netmask] [destination destination-ip netmask]| inbound inbound-interface | outbound outbound-interface]
10. predictor hash address [port]
11. replicate casa listen-ip remote-ip port [interval] [password [[encrypt] secret-string [timeout]]
12. protocol tcp
13. delay duration
14. idle duration
15. maxconns maximum-number
16. sticky seconds [netmask netmask] [source | destination]
17. exit
18. protocol datagram
19. idle duration
20. maxconns maximum-number
21. sticky seconds [netmask netmask] [source | destination]
22. exit
23. inservice
DETAILED STEPS
| |
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
•Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
ip slb firewallfarm firewall-farm
Example:
Router(config)# ip slb firewallfarm FIRE1
|
Adds a firewall farm definition to the IOS Server Load Balancing (IOS SLB) configuration and enters firewall farm configuration mode.
|
Step 4
|
real ip-address
Example:
Router(config-slb-fw)# real 10.1.1.1
|
Identifies a firewall by IP address as a member of a firewall farm and enters real server configuration mode.
|
Step 5
|
probe probe
Example:
Router(config-slb-fw-real)# probe FireProbe
|
Associates a probe with the firewall.
|
Step 6
|
weight setting
Example:
Router(config-slb-fw-real)# weight 16
|
(Optional) Specifies the firewall's workload capacity relative to other firewalls in the firewall farm.
|
Step 7
|
inservice
Example:
Router(config-slb-fw-real)# inservice
|
Enables the firewall for use by the firewall farm and by IOS Server Load Balancing (IOS SLB).
|
Step 8
|
exit
Example:
Router(config-slb-fw-real)# exit
|
Exits real server configuration mode.
|
Step 9
|
access [source source-ip netmask]
[destination destination-ip netmask]| inbound
inbound-interface | outbound outbound-interface]
Example:
Router(config-slb-fw)# access destination 10.1.6.0
255.255.255.0
|
(Optional) Routes specific flows to a firewall farm.
|
Step 10
|
predictor hash address [port]
Example:
Router(config-slb-fw)# predictor hash address
|
(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 11
|
replicate casa listen-ip remote-ip port [interval]
[password [[encrypt] secret-string [timeout]]
Example:
Router(config-slb-fw)# replicate casa 10.10.10.11
10.10.11.12 4231
|
(Optional) Configures a stateful backup of IOS Server Load Balancing (IOS SLB) firewall load balancing decision tables to a backup switch.
|
Step 12
|
protocol tcp
Example:
Router(config-slb-fw)# protocol tcp
|
(Optional) Enters firewall farm TCP protocol configuration mode.
|
Step 13
|
delay duration
Example:
Router(config-slb-fw-tcp)# delay 30
|
(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 14
|
idle duration
Example:
Router(config-slb-fw-tcp)# idle 120
|
(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 15
|
Example:
Router(config-slb-fw-tcp)# maxconns 1000
|
(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 16
|
sticky |
