|
|
This feature module describes the Cisco IOS Server Load Balancing (SLB) feature. It includes the following sections:
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.
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.
This section describes the following functions and capabilities provided by IOS SLB:
IOS SLB provides two load-balancing algorithms: weighted round robin and weighted least connections. You can specify either algorithm as the basis for choosing a real server for each new connection request that arrives at the virtual server.
The weighted round robin algorithm specifies that the real server used for a new connection to the virtual server is chosen from the server farm in a circular fashion. Each real server is assigned a weight, n, that represents its capacity to handle connections, as compared to the other real servers associated with the virtual server. That is, new connections are assigned to a given real server n times before the next real server in the server farm is chosen.
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. The first three connections to the virtual server are assigned to ServerA, the fourth connection to ServerB, and the fifth and sixth connections to ServerC.
 |
Note Assigning a weight of n=1 to all of the servers in the server farm configures the IOS SLB switch to use a simple round robin algorithm. |
The weighted least connections algorithm specifies that the next real server chosen from a server farm for a new connection to the virtual server is the server with the fewest active connections. Each real server is assigned a weight for this algorithm, also. When weights are assigned, the server with the fewest connections is based on the number of active connections on each server, and on the relative capacity of each server. The capacity of a given real server is calculated as the assigned weight of that server divided by the sum of the assigned weights of all of the real servers associated with that virtual server, or n1/(n1+n2+n3...).
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. ServerA would have a calculated capacity of 3/(3+1+2), or half of all active connections on the virtual server, ServerB one-sixth of all active connections, and ServerC one-third of all active connections. At any point in time, the next connection to the virtual server would be assigned to the real server whose number of active connections is farthest below its calculated capacity.
|
Note Assigning a weight of n=1 to all of the servers in the server farm configures the IOS SLB switch to use a simple least-connection algorithm. |
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.
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.
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.
Client-assigned load balancing allows you to limit access to a virtual server by specifying the list of client IP subnets that are permitted to use that virtual server. With this feature, you can assign a set of client IP subnets (such as internal subnets) connecting to a virtual IP address to one serverfarm, and assign another set of clients (such as external clients) to a different serverfarm.
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.
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.
The Dynamic Feedback Protocol (DFP) is a mechanism that allows host agents in load-balanced environments to dynamically report the change in status of the host systems that provide a virtual service. The status reported is a relative weight that specifies a host server's capacity to perform work.
When a DFP agent is defined to IOS SLB, a TCP connection is initiated from the manager to the DFP agent. Once this connection is established, the agent periodically sends update information across the connection to IOS SLB. This information is used by IOS SLB as an aid in load balancing the real servers, as well as acting as an application-level keep-alive for the connection. If an agent on the real server has no information to send, and an inactivity timeout was specified for this DFP agent, the agent must send an empty report to prevent removal of the connection. In the event of a failure, IOS SLB uses the weight specified by the user when the real server was configured, or a default weight if a weight was not specified.
The DFP agent can be either software running on the real server or a separate unit that collects information from one or more real servers. The DFP agent consolidates the information, formats it into the DFP, and reports the information to IOS SLB at periodic intervals. If a need arises, such as a sudden change in a real server's ability to handle flows, the DFP agent can send an early report.
As its name implies, firewall load balancing enables IOS SLB to balance flows to firewalls regardless of whether server load balancing is used. 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.
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.
IOS SLB firewall load balancing uses a hash algorithm to balance flows across the firewalls in a firewall farm. The hash algorithm uses the source and destination IP addresses of incoming flows (and optionally the source and destination TCP or User Datagram Protocol [UDP] port numbers) to select a firewall to handle the connection request.
IOS SLB firewall load balancing provides the following capabilities:
IOS SLB allows you to configure maximum connections for server and firewall load balancing.
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 FTP and firewall load balancing only in dispatched mode. Therefore, neither FTP not firewall load balancing can use NAT. |
IOS SLB supports the following types of NAT:
|
Note If an IP address is configured as a real IP address for a NAT virtual server, you cannot balance connection requests from that address to a different virtual server (whether NAT or dispatched) on the same load-balancing device. |
|
Note Both server NAT and client NAT are supported for the same connection. |
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 You cannot configure NAT on a firewall farm, therefore you cannot configure port-bound servers for IOS SLB firewall load balancing. |
IOS SLB supports both HTTP probes and ping probes. 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.
You can configure more than one probe for each server farm, or for each firewall in a firewall farm.
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.
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.
HTTP Probes
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 switch. See the description of the ip http server command in the Cisco IOS Configuration Fundamentals Command Reference for more details.
IOS SLB supports the following protocols:
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.
|
Note 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. |
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.
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 period defined by a configurable sticky timer. If the timer is configured on a virtual server or on a firewall farm, new connections from a client are sent to the same real server that handled the previous client connection, provided one of the following is true:
Sticky connections also permit the coupling of services that are handled by more than one virtual server 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 HTTP over Secure Socket Layer (HTTPS) uses port 443. If HTTP virtual servers and HTTPS virtual servers are coupled, connections for ports 80 and 443 from the same client IP address or subnet are assigned to the same real server.
SynGuard limits the rate of TCP synchronous idle characters (SYNs) handled by a virtual server to prevent a type of network problem known as a SYN flood denial-of-service attack. A user might send a large number of SYNs to a server, which could overwhelm or crash the server, denying service to other users. SynGuard prevents such an attack from bringing down IOS SLB or a real server. SynGuard monitors the number of SYNs to a virtual server over a specific time interval and does not allow the number to exceed a configured SYN threshold. If the threshold is reached, any new SYNs are dropped.
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.
|
Note A Web cache can start its own connections to real Web sites if pages are not available in its cache. Those connections cannot be load-balanced back to the same set of Web caches. IOS SLB addresses this by allowing you to configure "client exclude" statements, so that IOS SLB does not load balance connections initiated by the Web caches. |
IOS SLB uses ping probes, which you can configure to verify the presence of each real server, to detect WAP server failures. If a server's WAP stack fails but its Internet Control Message Protocol (ICMP) stack does not fail, IOS SLB cannot detect the WAP server failure.
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. On the Catalyst 4840G, this hardware acceleration is further expanded to enable hardware switching of server NAT and client NAT flows.
IOS SLB assures continuous, high availability of content and applications with proven techniques for actively managing servers and connections in a distributed environment. By distributing user requests across a cluster of servers, IOS SLB optimizes responsiveness and system capacity, and dramatically reduces the cost of providing Internet, database, and application services for large-scale as well as small- and medium- sized sites.
IOS SLB facilitates scalability, availability, and ease of maintenance:
Administration of server applications is easier. Clients know only about virtual servers; no administration is required for real server changes.
Security of the real server is provided because its address is never announced to the external network. Users are familiar only with the virtual IP address. You can filter unwanted flows based on both IP address and TCP or UDP port numbers. Additionally, though it does not eliminate the need for a firewall, IOS SLB can help protect against some denial-of-service attacks.
In a branch office, IOS SLB allows balancing of multiple sites and disaster recovery in the event of full-site failure, and distributes the work of load balancing.
IOS SLB has the following restrictions:
The Documentation CD-ROM is updated monthly; the documentation on Cisco Connection Online (CCO) is updated as changes are made. Therefore, these electronic documents might be more current than the printed documentation.
Standards
MIBs
RFCs
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:
To configure the IOS SLB network shown in Figure 2, use the following commands beginning in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)# ip slb serverfarm serverfarm-name Router(config-slb-sfarm)# | 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. |
Router(config-slb-sfarm)# real ip-address | 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. |
Router(config-slb-real)# inservice | Enables the real server for use by IOS SLB. See the inservice (server farm real server) command for more details. |
Router(config-slb-real)# exit | Return to server farm configuration mode. |
Router(config-slb-sfarm)# end | Return to global configuration mode. |
Router(config)# ip slb vserver virtserver-name | 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 {tcp | udp} port-number [service service-name] | Specifies the virtual server IP address, type of connection, TCP or UDP port number, and optional service coupling. See the virtual command for more details. |
Router(config-slb-vserver)# serverfarm serverfarm-name | Associates a real server farm with a virtual server. See the serverfarm command for more details. |
Router(config-slb-vserver)# inservice | Enables the virtual server for use by IOS SLB. See the inservice (server farm virtual server) command for more details. |
Router(config-slb-vserver)# client ip-address network-mask | Specifies which clients are allowed to use the virtual server. See the client 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:
The following commands configure the server farm PUBLIC and associate the three real servers:
Router# config t Enter configuration commands, one per line. End with CNTL/Z. Router(config)# ip slb serverfarm PUBLIC Router(config-slb-sfarm)# real 10.1.1.1 Router(config-slb-real)# inservice Router(config-slb-real)# exit Router(config-slb-sfarm)# real 10.1.1.2 Router(config-slb-real)# inservice Router(config-slb-real)# exit Router(config-slb-sfarm)# real 10.1.1.3 Router(config-slb-real)# inservice Router(config-slb-real)# end
The following commands configure the server farm RESTRICTED and associate the two real servers:
Router# config t Enter configuration commands, one per line. End with CNTL/Z. Router(config)# ip slb serverfarm RESTRICTED Router(config-slb-sfarm)# real 10.1.1.20 Router(config-slb-real)# inservice Router(config-slb-real)# exit Router(config-slb-sfarm)# real 10.1.1.21 Router(config-slb-real)# inservice Router(config-slb-real)# end Router#
The following show ip slb reals command displays the status of server farms PUBLIC and RESTRICTED, the associated real servers, and their status:
Router# show ip slb real real farm name weight state conns --------------------------------------------------------------------- 10.1.1.1 PUBLIC 8 OPERATIONAL 0 10.1.1.2 PUBLIC 8 OPERATIONAL 0 10.1.1.3 PUBLIC 8 OPERATIONAL 0 10.1.1.20 RESTRICTED 8 OPERATIONAL 0 10.1.1.21 RESTRICTED 8 OPERATIONAL 0 Router#
The following show ip slb serverfarm command displays the configuration and status of server farms PUBLIC and RESTRICTED:
Router# show ip slb serverfarm server farm predictor nat reals bind id --------------------------------------------------- PUBLIC ROUNDROBIN none 3 0 RESTRICTED ROUNDROBIN none 2 0 Router#
The following commands configure the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router# Router# config t Enter configuration commands, one per line. End with CNTL/Z. Router(config)# ip slb vserver PUBLIC_HTTP Router(config-slb-vserver)# virtual 10.0.0.1 tcp www Router(config-slb-vserver)# serverfarm PUBLIC Router(config-slb-vserver)# inservice Router(config-slb-vserver)# . (Information Deleted) . index = 1 Router(config-slb-vserver)# exit Router(config)# ip slb vserver RESTRICTED_HTTP Router(config-slb-vserver)# virtual 10.0.0.2 tcp www Router(config-slb-vserver)# serverfarm RESTRICTED Router(config-slb-vserver)# inservice Router(config-slb-vserver)# . (Information Deleted) . index = 1 Router(config-slb-vserver)# end Router#
The following show ip slb vservers command verifies the configuration of the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router# show ip slb vservers slb vserver prot virtual state conns ------------------------------------------------------------------- PUBLIC_HTTP TCP 10.0.0.1:80 OPERATIONAL 0 RESTRICTED_HTTP TCP 10.0.0.2:80 OPERATIONAL 0 Router# Router#
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 t Enter configuration commands, one per line. End with CNTL/Z. Router(config)# ip slb vserver RESTRICTED_HTTP Router(config-slb-vserver)# no inservice Router(config-slb-vserver)# . (Information Deleted) . index = 1 Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0 Router(config-slb-vserver)# inservice Router(config-slb-vserver)# src = 0 - 0 . (Information Deleted) . index = 1 Router(config-slb-vserver)# end Router#
The following show ip slb conns command verifies the restricted client access and status:
Router# show ip slb conns vserver prot client real state nat ------------------------------------------------------------------------------- RESTRICTED_HTTP TCP 10.4.4.0:80 10.1.1.20 CLOSING none Router#
The following show ip slb conns command displays detailed information about the restricted client access status:
Router# show ip slb conns client 10.4.4.0 detail VSTEST_UDP, client = 10.4.4.0:80 state = CLOSING, real = 10.1.1.20, nat = none v_ip = 10.0.0.2:80, TCP, service = NONE client_syns = 0, sticky = FALSE, flows attached = 0 Router#
To verify that the IOS SLB feature has been installed and is operating correctly, ping the real servers from the IOS SLB switch, then ping the virtual servers from the clients.
The following show ip slb stats command displays detailed information about the IOS SLB network status: Router# show ip slb stats Pkts via normal switching: 0 Pkts via special switching: 6 Connections Created: 1 Connections Established: 1 Connections Destroyed: 0 Connections Reassigned: 0 Zombie Count: 0 Connections Reused: 0 Router#
See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB networks and connections.
This section describes the following optional tasks you can use to fine tune the IOS SLB configuration:
To determine which real server to use for each new connection request, the IOS SLB feature uses one of two load-balancing algorithms: weighted round robin (the default) or weighted least connections. See the "Weighted Round Robin" section or the "Weighted Least Connections" section for detailed descriptions of these algorithms.
|
Note You can configure a real server with a weight relative to other real servers in the server farm, using the weight (server farm) real server configuration command. |
To specify the load-balancing algorithm, use the following command in server farm configuration mode:
| Command | Purpose |
|---|---|
Router(config-slb-sfarm)# predictor [roundrobin | leastconns] | Specifies whether the weighted round robin algorithm or the weighted least connections algorithm is 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 RESTRICTED Router(config-slb-sfarm)# predictor leastconns
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.
To configure a bind ID on the server farm for use by DFP, use the following command in server farm configuration mode:
| Command | Purpose |
|---|---|
Router(config-slb-sfarm)# bindid [bind_id] | 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 RESTRICTED Router(config-slb-sfarm)# bindid 309
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.
You can configure any of the following real server attributes, by using the following real server commands beginning in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)# ip slb serverfarm serverfarm-name Router(config-slb-sfarm)# | 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. |
Router(config-slb-sfarm)# real ip-address | 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. |
Router(config-slb-real)# faildetect numconns number-conns [numclients number-clients] | 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. |
Router(config-slb-real)# maxconns number-conns | Specifies the maximum number of active connections allowed on the real server at one time. See the maxconns (server farm) command for more details. |
Router(config-slb-real)# reassign threshold | Specifies the number of consecutive unanswered SYNs that initiates assignment of the connection to a different real server. See the reassign command for more details. |
Router(config-slb-real)# retry retry-value | 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. |
Router(config-slb-real)# weight weighting-value | Specifies the real server's workload capacity relative to other servers in the server farm. See the weight (server farm) command for more details. |
Router(config-slb-real)# inservice | 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 RESTRICTED Router(config-slb-sfarm)# real 10.1.1.1 Router(config-slb-real)# faildetect numconns 16
The following example shows how to configure maximum number of connections to 1000:
Router(config-slb-real)# maxconns 1000
The following example shows how to configure the number of consecutive unanswered SYNs to 4 that initiates assignment of the connection to a different real server:
Router(config-slb-real)# reassign 4
The 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 120
The following example shows how to configure workload capacity to 16, relative to other servers in the server farm:
Router(config-slb-real)# weight 16
The following example shows how to enable the real server back into service after making changes to its configuration:
Router(config-slb-real)# inservice
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.
To change the default settings of the virtual server values, use the related virtual server command beginning in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)# ip slb vserver virtserver-name | Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details. |
Router(config-slb-vserver)# no advertise | Omits the virtual server IP address from the routing protocol updates. See the advertise command for more details. |
Router(config-slb-vserver)# client ip-address network-mask | Specifies which clients are allowed to use the virtual server. See the client command for more details. |
Router(config-slb-vserver)# delay duration | Specifies the amount of time IOS SLB maintains TCP connection context after a connection has terminated. The default value is 10 seconds. See the delay (virtual server) command for more details. |
Router(config-slb-vserver)# idle duration | Specifies the minimum amount of time IOS SLB maintains connection context in the absence of packet activity. The default value is 3600 seconds (60 minutes). See the idle (virtual server) command for more details. |
Router(config-slb-vserver)# sticky duration [group group-id] [netmask netmask] | 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. |
Router(config-slb-vserver)# synguard syn-count interval | 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 command for more details. |
Router(config-slb-vserver)# inservice | 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_HTTP Router(config-slb-vserver)# no inservice Router(config-slb-vserver)# . (Information Deleted) . index = 1 Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0
By default, virtual server addresses are advertised. That is, static routes to the Null0 interface are installed for the virtual server addresses. To advertise these static routes using the routing protocol, you must configure redistribution of static routes for the routing protocol. To prevent the installation of a static route, use the no form of the advertise command:
Router(config-slb-vserver)# no advertise
The 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 20
The 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 180
The 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 1
The following command configures the rate of TCP SYNs to 3600000 handled by the virtual server:
Router(config-slb-vserver)# synguard 3600000
The following example enables the virtual server again after modification:
Router(config-slb-vserver)# inservice Router(config-slb-vserver)# src = 0 - 0 . (Information Deleted) . index = 1 Router(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.
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:
To configure an IOS SLB firewall load-balancing network, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# ip slb firewallfarm firewallfarm-name Router(config-slb-fw)# | 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 | Router(config-slb-fw)# real ip-address | 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 | Router(config-slb-fw-real)# pro be name | Associates a probe with the real server. See the probe (firewall farm real server) command for more details. |
Step 4 | Router(config-slb-fw-real)# wei ght weighting-value | (Optional) Specifies the real server's workload capacity relative to other servers in the firewall farm. See the weight (firewall farm real server) command for more details. |
Step 5 | Router(config-slb-fw-real)# ins ervice | Enables the real server for use by the firewall farm and by IOS SLB. See the inservice (firewall farm real server) command for more details. |
Step 6 | Router(config-slb-fw)# predicto r hash address [port] | (Optional) Specifies whether the source and destination TCP or UDP port numbers, as well as the source and destination IP addresses, are to be used in the hash algorithm used to determine how a real server is selected. See the predictor hash address (firewall farm) command for more details. |
Step 7 | Router(config-slb-fw)# replicat e casa listening-ip remote-ip port-number [interval] [password [0|7] password [timeout]] | (Optional) Configures a stateful backup of IOS SLB decision tables to a backup switch. See the replicate casa (firewall farm) command for more details. |
Step 8 | Router(config-slb-fw)# tcp | (Optional) Initiates TCP protocol configuration mode. See the tcp command for more details. |
Step 9 | Router(config-slb-fw-tcp)# dela y duration | (Optional) For firewall farm TCP protocol configuration mode, specifies the amount of time IOS SLB maintains TCP connection context after a connection has terminated. See the delay (firewall farm TCP protocol) command for more details. |
Step 10 | Router(config-slb-fw-tcp)# idle duration | (Optional) For firewall farm TCP protocol configuration mode, specifies the minimum amount of time IOS SLB maintains connection context in the absence of packet activity. See the idle (firewall farm TCP protocol) command for more details. |
Step 11 | Router(config-slb-fw-tcp)# maxc onns number-conns | (Optional) For firewall farm TCP protocol configuration mode, specifies the maximum number of active connections allowed on the real server at one time. See the maxconns (firewall farm TCP protocol) command for more details. |
Step 12 | Router(config-slb-fw-tcp)# stic ky duration [netmask netmask] | (Optional) For firewall farm TCP protocol configuration mode, specifies that connections from the same IP address use the same firewall if both of the following conditions are met:
See the sticky (firewall farm TCP protocol) command for more details. |
Step 13 | Router(config-slb-fw)# udp | (Optional) Initiates UDP protocol configuration mode. See the udp command for more details. |
Step 14 | Router(config-slb-fw-udp)# idle duration | (Optional) For firewall farm UDP protocol configuration mode, specifies the minimum amount of time IOS SLB maintains connection context in the absence of packet activity. See the idle (firewall farm TCP protocol) command for more details. |
Step 15 | Router(config-slb-fw-udp)# maxc onns number-conns | (Optional) For firewall farm UDP protocol configuration mode, specifies the maximum number of active connections allowed on the real server at one time. See the maxconns (firewall farm TCP protocol) command for more details. |
Step 16 | Router(config-slb-fw-udp)# stic ky duration [netmask netmask] | (Optional) For firewall farm UDP protocol configuration mode, specifies that connections from the same IP address use the same firewall if both of the following conditions are met:
See the sticky (firewall farm UDP protocol) command for more details. |
Step 17 | Router(config-slb-fw)# inservic e | Enables the firewall farm for use by IOS SLB. See the inservice (firewall farm) command for more details. |
Step 18 | Router(config-slb-fw-real)# exit | Return to firewall farm configuration mode. |
Step 19 | Router(config-slb-fw)# end | Return to global configuration mode. |
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. See the "Example of IOS SLB with Firewall Load Balancing" section for more details.
The following show ip slb reals command displays the status of firewall farm FIRE1, the associated real servers, and their status:
Router# show ip slb real real farm name weight state conns -------------------------------------------------------------------- 10.1.1.2 FIRE1 8 OPERATIONAL 0 10.1.2.2 FIRE1 8 OPERATIONAL 0
The following show ip slb firewallfarm command displays the configuration and status of firewall farm FIRE1:
Router# show ip slb firewallfarm firewall farm hash state reals ------------------------------------------------ FIRE1 IPADDR INSERVICE 2
To verify that IOS SLB firewall load balancing has been configured and is operating correctly:
Step 2 Ping the internal real servers (the ones inside the firewall) from the clients.
Step 3 Use the show ip slb stats command to display detailed information about the IOS SLB firewall load-balancing network status:
Router# show ip slb stats Pkts via normal switching: 0 Pkts via special switching: 0 Connections Created: 1911871 Connections Established: 1967754 Connections Destroyed: 1313251 Connections Reassigned: 0 Zombie Count: 0 Connections Reused: 59752 Connection Flowcache Purges:1776582 Failed Connection Allocs: 17945 Failed Real Assignments: 0 Router#
Step 4 Use the show ip slb real detail command to display detailed information about the IOS SLB firewall load-balancing real server status:
Router# show ip slb real detail 10.1.1.3, FIRE1, state = OPERATIONAL, type = firewall conns = 299310, dummy_conns = 0, maxconns = 4294967295 weight = 10, weight(admin) = 10, metric = 104, remainder = 2 total conns established = 1074779, hash count = 4646 server failures = 0 interface FastEthernet1/0, MAC 0010.f68f.7020 Router#
Step 5 Use the show ip slb conns command to display detailed information about the active IOS SLB firewall load-balancing connections:
Router# show ip slb conns vserver prot client real state nat ------------------------------------------------------------------------------- FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none Router#sh ip slb conn
Step 6 See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB networks and connections.
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:
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:
| Command | Description | |
|---|---|---|
Step 1 | Router(config)# ip slb probe name http | Configures the IOS SLB probe name and changes to HTTP configuration submode. See the ip slb probe (HTTP probe) command for more details. |
Step 2 | Router(config-slb-probe)# addre ss [ip-address] | (Optional) Configures the HTTP probe to receive responses from an IP address. See the address (HTTP probe) command for more details. |
Step 3 | Router(config-slb-probe)# crede ntials {username [password]} | (Optional) Configures header values for the HTTP probe. See the credentials command for more details. |
Step 4 | Router(config-slb-probe)# expec t [status number] [regex regular-expression] | (Optional) Configures the expected HTTP status code or regular expression. See the expect command for more details. |
Step 5 | Router(config-slb-probe)# heade r {name field-name [field-value]} | (Optional) Configures header values for the HTTP probe. See the header command for more details. |
Step 6 | Router(config-slb-probe)# inter val seconds | (Optional) Configures the HTTP probe transmit timers. See the interval (HTTP probe) command for more details. |
Step 7 | Router(config-slb-probe)# port port-number | (Optional) Configures the port to which the HTTP probe is to connect. See the port command for more details. |
Step 8 | Router(config-slb-probe)# reque st [method {get | post | head | name name}] [url path] | (Optional) Configures the URL path to request from the server, and the method used to perform the request to the server. See the request method, request url command for more details. |
To verify that the HTTP probe is configured correctly, use the following show ip slb probe command:
Router# show ip slb probe Server:Port State Outages Current Cumulative ---------------------------------------------------------------- 10.1.1.1:80 OPERATIONAL 0 never 00:00:00 10.1.1.2:80 OPERATIONAL 0 never 00:00:00 10.1.1.3:80 OPERATIONAL 0 never 00:00:00
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:
| Command | Description | |
|---|---|---|
Step 1 | Router(config)# ip slb probe name ping | Configures the IOS SLB probe name and changes to ping configuration submode. See the ip slb probe (ping probe) command for more details. |
Step 2 | Router(config-slb-probe)# addre ss [ip-address] | (Optional) Configures the ping probe to receive responses from an IP address. See the address (ping probe) command for more details. |
Step 3 | Router(config-slb-probe)# faild etect number-of-pings | (Optional) Specifies the number of consecutive unanswered pings that constitute failure of the real server. See the faildetect (ping probe) command for more details. |
Step 4 | Router(config-slb-probe)# inter val seconds | (Optional) Configures the ping probe transmit timers. See the interval (ping probe) command for more details. |
To verify that the ping probe is configured correctly, use the following show ip slb probe command:
Router# show ip slb probe Server:Port State Outages Current Cumulative ---------------------------------------------------------------- 13.13.13.13:80 OPERATIONAL 0 never 00:00:00
The IOS SLB Dynamic Feedback Protocol (DFP) is a mechanism that allows host agents in load-balanced environments to dynamically report the change in status of the host systems providing a virtual service. The status reported is a relative weight that specifies a host server's capacity to perform work.
To configure a DFP agent on a DFP manager (such as DistributedDirector), enter the following commands in order, beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# ip slb dfp [password [0|7] password [timeout]] | Configures DFP and initiates DFP configuration mode, and optionally sets a password. See the ip slb dfp command for more details. |
Step 2 | Router(config-slb-dfp)# | Configures a DFP agent. See the agent command for more details. |
On the DFP manager, use the following commands to:
Router(config)# ip slb dfp password Cookies 360 Router(config-slb-dfp)# agent 10.1.1.1 2221
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:
| Command | Description | |
|---|---|---|
Step 1 | Router(config)# ip slb natpool pool-name start-ip end-ip [netmask netmask | prefix-length leading_1_bits] [entries init-addr [max-addr]] | Configures the client address pool. |
Step 2 | Router(config-slb-sfarm)# nat {server | client pool-name} | 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 PUBLIC Router(config-slb-sfarm)# nat server
To configure IOS SLB NAT client mode for a specific server farm, enter the following commands in order, beginning in global configuration mode:
| Command | Description | |
|---|---|---|
Step 1 | Router(config)# ip slb natpool pool-name start-ip end-ip [netmask netmask | prefix-length leading_1_bits] [entries init-addr [max-addr]] | Configures the client address pool. |
Step 2 | Router(config)# ip slb serverfarm serverfarm-name | 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 | Router(config-slb-sfarm)# nat {server | client pool-name} | 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 | Router(config-slb-real)# inservice | 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)# exit | Return to server farm configuration mode. |
Step 7 | Router(config-slb-real)# end | Return to global configuration mode. |
Step 8 | Router(config)# ip slb vserver virtserver-name | Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details. |
This section discusses the following topics in detail:
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.
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 stateless backup requires the following:
To configure stateless backup over VLANs between IOS SLB switches, perform the following tasks in order:
|
Note When you use the inservice (server farm virtual server) command to configure the virtual server as "in-service" you must use the optional standby command and configure an HSRP group name. |
For firewall load balancing, configure the firewall farms—See the "Configuring IOS SLB Firewall Load Balancing" section.
|
Note When you use the inservice (firewall farm) command to configure the firewall farm as "in-service" you must use the optional standby command and configure an HSRP group name. |
Step 2 Configure the IP routing protocol—See the "Configuring IP Routing Protocols" chapter of the Catalyst 4840G Software Feature and Configuration Guide.
Step 3 Configure the VLAN between the switches—See the "About Virtual LANs" chapter of the Catalyst 4840G Software Feature and Configuration Guide.
Step 4 Enable HSRP—See the "Enabling HSRP" section.
Step 5 Customize group attributes—See the "Customizing Group Attributes" section.
Step 6 Verify the IOS SLB HSRP configuration—See the "Verifying the IOS SLB Stateless Backup Configuration" section.
A sample stateless backup configuration is shown in the "Sample IOS SLB Stateless Backup Configuration" section.
| Command | Purpose |
|---|---|
Router(config-if)# standby [group-number] ip [ip-address [secondary]] | Enables HSRP. |
To customize "hot standby" group attributes, use one or more of the following commands in interface configuration mode:
For server load balancing, to verify that stateless backup has been configured and is operating correctly, use the following show ip slb vserver commands to display information about the IOS SLB virtual server status:
Router# show ip slb vserver slb vserver prot virtual state conns ------------------------------------------------------------------- VS1 TCP 10.10.10.12:23 OPERATIONAL 2 VS2 TCP 10.10.10.18:23 OPERATIONAL 2 Router# show ip slb vserver detail VS1, state = OPERATIONAL, v_index = 10 virtual = 10.10.10.12:23, TCP, service = NONE, advertise = TRUE server farm = SERVERGROUP1, delay = 10, idle = 3600 sticky timer = 0, sticky subnet = 255.255.255.255 sticky group id = 0 synguard counter = 0, synguard period = 0 conns = 0, total conns = 0, syns = 0, syn drops = 0 standby group = None VS2, state = INOFSERVICE, v_index = 11 virtual = 10.10.10.18:23, TCP, service = NONE, advertise = TRUE server farm = SERVERGROUP2, delay = 10, idle = 3600 sticky timer = 0, sticky subnet = 255.255.255.255 sticky group id = 0 synguard counter = 0, synguard period = 0 conns = 0, total conns = 0, syns = 0, syn drops = 0 standby group = None
For firewall load balancing, to verify that stateless backup has been configured and is operating correctly, use the following show ip slb firewallfarm commands to display information about the IOS SLB firewall farm status:
Router# show ip slb firewallfarm
firewall farm hash state reals
------------------------------------------------
FIRE1 IPADDR INSERVICE 2
Router# show ip slb firewallfarm details
FIRE1, hash = IPADDRPORT, state = INSERVICE, reals = 2
FirewallTCP:
sticky timer = 0, sticky subnet = 255.255.255.255
idle = 3600, delay = 10, syns = 1965732, syn drop = 0
maxconns = 4294967295, conns = 597445, total conns = 1909512
FirewallUDP:
sticky timer = 0, sticky subnet = 255.255.255.255
idle = 3600
maxconns = 1, conns = 0, total conns = 1
Real firewalls:
10.1.1.3, weight = 10, OPERATIONAL, conns = 298823
10.1.1.4, weight = 10, OPERATIONAL, conns = 298622
Total connections = 597445
The following commands enable the HSRP standby group 100 IP address, priority, preempt, timers, configure a name and authentication for Device A in Figure 7:
Router(config-if)# standby 100 ip 172.20.100.10 Router(config-if)# standby 100 priority 110 Router(config-if)# standby 100 preempt Router(config-if)# standby 100 timers 5 15 Router(config-if)# standby 100 name Web_group1 Router(config-if)# standby 100 authentication Secret Router(config-if)# exit Router#
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.
To configure stateful backup to keep state across primary and backup Layer 3 switches, enter the following commands in order, beginning in global configuration mode:
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:
| Command | Description | |
|---|---|---|
Step 1 | Router(config)# ip slb vserver virtserver-name | Configures a virtual server and enters virtual server configuration mode. |
Step 2 | Router(config-slb-vserver)# replicate casa listening-ip remote-ip port-number [interval] [password [0|7] password timeout] | 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 8:
Router(config)# ip slb vserver RESTRICTED_HTTP Router(config-slb-vserver)# virtual 10.10.10.12 tcp telnet Router(config-slb-vserver)# replicate casa 10.10.3.132 10.10.99.3 1032 password PASS Router(config-slb-vserver)# inservice standby virt Router(config-slb-vserver)# . (Information Deleted)
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:
| Command | Description | |
|---|---|---|
Step 1 | Router(config)# ip slb firewallfarm firewallfarm-name | Configures a firewall farm and enters firewall farm configuration mode. |
Step 2 | Router(config-slb-fw)# replicate casa listening-ip remote-ip port-number [interval] [password [0|7] password timeout] | Configures a stateful backup of IOS SLB decision tables to a backup switch. See the replicate casa (firewall farm) command for more details. |
To obtain and display runtime information about IOS SLB, use the following commands in EXEC mode:
| Command | Purpose |
|---|---|
Router# show ip slb conns [vserver virtserver-name] [client ip-address] [detail] | 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. |
Router# show ip slb dfp [agent ip_address port-number] [detail] [weights] | 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. |
Router# show ip slb firewallfarm [detail] | Displays information about firewall farms. See the show ip slb firewallfarm command for more details. |
Router# show ip slb probe [name probe_name] [detail] | Displays information about HTTP and ping probes defined to IOS SLB. See the show ip slb probe command for more details. |
Router# show ip slb reals [vserver virtserver-name] [detail] | Displays information about the real servers defined to IOS SLB. See the show ip slb reals command for more details. |
Router# show ip slb replicate | Displays information about the IOS SLB replication configuration. See the show ip slb replicate command for more details. |
Router# show ip slb serverfarms [name serverfarm-name] [detail] | Displays information about the server farms defined to IOS SLB. See the show ip slb serverfarms command for more details. |
Router# show ip slb stats | Displays IOS SLB statistics. See the show ip slb stats command for more details. |
Router# show ip slb sticky [client ip-address] | Displays information about the sticky connections defined to IOS SLB. See the show ip slb sticky command for more details. |
Router# show ip slb vservers [name virtserver-name] [detail] | Displays information about the virtual servers defined to IOS SLB. See the show ip slb vservers command for more details. |
This section provides real-world examples of Layer 3 switching configurations and includes the following sections:
|
Note The IP and network addresses in these examples are generic, so you must replace them with the actual addresses for your network. |
The following example provides a complete configuration using the commands described in this feature module:
Router# show running-config Building configuration... Current configuration: ! . (Information Deleted) . ip slb probe PROBE2 http request method POST url /probe.cgi?all header Cookie Monster header Authorization Basic U2VtaXN3ZWV0OmNoaXBz ! ip slb serverfarm PUBLIC nat server real 10.1.1.1 inservice real 10.1.1.2 inservice real 10.1.1.3 inservice probe PROBE2 ! ip slb serverfarm RESTRICTED predictor leastconns bindid 309 real 10.1.1.1 weight 32 maxconns 1000 reassign 4 faildetect numconns 16 retry 120 inservice real 10.1.1.20 inservice real 10.1.1.21 inservice ! ip slb vserver PUBLIC_HTTP virtual 10.0.0.1 tcp www serverfarm PUBLIC no inservice ! ip slb vserver RESTRICTED_HTTP virtual 10.0.0.2 tcp www serverfarm RESTRICTED no advertise sticky 60 group 1 idle 1800 client 10.4.4.0 255.255.255.0 synguard 3600000 inservice !
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-zero no ip domain-lookup ip name-server 171.69.2.132 ip name-server 198.92.30.32 ip multicast-routing ip dvmrp route-limit 20000 bridge irb ! interface FastEthernet1no ip address no ip directed-broadcast no keepalive
! interface FastEthernet1.128ip address 172.68.16.10 255.255.255.0 ip helper-address 172.68.16.15 no ip redirects no ip directed-broadcast ip pim dense-mode ip multicast ttl-threshold 1 encapsulation isl 128
! interface FastEthernet1.199ip address 172.68.17.15 255.255.255.0 ip helper-address 172.68.16.16 ip helper-address 172.68.16.17 ip helper-address 172.68.16.18 no ip redirects no ip directed-broadcast ip pim dense-mode ip multicast ttl-threshold 1 encapsulation isl 199
! interface FastEthernet1.201ip address 172.68.18.10 255.255.255.0 ip helper-address 172.68.16.16 ip helper-address 172.68.16.17 ip helper-address 172.68.16.18 no ip redirects no ip directed-broadcast ip pim dense-mode ip multicast ttl-threshold 1 encapsulation isl 201
! interface FastEthernet2no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet3no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet4no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet5no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet6no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet7no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet8no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet9ip address 172.68.19.10 255.255.255.0 ip helper-address 172.68.16.16 ip helper-address 172.68.16.17 ip helper-address 172.68.16.18 no ip redirects no ip directed-broadcast ip pim dense-mode ip multicast ttl-threshold 1 ip sdr listen no keepalive
! interface FastEthernet10no ip address no ip directed-broadcast no keepalive shutdown
! interface FastEthernet11no ip address no ip directed-broadcast no keepalive shutdown
! . (Information Deleted) . interface GigabitEthernet41 snoop interface FastEthernet3 direction both snoop interface FastEthernet5 direction both snoop interface FastEthernet6 direction bothip address 172.68.21.10 255.255.255.0 ip helper-address 172.68.16.19 ip helper-address 172.68.16.20 ip helper-address 172.68.16.21
!
interface GigabitEthernet42
ip address 172.68.1.1 255.255.255.0
no ip directed-broadcast
ip pim sparse-dense-mode
!
interface BVI1
ip address 171.201.1.2 255.255.255.0
no ip directed-broadcast
ip pim dense-mode
no ip route-cache cef
!
interface Ethernet0
ip address 172.68.20.10 255.255.255.0
no ip directed-broadcast
! router eigrp 170 network 171.200.0.0 network 171.201.0.0 network 172.68.0.0 network 172.69.0.0 no auto-summary ! router bgp 180 network 172.68.1.0 network 172.69.1.0 no auto-summary ! ip classless ! bridge 1 protocol ieee bridge 1 route ip ! ip http server ! line con 0 line aux 0 line vty 0 4login
! ntp clock-period 17181168 ntp update-calendar ntp server 171.71.150.52 ntp server 171.69.4.143 ntp server 171.69.5.10 end
Figure 3 shows a sample IOS SLB firewall load-balancing network with the following components:
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 farm configuration samples:
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 probe router(config-slb-probe)# address 10.1.1.1 ; IP address of other load-balancing device router(config-slb-probe)# faildetect 4 router(config-slb-probe)# ip slb probe PROBE2 http ; HTTP probe router(config-slb-probe)# address 10.1.2.1 ; IP address of other load-balancing device router(config-slb-probe)# expect status 401 router(config-slb-probe)# ip slb firewallfarm FIRE1 ; Firewall farm FIRE1 router(config-slb-fw)# real 10.1.4.1 ; First firewall router(config-slb-fw-real)# probe PROBE1 router(config-slb-fw-real)# inservice ; Enable first firewall router(config-slb-fw-real)# real 10.1.3.1 ; Second firewall router(config-slb-fw-real)# probe PROBE2 router(config-slb-fw-real)# inservice ; Enable second firewall router(config-slb-fw-real)# exit router(config-slb-fw)# inservice ; Turn on 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 probe router(config-slb-probe)# address 10.1.4.2 ; IP address of other load-balancing device router(config-slb-probe)# faildetect 4 router(config-slb-probe)# ip slb probe PROBE2 http ; HTTP probe router(config-slb-probe)# address 10.1.3.2 ; IP address of other load-balancing device router(config-slb-probe)# expect status 401 router(config-slb-probe)# ip slb firewallfarm FIRE1 ; Firewall farm FIRE1 router(config-slb-fw)# real 10.1.1.2 ; First firewall router(config-slb-fw-real)# probe PROBE1 router(config-slb-fw-real)# inservice ; Enable first firewall router(config-slb-fw-real)# real 10.1.2.2 ; Second firewall router(config-slb-fw-real)# probe PROBE2 router(config-slb-fw-real)# inservice ; Enable second firewall router(config-slb-fw-real)# exit router(config-slb-fw)# inservice ; Turn on firewall load-balancing device
Figure 4 shows an example configuration with IOS SLB real server connections configured as part of a server farm, focusing on using ping and HTTP probe to monitor applications being server load-balanced.
:
The topology shown in Figure 4 is a heterogeneous server farm servicing a single virtual server. Following are the configuration statements for this topology, including a ping probe named PROBE1 and an HTTP probe named PROBE2:
! Configure ping probe PROBE1, change CLI to IOS SLB probe configuration mode Router(config)# ip slb probe PROBE1 ping ! Configure probe to receive responses from IP address 13.13.13.13 Router(config-slb-probe)# address 13.13.13.13 ! Configure unanswered ping threshold to 16 Router(config-slb-probe)# faildetect 16 ! Configure ping probe timer interval to transmit every 11 seconds Router(config-slb-probe)# interval 11 ! Configure HTTP probe PROBE2 Router(config-slb-probe)# ip slb probe PROBE2 http ! Configure request method as POST, set URL as /probe.cgi?all Router(config-slb-probe)# request method post url /probe.cgi?all ! Configure header Cookie Router(config-slb-probe)# header Cookie Monster ! Configure basic authentication username and password Router(config-slb-probe)# credentials Semisweet chips ! Exit to global configuration mode Router(config-slb-probe)# exit ! Enter IOS SLB server farm configuration mode for server farm PUBLIC Router(config)# ip slb serverfarm PUBLIC ! Configure NAT server and real servers on the server farm Router(config-slb-sfarm)# nat server Router(config-slb-sfarm)# real 10.1.1.1 Router(config-slb-sfarm)# inservice Router(config-slb-sfarm)# real 10.1.1.2 Router(config-slb-sfarm)# inservice Router(config-slb-sfarm)# real 10.1.1.3 Router(config-slb-sfarm)# inservice Router(config-slb-sfarm)# real 10.1.1.4 Router(config-slb-sfarm)# inservice Router(config-slb-sfarm)# real 10.1.1.5 Router(config-slb-sfarm)# inservice ! Configure ping probe on the server farm Router(config-slb-sfarm)# probe PROBE1 ! Configure HTTP probe on the server farm Router(config-slb-sfarm)# probe PROBE2 Router(config-slb-sfarm)# end
Figure 5 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.
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 farm ip slb serverfarm PUBLIC ! Use weighted least connections algorithm predictor leastconns ! First real server real 10.1.1.1 weight 16 inservice ! Second real server real 10.1.1.2 weight 4 ! Restrict maximum number of connections maxconns 1000 inservice ! Third real server real 10.1.1.3 weight 24 inservice ! Restricted Web server farm ip slb serverfarm RESTRICTED ! Use weighted least connections algorithm predictor leastconns ! First real server real 10.1.1.20 in-service ! Second real server real 10.1.1.21 in-service ! ! Unrestricted Web virtual server ip slb vserver PUBLIC_HTTP ! Handle HTTP requests virtual 10.0.0.1 tcp www ! Use public Web server farm serverfarm PUBLIC inservice ! ! Restricted HTTP virtual server ip slb vserver RESTRICTED_HTTP ! Handle HTTP requests virtual 10.0.0.1 tcp www ! Use restricted Web server farm serverfarm RESTRICTED ! Only allow clients from 10.4.4.x client 10.4.4.0 255.255.255.0 ! Couple connections with RESTRICTED_SSL sticky 60 group 1 inservice !
! Restricted SSL virtual server ip slb vserver RESTRICTED_SSL ! Handle SSL requests virtual 10.0.0.1 tcp https ! Use restricted Web server farm serverfarm RESTRICTED ! Only allow clients from 10.4.4.x client 10.4.4.0 255.255.255.0 ! Couple connections with RESTRICTED_WEB sticky 60 group 1 inservice
Figure 6 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.
The topology in Figure 6 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.
ip slb serverfarm FARM1 ! Translate server addresses nat server ! Server 1 port 80 real 10.1.1.1 inservice ! Server 2 port 80 real 10.2.1.1 inservice ! ip slb vserver HTTP1 ! Handle HTTP (port 80) requests virtual 128.1.0.1 tcp www serverfarm FARM1 inservice
ip slb natpool web-clients 128.3.0.1 128.3.0.254 ! NAT address pool for clients ip slb serverfarm FARM2 ! Translate server addresses nat server ! Translate client addresses nat client web-clients ! Server 3 port 80 real 10.3.1.1 inservice ! Server 4 port 8080 real 10.4.1.1 port 8080 inservice ! Server 4 port 8081 real 10.4.1.1 port 8081 inservice ! Server 4 port 8082 real 10.4.1.1 port 8082 inservice ! ip slb vserver HTTP2 ! Handle HTTP (port 80) requests virtual 128.2.0.1 tcp www serverfarm FARM2 inservice
ip slb natpool web-clients 128.5.0.1 128.5.0.254 ! NAT address pool for clients ip slb serverfarm FARM2 ! Translate server addresses nat server ! Translate client addresses nat client web-clients ! Server 3 port 80 real 10.3.1.1 inservice ! Server 4 port 8080 real 10.4.1.1 port 8080 inservice ! Server 4 port 8081 real 10.4.1.1 port 8081 inservice ! Server 4 port 8082 real 10.4.1.1 port 8082 inservice ! ip slb vserver HTTP2 ! Handle HTTP (port 80) requests virtual 128.4.0.1 tcp www serverfarm FARM2 inservice
Figure 7 shows the topology of an IP network with two Layer 3 switches configured for HSRP.
In this network:
|
Note Some configurations that use HSRP still require a routing protocol for convergence when a topology change occurs. The standby Layer 3 switch becomes active, but connectivity does not occur until convergence occurs. |
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.
hostname Device A ! ip slb serverfarm ServerGroup1 real 172.20.100.3 inservice real 172.20.100.4 inservice ! ip slb serverfarm ServerGroup2 real 172.20.200.3 inservice real 172.20.200.4 inservice ! ip slb vserver VS1 virtual 10.10.10.12 tcp 23 serverfarm ServerGroup1 in-service standby Web_Group1 ! ip slb vserver VS2 virtual 10.10.10.18 tcp 23 serverfarm ServerGroup2 in-service standby Web_Group2 ! ip routing router rip network 172.20.0.0 ! interface vlan100 ip address 172.20.100.1 255.255.255.0 standby 100 ip 172.20.100.10 standby 100 priority 110 standby 100 preempt standby 100 timers 5 15 standby 100 name Web_Group1 standby 100 authentication Secret ! interface vlan200 ip address 172.20.200.1 255.255.255.0 standby 200 ip 172.20.200.10 standby 200 priority 110 standby 200 preempt standby 200 timers 5 15 standby 200 name Web_Group2 standby 200 authentication Covert !
hostname Device B ! ip slb serverfarm ServerGroup1 real 172.20.100.3 inservice real 172.20.100.4 inservice ! ip slb serverfarm ServerGroup2 real 172.20.200.3 inservice real 172.20.200.4 inservice ! ip slb vserver VS1 virtual 10.10.10.12 tcp 23 serverfarm ServerGroup1 in-service standby Web_Group1 ! ip slb vserver VS2 virtual 10.10.10.18 tcp 23 serverfarm ServerGroup2 in-service standby Web_Group2 ! ip routing router rip network 172.20.0.0 ! interface vlan100 ip address 172.20.100.2 255.255.255.0 standby 100 ip 172.20.100.10 standby 100 preempt standby 100 timers 5 15 standby 100 name Web_Group1 standby 100 authentication Secret ! interface vlan200 ip address 172.20.200.2 255.255.255.0 standby 200 ip 172.20.200.10 standby 200 preempt standby 200 timers 5 15 standby 200 name Web_Group2 standby 200 authentication Covert
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 number 100 establishes Hot Standby group 100. (If you do not specify a group number, the default is group 0.) 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. The number 100 indicates that this command applies to Hot Standby group 100. 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 number 100 indicates that this command applies to Hot Standby group 100.
The standby timers interface configuration command sets the interval (in seconds) between hello messages (called the hello time) to five 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 eight seconds. (The defaults are three 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 number 100 indicates that this command applies to Hot Standby group 100.
The standby name interface configuration command associates the IOS SLB interface with an HSRP group name (in this case, Web-Group), previously specified on an inservice (server farm virtual server) command. The number 100 indicates that this command applies to Hot Standby group 100.
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. The number 100 indicates that this command applies to Hot Standby group 100.
Figure 8 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 To allow HSRP to function properly, set spantree portfast must be configured on any Layer 2 device between the IOS SLB switches. |
ip slb serverfarm SF1 nat server real 10.10.3.1 inservice real 10.10.3.2 inservice real 10.10.3.3 inservice ! ip slb vserver VS1 virtual 10.10.10.12 tcp telnet serverfarm SF1 replicate casa 10.10.99.132 10.10.99.99 1024 password PASS inservice standby virt ! interface Loopback1 ip address 10.10.99.132 255.255.255.255 ! interface FastEthernet1 ip address 10.10.3.132 255.255.255.0 no ip redirects no ip mroute-cache standby priority 5 preempt standby name out standby ip 10.10.3.100 standby track FastEthernet2 !
interface FastEthernet2 ip address 10.10.2.132 255.255.255.0 no ip redirects standby priority 5 preempt standby name virt standby ip 10.10.2.100 standby track FastEthernet1
ip slb serverfarm SF1 nat server real 10.10.3.1 inservice real 10.10.3.2 inservice real 10.10.3.3 inservice ! ip slb vserver VS1 virtual 10.10.10.12 tcp telnet serverfarm SF1 replicate casa 10.10.99.99 10.10.99.132 1024 password PASS inservice standby virt ! interface Loopback1 ip address 10.10.99.99 255.255.255.255 ! interface FastEthernet2 ip address 10.10.2.99 255.255.255.0 no ip redirects no ip route-cache no ip mroute-cache standby priority 10 preempt standby name virt standby ip 10.10.2.100 standby track FastEthernet3 ! interface FastEthernet3 ip address 10.10.3.99 255.255.255.0 no ip redirects no ip route-cache no ip mroute-cache standby priority 10 preempt standby name out standby ip 10.10.3.100 standby track FastEthernet2
Figure 9 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.
The sample network configuration in Figure 9 has the following characteristics:
ip slb serverfarm EVEN nat server real 10.10.3.2 inservice real 10.10.3.3 inservice ! ip slb serverfarm ODD nat server real 10.10.3.2 inservice real 10.10.3.3 inservice ! ip slb vserver EVEN ; Same EVEN virtual server as in SLB 2 virtual 10.10.10.12 tcp www serverfarm EVEN client 0.0.0.0 0.0.0.1 inservice standby STANDBY_EVEN ; See standby name in Ethernet 3/3 below ! ip slb vserver ODD ; Same ODD virtual server as in SLB 2 virtual 10.10.10.12 tcp www serverfarm ODD client 0.0.0.1 0.0.0.1 inservice standby STANDBY_ODD ; See standby name in Ethernet 3/2 below ! interface Ethernet3/2 ip address 10.10.5.132 255.255.255.0 standby priority 20 preempt standby name STANDBY_ODD ; See standby name in SLB 2, Ethernet 3/5 standby ip 10.10.5.100 ! interface Ethernet3/3 ip address 10.10.2.132 255.255.255.0 standby priority 10 standby name STANDBY_EVEN ; See standby name in SLB 2, Ethernet 3/1 standby ip 10.10.2.100
ip slb serverfarm EVEN nat server real 10.10.3.4 inservice real 10.10.3.5 inservice ! ip slb serverfarm ODD nat server real 10.10.3.4 inservice real 10.10.3.5 inservice ! ip slb vserver EVEN ; Same EVEN virtual server as in SLB 1 virtual 10.10.10.12 tcp www serverfarm EVEN client 0.0.0.0 0.0.0.1 inservice standby STANDBY_EVEN ; See standby name in Ethernet 3/1 below ! ip slb vserver ODD ; Same ODD virtual server as in SLB 1 virtual 10.10.10.12 tcp www serverfarm ODD client 0.0.0.1 0.0.0.1 inservice standby STANDBY_ODD ; See standby name in Ethernet 3/5 below ! interface Ethernet3/1 ip address 10.10.2.128 255.255.255.0 standby priority 20 preempt standby name STANDBY_EVEN ; See standby name in SLB 1, Ethernet 3/3 standby ip 10.10.2.100 ! interface Ethernet3/5 ip address 10.10.5.128 255.255.255.0 standby priority 10 preempt standby name STANDBY_ODD ; See standby name in SLB 1, Ethernet 3/2 standby ip 10.10.5.100
interface Ethernet0/0 ip address 10.10.5.183 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ! interface Ethernet0/1 ip address 10.10.2.183 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ! interface Ethernet0/2 ip address 10.10.6.183 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ip policy route-map virts ! access-list 100 permit ip 0.0.0.1 255.255.255.254 host 10.10.10.12 access-list 101 permit ip 0.0.0.0 255.255.255.254 host 10.10.10.12 route-map virts permit 10 match ip address 100 set ip next-hop 10.10.5.100 ! route-map virts permit 15 match ip address 101 set ip next-hop 10.10.2.100 !
Figure 10 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.
Following is the RIP static route redistribution configuration for the IOS SLB switch shown in Figure 10:
router rip redistribute static network 10.0.0.0 network 8.0.0.0
Following is the RIP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 10:
router rip network 10.0.0.0 network 8.0.0.0
Following is the OSPF static route redistribution configuration for the IOS SLB switch shown in Figure 10:
router ospf 1 redistribute static subnets network 10.10.6.217 0.0.0.0 area 0 network 8.8.8.0 0.0.0.255 area 0
Following is the OSPF static route redistribution configuration for the access router that is listening for routing updates shown in Figure 10:
router ospf 1 network 10.10.6.2 0.0.0.0 area 0 network 8.8.8.0 0.0.0.255 area 0
Following is the IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 10:
router igrp 1 redistribute connected redistribute static network 8.0.0.0 network 10.0.0.0
Following is the IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 10:
router igrp 1 network 8.0.0.0 network 10.0.0.0
Following is the Enhanced IGRP static route redistribution configuration for the IOS SLB switch shown in Figure 10:
router eigrp 666 redistribute static network 10.0.0.0 network 8.0.0.0
Following is the Enhanced IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 10:
router eigrp 666 network 10.0.0.0 network 8.0.0.0
Figure 11 shows an IOS SLB network configured to balance WAP flows on UDP port 9203 (WSP/WTP/WTLS/UDP). In this example:
ip slb probe PROBE1 ping ! ip slb serverfarm WAPFARM nat server real 10.10.2.1 inservice real 10.10.2.2 inservice probe PROBE1 ! ip slb vserver VSERVER virtual 10.10.1.1 udp 9203 serverfarm WAPFARM idle 3000 inservice
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.1 and 12.1(3)T command reference publications.
To specify that an HTTP probe is to receive responses from an IP address, use the address HTTP probe configuration command. To restore the default settings, use the no form of this command.
address [ip-address]
Syntax Description
ip-address (Optional) Configures the destination IP address that is to respond to the HTTP probe.
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
12.1(3a)E This command was introduced.
Release
Modification
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 http Router(config-slb-probe)# address 13.13.13.13
Related Commands
Configures the IP IOS SLB probe name. Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
To specify that a ping probe is to receive responses from an IP address, use the address ping probe configuration command. To restore the default settings, use the no form of this command.
address [ip-address]
Syntax Description
ip-address (Optional) Configures the destination IP address that is to respond to the ping probe.
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
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example configures a ping probe named PROBE1, 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 PROBE1 ping Router(config-slb-probe)# address 13.13.13.13
Related Commands
Configures the IP IOS SLB probe name. Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
By default, virtual server addresses are advertised. That is, static routes to the Null0 interface are installed for the virtual server addresses.
To control the installation of a static route to the Null0 interface for a virtual server address, use the advertise virtual server configuration command. Advertisement of this static route using the routing protocol requires that you configure redistribution of static routes for the routing protocol. To prevent the installation of a static route for the virtual server IP address, use the no form of this command.
advertiseSyntax Description
This command has no arguments or keywords.
Defaults
The virtual server IP address is added to the routing table.
Command Modes
Virtual server configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example prevents advertisement of the virtual server's IP address in routing protocol updates:
Router(config)# ip slb vserver PUBLIC_HTTP Router(config-slb-vserver)# no advertise
Related Commands
Displays information about the virtual servers.
Command
Description
To configure a DFP agent on the DFP manager, use the agent DFP configuration command. To remove an agent definition from the DFP configuration, use the no form of this command.
agent ip-address port-number [timeout [retry_count [retry_interval]]]
Syntax Description
ip-address Agent IP address port-number Agent TCP or UDP port number timeout (Optional) Time period, in seconds, during which the DFP manager must receive an update from the DFP agent. The default is 0 seconds, which means there is no timeout. retry_count (Optional) Number of times the DFP manager attempts to establish the TCP connection to the DFP agent. The default is 0 retries, which means there are infinite retries. retry_interval (Optional) Interval, in seconds, between retries. The default is 180 seconds.
Defaults
Timeout default: 0 seconds (no timeout)
Retry_count default: 0 (infinite retries)
Retry_interval default: 180 seconds
Command Modes
DFP configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
Usage Guidelines
You can configure up to 1024 agents.
A DFP agent collects status information about a server's load capability and reports that information to a load manager. The DFP agent can reside on the server, or it can be a separate device that collects and consolidates the information from several servers before reporting to the load manager.
Examples
The following example configures a DFP agent on the DFP manager, sets the DFP password to Cookies and the timeout to 360 seconds, changes the CLI to DFP configuration mode, sets the IP address of the DFP agent to 10.1.1.1, and sets the port number of the DFP agent to 2221 (FTP):
Router(config)# ip slb dfp password Cookies 360 Router(config-slb-dfp)# agent 10.1.1.1 2221
Related Commands
Configures DFP and initiates DFP configuration mode, and optionally sets a password.
Command
Description
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]
Syntax Description
bind_id (Optional) Bind ID number. The default bind ID is 0.
Defaults
Bind_id default: 0
Command Modes
Server farm configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
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 PUBLIC Router(config-slb-sfarm)# bindid 309
Related Commands
Configures DFP and initiates DFP configuration mode, and optionally sets a password. Displays information about the IOS SLB server farms.
Command
Description
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
connections Clears the IOS SLB connection database. serverfarm (Optional) Clears the connection database for the serverfarm named. farm_name (Optional) Character string used to identify the serverfarm. vserver (Optional) Clears the connection database for the virtual server named. server_name (Optional) Character string used to identify the virtual server. counters Clears the IOS SLB counters.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
12.1(1)E This command was introduced.
Release
Modification
Examples
The following example clears the connection database of server farm FARM1:
Router# clear ip slb connections serverfarm FARM1
The following example clears the connection database of virtual server VSERVER1:
Router# clear ip slb connections vserver VSERVER1
The following example clears the IOS SLB counters:
Router# clear ip slb counters
Related Commands
Displays information about the IOS SLB connections. Displays information about the firewall farm configuration. Displays information about the IOS SLB server farms. Displays IOS SLB statistics. Displays information about the IOS SLB virtual servers.
Command
Description
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
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
Ip_address default: 0.0.0.0 (all clients)
Network_mask default: 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
12.0(7)XE This command was introduced.
Release
Modification
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_HTTP Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0
Related Commands
Displays information about the virtual servers. Configures the virtual server attributes.
Command
Description
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]
Syntax Description
username Configures the authentication username of the HTTP probe header. The character string is limited to 15 characters. password (Optional) Configures the authentication password of the HTTP probe header. The character string is limited to 15 characters.
Defaults
No default behavior or values.
Command Modes
HTTP probe configuration
Command History
12.1(2)E This command was introduced.
Release
Modification
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 http Router(config-slb-probe)# credentials lauren develop
Related Commands
Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
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
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
12.1(3a)E This command was introduced.
Release
Modification
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).
Examples
The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# tcp Router(config-slb-fw-tcp)# delay 30
Related Commands
Displays information about the firewall farm configuration. Initiates TCP protocol configuration mode.
Command
Description
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
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
12.0(7)XE This command was introduced.
Release
Modification
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).
Examples
The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:
Router(config)# ip slb vserver PUBLIC_HTTP Router(config-slb-vserver)# delay 30
Related Commands
Displays information about the virtual servers. Configures the virtual server attributes.
Command
Description
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]
Syntax Description
status (Optional) Specifies that a status code is to be expected. status-code (Optional) Configures the expected HTTP status code. The valid range is 100 to 599. The default expected status code is 200. regex (Optional) Specifies that a regular expression is to be expected. regular-expression (Optional) Configures the regular expression expected in the HTTP response.
Defaults
The default expected status code is 200.
There is no default expected regular expression.
Command Modes
HTTP probe configuration
Command History
12.1(2)E This command was introduced. 12.1(3a)E The regex keyword and regular-expression variable were added.
Release
Modification
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 http Router(config-slb-probe)# expect status 401 regex Copyright
Related Commands
Configures the IP IOS SLB probe name. Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
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
Syntax Description
number-of-pings Number of consecutive unanswered pings allowed before a real server is considered to have failed. Valid range is 1 to 255. The default is 10 unanswered pings.
Defaults
The default value is 10 unanswered pings.
Command Modes
Ping probe configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
Examples
In the following example the unanswered ping threshold is set to 16:
Router(config)# ip slb probe PROBE1 ping Router(config-slb-probe)# faildetect 16
Related Commands
Identifies a firewall as a member of a firewall farm and initiates real server configuration mode. Displays information about the firewall farm configuration. Displays information about the real servers.
Command
Description
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]
Syntax Description
numconns Number of consecutive TCP connection reassignments allowed before a real server is considered to have failed. number-conns Connection reassignment threshold value in the range from 1 to 255. The default is 8 connection failures. numclients (Optional) Number of unique client connection failures allowed before a real server is considered to have failed. number-clients (Optional) Client connection reassignment threshold value in the range from 1 to 8. The default is 2 client connection failures.
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
12.0(7)XE This command was introduced.
Release
Modification
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 PUBLIC Router(config-slb-sfarm)# real 10.10.1.1 Router(config-slb-real)# faildetect numconns 16
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the server farm configuration. Displays information about the real servers.
Command
Description
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]
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: close User-Agent: cisco-slb-probe/1.0 Host: virtual IP address
Command Modes
HTTP probe configuration
Command History
12.1(2)E This command was introduced.
Release
Modification
Usage Guidelines
The header HTTP probe configuration command configures the name and value parameters of the header.
|
Note The colon ( : ) separating the field-name and field-value is automatically inserted if not provided. Multiple headers with the same name are not allowed. |
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 http Router(config-slb-probe)# header Cookie Monster
Related Commands
Configures the IP IOS SLB probe name. Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
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
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
12.1(3a)E This command was introduced.
Release
Modification
Usage Guidelines
TCP connections that do not send flows or keepalives before the idle timer expires are assumed to be inactive and are reset (RST).
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# tcp Router(config-slb-fw-tcp)# idle 120
Related Commands
Displays information about the firewall farm configuration. Initiates TCP protocol configuration mode.
Command
Description
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
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
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# udp Router(config-slb-fw-udp)# idle 120
Related Commands
Displays information about the firewall farm configuration. Initiates UDP protocol configuration mode.
Command
Description
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
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
Virtual server configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
Usage Guidelines
TCP connections that do not send flows or keepalives before the idle timer expires are assumed to be inactive and are reset (RST).
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb vserver PUBLIC_HTTP Router(config-slb-vserver)# idle 120
Related Commands
Displays information about the virtual servers. Configures the virtual server attributes.
Command
Description
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]
Syntax Description
standby (Optional) Configures the HSRP standby firewall farm for use with stateless and stateful backup. groupname (Optional) Specifies the HSRP group name with which the IOS SLB firewall farm is associated.
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
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example enables the firewall farm for use by the IOS SLB feature:
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# inservice
Related Commands
Identifies a firewall farm and enters firewall farm configuration mode. Displays information about the firewall farm configuration.
Command
Description
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.
inserviceSyntax 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
12.1(3a)E This command was introduced.
Release
Modification
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.
Examples
The following example enables the firewall for use by the IOS SLB feature:
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# real 10.10.1.1 Router(config-slb-fw-real)# inservice
Related Commands
Identifies a firewall as a member of a firewall farm and initiates real server configuration mode. Displays information about the firewall farm configuration. Displays information about the real servers.
Command
Description
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.
inserviceSyntax 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
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example enables the real server for use by the IOS SLB feature:
Router(config)# ip slb serverfarm PUBLIC Router(config-slb-sfarm)# real 10.10.1.1 Router(config-slb-sfarm-real)# inservice
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the server farm configuration. Displays information about the real servers.
Command
Description
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]
Syntax Description
standby (Optional) Configures the HSRP standby virtual server for use with stateless and stateful backup. groupname (Optional) Specifies the HSRP group name with which the IOS SLB virtual server is associated.
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.
Release
Modification
Examples
The following example enables the virtual server for use by the IOS SLB feature:
Router(config)# ip slb vserver PUBLIC_HTTP Router(config-slb-vserver)# inservice
Related Commands
Displays information about the virtual servers. Configures the virtual server attributes.
Command
Description
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
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
12.1(2)E This command was introduced.
Release
Modification
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 http Router(config-slb-probe)# interval 11
Related Commands
Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
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
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
12.1(3a)E This command was introduced.
Release
Modification
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 ping Router(config-slb-probe)# interval 11
Related Commands
Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
To configure DFP and supply an optional password, 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]]
Syntax Description
password (Optional) Specifies a password for MD5 authentication. 0 (Optional) Specifies that the password is unencrypted. This is the default setting. 7 (Optional) Specifies that the password is encrypted. password (Optional) Password value for MD5 authentication. This password must match the password configured on the host agent. timeout (Optional) Delay period, in seconds, during which both the old password and the new password are accepted. The default value is 180 seconds.
Defaults
The password encryption default is 0 (unencrypted).
The password timeout default is 180 seconds.
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.
Release
Modification
Usage Guidelines
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 360 Router(config-slb-dfp)#
Related Commands
Configures a DFP agent.
Command
Description
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]] ]
Syntax Description
conn (Optional) Configure an initial allocation and a maximum value for IOS SLB connection database entries. init-conn (Optional) Initial allocation of connection database entries. The number of connection database entries can grow dynamically: When the number of available connection database entries is less than half of init-conn, IOS SLB allocates additional connection database entries. Valid range is 1 to 1000000 connection database entries. The default is 8000 connection database entries. max-conn (Optional) Maximum number of connection database entries that can be allocated. Valid range is 1 to 8000000 connection database entries. The default is 8000000 connection database entries. frag (Optional) Configure an initial allocation and a maximum value for IOS SLB fragment database entries. init-frag (Optional) Initial allocation of fragment database entries. The number of fragment database entries can grow dynamically: When the number of available fragment database entries is less than half of init-frag, IOS SLB allocates additional fragment database entries. Valid range is 1 to 1000000 fragment database entries. The default is 2000 fragment database entries. max-frag (Optional) Maximum number of fragment database entries that can be allocated. Valid range is 1 to 8000000 fragment database entries. The default is 32000 fragment database entries. sticky (Optional) Configure an initial allocation and a maximum value for IOS SLB sticky connection database entries. init-sticky (Optional) Initial allocation of sticky database entries. The number of sticky database entries can grow dynamically: When the number of available sticky database entries is less than half of init-sticky, IOS SLB allocates additional sticky database entries. Valid range is 1 to 1000000 sticky database entries. The default is 4000 sticky database entries. max-sticky (Optional) Maximum number of sticky database entries that can be allocated. Valid range is 1 to 8000000 sticky database entries. The default is 8000000 sticky database entries.
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
12.1(2)E This command was introduced.
Release
Modification
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 512000
Related Commands
Displays all connections handled by IOS SLB, or, optionally, only those connections associated with a particular virtual server or client.
Command
Description
To identify a firewall farm and enter 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
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
12.1(3a)E This command was introduced.
Release
Modification
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 FIRE1 Router(config-slb-fw)#?
Related Commands
Identifies a firewall as a member of a firewall farm and initiates real server configuration mode.
Command
Description
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]]
Syntax Description
pool-name Configures a character string used to identify this client address pool. The character string is limited to 15 characters. start-ip Configures a starting IP address that defines the range of addresses in the address pool. end-ip Configures an ending IP address that defines the range of addresses in the address pool. netmask (Optional) Keyword used to configure the subnet mask. netmask (Optional) Mask for the associated IP subnet. prefix-length (Optional) Keyword used to configure the subnet mask. leading_1_bits (Optional) Mask for the associated IP subnet. entries (Optional) Configure an initial allocation and a maximum value for IOS SLB client NAT address entries for pool-name. init-addr (Optional) Initial allocation of client NAT address entries. The number of client NAT address entries can grow dynamically: When the number of available client NAT address entries is less than half of init-addr, IOS SLB allocates additional client NAT address entries. Valid range is 1 to 1000000 client NAT address entries. The default is 8000 client NAT address entries. max-addr (Optional) Maximum number of client NAT address entries that can be allocated. Valid range is 1 to 8000000 client NAT address entries. The default is the maximum number of ports that can be allocated within the IP address range specified for pool-name. For example, the following command: has a default max-addr of (3.3.3.1-3.3.3.5)*54535, or 4*54535, or 218140.
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
12.1(2)E This command was introduced.
Release
Modification
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.0
Related Commands
Displays information about the server farm configuration.
Command
Description
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
Syntax Description
name Configures a name for the HTTP probe. The character string is limited to 15 characters.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
12.1(2)E This command was introduced.
Release
Modification
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 for each server farm, or for each firewall in a firewall farm.
Examples
The following example configures an IOS SLB probe named PROBE2, then changes to HTTP configuration submode:
Router(config)# ip slb probe PROBE2 http Router(config-slb-probe)#
Related Commands
Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
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
Syntax Description
name Configures a name for the ping probe. The character string is limited to 15 characters.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
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 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 configuration submode:
Router(config)# ip slb probe PROBE1 ping Router(config-slb-probe)#
Related Commands
Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
To identify a server farm and enter 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
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
12.0(7)XE This command was introduced.
Release
Modification
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 PUBLIC Router(config-slb-sfarm)#?
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode.
Command
Description
To identify a virtual server and enter 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 virtserver-name
Syntax Description
virtserver-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
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example identifies a virtual server named PUBLIC_HTTP:
Router(config)# ip slb vserver PUBLIC_HTTP Router(config-slb-vserver)#
Related Commands
Associates a real server farm with a virtual server. Displays information about the virtual servers.
Command
Description
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
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
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# tcp Router(config-slb-fw-tcp)# maxconns 1000
Related Commands
Displays information about the firewall farm configuration. Displays information about the real servers. Initiates TCP protocol configuration mode.
Command
Description
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
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
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# udp Router(config-slb-fw-udp)# maxconns 1000
Related Commands
Displays information about the firewall farm configuration. Displays information about the real servers. Initiates UDP protocol configuration mode.
Command
Description
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
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
Maximum_number default: 4294967295
Command Modes
Real server configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb serverfarm PUBLIC Router(config-slb-sfarm)# real 10.10.1.1 Router(config-slb-real)# maxconns 1000
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the server farm configuration. Displays information about the real servers.
Command
Description
To configure IOS SLB NAT you must specify which NAT mode is to be using the nat configuration command. To remove a NAT configuration, use the no form of this command.
nat {server | client pool-name}
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.
Release
Modification
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 FARM2 Router(config-slb-sfarm)# nat server
The 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-clients Router(config-slb-sfarm)# real 10.3.1.1
Related Commands
Associates a real server farm with a virtual server. Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the server farm configuration.
Command
Description
To specify the port to which an HTTP probe is to connect, use the port HTTP probe configuration command. To restore the default settings, use the no form of this command.
port port-number
Syntax Description
port number Configures the TCP or UDP port number to which the HTTP probe is to connect.
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
12.1(3a)E This command was introduced.
Release
Modification
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 http Router(config-slb-probe)# port 8
Related Commands
Configures the IP IOS SLB probe name. Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays an IOS SLB HTTP or ping probe configuration.
Command
Description
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]
Syntax Description
roundrobin (Optional) Use 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. leastconns (Optional) Use 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
Weighted round robin
Command Modes
Server farm configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example specifies the weighted least connections algorithm:
Router(config)# ip slb serverfarm PUBLIC Router(config-slb-sfarm)# predictor leastconns
Related Commands
Displays information about the server farm configuration. Specifies the real server's capacity, relative to other real servers in the server farm.
Command
Description
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]
Syntax Description
port (Optional) Use the source and destination TCP or UDP port numbers, as well as the source and destination IP addresses, in the hash algorithm used to select a firewall.
Defaults
Use the source and destination IP addresses in the hash algorithm.
Command Modes
Firewall farm configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example specifies the hash algorithm is to use the source and destination IP addresses:
Router(config)# ip slb firewall FIRE1 Router(config-slb-fw)# predictor hash address
Related Commands
Displays information about the firewall farm configuration. Specifies the firewall's capacity, relative to other firewalls in the firewall farm.
Command
Description
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
Syntax Description
name Name of the probe to associate with this firewall farm.
Defaults
No default behavior or values.
Command Modes
Firewall farm real server configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
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 FIRE1 Router(config-slb-fw-real)# probe DAWN
Related Commands
Displays information about the server farm configuration.
Command
Description
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
Syntax Description
name Name of the probe to associate with this server farm.
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
12.1(2)E This command was introduced.
Release
Modification
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 PUBLIC Router(config-slb-sfarm)# probe PROBE1
Related Commands
Displays information about the server farm configuration.
Command
Description
To identify a firewall as a member of a firewall farm, 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
Syntax Description
ip-address Real server IP address.
Defaults
No default behavior or values.
Command Modes
Firewall farm configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
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 FIRE1 Router(config-slb-fw)# real 10.1.1.1 Router(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.
Command
Description
To identify a real server as a member of a server farm, 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]
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.
Release
Modification
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 PUBLIC Router(config-slb-sfarm)# real 10.1.1.1 Router(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.
Command
Description
Use the reassign real server configuration command to specify the threshold of consecutive unanswered synchronizations that, if exceeded, result in an attempted connection to a different real server. To restore the default reassignment threshold, use the no form of this command.
reassign threshold
Syntax Description
threshold Number of unanswered TCP SYNs that are directed to a real server before the connection is reassigned to a different real server. An unanswered 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
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example sets the threshold of unanswered SYNs to 2:
Router(config)# ip slb serverfarm PUBLIC Router(config-slb-sfarm)# real 10.10.1.1 Router(config-slb-real)# reassign 2
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the server farm configuration. Displays information about the real servers.
Command
Description
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]]
Syntax Description
listening-ip Specifies the listening IP address for state exchange messages that are advertised. remote-ip Specifies the destination IP address for all state exchange signals. port-number The ports and the valid name or number for the port-number argument are as follows: interval (Optional) Maximum replication delivery interval from 1 to 300 seconds. password (Optional) Specifies a password for MD5 authentication. 0 (Optional) Specifies that the password is unencrypted. This is the default setting. 7 (Optional) Specifies that the password is encrypted. password (Optional) Password value for MD5 authentication. This password must match the password configured on the host agent. timeout (Optional) Delay period, in seconds, during which both the old password and the new password are accepted.
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
12.1(3a)E This command was introduced.
Release
Modification
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 FIRE1 Router(config-slb-fw)# replicate casa 10.10.10.11 10.10.11.12 4231
Related Commands
Displays the configuration of IOS SLB IP replication. Displays information about the firewall farm configuration.
Command
Description
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]]
Syntax Description
listening-ip Specifies the listening IP address for state exchange messages that are advertised. remote-ip Specifies the destination IP address for all state exchange signals. port-number The ports and the valid name or number for the port-number argument are as follows: interval (Optional) Maximum replication delivery interval from 1 to 300 seconds. password (Optional) Specifies a password for MD5 authentication. 0 (Optional) Specifies that the password is unencrypted. This is the default setting. 7 (Optional) Specifies that the password is encrypted. password (Optional) Password value for MD5 authentication. This password must match the password configured on the host agent. timeout (Optional) Delay period, in seconds, during which both the old password and the new password are accepted.
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.
Release
Modification
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 VS1 Router(config-slb-vserver)# replicate casa 10.10.10.11 10.10.11.12 4231
Related Commands
Displays the configuration of IOS SLB IP replication. Displays information about the virtual servers.
Command
Description
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]
Syntax Description
method Configures the way the data is requested from the server. get Configures the Get method to request data from the server. post Configures the Post method to request data from the server. head Configures the header data type to request data from the server. name Name keyword to be followed by the name of the data to request data from the server. name Configures the name string of the data to send to the servers. The character string is limited to 15 characters. url (Optional) Configures the path from the server. path (Optional) Path from the server.
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
12.1(2)E This command was introduced.
Release
Modification
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 http Router(config-slb-probe)# request method post url /probe.cgi?all
Related Commands
Configures the IOS SLB IP probe name. Displays an IOS SLB HTTP probe configuration.
Command
Description
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
Syntax Description
retry-value Time, in seconds, to wait after the detection of a server failure before a new connection to the server is attempted. If the new connection attempt succeeds, the real server is placed in OPERATIONAL state. If the connection attempt fails, the timer is reset, the connection is reassigned, and the process repeats until it is successful or until the server is placed OUTOFSERVICE by the network administrator. Valid values range from 1 to 3600. The default value is 60 seconds. A value of 0 means do not attempt a new connection to the server when it fails.
Defaults
The retry-value default is 60 seconds.
Command Modes
Real server configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
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 PUBLIC Router(config-slb-sfarm)# real 10.10.1.1 Router(config-slb-real)# retry 120
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the server farm configuration. Displays information about the real servers.
Command
Description
To associate a real server farm with a virtual server, 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 serverfarm-name
Syntax Description
serverfarm-name Name of a server farm that has already been defined using the ip slb serverfarm command.
Defaults
No default behavior or values.
Command Modes
Virtual server configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
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_HTTP Router(config-slb-vserver)# virtual 10.0.0.1 tcp www Router(config-slb-vserver)# serverfarm PUBLIC
Related Commands
Displays information about the virtual servers. Configures the virtual server attributes.
Command
Description
To display the active IOS SLB connections, use the show ip slb conns privileged EXEC command.
show ip slb conns [vserver virtserver-name] [client ip-address] [detail]
Syntax Description
vserver (Optional) Displays only those connections associated with a particular virtual server. virtserver-name (Optional) Name of the virtual server to be monitored. client (Optional) Displays only those connections associated with a particular client IP address. ip-address (Optional) IP address of the client to be monitored. detail (Optional) Displays detailed connection information.
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.
Release
Modification
Examples
The following example shows IOS SLB active connection data:
router# show ip slb conns vserver prot client real state ---------------------------------------------------------------------------- TEST TCP 7.150.72.183:328 80.80.90.25:80 INIT TEST TCP 7.250.167.226:423 80.80.90.26:80 INIT TEST TCP 7.234.60.239:317 80.80.90.26:80 ESTAB TEST TCP 7.110.233.96:747 80.80.90.26:80 ESTAB TEST TCP 7.162.0.201:770 80.80.90.30:80 CLOSING TEST TCP 7.22.225.219:995 80.80.90.26:80 CLOSING TEST TCP 7.2.170.148:169 80.80.90.30:80 ZOMBIE
| Field | Description |
vserver | Name of the virtual server whose connections are being monitored and displayed. Information about each connection is displayed on a separate line. |
prot | Protocol being used by the connection. |
client | Client IP address being used by the connection. |
real | Real IP address of the connection. |
state | Current state of the connection:
|
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 ip_address port-number | detail | weights]
Syntax Description
agent (Optional) Displays information about an agent. ip_address (Optional) Agent IP address. port (Optional) Agent TCP or UDP port number. detail (Optional) Displays all data available. weights (Optional) Displays information about weights assigned to real servers for load balancing.
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.
Release
Modification
Examples
The following example shows DFP data:
router# show ip slb dfp detail
DFP Manager:
Current passwd:NONE Pending passwd:NONE
Passwd timeout:0 sec
Unexpected errors:0
DFP Agent 161.44.2.34:61936 Connection state:Connected
Timeout = 0 Retry Count = 0 Interval = 180 (Default)
Security errors = 0
Last message received:10:20:26 UTC 11/02/99
Last reported Real weights for Protocol TCP, Port www
Host 17.17.17.17 1 Weight 1
Host 68.68.68.68 Bind ID 4 Weight 4
Host 85.85.85.85 Bind ID 5 Weight 5
Last reported Real weights for Protocol TCP, Port 22
Host 17.17.17.17 Bind ID 111 Weight 111
router# show ip slb dfp weights
Real IP Address 17.17.17.17 Protocol TCP Port 22 Bind_ID 111 Weight 111
Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99
Real IP Address 17.17.17.17 Protocol TCP Port www Bind_ID 1 Weight 1
Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99
Real IP Address 68.68.68.68 Protocol TCP Port www Bind_ID 4 Weight 4
Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99
Real IP Address 85.85.85.85 Protocol TCP Port www Bind_ID 5 Weight 5
Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99
router# show ip slb dfp
DFP Manager:
Current passwd:NONE Pending passwd:NONE
Passwd timeout:0 sec
Agent IP Port Timeout Retry Count Interval
---------------------------------------------------------------
161.44.2.34 61936 0 0 180 (Default)
| Field | Description |
Agent IP | IP address of the agent about which information is being displayed. |
Port | TCP or UDP port number of the agent. |
Timeout | Time period, in seconds, during which the DFP manager must receive an update from the DFP agent. A value of 0 means there is no timeout. |
Retry Count | Number of times the DFP manager attempts to establish the TCP connection to the DFP agent. A value of 0 means there are infinite retries. |
Interval | Interval, in seconds, between retries. |
State | Current state of the connection.
|
To display firewall farm information, use the show ip slb firewallfarm configuration command.
show ip slb firewallfarm [detail]
Syntax Description
detail (Optional) Displays detailed information.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example shows firewall farm data:
Router# show ip slb firewallfarm firewall farm hash state reals ------------------------------------------------ FIRE1 IPADDR OPERATIONAL 2
| Field | Description |
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. |
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
name (Optional) Keyword to display a specific NAT pool. pool-name (Optional) NAT pool name string to display. detail (Optional) Lists all the interval ranges currently allocated in the client NAT pool.
Defaults
No default behavior or values.
Command Modes
EXEC configuration
Command History
12.1(2)E This command was introduced.
Release
Modification
Examples
The following example displays the default show ip slb natpool command:
Router# show ip slb natpool nat client B 1.1.1.6 1.1.1.8 Netmask 255.255.255.0 nat client A 1.1.1.1 1.1.1.5 Netmask 255.255.255.0
The following example displays the show ip slb natpool command with the additional detail parameter:
Router# show ip slb natpool detail
nat client A 1.1.1.1 1.1.1.5 Netmask 255.255.255.0
Start NAT Last NAT Count ALLOC/FREE
-------------------------------------------------------
1.1.1.1:11001 1.1.1.1:16333 0005333 ALLOC
1.1.1.1:16334 1.1.1.1:19000 0002667 ALLOC
1.1.1.1:19001 1.1.1.5:65535 0264675 FREE
nat client B 1.1.1.6 1.1.1.8 Netmask 255.255.255.0
Start NAT Last NAT Count ALLOC/FREE
-------------------------------------------------------
1.1.1.6:11001 1.1.1.6:16333 0005333 ALLOC
1.1.1.6:16334 1.1.1.6:19000 0002667 ALLOC
1.1.1.6:19001 1.1.1.8:65535 0155605 FREE
Related Commands
Configures the IOS SLB NAT.
Command
Description
To display information about an IOS SLB HTTP or ping probe, use the show ip slb probe configuration command.
show ip slb probe [name probe_name] [detail]
Syntax Description
name (Optional) Displays information about the specific probe named. probe_name (Optional) Probe name to display. detail (Optional) Displays detailed information, including the SA Agent operation ID, which you can use to correlate the output of the show rtr operational-state EXEC command.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
12.1(2)E This command was introduced.
Release
Modification
Examples
The following example shows IOS SLB HTTP probe data:
Router# show ip slb probe Server:Port State Outages Current Cumulative ---------------------------------------------------------------- 10.10.4.1:0 OPERATIONAL 0 never 00:00:00 10.10.5.1:0 FAILED 1 00:00:06 00:00:06
| Field | Description |
Server:Port | IP address and port of the real server. |
State | Operational state of the probe:
|
Outage | Number of intervals between successful probes. |
Current | Time since the last probe success. That is, the duration (so far) of the current outage. |
Cumulative | Total time the real server has been under test by the probe and has failed the probe test. This value is the sum of the Current time plus the total time of all previous outages. |
To display information about the real servers, use the show ip slb reals privileged EXEC command.
show ip slb reals [vserver virtserver-name] [detail]
Syntax Description
vserver (Optional) Displays information about only those real servers associated with a particular virtual server. virtserver-name (Optional) Name of the virtual server. detail (Optional) Displays detailed information.
Defaults
If no options are specified, the command displays information about all real servers.
Command Modes
Privileged EXEC
Command History
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example shows IOS SLB real server data:
router# show ip slb reals real farm name weight state conns -------------------------------------------------------------------- 80.80.2.112 FRAG 8 OUTOFSERVICE 0 80.80.5.232 FRAG 8 OPERATIONAL 0 80.80.15.124 FRAG 8 OUTOFSERVICE 0 80.254.2.2 FRAG 8 OUTOFSERVICE 0 80.80.15.124 LINUX 8 OPERATIONAL 0 80.80.15.125 LINUX 8 OPERATIONAL 0 80.80.15.126 LINUX 8 OPERATIONAL 0 80.80.90.25 SRE 8 OPERATIONAL 220 80.80.90.26 SRE 8 OPERATIONAL 216 80.80.90.27 SRE 8 OPERATIONAL 216 80.80.90.28 SRE 8 TESTING 1 80.80.90.29 SRE 8 OPERATIONAL 221 80.80.90.30 SRE 8 OPERATIONAL 224 80.80.30.3 TEST 100 READY_TO_TEST 0 80.80.30.4 TEST 100 READY_TO_TEST 0 80.80.30.5 TEST 100 READY_TO_TEST 0 80.80.30.6 TEST 100 READY_TO_TEST 0
| Field | Description |
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.
|
To display the IOS SLB replication configuration, use the show ip slb replicate privileged EXEC command.
show ip slb replicateSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
12.1(2)E This command was introduced.
Release
Modification
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#
Related Commands
Configures IOS SLB replication.
Command
Description
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
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example shows IOS SLB server farm data:
router# show ip slb serverfarms server farm predictor reals bind id ------------------------------------------------- FRAG ROUNDROBIN 4 0 LINUX ROUNDROBIN 3 0 SRE ROUNDROBIN 6 0 TEST ROUNDROBIN 4 0
| Field | Description |
server farm | Name of the server farm about which information is being displayed. Information about each server farm is displayed on a separate line. |
predictor | Type of load-balancing algorithm (ROUNDROBIN or LEASTCONNS) used by the server farm. |
reals | Number of real servers configured in the server farm. |
bind id | Bind ID configured on the server farm. |
To display IOS SLB statistics, use the show ip slb stats privileged EXEC command.
show ip slb statsSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example shows IOS SLB statistics:
router# show ip slb stats Pkts via normal switching: 0 Pkts via special switching: 12534087 Connections Created: 12466960 Connections Established: 12240100 Connections Destroyed: 12466960 Connections Reassigned: 0 Zombie Count: 0 Connections Reused: 0 Connection Flowcache Purges: 0 Failed Connection Allocs: 0 Failed Real Assignments: 0 Total indications: 0 Unknown conn indications: 0 SYNACK indications: 0 RST client indications: 0 RST server indications: 0 Two FINs indications: 0 Flow age indications: 0
| Field | Description |
Pkts via normal switching | Number of packets handled by IOS SLB via normal switching since the last time counters were cleared. |
Pkts via special switching | Number of packets handled by IOS SLB via special switching since the last time counters were cleared. |
Connections Created | Number of connections created since the last time counters were cleared. |
Connections Established | Number of connections created and have become established since the last time counters were cleared. |
Connections Destroyed | Number of connections destroyed since the last time counters were cleared. |
Connections Reassigned | Number of connections reassigned to a different real server since the last time counters were cleared. |
Zombie Count | Number of connections that are currently pending destruction (awaiting a timeout or some other condition to be met). |
Connections Reused | Number of zombie connections reused since the last time counters were cleared. A zombie connection is reused if it receives a TCP SYN or UDP packet and succeeds in connecting to a real server. The zombie connection becomes a real connection and the zombie count is decremented. |
Connection Flowcache Purges | Number of times the connection flow cache was purged since the last time counters were cleared. |
Failed Connection Allocs | Number of times the allocation of a connection failed since the last time counters were cleared. |
Failed Real Assignments | Number of times the assignment of a real server failed since the last time counters were cleared. |
Total indications | Total number of indications of all types since the last time counters were cleared. |
Unknown conn indications | Number of times unknown connections were detected since the last time counters were cleared. |
SYNACK indications | Number of TCP SYN/ACK events since the last time counters were cleared. |
RST client indications | Number of TCP RST client events since the last time counters were cleared. |
RST server indications | Number of TCP RST server events since the last time counters were cleared. |
Two FINs indications | Number of times two FINs (one in each direction) were detected on the connection since the last time counters were cleared. |
Flow age indications | Number of times TCP flows aged out since the last time counters were cleared. |
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
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example shows the IOS SLB sticky database:
Router# show ip slb sticky client netmask group real conns ----------------------------------------------------------------------- 10.10.2.12 255.255.0.0 4097 10.10.3.2 1 Router#
| Field | Description |
client | Client IP address or subnet which is bound to this sticky assignment. |
netmask | Subnet mask for this sticky assignment. |
group | Group ID for this sticky assignment. |
real | Real server used by all clients connecting with the client IP address or subnet detailed on this line. |
conns | Number of connections currently sharing this sticky assignment. |
To display information about the virtual servers, use the show ip slb vservers privileged EXEC command.
show ip slb vservers [name virtserver-name] [detail]
Syntax Description
name (Optional) Displays information about only this virtual server. virtserver-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
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example shows virtual server data:
router# show ip slb vservers slb vserver prot virtual state conns --------------------------------------------------------------------- TEST TCP 80.80.254.3:80 OPERATIONAL 1013 TEST21 TCP 80.80.254.3:21 OUTOFSERVICE 0 TEST23 TCP 80.80.254.3:23 OUTOFSERVICE 0
| Field | Description |
slb vserver | Name of the virtual server about which information is being displayed. Information about each virtual server is displayed on a separate line. |
prot | Protocol being used by the virtual server detailed on a given line. |
virtual | Virtual IP address of the virtual server detailed on a given line. |
state | Current state of the virtual server detailed on a given line:
|
conns | Number of connections associated with the virtual server detailed on a given line. |
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
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
10.0 This command was introduced.
Release
Modification
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 1 Router(config-if)# standby 1 authentication word
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
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
12.1(1)E This command was introduced.
Release
Modification
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/0 Router(config-if)# ip address 172.18.48.154 255.255.255.128 Router(config-if)# standby 1 ip 172.18.48.124 Router(config-if)# standby 1 priority 2 preempt Router(config-if)# standby 1 name Web-Group
Related Commands
Enables the virtual server for use by IOS SLB.
Command
Description
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]]
Syntax Description
group-number (Optional) Group number on the interface to which the other arguments in this command apply. priority priority (Optional) Priority value that prioritizes a potential Hot Standby router. The range is 1 to 255. preempt delay delay (Optional) Time in seconds. The delay argument causes the local router to postpone taking over the active role for delay seconds since that router was last restarted. The range is 0 to 3600 seconds (1 hour).
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).
Command Modes
Interface configuration
Command History
11.3 This command was introduced.
Release
Modification
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.
Examples
In the following example, the router has a priority of 120 (higher than the default value) and waits for 300 seconds (5 minutes) before attempting to become the active router:
Router(config)# interface fastethernet 1 Router(config-if)# standby ip 172.19.108.254 Router(config-if)# standby priority 120 preempt delay 300
Related Commands
Configures the standby track on an interface so that the Hot Standby priority changes based on the availability of other interfaces.
Command
Description
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
Syntax Description
group-number (Optional) Group number on the interface to which the timers apply. hellotime Hello interval in seconds. This is an integer from 1 to 255. holdtime Time in seconds before the active or standby router is declared to be down. This is an integer from 1 to 255.
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
10.0 This command was introduced.
Release
Modification
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 1 Router(config-if)# standby 1 ip Router(config-if)# standby 1 timers 5 15
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]
Syntax Description
group-number (Optional) Group number on the interface to which the tracking applies. type Interface type (combined with interface number) that will be tracked. number Interface number (combined with interface type) that will be tracked. interface-priority (Optional) Amount by which the Hot Standby priority for the router is decremented (or incremented) when the interface goes down (or comes back up).
Defaults
The default group number is 0.
The default interface priority is 10.
Command Modes
Interface configuration
Command History
10.3 This command was introduced.
Release
Modification
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 1 Router(config-if)# ip address 198.92.72.37 255.255.255.240 Router(config-if)# no ip redirects Router(config-if)# standby track fastethernet 10 Router(config-if)# standby track gigabitethernet 49 Router(config-if)# standby preempt Router(config-if)# standby ip 198.92.72.46
Related Commands
Configures the Hot Standby Router Protocol (HSRP) priority, preemption, and preemption delay.
Command
Description
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]
Syntax Description
duration Sticky timer duration in seconds. Valid values range from 0 to 65535. netmask (Optional) Places the virtual server as part of a sticky subnet, for coupling of services. netmask (Optional) Sticky subnet mask number.
Defaults
Virtual servers are not associated with any groups.
Command Modes
Firewall farm TCP protocol configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
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 FIRE1 Router(config-slb-fw)# tcp Router(config-slb-fw-tcp)# sticky 60
Related Commands
Displays information about the firewall farm configuration. Displays information about the virtual server or firewall farm sticky configuration. Initiates TCP protocol configuration mode.
Command
Description
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]
Syntax Description
duration Sticky timer duration in seconds. Valid values range from 0 to 65535. netmask (Optional) Places the virtual server as part of a sticky subnet, for coupling of services. netmask (Optional) Sticky subnet mask number.
Defaults
Virtual servers are not associated with any groups.
Command Modes
Firewall farm UDP protocol configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
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 FIRE1 Router(config-slb-fw)# udp Router(config-slb-fw-udp)# sticky 60
Related Commands
Displays information about the firewall farm configuration. Displays information about the virtual server or firewall farm sticky configuration. Initiates UDP protocol configuration mode.
Command
Description
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]
Syntax Description
duration Sticky timer duration in seconds. Valid values range from 0 to 65535. group (Optional) Places the virtual server in a sticky group, for coupling of services. group-id (Optional) Number identifying the sticky group to which the virtual server belongs. Valid values range from 0 to 255. netmask (Optional) Places the virtual server as part of a sticky subnet, for coupling of services. netmask (Optional) Sticky subnet mask number.
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.
Release
Modification
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 VS1 Router(config-slb-vserver)# sticky 60 group 10
Related Commands
Displays information about the virtual server or firewall farm sticky configuration. Displays information about the virtual servers. Configures the virtual server attributes.
Command
Description
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]
Syntax Description
syn-count Number of unanswered SYNs that are allowed to be outstanding to a virtual server. Valid values range from 0 (off) to 4294967295. The default is 0. interval (Optional) Interval, in milliseconds, for SYN threshold monitoring. Valid values range from 50 to 5000. The default is 100 ms.
Defaults
Syn-count default: 0 (off)
Interval default: 100 ms
Command Modes
Virtual server configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
Examples
The following example sets the threshold of unanswered SYNs to 50:
Router(config)# ip slb vserver PUBLIC_HTTP Router(config-slb-vserver)# synguard 50
Related Commands
Displays information about the virtual servers. Configures the virtual server attributes.
Command
Description
To initiate TCP protocol configuration mode, use the tcp firewall farm configuration command.
tcpDefaults
No default behavior or values.
Command Modes
Firewall farm configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example initiates TCP protocol configuration mode:
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# tcp Router(config-slb-fw-tcp)# exit
Related Commands
Displays information about the firewall farm configuration.
Command
Description
To initiate UDP protocol configuration mode, use the udp firewall farm configuration command.
udpDefaults
No default behavior or values.
Command Modes
Firewall farm configuration
Command History
12.1(3a)E This command was introduced.
Release
Modification
Examples
The following example initiates UDP protocol configuration mode:
Router(config)# ip slb firewallfarm FIRE1 Router(config-slb-fw)# udp Router(config-slb-fw-udp)# exit
Related Commands
Displays information about the firewall farm configuration.
Command
Description
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 {tcp | udp} [port-number] [service service-name]
Syntax Description
ip-address IP address for this virtual server instance, used by clients to connect to the server farm. tcp Perform load balancing for only TCP connections. udp Perform load balancing for only UDP connections. port-number (Optional) IOS SLB virtual port (the TCP or UDP port number or port name). If specified, only the connections for the specified port on the server are load-balanced. The ports and the valid name or number for the port-number argument are as follows: Specify a port number of 0 to configure an all-port virtual server (that is, a virtual server that accepts flows destined for all ports). service (Optional) Couple connections associated with a given service, such as HTTP or Telnet, so all related connections from the same client use the same real server. service-name (Optional) Type of connection coupling. Currently, the only choice is:
Defaults
No default behavior or values.
Command Modes
Virtual server configuration
Command History
12.0(7)XE This command was introduced.
Release
Modification
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.
|
Note 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 servers reject these flows, IOS SLB might fail the server and remove it from load balancing. |
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_HTTP Router(config-slb-vserver)# virtual 10.0.0.1 tcp www
The 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_HTTP Router(config-slb-vserver)# virtual 10.0.0.13 udp 0
Related Commands
Identifies a virtual server. Displays information about the virtual servers.
Command
Description
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
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
12.1(3a)E This command was introduced.
Release
Modification
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 FIRE1 Router(config-slb-fw)# real 10.10.1.1 First real server Router(config-slb-fw-real)# weight 16 Assigned weight of 16 Router(config-slb-fw-real)# inservice Enabled Router(config-slb-fw-real)# exit Router(config-slb-fw)# real 10.10.1.2 Second real server Router(config-slb-fw-real)# inservice Enabled; default weight Router(config-slb-fw-real)# exit Router(config-slb-fw)# real 10.10.1.3 Third real server Router(config-slb-fw-real)# weight 24 Assigned weight of 24; not enabled
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the firewall farm configuration. Displays information about the real servers.
Command
Description
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
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
12.0(7)XE This command was introduced.
Release
Modification
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 PUBLIC Router(config-slb-sfarm)# real 10.10.1.1 First real server Router(config-slb-real)# weight 16 Assigned weight of 16 Router(config-slb-real)# inservice Enabled Router(config-slb-real)# exit Router(config-slb-sfarm)# real 10.10.1.2 Second real server Router(config-slb-real)# inservice Enabled; default weight Router(config-slb-real)# exit Router(config-slb-sfarm)# real 10.10.1.3 Third real server Router(config-slb-real)# weight 24 Assigned weight of 24; not enabled
Related Commands
Identifies a real server as a member of a server farm and initiates real server configuration mode. Displays information about the server farm configuration. Displays information about the real servers.
Command
Description
This section documents the following new debug command related to the IOS SLB feature:
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 | all}
Syntax Description
all Displays all debug messages for IOS SLB. conns Displays debug messages for all connections being handled by IOS SLB. dfp Displays debug messages for DFP and the DFP agents. 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.
Defaults
No default behavior or values.
Command Modes
EXEC configuration
Command History
12.0(7)XE This command was introduced. 12.1(2)E The natpool and replication keywords were added. 12.1(3a)E The firewallfarm keyword was added.
Release
Modification
Usage Guidelines
See the following caution before using debug commands:
 |
