Downloads |
Table Of Contents
Overview of the IOS SLB Feature
Algorithms for Server Load Balancing
Automatic Server Failure Detection
Avoiding Attacks on Server Farms and Firewall Farms
Client-Assigned Load Balancing
Delayed Removal of TCP Connection Context
Dynamic Feedback Protocol for IOS SLB
Multiple Firewall Farm Support
Network Address Translation (NAT) and Session Redirection
Probes in Server Load Balancing
Probes in Firewall Load Balancing
Transparent Webcache Load Balancing
Supported Standards, MIBs, and RFCs
Configuring the Virtual Servers
Configuring the Restricted Clients
Verifying the Restricted Clients
Verifying IOS SLB Connectivity
Specifying a Server Load Balancing Algorithm
Configuring Real Server Attributes
Adjusting Virtual Server Values
Configuring IOS SLB Firewall Load Balancing
Configuring One or More Probes
Verifying Firewall Connectivity
Configuring IOS SLB Dynamic Feedback Protocol
Configuring IOS SLB as a DFP Manager
Configuring a Client Subsystem as a DFP Agent
Implementing IOS SLB Stateless Backup
How IOS SLB Stateless Backup Works
Configuring IOS SLB Stateless Backup
Verifying the IOS SLB Stateless Backup Configuration
Sample IOS SLB Stateless Backup Configuration
Configuring IOS SLB Stateful Backup
Configuring Stateful Backup for Server Load Balancing
Configuring Stateful Backup for Firewall Load Balancing
Monitoring and Maintaining the IOS SLB Feature
Complete Example Configuration
Example of a Layer 3 Switch with ISL, VLAN, and BVI with GEC
Example of IOS SLB with Firewall Load Balancing
Internal Firewall Load-Balancing Device
External Firewall Load-Balancing Device
Example of IOS SLB with Server Load Balancing and Firewall Load Balancing
Internal Server and Firewall Load-Balancing Device
External Firewall Load-Balancing Device
Example of IOS SLB with Multiple Firewall Farms
Internal Firewall Load-Balancing Device
External Firewall Load-Balancing Device
Example of IOS SLB with Probes
Example of a Layer 3 Switch Configured with IOS SLB
Switch A Configuration Statements
Switch B Configuration Statements
Switch C Configuration Statements
Example of an IOS Layer 3 Switch with HSRP
Device A (Active) Configuration Statements
Device B (Standby) Configuration Statements
Examples of IOS SLB with Stateless Backup
Example with Dynamic Routing and Trunking
Example with Dynamic Routing and No Trunking
Example with Static Routing and Trunking
Example with Static Routing and No Trunking
Example of IOS SLB with Stateful Backup
Switch SLB1 Configuration Statements
Switch SLB2 Configuration Statements
Example of IOS SLB with Active Standby
SLB 1 Configuration Statements
SLB 2 Configuration Statements
Access Router Configuration Statements
Example of IOS SLB with Redistribution of Static Routes
Routing Information Protocol (RIP)
Open Shortest Path First (OSPF)
Interior Gateway Routing Protocol (IGRP)
Enhanced Interior Gateway Routing Protocol (Enhanced IGRP)
Examples of IOS SLB with WAP Load Balancing
Example with WAP Load Balancing
Example with UDP Load Balancing
Examples of IOS SLB with Route Health Injection
Example with Two Distributed Sites with One Web Server Each
Example with Two Distributed Sites with Two Web Servers Each
Example with Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each
Example of IOS SLB with Sticky Connections
delay (firewall farm TCP protocol)
idle (firewall farm TCP protocol)
idle (firewall farm UDP protocol)
inservice (firewall farm real server)
inservice (server farm real server)
inservice (server farm virtual server)
maxconns (firewall farm TCP protocol)
maxconns (firewall farm UDP protocol)
predictor hash address (firewall farm)
probe (firewall farm real server)
replicate casa (firewall farm)
replicate casa (virtual server)
standby priority, standby preempt
sticky (firewall farm TCP protocol)
sticky (firewall farm UDP protocol)
weight (firewall farm real server)
FAQ (Frequently Asked Questions)
IOS Server Load Balancing
Feature History
12.0(7)XE
This feature was introduced with support for the following platforms:
•
Catalyst 6000 Family Switches with Supervisor Engine 1
•
The following functions were provided:
•
•
•
•
•
12.1(1)E
The following functions were added:
•
•
12.1(2)E
The following functions were added:
•
•
•
12.1(3a)E
The following functions were added:
•
•
12.1(5a)E
The following functions were added:
•
•
12.1(5)T
The Cisco IOS Release 12.1(1)E feature was migrated to Cisco IOS Release 12.1(5)T, supporting Cisco 7200 Series Routers only.
12.1(7)E
Support for the following platform was added:
•
The following functions were added:
•
12.1(8a)E
Support for the following platform was added:
•
The following functions were added:
•
This document describes the Cisco IOS Server Load Balancing (SLB) feature in Cisco IOS Release 12.1(8a)E. It includes the following sections:
•
•
•
•
Overview of the IOS SLB Feature
The IOS SLB feature is an IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, you can define a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. In this environment, the clients connect to the IP address of the virtual server. When a client initiates a connection to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured load-balancing algorithm.
Note
IOS SLB also provides firewall load balancing, which balances flows across a group of firewalls called a firewall farm.
Figure 1 illustrates a logical view of a simple IOS SLB network.
Figure 1 Logical View of IOS SLB
Functions and Capabilities
This section describes the following functions and capabilities provided by IOS SLB.
Note
•
•
•
•
•
•
•
•
•
Algorithms for Server Load Balancing
IOS SLB provides the following load-balancing algorithms:
You can specify one of these algorithms as the basis for choosing a real server for each new connection request that arrives at the virtual server.
Weighted Round Robin
The weighted round robin algorithm specifies that the real server used for a new connection to the virtual server is chosen from the server farm in a circular fashion. Each real server is assigned a weight, n, that represents its capacity to handle connections, as compared to the other real servers associated with the virtual server. That is, new connections are assigned to a given real server n times before the next real server in the server farm is chosen.
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. The first three connections to the virtual server are assigned to ServerA, the fourth connection to ServerB, and the fifth and sixth connections to ServerC.
Note
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
Alternate IP Addresses
IOS SLB enables you to telnet to the load-balancing device using an alternate IP address. To do so, use either of the following methods:
•
•
This function is similar to that provided by the LocalDirector (LD) Alias command.
Automatic Server Failure Detection
IOS SLB automatically detects each failed Transmission Control Protocol (TCP) connection attempt to a real server, and increments a failure counter for that server. (The failure counter is not incremented if a failed TCP connection from the same client has already been counted.) If a server's failure counter exceeds a configurable failure threshold, the server is considered out of service and is removed from the list of active real servers.
Automatic Unfail
When a real server fails and is removed from the list of active servers, it is assigned no new connections for a length of time specified by a configurable retry timer. After that timer expires, the server is again eligible for new virtual server connections and IOS SLB sends the server the next qualifying connection. If the connection is successful, the failed server is placed back on the list of active real servers. If the connection is unsuccessful, the server remains out of service and the retry timer is reset.
Avoiding Attacks on Server Farms and Firewall Farms
IOS SLB relies on a site's firewalls to protect the site from attacks. In general, IOS SLB is no more susceptible to direct attack than is any switch or router. However, a highly secure site can take the following steps to enhance its security:
•
•
•
•
Backup Server Farms
A backup server farm is a server farm that can be used when none of the real servers defined in a primary server farm is available to accept new connections. When configuring backup server farms, keep in mind the following considerations:
•
•
•
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.
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.
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.
You can define IOS SLB as a DFP manager, as a DFP agent for another DFP manager (such as DistributedDirector), or as both at the same time. In such a configuration, IOS SLB sends periodic reports to DistributedDirector, 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.
This capability enables a single device to perform both global load balancing, as managed by DistributedDirector, and local load balancing, as managed by IOS SLB.
DFP also supports the use of multiple DFP agents from different client subsystems (such as IOS SLB) at the same time.
As part of the implementation of the DFP agent subsystem, the manager command has been removed. Its function is now provided by the ip dfp agent global configuration command, and by the following DFP agent configuration commands:
Firewall Load Balancing
As its name implies, firewall load balancing enables IOS SLB to balance flows to firewalls. Firewall load balancing uses a load-balancing device on each side of a group of firewalls (called a firewall farm) to ensure that the traffic for each flow travels to the same firewall, ensuring that the security policy is not compromised.
You can configure more than one firewall farm in each load-balancing device.
Layer 3 firewalls, which have IP-addressable interfaces, are supported by IOS SLB firewall load balancing if they are subnet-adjacent to the firewall load-balancing device and have unique MAC addresses. The device does not modify the IP addresses in the user packet. To send the packet to the chosen firewall, the device determines which interface to use and changes the Layer 2 headers accordingly. This is the standard dispatched routing used by IOS SLB.
Layer 2 firewalls, which do not have IP addresses, are transparent to IOS SLB firewall load balancing. IOS SLB supports Layer 2 firewalls by placing them between two IP-addressable interfaces.
Whereas many Layer 3 firewalls might exist off a single Layer 3 interface on the load-balancing device (for example, a single LAN), only one Layer 2 firewall can exist off each interface.
When configuring the load-balancing device, you configure a Layer 3 firewall using its IP address, and a Layer 2 firewall using the IP address of the interface of the device on the "other side" of the firewall.
To balance flows across the firewalls in a firewall farm, IOS SLB firewall load balancing performs a route lookup on each incoming flow, examining the source and destination IP addresses (and optionally the source and destination TCP or User Datagram Protocol [UDP] port numbers). Firewall load balancing applies a hash algorithm to the results of the route lookup and selects the best firewall to handle the connection request.
Note
To maximize availability and resilience in a network with multiple firewalls, configure a separate equal-weight route to each firewall, rather than a single route to only one of the firewalls.
IOS SLB firewall load balancing provides the following capabilities:
•
•
•
•
•
•
•
Maximum Connections
IOS SLB allows you to configure maximum connections for server and firewall load balancing.
•
•
Multiple Firewall Farm Support
You can configure more than one firewall farm in each load-balancing device.
Network Address Translation (NAT) and Session Redirection
Cisco IOS NAT, RFC 1631, allows unregistered "private" IP addresses to connect to the Internet by translating them into globally registered IP addresses. Cisco IOS NAT also increases network privacy by hiding internal IP addresses from external networks.
IOS SLB can operate in one of two session redirection modes:
•
Note
•
IOS SLB supports the following types of NAT:
•
–
–
–
–
A less common form of server NAT is server port translation, which involves replacement of a virtual server port. Server port translation does not require server IP address translation, but the two translations can be used together.
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.
Note
Port-Bound Servers
When you define a virtual server, you must specify the TCP or UDP port handled by that virtual server. However, if you configure NAT on the server farm, you can also configure port-bound servers. Port-bound servers allow one virtual server IP address to represent one set of real servers for one service, such as Hypertext Transfer Protocol (HTTP), and a different set of real servers for another service, such as Telnet.
Packets destined for a virtual server address for a port that is not specified in the virtual server definition are not redirected.
IOS SLB supports both port-bound and non-port-bound servers, but port-bound servers are recommended.
Note
Probes
IOS SLB supports HTTP probes, ping probes, and WSP probes.
HTTP and ping 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.
WSP probes detect failures in the Wireless Application Protocol (WAP) stack on port 9201.
You can configure more than one probe, in any combination of types (HTTP, ping, or WSP), for each server farm, or for each firewall in a firewall farm.
Probes in Server Load Balancing
Probes determine the status of each real server in a server farm. All real servers associated with all virtual servers tied to that server farm are probed.
If a real server fails for one probe, it is failed for all probes. After the real server recovers, all probes must acknowledge its recovery before it is restored to service.
Probes in Firewall Load Balancing
Probes detect firewall failures. All firewalls associated with the firewall farm are probed.
If a firewall fails for one probe, it is failed for all probes. After the firewall recovers, all probes must acknowledge its recovery before it is restored to service.
Make sure you configure the HTTP probe to expect status code 401, to eliminate password problems. See the expect command for more details.
Use the ip http server command to configure an HTTP server on the device. See the description of the ip http server command in the Cisco IOS Configuration Fundamentals Command Reference for more details.
HTTP probes do not support HTTP over Secure Socket Layer (HTTPS).
In a transparent webcache load-balancing environment, an HTTP probe uses the real IP address of the webcache, since there is no virtual IP address configured.
Protocol Support
IOS SLB supports the following protocols:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Redundancy Enhancements
An IOS SLB device can represent a single point of failure, and the servers can lose their connections to the backbone, if either of the following occurs:
•
•
To reduce that risk, IOS SLB supports two redundancy options, both based on HSRP:
•
•
IOS SLB also supports active standby, in which two IOS SLBs can load-balance the same virtual IP address while at the same time acting as backups for each other. If a site has only one virtual IP address to load balance, an access router is used to direct a subset of the flows to each IOS SLB using policy-based routing.
IOS SLB firewall load balancing does not support active standby. That is, you cannot configure two pairs of firewall load balancing devices (one pair on each side of the firewalls), with each device in each pair handling traffic and backing up its partner.
Route Health Injection
By default, a virtual server's IP address is advertised (added to the routing table) when you bring the virtual server into service (using the inservice command). If you have a preferred host route to a website's virtual IP address, you can advertise that host route, but you have no guarantee that the IP address is available. However, you can use the advertise command to configure IOS SLB to advertise the host route only when IOS SLB has verified that the IP address is available. IOS SLB withdraws the advertisement when the IP address is no longer available. This function is known as route health injection.
Note
Slow Start
In an environment that uses weighted least connections load balancing, a real server that is placed in service initially has no connections, and could therefore be assigned so many new connections that it becomes overloaded. To prevent such an overload, slow start controls the number of new connections that are directed to a real server that has just been placed in service.
Sticky Connections
When you use sticky connections, new connections from a client IP address or subnet are assigned to the same real server (for server load balancing) or firewall (for firewall load balancing) as were previous connections from that address or subnet.
IOS SLB creates sticky objects to track client assignments. The sticky objects remain in the IOS SLB database after the last sticky connection is deleted, for a user-defined period. New connections from a client are sticky if the following conditions are met:
•
•
•
OR
A connection for the same client already exists. (That is, the connection is not the first for this client.)Sticky connections allow you to create a sticky object for a subnet, ensuring that all flows from the subnet are sent to the same real server. (Make sure the volume of flows is not so large that it overwhelms the real server.)
Sticky connections also permit the coupling of services that are handled by more than one virtual server or firewall farm. This allows connection requests for related services to use the same real server. For example, web server (HTTP) typically uses TCP port 80, and HTTPS uses port 443. If HTTP virtual servers and HTTPS virtual servers are coupled, connections for ports 80 and 443 from the same client IP address or subnet are assigned to the same real server.
SynGuard
SynGuard limits the rate of TCP start-of-connection packets (SYNchronize sequence numbers, or SYNs) handled by a virtual server to prevent a type of network problem known as a SYN flood denial-of-service attack. A user might send a large number of SYNs to a server, which could overwhelm or crash the server, denying service to other users. SynGuard prevents such an attack from bringing down IOS SLB or a real server. SynGuard monitors the number of SYNs handled by a virtual server at specific intervals and does not allow the number to exceed a configured SYN threshold. If the threshold is reached, any new SYNs are dropped.
IOS SLB firewall load balancing does not support SynGuard.
TCP Session Reassignment
IOS SLB tracks each TCP SYN sent to a real server by a client attempting to open a new connection. If several consecutive SYNs are not answered, or if a SYN is replied to with an RST, the TCP session is reassigned to a new real server. The number of SYN attempts is controlled by a configurable reassign threshold.
IOS SLB firewall load balancing does not support TCP session reassignment.
Transparent Webcache Load Balancing
IOS SLB can load balance port 80 flows across a cluster of transparent webcaches. To set up this function, configure the subnet IP addresses served by the transparent webcaches, or some common subset of them, as virtual servers. Virtual servers used for transparent webcache 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 webcache might need to initiate its own connections to the Internet. Those connections should not be load balanced back to the same set of webcaches. To address this need, IOS SLB allows you to configure client exclude statements, which exclude connections initiated by the webcaches from the load-balancing scheme.
IOS SLB firewall load balancing does not support transparent webcache load balancing.
In the following sample configuration, virtual server WEBCACHE examines all web flows passing through the load-balancing device and dispatches them to server farm WEBCACHE-FARM. The client exclude statement excludes flows originating from subnet 80.80.7.0, enabling the real servers 80.80.7.188 and 80.80.7.189 to communicate with the Internet as needed.
ip slb serverfarm WEBCACHE-FARMreal 80.80.7.188inservicereal 80.80.7.189inserviceip slb vserver WEBCACHEvirtual 0.0.0.0 0.0.0.0 tcp wwwserverfarm WEBCACHE-FARMclient 80.80.7.0 255.255.255.0 excludeinserviceWAP Load Balancing
You can use IOS SLB to load balance Wireless Session Protocol (WSP) sessions among a group of WAP gateways or servers on an IP bearer network. WAP runs on top of UDP on a set of well known ports, with each port indicating a different WAP mode:
•
•
•
•
IOS SLB uses ping probes to detect failures in the WAP load-balancing device, and WSP probes to detect failures in the WAP stack on port 9201.
Benefits
IOS SLB shares the same software code base as Cisco IOS and has all the software features sets of Cisco IOS software. IOS SLB is recommended for customers desiring complete integration of SLB technology into traditional Cisco switches and routers.
On the Cisco Catalyst 6500 switch, IOS SLB takes advantage of hardware acceleration to forward data packets at very high speed when running in dispatched mode.
IOS SLB assures continuous, high availability of content and applications with proven techniques for actively managing servers and connections in a distributed environment. By distributing user requests across a cluster of servers, IOS SLB optimizes responsiveness and system capacity, and dramatically reduces the cost of providing Internet, database, and application services for large-, medium-, and small-scale sites.
IOS SLB facilitates scalability, availability, and ease of maintenance:
•
•
•
•
Administration of server applications is easier. Clients know only about virtual servers; no administration is required for real server changes.
Security of the real server is provided because its address is never announced to the external network. Users are familiar only with the virtual IP address. You can filter unwanted flows based on both IP address and TCP or UDP port numbers. Additionally, though it does not eliminate the need for a firewall, IOS SLB can help protect against some denial-of-service attacks.
In a branch office, IOS SLB allows balancing of multiple sites and disaster recovery in the event of full-site failure, and distributes the work of load balancing.
Restrictions
IOS SLB has the following restrictions:
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
–
–
- Active standby
- Network Address Translation (NAT)
- Port-bound servers
- SynGuard
- TCP session reassignment
- Transparent webcache load balancing
•
–
–
–
•
–
The term "MSFC" refers to either an MSFC1 or an MSFC2, except when specifically differentiated.
The term "PFC" refers to either a PFC1 or a PFC2, except when specifically differentiated.
–
–
–
–
–
•
–
–
–
Supported Platforms
•
•
•
•
Supported Standards, MIBs, and RFCs
Standards
•
MIBs
•
Note
RFCs
•
Required Configuration Tasks
This section describes the tasks required to configure a basic IOS SLB network.
Configuring IOS SLB involves identifying server farms, configuring groups of real servers in server farms, and configuring the virtual servers that represent the real servers to the clients. See the following sections for required configuration tasks for the IOS SLB feature.
•
•
•
•
•
Figure 2 shows a sample IOS SLB network with the following components:
•
•
–
–
•
–
–
Figure 2 Example IOS SLB Network
To configure the IOS SLB network shown in Figure 2, use the following commands beginning in global configuration mode:
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode. See the ip slb serverfarm command for more details.
Identifies a real server as a member of a server farm and initiates real server configuration mode. See the real (server farm) command for more details.
Enables the real server for use by IOS SLB. See the inservice (server farm real server) command for more details.
Router(config-slb-real)# exitReturns to server farm configuration mode.
Router(config-slb-sfarm)# endReturns to global configuration mode.
Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details.
Router(config-slb-vserver)# virtual ip-address [network-mask] {tcp | udp} [port-number | wsp | wsp-wtp | wsp-wtls | wsp-wtp-wtls] [service service-name]Specifies the virtual server IP address, type of connection, TCP or UDP port number, WSP mode, and optional service coupling. See the virtual (virtual server) command for more details.
Associates a real server farm with a virtual server, or configures a backup server farm. See the serverfarm command for more details.
Enables the virtual server for use by IOS SLB. See the inservice (server farm virtual server) command for more details.
Specifies which clients are allowed to use the virtual server. See the client (virtual server) command for more details.
The following sections include examples of the configuration commands used to configure and verify the IOS SLB network shown in Figure 2:
•
•
•
•
•
Configuring the Server Farms
The following commands configure the server farm PUBLIC and associate the three real servers:
Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-real)# reassign 2Router(config-slb-real)# faildetect numconns 4 numclients 2Router(config-slb-real)# retry 20Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.1.1.2Router(config-slb-real)# reassign 2Router(config-slb-real)# faildetect numconns 4Router(config-slb-real)# retry 20Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.1.1.3Router(config-slb-real)# reassign 2Router(config-slb-real)# faildetect numconns 4Router(config-slb-real)# retry 20Router(config-slb-real)# inserviceRouter(config-slb-real)# endThe following commands configure the server farm RESTRICTED and associate the two real servers:
Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# real 10.1.1.20Router(config-slb-real)# reassign 2Router(config-slb-real)# faildetect numconns 4Router(config-slb-real)# retry 20Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.1.1.21Router(config-slb-real)# reassign 2Router(config-slb-real)# faildetect numconns 4Router(config-slb-real)# retry 20Router(config-slb-real)# inserviceRouter(config-slb-real)# endRouter#Verifying the Server Farms
The following show ip slb reals command displays the status of server farms PUBLIC and RESTRICTED, the associated real servers, and their status:
Router# show ip slb realreal farm name weight state conns---------------------------------------------------------------------10.1.1.1 PUBLIC 8 OPERATIONAL 010.1.1.2 PUBLIC 8 OPERATIONAL 010.1.1.3 PUBLIC 8 OPERATIONAL 010.1.1.20 RESTRICTED 8 OPERATIONAL 010.1.1.21 RESTRICTED 8 OPERATIONAL 0Router#The following show ip slb serverfarm command displays the configuration and status of server farms PUBLIC and RESTRICTED:
Router# show ip slb serverfarmserver farm predictor nat reals bind id---------------------------------------------------PUBLIC ROUNDROBIN none 3 0RESTRICTED ROUNDROBIN none 2 0Router#Configuring the Virtual Servers
The following commands configure the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router#Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# virtual 10.0.0.1 tcp wwwRouter(config-slb-vserver)# serverfarm PUBLICRouter(config-slb-vserver)# idle 120Router(config-slb-vserver)# delay 5Router(config-slb-vserver)# inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# exitRouter(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# virtual 10.0.0.2 tcp wwwRouter(config-slb-vserver)# serverfarm RESTRICTEDRouter(config-slb-vserver)# idle 120Router(config-slb-vserver)# delay 5Router(config-slb-vserver)# inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# endRouter#Verifying the Virtual Servers
The following show ip slb vserver command verifies the configuration of the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router# show ip slb vserverslb vserver prot virtual state conns-------------------------------------------------------------------PUBLIC_HTTP TCP 10.0.0.1:80 OPERATIONAL 0RESTRICTED_HTTP TCP 10.0.0.2:80 OPERATIONAL 0Router#Router#Configuring the Restricted Clients
The following commands remove the virtual server RESTRICTED_HTTP from service, configure the restricted client access to the virtual server, then enable the virtual server again:
Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# no inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0Router(config-slb-vserver)# inserviceRouter(config-slb-vserver)#src = 0 - 0.(Information Deleted).index = 1Router(config-slb-vserver)# endRouter#Verifying the Restricted Clients
The following show ip slb conns command verifies the restricted client access and status:
Router# show ip slb connsvserver prot client real state nat-------------------------------------------------------------------------------RESTRICTED_HTTP TCP 10.4.4.0:80 10.1.1.20 CLOSING noneRouter#The following show ip slb conns command displays detailed information about the restricted client access status:
Router# show ip slb conns client 10.4.4.0 detailVSTEST_UDP, client = 10.4.4.0:80state = CLOSING, real = 10.1.1.20, nat = nonev_ip = 10.0.0.2:80, TCP, service = NONEclient_syns = 0, sticky = FALSE, flows attached = 0Router#Verifying IOS SLB Connectivity
To verify that the IOS SLB feature has been installed and is operating correctly, ping the real servers from the IOS SLB switch, then ping the virtual servers from the clients.
The following show ip slb stats command displays detailed information about the IOS SLB network status:Router# show ip slb statsPkts via normal switching: 0Pkts via special switching: 6Connections Created: 1Connections Established: 1Connections Destroyed: 0Connections Reassigned: 0Zombie Count: 0Connections Reused: 0Router#Normal switching is when IOS SLB packets are handled on normal IOS switching paths (CEF, fastswitching, and process level switching). Special switching is when IOS SLB packets are handled on hardware-assisted switching paths.
See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB networks and connections.
Optional Configuration Tasks
This section describes the following optional tasks you can use to fine tune the IOS SLB configuration:
•
•
•
•
•
•
•
•
Specifying a Server Load Balancing Algorithm
To determine which real server to use for each new connection request, the IOS SLB feature uses one of the following load-balancing algorithms: weighted round robin (the default) or weighted least connections. See one of the following sections for more details:
•
•
Note
To specify the load-balancing algorithm, use the following command in server farm configuration mode:
Specifies the algorithm to be used to determine how a real server is selected. See the predictor (server farm) command for more details.
The following example shows how to configure weighted least-connections algorithm:
Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# predictor leastconnsSee the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB network connections and the "Complete Example Configuration" section for an example of an IOS SLB network configuration.
Specifying a Bind ID
The bind ID allows a single physical server to be bound to multiple virtual servers and report a different weight for each one. Thus, the single real server is represented as multiple instances of itself, each having a different bind ID. DFP uses the bind ID to identify for which instance of the real server a given weight is specified. The bind ID is needed only if you are using DFP.
To configure a bind ID on the server farm for use by DFP, use the following command in server farm configuration mode:
Specifies a bind ID on the server farm for use by DFP. See the bindid command for more details.
The following example shows how to configure a bind ID of 309 on server farm RESTRICTED:
Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# bindid 309See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB network connections and the "Complete Example Configuration" section for an example of an IOS SLB network configuration.
Configuring Real Server Attributes
You can configure any of the following real server attributes, by using the following real server commands beginning in global configuration mode:
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode. See the ip slb serverfarm command for more details.
Identifies a real server as a member of a server farm and initiates real server configuration mode. See the real (server farm) command for more details.
Specifies the number of consecutive connection failures and, optionally, the number of unique client connection failures, that constitute failure of the real server. See the faildetect (real server) command for more details.
Specifies the maximum number of active connections allowed on the real server at one time. See the maxconns (server farm) command for more details.
Specifies the threshold of consecutive unacknowledged synchronizations that, if exceeded, result in an attempted connection to a different real server. See the reassign command for more details.
Specifies the interval, in seconds, to wait between the detection of a server failure and the next attempt to connect to the failed server. See the retry command for more details.
Specifies the real server's workload capacity relative to other servers in the server farm. See the weight (server farm) command for more details.
Enables the real server for use by IOS SLB. See the inservice (server farm real server) command for more details.
The following example shows how to configure the consecutive connection failures to 16 that constitute the failure of real server 10.1.1.1:
Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-real)# faildetect numconns 16The following example shows how to configure maximum number of connections to 1000:
Router(config-slb-real)# maxconns 1000The following example shows how to configure to 4 the number of consecutive unacknowledged SYNs that initiates assignment of the connection to a different real server:
Router(config-slb-real)# reassign 4The following example shows how to configure the retry interval to 120 seconds between the detection of a server failure and the next attempt to connect on real server 10.1.1.1:
Router(config-slb-real)# retry 120The following example shows how to configure workload capacity to 16, relative to other servers in the server farm:
Router(config-slb-real)# weight 16The following example shows how to enable the real server back into service after making changes to its configuration:
Router(config-slb-real)# inserviceSee the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB network connections and the "Complete Example Configuration" section for an example of an IOS SLB network configuration.
Adjusting Virtual Server Values
To change the default settings of the virtual server values, use the related virtual server command beginning in global configuration mode:
Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details.
Controls the installation of a static route to the Null0 interface for a virtual server address. See the advertise command for more details.
Specifies which clients are allowed to use the virtual server. See the client (virtual server) command for more details.
Specifies the amount of time IOS SLB maintains TCP connection context after a connection has terminated. See the delay (virtual server) command for more details.
Specifies the minimum amount of time IOS SLB maintains connection context in the absence of packet activity. See the idle (virtual server) command for more details.
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. See the sticky (virtual server) command for more details.
Specifies the rate of TCP SYNs handled by a virtual server in order to prevent a SYN flood denial-of-service attack. See the synguard (virtual server) command for more details.
Enables the virtual server for use by IOS SLB. See the inservice (server farm virtual server) command for more details.
The following commands remove the virtual server RESTRICTED_HTTP from service and then configure the restricted client access to the virtual server:
Router(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# no inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0By default, virtual server addresses are advertised. That is, static routes to the Null0 interface are installed for the virtual server addresses. To advertise these static routes using the routing protocol, you must configure redistribution of static routes for the routing protocol. To prevent the installation of a static route, use the no form of the advertise command:
Router(config-slb-vserver)# no advertiseThe following command configures the delay timer to 20 seconds after the termination of the TCP connection to the virtual server:
Router(config-slb-vserver)# delay 20The following command configures the idle time to 180 seconds (3 minutes) that the IOS SLB maintains connectivity to the virtual server in the absence of packet activity:
Router(config-slb-vserver)# idle 180The following command configures the time to 60 seconds for connections from the same client to use the same real server:
Router(config-slb-vserver)# sticky 60 group 1The following command configures the rate of TCP SYNs to 3600000 handled by the virtual server:
Router(config-slb-vserver)# synguard 3600000In the following example, the virtual server is enabled again after modification:
Router(config-slb-vserver)# inserviceRouter(config-slb-vserver)#src = 0 - 0.(Information Deleted).index = 1Router(config-slb-vserver)#See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB network connections and the "Complete Example Configuration" section for an example of an IOS SLB network configuration.
Configuring IOS SLB Firewall Load Balancing
This section describes the tasks required to configure a basic IOS SLB firewall load-balancing network.
IOS SLB firewall load balancing uses probes to detect and recover from failures. You must configure a probe on each real server in the firewall farm. Ping probes are recommended; see the "Configuring Ping Probes" section for more details. If a firewall does not allow ping probes to be forwarded, use HTTP probes instead. See the "Configuring HTTP Probes" section for more details.
This section describes the following IOS SLB firewall load-balancing configuration tasks:
•
•
•
Configuring One or More Probes
To configure an IOS SLB probe for firewall load balancing, refer to one of the following sections:
You can configure more than one probe, in any combination of types (HTTP, ping, or WSP), for each server farm, or for each firewall in a firewall farm.
Configuring the Firewall Farm
To configure an IOS SLB firewall load-balancing network, enter the following commands in order, beginning in global configuration mode:
Step 1
Adds a firewall farm definition to the IOS SLB configuration and initiates firewall farm configuration mode. See the ip slb firewallfarm command for more details.
Step 2
Identifies a firewall as a member of a firewall farm and initiates real server configuration mode. See the real (firewall farm) command for more details.
Step 3
Associates a probe with the firewall. See the probe (firewall farm real server) command for more details.
Step 4
(Optional) Specifies the firewall's workload capacity relative to other firewalls in the firewall farm. See the weight (firewall farm real server) command for more details.
Step 5
Enables the firewall for use by the firewall farm and by IOS SLB. See the inservice (firewall farm real server) command for more details.
Step 6
(Optional) Routes specific flows to a firewall farm. See the access command for more details.
Step 7
(Optional) Specifies whether the source and destination TCP or UDP port numbers, in addition to the source and destination IP addresses, are to be used when selecting a firewall. See the predictor hash address (firewall farm) command for more details.
Step 8
(Optional) Configures a stateful backup of IOS SLB firewall load balancing decision tables to a backup switch. See the replicate casa (firewall farm) command for more details.
Step 9
(Optional) Initiates TCP protocol configuration mode. See the tcp command for more details.
Step 10
(Optional) For firewall farm TCP protocol configuration mode, specifies the amount of time IOS SLB firewall load balancing maintains TCP connection context after a connection has terminated. See the delay (firewall farm TCP protocol) command for more details.
Step 11
(Optional) For firewall farm TCP protocol configuration mode, specifies the minimum amount of time IOS SLB firewall load balancing maintains connection context in the absence of packet activity. See the idle (firewall farm TCP protocol) command for more details.
Step 12
(Optional) For firewall farm TCP protocol configuration mode, specifies the maximum number of active connections allowed on the firewall farm at one time. See the maxconns (firewall farm TCP protocol) command for more details.
Step 13
(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:
•
•
See the sticky (firewall farm TCP protocol) command for more details.
Step 14
(Optional) Initiates UDP protocol configuration mode. See the udp command for more details.
Step 15
(Optional) For firewall farm UDP protocol configuration mode, specifies the minimum amount of time IOS SLB firewall load balancing maintains connection context in the absence of packet activity. See the idle (firewall farm TCP protocol) command for more details.
Step 16
(Optional) For firewall farm UDP protocol configuration mode, specifies the maximum number of active connections allowed on the firewall farm at one time. See the maxconns (firewall farm TCP protocol) command for more details.
Step 17
(Optional) For firewall farm UDP protocol configuration mode, specifies that connections from the same IP address use the same firewall if either of the following conditions is met:
•
•
See the sticky (firewall farm UDP protocol) command for more details.
Step 18
Enables the firewall farm for use by IOS SLB. See the inservice (firewall farm) command for more details.
Step 19
Router(config-slb-fw-real)# exitReturns to firewall farm configuration mode.
Step 20
Router(config-slb-fw)# endExits configuration mode.
Verifying the Firewall Farm
The following show ip slb reals command displays the status of firewall farm FIRE1, the associated real servers, and their status:
Router# show ip slb realreal farm name weight state conns--------------------------------------------------------------------10.1.1.2 FIRE1 8 OPERATIONAL 010.1.2.2 FIRE1 8 OPERATIONAL 0The following show ip slb firewallfarm command displays the configuration and status of firewall farm FIRE1:
Router# show ip slb firewallfarmfirewall farm hash state reals------------------------------------------------FIRE1 IPADDR INSERVICE 2Verifying Firewall Connectivity
To verify that IOS SLB firewall load balancing has been configured and is operating correctly:
Step 1
Step 2
Step 3
Router# show ip slb statsPkts via normal switching: 0Pkts via special switching: 0Connections Created: 1911871Connections Established: 1967754Connections Destroyed: 1313251Connections Reassigned: 0Zombie Count: 0Connections Reused: 59752Connection Flowcache Purges:1776582Failed Connection Allocs: 17945Failed Real Assignments: 0Normal switching is when IOS SLB packets are handled on normal IOS switching paths (CEF, fastswitching, and process level switching). Special switching is when IOS SLB packets are handled on hardware-assisted switching paths.
Step 4
Router# show ip slb real detail10.1.1.3, FIRE1, state = OPERATIONAL, type = firewallconns = 299310, dummy_conns = 0, maxconns = 4294967295weight = 10, weight(admin) = 10, metric = 104, remainder = 2total conns established = 1074779, hash count = 4646server failures = 0interface FastEthernet1/0, MAC 0010.f68f.7020Step 5
Router# show ip slb connsvserver prot client real state nat-------------------------------------------------------------------------------FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneFirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB noneStep 6
Configuring HTTP Probes
HTTP probes verify connectivity for devices being server load-balanced, and for firewalls being firewall load-balanced. For a detailed description of HTTP probes, see the "Probes" section.
To configure an HTTP probe, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the IOS SLB probe name and changes to HTTP probe configuration submode. See the ip slb probe (HTTP probe) command for more details.
Step 2
(Optional) Configures an IP address to which to send the HTTP probe. See the address (HTTP probe) command for more details.
Step 3
(Optional) Configures header values for the HTTP probe. See the credentials command for more details.
Step 4
(Optional) Configures the expected HTTP status code or regular expression. See the expect command for more details.
Step 5
(Optional) Configures header values for the HTTP probe. See the header command for more details.
Step 6
(Optional) Configures the HTTP probe transmit timers. See the interval (HTTP probe) command for more details.
Step 7
(Optional) Configures the port to which the HTTP probe is to connect. See the port (HTTP probe) command for more details.
Step 8
(Optional) Configures the URL path to request from the server, and the method used to perform the request to the server. See the request method, request url command for more details.
Step 9
Router(config-slb-probe)# exitReturns to global configuration mode.
Step 10
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode. See the ip slb serverfarm command for more details.
or
Adds a firewall farm definition to the IOS SLB configuration and initiates firewall farm configuration mode. See the ip slb firewallfarm command for more details.
Step 11
Identifies a real server as a member of a server farm and initiates real server configuration mode. See the real (server farm) command for more details.
or
Identifies a firewall as a member of a firewall farm and initiates real server configuration mode. See the real (firewall farm) command for more details.
Step 12
Specifies an HTTP probe on the real server. See the probe (server farm) command for more details.
or
Specifies an HTTP probe on the real server. See the probe (firewall farm real server) command for more details.
Step 13
Router(config-slb-real)# endorRouter(config-slb-fw-real)# endExits configuration mode.
In addition, HTTP probes require a route to the virtual server. The route is not used, but it must exist to enable the sockets code to verify that the destination can be reached, which in turn is essential for HTTP probes to function correctly. The route can be either a host route (advertised by the virtual server) or a default route (specified using the ip route 0.0.0.0 0.0.0.0 command, for example).
To verify that the HTTP probe is configured correctly, use the following show ip slb probe command:
Router# show ip slb probeServer:Port State Outages Current Cumulative----------------------------------------------------------------10.1.1.1:80 OPERATIONAL 0 never 00:00:0010.1.1.2:80 OPERATIONAL 0 never 00:00:0010.1.1.3:80 OPERATIONAL 0 never 00:00:00Configuring Ping Probes
Ping probes verify connectivity for devices being server load-balanced, and for firewalls being firewall load-balanced. For a detailed description of ping probes, see the "Probes" section.
To configure a ping probe, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the IOS SLB probe name and changes to ping probe configuration submode. See the ip slb probe (ping probe) command for more details.
Step 2
(Optional) Configures an IP address to which to send the ping probe. See the address (ping probe) command for more details.
Step 3
(Optional) Specifies the number of consecutive unacknowledged pings that constitute failure of the real server or firewall. See the faildetect (ping probe) command for more details.
Step 4
(Optional) Configures the ping probe transmit timers. See the interval (ping probe) command for more details.
Step 5
Router(config-slb-probe)# exitReturns to global configuration mode.
Step 6
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode. See the ip slb serverfarm command for more details.
or
Adds a firewall farm definition to the IOS SLB configuration and initiates firewall farm configuration mode. See the ip slb firewallfarm command for more details.
Step 7
Identifies a real server as a member of a server farm and initiates real server configuration mode. See the real (server farm) command for more details.
or
Identifies a firewall as a member of a firewall farm and initiates real server configuration mode. See the real (firewall farm) command for more details.
Step 8
Specifies a ping probe on the real server. See the probe (server farm) command for more details.
or
Specifies a ping probe on the firewall. See the probe (firewall farm real server) command for more details.
Step 9
Router(config-slb-real)# endorRouter(config-slb-fw-real)# endExits configuration mode.
To verify that the ping probe is configured correctly, use the following show ip slb probe command:
Router# show ip slb probeServer:Port State Outages Current Cumulative----------------------------------------------------------------13.13.13.13:80 OPERATIONAL 0 never 00:00:00Configuring WSP Probes
WSP probes detect failures in the WAP stack on port 9201. For a detailed description of WSP probes, see the "Probes" section.
To configure a WSP probe, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the IOS SLB probe name and changes to WSP probe configuration submode. See the ip slb probe (WSP probe) command for more details.
Step 2
(Optional) Configures an IP address to which to send the WSP probe. See the address (WSP probe) command for more details.
Step 3
(Optional) Configures the WSP probe transmit timers. See the interval (WSP probe) command for more details.
Step 4
(Optional) Configures the WSP probe URL path. See the url (WSP probe) command for more details.
Step 5
Router(config-slb-probe)# exitReturns to global configuration mode.
Step 6
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode. See the ip slb serverfarm command for more details.
Step 7
Identifies a real server as a member of a server farm and initiates real server configuration mode. See the real (server farm) command for more details.
Step 8
Specifies a WSP probe on the real server. See the probe (server farm) command for more details.
Step 9
Router(config-slb-real)# endExits configuration mode.
To verify that the WSP probe is configured correctly, use the following show ip slb probe command:
Router# show ip slb probeServer:Port State Outages Current Cumulative----------------------------------------------------------------10.1.1.13:80 OPERATIONAL 0 never 00:00:00Configuring IOS SLB Dynamic Feedback Protocol
The IOS SLB Dynamic Feedback Protocol (DFP) enables DFP agents to report relative weights for real host servers to DFP managers. The DFP managers factor in the weights when load balancing the real servers.
The weights calculated by DFP override the static weights you define using the weight (server farm) command. If DFP is removed from the network, IOS SLB reverts to the static weights.
See the following sections for more details about configuring DFP:
•
•
Note
Configuring IOS SLB as a DFP Manager
To identify a DFP agent with which IOS SLB can initiate connections, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures DFP, supplies an optional password, and initiates DFP configuration mode. See the ip slb dfp command for more details.
Step 2
Identifies a DFP agent to which IOS SLB can connect. See the agent command for more details.
Use the following commands to:
•
•
Router(config)# ip slb dfp password Cookies 360Router(config-slb-dfp)# agent 10.1.1.1 2221 30 0 10Configuring a Client Subsystem as a DFP Agent
To define the port number to be used by the DFP manager to connect to the IOS SLB DFP agent to receive DFP reports, enter the following commands in order, beginning in global configuration mode:
Step 1
Identifies a DFP agent subsystem and initiates DFP agent configuration mode. See the ip dfp agent command for more details.
Step 2
Router(config-dfp)# interval seconds(Optional) Configures a DFP agent weight recalculation interval. See the interval (DFP agent) command for more details.
Step 3
(Optional) Configures a DFP agent password for MD5 authentication. See the password command for more details.
Step 4
Defines the port number to be used by the DFP manager to connect to the DFP agent. See the port (DFP agent) command for more details.
Step 5
Enables the DFP agent for communication with a DFP manager. See the inservice (DFP agent) command for more details.
Use the following commands to:
•
•
•
•
•
Router(config)# ip dfp agent slbRouter(config-dfp)# interval 11Router(config-dfp)# password Cookies 180Router(config-dfp)# port 2221Router(config-dfp)# inserviceConfiguring IOS SLB NAT
Cisco Network Address Translation (NAT), RFC 1631, allows unregistered "private" IP addresses to connect to the Internet by translating them into globally registered IP addresses. NAT also increases network privacy by hiding internal IP addresses from external networks. For a detailed description of NAT and the difference between "client" and "server" mode, see the "Network Address Translation (NAT) and Session Redirection" section.
To configure IOS SLB NAT for client mode, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the client address pool.
Step 2
Configures which NAT mode to use. See the nat command for more details.
The following commands configure a NAT server on server farm PUBLIC:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# nat serverTo configure IOS SLB NAT client mode for a specific server farm, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the client address pool.
Step 2
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode. See the ip slb serverfarm command for more details.
Step 3
Configures which NAT mode to use. See the nat command for more details.
Step 4
Router(config-slb-sfarm)# real ip-address [port_number]Identifies a real server as a member of a server farm and initiates real server configuration mode. See the real (server farm) command for more details.
Step 5
Enables the real server for use by IOS SLB. See the inservice (server farm real server) command for more details.
Step 6
Router(config-slb-real)# exitReturns to server farm configuration mode.
Step 7
Router(config-slb-real)# endReturns to global configuration mode.
Step 8
Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details.
Implementing IOS SLB Stateless Backup
Stateless backup, based on the Hot Standby Router Protocol (HSRP), provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of any single Layer 3 switch. Stateless backup is particularly useful for hosts that do not support a router discovery protocol (such as the Intermediate System-to-Intermediate System [IS-IS] Interdomain Routing Protocol [IDRP]) and do not have the functionality to shift to a new Layer 3 switch when their selected Layer 3 switch reloads or loses power.
This section discusses the following topics in detail:
•
•
•
•
How IOS SLB Stateless Backup Works
A Layer 3 switch running the HSRP detects a failure by sending and receiving multicast User Datagram Protocol (UDP) hello packets. When the IOS SLB switch running HSRP detects that the designated active Layer 3 switch has failed, the selected backup Layer 3 switch assumes control of the HSRP group MAC and IP addresses. (You can also select a new standby Layer 3 switch at that time.) Both the primary and the backup Layer 3 switch must be on the same subnet.
The chosen MAC and IP addresses must be unique and must not conflict with any others on the same network segment. The MAC address is selected from a pool of Cisco MAC addresses. Configure the last byte of the MAC address by using the HSRP group number. When the HSRP is running, it selects an active Layer 3 switch and instructs its device layer to listen on an additional (dummy) MAC address.
IOS SLB switching software supports HSRP over 10/100 Ethernet, Gigabit Ethernet, FEC, GEC, and BVI (Bridge-Group Virtual Interface) connections.
HSRP uses a priority scheme to determine which HSRP-configured Layer 3 switch is to be the default active Layer 3 switch. To configure a Layer 3 switch as active, you assign it a priority higher than that of all other HSRP-configured Layer 3 switches. The default priority is 100, so if you configure just one Layer 3 switch to have a higher priority, that switch becomes the default active switch.
HSRP works by the exchange of multicast messages that advertise priority among HSRP-configured Layer 3 switches. When the active switch fails to send a hello message within a configurable period, the standby switch with the highest priority becomes the active switch. The transition of packet-forwarding functions between Layer 3 switches is completely transparent to all hosts accessing the network.
HSRP-configured Layer 3 switches exchange the following types of multicast messages:
•
•
•
At any time, HSRP-configured Layer 3 switches are in one of the following states:
•
•
•
•
Configuring IOS SLB Stateless Backup
Configuring stateless backup requires the following:
•
•
To configure stateless backup over VLANs between IOS SLB switches, perform the following tasks in order:
Step 1
Note
For firewall load balancing, configure the firewall farms—See the "Configuring IOS SLB Firewall Load Balancing" section.
Note
Step 2
Step 3
Step 4
Step 5
Step 6
A sample stateless backup configuration is shown in the "Sample IOS SLB Stateless Backup Configuration" section.
Enabling HSRP
To enable HSRP on an IOS SLB interface, enable the protocol, then customize it for the interface. Enter the following command in interface configuration mode:
Customizing Group Attributes
To customize "hot standby" group attributes, use one or more of the following commands in interface configuration mode:
Verifying the IOS SLB Stateless Backup Configuration
For server load balancing, to verify that stateless backup has been configured and is operating correctly, use the following show ip slb vserver commands to display information about the IOS SLB virtual server status:
Router# show ip slb vserverslb vserver prot virtual state conns-------------------------------------------------------------------VS1 TCP 10.10.10.12:23 OPERATIONAL 2VS2 TCP 10.10.10.18:23 OPERATIONAL 2Router# show ip slb vserver detailVS1, state = OPERATIONAL, v_index = 10virtual = 10.10.10.12:23, TCP, service = NONE, advertise = TRUEserver farm = SERVERGROUP1, delay = 10, idle = 3600sticky timer = 0, sticky subnet = 255.255.255.255sticky group id = 0synguard counter = 0, synguard period = 0conns = 0, total conns = 0, syns = 0, syn drops = 0standby group = NoneVS2, state = INSERVICE, v_index = 11virtual = 10.10.10.18:23, TCP, service = NONE, advertise = TRUEserver farm = SERVERGROUP2, delay = 10, idle = 3600sticky timer = 0, sticky subnet = 255.255.255.255sticky group id = 0synguard counter = 0, synguard period = 0conns = 0, total conns = 0, syns = 0, syn drops = 0standby group = NoneFor firewall load balancing, to verify that stateless backup has been configured and is operating correctly, use the following show ip slb firewallfarm commands to display information about the IOS SLB firewall farm status:
Router# show ip slb firewallfarmfirewall farm hash state reals------------------------------------------------FIRE1 IPADDR INSERVICE 2Router# show ip slb firewallfarm detailsFIRE1, hash = IPADDRPORT, state = INSERVICE, reals = 2FirewallTCP:sticky timer = 0, sticky subnet = 255.255.255.255idle = 3600, delay = 10, syns = 1965732, syn drop = 0maxconns = 4294967295, conns = 597445, total conns = 1909512FirewallUDP:sticky timer = 0, sticky subnet = 255.255.255.255idle = 3600maxconns = 1, conns = 0, total conns = 1Real firewalls:10.1.1.3, weight = 10, OPERATIONAL, conns = 29882310.1.1.4, weight = 10, OPERATIONAL, conns = 298622Total connections = 597445Sample IOS SLB Stateless Backup Configuration
The following commands enable the HSRP standby group 100 IP address, priority, preempt, timers, configure a name and authentication for Device A in Figure 9:
Router(config-if)# standby 100 ip 172.20.100.10Router(config-if)# standby 100 priority 110Router(config-if)# standby 100 preempt delay sync 20Router(config-if)# standby 100 timers 5 15Router(config-if)# standby 100 name Web-group1Router(config-if)# standby 100 authentication SecretRouter(config-if)# exitRouter#Configuring IOS SLB Stateful Backup
Stateful backup enables IOS SLB to incrementally back up its load-balancing decisions, or "keep state," between primary and backup switches. The backup switch has its virtual servers in a dormant state until HSRP detects failover; then the backup (now primary) switch begins advertising virtual addresses and filtering flows. You can use HSRP to configure how quickly the failover is detected.
This enhancement 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.
Configuring Stateful Backup for Server Load Balancing
To configure stateful backup to keep state across primary and backup Layer 3 switches in a server load-balancing environment, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures a virtual server and initiates virtual server configuration mode.
Step 2
Configures a stateful backup of IOS SLB decision tables to a backup switch. See the replicate casa (virtual server) command for more details.
The following commands configure stateful backup for virtual server RESTRICTED_HTTP using listening IP 10.10.3.132 and remote IP 10.10.99.3 over port 1032 and configures the password as PASS for Device A in Figure 14:
Router(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# virtual 10.10.10.12 tcp telnetRouter(config-slb-vserver)# replicate casa 10.10.3.132 10.10.99.3 1032 password PASSRouter(config-slb-vserver)# inservice standby virtRouter(config-slb-vserver)#.(Information Deleted)Configuring Stateful Backup for Firewall Load Balancing
To configure stateful backup to keep state across primary and backup Layer 3 switches in a firewall load-balancing environment, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures a firewall farm and initiates firewall farm configuration mode.
Step 2
Configures a stateful backup of IOS SLB decision tables to a backup switch. See the replicate casa (firewall farm) command for more details.
Monitoring and Maintaining the IOS SLB Feature
To obtain and display runtime information about IOS SLB, use the following commands in EXEC mode:
Displays information about DFP agents. See the show ip dfp command for more details.
Displays all connections handled by IOS SLB, or, optionally, only those connections associated with a particular virtual server or client. See the show ip slb conns command for more details.
Displays information about DFP and DFP agents, and about the weights assigned to real servers. See the show ip slb dfp command for more details.
Displays information about firewall farms. See the show ip slb firewallfarm command for more details.
Displays information about the IOS SLB NAT configuration. See the show ip slb natpool command for more details.
Displays information about HTTP and ping probes defined to IOS SLB. See the show ip slb probe command for more details.
Displays information about the real servers defined to IOS SLB. See the show ip slb reals command for more details.
Router# show ip slb replicateDisplays information about the IOS SLB replication configuration. See the show ip slb replicate command for more details.
Displays information about the server farms defined to IOS SLB. See the show ip slb serverfarms command for more details.
Displays IOS SLB statistics. See the show ip slb stats command for more details.
Displays information about the sticky connections defined to IOS SLB. See the show ip slb sticky command for more details.
Displays information about the virtual servers defined to IOS SLB. See the show ip slb vserver command for more details.
Configuration Examples
This section provides real-world examples of IOS SLB configurations and includes the following sections:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
Complete Example Configuration
The following example provides a complete configuration using the commands described in this feature module:
Router# show running-configBuilding configuration...Current configuration:!.(Information Deleted).ip slb probe PROBE2 httprequest method POST url /probe.cgi?allheader Cookie Monsterheader Authorization Basic U2VtaXN3ZWV0OmNoaXBz!ip slb serverfarm PUBLICnat serverreal 10.1.1.1reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.2reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.3reassign 4faildetect numconns 16retry 120inserviceprobe PROBE2!ip slb serverfarm RESTRICTEDpredictor leastconnsbindid 309real 10.1.1.1weight 32maxconns 1000reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.20reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.21reassign 4faildetect numconns 16retry 120inservice!ip slb vserver PUBLIC_HTTPvirtual 10.0.0.1 tcp wwwserverfarm PUBLICno inservice!ip slb vserver RESTRICTED_HTTPvirtual 10.0.0.2 tcp wwwserverfarm RESTRICTEDno advertisesticky 60 group 1idle 120delay 5client 10.4.4.0 255.255.255.0synguard 3600000inservice!Example of a Layer 3 Switch with ISL, VLAN, and BVI with GEC
This example configuration focuses on both the Inter-Switch Link (ISL) and virtual LANs (VLANs), and on integrated routing and bridging (IRB) using a bridge-group virtual interface (BVI) over Gigabit EtherChannel (GEC). The Cisco proprietary ISL allows any Fast Ethernet port to be configured as a trunk. The Spanning-Tree Protocol detects and breaks loops on all the VLANs carried across the trunk.
The Gigabit Ethernet interface information applies to both two-port and eight-port Gigabit Ethernet interfaces for a Catalyst 8540 campus Layer 3 switch. This example also includes port snooping and Network Time Protocol (NTP) configurations.
!ip subnet-zerono ip domain-lookupip name-server 171.69.2.132ip name-server 198.92.30.32ip multicast-routingip dvmrp route-limit 20000bridge irb!interface FastEthernet1no ip addressno ip directed-broadcastno keepalive!interface FastEthernet1.128ip address 172.68.16.10 255.255.255.0ip helper-address 172.68.16.15no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1encapsulation isl 128!interface FastEthernet1.199ip address 172.68.17.15 255.255.255.0ip helper-address 172.68.16.16ip helper-address 172.68.16.17ip helper-address 172.68.16.18no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1encapsulation isl 199!interface FastEthernet1.201ip address 172.68.18.10 255.255.255.0ip helper-address 172.68.16.16ip helper-address 172.68.16.17ip helper-address 172.68.16.18no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1encapsulation isl 201!interface FastEthernet2no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet3no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet4no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet5no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet6no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet7no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet8no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet9ip address 172.68.19.10 255.255.255.0ip helper-address 172.68.16.16ip helper-address 172.68.16.17ip helper-address 172.68.16.18no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1ip sdr listenno keepalive!interface FastEthernet10no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet11no ip addressno ip directed-broadcastno keepaliveshutdown!.(Information Deleted).interface GigabitEthernet41snoop interface FastEthernet3 direction bothsnoop interface FastEthernet5 direction bothsnoop interface FastEthernet6 direction bothip address 172.68.21.10 255.255.255.0ip helper-address 172.68.16.19ip helper-address 172.68.16.20ip helper-address 172.68.16.21!interface GigabitEthernet42ip address 172.68.1.1 255.255.255.0no ip directed-broadcastip pim sparse-dense-mode!interface BVI1ip address 171.201.1.2 255.255.255.0no ip directed-broadcastip pim dense-modeno ip route-cache cef!interface Ethernet0ip address 172.68.20.10 255.255.255.0no ip directed-broadcast!router eigrp 170network 171.200.0.0network 171.201.0.0network 172.68.0.0network 172.69.0.0no auto-summary!router bgp 180network 172.68.1.0network 172.69.1.0no auto-summary!ip classless!bridge 1 protocol ieeebridge 1 route ip!ip http server!line con 0line aux 0line vty 0 4login!ntp clock-period 17181168ntp update-calendarntp server 171.71.150.52ntp server 171.69.4.143ntp server 171.69.5.10endExample of IOS SLB with Firewall Load Balancing
Figure 3 shows a sample IOS SLB firewall load-balancing network with the following components:
•
•
•
•
Figure 3 IOS SLB with Layer 3 Firewalls in Different Subnets
When you configure IOS SLB firewall load balancing, the load-balancing devices use route lookup to recognize flows destined for the firewalls. To enable route lookup, you must configure each device with the IP address of each firewall that will route flows to that device.
In the following firewall farm configuration samples:
•
•
Internal Firewall Load-Balancing Device
The following commands configure ping probe PROBE1, HTTP probe PROBE2, and firewall farm FIRE1, and associate the two real servers for the load-balancing device on the internal (secure) side of the firewall:
Router(config)# ip slb probe PROBE1 ping ; Ping probeRouter(config-slb-probe)# address 10.1.1.1 ; IP address of other load-balancing deviceRouter(config-slb-probe)# faildetect 4Router(config-slb-probe)# ip slb probe PROBE2 http ; HTTP probeRouter(config-slb-probe)# address 10.1.2.1 ; IP address of other load-balancing deviceRouter(config-slb-probe)# expect status 401Router(config-slb-probe)# ip slb firewallfarm FIRE1 ; Firewall farm FIRE1Router(config-slb-fw)# real 10.1.4.1 ; First firewallRouter(config-slb-fw-real)# probe PROBE1Router(config-slb-fw-real)# inservice ; Enable first firewallRouter(config-slb-fw-real)# real 10.1.3.1 ; Second firewallRouter(config-slb-fw-real)# probe PROBE2Router(config-slb-fw-real)# inservice ; Enable second firewallRouter(config-slb-fw-real)# exitRouter(config-slb-fw)# inservice ; Turn on firewall load-balancing deviceExternal Firewall Load-Balancing Device
The following commands configure ping probe PROBE1, HTTP probe PROBE2, and firewall farm FIRE1, and associate the two real servers for the load-balancing device on the external (Internet) side of the firewall:
Router(config)# ip slb probe PROBE1 ping ; Ping probeRouter(config-slb-probe)# address 10.1.4.2 ; IP address of other load-balancing deviceRouter(config-slb-probe)# faildetect 4Router(config-slb-probe)# ip slb probe PROBE2 http ; HTTP probeRouter(config-slb-probe)# address 10.1.3.2 ; IP address of other load-balancing deviceRouter(config-slb-probe)# expect status 401Router(config-slb-probe)# ip slb firewallfarm FIRE1 ; Firewall farm FIRE1Router(config-slb-fw)# real 10.1.1.2 ; First firewallRouter(config-slb-fw-real)# probe PROBE1Router(config-slb-fw-real)# inservice ; Enable first firewallRouter(config-slb-fw-real)# real 10.1.2.2 ; Second firewallRouter(config-slb-fw-real)# probe PROBE2Router(config-slb-fw-real)# inservice ; Enable second firewallRouter(config-slb-fw-real)# exitRouter(config-slb-fw)# inservice ; Turn on firewall load-balancing deviceExample of IOS SLB with Server Load Balancing and Firewall Load Balancing
Figure 4 shows a sample IOS SLB load-balancing network with server load balancing and firewall load balancing running together, and the following components:
•
•
•
•
•
•
Figure 4 IOS SLB with Server Load Balancing and Firewall Load Balancing
In the following firewall farm configuration samples:
•
•
Internal Server and Firewall Load-Balancing Device
The following example shows the configuration for ping probes ABCPROBE and XYZPROBE, firewall farm FIRE1, and server farm PUBLIC for the load-balancing device on the internal (secure) side of the firewalls:
ip slb probe ABCPROBE pingaddress 10.1.1.1ip slb probe XYZPROBE pingaddress 10.1.2.1!ip slb firewallfarm FIRE1real 10.1.4.1probe ABCPROBEinservicereal 10.1.3.1probe XYZPROBEinserviceinservice!ip slb serverfarm PUBLICnat serverreal 10.2.1.1inservicereal 10.2.1.2inservicereal 10.2.1.2inservice!ip slb vserver HTTP1virtual 128.1.0.1 tcp wwwserverfarm PUBLICidle 120delay 5inserviceExternal Firewall Load-Balancing Device
The following example shows the configuration for ping probes ABCPROBE and XYZPROBE and firewall farm FIRE1 for the load-balancing device on the external (Internet) side of the firewalls:
ip slb probe ABCPROBE pingaddress 10.1.4.2ip slb probe XYZPROBE pingaddress 10.1.3.2ip slb firewallfarm FIRE1real 10.1.1.2probe ABCPROBEinserviceprobe XYZPROBEinserviceinserviceExample of IOS SLB with Multiple Firewall Farms
Figure 5 shows a sample IOS SLB load-balancing network with multiple firewall farms and the following components:
•
•
•
•
•
Figure 5 IOS SLB with Multiple Firewall Farms
In the following firewall farm configuration samples:
•
•
Internal Firewall Load-Balancing Device
The following commands configure ping probes ABCPROBE and XYZPROBE and firewall farms ABCFARM and XYZFARM for the load-balancing device on the internal (secure) side of the firewalls:
Router(config)# ip slb probe ABCPROBE pingRouter(config-slb-probe)# address 10.1.2.1Router(config-slb-probe)# ip slb probe XYZPROBE pingRouter(config-slb-probe)# address 10.1.1.1Router(config-slb-probe)# ip slb firewallfarm ABCFARMRouter(config-slb-fw)# access source 10.1.6.0 255.255.255.0Router(config-slb-fw)# inserviceRouter(config-slb-fw)# real 10.1.4.2Router(config-slb-fw-real)# probe ABCPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# real 10.1.4.3Router(config-slb-fw-real)# probe ABCPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# ip slb firewallfarm XYZFARMRouter(config-slb-fw)# access source 10.1.5.0 255.255.255.0Router(config-slb-fw)# inserviceRouter(config-slb-fw)# real 10.1.3.2Router(config-slb-fw-real)# probe XYZPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# real 10.1.3.3Router(config-slb-fw-real)# probe XYZPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# exitRouter(config-slb-fw)# inserviceExternal Firewall Load-Balancing Device
The following commands configure ping probes ABCPROBE and XYZPROBE and firewall farms ABCFARM and XYZFARM for the load-balancing device on the external (Internet) side of the firewalls:
Router(config)# ip slb probe ABCPROBE pingRouter(config-slb-probe)# address 10.1.4.1Router(config-slb-probe)# ip slb probe XYZPROBE pingRouter(config-slb-probe)# address 10.1.3.1Router(config-slb-probe)# ip slb firewallfarm ABCFARMRouter(config-slb-fw)# access destination 10.1.6.0 255.255.255.0Router(config-slb-fw)# inserviceRouter(config-slb-fw)# real 10.1.2.2Router(config-slb-fw-real)# probe ABCPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# real 10.1.2.3Router(config-slb-fw-real)# probe ABCPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# ip slb firewallfarm XYZFARMRouter(config-slb-fw)# access destination 10.1.5.0 255.255.255.0Router(config-slb-fw)# inserviceRouter(config-slb-fw)# real 10.1.1.2Router(config-slb-fw-real)# probe XYZPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# real 10.1.1.3Router(config-slb-fw-real)# probe XYZPROBERouter(config-slb-fw-real)# inserviceRouter(config-slb-fw-real)# exitRouter(config-slb-fw)# inserviceExample of IOS SLB with Probes
Figure 6 shows an example configuration with IOS SLB real server connections configured as part of a server farm, focusing on using ping and HTTP probes to monitor applications being server load-balanced.
Figure 6 Sample Ping and HTTP Probe Topology
:
The topology shown in Figure 6 is a heterogeneous server farm servicing a single virtual server. Following are the configuration statements for this topology, including a ping probe named PROBE1 and an HTTP probe named PROBE2:
! Configure ping probe PROBE1, change CLI to IOS SLB probe configuration modeRouter(config)# ip slb probe PROBE1 ping! Configure probe to receive responses from IP address 13.13.13.13Router(config-slb-probe)# address 13.13.13.13! Configure unacknowledged ping threshold to 16Router(config-slb-probe)# faildetect 16! Configure ping probe timer interval to transmit every 11 secondsRouter(config-slb-probe)# interval 11! Configure HTTP probe PROBE2Router(config-slb-probe)# ip slb probe PROBE2 http! Configure request method as POST, set URL as /probe.cgi?allRouter(config-slb-probe)# request method post url /probe.cgi?all! Configure header CookieRouter(config-slb-probe)# header Cookie Monster! Configure basic authentication username and passwordRouter(config-slb-probe)# credentials Semisweet chips! Exit to global configuration modeRouter(config-slb-probe)# exit! Enter IOS SLB server farm configuration mode for server farm PUBLICRouter(config)# ip slb serverfarm PUBLIC! Configure NAT server and real servers on the server farmRouter(config-slb-sfarm)# nat serverRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.1.1.2Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.1.1.3Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.1.1.4Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.1.1.5Router(config-slb-sfarm)# inservice! Configure ping probe on the server farmRouter(config-slb-sfarm)# probe PROBE1! Configure HTTP probe on the server farmRouter(config-slb-sfarm)# probe PROBE2Router(config-slb-sfarm)# endExample of a Layer 3 Switch Configured with IOS SLB
Figure 7 shows an example configuration with IOS SLB server connections configured as part of a server farm, using real and virtual servers over Fast Ethernet interfaces.
Figure 7 Network Configuration for IOS SLB
As shown in the following sample configuration, the example topology has three public web servers and two restricted web servers for privileged clients in subnet 10.4.4.x. The public web servers are weighted according to their capacity, with server 10.1.1.2 having the lowest capacity and having a connection limit imposed on it. The restricted web servers are configured as members of the same sticky group, so that HTTP connections and Secure Socket Layer (SSL) connections from the same client use the same real server.
The network configuration to provide the previously described IOS SLB functionality follows:
! Unrestricted web server farmip slb serverfarm PUBLIC! Use weighted least connections algorithmpredictor leastconns! First real serverreal 10.1.1.1weight 16reassign 2faildetect numconns 4retry 20inservice! Second real serverreal 10.1.1.2weight 4! Restrict maximum number of connectionsmaxconns 1000reassign 2faildetect numconns 4retry 20inservice! Third real serverreal 10.1.1.3weight 24reassign 2faildetect numconns 4retry 20inservice! Restricted web server farmip slb serverfarm RESTRICTED! Use weighted least connections algorithmpredictor leastconns! First real serverreal 10.1.1.20reassign 2faildetect numconns 4retry 20inservice! Second real serverreal 10.1.1.21reassign 2faildetect numconns 4retry 20inservice!! Unrestricted web virtual serverip slb vserver PUBLIC_HTTP! Handle HTTP requestsvirtual 10.0.0.1 tcp www! Use public web server farmserverfarm PUBLICidle 120delay 5inservice!! Restricted HTTP virtual serverip slb vserver RESTRICTED_HTTP! Handle HTTP requestsvirtual 10.0.0.1 tcp www! Use restricted web server farmserverfarm RESTRICTED! Only allow clients from 10.4.4.xclient 10.4.4.0 255.255.255.0! Couple connections with RESTRICTED_SSLsticky 60 group 1idle 120delay 5inservice!! Restricted SSL virtual serverip slb vserver RESTRICTED_SSL! Handle SSL requestsvirtual 10.0.0.1 tcp https! Use restricted web server farmserverfarm RESTRICTED! Only allow clients from 10.4.4.xclient 10.4.4.0 255.255.255.0! Couple connections with RESTRICTED_WEBsticky 60 group 1idle 120delay 5inserviceExample of IOS SLB with NAT
Figure 8 shows an example configuration with IOS SLB real server connections configured as part of a server farm, focusing on the configuration of the NAT server and address pool of clients.
Figure 8 Sample IOS SLB NAT Topology
The topology in Figure 8 has four web servers, configured as follows:
•
•
Server 1 and Server 2 are load-balanced using Switch A, which is performing server address translation.
Server 3 and Server 4 are load-balanced using Switch B and Switch C. These two switches are performing both server and client address translation since there are multiple paths between the clients and the servers. These switches also must perform server port translation for HTTP packets to and from Server 4.
Switch A Configuration Statements
ip slb serverfarm FARM1! Translate server addressesnat server! Server 1 port 80real 10.1.1.1reassign 2faildetect numconns 4 numclients 2retry 20inservice! Server 2 port 80real 10.2.1.1reassign 2faildetect numconns 4retry 20inservice!ip slb vserver HTTP1! Handle HTTP (port 80) requestsvirtual 128.1.0.1 tcp wwwserverfarm FARM1idle 120delay 5inserviceSwitch B Configuration Statements
ip slb natpool web-clients 128.3.0.1 128.3.0.254! NAT address pool for clientsip slb serverfarm FARM2! Translate server addressesnat server! Translate client addressesnat client web-clients! Server 3 port 80real 10.3.1.1reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8080real 10.4.1.1 port 8080reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8081real 10.4.1.1 port 8081reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8082real 10.4.1.1 port 8082reassign 2faildetect numconns 4retry 20inservice!ip slb vserver HTTP2! Handle HTTP (port 80) requestsvirtual 128.2.0.1 tcp wwwserverfarm FARM2idle 120delay 5inserviceSwitch C Configuration Statements
ip slb natpool web-clients 128.5.0.1 128.5.0.254! NAT address pool for clientsip slb serverfarm FARM2! Translate server addressesnat server! Translate client addressesnat client web-clients! Server 3 port 80real 10.3.1.1reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8080real 10.4.1.1 port 8080reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8081real 10.4.1.1 port 8081reassign 2faildetect numconns 4retry 20inservice! Server 4 port 8082real 10.4.1.1 port 8082reassign 2faildetect numconns 4retry 20inservice!ip slb vserver HTTP2! Handle HTTP (port 80) requestsvirtual 128.4.0.1 tcp wwwserverfarm FARM2idle 120delay 5inserviceExample of an IOS Layer 3 Switch with HSRP
This example configuration for an IOS Layer 3 switch focuses on the HSRP, which provides high network availability. HSRP makes network topology changes transparent to the host. The active router is monitored by other standby routers, and as soon as an active router becomes unavailable, the standby router takes its place. Helper addresses facilitate connectivity by forwarding certain broadcasts to a target server.
Figure 9 shows the topology of an IP network with two Layer 3 switches configured for HSRP.
Figure 9 HSRP Example Network Topology
In this network:
•
•
•
•
Note
If the connection between Device A and the client accessing virtual server IP address 10.10.10.12 tcp 23 or 10.10.10.18 tcp 23 fails, fast-converging routing protocols, such as OSPF and the Enhanced Interior Gateway Routing Protocol (Enhanced IGRP), can respond within seconds, ensuring that Device B is prepared to transfer packets that would have gone through Device A.
Device A (Active) Configuration Statements
hostname Device A!ip slb serverfarm ServerGroup1real 172.20.100.3inservicereal 172.20.100.4inservice!ip slb serverfarm ServerGroup2real 172.20.200.3inservicereal 172.20.200.4inservice!ip slb vserver VS1virtual 10.10.10.12 tcp 23serverfarm ServerGroup1in-service standby Web-Group1!ip slb vserver VS2virtual 10.10.10.18 tcp 23serverfarm ServerGroup2in-service standby Web-Group2!ip routingrouter ripnetwork 172.20.0.0!interface vlan100ip address 172.20.100.1 255.255.255.0standby 100 ip 172.20.100.10standby 100 priority 110standby 100 preempt delay sync 20standby 100 timers 5 15standby 100 name Web-Group1standby 100 authentication Secret!interface vlan200ip address 172.20.200.1 255.255.255.0standby 200 ip 172.20.200.10standby 200 priority 110standby 200 preempt delay sync 20standby 200 timers 5 15standby 200 name Web-Group2standby 200 authentication Covert!Device B (Standby) Configuration Statements
hostname Device B!ip slb serverfarm ServerGroup1real 172.20.100.3inservicereal 172.20.100.4inservice!ip slb serverfarm ServerGroup2real 172.20.200.3inservicereal 172.20.200.4inservice!ip slb vserver VS1virtual 10.10.10.12 tcp 23serverfarm ServerGroup1in-service standby Web-Group1!ip slb vserver VS2virtual 10.10.10.18 tcp 23serverfarm ServerGroup2in-service standby Web-Group2!ip routingrouter ripnetwork 172.20.0.0!interface vlan100ip address 172.20.100.2 255.255.255.0standby 100 ip 172.20.100.10standby 100 preempt delay sync 20standby 100 timers 5 15standby 100 name Web-Group1standby 100 authentication Secret!interface vlan200ip address 172.20.200.2 255.255.255.0standby 200 ip 172.20.200.10standby 200 preempt delay sync 20standby 200 timers 5 15standby 200 name Web-Group2standby 200 authentication CovertDescription of Configuration
The standby ip interface configuration command enables HSRP and establishes 10.10.10.12 and 10.10.10.18 as the IP addresses of the virtual servers. The configurations of both Layer 3 switches include this command so that both switches share the same virtual IP address. The numbers 100 and 200 establish Hot Standby groups 100 and 200. (If you do not specify a group number, the default is group 0.) The numbers 100 and 200 in the following commands indicate that they apply to Hot Standby groups 100 and 200, respectively. The configuration for at least one of the Layer 3 switches in the Hot Standby group must specify the IP address of the virtual server; specifying the IP address of the virtual router is optional for other routers in the same Hot Standby group.
The standby preempt interface configuration command allows the Layer 3 switch to become the active switch when its priority is higher than all other HSRP-configured switches in this Hot Standby group. The configurations of both switches include this command so that each can be the standby Layer 3 switch for the other switch. If you do not use the standby preempt command in the configuration for a Layer 3 switch, that switch cannot become the active Layer 3 switch.
The standby priority interface configuration command sets the Layer 3 switch's HSRP priority to 110, which is higher than the default priority of 100. Only the configuration of Device A includes this command, which makes Device A the default active Layer 3 switch.
The standby timers interface configuration command sets the interval (in seconds) between hello messages (called the hello time) to 5 seconds, and sets the interval (in seconds) that a Layer 3 switch waits before it declares the active Layer 3 switch to be down (called the hold time) to 8 seconds. (The defaults are 3 seconds and 10 seconds, respectively.) To modify the default values, you must configure each Layer 3 switch to use the same hello time and hold time.
The standby name interface configuration command associates the IOS SLB interface with an HSRP group name (in this case, Web-Group1 or Web-Group2), previously specified on an inservice (server farm virtual server) command.
The standby authentication interface configuration command establishes an authentication string whose value is an unencrypted eight-character string that is incorporated in each HSRP multicast message. This command is optional. If you choose to use it, each HSRP-configured Layer 3 switch in the group should use the same string so that each switch can authenticate the source of the HSRP messages that it receives.
Examples of IOS SLB with Stateless Backup
There are several different ways in which you can configure IOS SLB stateless backup. The differences between the configurations depend on the networking capabilities of your load balancing devices, and on the capabilities of the distribution devices that direct client traffic to those load balancing devices.
•
•
•
•
•
This section contains the following examples, illustrating several different IOS SLB stateless backup configurations:
•
•
•
•
Note
Example with Dynamic Routing and Trunking
Figure 10 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
•
Figure 10 Stateless Backup with Layer 3 and Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4 numclients 2retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Eth1switchportswitchport vlan 1int Eth2ip address 10.10.2.1 255.255.255.0int vlan 1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track Eth2router eigrp 666redistribute staticnetwork 10.0.0.0SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Gig1no ip addressswitchportswitchport trunk encapsulation islint Eth1switchportswitchport vlan 1int Eth2ip address 10.10.3.1 255.255.255.0int vlan 1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERrouter eigrp 666redistribute staticnetwork 10.0.0.0Example with Dynamic Routing and No Trunking
Figure 11 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
Figure 11 Stateless Backup with Layer 3 and No Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Eth1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track Eth2int Eth2ip address 10.10.2.1 255.255.255.0router eigrp 666redistribute staticnetwork 10.0.0.0SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Eth1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERint Eth2ip address 10.10.3.1 255.255.255.0router eigrp 666redistribute staticnetwork 10.0.0.0Example with Static Routing and Trunking
Figure 12 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
•
Figure 12 Stateless Backup with Layer 2 and Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Eth1switchportswitchport vlan 1int Eth2ip address 10.10.2.1 255.255.255.0standby ip 10.10.2.100standby priority 10 preempt delay sync 20standby track vlan1int vlan 1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track Eth2SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Gig1no ip addressswitchportswitchport trunk encapsulation islint Eth1switchportswitchport vlan 1int Eth2ip address 10.10.2.2 255.255.255.0standby ip 10.10.2.100standby priority 5 preempt delay sync 20int vlan 1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERDistribution Device Configuration Statements
int Eth1switchportswitchport distribution vlan 2int Eth2switchportswitchport distribution vlan 2int vlan2ip address 10.10.2.3 255.255.255.0no shutip route 10.10.14.1 255.255.255.255 10.10.2.100Example with Static Routing and No Trunking
Figure 13 shows a sample IOS SLB stateless backup configuration with the following characteristics:
•
•
•
•
•
Figure 13 Stateless Backup with Layer 2 and No Trunking
SLB 1 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Eth1ip address 10.10.1.1 255.255.255.0standby ip 10.10.1.100standby priority 10 preempt delay sync 20standby name SERVERstandby track eth2int Eth2ip address 10.10.2.1 255.255.255.0standby ip 10.10.2.100standby priority 10 preempt delay sync 20standby track eth1SLB 2 Configuration Statements
ip slb serverfarm SF1real 10.10.1.3reassign 2faildetect numconns 4retry 20inservicereal 10.10.1.4reassign 2faildetect numconns 4retry 20inserviceip slb vserver VS1virtual 10.10.14.1 tcp wwwserverfarm SF1idle 120delay 5inservice standby SERVER...int Eth1ip address 10.10.1.2 255.255.255.0standby ip 10.10.1.100standby priority 5 preempt delay sync 20standby name SERVERint Eth2ip address 10.10.2.2 255.255.255.0standby ip 10.10.2.100standby priority 5 preempt delay sync 20Distribution Device Configuration Statements
int Eth1switchportswitchport distribution vlan 2int Eth2switchportswitchport distribution vlan 2int vlan2ip address 10.10.2.3 255.255.255.0no shutip route 10.10.14.1 255.255.255.255 10.10.2.100Example of IOS SLB with Stateful Backup
This example configuration focuses on the IOS SLB real server connections configured as part of a server farm, with real and virtual servers over Fast Ethernet interfaces configured with stateful backup standby connections.
Figure 14 is an example of a stateful backup configuration, using HSRP on both the client and server sides to handle failover. The real servers route outbound flows to 10.10.3.100, which is the HSRP address on the server side interfaces. The client (or access router), routes to the virtual IP address (10.10.10.12) through 10.10.2.100, HSRP address on the client side.
Notice the loopback interfaces configured on both boxes for the exchange of these messages. Each IOS SLB should also be given duplicate routes to the other switch loopback address. This allows replication messages to flow despite an interface failure.
Note
Figure 14 IOS SLB Stateful Environment
Switch SLB1 Configuration Statements
ip slb serverfarm SF1nat serverreal 10.10.3.1inservicereal 10.10.3.2inservicereal 10.10.3.3inservice!ip slb vserver VS1virtual 10.10.10.12 tcp telnetserverfarm SF1replicate casa 10.10.99.132 10.10.99.99 1024 password PASSinservice standby virt!interface Loopback1ip address 10.10.99.132 255.255.255.255!interface FastEthernet1ip address 10.10.3.132 255.255.255.0no ip redirectsno ip mroute-cachestandby priority 5 preempt delay sync 20standby name outstandby ip 10.10.3.100standby track FastEthernet2!interface FastEthernet2ip address 10.10.2.132 255.255.255.0no ip redirectsstandby priority 5 preempt delay sync 20standby name virtstandby ip 10.10.2.100standby track FastEthernet1Switch SLB2 Configuration Statements
ip slb serverfarm SF1nat serverreal 10.10.3.1inservicereal 10.10.3.2inservicereal 10.10.3.3inservice!ip slb vserver VS1virtual 10.10.10.12 tcp telnetserverfarm SF1replicate casa 10.10.99.99 10.10.99.132 1024 password PASSinservice standby virt!interface Loopback1ip address 10.10.99.99 255.255.255.255!interface FastEthernet2ip address 10.10.2.99 255.255.255.0no ip redirectsno ip route-cacheno ip mroute-cachestandby priority 10 preempt delay sync 20standby name virtstandby ip 10.10.2.100standby track FastEthernet3!interface FastEthernet3ip address 10.10.3.99 255.255.255.0no ip redirectsno ip route-cacheno ip mroute-cachestandby priority 10 preempt delay sync 20standby name outstandby ip 10.10.3.100standby track FastEthernet2Example of IOS SLB with Active Standby
Figure 15 shows an IOS SLB network configured for active standby, with two IOS SLB devices load-balancing the same virtual IP address while backing up each other. If either device fails, the other takes over its load via normal HSRP failover and IOS SLB stateless redundancy.
Figure 15 IOS SLB Active Standby
The sample network configuration in Figure 15 has the following characteristics:
•
•
•
•
•
•
SLB 1 Configuration Statements
ip slb serverfarm EVENnat serverreal 10.10.3.2reassign 2faildetect numconns 4 numclients 2retry 20inservicereal 10.10.3.3reassign 2faildetect numconns 4retry 20inservice!ip slb serverfarm ODDnat serverreal 10.10.3.2reassign 2faildetect numconns 4retry 20inservicereal 10.10.3.3reassign 2faildetect numconns 4retry 20inservice!ip slb vserver EVEN ; Same EVEN virtual server as in SLB 2virtual 10.10.10.12 tcp wwwserverfarm EVENclient 0.0.0.0 0.0.0.1idle 120delay 5inservice standby STANDBY_EVEN ; See standby name in Ethernet 3/3 below!ip slb vserver ODD ; Same ODD virtual server as in SLB 2virtual 10.10.10.12 tcp wwwserverfarm ODDclient 0.0.0.1 0.0.0.1idle 120delay 5inservice standby STANDBY_ODD ; See standby name in Ethernet 3/2 below!interface Ethernet3/2ip address 10.10.5.132 255.255.255.0standby priority 20 preempt delay sync 20standby name STANDBY_ODD ; See standby name in SLB 2, Ethernet 3/5standby ip 10.10.5.100!interface Ethernet3/3ip address 10.10.2.132 255.255.255.0standby priority 10standby name STANDBY_EVEN ; See standby name in SLB 2, Ethernet 3/1standby ip 10.10.2.100SLB 2 Configuration Statements
ip slb serverfarm EVENnat serverreal 10.10.3.4reassign 2faildetect numconns 4retry 20inservicereal 10.10.3.5reassign 2faildetect numconns 4retry 20inservice!ip slb serverfarm ODDnat serverreal 10.10.3.4reassign 2faildetect numconns 4retry 20inservicereal 10.10.3.5reassign 2faildetect numconns 4retry 20inservice!ip slb vserver EVEN ; Same EVEN virtual server as in SLB 1virtual 10.10.10.12 tcp wwwserverfarm EVENclient 0.0.0.0 0.0.0.1idle 120delay 5inservice standby STANDBY_EVEN ; See standby name in Ethernet 3/1 below!ip slb vserver ODD ; Same ODD virtual server as in SLB 1virtual 10.10.10.12 tcp wwwserverfarm ODDclient 0.0.0.1 0.0.0.1idle 120delay 5inservice standby STANDBY_ODD ; See standby name in Ethernet 3/5 below!interface Ethernet3/1ip address 10.10.2.128 255.255.255.0standby priority 20 preempt delay sync 20standby name STANDBY_EVEN ; See standby name in SLB 1, Ethernet 3/3standby ip 10.10.2.100!interface Ethernet3/5ip address 10.10.5.128 255.255.255.0standby priority 10 preempt delay sync 20standby name STANDBY_ODD ; See standby name in SLB 1, Ethernet 3/2standby ip 10.10.5.100Access Router Configuration Statements
interface Ethernet0/0ip address 10.10.5.183 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cache!interface Ethernet0/1ip address 10.10.2.183 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cache!interface Ethernet0/2ip address 10.10.6.183 255.255.255.0no ip directed-broadcastno ip route-cacheno ip mroute-cacheip policy route-map virts!access-list 100 permit ip 0.0.0.1 255.255.255.254 host 10.10.10.12access-list 101 permit ip 0.0.0.0 255.255.255.254 host 10.10.10.12route-map virts permit 10match ip address 100set ip next-hop 10.10.5.100!route-map virts permit 15match ip address 101set ip next-hop 10.10.2.100!Example of IOS SLB with Redistribution of Static Routes
Figure 16 shows an IOS SLB network configured to distribute static routes to a virtual server's IP address. The route to the address is added to the routing table as static if you advertise the address when you bring the virtual server into service (using the inservice command). See the advertise command for more details about advertising virtual server IP addresses.
Because the routing configuration varies from protocol to protocol, sample configurations for several different routing protocols are given.
Figure 16 IOS SLB Redistribution of Static Routes
Routing Information Protocol (RIP)
Following is the RIP static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router ripredistribute staticnetwork 10.0.0.0network 8.0.0.0Following is the RIP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router ripnetwork 10.0.0.0network 8.0.0.0Open Shortest Path First (OSPF)
Following is the OSPF static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router ospf 1redistribute static subnetsnetwork 10.10.6.217 0.0.0.0 area 0network 8.8.8.0 0.0.0.255 area 0Following is the OSPF static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router ospf 1network 10.10.6.2 0.0.0.0 area 0network 8.8.8.0 0.0.0.255 area 0Interior Gateway Routing Protocol (IGRP)
Following is the IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router igrp 1redistribute connectedredistribute staticnetwork 8.0.0.0network 10.0.0.0Following is the IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router igrp 1network 8.0.0.0network 10.0.0.0Enhanced Interior Gateway Routing Protocol (Enhanced IGRP)
Following is the Enhanced IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 16:
router eigrp 666redistribute staticnetwork 10.0.0.0network 8.0.0.0Following is the Enhanced IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 16:
router eigrp 666network 10.0.0.0network 8.0.0.0Examples of IOS SLB with WAP Load Balancing
Figure 17 shows an IOS SLB network configured to balance WAP flows. In this example:
•
•
•
Figure 17 IOS SLB with WAP Load Balancing
There are two ways to configure IOS SLB load balancing for WAP:
•
•
Example with WAP Load Balancing
The following commands configure the IOS SLB device shown in Figure 17 to balance WAP flows on UDP port 9201 (WSP/WTP/UDP):
Router(config)# ip slb probe PROBE3 wspRouter(config-slb-probe)# url http://localhost/test.txt!Router(config)# ip slb serverfarm WAPFARMRouter(config-slb-sfarm)# nat serverRouter(config-slb-sfarm)# real 10.10.2.1Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.10.2.2Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.10.2.3Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# probe PROBE3!Router(config)# ip slb vserver VSERVERRouter(config-slb-vserver)# virtual 10.10.1.1 udp 9201Router(config-slb-vserver)# serverfarm WAPFARMRouter(config-slb-vserver)# idle 3000Router(config-slb-vserver)# inserviceExample with UDP Load Balancing
The following commands configure the IOS SLB device shown in Figure 17 to balance WAP flows on UDP port 9203 (WSP/WTP/WTLS/UDP):
Router(config)# ip slb probe PROBE1 ping!Router(config)# ip slb serverfarm WAPFARMRouter(config-slb-sfarm)# nat serverRouter(config-slb-sfarm)# real 10.10.2.1Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.10.2.2Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.10.2.3Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# probe PROBE1!Router(config)# ip slb vserver VSERVERRouter(config-slb-vserver)# virtual 10.10.1.1 udp 9203Router(config-slb-vserver)# serverfarm WAPFARMRouter(config-slb-vserver)# idle 3000Router(config-slb-vserver)# inserviceExamples of IOS SLB with Route Health Injection
This section contains the following examples, illustrating several different IOS SLB route health injection configurations:
•
•
•
Example with Two Distributed Sites with One Web Server Each
Figure 18 shows an IOS SLB network configured with route health injection with the following characteristics:
•
•
•
Figure 18 Two Distributed Sites with One Web Server Each
When both web servers in Figure 18 are operational, the client router receives the host route from both IOS SLB devices.
If Web Server A fails, the virtual server for the virtual IP address on SLB A enters FAILED state and stops advertising the host route for the virtual IP address. The client router then begins using the route to SLB B.
When Web Server A is again available, the virtual server again advertises the host route for the virtual IP address, and the client router begins using SLB A.
Example with Two Distributed Sites with Two Web Servers Each
Figure 19 shows an IOS SLB network configured with route health injection with the following characteristics:
•
•
•
Figure 19 Two Distributed Sites with Two Web Servers Each
When all web servers in Figure 19 are operational, the client router receives the host route from both IOS SLB devices.
If one web server in either server farm fails, the route continues to be advertised by the given IOS SLB device.
If both Web Server A1 and Web Server A2 fail, the virtual server for the virtual IP address on SLB A enters FAILED state and stops advertising the host route for the virtual IP address. The client router then begins using the route to SLB B.
When either Web Server A1 or Web Server A2 is again available, the virtual server again advertises the host route for the virtual IP address, and the client router begins using SLB A.
Example with Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each
Figure 20 shows an IOS SLB network configured with route health injection with the following characteristics:
•
•
•
•
Figure 20 Two Distributed Sites with One Web Server and a Backup IOS SLB Switch Each
When both web servers in Figure 20 are operational, the client router receives the host route from both SLB A Primary and SLB B Primary.
If SLB A Primary fails, SLB A Backup begins advertising the host route to the virtual IP address. If SLB A Backup also fails, the virtual server for the virtual IP address on SLB A Primary and SLB A Backup enters FAILED state and stops advertising the host route for the virtual IP address. The client router then begins using the route to SLB B Primary (or to SLB B Backup, if SLB B Primary is not available).
When either SLB A Primary or SLB A Backup is again available, the virtual server again advertises the host route for the virtual IP address, and the client router begins using SLB A Primary or SLB A Backup.
Example of IOS SLB with Sticky Connections
The following sample configuration assigns all HTTP connections from a subnet to the same real server in server farm PUBLIC:
Router(config)# ip slb vserver httpRouter(config-slb-vserver)# serverfarm PUBLICRouter(config-slb-vserver)# sticky 30 group 1 netmask 255.255.255.248Router(config-slb-vserver)# virtual 20.20.20.20 tcp 80Router(config-slb-vserver)# inserviceThe following sample configuration adds HTTPS connections to the above configuration, using the same sticky information but with a different virtual server:
Router(config)# ip slb vserver httpsRouter(config-slb-vserver)# serverfarm PUBLICRouter(config-slb-vserver)# sticky 30 group 1 netmask 255.255.255.248Router(config-slb-vserver)# virtual 20.20.20.20 tcp 443Router(config-slb-vserver)# inserviceNow, all HTTP and HTTPS connections from the subnet are assigned to the same real server. For example, if a user connects to HTTP, then a second user connects to HTTPS, both connections are assigned to the same real server.
Command Reference
This section documents only new and modified commands.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
access
To route specific flows to a firewall farm, use the access firewall farm configuration command. To restore the default settings, use the no form of this command.
access [source source-ip-address network-mask] [destination destination-ip-address network-mask]
no access [source source-ip-address network-mask] [destination destination-ip-address network-mask]
Syntax Description
Defaults
The default source IP address is 0.0.0.0 (route flows from all sources to this firewall farm).
The default source IP network mask is 0.0.0.0 (route flows from all source subnets to this firewall farm).
The default destination IP address is 0.0.0.0 (route flows from all destinations to this firewall farm).
The default destination IP network mask is 0.0.0.0 (route flows from all destination subnets to this firewall farm).
Command Modes
Firewall farm configuration
Command History
Usage Guidelines
You can specify more than one source or destination for each firewall farm. To do so, configure multiple access statements, making sure the network masks do not overlap each other.
Examples
The following example routes flows with a destination IP address of 10.1.6.0 to firewall farm FIRE1:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# access destination 10.1.6.0 255.255.255.0Related Commands
address (HTTP probe)
To configure an IP address to which to send HTTP probes, use the address HTTP probe configuration command. To restore the default settings, use the no form of this command.
address [ip-address]
no address [ip-address]
Syntax Description
Defaults
If the HTTP probe is associated with a firewall farm, you must specify an ip-address.
If the HTTP probe is associated with a server farm, and you do not specify an ip-address, the address is inherited from the server farm real servers.
Command Modes
HTTP probe configuration
Command History
Examples
The following example configures an HTTP probe named PROBE2, changes the CLI to IOS SLB HTTP probe submode, and configures the probe to receive responses from IP address 13.13.13.13:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)# address 13.13.13.13Related Commands
Configures an HTTP probe name and changes to HTTP probe configuration submode.
Displays information about an IOS SLB probe.
address (ping probe)
To configure an IP address to which to send ping probes, use the address ping probe configuration command. To restore the default settings, use the no form of this command.
address [ip-address]
no address [ip-address]
Syntax Description
Defaults
If the ping probe is associated with a firewall farm, you must specify an ip-address.
If the ping probe is associated with a server farm, and you do not specify an ip-address, the address is inherited from the server farm real servers.
Command Modes
Ping probe configuration
Command History
Examples
The following example configures a ping probe named PROBE1, changes the CLI to IOS SLB ping probe submode, and configures the probe to receive responses from IP address 13.13.13.13:
Router(config)# ip slb probe PROBE1 pingRouter(config-slb-probe)# address 13.13.13.13Related Commands
Configures a ping probe name and changes to ping probe configuration submode.
Displays information about an IOS SLB probe.
address (WSP probe)
To configure an IP address to which to send WSP probes, use the address WSP probe configuration command. To restore the default settings, use the no form of this command.
address [ip-address]
no address [ip-address]
Syntax Description
Defaults
If the WSP probe is associated with a firewall farm, you must specify an ip-address.
If the WSP probe is associated with a server farm, and you do not specify an ip-address, the address is inherited from the server farm real servers.
In dispatched mode, ip-address is the same as the virtual server IP address. In directed (NAT) mode, ip-address is unnecessary.
Command Modes
WSP probe configuration
Command History
Examples
The following example configures a ping probe named PROBE3, changes the CLI to IOS SLB WSP probe submode, and configures the probe to receive responses from IP address 13.13.13.13:
Router(config)# ip slb probe PROBE3 wspRouter(config-slb-probe)# address 13.13.13.13Related Commands
Configures a WSP probe name and changes to WSP probe configuration submode.
Displays information about an IOS SLB probe.
advertise
To control the installation of a static route to the Null0 interface for a virtual server address, use the advertise virtual server configuration command. To prevent the installation of a static route for the virtual server IP address, use the no form of this command.
advertise [active]
no advertise [active]
Syntax Description
Defaults
The virtual server IP address is advertised. That is, a static route to the Null0 interface is installed for the virtual server IP addresses and it is added to the routing table.
If you do not specify active, the host route is advertised regardless of whether the virtual IP address is available.
Command Modes
Virtual server configuration
Command History
Usage Guidelines
Advertisement of a static route using the routing protocol requires that you configure redistribution of static routes for the routing protocol.
The advertise command does not affect virtual servers used for transparent webcache load balancing.
HTTP probes and route health injection require a route to the virtual server. The route is not used, but it must exist in order for HTTP probes and route health injection to function correctly.
•
•
HTTP probes and route health injection can both use the same default route; you do not need to specify two unique default routes.
Examples
The following example prevents advertisement of the virtual server's IP address in routing protocol updates:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# no advertiseRelated Commands
agent
To identify a DFP agent with which IOS SLB can initiate connections, use the agent DFP configuration command. To remove a DFP agent definition from the DFP configuration, use the no form of this command.
agent ip-address port-number [timeout [retry_count [retry_interval]]]
no agent ip-address port
Syntax Description
Defaults
Timeout default: 0 seconds (no timeout)
Retry count default: 0 (infinite retries)
Retry interval default: 180 seconds
Command Modes
DFP configuration
Command History
Usage Guidelines
The password specified on the ip slb dfp command in the DFP manager must match the password specified on the password command in the DFP agent.
You can identify up to 1024 DFP agents.
Examples
The following example sets the DFP password to Cookies (to match the DFP agent's password), sets the timeout to 360 seconds, changes the CLI to DFP configuration mode, enables IOS SLB to connect to the DFP agent with IP address 10.1.1.1 and port number 2221, and sets a timeout of 30 seconds, an infinite number of retries, and a retry interval of 10 seconds:
Router(config)# ip slb dfp password Cookies 360Router(config-slb-dfp)# agent 10.1.1.1 2221 30 0 10Related Commands
bindid
To configure a bind ID, use the bindid server farm configuration command. To remove a bind ID from the server farm configuration, use the no form of this command.
bindid [bind_id]
no bindid [bind_id]
Syntax Description
Defaults
The default bind ID is 0.
Command Modes
Server farm configuration
Command History
Usage Guidelines
You can configure one bind ID on each bindid command.
The bind ID allows a single physical server to be bound to multiple virtual servers and report a different weight for each one. Thus, the single real server is represented as multiple instances of itself, each having a different bind ID. DFP uses the bind ID to identify for which instance of the real server a given weight is specified.
Examples
The following example configures bind ID 309:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# bindid 309Related Commands
Configures DFP, supplies an optional password, and initiates DFP configuration mode.
Displays information about the IOS SLB server farms.
clear ip slb
To clear IP IOS SLB connections or counters, use the clear ip slb command.
clear ip slb {connections [serverfarm farm_name | vserver server_name] | counters}
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example clears the connection database of server farm FARM1:
Router# clear ip slb connections serverfarm FARM1The following example clears the connection database of virtual server VSERVER1:
Router# clear ip slb connections vserver VSERVER1The following example clears the IOS SLB counters:
Router# clear ip slb countersRelated Commands
client (virtual server)
To define which clients are allowed to use the virtual server, use the client virtual server configuration command. You can use more than one client command to define more than one client. To remove a client definition from the IOS SLB configuration, use the no form of this command.
client ip-address network-mask
no client ip-address network-mask
Syntax Description
ip-address
Client IP address. The default is 0.0.0.0 (all clients).
network-mask
Client IP network mask. The default is 0.0.0.0 (all subnets).
Defaults
The default client IP address is 0.0.0.0 (all clients).
The default client IP network mask is 0.0.0.0 (all subnets).
Taken together, the default is client 0.0.0.0 0.0.0.0 (allows all clients on all subnets to use the virtual server).
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The network-mask value is applied to the source IP address of incoming connections. The result must match the ip-address value for the client to be allowed to use the virtual server.
Examples
The following example allows only clients from 10.4.4.x access to the virtual server:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# client 10.4.4.0 255.255.255.0Related Commands
Displays information about the virtual servers defined to IOS SLB.
Configures the virtual server attributes.
credentials
To configure basic authentication values for the HTTP IOS SLB probe, use the credentials HTTP probe configuration command. To remove a credentials configuration, use the no form of this command.
credentials username [password]
no credentials username [password]
Syntax Description
Defaults
No default behavior or values.
Command Modes
HTTP probe configuration
Command History
Examples
The following example configures an HTTP probe named PROBE2, changes the CLI to IOS SLB HTTP probe submode, sets the HTTP authentication to username lauren, and sets the password to develop:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)# credentials lauren developRelated Commands
delay (firewall farm TCP protocol)
To change the amount of time IOS SLB maintains TCP connection context after a connection has terminated, use the delay firewall farm TCP protocol configuration command. To restore the default delay timer, use the no form of this command.
delay duration
no delay
Syntax Description
duration
Delay timer duration in seconds. The valid range is 1 to 600 seconds. The default value is 10 seconds.
Defaults
Duration default: 10 seconds
Command Modes
Firewall farm TCP protocol configuration
Command History
Usage Guidelines
The delay timer allows out-of-sequence packets and final acknowledgments (ACKs) to be delivered after a TCP connection ends.
Do not set this value to zero (0).
If you are configuring a delay timer for HTTP flows, choose a low number such as 5 seconds as a starting point.
Examples
The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# tcpRouter(config-slb-fw-tcp)# delay 30Related Commands
Displays information about the firewall farm configuration.
Initiates TCP protocol configuration mode.
delay (virtual server)
To change the amount of time IOS SLB maintains TCP connection context after a connection has terminated, use the delay virtual server configuration command. To restore the default delay timer, use the no form of this command.
delay duration
no delay
Syntax Description
duration
Delay timer duration in seconds. The valid range is 1 to 600 seconds. The default value is 10 seconds.
Defaults
Duration default: 10 seconds
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The delay timer allows out-of-sequence packets and final acknowledgments (ACKs) to be delivered after a TCP connection ends.
Do not set this value to zero (0).
If you are configuring a delay timer for HTTP flows, choose a low number such as 5 seconds as a starting point.
Examples
The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# delay 30Related Commands
Displays information about the virtual servers defined to IOS SLB.
Configures the virtual server attributes.
expect
To configure a status code or regular expression to expect from the HTTP probe, use the expect HTTP probe configuration command. To restore the default settings, use the no form of this command.
expect [status status-code] [regex regular-expression]
no expect [status status-code] [regex regular-expression]
Syntax Description
Defaults
The default expected status code is 200.
There is no default expected regular expression.
Command Modes
HTTP probe configuration
Command History
12.1(2)E
This command was introduced.
12.1(3a)E
The regex keyword and regular-expression variable were added.
Usage Guidelines
The expect command configures the expected status code or regular expression to be received from the servers. A real server is considered to have failed and is taken out of service if any of the following events occurs:
•
•
•
For IOS SLB firewall load balancing, configure the HTTP probe to expect status code 40l.
Examples
The following example configures an HTTP probe named PROBE2 changes the CLI to HTTP submode, and configures the HTTP probe to expect the status code 40l and the regular expression Copyright:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)# expect status 401 regex CopyrightRelated Commands
Configures an HTTP probe name and changes to HTTP probe configuration submode.
Displays information about an IOS SLB probe.
faildetect (ping probe)
To specify the conditions that indicate a server failure, use the faildetect ping probe configuration command. To restore the default values that indicate a server failure, use the no form of this command.
faildetect number-of-pings
no faildetect
Syntax Description
number-of-pings
Number of consecutive unacknowledged pings allowed before a real server is considered to have failed. Valid range is 1 to 255. The default is 10 unacknowledged pings.
Defaults
The default value is 10 unacknowledged pings.
Command Modes
Ping probe configuration
Command History
Examples
In the following example the unacknowledged ping threshold is set to 16:
Router(config)# ip slb probe PROBE1 pingRouter(config-slb-probe)# faildetect 16Related Commands
faildetect (real server)
To specify the conditions that indicate a server failure, use the faildetect real server configuration command. To restore the default values that indicate a server failure, use the no form of this command.
faildetect numconns number-conns [numclients number-clients]
no faildetect
Syntax Description
Defaults
If you do not specify the faildetect command, the default value of the connection reassignment threshold is 8.
If you do not specify the numclients keyword, the default value of the unique client failure threshold is 2.
Command Modes
Real server configuration
Command History
Examples
In the following example the connection reassignment threshold is set to 16 and, because the number-clients keyword is not configured, the threshold for unique client connection failure is set to the default value 8. The real server is considered to have failed when 8 unique clients have had connection failures and there have been 16 connection reassignments.
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# faildetect numconns 16Related Commands
header
To configure the basic authentication values for the HTTP probe, use the header HTTP probe configuration command. To remove a header HTTP probe configuration, use the no form of this command.
header field-name [field-value]
no header field-name [field-value]
Syntax Description
field-name
Configures the name of the HTTP probe header. The character string is limited to 15 characters.
field-value
(Optional) Configures the value of the HTTP probe header.
Defaults
No default behavior or values, although the following headers are inserted in the request by default:
Accept: */*Connection: closeUser-Agent: cisco-slb-probe/1.0Host: virtual IP addressCommand Modes
HTTP probe configuration
Command History
Usage Guidelines
The header HTTP probe configuration command configures the name and value parameters of the header.
Note
Examples
The following example configures an HTTP probe named PROBE2, changes the CLI to HTTP submode, and configures the HTTP probe header name as Cookie and value as Monster:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)# header Cookie MonsterRelated Commands
Configures an HTTP probe name and changes to HTTP probe configuration submode.
Displays information about an IOS SLB probe.
idle (firewall farm TCP protocol)
To specify the minimum amount of time IOS SLB maintains connection information in the absence of packet activity, use the idle firewall farm TCP protocol configuration command. To restore the default idle duration value, use the no form of this command.
idle duration
no idle
Syntax Description
duration
Idle connection timer duration in seconds. Valid values range from 10 to 65535. The default is 3600 seconds (1 hour).
Defaults
Duration default: 3600 seconds
Command Modes
Firewall farm TCP protocol configuration
Command History
Usage Guidelines
If a client sends a TCP packet that is not a sequence number (SYN) or reset (RST) packet, and IOS SLB does not have a TCP connection object in its table (possibly due to expiration of the idle timer), IOS SLB sends a TCP RST to the client.
If you are configuring an idle timer for HTTP flows, choose a low number such as 120 seconds as a starting point. A low number ensures that the IOS SLB connection database maintains a manageable size if problems at the server, client, or network result in a large number of connections. However, do not choose a value under 60 seconds; such a low value can reduce the efficiency of IOS SLB.
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# tcpRouter(config-slb-fw-tcp)# idle 120Related Commands
Displays information about the firewall farm configuration.
Initiates TCP protocol configuration mode.
idle (firewall farm UDP protocol)
To specify the minimum amount of time IOS SLB maintains connection information in the absence of packet activity, use the idle firewall farm UDP protocol configuration command. To restore the default idle duration value, use the no form of this command.
idle duration
no idle
Syntax Description
duration
Idle connection timer duration in seconds. Valid values range from 10 to 65535. The default is 3600 seconds (1 hour).
Defaults
Duration default: 3600 seconds
Command Modes
Firewall farm UDP protocol configuration
Command History
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# udpRouter(config-slb-fw-udp)# idle 120Related Commands
Displays information about the firewall farm configuration.
Initiates UDP protocol configuration mode.
idle (virtual server)
To specify the minimum amount of time IOS SLB maintains connection information in the absence of packet activity, use the idle virtual server configuration command. To restore the default idle duration value, use the no form of this command.
idle duration
no idle
Syntax Description
duration
Idle connection timer duration in seconds. Valid values range from 10 to 65535. The default is 3600 seconds (1 hour).
Defaults
The default idle duration is 3600 seconds.
Command Modes
Virtual server configuration
Command History
Usage Guidelines
If a client sends a TCP packet that is not a sequence number (SYN) or reset (RST) packet, and IOS SLB does not have a TCP connection object in its table (possibly due to expiration of the idle timer), IOS SLB sends a TCP RST to the client.
If you are configuring an idle timer for HTTP flows, choose a low number such as 120 seconds as a starting point. A low number ensures that the IOS SLB connection database maintains a manageable size if problems at the server, client, or network result in a large number of connections. However, do not choose a value under 60 seconds; such a low value can reduce the efficiency of IOS SLB.
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# idle 120Related Commands
Displays information about the virtual servers defined to IOS SLB.
Configures the virtual server attributes.
inservice (DFP agent)
To enable the DFP agent for communication with a DFP manager, use the inservice DFP agent configuration command. To remove the DFP agent from service, use the no form of this command.
inservice
no inservice
Syntax Description
This command has no arguments or keywords.
Defaults
If the inservice command is not specified, the DFP agent is inactive.
Command Modes
DFP agent configuration
Command History
Usage Guidelines
A DFP agent is inactive until both of the following conditions are met:
•
•
When you use the no form of this command to remove a DFP agent from service, the DFP agent closes all open connections, and no new connections are assigned.
Examples
In the following example, the DFP agent is enabled for communication with a DFP manager:
Router(config)# ip dfp agent slbRouter(config-dfp)# inserviceRelated Commands
inservice (firewall farm)
To enable the firewall farm for use by IOS SLB, use the inservice firewall farm configuration command. To remove the firewall farm from service, use the no form of this command.
inservice [standby group-name]
no inservice [standby group-name]
Syntax Description
Defaults
If the inservice command is not specified, the firewall farm is defined to IOS SLB but is not used.
Command Modes
Firewall farm configuration
Command History
Usage Guidelines
When you use the no form of this command to remove a firewall farm from service, the firewall farm quiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.
Examples
In the following example, the firewall farm is enabled for use by the IOS SLB feature:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# inserviceRelated Commands
Identifies a firewall farm and initiates firewall farm configuration mode.
Displays information about the firewall farm configuration.
inservice (firewall farm real server)
To enable the firewall for use by IOS SLB, use the inservice firewall farm real server configuration command. To remove the firewall from service, use the no form of this command.
inservice
no inservice
Syntax Description
This command has no arguments or keywords.
Defaults
If the inservice command is not specified, the firewall is defined to IOS SLB but is not used.
Command Modes
Firewall farm real server configuration
Command History
Usage Guidelines
IOS SLB firewall load balancing uses probes to detect failures. Therefore, if you have not configured a probe, the firewall is not placed in service.
When you use the no form of this command to remove a firewall from service, the firewall quiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.
Examples
In the following example, the firewall is enabled for use by the IOS SLB feature:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# real 10.10.1.1Router(config-slb-fw-real)# inserviceRelated Commands
inservice (server farm real server)
To enable the real server for use by IOS SLB, use the inservice server farm real server configuration command. To remove the real server from service, use the no form of this command.
inservice
no inservice
Syntax Description
This command has no arguments or keywords.
Defaults
If the inservice command is not specified, the real server is defined to IOS SLB but is not used.
Command Modes
Server farm real server configuration
Command History
Usage Guidelines
When you use the no form of this command to remove a real server from service, the real server quiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.
Examples
In the following example, the real server is enabled for use by the IOS SLB feature:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-sfarm-real)# inserviceRelated Commands
inservice (server farm virtual server)
To enable the virtual server for use by IOS SLB, use the inservice server farm virtual server configuration command. To remove the virtual server from service, use the no form of this command.
inservice [standby group-name]
no inservice [standby group-name]
Syntax Description
Defaults
If the inservice command is not specified, the virtual server is defined to IOS SLB but is not used.
Command Modes
Server farm virtual server configuration
Command History
12.0(7)XE
This command was introduced.
12.1(1)E
The standby keyword and group-name variable were added.
Usage Guidelines
When you use the no form of this command to remove a virtual server from service, the virtual server quiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.
Examples
In the following example, the virtual server is enabled for use by the IOS SLB feature:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# inserviceRelated Commands
Displays information about the virtual servers defined to IOS SLB.
Configures the virtual server attributes.
interval (DFP agent)
To configure a DFP agent weight recalculation interval, use the interval DFP agent configuration command. To restore the default setting, use the no form of this command.
interval seconds
no interval seconds
Syntax Description
seconds
Specifies the number of seconds to wait before recalculating weights for the DFP manager. Valid values range from 5 to 65535 seconds. The default interval is 10 seconds.
Defaults
The default interval value is 10 seconds.
Command Modes
DFP agent configuration
Command History
Usage Guidelines
The DFP agent sends the new weight to the DFP manager only if the new weight is different from the old weight. If the new weight is the same as the old weight, it is not sent to the DFP manager.
Examples
The following example configures the DFP agent to recalculate weights every 11 seconds:
Router(config)# ip dfp agent slbRouter(config-dfp)# interval 11Related Commands
interval (HTTP probe)
To configure an HTTP probe interval, use the interval HTTP probe configuration command. To remove an HTTP probe interval configuration, use the no form of this command.
interval seconds
no interval seconds
Syntax Description
seconds
Designates the number of seconds to wait before reattempting the probe. Valid values range from 1-65535 seconds. The default interval is 8 seconds.
Defaults
The default interval value is 8 seconds.
Command Modes
HTTP probe configuration
Command History
Examples
The following example configures an HTTP probe named PROBE2, changes the CLI to HTTP submode, and configures the HTTP probe timer interval to transmit every 11 seconds:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)# interval 11Related Commands
Configures an HTTP probe name and changes to HTTP probe configuration submode.
Displays information about an IOS SLB probe.
interval (ping probe)
To configure a ping probe interval, use the interval ping probe configuration command. To remove a ping probe interval configuration, use the no form of this command.
interval seconds
no interval seconds
Syntax Description
seconds
Designates the number of seconds to wait before reattempting the probe. Valid values range from 1-65535 seconds. The default interval is 1 second.
Defaults
The default interval value is 1 second.
Command Modes
Ping probe configuration
Command History
Examples
The following example configures a ping probe named PROBE1, changes the CLI to ping submode, and configures the ping probe timer interval to transmit every 11 seconds:
Router(config)# ip slb probe PROBE1 pingRouter(config-slb-probe)# interval 11Related Commands
Configures a ping probe name and changes to ping probe configuration submode.
Displays information about an IOS SLB probe.
interval (WSP probe)
To configure a WSP probe interval, use the interval WSP probe configuration command. To remove a WSP probe interval configuration, use the no form of this command.
interval seconds
no interval seconds
Syntax Description
seconds
Designates the number of seconds to wait before reattempting the probe. Valid values range from 1-65535 seconds. The default interval is 8 seconds.
Defaults
The default interval value is 8 seconds.
Command Modes
WSP probe configuration
Command History
Examples
The following example configures a ping probe named PROBE3, changes the CLI to WSP probe submode, and configures the WSP probe timer interval to transmit every 11 seconds:
Router(config)# ip slb probe PROBE3 wspRouter(config-slb-probe)# interval 11Related Commands
Configures a WSP probe name and changes to WSP probe configuration submode.
Displays information about an IOS SLB probe.
ip dfp agent
To identify a DFP agent subsystem and initiate DFP agent configuration mode, use the ip dfp agent global configuration command. To remove the DFP agent identification, use the no form of this command.
ip dfp agent subsystem-name
no ip dfp agent subsystem-name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
To discover the subsystem names that are available in your environment, enter the following command:
ip dfp agent ?
Examples
The following example identifies a DFP agent subsystem named slb:
Router(config)# ip dfp agent slbRouter(config-dfp)#?Related Commands
Identifies a DFP agent to which IOS SLB can connect.
Configures DFP, supplies an optional password, and initiates DFP configuration mode.
ip slb dfp
To configure DFP, supply an optional password, and initiate DFP configuration mode, use the ip slb dfp global configuration command. To remove the DFP configuration, use the no form of this command.
ip slb dfp [password [0 | 7] password [timeout]]
no ip slb dfp
Syntax Description
Defaults
The password encryption default is 0 (unencrypted).
The password timeout default is 180 seconds, if a password is specified.
Command Modes
Global configuration
Command History
12.0(7)XE
This command was introduced.
12.1(3a)E
The 0 and 7 keywords were added.
Usage Guidelines
The password specified on the ip slb dfp command in the DFP manager must match the password specified on the password command in the DFP agent.
The timeout option allows you to change the password without stopping messages between the DFP agent and its manager. The default value is 180 seconds.
During the timeout, the agent sends packets with the old password (or null, if there is no old password), and receives packets with either the old or new password. After the timeout expires, the agent sends and receives packets only with the new password; received packets that use the old password are discarded.
If you are changing the password for an entire load-balanced environment, set a longer timeout. This allows enough time for you to update the password on all agents and servers before the timeout expires. It also prevents mismatches between agents and servers that have begun running the new password and agents, and servers on which you have not yet changed the old password.
Examples
The following example configures DFP, sets the DFP password to Cookies and the timeout to 360 seconds, and changes the CLI to DFP configuration mode:
Router(config)# ip slb dfp password Cookies 360Router(config-slb-dfp)#Related Commands
Identifies a DFP agent to which IOS SLB can connect.
Identifies a DFP agent subsystem and initiates DFP agent configuration mode.
ip slb entries
To configure an initial allocation and a maximum value for IOS SLB database entries, use the ip slb entries global configuration command. To restore the default values, use the no form of this command.
ip slb entries [conn [init-conn [max-conn]] | frag [init-frag [max-frag]] | sticky [init-sticky [max-sticky]]]
no ip slb entries [conn | frag | sticky]
Syntax Description
Defaults
For connections, the default initial allocation is 8000 connections, and the default maximum is 8000000 connections.
For fragments, the default initial allocation is 4000 fragments, and the default maximum is 8000000 fragments.
For sticky connections, the default initial allocation is 2000 sticky connections, and the default maximum is 3200 sticky connections.
Command Modes
Global configuration
Command History
Usage Guidelines
If you configure an initial allocation value that exceeds the amount of available memory, memory might not be available for other features. In extreme cases, the router or switch might not boot properly. Therefore, be careful when you configure initial allocation values.
Examples
The following example configures an initial allocation of 128,000 connections, which can grow dynamically to a limit of 512,000 connections:
Router(config)# ip slb entries conn 128000 512000Related Commands
Displays all connections handled by IOS SLB, or, optionally, only those connections associated with a particular virtual server or client.
ip slb firewallfarm
To identify a firewall farm and initiate firewall farm configuration mode, use the ip slb firewallfarm global configuration command. To remove the firewall farm from the IOS SLB configuration, use the no form of this command.
ip slb firewallfarm firewallfarm-name
no ip slb firewallfarm firewallfarm-name
Syntax Description
firewallfarm-name
Character string used to identify the firewall farm. The character string is limited to 15 characters.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Grouping real servers into firewall farms is an essential part of IOS SLB firewall load balancing. Using firewall farms enables IOS SLB to assign new connections to the real servers based on their weighted capacities, and on the load-balancing algorithms used.
Examples
The following example identifies a firewall farm named FIRE1:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)#?Related Commands
Identifies a firewall as a member of a firewall farm and initiates real server configuration mode.
ip slb natpool
To configure an IOS SLB NAT, use the ip slb natpool configuration command to create at least one client address pool. To remove an ip slb natpool configuration, use the no form of this command.
ip slb natpool pool-name start-ip end-ip [netmask netmask | prefix-length leading_1_bits] [entries init-addr [max-addr]]
no ip slb natpool pool-name
Syntax Description
Defaults
The default initial allocation is 8000 client NAT address entries.
The default maximum number of client NAT address entries that can be allocated is the maximum number of ports that can be allocated within the IP address range.
Command Modes
Global configuration
Command History
Usage Guidelines
If you want to use client NAT, you must create at least one client address pool.
Examples
The following example configures an IOS SLB NAT server farm pool of addresses with the name web-clients, the IP address range from 128.3.0.1 through 128.3.0.254, and a subnet mask of 255.255.0.0:
Router(config)# ip slb natpool web-clients 128.3.0.1 128.3.0.254 netmask 255.255.0.0Related Commands
Displays information about the IOS SLB NAT configuration.
Displays information about the server farm configuration.
ip slb probe (HTTP probe)
To configure an HTTP probe name and to change to HTTP probe configuration submode, use the ip slb probe (HTTP probe) configuration command. To remove an ip slb probe configuration, use the no form of this command.
ip slb probe name http
no ip slb probe name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
This command configures the HTTP probe name and application protocol, and changes the user interface to HTTP submode.
The HTTP probe cannot be unconfigured while it is being used by the server farm or firewall farm.
You can configure more than one probe, in any combination of types (HTTP, ping, or WSP), for each server farm, or for each firewall in a firewall farm.
Note
Examples
The following example configures an IOS SLB probe named PROBE2, then changes to HTTP probe configuration submode:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)#Related Commands
ip slb probe (ping probe)
To configure a ping probe name and to change to ping probe configuration submode, use the ip slb probe (ping probe) configuration command. To remove an ip slb probe configuration, use the no form of this command.
ip slb probe name ping
no ip slb probe name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
This command configures the ping probe name and application protocol, and changes the user interface to ping submode.
The ping probe cannot be unconfigured while it is being used by the server farm or firewall farm.
You can configure more than one probe, in any combination of types (HTTP, ping, or WSP), for each server farm, or for each firewall in a firewall farm.
Examples
The following example configures an IOS SLB probe named PROBE1, then changes to ping probe configuration submode:
Router(config)# ip slb probe PROBE1 pingRouter(config-slb-probe)#Related Commands
ip slb probe (WSP probe)
To configure a WSP probe name and to change to WSP probe configuration submode, use the ip slb probe (WSP probe) configuration command. To remove an ip slb probe configuration, use the no form of this command.
ip slb probe name wsp
no ip slb probe name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
This command configures the WSP probe name and application protocol, and changes the user interface to WSP probe configuration submode.
The WSP probe cannot be unconfigured while it is being used by the server farm or firewall farm.
You can configure more than one probe, in any combination of types (HTTP, ping, or WSP), for each server farm, or for each firewall in a firewall farm.
Examples
The following example configures an IOS SLB probe named PROBE3, then changes to WSP probe configuration submode:
Router(config)# ip slb probe PROBE3 wspRouter(config-slb-probe)#Related Commands
ip slb serverfarm
To identify a server farm and initiate server farm configuration mode, use the ip slb serverfarm global configuration command. To remove the server farm from the IOS SLB configuration, use the no form of this command.
ip slb serverfarm serverfarm-name
no ip slb serverfarm serverfarm-name
Syntax Description
serverfarm-name
Character string used to identify the server farm. The character string is limited to 15 characters.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Grouping real servers into server farms is an essential part of IOS SLB. Using server farms enables IOS SLB to assign new connections to the real servers based on their weighted capacities, and on the load-balancing algorithms used.
Examples
The following example identifies a server farm named PUBLIC:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)#?Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode.
ip slb vserver
To identify a virtual server and initiate virtual server configuration mode, use the ip slb vserver global configuration command. To remove a virtual server from the IOS SLB configuration, use the no form of this command.
ip slb vserver virtual_server-name
no ip slb vserver virtual_server-name
Syntax Description
virtual_server-name
Character string used to identify the virtual server. The character string is limited to 15 characters.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Examples
The following example identifies a virtual server named PUBLIC_HTTP:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)#Related Commands
Associates a real server farm with a virtual server.
Displays information about the virtual servers defined to IOS SLB.
manager
This command has been removed. Its function is now performed by the ip dfp agent global configuration command, and by the following DFP agent configuration commands:
maxconns (firewall farm TCP protocol)
To limit the number of active connections to the real server, use the maxconns firewall farm TCP protocol configuration command. To restore the default of no limit, use the no form of this command.
maxconns maximum-number
no maxconns
Syntax Description
maximum-number
Maximum number of simultaneous active TCP connections using the firewall farm. Valid values range from 1 to 4294967295. The default is 4294967295.
Defaults
Maximum_number default: 4294967295
Command Modes
Firewall farm TCP protocol configuration
Command History
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# tcpRouter(config-slb-fw-tcp)# maxconns 1000Related Commands
Displays information about the firewall farm configuration.
Displays information about the real servers.
Initiates TCP protocol configuration mode.
maxconns (firewall farm UDP protocol)
To limit the number of active connections to the real server, use the maxconns firewall farm UDP protocol configuration command. To restore the default of no limit, use the no form of this command.
maxconns maximum-number
no maxconns
Syntax Description
maximum-number
Maximum number of simultaneous active UDP connections using the firewall farm. Valid values range from 1 to 4294967295. The default is 4294967295.
Defaults
Maximum_number default: 4294967295
Command Modes
Firewall farm UDP protocol configuration
Command History
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# udpRouter(config-slb-fw-udp)# maxconns 1000Related Commands
Displays information about the firewall farm configuration.
Displays information about the real servers.
Initiates UDP protocol configuration mode.
maxconns (server farm)
To limit the number of active connections to the real server, use the maxconns real server configuration command. To restore the default of no limit, use the no form of this command.
maxconns maximum-number
no maxconns
Syntax Description
maximum-number
Maximum number of simultaneous active connections on the real server. Valid values range from 1 to 4294967295. The default is 4294967295.
Defaults
The default maximum number of simultaneous active connections on the real server is 4294967295.
Command Modes
Real server configuration
Command History
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# maxconns 1000Related Commands
mls aging slb normal
To configure the aging time for flows, use the mls aging slb normal global configuration command. To restore the default setting, use the no form of this command.
mls aging slb normal time
no mls aging slb normal time
Syntax Description
Defaults
The default aging idle time is 2000 milliseconds.
Command Modes
Global configuration
Command History
Usage Guidelines
This command is supported for Catalyst 6000 Family Switches only.
Examples
The following example sets the idle time to 4000 milliseconds:
Router(config)# mls aging slb normal 4000Related Commands
mls aging slb process
To control how often the aging process runs, use the mls aging slb process global configuration command. To restore the default setting, use the no form of this command.
mls aging slb process time
no mls aging slb process time
Syntax Description
time
Aging process interval, in milliseconds. The valid range is 1 millisecond to 10000 milliseconds. The default setting is 2000 seconds.
Defaults
The default aging process interval is 2000 milliseconds.
Command Modes
Global configuration
Command History
Usage Guidelines
This command is supported for Catalyst 6000 Family Switches only.
Examples
The following example sets the aging process interval to 4000 milliseconds:
Router(config)# mls aging slb process 4000Related Commands
mls ip slb search wildcard
To specify the behavior of IOS SLB wildcard searches, use the mls ip slb search wildcard global configuration command. To restore the default setting, use the no form of this command.
mls ip slb search wildcard [pfc | rp]
no mls ip slb search wildcard [pfc | rp]
Syntax Description
Defaults
The default setting is for the PFC to perform IOS SLB wildcard searches.
Command Modes
Global configuration
Command History
Usage Guidelines
This command is supported for Catalyst 6000 Family Switches only.
If you configure IOS SLB and either input ACLs or firewall load balancing on the same Catalyst 6000 Family Switch, you can exceed the capacity of the TCAM on the PFC. To correct the problem, use the mls ip slb search wildcard rp command to reduce the amount of TCAM space used by IOS SLB, but be aware that this command can result in a slight increase in route processor utilization.
Examples
The following example limits wildcard searches to the route processor:
Router(config)# mls ip slb search wildcard rpRelated Commands
Identifies a firewall farm and initiates firewall farm configuration mode.
Associates a real server farm with a virtual server.
Identifies a virtual server.
nat
To configure IOS SLB NAT and specify a NAT mode, use the nat server farm configuration command. To remove a NAT configuration, use the no form of this command.
nat {server | client pool-name}
no nat {server | client}
Syntax Description
server
Configures the destination address in load-balanced packets sent to the real server as the address of the real server chosen by the server farm load-balancing algorithm.
client
Configures the client address in load-balanced packets using addresses from the client address pool.
pool-name
Configures the pool name and must match the pool-name parameter from a previous ip slb natpool command.
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
12.1(1)E
This command was introduced.
12.1(2)E
The client keyword and pool-name variable were added.
Usage Guidelines
The no nat command is allowed only if the virtual server was removed from service with the no inservice command.
Examples
The following example changes to IOS SLB server farm configuration mode and configures NAT mode as server address translation on server farm FARM2:
Router# ip slb serverfarm FARM2Router(config-slb-sfarm)# nat serverThe following example configures the NAT mode on server farm FARM2 to client translation mode and, using the real (server farm) command, configures the real server IP address as 10.3.1.1:
Router(config-slb-sfarm)# nat client web-clientsRouter(config-slb-sfarm)# real 10.3.1.1Related Commands
password
To configure a DFP agent password for MD5 authentication, use the password DFP agent configuration command. To remove the DFP agent password, use the no form of this command.
password [0 | 7] password [timeout]
no password
Syntax Description
Defaults
The password encryption default is 0 (unencrypted).
The password timeout default is 180 seconds.
Command Modes
DFP agent configuration
Command History
Usage Guidelines
The password specified on this command must match the password specified on the DFP manager.
The timeout option allows you to change the password without stopping messages between the DFP agent and its manager. The default value is 180 seconds.
During the timeout, the agent sends packets with the old password (or null, if there is no old password), and receives packets with either the old or new password. After the timeout expires, the agent sends and receives packets only with the new password; received packets that use the old password are discarded.
If you are changing the password for an entire load-balanced environment, set a longer timeout. This allows enough time for you to update the password on all agents and servers before the timeout expires. It also prevents mismatches between agents and servers that have begun running the new password and agents, and servers on which you have not yet changed the old password.
Examples
The following example sets the DFP agent password (unencrypted by default) to Cookies and the timeout to 360 seconds:
Router(config)# ip dfp agent slbRouter(config-dfp)# password Cookies 360Related Commands
port (DFP agent)
To define the port number to be used by the DFP manager to connect to the DFP agent, use the port (DFP agent) DFP agent configuration command. To disable the port number definition and remove existing connections, use the no form of this command.
port port-number
no port port-number
Syntax Description
port-number
Port number used by the DFP manager to connect to the DFP agent. The valid range is 1 to 65535.
Defaults
No default behavior or values.
Command Modes
DFP agent configuration
Command History
Examples
In the following example, the DFP manager is enabled to connect to the DFP agent using port number 2221:
Router(config)# ip dfp agent slbRouter(config-dfp)# port 2221Related Commands
port (HTTP probe)
To specify the port to which an HTTP probe is to connect, use the port (HTTP probe) HTTP probe configuration command. To restore the default settings, use the no form of this command.
port port-number
no port port-number
Syntax Description
Defaults
In dispatched mode, the port number is inherited from the virtual server.
If port translation is configured for the real server, that port number is used. See the real (server farm) command for more details.
Command Modes
HTTP probe configuration
Command History
Examples
The following example configures an HTTP probe named PROBE2, changes the CLI to IOS SLB HTTP probe submode, and configures the probe to connect to port number 8:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)# port 8Related Commands
predictor (server farm)
To specify the load-balancing algorithm for selecting a real server in the server farm, use the predictor server farm configuration command. To restore the default load-balancing algorithm of weighted round robin, use the no form of this command.
predictor [roundrobin | leastconns]
no predictor
Syntax Description
roundrobin
(Optional) Uses the weighted round robin algorithm for selecting the real server to handle the next new connection for the server farm. See the "Weighted Round Robin" section for a detailed description of this algorithm. This is the default value.
leastconns
(Optional) Uses the weighted least connections algorithm for selecting the real server to handle the next new connection for this server farm. See the "Weighted Least Connections" section for a detailed description of this algorithm.
Defaults
If you do not specify a load-balancing algorithm, the weighted round robin algorithm is used.
Command Modes
Server farm configuration
Command History
Examples
The following example specifies the weighted least connections algorithm:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# predictor leastconnsRelated Commands
Displays information about the server farm configuration.
Specifies the real server's capacity, relative to other real servers in the server farm.
predictor hash address (firewall farm)
To specify the load-balancing algorithm for selecting a firewall in the firewall farm, use the predictor hash address firewall farm configuration command. To restore the default load-balancing algorithm, use the no form of this command.
predictor hash address [port]
no predictor
Syntax Description
port
(Optional) Uses the source and destination TCP or UDP port numbers, in addition to the source and destination IP addresses, when selecting a firewall.
Defaults
Uses the source and destination IP addresses when selecting a firewall.
Command Modes
Firewall farm configuration
Command History
Examples
The following example specifies that source and destination IP addresses are to be used when selecting a firewall:
Router(config)# ip slb firewall FIRE1Router(config-slb-fw)# predictor hash addressRelated Commands
Displays information about the firewall farm configuration.
Specifies the firewall's capacity, relative to other firewalls in the firewall farm.
probe (firewall farm real server)
To associate a probe with a firewall farm, use the probe firewall farm real server configuration command. To remove the association, use the no form of this command.
probe name
no probe name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Firewall farm real server configuration
Command History
Usage Guidelines
You can configure more than one probe for each firewall in a firewall farm.
Examples
The following example associates probe DAWN with server farm FIRE1:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw-real)# probe DAWNRelated Commands
probe (server farm)
To associate a probe with a server farm, use the probe server farm configuration command. To remove the association, use the no form of this command.
probe name
no probe name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
Usage Guidelines
You can configure more than one probe for each server farm.
Examples
The following example associates probe PROBE1 with server farm PUBLIC:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# probe PROBE1Related Commands
real (firewall farm)
To identify a firewall as a member of a firewall farm and initiate real server configuration mode, use the real firewall farm configuration command. To remove the firewall from the IOS SLB configuration, use the no form of this command.
real ip-address
no real ip-address
Syntax Description
Defaults
No default behavior or values.
Command Modes
Firewall farm configuration
Command History
Usage Guidelines
A firewall farm comprises a number of firewalls. The firewalls are the physical devices that provide the firewall load-balanced services.
Examples
The following example identifies a firewall as a member of firewall farm FIRE1:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# real 10.1.1.1Router(config-slb-real)#Related Commands
Enables the firewall for use by IOS SLB.
Displays information about the firewall farm configuration.
Displays information about the real servers.
real (server farm)
To identify a real server as a member of a server farm and initiate real server configuration mode, use the real server farm configuration command. To remove the real server from the IOS SLB configuration, use the no form of this command.
real ip-address [port_number]
no real ip-address [port_number]
Syntax Description
ip-address
Real server IP address.
port_number
(Optional) Port translation for the server. Valid values range from 1 to 65535.
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
12.0(7)XE
This command was introduced.
12.1(2)E
The port-number variable was added.
Usage Guidelines
A server farm comprises a number of real servers. The real servers are the physical devices that provide the load-balanced services.
Examples
The following example identifies a real server as a member of the server farm:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-real)#Related Commands
Enables the real server for use by IOS SLB.
Displays information about the server farm configuration.
Displays information about the real servers.
reassign
To specify the threshold of consecutive unacknowledged synchronizations that, if exceeded, result in an attempted connection to a different real server, use the reassign real server configuration command. To restore the default reassignment threshold, use the no form of this command.
reassign threshold
no reassign
Syntax Description
threshold
Number of unacknowledged TCP SYNs that are directed to a real server before the connection is reassigned to a different real server. An unacknowledged SYN is one for which no SYN or ACK is detected before the next SYN arrives from the client. IOS SLB allows 30 seconds for the connection to be established or for a new SYN to be received. If neither of these occurs within that time, the connection is removed from the IOS SLB database.
The 30-second timer is restarted for each SYN as long as the number of connection reassignments specified on the faildetect (real server) command's numconns keyword is not exceeded. See the faildetect (real server) command for more information.
Valid threshold values range from 1 to 4 SYNs. The default value is 3.
Defaults
Threshold default: 3 SYNs
Command Modes
Real server configuration
Command History
Usage Guidelines
IOS SLB does not reassign sticky connections if either of the following conditions is true:
•
•
Examples
The following example sets the threshold of unacknowledged SYNs to 2:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# reassign 2Related Commands
replicate casa (firewall farm)
To configure a stateful backup of IOS SLB decision tables to a backup switch, use the replicate casa firewall farm configuration command. To remove a replicate casa configuration, use the no form of this command.
replicate casa listening-ip remote-ip port-number [interval] [password [0 | 7] password [timeout]]
no replicate casa listening-ip remote-ip port-number
Syntax Description
Defaults
The interval default is 10 seconds.
The password encryption default is 0 (unencrypted).
The password timeout default is 180 seconds.
Command Modes
Firewall farm configuration
Command History
Usage Guidelines
The timeout option allows you to change the password without stopping messages between the backup and primary Layer 3 switches. The default value is 180 seconds.
During the timeout, the backup sends packets with the old password (or null, if there is no old password), and receives packets with either the old or new password. After the timeout expires, the backup sends and receives packets only with the new password.
When setting a new password timeout, keep the following in mind:
•
•
Examples
The following example configures a stateful backup Layer 3 switch with a listening IP address of 10.10.10.11, a remote IP address of 10.10.11.12, over HTTP port 4231:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# replicate casa 10.10.10.11 10.10.11.12 4231Related Commands
Displays the configuration of IOS SLB IP replication.
Displays information about the firewall farm configuration.
replicate casa (virtual server)
To configure a stateful backup of IOS SLB decision tables to a backup switch, use the replicate casa virtual server configuration command. To remove a replicate casa configuration, use the no form of this command.
replicate casa listening-ip remote-ip port-number [interval] [password [0 | 7] password [timeout]]
no replicate casa listening-ip remote-ip port-number
Syntax Description
Defaults
The interval default is 10 seconds.
The password encryption default is 0 (unencrypted).
The password timeout default is 180 seconds.
Command Modes
Virtual server configuration
Command History
12.1(2)E
This command was introduced.
12.1(3a)E
The 0 and 7 keywords were added.
Usage Guidelines
The timeout option allows you to change the password without stopping messages between the backup and primary Layer 3 switches. The default value is 180 seconds.
During the timeout, the backup sends packets with the old password (or null, if there is no old password), and receives packets with either the old or new password. After the timeout expires, the backup sends and receives packets only with the new password.
When setting a new password timeout, keep the following in mind:
•
•
Examples
The following example configures a stateful backup Layer 3 switch with a listening IP address of 10.10.10.11, a remote IP address of 10.10.11.12, over HTTP port 4231:
Router(config)# ip slb vserver VS1Router(config-slb-vserver)# replicate casa 10.10.10.11 10.10.11.12 4231Related Commands
Displays the configuration of IOS SLB IP replication.
Displays information about the virtual servers defined to IOS SLB.
request method, request url
To configure an HTTP probe to check the status of the real servers, use the request method or request url configuration command. To remove a request method or request url configuration, use the no form of this command.
request [method {get | post | head | name name}] [url path]
no request [method {get | post | head | name name}] [url path]
Syntax Description
Defaults
If no values are configured following the method keyword, the default is Get.
If no URL path is set to the server, the default is /.
Command Modes
HTTP IOS SLB probe configuration
Command History
Usage Guidelines
The request method/url command configures the IOS SLB HTTP probe method used to receive data from the server. Only one IOS SLB HTTP probe can be configured for each server farm.
Examples
The following example configures an IOS SLB HTTP probe named PROBE2, changes the CLI to IOS SLB probe submode, and configures HTTP requests to use the post method and the URL /probe.cgi?all:
Router(config)# ip slb probe PROBE2 httpRouter(config-slb-probe)# request method post url /probe.cgi?allRelated Commands
Configures the IOS SLB IP probe name.
Displays information about an IOS SLB probe.
retry
To specify how long to wait before a new connection is attempted to a failed server, use the retry real server configuration command. To restore the default retry value, use the no form of this command.
retry retry-value
no retry
Syntax Description
Defaults
The retry-value default is 60 seconds.
Command Modes
Real server configuration
Command History
Examples
The following example specifies that 120 seconds must elapse after the detection of a server failure before a new connection is attempted:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# retry 120Related Commands
serverfarm
To associate a real server farm with a virtual server, or to configure a backup server farm, use the serverfarm virtual server configuration command. To remove the server farm association from the virtual server configuration, use the no form of this command.
serverfarm primary-serverfarm-name [backup backup-serverfarm-name [sticky]]
no serverfarm primary-serverfarm-name [backup backup-serverfarm-name [sticky]]
Syntax Description
Defaults
If backup backup-serverfarm-name is not specified, no backup server farm is configured.
If a backup server farm is configured but sticky is not specified, sticky connections are not used in the backup server farm.
Command Modes
Virtual server configuration
Command History
12.0(7)XE
This command was introduced.
12.1(8a)E
The backup and sticky keywords and the backup-serverfarm-name arguments were added.
Examples
The following example shows how the ip slb vserver, virtual, and serverfarm commands are used to associate the real server farm named PUBLIC with the virtual server named PUBLIC_HTTP.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# virtual 10.0.0.1 tcp wwwRouter(config-slb-vserver)# serverfarm PUBLICRelated Commands
Displays information about the virtual servers defined to IOS SLB.
Configures the virtual server attributes.
show ip dfp
To display information about DFP agents, use the show ip dfp privileged EXEC command.
show ip dfp [agent subsystem-name] [detail]
Syntax Description
agent subsystem-name
(Optional) Displays information about the specified DFP agent, such as slb for IOS SLB.
detail
(Optional) Displays detailed DFP agent information.
Defaults
If no options are specified, the command displays output for all DFP agents identified by ip dfp agent commands, regardless of whether those agents are currently in service (Inservice: yes) or active (AppActive: yes).
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Detailed output for show ip dfp includes information about all DFP agents identified by ip slb agent commands, regardless of whether those agents are currently in service (Inservice: yes) or active (AppActive: yes).
Examples
The following example shows detailed information for DFP agent slb:
Router# show ip dfp agent slb detailUnexpected errors: 0DFP Agent for service: SLBPort: 666 Interval: 10Current passwd: <none> Pending passwd: <none>Passwd timeout: 0Inservice: yes AppActive: yesManager IP Address Timeout------------------ -------172.18.45.27 0Weight Table Report for Agent SLBWeights for Port: 80 Protocol: TCPIP Address Bind ID Weight--------------- ------- -------1.1.1.1 0 65535Weights for Port: 0 (wildcard) Protocol: 0 (wildcard)IP Address Bind ID Weight--------------- ------- -------0.0.0.0 65534 0Bind ID Table Report for Agent SLBBind IDs for Port: 80 Protocol: TCPBind ID Client IP Client Mask------- --------------- ---------------0 0.0.0.0 0.0.0.0
Related Commands
show ip slb conns
To display the active IOS SLB connections, use the show ip slb conns privileged EXEC command.
show ip slb conns [vserver virtual_server-name | client ip-address | firewall firewallfarm-name] [detail]
Syntax Description
Defaults
If no options are specified, the command displays output for all active IOS SLB connections.
Command Modes
Privileged EXEC
Command History
12.0(7)XE
This command was introduced.
12.1(7)E
The firewall keyword and firewallfarm-name variable were added.
Examples
The following example shows IOS SLB active connection data:
Router# show ip slb connsvserver prot client real state----------------------------------------------------------------------------TEST TCP 7.150.72.183:328 80.80.90.25:80 INITTEST TCP 7.250.167.226:423 80.80.90.26:80 INITTEST TCP 7.234.60.239:317 80.80.90.26:80 ESTABTEST TCP 7.110.233.96:747 80.80.90.26:80 ESTABTEST TCP 7.162.0.201:770 80.80.90.30:80 CLOSINGTEST TCP 7.22.225.219:995 80.80.90.26:80 CLOSINGTEST TCP 7.2.170.148:169 80.80.90.30:80 ZOMBIE
show ip slb dfp
To display DFP manager and agent information, such as passwords, timeouts, retry counts, and weights, use the show ip slb dfp privileged EXEC command.
show ip slb dfp [agent agent_ip_address port-number | manager manager_ip_address | detail | weights]
Syntax Description
Defaults
If no options are specified, the command displays summary information.
Command Modes
Privileged EXEC
Command History
12.0(7)XE
This command was introduced.
12.1(5a)E
The manager keyword and manager_ip_address variable were added.
Usage Guidelines
The following example displays high-level information about all DFP agents and managers:
Router# show ip slb dfpDFP Manager:Current passwd:NONE Pending passwd:NONEPasswd timeout:0 secAgent IP Port Timeout Retry Count Interval---------------------------------------------------------------161.44.2.34 61936 0 0 180 (Default)
The following example displays detailed information about DFP agents and managers:
Router# show ip slb dfp detailDFP ManagerCurrent passwd <none> Pending passwd <none>Passwd timeout 0 secUnexpected errors 0% No DFP Agents configuredThe following example displays detailed information about DFP manager 55.55.55.2:
Router# show ip slb dfp manager 55.55.55.2DFP Manager 55.55.55.2 Connection state ConnectedTimeout = 20Last message sent 033537 UTC 01/02/00The following example displays detailed information about weights assigned to real servers for load balancing:
Router# show ip slb dfp weightsReal IP Address 17.17.17.17 Protocol TCP Port 22 Bind_ID 111 Weight 111Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99Real IP Address 17.17.17.17 Protocol TCP Port www Bind_ID 1 Weight 1Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99Real IP Address 68.68.68.68 Protocol TCP Port www Bind_ID 4 Weight 4Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99Real IP Address 85.85.85.85 Protocol TCP Port www Bind_ID 5 Weight 5Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99show ip slb firewallfarm
To display firewall farm information, use the show ip slb firewallfarm configuration command.
show ip slb firewallfarm [detail]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows firewall farm data:
Router# show ip slb firewallfarmfirewall farm hash state reals------------------------------------------------FIRE1 IPADDR OPERATIONAL 2
Table 4 show ip slb firewallfarm Field Descriptions
firewall farm
Name of the firewall farm.
hash
Load-balancing algorithm used to select a firewall for the firewall farm:
•
•
See the predictor hash address (firewall farm) command for more details.
state
Current state of the firewall farm.
•
•
•
reals
Number of firewalls that are members of the firewall farm.
show ip slb natpool
To display the IP IOS SLB NAT configuration, use the show ip slb natpool command.
show ip slb natpool [name pool-name] [detail]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC configuration
Command History
Examples
The following example displays the default show ip slb natpool command:
Router# show ip slb natpoolnat client B 1.1.1.6 1.1.1.8 Netmask 255.255.255.0nat client A 1.1.1.1 1.1.1.5 Netmask 255.255.255.0The following example displays the show ip slb natpool command with the additional detail parameter:
Router# show ip slb natpool detailnat client A 1.1.1.1 1.1.1.5 Netmask 255.255.255.0Start NAT Last NAT Count ALLOC/FREE-------------------------------------------------------1.1.1.1:11001 1.1.1.1:16333 0005333 ALLOC1.1.1.1:16334 1.1.1.1:19000 0002667 ALLOC1.1.1.1:19001 1.1.1.5:65535 0264675 FREEnat client B 1.1.1.6 1.1.1.8 Netmask 255.255.255.0Start NAT Last NAT Count ALLOC/FREE-------------------------------------------------------1.1.1.6:11001 1.1.1.6:16333 0005333 ALLOC1.1.1.6:16334 1.1.1.6:19000 0002667 ALLOC1.1.1.6:19001 1.1.1.8:65535 0155605 FREEshow ip slb probe
To display information about an IOS SLB probe, use the show ip slb probe configuration command.
show ip slb probe [name probe_name] [detail]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB probe data:
Router# show ip slb probeServer:Port State Outages Current Cumulative----------------------------------------------------------------10.10.4.1:0 OPERATIONAL 0 never 00:00:0010.10.5.1:0 FAILED 1 00:00:06 00:00:06
show ip slb reals
To display information about the real servers, use the show ip slb reals privileged EXEC command.
show ip slb reals [vserver virtual_server-name] [detail]
Syntax Description
Defaults
If no options are specified, the command displays information about all real servers.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB real server data:
Router# show ip slb realsreal farm name weight state conns--------------------------------------------------------------------80.80.2.112 FRAG 8 OUTOFSERVICE 080.80.5.232 FRAG 8 OPERATIONAL 080.80.15.124 FRAG 8 OUTOFSERVICE 080.254.2.2 FRAG 8 OUTOFSERVICE 080.80.15.124 LINUX 8 OPERATIONAL 080.80.15.125 LINUX 8 OPERATIONAL 080.80.15.126 LINUX 8 OPERATIONAL 080.80.90.25 SRE 8 OPERATIONAL 22080.80.90.26 SRE 8 OPERATIONAL 21680.80.90.27 SRE 8 OPERATIONAL 21680.80.90.28 SRE 8 TESTING 180.80.90.29 SRE 8 OPERATIONAL 22180.80.90.30 SRE 8 OPERATIONAL 22480.80.30.3 TEST 100 READY_TO_TEST 080.80.30.4 TEST 100 READY_TO_TEST 080.80.30.5 TEST 100 READY_TO_TEST 080.80.30.6 TEST 100 READY_TO_TEST 0
Table 6 show ip slb reals Field Descriptions
real
IP address of the real server about which information is being displayed. Used to identify each real server. Information about each real server is displayed on a separate line.
farm name
Name of the server farm or firewall farm with which the real server is associated.
weight
Weight assigned to the real server. The weight identifies the real server's capacity, relative to other real servers in the server farm.
state
Current state of the real server.
•
•
•
•
•
•
•
•
•
•
•
conns
Number of connections associated with the real server.
The following is sample output from the show ip slb reals detail command for a real server in a server farm:
Router# show ip slb reals detail10.10.1.7, S, state = OPERATIONAL, type = serverconns = 0, dummy_conns = 0, maxconns = 4294967295weight = 8, weight(admin) = 8, metric = 0, remainder = 0reassign = 3, retry = 60failconn threshold = 8, failconn count = 0failclient threshold = 2, failclient count = 0total conns established = 0, total conn failures = 0server failures = 0The following is sample output from the show ip slb reals detail command for a real server in a firewall farm:
Router# show ip slb reals detail10.10.3.2, F, state = OPERATIONAL, type = firewallconns = 0, dummy_conns = 0, maxconns = 4294967295weight = 8, weight(admin) = 8, metric = 0, remainder = 0total conns established = 8377, hash count = 0server failures = 0interface FastEthernet1/0, MAC 0000.0c41.1063Table 7 describes the fields shown in the above detail displays.
Table 7 show ip slb reals detail Field Descriptions
IP address
IP address of the real server about which information is being displayed. Used to identify each real server. Information about each real server is displayed on a separate line.
farm name
Name of the server farm or firewall farm with which the real server is associated.
state
Current state of the real server.
•
•
•
•
•
•
•
•
•
•
•
type
Indicates whether the real server is associated with a server farm (server) or firewall farm (firewall).
conns
Number of connections associated with the real server.
In general packet radio service (GPRS) load balancing, number of sessions associated with the real server.
In per-packet server load balancing, number of request packets that have been load balanced to each real server, using the connection count.
dummy_conns
Internal counter used in debugging.
maxconns
Maximum number of active connections allowed on the real server at one time.
weight
Weight assigned to the real server. The weight identifies the real server's capacity, relative to other real servers in the server farm. This value could be changed by DFP.
weight(admin)
Configured (or default) weight assigned to the real server.
metric
Internal counter used in debugging.
remainder
Internal counter used in debugging.
reassign
Total number of consecutive unacknowledged SYNchronize sequence numbers (SYNs) or Create Packet Data Protocol (PDP) requests since the last time the clear ip slb counters command was issued.
retry
Interval, in seconds, to wait between the detection of a failure on the real server and the next attempt to connect to the server.
failconn threshold
Maximum number of consecutive connection failures allowed before the real server is considered to have failed.
failconn count
Total number of consecutive connection failures since the last time the clear ip slb counters command was issued.
failclient threshold
Maximum number of unique client connection failures allowed before the real server is considered to have failed.
failclient count
Total number of unique client connection failures since the last time the clear ip slb counters command was issued.
total conns established
Total number of successful connection assignments since the last time the clear ip slb counters command was issued.
total conn failures
Total number of unsuccessful connection assignments since the last time the clear ip slb counters command was issued.
server failures
Total number of times this real server has been marked failed.
hash count
Total number of times the hash algorithm has been called.
interface
Type of interface.
MAC
MAC address of the firewall.
show ip slb replicate
To display the IOS SLB replication configuration, use the show ip slb replicate privileged EXEC command.
show ip slb replicate
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example displays the IOS SLB replication configuration:
Router# show ip slb replicate VS1, local = 10.10.99.132 remote = 10.10.99.99 port = 1024 current password = none pending password = none password timeout = 180 sec (Default) unsent conn updates: 0 conn updates received: 32 conn updates transmitted: 471 update packets received: 12 update packets transmitted: 34 failovers: 0 Router#Table 8 describes the fields shown in the display.
show ip slb serverfarms
To display information about the server farms, use the show ip slb serverfarms privileged EXEC command.
show ip slb serverfarms [name serverfarm-name] [detail]
Syntax Description
name
(Optional) Displays information about only a particular server farm.
serverfarm-name
(Optional) Name of the server farm.
detail
(Optional) Displays detailed server farm information.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB server farm data:
Router# show ip slb serverfarmsserver farm predictor reals bind id-------------------------------------------------FRAG ROUNDROBIN 4 0LINUX ROUNDROBIN 3 0SRE ROUNDROBIN 6 0TEST ROUNDROBIN 4 0
show ip slb stats
To display IOS SLB statistics, use the show ip slb stats privileged EXEC command.
show ip slb stats
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB statistics:
Router# show ip slb statsPkts via normal switching: 0Pkts via special switching: 12534087Connections Created: 12466960Connections Established: 12240100Connections Destroyed: 12466960Connections Reassigned: 0Zombie Count: 0Connections Reused: 0Connection Flowcache Purges: 0Failed Connection Allocs: 0Failed Real Assignments: 0Total indications: 0Unknown conn indications: 0SYNACK indications: 0RST client indications: 0RST server indications: 0Two FINs indications: 0Flow age indications: 0
show ip slb sticky
To display the IOS SLB sticky database, use the show ip slb sticky privileged EXEC command.
show ip slb sticky [client ip_address]
Syntax Description
client
(Optional) Displays only those sticky database entries associated with a particular client IP address or subnet.
ip-address
(Optional) IP address of the client.
Defaults
If no options are specified, the command displays information about all virtual servers or firewall farms.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows the IOS SLB sticky database:
Router# show ip slb stickyclient netmask group real conns-----------------------------------------------------------------------10.10.2.12 255.255.0.0 4097 10.10.3.2 1
show ip slb vserver
To display information about the virtual servers, use the show ip slb vserver privileged EXEC command.
show ip slb vserver [name virtual_server-name] [detail]
Syntax Description
name
(Optional) Displays information about only this virtual server.
virtual_server-name
(Optional) Name of the virtual server.
detail
(Optional) Displays detailed information.
Defaults
If no options are specified, the command displays information about all virtual servers.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows virtual server data:
Router# show ip slb vserverslb vserver prot virtual state conns---------------------------------------------------------------------TEST TCP 80.80.254.3:80 OPERATIONAL 1013TEST21 TCP 80.80.254.3:21 OUTOFSERVICE 0TEST23 TCP 80.80.254.3:23 OUTOFSERVICE 0
The following example shows detailed data for a virtual server with route health injection (advertise=TRUE):
Router#show ip slb vserver detailRH1, state = OPERATIONAL, v_index = 6virtual = 5.5.5.5/32:80, TCP, service = NONE, advertise = TRUEserver farm = RHSF, delay = 10, idle = 3600backup server farm = BACKUP, use count = 0, backup sticky = FALSEsticky timer = 0, sticky subnet = 255.255.255.255sticky group id = 0synguard counter = 0, synguard period = 0conns = 1, total conns = 31484, syns = 0, syn drops = 0standby group = None
standby authentication
To configure an authentication string for the Hot Standby Router Protocol (HSRP), use the standby authentication interface configuration command. To delete an authentication string, use the no form of this command.
standby [group-number] authentication string
no standby [group-number] authentication string
Syntax Description
group-number
(Optional) Group number on the interface to which this authentication string applies.
string
Authentication string. It can be up to eight characters in length.
Defaults
The group number default is 0.
The string default is cisco.
Command Modes
Interface configuration
Command History
Usage Guidelines
The authentication string is transmitted unencrypted in all HSRP messages. The same authentication string must be configured on all routers and access servers on a cable to ensure interoperation. Authentication mismatch prevents a device from learning the designated Hot Standby IP address and the Hot Standby timer values from other routers configured with HSRP. Authentication mismatch does not prevent protocol events such as one router taking over as the designated router.
When group number 0 is used, no group number is written to NVRAM, providing backward compatibility.
Examples
In the following example, word is configured as the authentication string required to allow Hot Standby routers in group 1 to interoperate:
Router(config)# interface fastethernet 1Router(config-if)# standby 1 authentication wordstandby name
To specify an HSRP group name with which to associate an IOS SLB interface, use the standby name interface configuration command. To remove the group name association on the interface, use the no form of this command.
standby [group-number] name group-name
no standby [group-number] name group-name
Syntax Description
group-number
(Optional) Group number of the interface to which the timers apply. The default is 0.
group-name
Specifies the HSRP group name with which the IOS SLB virtual server is associated.
Defaults
The default group number is 0.
Command Modes
Interface configuration
Command History
Usage Guidelines
The HSRP group name must first be specified on the inservice (server farm virtual server) command.
Examples
In the following example, HSRP is enabled for group number 1, group name Web-Group, on Ethernet port 0 on the EIP that is installed in slot 5:
Router(config)# interface Ethernet5/0Router(config-if)# ip address 172.18.48.154 255.255.255.128Router(config-if)# standby 1 ip 172.18.48.124Router(config-if)# standby 1 priority 2 preempt delay sync 20Router(config-if)# standby 1 name Web-GroupRelated Commands
standby priority, standby preempt
To configure Hot Standby Router Protocol (HSRP) priority, preemption, and preemption delay, use the standby interface configuration command. To restore the default values, use the no form of this command.
standby [group-number] priority priority [preempt [delay [delay] [minimum [min-delay] | sync [sync-period]]]]
standby [group-number] [priority priority] preempt [delay [delay] [minimum [min-delay] | sync [sync-period]]]]
no standby [group-number] priority priority [preempt [delay [delay] [minimum [min-delay] | sync [sync-period]]]]
no standby [group-number] [priority priority] preempt [delay [delay] [minimum [min-delay] | sync [sync-period]]]]
Syntax Description
Defaults
The group number default is 0.
The priority default is 100.
The delay default is 0 seconds (if the router wants to preempt, it will do so immediately).
The minimum delay default is 0 seconds (if the router wants to preempt, it will do so immediately).
The synchronization period default is 0 seconds (if the router wants to preempt, it will do so immediately, without synchronizing).
Command Modes
Interface configuration
Command History
11.3
This command was introduced.
12.0(2)T
The syntax was restructured, and the minimum and sync keywords and min-delay and sync-period arguments were added.
Usage Guidelines
When using this command, you must specify at least one keyword (priority or preempt), or you can specify both.
When group number 0 is used, no group number is written to NVRAM, providing backward compatibility.
The assigned priority is used to help select the active and standby routers. Assuming preemption is enabled, the router with the highest priority becomes the designated active router. In case of ties, the primary IP addresses are compared, and the higher IP address has priority.
Note that the device's priority can change dynamically if an interface is configured with the standby track command and another interface on the router goes down.
When a router first comes up, it does not have a complete routing table. If it is configured to preempt, it will become the active router, yet it is unable to provide adequate routing services. This problem is solved by configuring a delay before the preempting router actually preempts the currently active router.
If you use the standby preempt command, you must also set the preempt synchronization delay or critical information, such as mobility bindings or load-balancing information, cannot be retrieved before the home agent preempts to become active. In the case where one router is designated as the active home agent, the priority is set highest in the HSRP group and preempt is set.
If you use the standby preempt delay command on both the backup server and backup client, you must specify the same delay on both.
Use the standby preempt delay sync command to ensure that all critical information, such as mobility bindings or load-balancing information, is downloaded to the local router before it takes the active role. When all critical information is downloaded or when the timer expires, whichever comes first, the router becomes active.
Examples
In the following example, the router has a priority of 120 (higher than the default value) and waits for 20 seconds before attempting to become the active router:
Router(config)# interface fastethernet 1Router(config-if)# standby ip 172.19.108.254Router(config-if)# standby priority 120 preempt delay sync 20Related Commands
Configures the standby track on an interface so that the Hot Standby priority changes based on the availability of other interfaces.
standby timers
To configure the time between hellos and the time before other routers declare the active Hot Standby or standby router to be down, use the standby timers interface configuration command. To restore the timers to their default values, use the no form of this command.
standby [group-number] timers hellotime holdtime
no standby [group-number] timers hellotime holdtime
Syntax Description
Defaults
The default group number is 0.
The default hellotime is 3 seconds.
The default holdtime is 3 seconds.
Command Modes
Interface configuration
Command History
Usage Guidelines
The standby timers command configures the time between standby hellos and the time before other routers declare the active or standby router to be down. Routers or access servers on which timer values are not configured can learn timer values from the active or standby router. The timers configured on the active router always override any other timer settings. All routers in a Hot Standby group should use the same timer values. Normally, holdtime is greater than or equal to 3 times hellotime (holdtime > 3 * hellotime).
When group number 0 is used, no group number is written to NVRAM, providing backward compatibility.
Examples
In the following example, for group number 1 on Fast Ethernet interface 1, the time between hello packets is set to 5 seconds, and the time after which a router is considered to be down is set to 15 seconds:
Router(config)# interface fastethernet 1Router(config-if)# standby 1 ipRouter(config-if)# standby 1 timers 5 15standby track
To configure an interface so that the Hot Standby priority changes based on the availability of other interfaces, use the standby track interface configuration command. To remove the tracking, use the no form of this command.
standby [group-number] track type number [interface-priority]
no standby [group-number] track type number [interface-priority]
Syntax Description
Defaults
The default group number is 0.
The default interface priority is 10.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command ties the router's Hot Standby priority to the availability of its interfaces. It is useful for tracking interfaces that are not configured for the HSRP.
When a tracked interface goes down, the Hot Standby priority decreases by 10. If an interface is not tracked, its state changes do not affect the Hot Standby priority. For each interface configured for Hot Standby, you can configure a separate list of interfaces to be tracked.
The optional argument interface-priority specifies how much to decrement the Hot Standby priority by when a tracked interface goes down. When the tracked interface comes back up, the priority is incremented by the same amount.
When multiple tracked interfaces are down and interface-priority values have been configured, these configured priority decrements are cumulative. If tracked interfaces are down, but none was configured with priority decrements, the default decrement is 10 and it is noncumulative.
When group number 0 is used, no group number is written to NVRAM, providing backward compatibility.
Examples
In the following example, Fast Ethernet interface 1 tracks Fast Ethernet interface 10 and Gigabit Ethernet interface 49. If one or both of these two interfaces go down, the Hot Standby priority of the router decreases by 10. Because the default Hot Standby priority is 100, the priority becomes 90 when one or both of the tracked interfaces go down.
Router(config)# interface fastethernet 1Router(config-if)# ip address 198.92.72.37 255.255.255.240Router(config-if)# no ip redirectsRouter(config-if)# standby track fastethernet 10Router(config-if)# standby track gigabitethernet 49Router(config-if)# standby preempt delay sync 20Router(config-if)# standby ip 198.92.72.46Related Commands
Configures the Hot Standby Router Protocol (HSRP) priority, preemption, and preemption delay.
sticky (firewall farm TCP protocol)
To assign all connections from a client to the same firewall, use the sticky firewall farm TCP protocol configuration command. To remove the client/server coupling use the no form of this command.
sticky duration [netmask netmask]
no sticky
Syntax Description
Defaults
Virtual servers are not associated with any groups.
Command Modes
Firewall farm TCP protocol configuration
Command History
Examples
The following example specifies that if a client's subsequent request for a firewall farm is made within 60 seconds of the previous request, then the same firewall is used for the connection:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# tcpRouter(config-slb-fw-tcp)# sticky 60Related Commands
Displays information about the firewall farm configuration.
Displays information about the IOS SLB database.
Initiates TCP protocol configuration mode.
sticky (firewall farm UDP protocol)
To assign all connections from a client to the same firewall, use the sticky firewall farm UDP protocol configuration command. To remove the client/server coupling use the no form of this command.
sticky duration [netmask netmask]
no sticky
Syntax Description
Defaults
Virtual servers are not associated with any groups.
Command Modes
Firewall farm UDP protocol configuration
Command History
Examples
The following example specifies that if a client's subsequent request for a firewall farm is made within 60 seconds of the previous request, then the same firewall is used for the connection:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# udpRouter(config-slb-fw-udp)# sticky 60Related Commands
Displays information about the firewall farm configuration.
Displays information about the IOS SLB database.
Initiates UDP protocol configuration mode.
sticky (virtual server)
To assign all connections from a client to the same real server, use the sticky virtual server configuration command. To remove the client/server coupling use the no form of this command.
sticky duration [group group-id] [netmask netmask]
no sticky
Syntax Description
Defaults
Sticky connections are not tracked.
Virtual servers are not associated with any groups.
Command Modes
Virtual server configuration
Command History
12.0(7)XE
This command was introduced.
12.1(2)E
The netmask keyword and netmask variable were added.
Usage Guidelines
The last real server that was used for a connection from a client is stored for the set duration seconds. If a new connection from the client to the virtual server is initiated during that time, the same real server that was used for the previous connection is chosen for the new connection. If two virtual servers are placed in the same group, coincident connection requests for those services from the same IP address are handled by the same real server.
Examples
The following example specifies that if a client's subsequent request for a virtual server is made within 60 seconds of the previous request, then the same real server is used for the connection. This example also places the virtual server in group 10.
Router(config)# ip slb vserver VS1Router(config-slb-vserver)# sticky 60 group 10Related Commands
Displays information about the IOS SLB database.
Displays information about the virtual servers defined to IOS SLB.
Configures the virtual server attributes.
synguard (virtual server)
To limit the rate of TCP SYNs handled by a virtual server to prevent a SYN flood denial-of-service attack, use the synguard virtual server configuration command. To remove the threshold, use the no form of this command.
synguard syn-count [interval]
no synguard
Syntax Description
Defaults
Syn-count default: 0 (off)
Interval default: 100 ms
Command Modes
Virtual server configuration
Command History
Examples
The following example sets the threshold of unacknowledged SYNs to 50:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# synguard 50Related Commands
Displays information about the virtual servers defined to IOS SLB.
Configures the virtual server attributes.
tcp
To initiate TCP protocol configuration mode, use the tcp firewall farm configuration command.
tcp
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Firewall farm configuration
Command History
Usage Guidelines
There is not a no form of this command.
Examples
The following example initiates TCP protocol configuration mode:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# tcpRouter(config-slb-fw-tcp)# exitRelated Commands
udp
To initiate UDP protocol configuration mode, use the udp firewall farm configuration command.
udp
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Firewall farm configuration
Command History
Usage Guidelines
There is not a no form of this command.
Examples
The following example initiates UDP protocol configuration mode:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# udpRouter(config-slb-fw-udp)# exitRelated Commands
url (WSP probe)
To specify the URL path that a WSP probe is to request from the server, use the url WSP probe configuration command. To restore the default settings, use the no form of this command.
url [path]
no url [path]
Syntax Description
Defaults
If no URL path is specified, the default is /.
Command Modes
WSP probe configuration
Command History
Examples
The following example configures a ping probe named PROBE3, changes the CLI to IOS SLB WSP probe submode, and configures the probe to request URL path http://localhost/test.txt:
Router(config)# ip slb probe PROBE3 wspRouter(config-slb-probe)# url http://localhost/test.txtRelated Commands
Configures a WSP probe name and changes to WSP probe configuration submode.
Displays information about an IOS SLB probe.
virtual (virtual server)
To configure virtual server attributes, use the virtual virtual server configuration command. To remove the attributes, use the no form of this command.
virtual ip-address [network-mask] {tcp | udp} [port-number | wsp | wsp-wtp | wsp-wtls | wsp-wtp-wtls] [service service-name]
no virtual
Syntax Description
Defaults
No default behavior or values.
Command Modes
Virtual server configuration
Command History
12.0(7)XE
This command was introduced.
12.1(5a)E
The wsp, wsp-wtp, wsp-wtls, and wsp-wtp-wtls keywords were added.
Usage Guidelines
The no virtual command is allowed only if the virtual server was removed from service by the no inservice command.
For some applications, it is not feasible to configure all the virtual server TCP or UDP port numbers for IOS SLB. To support such applications, you can configure IOS SLB virtual servers to accept flows destined for all ports. To configure an all-port virtual server, specify a port number of 0.
On Catalyst 6000 Family Switches, if you use FTP sessions with MNLB you must configure a port-bound virtual server bound to port 21 on the MNLB Services Manager (the LocalDirector).
In general, you should use port-bound virtual servers instead of all-port virtual servers. When you use all-port virtual servers, 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. To prevent this problem, use one of the following procedures:
•
•
•
Examples
The following example specifies that the virtual server with the IP address 10.0.0.1 performs load balancing for TCP connections for the port named www. The virtual server processes HTTP requests.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# virtual 10.0.0.1 tcp wwwThe following example specifies that the virtual server with the IP address 10.0.0.13 performs load balancing for UDP connections for all ports. The virtual server processes HTTP requests.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# virtual 10.0.0.13 udp 0Related Commands
Identifies a virtual server.
Displays information about the virtual servers defined to IOS SLB.
weight (firewall farm real server)
To specify a real server's capacity, relative to other real servers in the firewall farm, use the weight firewall farm real server configuration command. To restore the default weight value, use the no form of this command.
weight weighting-value
no weight
Syntax Description
weighting-value
Weighting value to use for real server predictor algorithm. Valid values range from 1 to 255. The default weighting value is 8.
Defaults
Weighting-value default: 8
Command Modes
Firewall farm real server configuration
Command History
Examples
The following example specifies the relative weighting values of three real servers as 16, 8 (by default), and 24, respectively:
Router(config)# ip slb firewallfarm FIRE1Router(config-slb-fw)# real 10.10.1.1 First real serverRouter(config-slb-fw-real)# weight 16 Assigned weight of 16Router(config-slb-fw-real)# inservice EnabledRouter(config-slb-fw-real)# exitRouter(config-slb-fw)# real 10.10.1.2 Second real serverRouter(config-slb-fw-real)# inservice Enabled; default weightRouter(config-slb-fw-real)# exitRouter(config-slb-fw)# real 10.10.1.3 Third real serverRouter(config-slb-fw-real)# weight 24 Assigned weight of 24; not enabledRelated Commands
weight (server farm)
To specify a real server's capacity, relative to other real servers in the server farm, use the weight real server configuration command. To restore the default weight value, use the no form of this command.
weight weighting-value
no weight
Syntax Description
weighting-value
Weighting value to use for real server predictor algorithm. Valid values range from 1 to 255. The default weighting value is 8.
Defaults
Weighting-value default: 8
Command Modes
Real server configuration
Command History
Usage Guidelines
The static weights you define using this command are overridden by the weights calculated by DFP. If DFP is removed from the network, IOS SLB reverts to these static weights.
Examples
The following example specifies the relative weighting values of three real servers as 16, 8 (by default), and 24, respectively:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1 First real serverRouter(config-slb-real)# weight 16 Assigned weight of 16Router(config-slb-real)# inservice EnabledRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.10.1.2 Second real serverRouter(config-slb-real)# inservice Enabled; default weightRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.10.1.3 Third real serverRouter(config-slb-real)# weight 24 Assigned weight of 24; not enabledRelated Commands
Debug Commands
This section documents the following new debug command related to the IOS SLB feature:
debug ip dfp agent
To display debug messages for the DFP agent subsystem, use the debug ip dfp EXEC command. To stop debug output, use the no form of this command.
debug ip dfp agent
no debug ip dfp agent
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC configuration
Command History
Usage Guidelines
See the following caution before using debug commands:
Caution
This command displays debug messages for the DFP agent subsystem.
Examples
The following example configures a DFP agent debug session:
Router# debug ip dfp agentDFP debugging is onRouter#The following example stops all debugging:
Router# no debug allAll possible debugging has been turned offRouter#debug ip slb
To display debug messages for IOS SLB, use the debug ip slb EXEC command. To stop debug output, use the no form of this command.
debug ip slb {conns | dfp | firewallfarm | icmp | natpool | probe | reals | replication | sessions | vservers | all}
no debug ip slb {conns | dfp | firewallfarm | icmp | natpool | probe | reals | replication | sessions | vservers | all}
Syntax Description
all
Displays all debug messages for IOS SLB.
conns
Displays debug messages for all connections being handled by IOS SLB, including WSP events and states.
dfp
Displays debug messages for DFP. To display debug messages for the DFP agent subsystem, use debug ip dfp agent.
firewallfarm
Displays debug messages related to firewall load balancing.
icmp
Displays all Internet Control Message Protocol debug messages for IOS SLB.
natpool
Displays debug messages related to the IOS SLB client NAT pool.
probe
Displays debug messages related to probes.
reals
Displays debug messages for all real servers defined to IOS SLB.
replication
Displays debug messages related to IOS SLB stateful backup virtual server.
sessions
Displays debug messages for all sessions being handled by IOS SLB.
vservers
Displays debug messages for all virtual servers defined to IOS SLB.
Defaults
No default behavior or values.
Command Modes
EXEC configuration
Command History
Usage Guidelines
See the following caution before using debug commands:
Caution
Examples
The following example configures a debug session to check all IP IOS SLB parameters:
Router# debug ip slb allSLB All debugging is onRouter#The following example stops all debugging:
Router# no debug allAll possible debugging has been turned offRouter#The following example configures debugging to check IP IOS SLB replication used with stateful backup and displays the output from the send or transmit virtual server:
Router# debug ip slb replication*Mar 2 08:02:38.019: SLB Replicate: (send) update vs: VS1 update_count 42FAQ (Frequently Asked Questions)
The following questions and answers can help you troubleshoot IOS SLB, if you have problems.
Can I use IOS SLB to load balance clients and real servers that are on the same LAN or VLAN?
NO!
IOS SLB does not support load balancing of flows between clients and real servers that are on the same LAN or VLAN. The packets being load balanced cannot enter and leave the load-balancing device on the same interface.
Why is IOS SLB not marking my connections as ESTABLISHED even though I'm transferring data?
If you are using dispatched mode, make sure there are no alternate paths that allow outbound flows to bypass IOS SLB. Also, make sure the clients and real servers are not on the same IP subnet.
Why am I able to connect to real servers directly, but unable to connect to the virtual server?
Make sure that the virtual IP address is configured as a loopback in each of the real servers (if you are running in dispatched mode).
Why is IOS SLB not marking my real server as failed when I disconnect it from the network?
Tune the values for the numclients, numconns, and delay keywords.
If you have a very small client population (for example, in a test environment), the numclients keyword could be causing the problem. This parameter prevents IOS SLB from mistaking the failure of a small number of clients for the failure of a real server.
Why does IOS SLB show my real server as INSERVICE even though I have taken it down or physically disconnected it?
The INSERVICE and OUTOFSERVICE states indicate whether the network administrator intends for that real server to be used when it is operational. A real server that was INSERVICE but was removed from the selection list dynamically by IOS SLB as a result of automatic failure detection, is marked as FAILED. Use the show ip slb reals detail command to display these real server states.
Beginning with release 12.1(1)E, INSERVICE is changed to OPERATIONAL, to better reflect what is actually occurring.
Why is IOS SLB not balancing correctly? I am using dispatched mode, the servers are leaving sockets open, and I am seeing RSTs in response to a number of SYNs. Curiously, sometimes things work fine.
Enter the show mls flow command:
Router# sh mls flowcurrent ip flowmask for unicast: full flowcurrent ipx flowmask for unicast: destination onlyThe current IP flowmask must be full flow. If it is not, correct the problem using the mls flow ip full command:
Router# config tEnter configuration commands, one per line.End with CNTL/Z.Router(config)# mls flow ip fullRouter(config)#How can I verify that IOS SLB sticky connections are working properly?
Use the following procedure:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
How can I verify that server failures are being detected correctly?
Use the following procedure:
1.
2.
3.
–
–
–
Does the no inservice command take a resource out of service immediately?
When you use the no form of the inservice command to remove a firewall, firewall farm, real server, or virtual server from service, the resource quiesces gracefully. No new connections are assigned, and existing connections are allowed to complete.
To stop all existing connections for an entire firewall farm or virtual server immediately, use the clear ip slb command.
I configured both IOS SLB and input ACLs on the same Catalyst 6000 Family Switch, and now I see TCAM Capacity Exceeded messages. Why?
If you configure IOS SLB and either input ACLs or firewall load balancing on the same Catalyst 6000 Family Switch, you can exceed the capacity of the TCAM on the Policy Feature Card (PFC). To correct the problem, use the mls ip slb search wildcard rp command to reduce the amount of TCAM space used by IOS SLB, but be aware that this command can result in a slight increase in route processor utilization.
Glossary
active standby—Redundancy scheme in which two IOS SLB devices can load-balance the same virtual IP address while at the same time acting as backups for each other. See also active standby, stateful backup.
bearer network—Network that carries messages of a transport-layer protocol, and ultimately also of the session-layer protocols, between physical devices. A single session can use more than one bearer network.
CASA—Content Aware Services Architecture. CASA is a protocol designed to allow network appliances to selectively control the flow of IP packets through a router, switch, or other network device.
client NAT—Translation scheme in which the client IP address is replaced with an IP address associated with one of a group of load-balancing devices, resulting in outbound flows being routed to the correct device. See also directed mode, server NAT.
client subsystem—Users, such as IOS SLB, of the DFP agent function.
cluster—Set of computer systems that are connected through multisystem hardware or software to supply services traditionally provided by a single system. This arrangement provides higher availability and better scalability of the system.
content-aware networking—Networking strategy that enables content to be dynamically distributed. Because content can be dynamically cached, it can be located at any given place at any given time and distributed between the servers and the location of the webcache. Cisco has developed the ContentFlow architecture and the DFP to enable networks to provide content-aware networking services.
ContentFlow architecture—Cisco's content-aware networking architecture that describes message flows and actions in a distributed environment.
DFP—Dynamic Feedback Protocol. Allows host agents to dynamically report the change in status of the host systems providing a virtual service. The status reported is a relative weight that specifies a host server's capacity to perform work.
DFP agent—Host agent in a load-balanced environment that dynamically reports changes in status of the host systems that provide a virtual service. The status reported is a relative weight that specifies a host server's capacity to perform work. See also DFP manager.
DFP manager—Host manager in a load-balanced environment that collects status reports from DFP agents. See also DFP agent.
directed mode—Session redirection mode in which 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 real server, translating the virtual server IP address to a real server IP address through NAT. See also dispatched mode, NAT.
dispatched mode—Session redirection mode in which the virtual server address is known to the real servers. The virtual server IP address must be configured 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. See also directed mode.
Dynamic Feedback Protocol—See DFP.
firewall—Router or access server, or several routers or access servers, designated as a buffer between any connected public networks and a private network. A firewall router uses access lists and other methods to ensure the security of the private network.
firewall farm—Group of firewalls.
firewall load balancing—Load-balancing scheme in which the network administrator configures a group of firewalls into a firewall farm. When a client initiates a connection, IOS SLB chooses a firewall for the connection based on a hash algorithm.
HSRP—Hot Standby Router Protocol. Provides high network availability and transparent network topology changes. HSRP creates a Hot Standby router group with a lead router that services all packets sent to the Hot Standby address. The lead router is monitored by other routers in the group, and if it fails, one of these standby routers inherits the lead position and the Hot Standby group address. See also redundancy, stateful backup, stateless backup.
HTTP redirect load balancing—Load-balancing scheme in which all HTTP requests that belong to the same transaction are directed to the same real server.
IOS SLB—IOS Server Load Balancing. Load-balancing scheme in which 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. When a client initiates a connection to the virtual server, IOS SLB chooses a real server for the connection based on a configured load-balancing algorithm.
load balancing—Spreading user requests among available servers within a cluster of servers, based on a variety of algorithms.
MD5—Message Digest Algorithm Version 5. Neighbor router authentication scheme used to ensure reliability and security when routing updates are exchanged between neighbor routers.
Message Digest Algorithm Version 5—See MD5.
NAT—Network Address Translation. Modification of one or more of the following fields in an IP packet: source IP address, destination IP address, source TCP/UDP port, destination TCP/UDP port. See also client NAT, server NAT.
NetFlow switching—High-performance network-layer switching path that captures as part of its switching function a rich set of traffic statistics including user, protocol, port, and type of service information.
Network Address Translation—See NAT.
port-bound—Server configuration scheme in which a virtual server IP address represents one set of real servers for one service, such as Hypertext Transfer Protocol (HTTP), and a different set of real servers for another service, such as Telnet.
real server—The specification of a physical server associated with a virtual server. The specification includes the real server's IP address and an optional weight to be used by the virtual server predictor.
redundancy—The duplication of devices, services, or connections so that, in the event of a failure, the redundant devices, services, or connections can perform the work of those that failed. See also stateful backup, stateless backup.
round robin—See weighted round robin.
Secure Socket Layer—See SSL.
server cluster—See server farm.
server farm—Also called a server cluster. Group of real servers that provide various applications and services.
Server Load Balancing—See IOS SLB.
server NAT—Translation scheme in which the virtual server IP address is replaced with the real server IP address (and vice versa), allowing servers to be many hops away from the load-balancing device, and enabling intervening routers to route to them without requiring tunnelling. See also client NAT, directed mode, server port translation.
server port translation—Translation scheme in which the virtual server port number is replaced with the real server port number (and vice versa), allowing servers to be many hops away from the load-balancing device, and enabling intervening routers to route to them without requiring tunnelling. See also client NAT, directed mode, server NAT.
services manager—Functionality built into IOS SLB that makes load-balancing decisions based on application availability, server capacity, and load distribution algorithms such as weighted round robin or weighted least connections, or the DFP. The services manager determines a real server for the packet flow using load balancing and server/application feedback.
SLB—See IOS SLB.
SSL—Secure Socket Layer. Encryption technology for the web used to provide secure transactions such as the transmission of credit card numbers for e-commerce.
stateful backup—Redundancy scheme that enables IOS SLB to incrementally backup its load-balancing decisions, or "keep state," between primary and backup switches. See also active standby, stateless backup.
stateless backup—Redundancy scheme that provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of a single Layer 3 switch. See also active standby, stateful backup.
sticky connections—Load-balancing scheme in which new connections from a client IP address or subnet are assigned to the same real server (for server load balancing) or firewall (for firewall load balancing) as were previous connections from that address or subnet.
virtual server—Presents a single address that represents an application server farm to clients.
WAP—Wireless Application Protocol. Suite of protocols used to deliver services to wireless devices.
weighted least connection—Load-balancing algorithm in which the next real server chosen for a new connection to the virtual server is the server with the fewest active connections. 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. 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...).
weighted round robin—Load-balancing algorithm in which the real server used for a new connection to the virtual server is chosen 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. New connections are assigned to a given real server n times before the next real server in the list is chosen.
Wireless Application Protocol—See WAP.
Wireless Session Protocol—See WSP.
Wireless Transaction Protocol—See WTP.
Wireless Transport Security Layer—See WTLS.
workload agents—Value-added software components developed for specific platforms by third-party developers. Workload agents run on server platforms or on platforms that manage server farms. Workload agents deliver server and application information to the services manager. This information enables the services manager to make optimum server selection.
WSP—Wireless Session Protocol. Session-layer protocol of the WAP suite.
WTLS—Wireless Transport Security Layer. Layer that provides security between WAP clients and WAP gateways.
WTP—Wireless Transaction Protocol. Transaction-layer protocol of the WAP suite.