Caution Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, only use debug commands to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network flows and fewer users. Debugging during these periods reduces the effect these commands have on other users on the system. |
Examples
The following example configures a debug session to check all IP IOS SLB parameters:
Router# debug ip slb all SLB All debugging is on Router#
The following example stops all debugging:
Router# no debug all All possible debugging has been turned off Router#
The following example configures debugging to check IP IOS SLB replication used with stateful backup and displays the output from the send or transmit virtual server:
Router# debug ip slb replication *Mar 2 08:02:38.019: SLB Replicate: (send) update vs: VS1 update_count 42
The following questions and answers can help you troubleshoot IOS SLB, if you have problems.
| Question | Answer |
|---|---|
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 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 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 flow current ip flowmask for unicast: full flow current ipx flowmask for unicast: destination only The current IP flowmask must be full flow. If it is not, correct the problem using the mls flow ip full command: Router# config t Enter configuration commands, one per line. End with CNTL/Z. Router(config)# mls flow ip full Router(config)# |
How can I verify that IOS SLB sticky connections are working properly? | Use the following procedure: 1. Configure the sticky connections. 2. Start a client connection. 3. Enter the show ip slb reals detail and show ip slb conns commands. 4. Examine the real server connection counts. The real server whose count increased is the one to which the client connection is assigned. 5. Enter the show ip slb sticky command to display the sticky relationships that IOS SLB stored. 6. End the connection. 7. Ensure that the real server's connection count decreased. 8. Restart the connection, after waiting no longer than the sticky timeout value. 9. Enter the show ip slb conns command again. 10. Examine the real server connection counts again, and verify that the sticky connection is assigned to the same real server as before. |
How can I verify that server failures are being detected correctly? | Use the following procedure:
1. Use a large client population. If the number of clients is very small, tune the numclients keyword on the faildetect (real server) command so that the servers are not displayed as FAILED. 2. Enter the show ip slb reals detail command to show the status of the real servers. 3. Examine the status and connection counts of the real servers.
|
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.
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.
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 Web cache. 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 manager.
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 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.
Hot Standby Routing Protocol—See HSRP.
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.
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.
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.
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.
Posted: Tue Sep 26 07:25:53 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.